spec(t27f): spec_graph_view -- the first T27F graph view, a deterministic layout of a spec graph #10034

T27F is the visual spec of .t27 (epic gHashTag/trinity#1648, RFC gHashTag/trinity#1649; definition in .claude/skills/t27f/SKILL.md, "What T27F is"). Its core graph IR is specs/t27f/spec_graph.t27 (#10020, PR #10029). Nothing turns a spec graph into a picture yet: the only T27F view a host draws today is the topic-map reel (specs/t27f/reel.t27, an application). This issue adds the first core view, the graph view, as a spec: a deterministic layout that gives every node and edge of a SpecGraph its numbers, which a host then draws, the way reel.t27 gives a host the numbers of a reel frame.

Boundary

• specs/t27f/spec_graph_view.t27
• .claude/skills/t27f/SKILL.md
• specs/OWNERS.md

User Scenarios

• Given a valid spec graph, when a host asks for the layout, then every node gets x, y, width, height, fill, stroke and dash numbers and every edge gets two end points and a source line, with no randomness: the same graph always gives the same numbers.
• Given a graph with nodes of several kinds, when it is laid out, then each node kind present has its own column and every node sits in the column of its kind.
• Given nodes with different inference labels, when they are laid out, then size, colour, dash and row order come from the label (exact, derived, suggested, unknown), so a reader tells a fact from a guess without reading text.
• Given a node labelled UNKNOWN, when it is laid out, then it is drawn in a band of its own below every known node, overlapping nothing, and no edge line ends at it.
• Given a node, when a host needs its widget, then the widget is the one spec_graph.t27 binds to the node's kind and label in the ui_plan.t27 catalog.
• Given a graph that validate_graph refuses, or an edge with no source line to point at, when a host asks for the layout, then the view refuses it with a code instead of drawing it.

Requirements

• FR-001: The spec MUST place each node kind present in the graph in exactly one column, in a fixed kind order, with no empty columns.
• FR-002: The spec MUST derive each node's row order, width, height, fill colour, stroke colour and dash pattern from its inference label only.
• FR-003: The spec MUST draw every UNKNOWN node in a band below the deepest known node, separated by a fixed gap, and MUST NOT emit an edge with an UNKNOWN endpoint.
• FR-004: Every edge the spec emits MUST carry a source line inside the spec file: its own line, or for a DERIVED TESTED_BY edge the line of the CALLS edge it is derived from.
• FR-005: The spec MUST bind every node to a ui_plan.t27 widget through spec_graph.t27 node_widget, never by a rule of its own.
• FR-006: The spec MUST return a verdict: VIEW_OK, or the validate_graph code, or a view code for an edge with no source line; a refused graph MUST NOT be laid out.
• FR-007: The spec MUST be tested on the tutorial_08_graph fixture of spec_graph.t27, with at least 1 negative control in the spec and at least 2 mutation controls run on the lab.
• FR-008: The spec MUST expose scalar host entry points for the fixture, so a wasm host can draw it without passing arrays.
• FR-009: The change MUST be .t27 and prose only, ASCII-only (L3), and verified on the Railway lab, not on the Mac.

Success Criteria

• t27c test-report for specs/t27f/spec_graph_view.t27 on the lab: N/N tests passing, 0 FAIL, 0 BLOCKED, 0 vacuous (N reported in the PR).
• t27b test --check on the lab: N PASS lines, 0 FAIL lines.
• Fixture layout: 15 of 15 nodes placed, 16 of 16 edges with a source line, 0 node boxes overlapping, 0 edges touching the UNKNOWN node.
• Mutation controls on the lab: at least 2 of 2 mutations of the layout rules make at least 1 test fail on both t27c and t27b.
• The sha256 of the file on the lab equals the sha256 of the committed file (1 of 1 match).
• A written answer on the MCP t27f_view host glue for a spec view: added lines per file (limit 40) and per PR (limit 80), and whether any non-t27 edit needs the owner-approved-foreign label.