Phase 6 — The IR (spine)

[accuser]

Opens phase 6 of design/bynk-compiler-trajectory.md, per the trajectory's own rule ("a phase's
track opens when the previous phase's probe reads zero") and design/tracks/semantics-in-the-checker.md's
own retirement note, which names this explicitly: "Opens phase 6 (the IR, per the trajectory)"
(design/archive/retired-tracks.md's closing summary).

Why now

Phase 5's probe (emit_diagnostics) reads its own named floor as of retirement (9 August 2026) —
4/6 (true/naive), true=4 the four #[cfg(test)] assertion strings that track's own §5 named as
the floor rather than open work (confirmed live, cargo xtask greenfield-status). All six named
phase-5 slices shipped, closing R3.5 in full.

Phase 6's own probe, ast_importers (bynk_syntax::ast imports in bynk-emit), reads 9 live
today — down from 13 files at §3.0's own 30 July baseline. Some of that drop is directly
attributable, not assumed: P5.5 (phase 5's own last slice) dropped it from 10 to 9 by relocating
emitter/secrets.rs's AST-walking half into bynk-check::secrets. The rest of the 13→9 gap needs
precise attribution in the settling review rather than asserted here — the same "ordinary churn
already paid down part of the distance" finding phases 4 and 5 both made once they actually looked.

The nine remaining files: project.rs, project/tests_emit.rs, emitter.rs, emitter/lower.rs,
emitter/serialisation.rs, emitter/workers.rs, emitter/workers_entry.rs, emitter/wrangler.rs,
emitter/runtime_use.rs. lower.rs is the load-bearing one — it is the file R6.2's already-landed
fix (T2.1, #1017) touched, and it is where the reference's Part 6 (bynk-greenfield-compiler.md
§6.2–§6.5) finds most of its evidence.

Appendix D's own R6.x rows already show more landed than the trajectory's phase-6 section
implies, none of it by a track for this phase — all of it ordinary paydown between v0.237.1 and
today, the same shape phase 4 and phase 5 both found for themselves: R6.2 (the statement-sink
signature) ✅ landed (T2.1, #1017); R6.3 (short-circuit) ✅ landed (pre-dating Appendix D, plus T2.3,
#1019); R6.5 (name-matched write detection)'s expr_children fix ✅ landed, though the underlying
name-match (not yet an IR walk) remains; R6.11 (the kernel table)'s joinOn/groupBy gap ✅ landed,
though the bidirectional drift test and the second copy remain. R4.9 (expr_types: HashMap<Span, Ty>, five silent fallbacks) is the one phase-3-adjacent rule that stayed open at that track's own
retirement ("functionally but not structurally") — directly relevant to R6.1 below.

What this issue is, and is not

This is the spine only — opening the phase per the trajectory's own convention. No track-doc
draft exists yet; the research above is this issue's own, meant as starting material for one, not a
substitute for a settling review under the usual draft PR ("Part of #"), the same
precedent identity-and-totality.md, project-model.md and semantics-in-the-checker.md all set.

Open design questions the settling phase needs to close:

1. Freeze scope. emitter/lower.rs and emitter.rs are large, central, and frequently touched
   by unrelated work. semantics-in-the-checker.md's own Q4 precedent was to freeze per-slice, not
   track-wide, once its own decomposition turned out to be six small slices rather than one large
   one — phase 6 is the opposite shape (trajectory §5: relative size 20, the largest phase), so the
   same per-slice discipline may not transfer cleanly and needs its own argument, not an assumed
   default.
2. Does phase 6 need R4.9 closed first, or does IrExpr's own TyId-by-construction make it
   moot? R6.1 ("every IrExpr carries its type … no side table and no fallible lookup") reads as
   R4.9 applied at the checker→emitter boundary. But R4.9 is about expr_types's own shape
   (HashMap<Span, Ty> → IndexVec), gated on R2.4 and marked "large" in Appendix D — while R6.1 is
   about a different structure (IrExpr itself) carrying its TyId at construction. Building the
   IR might satisfy R6.1 without ever touching expr_types's representation, in which case R4.9
   stays open by design rather than by omission — or the two might be more entangled than that
   reading suggests. Needs settling, not assuming either way.
3. Where does the IR live? The reference (Part 6) specifies the shape (IrExpr, IrItem,
   Callee, …) but not the crate boundary. Candidates: a new bynk-ir crate (R10.3's "carve
   prospectively when a dependency arrives only one consumer needs" — bynk-check produces the typed
   input, bynk-emit alone consumes the IR), or inside bynk-check itself, now the crate phase 5
   made "the one crate that checks". Gets R10.1's "input/output stated in one line" test wrong at the
   start if picked casually.
4. R6.10 says Callee dispatch is "resolved in phase 5." Phase 5 (the track, bynk-check's
   whole-project checking) just retired without building a Callee enum — its own scope was the
   seven-category diagnostic relocation, not this. Is R6.10's "phase 5" the reference document's own
   conceptual phase numbering (checking, wherever that work currently lands) rather than this
   trajectory's phase-5 track specifically — meaning phase 6 builds Callee resolution as
   bynk-check work, not a retroactively-missed phase-5 item? Needs stating plainly so a reviewer
   doesn't read it as scope phase 5 dropped.
5. A fresh count, not the trajectory's stale "20, low confidence" sizing. Given finding above —
   R6.2/R6.3 landed, R6.5/R6.11 partially landed by ordinary churn — the real remaining surface is
   probably smaller than the trajectory's §5 estimate, the same correction phase 5's own settling
   review made to its row. Needs a genuine recount (rule by rule against Appendix D, the way phase
   5's §1 did for emit_diagnostics) before any slice decomposition is proposed, not an inherited
   number.
6. Part 14's E7 gap (idempotency, §13.4) — in scope, or a forward reference? Part 13's own worked
   exercise found one of its four cases a "partial failure": a durable Idempotency provider needs a
   transactional-participation contract ("E7") that Part 14 names but does not yet build. No durable
   Idempotency provider exists in the shipped compiler today. Building E7 speculatively is exactly
   what R10.3's "carve when a dependency arrives, not on appetite" discipline (and this trajectory's
   own "named trigger, not appetite" treatment of semantics-in-the-checker.md's R10.1 deferral)
   argues against — the settling review should say so explicitly rather than silently including or
   silently dropping it.

Reference rules: R5.1–R5.11, R6.1, R6.5, R6.7–R6.16 (design/bynk-greenfield-compiler.md).
Relative size: trajectory §5 says 20, low confidence — question 5 above is exactly why that
number should not be taken at face value into a slice decomposition.