SPATIAL-2b: carried coordinate-frame identity and operational frame refusal

[gunbai-bot]

What this corrects

#8091 merged claiming that a phantom frame parameter made cross-frame subtraction fail to typecheck — "the stronger of the two options, available here rather than merely preferable."

Measured on the production compile-and-run path (no test harness involved) 2026-08-11:

fn frame_violation() -> Int {          // RoomFrame location minus BuildingFrame location
  match displacement_between3(from: room_point(),      // Point3<RoomFrame>
                              to:   building_point())  // Point3<BuildingFrame>

Compiles clean. Returns 9. A plausible number for a question with no answer — the fabricated output DESIGN §5 forbids.

Why the phantom could never have worked

Not a modelling slip. v1.compiler.infer's argument-position judge compares nominal head names; applied type arguments live in Node.children and every name-level comparison discards them. Point3 matched Point3, so the frames were never looked at. A probe matrix isolated the axis — a primitive mismatch fires TypeMismatch:Primitive(String), while wrong type argument, wrong nominal record type, and a record returned as Int all produce zero diagnostics.

A separate compiler PR closes the call boundary. It cannot close the producer side: return-position conformance is a different relation that declines to judge record types at all, blocked on feature:conformance-produced-type-identity. So this stays writable regardless:

fn falsely_reframe(p: Point3<RoomFrame>) -> Point3<BuildingFrame> { p }

A consumer sees only the declared type. It cannot reconstruct an identity the producer erased. Therefore the carried identity is the authority.

The change

• std.coordinate_frame mints CoordinateFrameIdentity — declaration-owned, never derived from a name or from contents (the HostResourceIdentity precedent; a content-derived key makes two coincidentally-identical frames one frame). Recorded as the corpus's third minted-occurrence carrier, which is evidence the subject-parameterized extraction is due — left as a trigger, not built here.
• Phantom <F> removed, not demoted. Two authorities for one fact is the §3 violation whichever is right, and the weaker one is the one the compiler cannot enforce end to end.
• SpatialResult has three arms — ready, arithmetic refusal, frame refusal. One coproduct rather than nested result types: there is one question at the operation boundary and the causes are what differ.
• The refusal names roles, not expected/observed. In add_vector3(a, b) neither frame is normatively expected — the first operand merely establishes the result's frame, so "expected" would report argument order as a requirement. It carries an operation identity and the relation required.
• The frame check precedes the arithmetic everywhere, because operands in different frames pose no question to overflow.

Guarantee rung, stated honestly

Frame consistency by checked derivation — not by construction. It is not true that cross-frame programs are unwritable. std.coordinate_frame carries the full account and the dissolve-on: when feature:conformance-produced-type-identity closes, a static projection can be reintroduced above this carrier, and the carried check remains as the serialization / external-input boundary a static guarantee cannot reach.

Evidence (green by execution)

Cross-frame subtraction, addition, subtraction, translation and transform application each refuse and name both frames · same-frame operations still answer (the positive sibling a refusal-only control cannot see) · frame and overflow asserted distinct in both directions · a transform's translation must be in its destination frame.

The decisive one is the lying-producer control: a function handing back a room-frame value under a building-frame annotation cannot rewrite the carried frame, and the next operation refuses.

Mutation-tested — disabling a single frame guard turns the suite red.

Sequencing

Independent of the compiler PR; repairs the current-main operational guarantee on its own. Whichever merges second should merge main and regenerate rather than hand-resolve generated artifacts. SPATIAL-3A resumes after both are in CI.