Development record

`/abcd` Tells You Where You Are

intentsupersededminorbundle-memberitd-20

Superseded by itd-121 on 2026-09-20, on the product thinker's ruling: the board this intent describes is built on dev-sync and the logbook, neither of which the Go rebuild has; the bare status board and the record dispatcher answer the same question in the shipped shape. The two pieces still wanted, a next-actions list and the planned intents with their spec, are captured as iss-2609201954342967.

Press Release

abcd ships a top-level /abcd command that shows status and quick actions. Type /abcd (no subcommand) and abcd reports: current voyage, visibility, lifeboat status, dev-sync staleness, last disembark, suggested next actions. It's the at-a-glance command for "what's the state of my abcd setup right now?" without having to remember which subcommand to invoke.

"I'd open a voyage I hadn't touched in weeks and have no idea where I'd left off with abcd," said Iris, product manager. "The /abcd command is a one-line status board. Tells me dev-sync hasn't run in 3 days, no recent disembark, and a planned intent ready to pick up. Perfect re-orientation."

Why This Matters

abcd ships six commands (ahoy, disembark, embark, launch, intent, capture). Every command's bare invocation is status+help only (per the universal abcd convention) — but each shows status scoped to its own command's surface (ahoy shows install state, disembark shows last lifeboat pack timestamp, etc.). None of them gives a cross-command "tell me what's happening across the whole project" answer. Users coming back to a project after time away have to either invoke every command individually or inspect filesystem state manually to figure out where they left off.

The pattern was already prototyped in ~/.claude/commands/abcd.md (the user-level command that did /abcd status etc.). Lifting it to be a plugin command makes status-checking discoverable and uniform.

What's In Scope

/abcd (no subcommand) shows status: project name, visibility, lifeboat presence + age, dev-sync last run, recent commands, planned/active intents, suggested next actions
/abcd status as explicit alias
/abcd help summarising the four main verbs + this status command + /abcd:intent family
Output is markdown with light formatting (tables for state, bullets for suggestions)

What's Out of Scope

/abcd init, /abcd init-project (those map to /abcd:ahoy and the itd-21 intent)
Cross-project status (only current cwd's project)
Interactive status dashboard (this is one-shot output, not a TUI)

Scope Conditions

None stated.

Acceptance Criteria

BDD format, per itd-1-acceptance-gates. These gates are checked by intent-fidelity-reviewer when this intent moves to shipped/.

Given an abcd-managed repo, when the user runs /abcd (no subcommand), then the output includes (in this order): project name + visibility, lifeboat presence + age, dev-sync last-run timestamp, recent commands (last 5 from logbook), planned/active intents (from intents/planned/ and any in-flight specs), and a "suggested next actions" bullet list — all in markdown with light table formatting.
Given a project where dev-sync hasn't run in > N hours (configurable threshold), when /abcd runs, then the dev-sync status is highlighted (e.g., "stale: 3 days") AND "Run dev-sync" appears in suggested next actions.
Given a project with no lifeboat ever produced, when /abcd runs, then the lifeboat status reads "never disembarked" AND "Run /abcd:disembark when ready" is among suggested next actions.
Given a project with planned intents in intents/planned/, when /abcd runs, then each planned intent is listed with its title, its phase, and spec_id AND an "in flight on spec spc-N" annotation if the linked spec shows active status.
Given the user runs /abcd help, when the output renders, then it summarises the four main verbs (ahoy, disembark, embark, launch) and the meta-development surfaces (/abcd:intent, /abcd:capture) plus the /abcd status command — single-page, scannable.
Given the user is OUTSIDE an abcd-managed repo (no .abcd/ directory), when they run /abcd, then the output gracefully reports "no abcd config in this directory" and suggests either cd to an abcd repo or /abcd:ahoy to install — does not error.

Open Questions

~~How does this interact with /abcd:intent list — overlap or complementary?~~ Resolved 2026-05-08 by the bare-command-as-render discipline (see 02-constraints/04-naming.md): /abcd:intent list is forbidden (collapses to bare /abcd:intent). The question becomes: does /abcd (this dispatcher's bare) overlap with bare /abcd:intent? Answer: complementary — /abcd is the cross-verb status (project / lifeboat / dev-sync / recent commands / planned intents); bare /abcd:intent is the intent-corpus render (drafts/planned/shipped/disciplines/superseded grouped). Dispatcher links to bare /abcd:intent for drilldown.
Should "suggested next actions" be opinionated (specific recommendations) or open-ended ("you might want to disembark; you might want to start an intent")?
How does the user discover this exists — README, ahoy summary, both?

Audit Notes

Populated by intent-fidelity-reviewer when intent moves to shipped/.

Implementation notes (spc-83.2)

Dev-sync staleness is a v1 terminal known-state stub. The dev-sync implementation exposes migration logic (abcd dev-sync work), NOT a durable last-run timestamp; no config field or history-store record captures when dev-sync last ran. Section (3) of the /abcd board therefore renders no dev-sync record permanently in v1 — the staleness signal does not function until a state substrate exists. This is a recorded terminal state, not a shipped capability. Adding the substrate is out of scope. Full record in the surface doc: ../../brief/04-surfaces/08-abcd.md.
No spc-17 (predecessor store) stub to replace. That spc-17 shipped bare/probe renders for the sub-verb surfaces only; the top-level commands/abcd.md never existed. This task creates it fresh — the "stub replacement" premise is not-applicable (verified against git log).
SD001 alias rationale: status / help are positional aliases routing to the identical bare render (no distinct behaviour), which satisfies SD001 rather than tripping it — recorded in the surface doc against the SD001 clause.
/abcd help covered via the alias (v1 scope). The draft AC had /abcd help render a distinct single-page summary of the four main verbs plus the meta-development surfaces. V1 makes help a byte-identical POSITIONAL ALIAS of the bare status board (bare-as-render IS the help), so the where-am-i board — which already surfaces the active surfaces and suggested next actions — is the help output. A separate verb-summary render would be a forbidden SD001 sub-verb; folding help into the bare render is the deliberate v1 resolution, fully covering the /abcd help requirement without a divergent surface.
Bundle-member linkage (spc-83 four-intents-one-spec). This intent is authored as a standalone press release but ships as one of FOUR intents sharing spec spc-83-operator-surfaces-manifest-lockstep. abcd's data model represents "N intents, one spec" as a bundle (kind: bundle-member + shared bundle: spc-83-operator-surfaces), which the doc_fidelity intent-resolution and the spec-close preflight require — so this intent carries that linkage. It is a bundle member by delivery relationship, not a change to its standalone press-release scope.

Frontmatter

id	itd-20
type	intent
lifecycle	superseded
kind	bundle-member
severity	minor

.abcd/development/intents/superseded/itd-20-top-level-abcd-dispatcher.md
open on GitHub ↗ · commit history ↗

References1

itd-4Nothing You Notice Gets Lostbuilds on

Referenced by3

iss-168abcd's presence should be visible in the host harness's status line / command line: a managed repo shows an 'abcd-managed' indicator (and possibly guard health) so the user can tell at a glance whether the current session is under abcd management without running a command. Needs a per-host adapter (e.g. a statusline hook) with the usual basics-built-in stance.related
itd-121Type The Id, Get Your Next Movesuperseded by
itd-200A managed repository shows it is managed, and whose answer the loop is waiting on, in the host's status linebuilt on by

mentions20

adr-34Intent lifecycle and phase scheduling are orthogonal axes
dcn-26092500000000312026-09-25 — itd-2609211913453478's acceptance criterion 4 ships under two readings the intent's scope line does not state. A glossary entry's `not_to_be_confused_with` passes when at least one member names a family row on the record-families page or the page itself, where the scope line says the field "may name only a family on the page"; the stricter reading would force nonsense pairs such as warm against intent, and the entries keep their real confusion pairs. The family-key rule (`record_family_key`, warn) reports a record frontmatter key only when the glossary already marks that word superseded or forbidden, so a brand-new grouping word with no row (the intent's own Mechanism case, e.g. an `initiative:` key) is not detected by construction, and the stores the page does not row (adr, rdi, dsp, rdg, adm, srp) are not reported. The six `grandfathered_at_phase` warnings on itd-20, 27, 28, 63, 69 and 72 are history and stay. Recorded for the product thinker to confirm or widen (autonomous run A, glossary lane review, orchestrator abcd-39).
iss-3phase membership and lifecycle directories disagree: planned intents (itd-20, itd-24, itd-29, itd-46) appear in no phase Scope, while draft itd-43 is scoped into Phase 0/1 yet listed later-phase. ADR-bound.
iss-123Round-4 residue of the brief reconciliation: nine precision-grade discrepancies remain after three fix rounds (102 -> 52 -> 25 -> 9), all empirically verified by the checkers and none of the judgement-flip-flop class. Examples: bare ahoy prints a next-step line only for unmanaged kinds but the criterion says any folder kind; embark's manifest verification excludes the post-pack synthesis layer while the chapter claims blanket tamper-evidence; a live bundle (spc-83-operator-surfaces, itd-20+itd-24) contradicts the no-live-bundles claim; the persona_registry lint checks personas.json, not the markdown page named as SSOT; history capture idempotency keys on (sha256, session, kind), not content hash alone. Full findings in the local scratch tier (2026-07-22-iss35-crosscheck-round4 file). The geometric tail also suggests the detector at 22-checker depth has a nonzero noise floor per fresh run — the pass threshold question belongs to iss-122.
iss-2608220150151397brief 01-product/03-mental-model.md claims the corpus has zero live bundles and points at retired-bundle history, but four planned intents (itd-20/24/63/69) declare bundle-member of spc-83-operator-surfaces and intents/README heads it Active bundles; residual of resolved iss-123 which fixed the README half only
iss-2609201954342967The bare status board lacks two rows the record dispatcher already answers for a single record: suggested next actions for the repository, and the planned intents with their spec and whether it is in flight. Ruled by the product thinker on 2026-09-20 while superseding itd-20 (the Python-era board built on [redacted-user]-sync and the logbook) by itd-121: those two pieces of itd-20 are still wanted and are captured here so the supersession loses nothing. Wanted: (1) the board ends with a short next-actions list derived the way abcd <record-id> derives one record's next move (an owed fidelity audit, an unplanned draft with all decisions recorded, a stale claim); (2) the board lists each planned intent with its spec id and an in-flight marker where the spec is open and its branch exists. Both are read-only rows on the existing board; no new verb.
iss-2609290448510918The predecessor-store qualifier sweep reaches past the six intents iss-2609261536147903 named: outside drafts/ and those six, 192 citation sites across about forty intents name a spc-N at or below spc-70 that is not the citing intent's own spec, with no '(predecessor store)' on the line. Some are live cross-references (the cold-reading family's intents cite each other's live specs), and some are the predecessor store's (itd-4, itd-6, itd-29, itd-47 and itd-49 describe pre-rebuild work in its terms), so each site needs the same reading against the live spec it collides with; the specs charter's Two spc-N Namespaces section is the rule. Found while sweeping the pattern of iss-2609261536147903 in lane drainDrift3; a census script over intents/{planned,shipped,disciplines} reproduces the count.
iss-2610171626303019The v0.15.1 release review found the brief at .abcd/development/brief/04-surfaces/08-abcd.md:523 out of step with the shipped code. It says: In the itd-20 design-target note: 'There is no alias routing either: `status` is refused and `help` prints the verb list'; line 590 adds 'Nothing routes them today'. In the code: `status` is a shipped top-level verb (bin/abcd-darwin-arm64 status --help: 'List everyone's announcements, reservations and releases being cut'), and the chapter itself says so at 'abcd status is its own verb' (39-status.md); it is not refused.
iss-261025221420007005-intent.md:523 says every record in superseded/ carries kind_at_supersession; itd-17, itd-27 and itd-58 do not, and itd-20 keeps a non-null bundle with no bundle_at_supersession, against :509.
iss-2610252214242532intents/README.md lags the code and the record. :38 and :277 list the spc-83-operator-surfaces members as planned (itd-24, 63 and 69 shipped; itd-20 superseded). :100 and :132 mark bundle and reclassify as design targets, though bundle.go and reclassify.go ship. :159 says an intent is 'implemented by exactly one spec', against invariant 17 (02-constraints/03-invariants.md:171). Its own :33 names the brief canonical.
iss-261025221446387308-abcd.md:517-599 keeps the six-section board of itd-20 as a 'Design target', with two open questions and an alias rationale, though itd-20 was superseded by itd-121 on 2026-09-20 (intents/superseded/itd-20-top-level-abcd-dispatcher.md:24,32) and the truth rule (00-meta.md:7-16) admits only decided shipped or staged machinery and sends open questions to 03-open-questions.md; 01-product/04-scope.md:16 still cites the board as 'per itd-20', 08-abcd.md:604 names only itd-20, and 06-capture.md:520-522 links its dev-sync dependency to this section.
iss-2610262030547620The truth rule says everything in the brief is decided; the board chapter's design target rests on a superseded intent with no spec
iss-261104055441886505-intent.md:511 and :525 say an intent in superseded/ with kind_at_supersession: bundle-member carries bundle: null and bundle_at_supersession: <bundle-id>. intents/superseded/itd-20-top-level-abcd-dispatcher.md has kind_at_supersession: bundle-member, keeps bundle: spc-83-operator-surfaces and has no bundle_at_supersession.
itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them
itd-21Start a New Project With abcd Conventions
itd-33Multiple Agents Coordinate On Intent And Spec Work Without Duplicating Effort Or Producing Competing Artefacts
itd-78abcd Knows What to Build First — Even When It's Something Small
itd-177An intent's claims are typed and its scope conditions keep their identity across edits — the readiness gate refuses an intent that leaves a context claim unrecorded
itd-2609151838312703Sessions under any account, on any machine or in the cloud announce what they are doing through short fixed-form announcements on the shared remote, a person reads everyone's status with one command, and what is really a hold stays a reservation
spc-17every-citation-abcd-publishes-is-provably-alive-and-honestly