Development record
Every Intent Has Acceptance Criteria; Every Audit Verifies Them
Rule
Every standalone or bundle-member intent in drafts/ and planned/ carries a ## Acceptance Criteria section with at least one well-formed Given-When-Then bullet. Every discipline intent in disciplines/ carries the same. /abcd:intent plan refuses to promote an intent without it (hard block via the record lint, internal/core/lint). Every shipped intent's ## Audit Notes section contains per-criterion verdicts (MET / MET_WITH_CONCERNS / NOT_MET / INCONCLUSIVE) emitted by the intent-auditor agent's single-document role.
Why
abcd's intent format captures direction (press release or ## Rule) and scope (in/out lists). Without acceptance criteria it cannot capture the verifiable bar for "shipped". The intent-auditor agent is otherwise reduced to interpreting prose, which means drift detection depends on the reviewer's judgement rather than on a pre-committed standard.
Prior art (PAUL) treats acceptance criteria as a hard gate: defined before tasks, verified by an Execute/Qualify loop, with multi-state escalation outcomes (DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED). The full PAUL framework is more than abcd currently needs; the acceptance-criteria pattern (Given-When-Then) is the load-bearing piece.
This is a small schema bump with a large quality return. Every intent gets a measurable definition of done; every audit becomes a check, not an interpretation. The discipline is project-agnostic: any project using the abcd intent framework inherits this rule — application projects (idelphiDev, etc.) write their own Given-When-Then criteria for their own user moments; framework projects (abcd itself) write criteria for their own discipline intents.
What's In Scope
## Acceptance Criteriasection required in every intent template (standalone, bundle-member, and discipline). At least one Given-When-Then bullet. The section header is fixed (parser depends on it).- Hard-block validation in
/abcd:intent plan— intent cannot transitiondrafts/→planned/(ordrafts/→disciplines/) without at least one well-formed acceptance criterion. Lint code:IL002(delivered by spc-8 (predecessor store); see05-internals/06-lint.md). intent-auditorsingle-document role — when auditing a shipped intent, the agent emits a per-criterion verdict block into the intent's own## Audit Notessection. The writer maintains a single delimited### itd-1 review <ts>block (machine-fenced so a repeat review replaces it in place — the section never accumulates stale blocks; git history is the prior-review trail):## Audit Notes ### itd-1 review <ts> Acceptance: - [MET] Given <X>, when <Y>, then <Z> — verified by … - [MET_WITH_CONCERNS] Given <A>, when <B>, then <C> — partially observed; concern: … - [NOT_MET] Given <D>, when <E>, then <F> — divergence: … - [INCONCLUSIVE] Given <G>, when <H>, then <J> — could not verify: … Overall: MET / MET_WITH_CONCERNS / NOT_MET / INCONCLUSIVEThis
## Audit Noteswrite is the verdict of record; each run also writes a per-run forensic copy at.abcd/logbook/audit/review-<ts>/report.{json,md}. spc-12 (predecessor store) ships the manual reviewer (/abcd:intent audit <itd-N>) plus the## Audit Notes/review-<ts>writers; automatic invocation on theplanned → shippedtransition is deferred to the lifecycle-owning spec (spc-6, predecessor store). Until that lands, a shipped intent's## Audit Notesis populated only when/abcd:intent auditis run by hand.- Escalation states — four states, lifted from PAUL. Binary pass/fail loses information; four states preserve nuance without exploding.
- Verdict family disjointness (cross-referenced from
05-internals/01-agents.md § Verdict-tag protocol). The four criterion verdicts above (MET/MET_WITH_CONCERNS/NOT_MET/INCONCLUSIVE) score promise vs reality on a shipped intent — they belong tointent-auditor's Role 1 output. They are deliberately disjoint from review verdicts (SHIP/NEEDS_WORK/MAJOR_RETHINK) which score changes/runs (oracle reviews of plans, implementations, completions; consumed by the native receipt schema validator). The two enums never mix — review verdicts emit on a change, criterion verdicts emit on a promise. This disjointness was reinforced 2026-05-08 when idea-4's pre-review draft conflated the two families ("NOT_MET on an agent run" — wrong; criterion verdicts apply to intents not agents). Closing-the-loop signals on agents (per Frontier Awareness, idea-4) MUST use canary/golden-test/operator-tagged failure signals, NOT spec-level criterion verdicts. - Intent template update — the intent template the binary scaffolds (
internal/core) includes the## Acceptance Criteriasection with one example criterion. The discipline template (separate file) includes the same section. - Inheritance into every other spec — every native spec plan-reviewed under abcd inherits the discipline's gate: the spec must reference the parent intent's acceptance criteria as the verification bar, and
intent-auditorchecks delivered reality against them on shipping.
What's Out of Scope
- Full PAUL Execute/Qualify loop — the per-task verification machinery (coherence checks, diagnostic routing) is out of scope. This discipline takes only the acceptance-criteria pattern.
- Automated criterion-checking — the reviewer reads, judges, and emits verdicts. No code-level test generation from Given-When-Then. (Could become an
itd-candidate later.) - Cross-intent acceptance dependencies — each intent's criteria are independent. No "this intent inherits acceptance from itd-N" beyond the discipline's own application.
- Quantitative thresholds as a separate system — criteria can include numbers ("token overhead < 200") but there's no separate metric-tracking system. The reviewer reports observed vs. target.
- Retroactive backfill of historic intents that have already shipped — once an intent ships, the criteria are frozen alongside the press release. Pre-discipline historic intents (none yet shipped at time of this draft) won't be retroactively rewritten.
Acceptance Criteria
Yes, this discipline eats its own dog food. The criteria below describe how the discipline itself is checked — by the record lint (
internal/core/lint) at promotion time and byintent-auditor's single-document role on every shipped intent.
- Given a draft intent without an
## Acceptance Criteriasection, when the user runs/abcd:intent plan itd-N, then the command refuses to promote the intent and lists the missing section as the reason. - Given a draft intent with a malformed acceptance section (e.g. no Given-When-Then bullets, or a header but empty body), when
/abcd:intent planruns, then the lint emits a specific error pointing at the malformed line. - Given a discipline-kind intent in
drafts/without a## Acceptance Criteriasection, when the user attempts to promote it via/abcd:intent plan --kind discipline, then the same hard-block applies — disciplines are not exempt from their own rule. - Given a shipped intent with three acceptance criteria, when
intent-auditorruns, then the resulting Audit Notes contain exactly three per-criterion verdict lines plus an overall status. (Audit note 2026-05-07: this criterion is verifiable only after the reviewer's implementation lands in a separate spec; until then it is a paper-only gate. The reviewer itself will retroactively run against this discipline when implemented.) - Given a reviewer verdict of
NOT_METon any criterion, when the reviewer writes its report, then the report includes a "Divergence" sub-section explaining what was delivered vs. what was promised — not just a label. - Given the brief is updated, when a contributor reads
04-surfaces/05-intent.md(intent system), then they find the acceptance-pattern requirement and one worked example with all four verdict types. - Given a native spec that traces back to a parent intent, when the spec's plan-review runs, then the review verifies the spec's acceptance section references (or is structurally compatible with) the parent intent's
## Acceptance Criteriabullets — drift between the two surfaces is flagged. - Given any native spec that traces back to a brief phase or directly to this discipline, when the spec's plan-review runs, then the review verifies the spec carries its own
## Acceptance Criteriablock — the discipline applies to plumbing specs too, not just intent-derived ones.
Open Questions
- Lint strictness on existing drafts — pre-discipline drafts (already grandfathered above) may have malformed AC sections rather than missing ones. Should
/abcd:intent planwarn-and-prompt or hard-block in that case? (Recommend: hard-block. The whole point is to force the discipline. Backfill happens at the user's own pace via/abcd:intent refine.) - Verdict-rollup logic — lives in
brief/04-surfaces/05-intent.md § 7(SSOT). Don't duplicate here. - How many criteria are too many? — 1 minimum is enforced; 5+ may indicate the intent is too big and should split. Document as a soft guideline, not a lint.
- Criterion language — strict Given-When-Then only, or allow plain bullet criteria as a fallback? (Recommend: strict. Plain bullets are what scope sections already provide; criteria need to be observable, not aspirational.)
- Discipline-specific AC shape — disciplines describe rules, not deliverables. Should their
## Acceptance Criteriadescribe how the rule is verified (e.g., "Given an intent without AC, when plan runs, then it fails") rather than what the deliverable is? (Recommend: yes, explicit in the discipline template; this discipline's own AC above is a worked example.)
Audit Notes
Empty. Populated by intent-auditor's single-document role when this discipline is first audited. Note: disciplines never "ship" in the standalone-intent sense — they are audited continuously via the rule-applies-to-every-spec semantics rather than via a planned→shipped transition. The reviewer's findings here record any spec that violated this discipline (e.g., merged without an AC section).
References
- See
research/related-work.mdfor the full PAUL / BDD comparison that informed this discipline. - The discipline is one of two introduced alongside itd-5 (prompt-quality additions). Both lived as
kind: standaloneintents and were reclassified tokind: disciplinewhen the three-kinds model was introduced.
Frontmatter
| id | itd-1 |
|---|---|
| type | intent |
| lifecycle | disciplines |
| kind | discipline |
| severity | critical |
.abcd/development/intents/disciplines/itd-1-acceptance-gates.md
open on GitHub ↗ · commit history ↗
Referenced by32
- adr-2Three intent kinds (standalone / bundle-member / discipline)related
- iss-2610262031299872itd-1 writes each audit run's forensic copy under .abcd/logbook/, a location the naming chapter has retiredrelated
- iss-2610262033567089itd-1 says plan's acceptance-criteria refusal is a record-lint hard block; the intent surface says it is the intent package's own check, not internal/core/lintrelated
- iss-2610262037138873itd-1 says a shipped intent's Audit Notes come only from an audit run by hand, because the automatic audit at ship time is deferred; the build loop already runs that audit and ingests it when the intent ships.related
- iss-2610262037142878itd-1 says reviews of implementations return SHIP / NEEDS_WORK / MAJOR_RETHINK; the build's implementation reviewers return SHIP or FIX FIRST.related
- iss-2610262038389473itd-1 says Audit Notes fill only from a hand-run audit; 01-agents says a build run audits automatically in the validate stagerelated
- iss-2610262038393994itd-1 writes each audit's forensic copy under .abcd/logbook/; 04-universal-patterns says that name is retired and must not be re-mintedrelated
- iss-2610262038399413itd-1 says the SHIP/NEEDS_WORK/MAJOR_RETHINK review verdicts score plan and implementation reviews; 01-agents limits them to a packed lifeboatrelated
- iss-2610262038415265itd-1 cites lint code IL002 and points to 06-lint.md for it; 06-lint says the engine has no numbered codesrelated
- iss-2610262040343151itd-1 has every audit run write a forensic copy under .abcd/logbook/; the build sequence says .abcd/logbook/ is a retired location held retired by a detector.related
- iss-2610262040355731itd-1 says Audit Notes are filled only by a hand-run audit; the verification matrix says the shipping close itself requests the audit and can ingest the verdict.related
- iss-2610262042332488itd-1 puts Acceptance Criteria in the discipline template; itd-190 says the discipline template carries no claim sectionsrelated
- iss-2610262042345947itd-1 gives intent-auditor four verdict states and rejects binary pass/fail; itd-81 requires binary verdicts from every judge, intent-auditor named firstrelated
- iss-2610262042363456The agent that audits a shipped intent is intent-auditor in itd-1 and intent-fidelity-reviewer in itd-25related
- iss-2610262043043502itd-1 names the agent that writes criterion verdicts 'intent-auditor'; itd-50 names it 'intent-fidelity-reviewer'.related
- iss-2610262043043610itd-1 fixes the audit at four verdict states; itd-50 adds UNACHIEVABLE as a fifth terminal audit outcome.related
- iss-2610262043221489itd-1 calls the single-document fidelity auditor intent-auditor; itd-34 calls the same agent intent-fidelity-reviewerrelated
- iss-2610262043257570itd-1 says Audit Notes fill only when the audit is run by hand; itd-2609081951381895 has spec close send the review and ingest the answerrelated
- iss-2610262043392051itd-1 calls the Role 1 fidelity agent intent-auditor; itd-48 calls the same agent intent-fidelity-reviewerrelated
- iss-2610262043406581itd-1 calls the fidelity-review sub-verb /abcd:intent audit; itd-80 ships it as abcd intent review ingestrelated
- iss-2610262043417816itd-1 has a repeat review replace the one Audit Notes block in place; itd-80 appends each ingested verdict, keyed on its receiptrelated
- itd-5Every Agent Prompt Carries Its Version, Earns Its Lock, And Survives Injectionblocks
- itd-21Start a New Project With abcd Conventionsbuilt on by
- itd-27Domain Experts Get Their Intents Grilled Before Anyone Codes Thembuilt on by
- itd-28Spec-Tied Reviews Live Next To The Spec They Reviewedbuilt on by
- itd-30Design Fictions As An Alternative Capture Format For Intentsbuilt on by
- itd-34Intents Promote In Three Flavours — Standalone, Bundle-Member, Disciplinebuilt on by
- itd-37Every Spec Externalises How It Should And Shouldn't Be Modifiedbuilt on by
- itd-80An Intent Ships Itself: `planned → shipped` Follows Its Spec Closing, With A Fidelity Audit Attachedbuilt on by
- itd-81No Judge Ships Unmeasured, And A Clean Diff Is A Resultblocks
- itd-84An Intent Is Decomposed Before It Is Filed, And A Reversal Is Only Ever Flaggedblocks
- itd-190The claim recording gradient: an intent's three claim kinds carry three recording requirements, and the readiness gate holds thembuilt on by
mentions184
- adr-51An intent can declare its mechanism claim and its scope conditions
- adr-2609151513118583An intent owns one or more specs, and it ships when its last spec closes
- dcn-26070800000000072026-07-08 — Edges stay one-way (dependent-authored), reverse views derived
- dcn-26080500000000032026-08-05 — iss-80 (v0.5.0): resolved as already-fixed, with the residual verification gap closed rather than the defect re-fixed. The branch-local id-collision class this item tracked — `itd-N`/`spc-N`/`iss-N` allocators scanning only the working tree, so two agents on branches cut from one base each mint the same id and collide at merge — was already closed by iss-115 and iss-120, which introduced `recordid.MaxAcrossRefs` (scan every git ref for the family's highest committed id) and folded it into all three minting paths: `internal/core/spec/store.go`, `internal/core/intent/create.go`, and `internal/core/capture/workflow.go`. What survived was uneven evidence, not an uneven fix: only the `spc-N` family had an end-to-end regression test standing up a real two-branch history (`internal/core/spec/refunion_test.go`), while none of capture's or intent's existing tests stood up a real two-branch history through `Capture`/`CreateFromText` and so never drove the ref scan through their public entry points at all — `MaxAcrossRefs` was exercised only as a primitive in its own package test, never as wiring. That is the shape in which a fix silently un-wires: a refactor that dropped the `MaxAcrossRefs` call from `Capture` or `CreateFromText` would have left every existing test in both packages green. So this round adds `internal/core/capture/refunion_test.go` (`TestCaptureMintsPastACommittedBranch`) and `internal/core/intent/refunion_test.go` (`TestCreateFromTextMintsPastACommittedBranch`), each mirroring the spec test's exact fixture via `internal/gittest.NewRepo` — branch A mints and commits record 1, branch B is cut from before that commit so its working tree carries no record, and B must mint record 2. Both were mutation-checked before being trusted: with `MaxAcrossRefs` stubbed to return an empty `RefScan`, each fails with precisely the collision it names (`iss-1`/`itd-1` re-minted on branch B), and all three families fail together — so the tests are pinned to the ref-union behaviour rather than passing incidentally. No production code was touched, which is the point: the minting paths were verified correct by reading before the coverage was written, and the change is test-and-record only. Impact recorded as `internal` and no CHANGELOG entry, matching the iss-34 precedent for a test-only closure with no user-facing behaviour change.
- dcn-26081700000000022026-08-17 — README bucket-vocabulary alignment (#289), made unattended
- iss-210A lone token that a user plausibly expects to be a subverb, but which is not one, is swallowed as free text and WRITES A RECORD on both mutating verb families — 'abcd intent status' files drafts/itd-N-status.md and 'abcd capture status' files issues/open/iss-N-status.md, each exit 0. Verified 2026-08-11 by building HEAD into a scratch repo and running both. This is a residual hole in the unrecognized-input-never-writes rule (iss-29) that iss-104's fix does not cover: suspectedTypoedSubcommand (internal/surface/cli/cli.go:2000) fires only on a NEAR-MISS of a real subverb, bestDist initialised to 3 so only edit distances 1 and 2 refuse. It is deliberately high-precision so a genuine multi-word prose title whose first word resembles a verb still files — the controls confirm that half works: 'capture resovle iss-1 note' and 'intent paln itd-1' both exit 2 with a did-you-mean and write nothing. But 'status' is edit distance >=4 from every real subverb in either family (intent: new/plan/ready/link/review/ingest; capture: list/resolve/wontfix), so the guard never engages and the word becomes the record title. The class is any plausible-but-nonexistent subverb far from every real one; 'abcd intent list' happens to be caught only by the accident that levenshtein(list,link)=2. NOT an intent-vs-capture asymmetry: the two behave identically, so a fix must land on the shared guard, not on the intent path alone. Fix direction: edit distance is the wrong discriminator for this class. A LONE single token with no other args is never a useful issue or intent title, so treat it as an unrecognized subcommand regardless of distance — refuse, exit 2, write nothing, name the real subverbs, and say how to force prose (quote it, or add words) so the terse-free-text escape hatch stays open. Detector: extend intent_surface_test.go and the capture surface test with a lone-token case per mutating verb family asserting exit 2 and zero records written, watched fail before the change; the existing near-miss cases must keep passing, and a multi-word prose title must still file. Impact on resolve is 'fix' at best and arguably 'breaking' — an unattended script or loop that shells 'abcd capture <one-word>' expecting a file would start failing — so it is NOT additive-class. Standing risk this closes: any autonomous loop that shells a bare word into either verb silently grows the ledger with junk records that a human must later triage.
- iss-298The brief carries broken and stale intra-record cross-references invisible to links_resolve (which strips the #fragment before resolving): six deep links name headings that were renamed or renumbered (04-launch.md, 04-universal-patterns.md, 01-ahoy.md, 05-intent.md sections 5/6/7), ten anchors mis-encode an em dash, 00-meta.md cites a deleted disembark section-3 budget rule, and three live README lines cite the pre-split monolithic brief by section number
- iss-320brief and intent record cross-references carry dangling section anchors including five that misdirect a reader to the wrong section
- iss-351the three-disciplines roster itd-1 itd-5 itd-37 is hand-enumerated at six sites while intents/disciplines/ holds six active disciplines, dropping itd-79 itd-81 itd-84 from the mental model, scope, roadmap dashboard and phase-0 acceptance
- iss-390the pre-decided promotion of examples-use-reserved-identifiers to a discipline-kind intent never happened — the iss-154 lint shipped, the principles README contract says a mechanical gate promotes the principle, and no discipline intent exists
- iss-2608280824478819The canonical credit surface is incomplete: design-shaping inspirations fully credited in the committed record never propagated to ACKNOWLEDGEMENTS.md. Backfill set from the 2026-08-28 attribution review: add Inspirations entries for CARL and PAUL (both Kahler, MIT; mechanisms adopted per itd-3 and itd-1), SpecStory (adr-29 seam, specstory-import ships in CLI help), the Karpathy LLM-wiki gist (memory-substrate pattern), gitleaks and TruffleHog (integrated scanners, one self-declared adapted regex), and Dieter Rams; complete the Diataxis entry with the author and CC-BY-SA 4.0; widen the mattpocock entry (ADR three-clause test, PRD shape); add Dell'Acqua et al. 2023 to the CSL references; add source URLs to the Horn and Weng credits and the arXiv id to the Iacob citation; record the skills' authorship in the socratic/first-principles research note; fix the dead to-prd deep link in itd-27.
- iss-2608301803423101an unclosed comment or fence anywhere in an issue record blinds every grounds triage route permanently and promote orphans a draft per attempt
- iss-2609081941074556releaseOf stamps the homepage feature block by strings.Contains of the record id against each CHANGELOG line, with no word boundary, walking newest dated section first. A short id therefore inherits a longer one: on ec7f40d6 releaseOf(itd-9) returns 0.4.1 off the itd-93 credit and releaseOf(itd-1) returns 0.7.1 off itd-130, and a future superstring landing in a newer section restamps the featured id. site check does not validate the stamp. The same package already carries bodyHandleRe. Fix: match the record id at a word boundary (reuse bodyHandleRe, or split the line into tokens); newest-section-first can stay. Detector: a changelog whose newer dated section mentions itd-1990 must not stamp featured itd-199, while a line naming itd-199 as its own id still matches. Independent of the Audit Notes rollup scanner. Reported as GitHub issue 624 against ec7f40d6. <!-- record-lint: illustrative -->
- iss-2609261536147903Planned intents and disciplines still cite specs of the retired predecessor store unqualified, and such an id at or below spc-70 resolves to a live spec on another subject (spc-12, for one, is live as the disembark grounding spec): itd-48, itd-50 and itd-53 name spc-12, spc-28, spc-29, spc-31, spc-33, spc-43 and spc-52 for the fidelity reviewer, lifecycle hook and cleanup work (which of these are predecessor ids is itself the reading this record owes); itd-24 names spc-66 as the phase-audit receipt; itd-1 and itd-37 name spc-12 as the manual reviewer. The specs charter (Two spc-N Namespaces) rules that every predecessor citation carries the '(predecessor store)' qualifier; iss-239 applied it to the draft corpus only. Each site needs a reading to tell a predecessor citation from a live one, which is why the sweep was not folded into iss-239.
- iss-2610040732240935Record pages scroll sideways at 360 px whenever a record's title or source path holds a long unbroken token, and the overflow audit cannot see it. Every ADR minted with a timestamp id shows its source path, .abcd/development/decisions/adrs/<16 digits>-<slug>.md, as one mono span in the side panel's reclinks paragraph, and the run up to the first hyphen is about fifty characters with no break opportunity: /record/adr/adr-2609091248200336/ measures scrollWidth 374 at 360 px. adr-2610031751065746 and adr-2610031751066232 also carry a home-relative path in their titles, which overflows the record page's h1 (scrollWidth 455). The stylesheet sets no overflow-wrap on body, the title or reclinks, so a block whose text has nowhere to break widens the page. The site-screenshots audit samples only the lowest-numbered record of each type (adr-1, itd-1, iss-1), whose paths and titles are short, so these pages have overflowed since timestamp ADRs began without the job noticing.
- iss-2610121206277151The stale-usage note's classifier (internal/surface/cli/staleusage.go) reads a positional argument under a verb that has sub-verbs as an unknown sub-verb: 'abcd build itd-1 --frob-top' takes itd-1 for a sub-verb of build, so a flag the build page genuinely documents for 'abcd build <itd-N>' gets no stale-binary note. It fails safe (the plain unknown-flag refusal, never wrong advice), but a stale binary is then not told why. Found by the fix for iss-2610120921425348 and iss-2610120921497084 (branch fix/stale-usage-notes), which left it outside those remedies. <!-- record-lint: forward-looking -->
- iss-2610262030417187Invariant 8 requires every intent's press release to carry Acceptance Criteria; the intent chapter says a bench draft may carry none
- iss-2610262031362851itd-21 files the starter intent as itd-1, an id the collision-proof minting invariant does not allocate
- iss-2610262033346897The intent chapter stages the fidelity audit's request under the local reviews directory, while universal patterns puts the same audit's output in a review sub-tier of the log tier.
- iss-2610262034034042itd-21 has the scaffold's starter intent captured as itd-1; the intent create mints a timestamp-numeric id
- iss-2610262036053576itd-21's scaffold files the starter intent as `itd-1`; 24-decide says every minting family draws timestamp ids through one mint that reads no maximum.
- iss-2610262043436609itd-37 gives Role 1 the job of spotting spec boilerplate at plan-review; itd-48 defines Role 1 as grading a shipped intent's criteria against delivered reality
- itd-2In-Session Subagent Dispatch — the Default Host-Delegated Oracle
- itd-3abcd Loads Its Own Rules On Demand
- itd-4Nothing You Notice Gets Lost
- itd-7Lifeboats Carry RepoPrompt Workspace Definitions Forward
- itd-8Lifeboats Carry Source Code, Not Just Lessons
- itd-9Old Lifeboats Still Unpack
- itd-10Full Removal When You Mean It
- itd-11Disembark Survives Noisy Transcripts
- itd-12Working Notes Don't Outrank Settled Decisions
- itd-13Reviews and Memory Stay Fresh, Always
- itd-14Prompts Are Versioned Like Code
- itd-15abcd Audits Its Own Prompts on Every Self-Disembark
- itd-16`/abcd:audit` Is the Umbrella; Conversation/Edit Chain Is Its Default Application
- itd-17Pick the Right Oracle for the Job, Automatically
- itd-18Sensible Permissions From Day One
- itd-19Defaults That Match Where the Project Lives
- itd-20`/abcd` Tells You Where You Are
- itd-22abcd Reaches Any Harness Through an Adaptor
- itd-23Lifeboats Speak To External Tools
- itd-24Completed Releases Get A Retrospective
- itd-25Patterns Surface Themselves
- itd-26Raid the Open Ocean, Bring the Cargo Home with Papers
- itd-29Domain Experts Run A Spec Autonomously And Recover From Anything Without Touching Git
- itd-31The Brief and Every Intent Stay Consistent — Or Abcd Tells You Why They Don't
- itd-32Every Audit In Abcd Knows What It Audits, By What, And Against What
- itd-35Lifeboats Carry Their Own Integrity Proof
- itd-36Knowledge That Compounds, Not Knowledge That Re-Derives
- itd-39abcd Surfaces the Right Memory at the Right Moment
- itd-40abcd Knows What Kind of Folder You're In
- itd-41abcd Tells You, Honestly, What a Phasing Choice Costs
- itd-43abcd Speaks One Word for a Specced Block of Work, and That Word Is "Spec"
- itd-46`/abcd:intent "<text>"` And `/abcd:capture "<text>"` Become Symmetric Create Paths
- itd-51abcd Knows What "Safe Enough to Adopt" Means Before a New Harness Arrives
- itd-55abcd Can Tell Whether Its Own Reasoning Rests On Bedrock Or On An Unexamined Assumption
- itd-57Every abcd Voyage Ships With A Manual-Hold Sentinel That Blocks A Spec From Autonomous Pickup Until A Human Lifts It
- itd-58A Real Reviewer's SHIP Verdict Reaches The Session Gate Through A Channel The Worker Cannot Forge
- itd-59Every Autonomous Run Pass Leaves the Same Durable, Queryable Transcript an Interactive Session Does
- itd-60When A Surface Ships, The Brief Describes It — Or The Intent Does Not Reach Shipped
- itd-61A Human Edit To The Brief Cannot Commit Until Its Implied Intents And Principles Are Drawn Out And Reconciled
- itd-62abcd Routes The Invisible Risks An Amateur Cannot See To A Real, Fail-Closed Gate That Wraps A Trusted Scanner
- itd-64abcd Learns From Its Own Runs Which Configurations Work Best, And Tunes Its Configuration Layer Accordingly
- itd-65abcd Refuses To Publish A Payload Until The Full Ship-Time Pre-Flight Gate Suite Passes, Not Just The Secret Scan
- itd-66abcd Renders The Exact Public Payload, Proves The Excludes Never Leak, And Smoke-Tests The Installed Surface Before Any Snapshot
- itd-67abcd Is An Installable, Versioned Claude Code Plugin Whose Repo Is Its Own Marketplace And Whose Every Launch Bumps, Tags, And Publishes A New Version
- itd-69Plugin Metadata Stays Consistent Across Every Duplicated Surface
- itd-72Publishing A Release Is One Atomic, Refusable `ship`
- itd-73abcd Cuts the Version — You Never Type One
- itd-74abcd Keeps the Names You Ban Out of Everything You Publish
- itd-79Personas Come From the Registry; the Role Picks the Name
- itd-83The Review Bar Fires By Itself, In Every Repo abcd Manages
- itd-85A Read-Only Repo-Conformance Audit
- itd-86abcd Can Read Its Own Design Documents As A Stranger Would
- itd-87A Finding That Comes Back After You Closed It Tells You Something, And abcd Stops Throwing It Away
- itd-88Know What a Repo Can and Cannot Tell You — Before You Trust the Lifeboat
- itd-89Capture the Session You Just Had, Because You Cannot Capture It Later
- itd-90The Product Thinker Is Handed Exactly The Questions Only They Can Answer — And Nothing Else
- itd-91A Project Declares Once How It Wants AI Acknowledged — And Every Commit, PR, And Record Follows
- itd-93abcd Scaffolds a Release Gate That Works on the First Try
- itd-95Disembark Grounds A Lifeboat's Open Questions On A Repo's TODO And FIXME Markers
- itd-96Disembark Reads A Repo's Naming And Internals Conventions Into Its Lifeboat
- itd-105A fresh plugin install just works: the hook binary survives install and every update
- itd-108The plugin installs from the curated release artifact, not the repo, and every cut release reaches users automatically
- itd-110The grill interview renders with clear structure and colour instead of a wall of prose: each question visually separated, the decision point, options, and the recommended answer distinctly styled, progress through the design tree visible, so the person being grilled always knows what is being asked and where they are
- itd-113The MCP Front Door Opens — abcd's Core Verbs From Any MCP-Capable Harness
- itd-114Two Agents Can Mint At The Same Instant And Never Collide
- itd-115A Ready PR Merges Without Ever Wedging BEHIND
- itd-116Validated GitHub Issues Become Ledger Entries Without Retyping
- itd-118Merged work leaves no residue: abcd-managed repos delete a PR branch on merge, and abcd tidies the stale local branch, tracking ref, and worktree
- itd-119An Issue Graduates Into An Intent Without Retyping
- itd-120A Resolved Issue Points At What Fixed It
- itd-121Type The Id, Get Your Next Move
- itd-122The Registry Cannot Wave Its Hands
- itd-123The Intent Audit Says Audit
- itd-124The Conformance Check Calls Itself Lint
- itd-125The Lifeboat Verdict Says What It Is
- itd-134Every abcd-managed CLI greets like abcd does: one command scaffolds a banner for a managed repo, rendered from that repo's canonical identity block — name, tagline, version — as a committed, language-neutral artefact (the generator emits the rendered banner, not code), so a CLI in any language opens with its own identity without hand-drawing anything. Split out of itd-112 at its 2026-08-21 grill: itd-112 keeps abcd's own banner and the colour ladder; this intent carries the managed-repo generator and the per-repo accent question.
- itd-141docs-lint enforces the writing style guide's machine-checkable rules: an em dash inside a list item, a lower-case letter opening a list lead-in after its colon, and a capital letter after a semicolon are flagged as findings, with code spans and fenced blocks masked, so the canonical style guide's machine-enforceable subset is a shipped gate rather than a review habit — and the guide marks a rule machine-enforced only once its lint ships
- itd-142The brief-creation interview: abcd elicits a repository's brief in a staged conversation — narrative first, then frontier rounds that ask only what the record cannot yet settle, options at conjectural questions (at most three candidate construals, a ceiling not a target, with a null answer always available), and a per-item confirmation — distilling committed products into the brief and a ledger while the transcript is discarded. Entry is one door for both modes: a brownfield repository arrives pre-populated from embark probe coverage, provenance-stamped and still requiring confirmation; a greenfield repository is the same interview run from the all-blank coverage state. Command-shaped, because it mutates state — abcd ships zero skills
- itd-143The brief gains a framing chapter under 01-product/ — the macro-why home: one section holds the project's framing, the why behind the why, and receives the brief-creation interview's committed framing products; the brief-lifeboat mapping gains the matching row so a lifeboat carries framing like any other section
- itd-144Every livery mark has a surface and earns it: the duckling, the lifeboat, and the two-by-two signal-flag icon are placed deliberately across abcd's surfaces instead of sitting as generated-but-unused assets. The lifeboat mark renders when disembark finishes packing a lifeboat and mirrors when embark unpacks one, so the direction of travel reads at a glance; the duckling appears as the mascot wherever the harness greets a human; the icon becomes the website and app icon. Settles the forge/web logo question itd-112 deferred as 'the existing logo stays for now'. Follows itd-133, which shipped the marks deliberately unwired, and consumes itd-112's colour ladder and emission discipline rather than minting its own.
- itd-145An adopted idea cannot ship uncredited: abcd enforces its own acknowledgement convention mechanically, so a record that cites an external source, standard, or tool without a matching ACKNOWLEDGEMENTS entry fails the record gate and names what is missing. 'Credit in the same change that lands it' stops depending on the author remembering. Seeded by a real miss in this repo: the maritime signal-flag standard the livery logo encodes and the NO_COLOR convention the colour ladder implements both shipped before their credit landed, and nothing caught it.
- itd-149abcd handles inbound security advisories and issues, and cuts the release, for every managed repo. The 2026-08-27 security-advisory pilot proved the loop by hand across two independent operators: advisory and issue intake, recall-dedup triage against the ledger, record-first fixes in isolated worktrees, one integration branch, an independent adversarial gate over the assembled diff, auto-merge armed only after APPROVE, and a derived release cut through the semantic-receipt gates. This intent automates that loop as abcd capability for any managed repo, with findings F-A through F-W of the pilot note as the acceptance-criteria source and F-U (re-run every required pass against the final content commit; never transfer a verdict) and F-Q (the two release gates are human-by-design) load-bearing.
- itd-159the managed .gitignore visibility table has no mode for a public repo that commits its record: on abcd-cli (public, single-repo-curated-release, .abcd/** deliberately in-tree) ahoy install applied the public policy and fenced /.abcd/ and /memory/, contradicting the repo's own boundary that the record is present in every checkout. The visibility table needs a committed-record declaration (config or marker) that suppresses the fence
- itd-163A cited source always resolves and an adopted inspiration is always acknowledged: the reference-closure and acknowledgements-mirror gate
- itd-164A source is licence-vetted before the record may lean on it: cite refresh records the verdict, the gate reads the committed baseline
- itd-165A failed fidelity verdict becomes work somebody can see
- itd-167The product thinker answers a stop in a medium they already use, and answers it whenever they get to it
- itd-168The product thinker sets how the system talks to them, and the defaults are plain language and options to choose from
- itd-169An agent loop that stops says who it is asking and what it needs, and never simply halts
- itd-170What the product thinker reports after using the product finds its way back to the promise that predicted it
- itd-171A decision points back to the conversation where it was reached
- itd-172Every record has a short title and a one-line summary a non-engineer can read
- itd-173Verification escalates from the built-in check to an outside audit, and the product thinker picks the rung
- itd-174Each repository configures how far its facilitator is consulted and when it escalates
- itd-175The product thinker writes down how this could be wrong, and what would show it
- itd-176Whatever ships says how hard anyone looked at it
- itd-186The read-block eval falsifies the firewall — planted warm content that reaches a reading fails the build loudly
- itd-192An acceptance criterion whose producer does not exist is judged by whether this phase wires it, not by whether the narrowing was disclosed
- itd-2609090746410233A lifeboat packs from a worktree, a branch, or an abandoned feature test, experiment or implementation, not only from a whole repository
- itd-2609090746414083A lifeboat packs from a lab session home, the throwaway experiment's intention, harvest and bundle, with the same coverage honesty as a repository
- itd-2609150819439571abcd has no supported operation for correcting a factual error inside a durable record, and no documented convention saying what to do instead. The record is deliberately not rewritten, which is right, but "not rewritten" and "wrong" are different states and only the first has a mechanism.
- itd-2609150819440345Which session holds which worktree, branch or record is coordinated entirely by conversation, so every new session repeats a handshake that nothing records. A session joining work in progress has no way to ask what is already claimed: it messages the peers it can see, waits for replies, and rebuilds a picture that the sessions before it had already built and did not write down. One measured encounter cost four messages and about fifteen minutes before any work began, and the picture it produced is not durable, so the session after that pays again. The convention that a diff you did not make is a peer's work depends on knowing who the peers are and what they hold, which is precisely the thing no artefact carries. The repository already records this gap for the narrow case of detecting a peer session before mutating git state; the wider case is claim rather than presence, and the two want the same substrate. Whatever holds it should be as cheap to write as it is to read, because a coordination record nobody updates is worse than the chat it replaced.
- itd-2609151138388536Every Decision Is Its Own Record, and the Log Stops Conflicting
- itd-2609151516525843A Repository Can Ban A Name On Its First Commit, And A Machine Can Ban One Everywhere
- itd-2609151541116052During the peer-listing planning interview on 2026-09-20, the agent listed the rewritten acceptance criteria in prose and then asked, through the interactive question view, whether the criteria were the product thinker's. The prose was not on screen while the question showed, so the product thinker was asked to confirm text they could not see (iss-2609202058058301). A confirming question has to carry what it confirms.
- itd-2609151658486398A release cut publishes the security advisories its fixes close: when the release workflow cuts a version, every draft advisory whose fixing record shipped in that cut is published with the fixed version stamped and its opt-in credits, and an advisory whose record was closed as won't-fix is closed as not a vulnerability, so no fixed advisory sits unpublished after its release and no hand step decides which ones publish
- itd-2609151838327688An opt-in adapter to a local message broker brings push delivery and cross-machine reach to the session mailbox: with the adapter enabled a session is woken the moment a message arrives, machines on the local network exchange messages without a shared mount, and every delivered message is still mirrored to the mailbox as a record; without it the mailbox works as before
- itd-2609180517121254Every payload a host hands back from a delegated step names the model that produced it and the number of agents that ran, and the ingesting verb refuses one that does not
- itd-2609211116005482`abcd build next` picks the readiest planned intent itself, and writes down why
- itd-2609231507251267Release pages on the project website
- itd-2610031259176838Outside contributors reserve work through a draft pull request that abcd honours
- itd-2610031325050110abcd notices a harness update downloaded but not yet running
- itd-2610031651058674abcd's check reports README parts that have gone stale, and writes nothing
- itd-2610032150580455The dashboard from anywhere, through Tailscale
- itd-2610040740108331The dashboard on the home network, without Tailscale
- itd-2610040740122709Acting from the dashboard: rewriting the brief and approving intents
- itd-2610040740135705The dashboard for more people: the facilitator's view and the team's, configurable
- itd-2610040754440360The private dashboard for every abcd-managed project
- itd-2610040754453237The public record site for every abcd-managed project
- itd-2610040817105016Every brief section shows what realises it, and a brief change names what it touches
- itd-2610040822131032A lab runs end to end from a question the product thinker asks
- itd-2610050548126044abcd reminds a session to refresh its handover note only when that session changed the tree
- itd-2610052000411162Anyone can open, edit on their own device and submit the brief of a public abcd-managed project on abcdesign.app
- itd-2610052000424067A group works on one public project's brief together on abcdesign.app, adds notes, and exports the combined work
- itd-2610070544145422Someone on Windows installs abcd and it just works: the
- itd-2610070549060530A word in a new idea marks it to revisit, and the board puts it first
- itd-2610070550516046On the dashboard, a product thinker sees the brief and their ideas together, and puts the ideas in order
- itd-2610071545369520A person confirms the assistant's verdict on each warned banned-name line instead of judging it alone
- itd-2610071545380041Work about abcd itself goes to abcd as a report, never into a managed repository's own plans
- itd-2610100627454580An agent's text comes back from abcd's rewriter written for its reader and within its limits
- itd-2610100704270254An abcd run sets how many sub-agents it keeps alive by the models they run on
- itd-2610141646454347An ideate verdict proves its own legs
- itd-2610161647248332abcd finds out what the forge can do before choosing a route
- itd-2610161710315026Unattended runs reach only a declared list of hosts
- itd-2610161710316538Drains and builds a person's session drives report how isolated they were
- itd-2610161904178040People who think in Emacs can edit the brief with Emacs keys
- itd-2610171228577260A product thinker settles a visual design in rounds that abcd runs end to end
- itd-2610230856403803A build run's dependent lane cannot start until its predecessor has merged into the default branch: readiness reads a predecessor as landed only when its lane is done, its pull request an ancestor of the default branch, so a step that needs another waits a whole preflight and merge-queue cycle (about one to two and a half hours each on 2026-10-22) before it opens. Stacked changes are standard practice for dependent work (Graphite, Sapling and ghstack stacks, and merge queues taking a stack in order), and on 2026-10-22/23 that shape was rolled by hand twice: merge-gate steps 2 and 3, and model-matrix step 2 stacked on the route branch. Building it is more than a fix: the dependent lane's pull request is based on the predecessor's branch, the stack merges in order, and a lane rebases (and re-stamps what it resolved) when the predecessor changes.
- itd-2610240913343804No surprises: abcd says up front what it will do on its own and what it will ask
- itd-2610241015120503The person and the repository agree when abcd may merge, and what a cloud session may do
- itd-2610241331131356The session view reads live agent state from a workspace manager
- itd-2610262140595217abcd records how each preflight on a machine behaved
- itd-2610262141001890abcd adjusts how many preflights run at once from what it recorded
- itd-2610281253044600The status line says what each session is working on
- itd-2610300955026531Agents can work under a forge account of their own
- itd-2610300955031405A merge approval can require a security key touch
- itd-2610300955049260Approve a merge from the dashboard or a web app
- itd-2610301327282266abcd's help fits the screen it is read on
- itd-2611011151475128Every documentation surface is rendered from its one home
- itd-2611011151512956Hand-written text in a rendered page is caught and offered back to its source
- itd-2611011239589823A project's how-to guides and learning material stay current with the product
- itd-2611011333366788abcd resolves every layered setting through the shared
- itd-2611011813155166A repository switches an abcd verb or project gate off
- itd-2611011813162141A repository names a sequence of abcd steps a person runs
- itd-2611011813175068The product thinker approves a goal's scope once
- itd-2611012123486967Raising a spending cap needs the person's touch
- itd-2611012123505400Hosted CI reuses test results that cannot have changed
- itd-2611012200551577Every reading of git state goes through internal/gitutil
- spc-6issue-capture
- spc-7abcd-intent-quoted-text-create-symmetric
- spc-8epic-to-spec-terminology
- spc-12disembark-grounds-a-lifeboat-s-open-questions-on-a-repo-s-to