Development record
itd-21 files the starter intent as itd-1, an id the collision-proof minting invariant does not allocate
itd-21 files the starter intent as itd-1, an id the collision-proof minting invariant does not allocate
A premise contradiction (severity minor) found by the cross-document consistency pass.
- End A:
.abcd/development/intents/drafts/itd-21-no-lifeboat-scaffolding.md:32— "Starter intent (/abcd:intentinterview kicked off as last step) capturing the project's mission asitd-1" - End B:
.abcd/development/brief/02-constraints/03-invariants.md:159— "the mint never allocates by looking at the current maximum"
itd-21 ends its scaffold with an interview capturing the project's mission as itd-1. Invariant 11 says record ids are collision-proof by construction and the mint never allocates by looking at the current maximum. A fixed or next-ordinal itd-1 is neither, and two minters would both claim it, so the draft depends on an id the allocator does not produce.
Evidence: .abcd/work/reviews/2026-10-26-consistency/00-summary.md, finding 151.
Frontmatter
| id | iss-2610262031362851 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610262031362851-itd-21-files-the-starter-intent-as-itd-1.md
open on GitHub ↗ · commit history ↗
References1
- itd-21Start a New Project With abcd Conventionsrelated
mentions3
- 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.
- itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them