fix(code-index): answer master-red reads from their true authority

[ScriptedAlchemy]

Fixes #2313, Fixes #2333, Fixes #2336, Fixes #2344

Master-red bundle, plus the #2339 follow-up. For each test, this states the cause and whether production or the pin was wrong. Fail-before evidence is from origin/master (d0d4d3a at the start of the work), or from this branch with the production change reverted and the new test kept.

Per test

#2313 search_quality_suite candidate_producers::reader_refuses_historical_v10_writer_artifact_as_incompatible: production wrong

Since d054014, open_content_addressed goes through the full-verify path. That path decoded the embedded receipt before checking format_revision, so a revision-10 artifact failed serde as Corrupt("unknown field generation …") instead of Incompatible. The pre-refactor open checked the revision first; the full-verify open now does too (verify_artifact_state_revision before the receipt decode). The lib test named in #2313 was already green on master.

• master: 70 passed; 1 failed, unexpected error: Corrupt("unknown field generation …")
• branch: 71 passed; 0 failed

#2333 / #2344 (1) tracedecay --lib daemon::tests::runtime_identity::concurrent_same_identity_worktrees_keep_exact_server_and_scheduler_bindings: stale pin

21552e3 (#2319, #2340) intentionally answers graph-owner refusals as isError tool results, and #2319 re-pinned the mcp_suite callers; this daemon lib test was missed. The route still refuses the listing. The pin now asserts isError: true plus the literal problem: kind unavailable, code code-graph-unavailable, message the exact project code graph is unavailable: the verified code graph is not ready for the exact project root. The two "readiness" lib tests another lane reported did not fail in any full lib run here. On master the only lib failures were this test and a rebind race in daemon_http_shutdown_releases_loopback_listener, filed as #2342.

• master: 768 passed; 2 failed; branch: 770 passed; 0 failed

#2336 core_cli_suite tool_diagnostics_reads_the_typescript_producer_publication / …_a_monorepo_package_finding: production wrong (two causes)

A temporary probe (removed) showed that every failing read returned from diagnostic_identity.resolve() == None while a complete publication for generation G existed.

1. Since perf(diagnostics): check only changed TypeScript projects at the seal #2325 the TypeScript producer publishes at the seal. The read resolved publication identity through lexical serving, which is not ready yet in that window, even though the retained text owner, the seal pointer and the LSP identity all named G. resolve_current_publication_identity now reads the retained owner. It uses only the manifest and snapshot, the same "identity, not serving" rule the LSP identity port already follows. The perf(diagnostics): check only changed TypeScript projects at the seal #2325 reconcile test that pinned resolve == None while projection is held now pins "nothing serves" through the serving accessor, and asserts that the read identity names the sealed generation.
2. Under load the retained owner still named G, but fresh=false: the source proof had moved (for example, Git metadata) and was being renewed. The fence documents this state as "reads report the retained owner stale". The diagnostics read now checks the retained code-index identity first (a call it already made), so an unresolved publication identity reads as application.diagnostics.stale, not unavailable.

• master: the pair fails in about 1 of 4 runs (application.diagnostics.unavailable), and 1 of 120 with only fix 1 applied under 8-way contention
• branch: 0 failures in 120 runs under 8-way contention on the final binary (240 test executions)
• New mcp_suite diagnostics_read_test::moved_source_proof_reads_the_publication_as_stale_until_renewed publishes TS4023, moves .git/index's mtime, and requires every read to be stale until the same finding returns. master: [String("application.diagnostics.unavailable")]; branch: pass.
• Reconcile test with production reverted: the retained generation answers identity while its text projection is held panics; branch: pass.

#2344 (2) daemon_suite indexing_lifecycle_test::ignored_dependency_admission_survives_physical_daemon_restart_without_widening: production wrong, then shape

The refusal was not just the #2340 shape change: it said ignored-dependency admission found no exact-scope serving generation. Since #2332, a ready generation serves from its text owner and decodes only on demand. Ignored-dependency admission requires the decoded seat but never demanded it, so every retry would have refused. Admission now demands the complete generation when a graph-on mount has no decoded seat, and the caller's typed retry finds it seated. An earlier variant that waited inside admission hung a symlink-rejection test that never seats; it was dropped for this one. The test retries through that typed state, then pins isError with code application.symbol-graph.ignored-dependency-generation-advanced and message ignored dependency indexing advanced the graph generation; retry the request.

#2344 (3) daemon_suite indexing_lifecycle_test::status_wait_for_returns_reached_with_the_saved_edit_generation: production wrong (payload)

Re-checked after #2341: it passes alone on current master but fails under full-suite load, with wait: reached beside code_index_freshness.status: stale / staleness_state: verifying on the edit's generation. There is one freshness authority, CodeIndexSchedulerRegistryV1::dashboard_freshness_read, and it was read twice. The wait read it and reached; then status built the payload from a second read, after a late watcher event had moved the proof. CodeIndexReadinessWaitReadV1::Reached now carries the reading that satisfied the wait, and status renders code_index_freshness from that reading, as the dispatch comment already promised ("the payload describes the worktree the wait ended on").

• Failed in the full daemon_suite run before this change (left: "stale" right: "current"); daemon_suite is 64 passed after it.

#2339 follow-up: symbol-graph ended_at == started_at

complete_or_failed stamped finished_at: context.observed_at. It now ends at observed_at + wall_micros, from the same cost receipt that supplies elapsed_micros. An overflow is a typed failure. typed_callers_carry_their_read_cost asserts ended_at - started_at == cost.wall_micros. master: left: Some(0) right: Some(1750); branch: pass.

Suites (local, Linux)

• tracedecay-query: lib 267 passed, search_quality_suite 71 passed
• tracedecay lib 770 passed; tracedecay-application lib 478; tracedecay-code-index-runtime lib 529 in a full run and 528 passed; 1 failed in the next, where the failure (shutdown_timeout_retains_blocked_worker_owner_until_retry_joins_it, a 2 s admission wait under load) passes 5/5 alone; tracedecay-mcp lib 387; tracedecay-contracts lib 420
• daemon_suite 64 passed
• mcp_suite 585 passed; 1 failed. The failure is status_behavior_test::tracedecay_status_reports_the_sealed_branch_and_keeps_diagnostics_opt_in, which fails on current master with every crate at master (8 of 10 isolated runs, together with context_related_order_test), filed as test(mcp): status and context pins read a transient verifying state #2356.
• tracedecay-cli: bin 334, core_cli_suite 145 passed; 1 failed. The failure is branch_add_admits_background_publication_and_remove_retires_its_exact_artifacts: it pins a transient indexing label that is already synced. It first failed after refactor(mcp): serve admin project through its owners #2351 and refactor(mcp): serve admin cli through its owners #2354, and this diff doesn't touch branch admission; filed as test(cli): branch add pin expects an indexing state that already finished #2360. core_cli_suite was 146 passed before rebasing onto those.
• Focused re-run after the final rebase onto ea3b0cb: every test above that changed passes (1, 2+1, 9, 4, 6 passed).
• cargo clippy -p tracedecay-query -p tracedecay-application -p tracedecay-code-index-runtime -p tracedecay-contracts -p tracedecay-mcp -p tracedecay -p tracedecay-cli --all-targets -- -D warnings, with and without tracedecay-cli/test-transport,tracedecay/test-transport,tracedecay/test-helpers: clean
• cargo fmt --all -- --check: clean
• cargo check --workspace --all-targets --target x86_64-pc-windows-gnu --features tracedecay/test-transport,tracedecay/test-helpers,tracedecay-cli/test-transport: exit 0. Its warnings are pre-existing unix-only test code; none is on a changed line.

Runtime journey

core_cli_suite tool_surface_transport_test::tool_diagnostics_reads_* drives the shipped target/debug/tracedecay (tracedecay tool diagnostics --format json against a spawned daemon in an isolated HOME, a real TS project with its own node_modules/.bin/tsc). Run as 8 parallel loops × 15 runs on the final binary: A..H failed=0.

[changeset-bot]

⚠️ No Changeset found

Latest commit: be394cf

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-27T22:03:25.715980Z	be394cf	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.