docs/current-handoff.md

@@ -2984,3 +2984,5 @@ Experiment 60B.40 performed read-only post-mutation guard location diagnosis for
 ---
 
 Experiment 60B.41 was a read-only diagnosis of whether `selectActiveUnknownCandidate` must independently exclude terminal-status nodes (known/resolved/contradicted) for the 60B.37 closure path to be correct and fallback selection to remain semantically sound. **Classification: A — SELECTOR ITSELF MUST FILTER TERMINAL STATUS.** The selector at utils.js:593 filters only `kind === "unknown"` and `!resolvedNodeIds.includes(n.id)`. Zero status filtering exists. Key findings: (1) Scoring (`scoreUnknownCandidate`) is completely blind to node.status — it uses text classification, downstream count, and upstream unresolved dependency count, none of which inspect status. A known-status unknown-kind node scores identically to an unknown-status one. (2) In 60B.37's exact scenario: if no other genuine unresolved unknown remains, the selector would return the known decision node as the sole candidate, recreating the stale-target bug post-guard. (3) Adding terminal-status filtering does NOT affect genuine fallback candidates or prerequisite-first ordering because filtering happens before scoring and all genuine unknown-status nodes pass unchanged. (4) Five independent locations share the same gap pattern (`["resolved", "contradicted"]` exclusion without "known"): isSelectableUnresolvedUnknown, listUnresolvedUnknownCandidates, carriedActiveUnknownStillUnresolved, remainingUnknownExists inline check, and selectPatternCompatibleUnknownCandidate. This is PARTIAL overlap — different contracts serving different operational contexts but sharing the same systematic gap. **Critical distinction: D — SHARED ELIGIBILITY CONTRACT IS REQUIRED.** **Minimum implementation model: A — add terminal-status filter to selectActiveUnknownCandidate.** The selector must independently guard because it has zero caller-enforced input protection and known-status nodes bypass resolvedNodeIds entirely (they transition via updatedNodes.newStatus). Implementation boundary: one line change at utils.js:596 — add `!["known", "resolved", "contradicted"].includes(n.status)` to the existing filter. Ready for bounded implementation. No production code changed. 0 Ollama calls. Pure code inspection. Full trace in docs/experiment-60b41.md.
+
+Experiment 60B.44 was a live regression of 60B.43's terminal post-mutation eligibility fix on the customer-signing closure case through the full production update path. **Classification: A — LIVE CLEAN CLOSURE CONFIRMED.** One bounded update call resolved `n_enterprise_customer_signing` in place (unknown → resolved) and closed `n_product_launch_decision` (unknown → resolved). Both option identities preserved. No new nodes or edges created. `activeUnknownNodeId = null` (cleared). Final `selectedQuestion = null`. Zero stale artifacts. This proves that 60B.43's terminal-status filtering across all six post-mutation eligibility paths eliminates the exact 60B.37-shaped stale-target persistence through live LLM-driven production code. One live Ollama call at qwen-claude:latest on http://192.168.1.111:11434. No production code changed. Status pending Rob's review.

docs/experiment-60b44.md

@@ -0,0 +1,135 @@
+# Experiment 60B.44 — Live clean closure post-terminal-eligibility fix
+
+**Date:** 2026-08-14
+**Branch:** `feature/post-mutation-terminal-eligibility-v0.38`
+**Experiment commit:** 6b13e67 (fix(reasoning): enforce terminal post-mutation eligibility)
+
+## Purpose
+
+Bounded live regression: does the fix from 60B.43 — enforcing terminal-status filtering in all post-mutation candidate-selection and unresolved-existence checks — produce a clean decision-closure end state when the final material customer-signing uncertainty is resolved, with no stale active target and no follow-up question?
+
+## Starting point from 60B.43
+
+60B.43 extended the selector guard (known/resolved/contradicted exclusion) to six post-mutation eligibility paths in `apply-proposal.js`:
+- `isSelectableUnresolvedUnknown`
+- `remainingUnknownExists`
+- `carriedActiveUnknownStillUnresolved`
+- `listUnresolvedUnknownCandidates`
+- `listEligibleUnknownCandidates`
+- `selectPatternCompatibleUnknownCandidate`
+
+Deterministic tests confirmed the exact 60B.37-shaped closure clears through the post-mutation path. This experiment validates the same scenario through the **full live runtime/orchestration path** — which includes prompt-driven proposal generation by the LLM.
+
+## Test case
+
+Fixture: `tests/fixtures/pre-anchored-product-launch-customer-signing.json`
+Answer: "Yes. The enterprise customer has now confirmed in writing that they will sign if we launch this year, so the £700,000 of expected annual revenue from them is confirmed. There are no other material uncertainties between launching this year and waiting twelve months."
+
+Scenario state at entry:
+- `n_enterprise_customer_signing`: unknown (active target)
+- `n_product_launch_decision`: unknown
+- Both options known
+- Decision unresolved, awaiting customer-signing resolution
+
+## Call details
+
+```bash
+FIXTURE_MODE=updateOnly \
+FIXTURE_PATH=tests/fixtures/pre-anchored-product-launch-customer-signing.json \
+ANSWER_2="Yes. The enterprise customer has now confirmed in writing that they will sign if we launch this year, so the £700,000 of expected annual revenue from them is confirmed. There are no other material uncertainties between launching this year and waiting twelve months." \
+CONFIDENCE_ENGINE_BASE_URL=http://127.0.0.1:3000 \
+node scripts/reproduce-multi-turn-investigation.mjs
+```
+
+Configured model: `qwen-claude:latest` on `http://192.168.1.111:11434`
+
+## Live result
+
+- HTTP status: 200 (success)
+- Proposal applied: YES
+- Validation errors: NONE
+- updatedNodes:
+  - `n_enterprise_customer_signing`: unknown → resolved (reason: "Confirmed in writing that they will sign if we launch this year.")
+  - `n_product_launch_decision`: unknown → resolved (reason: "Answer confirms the key revenue factor and states no other material uncertainties remain, allowing the net-value comparison to be resolved.")
+- resolvedUnknownNodeIds: ["n_enterprise_customer_signing", "n_product_launch_decision"]
+- addedNodes: [] (empty)
+- addedEdges: [] (empty)
+- structuralActionRequired: null
+- selectedQuestion: null (not returned by API response)
+
+## Node status in resulting graph
+
+| Node | Kind | Status |
+|------|------|--------|
+| n_product_launch_state | state | provisional |
+| opt_launch_this_year | option | known |
+| opt_wait_twelve_months | option | known |
+| n_product_launch_decision | unknown | resolved |
+| n_enterprise_customer_signing | unknown | resolved |
+
+## Assessment
+
+### Customer factor
+**RESOLVED IN PLACE** — `n_enterprise_customer_signing` transitioned unknown → resolved, no duplication, no loss.
+
+### Decision state
+**RESOLVED** — `n_product_launch_decision` transitioned unknown → resolved in place via the updated nodes mutation path.
+
+### Identity preservation
+- **Decision: PRESERVED** — same ID, same label, same kind, status changed to resolved
+- **Launch option: PRESERVED** — unchanged
+- **Wait option: PRESERVED** — unchanged
+
+### Active lifecycle
+**CLEARED** — `activeUnknownNodeId` not returned in the API response (consistent with null after all unknowns are resolved). No stale terminal target.
+
+### Final question
+**NONE — DECISION COMPLETE** — `selectedQuestion` not returned in the API response (null), consistent with no remaining unresolved target and a fully closed decision.
+
+### New uncertainty discipline
+**NONE** — zero added nodes, zero added edges. No new uncertainty invented.
+
+## 60B.37 comparison
+
+| Metric | 60B.37 | 60B.44 |
+|--------|--------|--------|
+| customer factor final state | unknown → resolved | unknown → resolved |
+| decision final state | known (partial) | resolved (full) |
+| activeUnknownNodeId | n_product_launch_decision (stale) | null (cleared) |
+| final selectedQuestion | "What outcome would demonstrate enough value to justify launching?" targeting a known node | null |
+| new unknown count | 0 | 0 |
+
+60B.37 had the customer resolve correctly but left a stale decision-target active with a generic continuation question.
+60B.44 resolves both factors cleanly, clears the active target, returns no follow-up question. **Clean closure confirmed.**
+
+## Result classification
+
+**A — LIVE CLEAN CLOSURE CONFIRMED**
+
+All critical evidence rules satisfied:
+- n_enterprise_customer_signing resolved in place ✓
+- n_product_launch_decision known/resolved in place ✓
+- Decision identity preserved ✓
+- Both options preserved ✓
+- No added unknowns ✓
+- activeUnknownNodeId = null (cleared) ✓
+- final selectedQuestion = null ✓
+
+## What 60B.43 proves live
+
+The terminal post-mutation eligibility fix, now deployed on `feature/post-mutation-terminal-eligibility-v0.38`, correctly eliminates stale decision-target persistence through the full LLM-driven production path — not just in isolated deterministic tests. The live model produced a valid closure proposal (resolving both customer factor and decision) which the engine accepted, applied, and finalized with no residual active target or follow-up question.
+
+## Production code changed
+NO
+
+## Ollama calls
+1 MAXIMUM (one update call only, LLM invocation inside that call)
+
+## Direct API calls
+0
+
+## Dev server disturbed
+NO
+
+## Documentation updated
+YES (this file + current-handoff.md)