Worker-bundle impact declaration unusable on changes with a missing workflow (exposure fixed; recovery path still absent)

[JRedeker]

Problem

Archive release readiness can require worker_bundle_impact, but the deployed ADV registry does not expose the typed declaration tool.

Evidence

• PokeEdge pinBuildkitImage archive finalization reports WORKER_BUNDLE_PROVENANCE_DECLARATION_REQUIRED and remediates: declare worker_bundle_impact with kind required or not_applicable plus rationale.
• Advance source includes tests/documentation for adv_change_set_worker_bundle_impact and adv_worker_bundle_provenance_record.
• Live adv_tool_describe({name:"adv_change_set_worker_bundle_impact"}) returns TOOL_NOT_FOUND after current trunk deployment and OpenCode restart.

Required behavior

• Register and expose typed worker-bundle impact declaration through the live ADV tool registry/catalog.
• Ensure generated manifests/tool ownership surfaces include it.
• Add integration test: a release-blocked change can declare not_applicable with rationale and proceed to normal readiness evaluation.
• Preserve typed signal-backed persistence; no direct state edit or archive bypass.

[JRedeker]

Update: tool is now exposed, but exposure alone is insufficient

Re-tested on PokeEdge change pilotAzureScheduleRestore after a plugin rebuild + fresh OpenCode session.

The original symptom is resolved. adv_tool_describe({name:"adv_change_set_worker_bundle_impact"}) now returns the full schema, and the tool appears in the registry.

A second defect is still blocking. Calling the now-exposed tool fails:

adv_change_set_worker_bundle_impact(
  changeId: "pilotAzureScheduleRestore",
  kind: "not_applicable",
  rationale: "<non-empty>")

→ { "error": "workflow execution already completed",
    "errorClass": "WorkflowNotFoundError" }

Verified afterwards: worker_bundle_impact is absent from the change. Nothing persisted.

Root cause

adv_change_set_worker_bundle_impact reads through the Temporal-backed store, which throws when the owning workflow is gone — so it never reaches its own disk write:

• plugin/src/tools/change.ts:2711 — await store.changes.get(changeId) (throws here)
• plugin/src/tools/change.ts:2726 — await store.changes.save(updated) (never reached)
• plugin/src/tools/change.ts:2737 — fireSignalAndRefresh(...) (never reached)

This is asymmetric with every other release-critical writer. adv_gate_complete reads the durable projection directly and has an explicit recovery path:

• plugin/src/tools/gate.ts:838 — loadChange(input.store.paths.changes, input.changeId)
• plugin/src/tools/gate.ts:685 — completeGateViaRecovery(...)

with the intent stated in-code at gate.ts:836:

// AC3: readiness/blocker evaluation must read the durable disk projection when available. Under recovery the disk projection is authoritative

The readiness side is fine — evaluateWorkerBundleProvenance (gate-readiness.ts:976) is pure over ChangeWorkflowState, and changeToWorkflowState carries the field (change-state.ts:230). So a disk-side declaration would clear the blocker. The writer simply can't get there.

Why this strands changes

Two defects compound:

1. Enforcement shipped ahead of remediation — the rq-workerBundleReleaseProvenance01 blocker in gate-readiness.ts predates tool registration in tool-registry.ts (70869914 descends from b25e85e2). Any change reaching the release gate in that window is blocked with no lever.
2. The declaration tool has no recovery path, so once the workflow is gone the blocker becomes permanent.

Observed end state: all gates done except release, which is stuck on WORKER_BUNDLE_PROVENANCE_DECLARATION_REQUIRED. The change is otherwise fully shipped — status: archived, archive bundle written, PRs merged, production verified. _recovery: { mode: "temporal_query_fallback", reason: "missing_workflow" }.

No deployed tool can resolve it: adv_change_workflow_terminate refuses (PROOF_MISSING_GATES, since release isn't done), adv_archive_purge would destroy a correct shipped bundle, and adv_doctor covers STSL/search-attribute/worker-restart only.

Suggested additions to Required behavior

• Give adv_change_set_worker_bundle_impact the same durable-projection recovery path as adv_gate_complete (loadChange + disk save), treating signal failure on a missing workflow as non-fatal once the projection write succeeds.
• Strengthen the proposed integration test: the current wording ("a release-blocked change can declare not_applicable and proceed") passes against a healthy workflow and would not have caught this. Add a case where the owning workflow is missing.
• Consider a general guard that release-gate enforcement cannot ship before its remediation tool is registered, since that ordering is what opens the stranding window.

Related: #303 (workflow unqueryable after session ends) is a milder form of the same missing-workflow class.