# Experiment 57J.43 — Remove Surviving Semantic-Only/No-Op Prompt Conflict

**Branch:** `feature/semantic-to-mutation-contract-v0.18`
**Starting HEAD:** `0c477adea99c8b6532cd0482fd7f1a41b6afbaee` (frozen v0.17)
**Production commit:** `359ccc4` prompt: remove semantic-only mutation conflict

## Objective

Apply the smallest proven correction from 57J.42's diagnosis: replace the two conflicting Additional Guidance bullets so that no surviving instruction tells the model it may preserve semantic meaning with an empty graph mutation when rule #6's structural-mutation MUST rule applies.

Not solving update-vs-add action selection (confirmed unresolved by 57J.42).

## What Was Changed

### Prompt (lib/graph/prompt-builder.js, Additional Guidance)

**Replaced two bullets:**

```
- If the answer does not justify a change, return empty arrays for every category.
- Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved.
```

**With three conditional bullets:**

```
- If rule #6 does not apply (the answer contains no user-supported meaning that requires graph progress) and there is no other justification for change, return empty arrays for every category.
- If rule #6 applies but you choose an update/refinement of existing structure, resolve an existing unknown, or add justified new structure, your structural proposal plus answerMeaning together represent the complete response — answerMeaning preserves semantic fidelity while structural mutation handles graph progress; neither replaces the other.
- If you add a new unknown with addedNodes, connect it with at least one addedEdge to an existing updated/resolved node or to a newly added non-unknown node from the answer.
```

### Tests (tests/graph/prompt-builder.test.js)

Added 7 focused tests:

| # | Test | Coverage |
|---|------|----------|
| 1 | no direct contradiction remains | Both MUST and empty-array permission must coexist with rule #6 as a condition on the permission |
| 2 | legitimate true no-op preserved | Empty arrays still allowed when rule #6 does not apply |
| 3 | answerMeaning is not structural progress | Must reference "semantic fidelity" not "graph change remains unresolved" |
| 4 | duplicate protection preserved | Rule #4, #11 + AG preference for updates intact |
| 5 | update/refine route preserved | update/refinement still listed as valid option in both rule #6 and Additional Guidance |
| 6 | possibleInference separation preserved | Rule #27 untouched; Additional Guidance does not reference possibleInference for mutation trigger |
| 7 | no action-selection machinery added | No keyword routing, node-kind decision table, or provider-specific paths introduced |

## Test Results

- prompt-builder.test.js: **22/22 pass** (7 new + 15 pre-existing)
- utils.test.js: **68/68 pass** (pre-existing regression)
- apply-proposal.test.js: **64/64 pass** (pre-existing regression)
- Total: **154 tests, 0 failures**

## What This Guarantees

1. The empty-array permission in Additional Guidance is now explicitly conditioned on rule #6 not applying — eliminating the MUST vs PERMIT contradiction diagnosed in Pattern E of 57J.42.
2. `answerMeaning` can no longer be interpreted as substituting for graph mutation, because the corrected bullet explicitly separates semantic fidelity from structural mutation.
3. All existing contracts are preserved: duplicate avoidance, genuinely-new-concepts protection, fidelity/inference separation, traceability, update/refine preference.

## What Is Intentionally Left Unresolved

1. **Action selection under rule #6** — when rule #6 applies and multiple structural paths exist (update vs add), the prompt still does not provide decision criteria. This was confirmed by 57J.42 as a separate ambiguity from Pattern E.
2. **Live production validation** — this commit only corrects the prompt text and tests; whether the corrected prompt produces compliant proposals in practice requires a live regression pass (next experiment).

## Stop Conditions Met

- No validators changed
- No schema changed
- No semantic classifiers added
- No provider-specific logic added
- No action-selection machinery added

## Documentation Updated: YES