Feature/product platform foundation v0.62 #1

Merged
robbond merged 683 commits from feature/product-platform-foundation-v0.62 into feature/emergent-unknowns-v0.5 2026-09-09 07:58:20 +01:00
2 changed files with 133 additions and 0 deletions
Showing only changes of commit 8184e050c8 - Show all commits
+12
View File
@@ -1429,3 +1429,15 @@ New branch: `feature/semantic-action-contract-v0.23`
**Update 2:** NOT REACHED (Update 1 blocked).
**What remains unproven:** Whether Update 2 would produce `structuralActionRequired = false` if an anchor existed. The experiment's fixed scenario creates a self-defeating constraint: Answer 2 intentionally repeats the same meaning, so even if Update 1 succeeded with structuralActionRequired=true, the model is structurally unable to declare false for identical input in a single harness invocation without a separate starting anchor. Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434. No production code changed.
---
### Experiment 57J.74 — Pre-Anchored Update-Only Fixtures and Harness
**Objective:** Confirm whether a deterministic pre-existing graph fixture + update-only harness mode exists that allows direct testing of the `false + no meaningful mutation → accepted` branch without requiring Update 1 to establish an anchor. **Classification: A — HARNESS-ONLY FIX VALIDATED.**
**Answer:** YES. Added a deterministic situationGraph fixture (`tests/fixtures/pre-anchored-update-savings-realism.json`) containing exactly one unresolved savings-realism unknown node (`n_savings_realism`, kind=unknown, status=unknown) with a valid depends_on edge into the graph state. Added `PRE_ANCHORED_FIXTURE` inlined constant + `runPreAnchoredSimulation()` harness helper that bypasses Start and sends the fixture directly as the Update request's situationGraph input. Added 10 deterministic harness tests covering: fixture anchor count, schema validity, relationship integrity, exact graph injection, zero Start calls, exactly one Update call, preservation of normal start→update mode, preservation of 57J.62 capture hardening (accepted/rejected), preservation of 57J.72 structuralActionRequired capture (true/false/null via accepted response and rejected snapshot), and zero retries/additional calls. All 39 harness tests pass. Zero Ollama calls. Zero production code changes.
**What this fixes:** The self-defeating constraint from 57J.73 where Answer 2 was unreachable because Update 1 failed at proposal_compatibility when declaring `structuralActionRequired=true` with zero mutation. Now the harness can inject a pre-anchored graph as the Update input, enabling direct testing of whether the live model produces `false + no meaningful mutation → accepted` on a graph that already contains the savings-realism anchor.
**What remains unproven:** Whether the live model will actually produce `false + no meaningful mutation` for Answer 2 when given this pre-anchored graph (a separate live experiment is required).
+121
View File
@@ -0,0 +1,121 @@
# Experiment 57J.74 — Pre-Anchored Update-Only Fixtures and Harness
**Branch:** `feature/semantic-action-contract-v0.23`
**Starting HEAD:** `beef434` (tooling: capture structural action declaration in live harness)
**Experiment commit:** pending (`docs: record pre-anchored update apparatus`)
## Objective
Answer exactly:
> Does a deterministic pre-existing graph fixture + update-only harness mode exist that allows direct testing of the `false + no meaningful mutation → accepted` branch without requiring Update 1 to establish an anchor?
This resolves the self-defeating constraint from **57J.73** (Classification G), where Answer 2 was unreachable because Update 1 failed to produce mutation and triggered contract rejection — making it impossible to test whether the model produces `false + no-op` on a graph that already contains the savings-realism anchor.
## Problem Statement
The v0.23 harness only supports `start → update(n)` chains. There is no mechanism to inject an arbitrary pre-anchored situationGraph directly into the Update API without first running Start. This means:
1. **Update 2 can never receive a graph where the savings-realism anchor already exists** from Answer 1's perspective, because Answer 1 fails at proposal_compatibility when it declares `structuralActionRequired=true` but produces zero mutation.
2. Even if Update 1 were to succeed (e.g., with Start producing a pre-populated anchor), there is no harness mechanism to **inject** that graph for the next update's input without actually sending an answer.
3. Testing the `false + no-op` branch requires starting from a known anchored state — but only `start → update` chains are supported.
## Hypothesis
If a deterministic pre-existing graph fixture (with a dedicated savings-realism unknown) can be injected directly into the Update request as an arbitrary situationGraph, and the harness can report `structuralActionRequired=false` + zero meaningful mutation when updating with Answer 2's input on that anchored graph, then:
```text
false + no meaningful mutation → accepted
```
can be tested without relying on Update 1's success.
## Tooling Changes
### Fixture: `tests/fixtures/pre-anchored-update-savings-realism.json`
A deterministic situationGraph representing the state after Answer 1 has been processed:
```json
{
"centralStatement": "We are considering relocating the engineering team to reduce operating costs.",
"nodes": [
{
"id": "n_relocation_state",
"kind": "state",
"status": "provisional",
"label": "Engineering team relocation consideration"
},
{
"id": "n_savings_realism",
"kind": "unknown",
"status": "unknown",
"label": "Are the projected office savings from relocation realistic?"
}
],
"edges": [
{ "fromNodeId": "n_savings_realism", "toNodeId": "n_relocation_state", "relationship": "depends_on" }
],
"activeUnknownNodeId": "n_savings_realism",
"resolvedNodeIds": []
}
```
Contains exactly one unresolved savings-realism anchor (`kind=unknown, status=unknown`).
### Harness: `runPreAnchoredSimulation()` in test file
A new synchronous simulator that mirrors what the harness does when supplied an arbitrary pre-anchored graph:
- **No Start call** — graph is supplied directly via `initialGraph` or defaults to the fixture
- Verifies fixture integrity before proceeding (exactly one savings-realism unknown)
- Sends the exact fixture graph into the Update request body
- Reports: node count, edge count, `structuralActionRequired`, answerMeaning fields, proposal mutations, selectedQuestion
- Call accounting reflects 0 start + 1 update
### Inlined fixture constant: `PRE_ANCHORED_FIXTURE`
The JSON fixture is also inlined as a JS constant in the test file so all tests can access it without filesystem reads.
## Harness Tests Added (10)
| # | Test | Asserts |
|---|------|---------|
| 1 | `pre-anchored fixture contains exactly one savings-realism anchor` | `savingsNodes.length === 1`, `id === "n_savings_realism"` |
| 2 | `fixture uses valid existing graph shape` | All node/edge fields present with valid enum values |
| 3 | `fixture contains a valid relationship into the graph` | Edge exists, from/to nodes exist, `relationship === "depends_on"` |
| 4 | `pre-anchored update-only mode sends exact fixture graph into real update request shape` | node count = 2, edge count = 1, ids match fixture |
| 5 | `pre-anchored update-only mode does not call Start` | `startCalls === 0`, `updateCalls === 1` |
| 6 | `pre-anchored update-only mode makes exactly one Update call` | `type === "all_success"`, exitCode = 0 |
| 7 | `normal Start→Update harness mode remains unchanged` | `startCalls === 1`, `updateCalls === 1` via existing patterns |
| 8 | `57J.62 accepted/rejected capture hardening remains unchanged` | addedNodes/updatedNodes/resolvedUnknownNodeIds captured on acceptance; rejection snapshot intact |
| 9 | `57J.72 structuralActionRequired direct capture remains unchanged` | true/false/null reports work correctly via existing patterns |
| 10 | `no retries/additional calls introduced in pre-anchored mode` | `totalCalls === 1`, zero retry entries |
## Results
**All 39 tests pass.** The pre-anchored fixture is valid, the update-only apparatus makes exactly one Update call with no Start, the exact fixture graph is sent, and all existing harness behaviour (57J.62 capture hardening, 57J.72 structuralActionRequired capture, normal start→update mode) remains unchanged.
## Classification: A — HARNESS-ONLY FIX VALIDATED
The pre-anchored update-only apparatus successfully decouples Update testing from the Start pipeline for anchor establishment. The fixture is deterministic and valid per the existing graph schema. The harness helper reports all necessary fields with zero Ollama calls, zero production code changes, and zero API calls beyond the single Update request.
## What this enables (but does not prove)
This **enables** testing `false + no meaningful mutation → accepted` by injecting a pre-anchored graph as the Update input. It does **not** itself prove that the live model will produce that outcome — only that the harness can now reach that test scenario without requiring Update 1's success. The next step is a live update-only experiment: inject the fixture, send Answer 2, observe whether the model produces `structuralActionRequired = false` with zero mutation.
## What remains unproven
1. Whether the live model, given this pre-anchored graph and Answer 2 input, declares `false + no meaningful mutation`
2. Whether the live update accepts that as an intentional no-op (vs. rejecting it)
3. Whether a different pre-anchored graph with additional anchors would produce different results
## Production code changed: NO
## Harness restored: YES
Scenario, answers, and maxUpdates in `scripts/reproduce-multi-turn-investigation.mjs` are at canonical defaults.
## Ollama calls beyond harness count: 0
## Dev server disturbed: NO