Delivery observations and ticket closure

GET /v1/work-coordinators/{coordinatorId}/items/{itemId}/delivery-observation returns an allowlisted snapshot of a stored work claim. It requires the existing coordinator read authorization, feature gate, current tenant membership and applicable unrevoked read grant. Responses are private and no-store. Unknown query parameters are rejected.

The response names the organization, coordinator, item, lane and revision. Its claim contains kind, state, canonical manifest source SHA/repository/project when available, and SHA-256 of the raw receipt. It never returns receipt contents, credentials, leases or a signature. The provenance is always work-item-claim/untrusted. recordedAt is the stored item update time, not a freshness guarantee or a production probe.

Acceptance is always unknown/independent-acceptance-unavailable. Neither a live work state, receipt string, receipt hash, review artifact nor public application version proves acceptance of a specific product at an exact source revision. Independent observers must retain that distinction and bind their own deployment observations to an operator-maintained product mapping. No acceptance signer or new authority is installed.

For compatibility, ship/install workers may still record live claims. Their linked closure intents stay pending with an actionable reason; repeated close-tickets calls never dispatch issue mutations. The lane remains blocked while any delivery node is an unaccepted live claim, including an ancestor hidden by a completed child. The shared readiness guard also refuses leases dependent on a live ship/install item. Cross-lane dependencies inspect all upstream delivery nodes, so a passed child cannot hide a live delivery ancestor and release downstream work. The dependency traversal follows passed legacy intermediates and applies the delivery barrier to every crossed predecessor lane. It uses deduplicated IDs to terminate on legacy cycles. Unrelated same-lane work and passed non-delivery predecessors retain their normal scheduling behavior. Agent issue updates to done (including canonical stage changes) are refused for any issue linked to ship/install work, including when an older delivery claims live. A normal authorized human issue closure remains available after independent verification. There is no automatic acceptance override, including for administrator callers or receipt JSON claiming PASS.

A future acceptance authority must provide a separately authenticated, immutable record bound to organization, project/product, item and generation, exact source and observed deployment identity, with freshness/revocation checks before ticket mutation. Until then, automation fails closed. This patch neither retroactively reopens already-closed tickets nor changes unrelated issue workflows.

Verification record

Work is tracked by goodqa#12485 and scenario brief goodqa#12487 under epic goodqa#5955. The brief verifies against its stored rendering; consumer preflight resolves this repository but warns about additional direct consumers. No broad consumer-suite or production-acceptance claim is made.

The real Fastify/PostgreSQL owning suite ran on dev2 through the shared broker, without mocking either side of the authorization/closure seam.

• Original-code snapshot def7e4cf707348cf5419e894294413d24180fb5c: 65 tests executed, 63 passed and two expected negative-control failures. An arbitrary receipt caused the linked closure intent to become completed instead of pending.
• Original-code snapshot e0094ab9fdf4cd12c1bf24863782b1a53aa4a2f2: 67 tests executed, 63 passed and four failures. The direct stale-receipt control returned HTTP 200 and closed the issue instead of refusing with 409. The separate custom-command attempt had zero tests due to unavailable database setup and is not scored as a product failure.
• Candidate snapshot 2da8a1391476e9cb60bacdd781b93f7eefebbe9a: 68/68 owning tests passed, zero skipped and zero unhandled errors. Its code-tree digest is ca36a9127784e5b91e18972cabccbf6ca72ec3d4c2678f48079862fb3cd776f3.
• API-key scope tests pass. The combined API-key/user-token census run has 30 passes and one census failure, reproduced identically on base 2fa59157582e404fcf6ebbbcde09fc09ee67bba8. Its unreviewed key-only branch inventory was not weakened or waived.

Raw reports, logs, source archives and SHA-256 manifests are retained on DEV under /home/eric/release-evidence/delivery-observation-20261028/. The first negative run is negative-first/, the direct stale-receipt replay is issue-negative/, the repaired owning suite is final-owning/, and the matching census runs are auth-candidate/ and auth-baseline/.

These checks prove the bounded claim/closure and observation behavior. They do not prove deployment, independent product acceptance, installed watchdog coverage, owner-process liveness, reviewer availability, or complete GoodQA hardening. No production deployment or flag was changed.

The final-test replay against original main (snapshot 3ab1c37e796eed300e4cc67671f7f8374a95e0fa, run ef89692ca5dd-2df27ad7) executed 68 tests on the dev2 database pool: 59 passed and 9 failed. It independently reproduced the completed-child false green (done instead of blocked) as well as the closure bypasses; the observer route is absent on that baseline. Raw results and original source are preserved in ancestor-negative/ under the evidence directory above.

The exact passing candidate snapshot also passed api-typecheck (pnpm exec tsc --noEmit -p tsconfig.json) with no diagnostics in broker run 2952f89e9119-f27bd90e; log and identity are retained in final-typecheck/.

Scheduling follow-up

Independent review found that the first repair (ba7b206be2686be4082bd791a39248eae497aba6) blocked closure/display but still allowed dependency leasing. The shared readiness guard now traverses dependency ancestors and every crossed predecessor lane, so stored passed intermediates cannot launder an unaccepted delivery claim into readiness.

Frozen baseline 6210ff01a5de30288ed60c40decb1e6fcd8ea441 ran 77 tests: 67 passed and ten scheduling controls failed as expected. Candidate 103309859fadbbaa00b291f70e16094a6ca07e08 passed all 77, including legal non-delivery and unrelated-lane controls. Source archives, raw results and query plans are retained under scheduling/54ca88ecba18-07d88feb/ and scheduling/681390c7b3a7-9f791eb0/ within the evidence directory. Preliminary runs included an invalid positive fixture that partially cleared lease fields; the final matrix uses normal API transitions. Obsolete candidate jobs were stopped and are recorded as stopped, never passed.

The pooled PostgreSQL readiness probe used 1,049 items, a 32-node chain and 24 queued candidates. Candidate EXPLAIN ANALYZE measured 24.012 ms execution and 1.915 ms planning. This bounded warm fixture is not a production-scale latency guarantee; no index change is justified by this measurement alone.

The same candidate source passed API typechecking without diagnostics in run e807f96901eb-2e43eb6d.

Existing leases

A lease does not permanently grant dependency readiness. Before a held worker starts, completes, renews a heartbeat, or uses another execution path through assertRunnable, the service rechecks the current shared readiness predicate. A new unaccepted delivery upstream can therefore fence an existing lease with work_dependency_not_ready. Rejection must not mutate item state, revision, heartbeat or expiry. Explicit cancellation/escalation paths remain available to stop work.

Maintenance uses a recovery-only intent: reclaiming an expired lease may proceed despite changed dependencies, but does not authorize execution. The item returns to the queue and the normal lease guard continues to hold it. Existing lane/authority holds retain their previous recovery behavior. This server fence cannot undo external effects already performed; the worker adapter's heartbeat-loss stop path and operator containment remain separate operational concerns.

Follow-on brief goodqa#12515 is linked to implementation goodqa#12485 under epic goodqa#5955. Frozen PR-head product code with regression tests (d4d49cec15b9e8ffe738454d76fe10d1472b4905, run 029eb2219e25-2ff7be2e) executed 80 pooled-DB cases: 77 passed and all three new running/completion/heartbeat controls failed with HTTP 200 instead of 409. The unrelated active-work controls succeeded before the failing assertion. Raw first-run evidence and frozen touched sources are in active-lease/029eb2219e25-2ff7be2e/ under the evidence directory above. Candidate validation and independent review are required before updating the draft PR.

The readiness SELECT does not lock each ancestor row. Normal coordinator mutations serialize on the coordinator row's transaction-wide update lock; dependency edges are scoped to that coordinator. Parent mutations lock the child coordinator as well. This protects the inspected application transaction paths, not direct database writers that bypass the lock protocol. The recovery intent is internal to maintenance's expired-lease selection and is not a request parameter. No instantaneous revocation of already-performed external effects is claimed.

Active-lease candidate 5b0972a03cd0fdc8e59abe0e2f92c518222170e9 passed all 242 pooled cases across coordinator, attention and direct reviewer-consumer suites (a44f393ebf00-5d91cf3c). This includes the recovered-but-still-blocked lease and legal cancellation controls.

The same active-lease source passed API typecheck with no diagnostics (086128db5c17-f4ccb68b).

MCP production claims (R79)

Canonical issue updates apply the same independent acceptance requirement to explicit agent on_production and done requests, including resolved stage IDs and same-status repetition. Field-only edits that do not request a status/stage remain legal. on_production is a nonterminal status; this repair does not describe the original path as a terminal-done bypass. Human transitions and unrelated agent work retain existing behavior. No acceptance issuer is introduced.

close_issue_done attempts the canonical status update before writing its evidence note. A refused transition leaves no new note. These remain two independent requests: if the status succeeds and the note request returns an HTTP error, the tool returns issue_note_failed_after_status_update with statusUpdated: true, noteRecorded: 'unknown', and the original refusal. A failure response cannot prove the note was never committed, so callers must inspect comments before retrying. This is not atomicity or a rollback promise. The scope covers explicit status/stage requests, not arbitrary comments or background revalidation of existing human-set status.

Frozen base 664e968fee9229e3ca9e8bce567b89384ac598f2, test-only snapshot ad9cf8c525c6f3b392a3dae219117fadc47e587a, pooled run d94ff13d7d6d-902ee9d2: 81 passed and 3 expected failures. MCP/default and direct REST wrote an unverified production claim; MCP/explicit done was refused but left the note. Unrelated MCP and human controls passed. Full raw evidence is retained under /home/eric/release-evidence/delivery-observation-20261028/mcp-status/.

Candidate snapshot 3e3bf873e2aecf3acc610a10d672a8368a0f7079 passed all 84 coordinator controls, including repaired MCP/REST refusals, stage parity, legal human/unrelated actions and explicit note-error partial outcome. API typecheck 137d85ea54ac-aed6a033 passed. Expanded owning run 7c68ca701710-1d222215 was 291/299: one MCP census failure and seven persona fixture setup failures remain. Unchanged base 664e968 reproduced the exact same eight failures in run c6ebaef1e5fa-bcff44de (165/173). They are retained, not waived; this is not a full-green release qualification.

R81 review correction: frozen test-only snapshot b39bf2499d4538b207ba864873b8238b22c765c9 on reviewed ef77478 reproduced same-status claims in pooled run a3a6c644f24a-44f84de5 (84 passed, 2 intended failures). Repeated status/stage and MCP requests succeeded, persisted a note and advanced revisions despite unaccepted delivery. The guard now precedes the changed-status mutation block but remains within explicit status/stage handling. Human manual requests and unrelated agent title edits remain legal.

R81 corrected candidate 5669ae00c118a80144268c9ec8cc8782c96cb70e passed all 86 coordinator cases in 99c1ecf5bc0b-21f0a9b6. Expanded result: 293/301, with the same eight retained census/persona failures as unchanged-base run c6ebaef1e5fa-bcff44de. The failing test files are byte-identical to that base. Same-status refusals preserve revision, status, stage, closure timestamp and notes; human repeated claims and unrelated agent edits remain legal.

API typecheck ad30034cab00-5d76a127 passed without diagnostics on that same corrected snapshot. Final API source/test diff against the tested snapshot is zero; later documentation only records results. Independent review is required before push. No deployment or acceptance authority is established.