process-gap(orchestrator+determination): fix ruling summary names single property while geometry rationale requires coupled second property — literal implementation ships a shrunken element

## Summary

A defect-fix determination's one-line ruling named a single property change. The rationale section of the same ruling described the geometry of why the fix was needed — and that geometry required a coupled second property change to preserve the element's dimensions. An implementer reading only the ruling summary would apply the first property change but not the second, shipping an element that was correctly repositioned but had shrunk to the wrong size.

Caught at orchestration-brief time by cross-reading the summary against the rationale before dispatching the implementer.

## Pattern observed (private factory project; identifiers scrubbed)

Ruling summary (one line): "Set [layout-property-A] to [value-X]."

Rationale prose: "The element appears at the wrong vertical position because [layout-property-A] is [old-value]. To move it [N] units without changing its size, [layout-property-A] must be [value-X] AND [layout-property-B] must be [value-Y] — changing only [layout-property-A] while leaving [layout-property-B] unchanged shrinks the element from [old-size] to [new-size]."

The summary named one property. The rationale described a two-property coupled change. The rationale was correct; the summary was incomplete.

## Why this is a gap rather than a one-off

Fix rulings are often consumed by implementers who read the summary and act on it. The rationale prose is architectural justification — it answers "why" — but it also implicitly encodes the complete property delta. When the summary is incomplete, the implementer has three failure modes:

1. **Literal implementation** — apply only the named property, ship the shrunken element. The fix is partially correct (position) and partially incorrect (size). Tests that only assert the corrected axis pass; the second axis degrades silently.
2. **Re-derived interpretation** — read the rationale, derive the correct coupled change independently. Depends on the implementer doing work the ruling should have done; not repeatable.
3. **Escalation** — notice the divergence and ask for clarification before acting. Adds a round-trip.

The orchestrator caught mode 1 at brief-time by cross-reading, but the catch depended on the orchestrator reading both sections and recognizing the inconsistency — not on the ruling format enforcing completeness.

## Relationship to existing issues

- **#482** — adjudication rulings specifying *tests* must declare four explicit fields. This issue is the analog for *fix-specification rulings*: the four-field structure (#482) addresses test lifecycle consistency; the proposed machine-checkable property-delta structure (this issue) addresses implementation-surface completeness. Adjacent gap, different ruling type.
- **#446** — fix-phase commit ordering. Orthogonal: #446 is about when commits land; this is about what the ruling says before the implementer acts.
- **#419** — implementer spec-diff re-read mandate. Related: the re-read mandate mitigates cases where the implementer reads only the summary; a complete ruling reduces dependence on the implementer deriving unstated implications from rationale prose.

## Proposed remedy

### Machine-checkable property delta in fix rulings

When a fix ruling is issued for a layout/geometry/visual property defect (or any fix where multiple coupled properties must change together), the ruling MUST enumerate a complete property delta:

**Ordering invariant:** the property delta section must be self-sufficient — implementing every row in the delta and nothing else produces a correct fix. The rationale section may explain why, but the delta section must be a complete specification.

### Orchestrator pre-dispatch check

Before dispatching an implementer on a fix ruling, the orchestrator verifies that:

1. The ruling names every property that the rationale describes changing.
2. For geometry/layout fixes: the set of named properties is closed under the described dimensional constraints (changing A while leaving B at its old value does not violate a preserved invariant stated in the rationale).

This check is cheap (cross-reading two sections of the ruling) and catches the gap before any code is written.

### Adversary lens extension

Add a "fix ruling completeness" check to adversarial reviews of determination outputs: for any ruling whose rationale describes coupled property changes, verify the ruling summary or delta section is complete.

## Evidence availability

Private project; framework-pattern detail only. No identifiers. One direct instance; likely generalizes to any fix ruling where implementation requires coupled changes that the rationale describes but the summary omits.

## Cross-refs

- #482 — four-field ruling format for test-specifying adjudications (parallel gap)
- #446 — fix-phase order-of-operations
- #419 — implementer spec-diff re-read mandate