P1: FastEmbed production journeys red on the #707 tip (artifact_digest refusal, linked-worktree publish timeout)

[ScriptedAlchemy]

Three tracedecay --lib --features test-helpers production journeys fail deterministically on the #707 tip (5c1623f) whenever TRACEDECAY_DISTRIBUTION_FASTEMBED_FIXTURE points at the byte-pinned JinaEmbeddingsV2BaseCode package. They skip (vacuously pass) without it, which is why CI and most lanes did not see them. They also fail identically on f52868364 and on every lane branch based there (ci-red-suite, freshness-1071, daemon-1040, compat-1072 — hauler cc-9918..cc-9921, 0 passed / 4 failed each), so the regression predates today's merges. The same journeys passed with the same fixture at 18203ff30 (#908 evidence).

Failing tests

1. daemon::production_harness::semantic_activation_journey_test::public_semantic_activation_rollback_and_exact_retry_preserve_graph_authority

2. daemon::production_harness::semantic_restart_journey_test::strict_semantic_answers_again_after_daemon_restart_without_rebuild

   Both: semantic activation input was rejected: semantic profile qualification failed: semantic snapshot preflight failed: semantic runtime rejected the verified evaluation target authority: semantic runtime rejected the transition at inspect_generation.artifact_digest — ProductionSemanticRuntimeV1::inspect_generation (crates/tracedecay-usecases/src/semantic_runtime/production.rs ~L2760) compares the installed lifecycle state's artifact_digest() with required.artifact_manifest_digest; they no longer agree. The fixture itself installs and verifies fine (model.verify_and_install 38 s in the stage ledger), so the disagreement is between how the evaluation target's pins are derived and how the lifecycle reports the installed artifact.

3. daemon::production_harness::generation_retention_test::linked_worktree_scope_retention_crash_replay_and_pure_inventory_journey

   mounted linked-worktree production composition: Config { message: "production-composition code index did not publish for '<iso>/linked-b' after 20001 ms; composition gate capacity=2, admitted=1, waiting=0; scheduler_state=None; …" } — the linked worktree's code index never publishes while the primary does. May share a root cause with the stale-pins problem (the linked scope's semantic owner refusing and holding the seat) or be an independent linked-route defect; determine which.

A fourth test (semantic_availability_journey_test::retrieval_answers_before_activation_and_is_unchanged_by_live_semantic_activation) failed only because its helper read one page of a truncated tracedecay_search answer; fixed in 5c1623f.

Leads (git log 18203ff30..f52868364 --no-merges on the semantic runtime): 40847ffe6 refactor(configuration): share one runtime pin between root and usecases, 8e965d384 fix(semantic): restore from sealed source metadata, 76586f52a fix(semantic): pass the acquisition target as one value, 930b252a7 fix(semantic): retire projection cache ownership safely, and the 2f17bc83b reconcile.

Repro

TRACEDECAY_DISTRIBUTION_FASTEMBED_FIXTURE=/fast/tmp/td-753-fastembed-fixture \
cargo test -p tracedecay --lib --features test-helpers -- --test-threads=2 \
  public_semantic_activation_rollback_and_exact_retry_preserve_graph_authority \
  strict_semantic_answers_again_after_daemon_restart_without_rebuild \
  linked_worktree_scope_retention_crash_replay_and_pure_inventory_journey

Fix the production defect at its owning boundary (do not re-pin the fixture or relax the digest check unless the pins are genuinely derived from the wrong authority, and say which). Do not raise the 20 s publish deadline.

[ScriptedAlchemy]

After 5c1623f (retrieve paging fixed in the helper) semantic_availability_journey_test::retrieval_answers_before_activation_and_is_unchanged_by_live_semantic_activation reaches the activation stage and then fails on the same refusal: the strict tracedecay_search after activation answers isError with reason: semantic_unavailable (hauler cc-9930). Treat it as the fourth test in this issue's set.

[ScriptedAlchemy]

Root cause for the linked-worktree case (linked_worktree_scope_retention_crash_replay_and_pure_inventory_journey, "linked-b never publishes"), found while closing the same symptom in #1103's git_watch_test::linked_worktree_requires_mount_then_serves_only_its_exact_generation. It is independent of the semantic pins.

What happens. Since f347a0a (fix(index): require opt-in for linked worktree scopes, Sep 1) a linked worktree route carries CodeIndexAutomaticAdmissionV1::LinkedWorktreeDisabled unless sync.watch_linked_worktrees = true on the project layer. The route serves but never indexes: activate() refuses, and tracedecay_search on that scope answers the typed linked_worktree_disabled state. The daemon log of the failing journey shows it directly: code_index_activation_skipped project=…/linked-b reason=linked_worktree_disabled, then code_index_complete_generation_unavailable reason=no_unique_mounted_scope on every poll. ProductionProjectCompositionHarnessV1::open then waits 20 s in wait_for_production_composition_code_index for a publication that by contract never comes and fails with mounted_generation=None. The deferred project-open owners already treat this admission as terminal (3b0d7c4, code_index_disabled_for_scope); the harness wait did not.

Fix on fable/daemon-suite-1103 (branch for #1103, worktree /fast/tmp/td-daemon-suite-1103):

• 25c90815a fix(daemon): open compositions over a disabled linked-worktree index — the harness wait returns for LinkedWorktreeDisabled instead of exhausting the bound, and exposes ProductionProjectCompositionHarnessV1::configuration_revision(project) (the revision CAS token) so a journey can write the opt-in through the production tool.
• 6127b3efb test(daemon-suite): opt the linked worktree into indexing before open — the test-transport daemon_suite: 772-file lifecycle batch writes ~2.4 GB of artifacts and misses the 45 s receipt; hooked saves reconcile only at the 30 s window #1103 journey writes sync.watch_linked_worktrees.v1 = true on the project layer via tracedecay_configuration_set (with expected_revision and an idempotency key) on the first composition, before the one that opens the worktree route; admission is decided from the durable revision at route open. With that the worktree indexes, publishes and serves its own generation; the test passes (hauler cc-10270).

For this issue's journey the same restatement applies: apply the project-layer opt-in on the primary before open(isolation, [primary, linked]). The reference for the production path is daemon/tests/runtime_identity.rs::opted_in_linked_worktree_indexes_reopens_and_shuts_down_beside_primary. Two adjacent contracts the journey should not fight: a commit inside the linked worktree moves the shared refs/heads, which is the primary route's tier-1 git signal, so the primary's code lanes are typed stale until its next (Noop) reconcile re-resolves identity; and coverage.recall is partial whenever the semantic lane is unavailable.

One inconsistency worth a look by whoever owns the linked-worktree policy, not fixed here: code_index_reconcile_sink mounts a LinkedWorktreeDisabled route on explicit demand (explicit_reconcile_overrides_linked_worktree_watch_policy), but code_index_search_executor still refuses that scope with linked_worktree_disabled, so tracedecay init inside a non-opted-in linked worktree indexes something search will never serve.

[ScriptedAlchemy]

Status after cb211ad / a2db02c (lane fable/fastembed-1097, 7 commits): two of four fixed, two remain with named causes.

Fixed — inspect_generation.artifact_digest (both semantic journeys): 2f17bc83b moved the daemon onto the scoped lifecycle owner, whose shared-inventory acquisition published the artifact store's manifest content digest (ModelArtifactManifestV1::artifact_identity_digest, which also hashes host-derived resource ceilings) as the lifecycle artifact_digest. The pins derive from the projection's model_artifact_digest = catalog_package_digest (enforced by SemanticCompatibilityPinsV1::valid) and were canonical; the lifecycle drifted. 18ca997e6 makes the lifecycle name the catalog package on every path and recovers the store address from the install directory for lease reconciliation, restart re-admission and rollback. Also fixed on the way: two routes' concurrent cold model loads double-counted process RSS growth and tripped the 2 GiB cold-load ceiling (905017414 serialises cold opens; admission wait is excluded from the deadline), the projection error was erased to a bare Projection in schedule failures (59b5e0743), and the activation journey injected failure through a pre-restart owner handle (897745466). On the tip with the fixture: public_semantic_activation_rollback_and_exact_retry_preserve_graph_authority ok, strict_semantic_answers_again_after_daemon_restart_without_rebuild ok (cc-10296).

Linked worktree — independent of the digest: since f347a0a46 a linked worktree is LinkedWorktreeDisabled unless sync.watch_linked_worktrees is set; the harness parked on a publication that admission forbids (a2c41d53c now answers the typed disabled state like the daemon's deferred owners) and the journey never opted in (6595c120c commits the opt-in through the public configuration authority). I found no run where this journey ever passed with the fixture — the vacuous fixture-less passes hid it. It now gets through mount, opt-in, install and both semantic generations and fails at the second set_semantic_profile with a per-scope profile-state revision CAS refusal that the primary's commit invalidates — a design decision, filed as #1107. The same route defect explains #1103's linked_worktree_requires_mount_then_serves_only_its_exact_generation (wt-feat-y never publishes): that journey also needs the opt-in, or its harness the typed disabled answer.

Still red — semantic_availability_journey_test::retrieval_answers_before_activation_and_is_unchanged_by_live_semantic_activation: fails in phase 1, before any activation, at search(strict = true): the tool answers isError: true carrying {status: unavailable, reason: semantic_unavailable, coverage: {exact/graph/lexical/semantic: calibration_unavailable}} where the journey (and the workspace rule that unavailable authorities are typed states, not transport errors) expects a typed status: "unavailable" payload with isError unset. Needs the MCP rendering/handler path for strict-semantic refusals checked — which side changed.