docs: record accepted answer-meaning capture

docs/current-handoff.md

@@ -1659,3 +1659,11 @@ This satisfies 57J.77's boundary A recommendation: a committed update-only path
 ### Experiment 57J.80 — Incremental Meaning on Existing Uncertainty (PRE-ANCHORED)
 
 **Objective:** When a savings-realism uncertainty already exists and the user supplies new concrete information relevant to it, does the model emit `structuralActionRequired=true`, preserve that new information structurally, and avoid creating a duplicate equivalent uncertainty? **Classification: I — BLOCKED.** The committed `FIXTURE_MODE=updateOnly` apparatus passed a null `previousQuestion` through to the production server, which rejected at `request_validation` stage with `"Expected string, received null"`. The rejection occurred before any model inference call. One update call was made (counted but not executed by the model). No graph mutation, no structural action output, no information preservation assessment possible. The pre-anchored fixture and harness from 57J.78 remain correct for their original intent; this experiment encountered a boundary condition where no prior Start means no selectedQuestion to carry forward. Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434. No production code changed.
+
+### Experiment 57J.82 — Incremental Supported Information on Anchored Uncertainty
+
+**Objective:** With the savings-realism uncertainty already present, does new supported information cause the model to emit `structuralActionRequired=true`, preserve that information structurally, and keep a single savings-realism uncertainty identity? **Classification: G — FIELD MISSING.** The model extracted partial information as a newValue (~£2M/year (lease elimination)) onto the existing node, preserved exactly one uncertainty identity, but did not populate `structuralActionRequired`. Full results in `docs/experiment-57j82.md`. Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434.
+
+### Experiment 57J.83 — Direct Answer-Meaning Capture from updatedProposal
+
+**Objective:** Verify the production path correctly reads `answerMeaning` and `structuralActionRequired` from inside `updatedProposal` (graphUpdate schema container) and that all test mock boundaries are coherent with this contract. **Classification: IMPLEMENTED.** Fixed mock boundary mismatch where some fixtures placed fields at root level while capture logic read from inside `updatedProposal`. All 49 harness tests pass. Full results in `docs/experiment-57j83.md`. No production code changed; only experiment apparatus (script + test harness).

docs/experiment-57j83.md

@@ -0,0 +1,54 @@
+# Experiment 57J.83 — Direct Answer-Meaning Capture from updatedProposal
+
+**Branch:** `feature/semantic-action-contract-v0.23`
+**Starting HEAD:** `d289173` (experiment: rerun incremental meaning on anchored uncertainty)
+
+## Objective
+
+Verify that the production path's accepted-response capture correctly reads `answerMeaning` and `structuralActionRequired` from inside `updatedProposal` (the graphUpdate schema container), not from root-level mock fields. Confirm the test harness mock boundaries are coherent with this contract.
+
+## Background
+
+The production harness (`scripts/reproduce-multi-turn-investigation.mjs`) was updated to capture accepted answer meaning directly from `updatedProposal`:
+
+```js
+const proposal = updateResult.json().updatedProposal ?? updateResult.json().proposal ?? null;
+const am = proposal?.answerMeaning ?? null;
+const sar = proposal?.structuralActionRequired;
+```
+
+However, some mock fixtures in the test harness still placed `answerMeaning` and `structuralActionRequired` at root level (mirroring an earlier production shape). This created a disconnect: the mock surface presented fields at root while the capture logic read from inside `updatedProposal`. The regression (57J.78) exposed this because it supplied mock fields at the root only.
+
+## Fix Applied
+
+### Production capture (scripts/reproduce-multi-turn-investigation.mjs)
+- Reads `answerMeaning` and `structuralActionRequired` from `updatedProposal.proposal` — not from root
+- Captures all five fields directly: `userSupportedMeaning`, `possibleInference`, `supportCategory`, `resolutionGuidance`, `structuralActionRequired`
+- Null vs. field-absence properly handled via optional chaining
+
+### Test harness (tests/reproduce-multi-turn-investigation.harness.test.js)
+All mock boundaries were normalized to match the production shape:
+
+1. **runPreAnchoredSimulation** default fixture: fields already inside `updatedProposal` — no change needed
+2. **runPreAnchoredSimulation** with custom `onResponseUpdate`: removed root-level `structuralActionRequired`/`answerMeaning`; added to `updatedProposal`
+3. **runSimulationWithResponseShape** response normalizer: updated to read from `updatedProposal` first, falling back to root for backwards compat
+4. **Standalone mocks** (5 locations): removed root-level duplicate annotations; ensured fields only inside `updatedProposal`
+
+## Validation
+
+```
+npx vitest run tests/reproduce-multi-turn-investigation.harness.test.js
+✓ 49 tests passed
+```
+
+All 49 tests pass. No production code was modified during validation — all changes were to test harness and script capture logic which are both in the "experiment tooling" category.
+
+## Production code changed: NO
+
+No production API server or inference pipeline was modified. The captured paths (script + test harness) are experiment apparatus only.
+
+## Harness restored: YES
+
+The harness reproduces the same one-shot semantics across all 49 tests, including the 57J.78 regression case. Mock response shape now matches the accepted production contract.
+
+---