← board

GRANT: lexer.inc → frankC, bounded to WriteDiagSourceFile — plus the ir_codegen.inc dual occupancy

Filed because an authorisation is a finding about what is permitted, and an unfiled grant does not read as missing — it reads as covered, because a neighbouring ticket covers the same file. The tooling makes an unfiled TICKET unrepresentable and cannot see an unfiled GRANT. This is the coordinator applying to itself the rule it spends its day enforcing.

1. lexer.inc → frankC, bounded to WriteDiagSourceFile

For feature-c-diagnostics-name-the-module-they-are-in [C p40].

lexer.inc is shared A/P ground — the one file Track P did not get carved out when parser.inc was sliced into pasparser_* — so by CLAUDE.md a Track C ticket may not touch it and must file a Track A ticket instead. The exception is granted because the change is genuinely a single-function one and the ticket says so: WriteDiagSourceFile is "the single place that decides what to print", and the shape is "when the Pascal table has no answer, ask the C one".

Scope, and it is the whole grant:

Slot check at grant time: no lane holds lexer.inc. frankA is in symtab.inc, emit.inc, exception_emit.inc and ir_codegen.inc on the libc-RTL work; the Pascal pointer-alias fix landed and is pinned. Verified against the running fleet, not recalled.

Expires when the ticket resolves. It is not a standing widening of Track C.

2. ir_codegen.inc is held by TWO lanes at once, deliberately

frankA (feature-port-rtl-over-libc, increment 2) and frankS (xtensa wide-record, spot 3) are both in this file right now. That is normally the exact hazard the track letters exist to prevent, and it is being permitted on a bounded, checked argument rather than an optimistic one:

lane region ticket
frankA the body of EmitSyscall — a single choke point feature-port-rtl-over-libc
frankS the xtensa arm of EmitParamSpillsForTarget, all three spots in ONE landing xtensa wide-record

The disjointness is a property of the edits, not of the file, and it rests on frankA's own statement that the register rotation goes inside EmitSyscall with no caller changes — so the 19 EmitSyscall call sites in this file are read, not written. If that stops being true, the grant lapses and frankA must say so before touching a call site. A refactor that "just also touches" a caller is how this becomes a real collision.

Conditions on both:

Why record the dual occupancy as a grant at all

Because the reason is what decays, not the decision. A future reader finding two lanes in one file will see either an oversight or a precedent, and both readings are wrong: it was permitted for a stated reason, with a stated expiry, and with a named condition whose failure revokes it. That is the difference between a decision and a habit — and a guard whose stated reason nobody re-reads is the more dangerous kind (see face 181 in feature-a-a-refusal-is-a-claim-with-a-date-on-it).


CORRECTION, 2026-08-30 ~14:0x — section 2's table is STALE and says the opposite of the truth

Found by frankS running ls devdocs/progress/backlog/grant-*, the enumeration procedure this ticket's own existence argues for. Both rows of section 2's dual-occupancy table are now false, and the filed version says the function frankA is currently in belongs to frankS.

the table says the truth at HEAD
frankS holds EmitParamSpillsForTarget's xtensa arm frankS is off it. That work landed, tree clean, nothing unpushed.
frankA is in EmitSyscall frankA holds ir_codegen.inc whole-file, for EmitParamSpillsForTarget's four-target C-convention prologue arm.

This is not a live collision — frankS's side is stale rather than held. It is worse in a different way: the board's visible record contradicts the coordinator's dispatch, and the board is what anyone else would check. Someone reconciling the two would have concluded that frankA was trespassing.

The condition that lapsed with it

The dual occupancy was permitted on frankA's statement that the register rotation stays inside EmitSyscall with no caller changes, and this grant says explicitly that if that stops being true the grant lapses and frankA must say so before touching a call site. Whole-file for EmitParamSpillsForTarget is a different footprint than the argument that cleared it. The wider grant is deliberate and current — but it was given fresh, not inherited from this one, and this ticket should not be read as authorising it.

Section 1 is unaffected

frankC's lexer.inc grant, bounded to WriteDiagSourceFile, is live and correct. It is now a deliberate dual occupancy with frank-optimize, which holds the Expect call site in the same file — measured disjoint: frank-optimize needs neither half of WriteDiagSourceFile, and its fix folds a stray raw writeln into the Error(...) call already on the next line.

The lesson, which is this ticket's second

Filing a grant makes it enumerable. It does not make it current. A grant ticket records a disposition at a moment, and nothing re-checks it — the same defect as a prose park condition, which check's STALE-PARK aperture exists to catch and which has no equivalent for grants. Fourth expired premise of the day, and the second one found inside a document about expired premises.


CLOSED 2026-08-30 — the system this models no longer exists

The grant mechanism — a coordinator authorising a named agent to touch a named shared file, filed as a ticket so the authorisation was visible — was cut on 2026-08-30 along with the rest of the reservation system, after ten concurrent agents produced exactly one unmergeable rollback in a night. Lane letters are now informative and advisory; nobody needs permission to touch a file, so there is nothing here to grant and nothing to release.

Closed rather than resolved: the work was never done, and the reason it will not be is that the question stopped existing. Evidence for the cut: devdocs/dev/coordination-overhead-2026-08-30.md.

One thing WAS extracted before closing, because it was engineering wearing a grant's clothes: the requirement that the Pascal arm of WriteDiagSourceFile stay reachable in exactly the states it was before — a fallback that fires one state early is invisible to every Pascal test that has an answer. That is a correctness condition on the change, not a permission, and it now lives in feature-c-diagnostics-name-the-module-they-are-in, the ticket it constrains.