# Exact work-intent resolution — September 12, 2026

State: local implementation and verification; not production publication or whole-goal completion.

The immediately preceding rollback explanation was status-only, not implementation progress. This continuation rechecked current instructions, worktree, live state, intake and existing agent handles before integrating the pending recovery work. The full intake/usefulness/memory/deployment/testing goal remains unchanged.

## What changed

`POST /api/matm/commons/work-resolution` resolves one authenticated actor's exact original work POST. Under the existing actor/credential locks and transaction, it either returns the committed original operation's **current** projection or inserts a permanent prevention record into that same original actor/path/key slot. The outer resolution receipt commits with the prevention record. The endpoint never executes the original request, edits another actor's slot, restores withdrawn payloads or grants payment/execution authority.

No database table, writable runtime, credential registry or raw-body journal was added. Retained records contain keyed references, not original bodies or either raw idempotency key. Both original and resolution keys remain in the existing protected client custody while pending. New successful original receipts jointly authenticate their stored request digest and result reference. Historical successful references retain ordinary current replay, but cannot certify an applied resolution without that newer binding; they return `503 work_resolution_legacy_reference_unbound`, never manufactured proof or a replacement fence.

The optional protected controller adds `resolve_work_intent()`. Once resolution mode/key is durably saved, restart/resume sends only that exact resolution. Each physical attempt charges the cleanup pool; earlier unknown charges remain held. Valid completion or prevention retires the pending body/key but preserves the intent tombstone and cumulative task accounting. Distinct subsequent intents are allowed within the same remaining task budget; replacing the task budget is still unfinished engineering.

Initial-save boundary: if neither custody copy receives the selected resolution mode, no resolution request was sent and restart can still show original mode. Re-request resolution explicitly after such a failure; do not blindly resume the original operation. A saved newer copy repairs its peer before sending. Resolution respects current authority, retry timing, halt and finite cleanup capacity; passing the ordinary deadline does not grant unlimited dispatch.

Public source owners now include the exact root route, discovery bundle, request schema, response/receipt/key binding, condition meanings, current-state replay, permanent quotas and download parity. Seventeen explicitly fictional request examples include resolution; no response receipt, actual demand or performed work is fabricated. The guides retain source-only/pending-deployment status.

## Defects reproduced and repaired

- Copying a valid other operation's keyed request digest into a valid successful slot was not jointly authenticated by the older result-reference MAC. The new binding rejects that splice; historical ordinary replay remains compatible without upgrading its proof.
- Expiry while waiting for the original slot, capacity read or current history now stops resolution. Main also reproduced expiry during outer-receipt insertion: the added test returned 200 where 401 was required. The final pre-commit authority check repaired it and rolls back both rows.
- An independent code review reproduced a backward-clock shift during dispatch save that could cross persisted retry timing. The correction and focused final results are recorded below when complete.
- Root GET on a POST-only resolution path follows the existing no-read-owner behavior (404); unsupported mutation methods return405. The initial test incorrectly expected405 for GET. The repaired test verifies no body/database authority, rather than altering the existing route policy.
- Adding the resolution request example changed the guide count16→17; the old fixed-count test failed, then was strengthened to check the exact original body/key association and distinct outer key.
- During coordinated native-harness/runner editing, the runner correctly rejected old ten-gate fixture results. These transient failures are not native database failures or passing evidence. Current required gates include all ten prior gates plus resolution race, current withdrawal and atomicity.

## Direct observations so far

- Owned WSGI/auth/SQLite-transport resolution suite:54PASS after final pre-commit expiry repair.
- Root work integration:23PASS, including actual prevention, authenticated current withdrawal and missing authority.
- Wire helper:60PASS after root registry integration.
- Protected actual-owned-handler/custody integration:25PASS, including six native Windows custody cases, before the final retry/save-boundary additions.
- Public client contract:9PASS; subsequent guide changes require final regeneration/recheck.
- Isolated-runner safeguards:41PASS after coordinated gate declaration update. Native concurrency/restart execution remains separately recorded below, not inferred from these fixtures.

At **2026-09-13T00:23:16Z**, certificate-validated anonymous GETs reported operationalAvailable=true, productionReady=false, Commons available=true, backend=mysql, workExchange absent. Production was not changed. This is a read-only observation, not exact deployed-byte attestation or a renewed acceptance receipt.

## Intake and remaining work

Both queues were scanned: integrityPASS,16active fully reviewed files,718981bytes,67closed records,83total,0new. Prior reviews are reused only for their exact source hashes. No source was removed or declared incorporated merely because a new test passed.

This work applies the reliability/protocol recommendations for exact effect reconciliation and the operations/resource recommendations for reserved cleanup and retained uncertainty. It does not close source-rights/correction dependencies, safe subsequent task retirement, metered reads/credential lifecycle, hard transport deadlines, arbitrary future recovery-chain capacity, fallback work-retention maintenance, Passenger operation, responsive visual QA, publication or public-documentation-only useful pilot/cleanup. Actual ChatGPT connector acceptance remains separately owned.

Limits:64 permanent fences and256 permanent resolution receipts per actor; existing exact replays remain available at capacity. LIMIT bounds returned rows, not worst-case index-scan work. A valid wrapper is at most24576UTF-8 bytes and may be smaller under configuration. Stale nested original policy may be fenced but is never executed; the original supported top-level POST envelope remains required. No identity cycling, key substitution or ledger reset is a quota-recovery path.

## Fresh native MySQL result

`reports/v049-work-resolution-native-20260912.json` records **PASS_NATIVE_ISOLATED** on MySQL9.7.0-commercial / REPEATABLE READ, both historical baselines1/2. All13mandatory gates passed on each: ten existing migration/constraint/workflow/replay/cleanup gates plus both same-slot resolution race orders, current withdrawn-result resolution and atomic failure rollback. Wire validation was exercised against actual handler results. Separate native connection IDs and a held first actor lock prove the tested serialized outcomes; the overlap hook is not server lock-wait telemetry.

Both baselines also passed actual server-process restart with unchanged data directory/port/version and changed verified owned PID. Cold readback preserved exact fence/outer receipt, permanent late-original410, current withdrawn result, same identity, revoked-authority rejection and continuation of a separate active agreement. No fallback archive or Passenger restart was run in this invocation.

The isolated runner returned exit0. It removed exactly105/106fixture rows respectively, never dropped the schema, confirmed serverStopped=true/serverExitCode0, and removed generated plaintext fixture credentials. Stopped private fixture data remains at `[PRIVATE LOCAL PATH]`; no existing service or production was accessed. Original summary SHA256: `b49d5c874d92281fea85871c6dc507a0d328045ba4386bc51c35a39b979eabf9`. Runner SHA256: `7653e2777634e9eb836cfd867eaddaa8466615f74b0dc4db4dfccf5f70d64ea7`. The evidence JSON binds runtime/schema/harness/wire-helper source hashes; controller/browser/deployment are not inferred from those bindings.

## Final local verification checkpoint

The post-save retry regression failed for both ordinary and resolution dispatch before the fix. Both now recheck persisted retry timing after custody-save latency, alongside authority/deadline checks. Four additional protected-handler tests cover ordinary/resolution clock rollback and failures before the first or second resolution-mode copy is saved. Eight focused tests passed, and the controller suite passed81tests.

After final client download regeneration, a combined run completed **471tests, zero failures/errors/skips**, in79.140seconds. Modules: wire60, controller81, budget48, autonomous39, actual-owned/custody29(including6native Windows cases), public-contract9, work-root23, records15, owned-work58, resolution54, existing-root20, UAIX-strategy9, discovery12, native-harness-resolution-model14. This run uses isolated fixture identities/storage and does not access production. The independent real MySQL run is described above.

An earlier public-download parity check caught the controller changing during delegated work; regeneration repaired that drift before the final combined run. Native evidence JSON is byte-identical to the original summary (same SHA256 above), and every bound native source hash still matches current source. Committed-extraction and package identities are recorded separately after execution; no earlier count substitutes for them. Keep releases `-wip.zip` and the full goal active.

## Committed-package regression

Checkpoint70e52da was committed/pushed and both WIP ZIPs built. After extraction had definitively finished, the same471tests ran in80.860seconds with470PASS/1FAIL/0errors/0skips. The failure was the actual-root wire workflow's correction: a fresh time-derived terms object advanced retention beyond the original selection, correctly receiving409 rather than the test's expected200. This failed run remains in `validation-70e52da-wip.json` beside the original ZIPs; it is not accepted package evidence. The fixture correction must retain selected terms and prove its behavior across a second boundary, without weakening the runtime retention check.

Original ZIP CRCs, six source/download pairs and protected hero bytes passed. The initial overly broad private-path assertion flagged `runtime/release.json`; inspection confirmed this is the existing generated release metadata (schema, source commit, version, runtime/backend and exposure declarations), not mutable custody. The corrected check allows only that exact runtime member and excludes private memory/reports/intake/secrets from root. No package was deployed.

The fixture defect was reproduced explicitly by advancing the fourth terms selection by one second: `409 work_retention_expansion`. The corrected workflow chooses terms once and uses detached copies. Two regressions now run the complete workflow with a clock advancing on every request and separately prove a genuine one-second retention expansion still fails409 while the original selected retention succeeds. The focused wire suite passed62tests. Only tests, evidence and derived progress memory changed after70e52da; native-bound runtime/helper bytes remain unchanged. The original failed ZIPs/evidence remain retained rather than overwritten.

After that correction, the same combined module set completed **473tests, zero failures/errors/skips**, in76.241seconds. Wire62 replaces wire60; every other module count above is unchanged. Typed progress/export memory records this superseding checkpoint; committed extraction remains a separate required verification.