Intents Promote In Three Flavours — Standalone, Bundle-Member, Discipline

Re-scoped on 2026-09-21 by the product thinker: the three kinds, the disciplines/ shelf and the two-way supersession link this record described have shipped through other records; what remains, and what this record now plans, is the bundle command and the reclassify verb. The press release and scope below are read through this paragraph and the Decisions section.

Press Release

abcd ships three intent kinds, each with its own lifecycle path through /abcd:intent plan. A standalone intent maps 1:1 to a flow-next spec — the default for ~60% of intents, and the only path the prior brief recognised. A bundle-member intent shares a spec with its bundle-mates: the persona runs /abcd:intent plan itd-A itd-B, abcd creates one shared spec with both intents listed, and both files move from drafts/ to planned/ together. A discipline intent has no persona moment of its own — it's a cross-cutting rule (every spec must carry acceptance criteria, every agent prompt must declare a version) that lives in disciplines/ instead of drafts/, never gets its own spec, but applies to every other spec as an inherited acceptance gate. Capture stays format-neutral; the binding kind field is set at plan time, with an oracle classifier writing an advisory hint at capture time. The discipline shape is voyage-agnostic — an application voyage (e.g., a macOS app under abcd) produces its own disciplines around privacy-impact review or accessibility passes with the same lifecycle as abcd's own discipline intents.

"I had an intent that didn't fit the standard mould — it was a rule about every future spec, not a feature being built — and I'd been forcing it through the press-release format anyway, ending up with prose that read awkwardly because there was no real persona moment to describe," said Iris, product lead. "The discipline kind let me write ## Rule instead of ## Press Release and have the system understand what it was looking at. Two of my intents reclassified from standalone to discipline; the lifecycle paths matched the actual shape of the work for the first time."

Why This Matters

The original abcd intent system treated every intent as a 1:1 capability that maps to one flow-next spec. An audit-driven corpus sweep surfaced a structural finding: ~40% of intents have non-1:1 relationships with at least one other intent. Three patterns recurred:

1. Coupled intents — two or more intents that capture distinct user moments but only make sense delivered together. The original canonical example was itd-31 (cross-document fidelity review) and itd-32 (audit-role taxonomy) — but that bundle was dissolved on 2026-05-07 when the round-2 command-structure review split the three review roles into three distinct verbs under /abcd:intent (review/consistency/shape), making itd-32's unified-/abcd:audit-surface taxonomy premise no longer load-bearing. itd-31 promoted to standalone; itd-32 superseded. The pattern itself is still real (coupled intents that ship together as one shared spec exist in the corpus), but it has no live example in the current corpus.
2. Subsuming intents — one intent whose value is fully covered by another, larger intent. itd-5 (prompt-quality additions) and itd-14 (prompt registry) are the canonical example: itd-5 carves off a cheaper subset of itd-14. Shipping both means writing prompt-version handling twice.
3. Cross-cutting rules — itd-1 (acceptance gates) and itd-5 are not features at all. They are rules that apply to every other spec. Forcing them into the standalone-spec mould produces a "spec" whose only deliverable is "every other spec inherits this gate" — which is not a spec.

The 1:1 model fits cleanly only for the standalone ~60%. The other 40% calcifies into wrong shapes — bundles ship as separately-planned epics that retrofit onto each other; disciplines get press-release shaped despite having no user moment; supersession is implicit and lossy.

This intent introduces the three kinds as first-class lifecycle paths. Most intents stay standalone — the default doesn't change. Bundle-member and discipline are escape hatches for the shapes the standalone path doesn't fit. Capture stays cheap and format-neutral; the kind decision happens at plan time, when the user is committing to build the thing — that's where the shape decision has to be true.

The change is also project-agnostic. abcd is the loud first user of disciplines because abcd is a methodology project (its outputs include rules), but the pattern generalises. An idelphiDev intent like "every recording feature must include a privacy-impact review" is structurally identical to itd-1 — a rule that applies to every other spec — and naturally fits the discipline kind. The three kinds are a property of the intent framework, not of abcd's particular subject matter.

What's In Scope

Three intent kinds

• kind: standalone — one press-release-shaped user moment, ships as one spec. Default; ~60% of the corpus. Lives in drafts/ → planned/ → shipped/. No change from the original 1:1 behaviour.
• kind: bundle-member — multiple intents that share underlying delivery. Each member has its own press release (each captures a distinct user moment); they share an epic_id and a bundle: <bundle-id> frontmatter field. /abcd:intent plan <itd-A> <itd-B> is the multi-arg promotion path. Members move together (drafts/ → planned/ → shipped/); audit runs per-member against the same delivered reality.
• kind: discipline — cross-cutting rule with no user moment. Lives in disciplines/ instead of drafts/. Never gets a flow-next spec; instead imposes acceptance gates that every other spec inherits and is checked against. Uses ## Rule + ## Why template instead of ## Press Release. kind_notes free-text field describes what kind of rule it is (subtype taxonomy deferred — see "Discipline subtypes are deferred" below).

Lifecycle paths

/abcd:intent plan proposes a kind based on the intent body, cross-references, and any suggested_kind hint from capture time. The user confirms or overrides; the chosen value is binding once written to frontmatter.

• Standalone: today's path. /flow-next:plan + plan-review; bidirectional link; drafts/ → planned/.
• Bundle-member: multi-arg /abcd:intent plan itd-A itd-B. /flow-next:plan once with all intents as joint input; epic.intent: [itd-A, itd-B]; each intent's epic_id: spc-N and bundle: <bundle-id>; all members drafts/ → planned/ together.
• Discipline: no /flow-next:plan call. Registers acceptance gates in .abcd/disciplines/<itd-N>.json. /flow-next:plan-review runs on the discipline's ## Rule for sanity (catches malformed rules). drafts/ → disciplines/ (active state encoded by directory location; no status: field per the 2026-05-08 directive — see brief 04-surfaces/05-intent.md § 5). No ship step — disciplines are continuously active once in disciplines/.

/abcd:intent reclassify subcommand

For late kind changes (a standalone intent realised to be a bundle-member; a draft realised to be a discipline; a shipped intent superseded by a later one):

• /abcd:intent reclassify <itd-N> --kind <new-kind> [--reason <text>]
• Records reclassification_history entry (date + from-kind + to-kind + reason) in the intent's frontmatter
• Moves the file between directories as the new kind dictates
• --kind superseded --by <itd-M> is the supersession path: file moves to superseded/; frontmatter records superseded_by: itd-M; preserved as historical record

Frontmatter additions

All intent files gain four new fields:

suggested_kind: null    # advisory, written by capture-time LLM classifier; can be ignored
bundle: null            # for kind: bundle-member, the bundle ID
reclassification_history: []   # appended to by /abcd:intent reclassify

Discipline-kind intents additionally use kind_notes: "<free-text>" describing what kind of rule they are. Disciplines have no status field — the directory IS the state (disciplines/ = active; superseded/ = retired). Across all kinds, directory location is the single source of truth for lifecycle state; status fields would duplicate (and risk drifting from) what the directory already says.

Supersession captures original kind

When /abcd:intent reclassify <itd-N> --kind superseded --by <itd-M> runs, the intent's frontmatter records two fields:

superseded_by: itd-M               # the successor intent
kind_at_supersession: <original>   # what the intent was when retired:
                                   #   standalone | bundle-member | discipline

Both are required (lint hard-blocks if either is missing). The reason: "superseded" means different things depending on what the intent was. A superseded standalone is a retired capability. A superseded bundle-member is a retired half of a coupled pair. A superseded discipline is a retired rule that was inherited by every other spec. Without kind_at_supersession, future archaeology has to reconstruct the original shape from reclassification_history (which exists but is harder to query).

intent-fidelity-reviewer shape-classification role (third role)

The same agent that performs single-document fidelity audits (per the itd-1 discipline) and cross-document fidelity audits (per itd-48, which superseded itd-31) gains a third role: shape classification. It runs continuously via the pre-commit hook (writing findings to the latest report) and on-demand via /abcd:intent shape. Bare /abcd:intent (status+help) surfaces the latest cached shape suggestions in its summary output without itself running a fresh scan — bare invocation never mutates the report. Findings live at .abcd/logbook/audit/shape-<ts>/report.{json,md}. Specific suggestions:

• Bundle candidate: "intents X and Y reference each other in scope/references and target the same release; consider kind: bundle-member with shared bundle ID."
• Supersession candidate: "intent X's scope is fully covered by intent Y; consider kind: superseded --by Y."
• Discipline candidate: "intent X has no user moment in its press release (the customer quote describes a process, not a feature); consider kind: discipline."

The user accepts a suggestion via /abcd:intent reclassify. Declined suggestions are logged so the reviewer doesn't re-surface the same one every run.

The agent count in the catalog stays at 15 — these three roles share one agent's prompt scaffolding, oracle backend resolution, and receipts.

Discipline subtypes are deferred

The brief introduces the discipline kind itself; it deliberately does not commit to a closed enum of discipline subtypes (e.g., methodology / documentation / audit / convention). Each discipline declares a free-text kind_notes field describing what kind of rule it is. The subtype taxonomy moves from free-text to formal enum when ANY of the following:

1. Three or more disciplines exist with kind_notes describing similar shapes.
2. A user is confused about which existing discipline a finding belongs to.
3. intent-fidelity-reviewer's shape-classification role cannot describe a proposed discipline without more constraint than kind_notes provides.
4. Cross-project usage — once abcd is in three or more projects, comparing disciplines across them needs a shared subtype vocabulary.

This mirrors the lint-code namespace pattern in 05-internals/06-lint.md — categories added empirically as intents introduce them, not declared up front.

New directories

• intents/disciplines/ — active discipline-kind intents (created alongside this intent)
• intents/superseded/ — intents killed by reclassification or absorption (currently empty)

Reclassification of two existing intents

itd-1 (acceptance gates) and itd-5 (prompt-quality additions) are reclassified from kind: standalone to kind: discipline. Their press-release sections are replaced with ## Rule + ## Why (the press-release format requires a user moment, which disciplines do not have). Files move from drafts/ to disciplines/. Each gains a reclassification_history entry recording the reclassification.

Brief edits

• 01-product/03-mental-model.md — three-layer model gains the three intent kinds under "Intents."
• 04-surfaces/05-intent.md — § 1 grows kinds + discipline format + subtype-deferred revisit triggers; § 2 subcommands table adds reclassify and multi-arg plan; § 5 lint rules extend to verify kind, bundle:, and directory matching; § 6 documents the reviewer's three roles.
• 05-internals/01-agents.md — intent-fidelity-reviewer row condensed; new "three roles" sub-section.

What's Out of Scope

• Mandating bundle-member or discipline kinds for any specific intent. The kinds are available; the user (with the LLM classifier's advice) chooses. abcd never auto-reclassifies without user confirmation.
• A closed enum of discipline subtypes. Deferred per the revisit triggers above.
• Cross-bundle dependency tracking ("bundle X must ship before bundle Y"). Out of scope; bundles are a delivery shape, not a dependency graph.
• Auto-merging coupled intents at capture time. The LLM classifier proposes; the user binds at plan time. The framework never silently merges intents.
• A fourth kind for some hypothetical case the three kinds don't cover. If a fourth kind is needed, it lands as a future intent, not this one. Lineage update (itd-44; amended 2026-09-26, iss-239): the standing-infrastructure-choice case the three kinds don't fit is drafted as itd-44 — and not as a fourth persisted kind. itd-44 proposes a fourth capture-time verdict, decision, that would route a confirmed standing choice into the existing ADR store (adr-N); it is a draft with no live spec, and nothing in the binary implements the verdict (its thin-adoption design was ratified against spc-56 of the predecessor store, not the live spc-56). The persisted kind enum here stays three-valued, and there is deliberately no intents/decisions/ lifecycle.
• Migrating disciplines into the brief itself. Disciplines live in intents/disciplines/ so they have the same lifecycle, lint, and frontmatter discipline as other intents. Folding them into the brief would lose the lifecycle handling. The brief describes the discipline kind in its mental-model and intent-surface sections; the discipline files themselves stay under intents/.

Mechanism

We expect a reclassify verb to end the hand moves that leave one-way supersession links and mismatched kinds, because the two-way write and the shelf move become one command whose refusals name what is missing; shown wrong if superseded records still arrive with a missing back-link after it ships.

Scope Conditions

None stated.

Acceptance Criteria

• Given two draft intents, when abcd intent plan itd-A itd-B runs, then it asks for a bundle name, mints one shared spec naming both, writes kind: bundle-member and bundle: <name> on each, and moves both to planned/ together; a draft that names the other in blocked_by is refused naming the edge (a bundle cannot contain its own blocker), and nothing moves.
• Given a bundle's shared spec is closed, when the close-hook runs, then every member with that bundle: ships together.
• Given abcd intent reclassify <itd-N> --kind <standalone|bundle-member> or --kind superseded --by <itd-M|adr-N> --reason "…", when it runs, then the record's kind, shelf and links change in one write, with superseded_by on the record and supersedes on the successor written together; a shipped intent asked to become a discipline is refused and told to file a discipline that supersedes it.
• Given one member of a bundle is superseded, when the reclassify completes, then the surviving member stays bundle-member and its record states that the bundle now has one member.
• Given the record lint runs, when a planned intent's kind does not match its shelf, or a bundle-member names a bundle whose other members do not exist, then the lint refuses naming the record.

Dependencies

• Coordinated with: the itd-1 discipline — itd-1 is the first intent reclassified to kind: discipline under this framework. itd-1's content rewrite and itd-34's lifecycle changes ship in the same brief revision.
• Coordinated with: the itd-5 discipline — second discipline reclassified.
• Coordinated with: itd-48 — itd-48 owns the cross-document role (Role 2) and the shape-classification role (Role 3) on intent-fidelity-reviewer, superseding itd-31 which originally introduced the cross-document concept. The agent's three-role architecture is documented uniformly across the brief and intent surfaces.
• Coordinated with: itd-48 (cross-document role) and [itd-34's own shape-classification role] — these are the second and third roles on intent-fidelity-reviewer (the first being single-document fidelity per itd-1). Each role has its own user-facing verb under /abcd:intent (consistency, shape, review respectively). The earlier tier-0-audit-substrate bundle (itd-31 + itd-32) was dissolved on 2026-05-07 when the unified-/abcd:audit-surface premise no longer held; itd-31 promoted to standalone (later superseded by itd-48 on 2026-05-27), itd-32 superseded. An even earlier attempted bundle (intent-capture-discipline, itd-27 + itd-30) was retired on the same day because itd-27 and itd-30 are scoped to different phases — bundles cannot span phases (one shared spec shipped together is the invariant). Both intent-capture intents reclassified to standalone.

Decisions

Ruled by the product thinker on 2026-09-21, in the interview that gave this intent its spec:

1. Both remainders are built: the bundle command and the reclassify verb.
2. You name the bundle; the command asks for a short name.
3. A survivor stays. When one member is superseded the other stays a bundle-member of a bundle of one, and says so.
4. A shipped intent never changes kind. A rule discovered after the fact is filed as a discipline that supersedes it.
5. No phase rule (ruled 2026-09-21, adr-2609212115255771): phases are retired, so the same-phase invariant this record carried is replaced by the blocker check above.

Noted on 2026-09-26, not a ruling: row 1 of the closed spec spc-2609211859391533's steps table ("bundle plan, named, refused across phases") predates decision 5 and is left as written; it means refused across shelves.

Open Questions

None open; decisions 2 to 4 settle the three this record carried.

Audit Notes

Fidelity review — receipt rcp-03d2e3b295e8 (verifier intent-auditor claude-fable-5-1).

Provenance: intent-auditor@claude-fable-5-1 · rubric_hash sha256:effa65b3e9e88ff29433b443ec2be159522a8b0b71cf1434526514aa61edb13e · prompt_hash sha256:fffb8fec06cee1e4ff5bd2c1aab90e8fa48c762816ffcae3ee131aef637e1524 Input attestations: diff:f91708205..4ce401c5f (internal/core/intent/{bundle,reclassify}.go, internal/core/intent/lifecycle.go, internal/core/lint/schema_bundle.go, internal/core/spec, internal/surface/cli/cli.go, commands/intent.md at BASE 4ce401c5; tree 376356ce669156f45b423eb7858a952ffeb0f9d6)@-;

Acceptance rollup: MET 4 · MET_WITH_CONCERNS 1 · NOT_MET 0 · INCONCLUSIVE 0

Per-criterion verdicts:

• ac-1 — MET_WITH_CONCERNS: PlanBundle mints one shared spec listing every member, stamps kind: bundle-member and bundle: < name>, moves all under the mint lock, and refuseBundleBlocker refuses a member naming another in blocked_by naming the edge with nothing moved (tests at bundle_test.go:61,95,124 green); concern: the CLI does not ASK for the bundle name, it refuses without --bundle, and the ask is delegated to the plugin page's interview text, as spc-2609211859391533 scope 1 records evidence: internal/core/intent/bundle.go:82 — "PlanBundle plans several drafts as one bundle (criterion 1)" evidence: internal/core/intent/bundle.go:264 — "a bundle cannot contain its own blocker, since its members ship together — plan %s first, or drop the edge (nothing moved)" evidence: internal/surface/cli/cli.go:2200 — "several intents are planned as one bundle, and --bundle < name> names it; re-run with --bundle (nothing moved)" evidence: commands/intent.md:384 — "Ask the human for the bundle's name" evidence: internal/core/intent/bundle_test.go:61 — "TestPlanBundleMintsOneSharedSpecAndMovesBothMembers" evidence: internal/core/intent/bundle_test.go:95 — "TestPlanBundleRefusesAMemberBlockedByAnother" evidence: internal/core/intent/bundle_test.go:124 — "TestPlanBundleRefusalMovesNothing"
• ac-2 — MET: Reconcile dispatches a spec carrying bundle: and an intents: list to reconcileBundle, which ships every member whose bundle matches together and rolls every move back on a failure; TestReconcileShipsEveryBundleMemberTogether and TestSpecCloseShipsABundleCLI green evidence: internal/core/intent/lifecycle.go:766 — "if sp.Bundle != "" && len(sp.Intents) > 0 { return reconcileBundle(" evidence: internal/core/intent/bundle.go:398 — "reconcileBundle is Reconcile for a bundle's shared spec (criterion 2)" evidence: internal/core/intent/bundle.go:593 — "if it.Bundle != sp.Bundle { skipped = append(skipped, it.ID)" evidence: internal/core/intent/bundle_test.go:189 — "TestReconcileShipsEveryBundleMemberTogether" evidence: internal/surface/cli/intent_bundle_cli_test.go:105 — "TestSpecCloseShipsABundleCLI"
• ac-3 — MET: Reclassify runs under the intent mint lock, sets kind and shelf, writes superseded_by on the record and appends supersedes on the successor (intent or ADR) as pending writes applied together with rollback, and refuses --kind discipline on a shipped record with the file-a-discipline-that-supersedes-it remedy; tests at reclassify_test.go:30,70,93,112 green evidence: internal/core/intent/reclassify.go:340 — "recFields := map[string]string{"superseded_by": succID, "kind_at_supersession": kindAt, "kind": kindAt}" evidence: internal/core/intent/reclassify.go:368 — "appendFrontmatterListItem(string(succData), "supersedes", it.ID)" evidence: internal/core/intent/reclassify.go:152 — "a shipped intent never changes kind; a rule found after the fact is filed as a new discipline — file a discipline that supersedes it" evidence: internal/core/intent/reclassify_test.go:30 — "TestReclassifySupersededWritesBothDirectionsAndMoves" evidence: internal/core/intent/reclassify_test.go:70 — "TestReclassifySupersededByAnADRAppendsToItsList" evidence: internal/core/intent/reclassify_test.go:93 — "TestReclassifyRefusesAShippedIntentBecomingADiscipline" evidence: internal/surface/cli/cli.go:2481 — "reclassify < itd-N> --kind < standalone|bundle-member --bundle < name>|superseded --by < itd-M|adr-N> --reason"
• ac-4 — MET: supersede finds the lone other member and appends a reclassification_history line 'bundle < name> now has one member' keeping its kind bundle-member; TestReclassifySupersedingABundleMemberLeavesASurvivorThatSaysSo asserts both evidence: internal/core/intent/reclassify.go:380 — "line := intentbundle.OneMember(it.Bundle) + ": " + it.ID + " was superseded by " + succID" evidence: internal/core/intent/reclassify.go:381 — "historyEntry(date, KindBundleMember, KindBundleMember, line)" evidence: internal/core/intent/reclassify_test.go:200 — "TestReclassifySupersedingABundleMemberLeavesASurvivorThatSaysSo" evidence: internal/core/intent/reclassify_test.go:226 — "the survivor's record must state the bundle now has one member"
• ac-5 — MET: intent_lifecycle refuses a planned or shipped kind other than standalone/bundle-member and a disciplines/ record not of kind discipline, and record_schema's checkIntentBundles refuses a bundle-member whose bundle no other record names unless its history says it now has one member; both tests green evidence: internal/core/lint/lint.go:2214 — "planned: kind must be standalone or bundle-member (non-null)" evidence: internal/core/lint/schema_bundle.go:67 — "bundle-member names bundle '" + name + "', which no other record names and whose history does not say it now has one member" evidence: internal/core/lint/schema_bundle_test.go:11 — "TestRecordSchemaBundleMemberNamesABundleOthersName" evidence: internal/core/lint/schema_bundle_test.go:73 — "TestIntentLifecycleRefusesAKindThatDoesNotMatchItsShelf"

Gap audit:

• honoured:
  • multi-arg plan mints one shared spec and moves every member drafts/ to planned/ together, refusing a member that names another in blocked_by evidence: internal/core/intent/bundle.go:82 — "PlanBundle plans several drafts as one bundle" evidence: internal/core/intent/bundle_test.go:61 — "TestPlanBundleMintsOneSharedSpecAndMovesBothMembers"
  • a bundle's members ship together on the shared spec's close evidence: internal/core/intent/lifecycle.go:766 — "return reconcileBundle("
  • reclassify writes the two-way supersession link in one command and moves the shelf evidence: internal/core/intent/reclassify.go:368 — "appendFrontmatterListItem(string(succData), "supersedes", it.ID)"
  • a shipped intent never changes kind (decision 4) evidence: internal/core/intent/reclassify.go:152 — "a shipped intent never changes kind"
  • a survivor stays a bundle-member of a bundle of one and says so (decision 3) evidence: internal/core/intent/reclassify.go:380 — "intentbundle.OneMember(it.Bundle)"
  • lint refuses a kind off its shelf and a bundle-member naming a bundle nobody else names evidence: internal/core/lint/schema_bundle.go:31 — "func checkIntentBundles(" evidence: internal/core/lint/lint.go:2214 — "planned: kind must be standalone or bundle-member"
  • both verbs reachable from the CLI and the plugin page evidence: internal/surface/cli/cli.go:2194 — "plan < itd-N> [< itd-N>…] [--bundle < name>]" evidence: commands/intent.md:390 — "intent plan < itd-A> < itd-B> [< itd-C>…] --bundle < name>"
• diverged:
  • the command 'asks for a bundle name': the CLI refuses without --bundle rather than prompting, and the ask lives in the plugin page's interview text, as the spec's scope 1 records evidence: internal/surface/cli/cli.go:2200 — "re-run with --bundle (nothing moved)" evidence: commands/intent.md:384 — "Ask the human for the bundle's name"
  • the press release's capture-time kind classifier, disciplines/< itd-N>.json gate registry and shape-classification role are read through the 2026-09-21 re-scope, which limits this record's remainder to the bundle command and reclassify; they are not part of this delivery evidence: .abcd/development/intents/shipped/itd-34-three-intent-kinds.md:15 — "what remains, and what this record now plans, is the bundle command and the reclassify verb"
• missing: (none)

References

• brief/01-product/03-mental-model.md — three intent kinds in the three-layer model.
• brief/04-surfaces/05-intent.md — § 1 (kinds + discipline format + revisit triggers); § 2 (subcommands including reclassify and multi-arg plan); § 5 (lint rules); § 6 (reviewer's three roles).
• brief/05-internals/01-agents.md — intent-fidelity-reviewer's three roles documented; agent count stays 15.
• README.md — top-level "What is intent-driven development?" section gains a paragraph on the three kinds; /abcd:intent planned-commands table gains reclassify and multi-arg plan rows.
• 2026-05-07 audit conversation that surfaced the structural finding: ~40% of intents have non-1:1 relationships with at least one other intent.
• The discipline-kind framing is consistent across project types (framework projects produce more disciplines than application projects, but both produce some). Cross-project taxonomy revisit: see "Discipline subtypes are deferred" above.

Grounds

• pursued: the autonomous run supersedes and re-plans records unattended and has no verb to do it with; we expect the reclassify verb and the bundle command to be what it calls, and the hand moves with their one-way links to stop; shown wrong if a record superseded after this ships still carries a one-way link, or if the run never calls either