disembark and embark status banners point to the wrong phase: 02-disembark.md says Phase 4, 03-embark.md says Phase 5, but phase-6-lifeboat.md owns both.

Frontmatter

.abcd/work/issues/resolved/iss-5-disembark-embark-phase-banners.md
open on GitHub ↗ · commit history ↗

References1

• iss-1launch phase ownership contradicts across the record: phase-1-ahoy.md and build-sequence.md make install plus launch the first milestone, but 04-surfaces/04-launch.md says full launch builds in Phase 5. ADR-bound.blocked by

mentions7

• adr-33Launch phase ownership is tiered; the phase index is the sole ownership source
• dcn-26101810034672332026-10-18 — A pull request carries a reservation's work only through its head branch or a closing trailer (facilitator-on-delegation, itd-2610180912189125 review round 2, blocker 4; refines dcn-2610180936568358): the link is the record id in the pull request's head branch name, or on a `Resolves:` or `Delivers:` line of its body, matched on word boundaries so that iss-5 never matches iss-50. A `Refs:` line, which the issue-resolution gate requires of any pull request that only names an issue, carries the work only when the head branch is already this copy's own by another route, and never makes a branch own, so a sibling copy's pull request that mentions the record neither leaves this session waiting nor becomes its branch (grounds: plan review round 2, blocker 4; the RS004 rule in scripts/check-issue-resolution.sh)
• iss-2608270908346617record filename grammar diverges: lint's schema accepts an arbitrary tail and zero ordinal where recordid and capture require a kebab slug and positive ordinal, so a file like iss-5 with an underscore tail is lint-visible but dropped by capture's scanLedger into neither Issues nor Skipped and is a hard CitationError when cited — a silently lost record
• iss-2608280739112123capture's ledger reader is stricter than the shared recordid grammar: after standardising lint and the resolver on recordid.FilenameNumRe, capture's scanLedger/alloc/validate still use their own reFilenameID (strict kebab, no double/leading/trailing hyphen), so a hand-crafted iss-5--x.md is lint-green and resolver-visible but silently absent from capture list. Harmless direction (lint too lenient, capture cannot mint such a slug, no committed record hits it) but it leaves the writer/reader/resolver/gate on two grammars instead of one. Route scanLedger, alloc and validate through recordid.FilenameNumRe("iss") so all four share one grammar. Follow-up to the batch that closed iss-2608270908346617.
• itd-4Nothing You Notice Gets Lost
• itd-2609091034175565Before an agent starts on an item, it reserves it on the shared remote, and everyone who works on the project sees the reservation
• spc-2610180914469489A session left to work on never stops while it has work