The big idea, in one paragraph

AI-DLC turns the AI from an assistant you consult into the primary actor that does the routine work, while people keep every decision. The whole method is one loop repeated for every activity: the AI drafts a plan, asks the questions the request did not answer, defers the decision to a person, and implements only after that person has approved. Everything the loop produces (plans, requirements, designs, decisions) is written into the project and kept with the code, so each phase hands the next one richer context and work can continue in any session. Three things make it different from “use an AI to write code”: the work is cut into units of work instead of epics, delivered in bolts of hours or days instead of sprints, and validated by the whole team at once (mob elaboration, mob construction) instead of by handoffs.

In everyday termsYou are renovating a house. The architect (AI) draws, asks, and waits for your signature before any wall moves; the plans and every signed page stay in a folder next to the house, so a new crew can pick up tomorrow where today stopped.

Twelve concepts follow. Each: what it is, why the method has it, how it shows up in the tool, an example, the analogy, and a one-line test that you have understood it. Sources are the AWS AI-DLC blog (Raja SP, 31 Jul 2025) and the AI-DLC Workflows v2.11 docs; OURS marks our team's conventions.

The two pictures

Intent

What it is

The piece of work you want done, stated as an outcome, in your words. In the tool an intent is also a thing: one tracked run with its own folder (the intent record) holding every artifact, decision and audit entry for that work.

Why AI-DLC has it

Traditional projects start from a requirements document or a ticket, both of which are already somebody's interpretation. AI-DLC starts from the intent and lets the AI do the interpreting out loud, as numbered requirements and explicit questions, so the interpretation is reviewed instead of assumed. Several intents can live side by side; each stays small enough to finish.

How it works in the tool

Your first /aidlc … creates the intent: the request is copied into project-description.json, the record folder intents/<YYMMDD>-<label>/ appears, and the first stage starts. /aidlc intent lists intents; /aidlc intent <name> switches; add-repo widens one until units are decided.

Example

“On the pending list, show how many business days each request has waited and flag anything over 5.” That sentence is the intent; 261013-request-age-api is the record.

In everyday termsOne renovation project with its own folder in the cabinet. The same house can have several folders open; each has a name and a date.

You've got it when You can say what the intent is in one sentence without naming a file, a screen or a table.

Don't confuse with: a workflow (one run through the stages for the intent) and a session (one conversation; a run spans many).

The five phases

What it is

Initialization bootstraps the folder. Ideation asks “is this worth doing, for whom, how big?”. Inception asks “what exactly is being built, and how is it sliced?”. Construction asks “how is it built in pieces a person can review?”. Operation asks “is it running, and is it getting better?”. The AWS method names three (Inception, Construction, Operations); the tool adds Initialization and Ideation in front.

Why AI-DLC has it

Each phase exists to give the next one richer context. Ideation prevents building the wrong thing; Inception prevents building the right thing badly or all at once; Construction prevents unreviewable change; Operation closes the loop so the next idea starts from evidence. Automatic checks at the three boundaries (1→2, 2→3, 3→4) confirm the previous phase left a complete, consistent trail.

How it works in the tool

Five phases, 33 stages. The status line shows the phase and the stage: [AIDLC] INCEPTION > Requirements Analysis [▓▓▓▓▓░░░░░] 1/2 -- product. Artifacts land in <record>/ideation/, inception/, construction/, operation/; the boundary checks in verification/phase-check-*.md. 4.7 is terminal and can loop back to 1.1.

Example

Express skips Ideation entirely (the requirement is already understood) and keeps two Inception stages, two Construction stages and three Operation stages: ten in all.

In everyday termsDeciding (is it worth it?), planning (what exactly, room by room?), building (one room at a time, each inspected), living in it (does it work, what next?).

You've got it when Given any stage number you can say which question its phase is answering.

Don't confuse with: stages: the 33 steps inside the phases.

Stages, and the lead agent

What it is

A stage is one of 33 numbered steps (1.1 … 4.7). Each has defined inputs, steps and outputs, a lead agent persona, and ends with an approval gate. Some are conditional and skip themselves (no UI, greenfield, solo team); scopes decide which run at all.

Why AI-DLC has it

Breaking the lifecycle into small named steps is what makes it repeatable and traceable: every artifact has a stage that produced it and a person who approved it. The tool deliberately uses a few broad agents (“small mob, broad agents”) rather than many narrow specialists, because narrow specialists recreate waterfall handoff chains; a broad agent keeps context across stages.

How it works in the tool

A stage announces itself, reads knowledge and prior artifacts, writes its files, and asks. Lead agents: product (1.1, 1.4, 2.3, 2.4), architect (1.3, 2.6, 2.7, 2.8, 3.1–3.3), developer (2.1 scan, 3.5), quality (3.6, 4.6), delivery (1.5, 1.7, 2.9), design (1.6, 2.5), pipeline-deploy (2.2, 3.7, 4.1, 4.3), aws-platform (3.4, 4.2), operations (4.4, 4.5, 4.7). /aidlc --stage <slug> jumps; --single runs one in isolation.

Example

2.3 Requirements Analysis: lead product; input the intent and the codekb; output requirements.md and requirements-analysis-questions.md; gate Approve / Request Changes.

In everyday termsOne meeting or one job with a named deliverable, run by the specialist whose job it is: the survey by the surveyor, the drawings by the architect, the first fix by the electrician.

You've got it when You can name the artifact a stage writes and who leads it without looking it up for 2.3, 2.7, 3.5 and 3.6.

Don't confuse with: a phase (a group of stages) and a gate (the question at a stage's end).

Approval gates and the plan → ask → defer loop

What it is

Every stage outside Initialization ends with a question only a person answers: (1) Approve (2) Request Changes. Your reply is recorded in your own words as an audit shard. Free-form replies count (“looks good”); an approval with an instruction both approves and applies it. After three revision rounds a third option appears: archive the current version and move on.

Why AI-DLC has it

This is the method's core loop made concrete: the AI plans and asks; the human decides; only then does the AI implement. Gates are where business context enters, where responsibility is attached to a name, and where “done” stops being the AI's opinion. They also make the record auditable: anyone can read who accepted what and why.

How it works in the tool

At every gate: 1, or 2 followed by what to change. The tool rewrites the artifact and asks the same question again. A few gates carry extra options: 1.7 Reject Initiative, 2.3 Add User Stories, 2.6 Add Units Generation, 2.7 Approve Plan / Revise Plan, 3.5 Approve Plan / Request Changes / I'll edit the files, 4.7 Start New Ideation Cycle. Unattended runs must say so explicitly (AIDLC_UNATTENDED=1); otherwise a human turn is required.

Example

“1 A: the received day is day 0, same as the report … (Ravi, Meena)” became A-01 confirmed in requirements.md and shard 0003-2-3-requirements-analysis.md; the later “2 The screen team already named the fields …” renamed them before any code existed.

In everyday termsThe owner signs each page before the next job starts; “not like that, move the sink” is written on the drawing and the architect brings it back redrawn.

You've got it when You stop reading gates as formalities: each one is a decision with your name on it, and 2 <why> is a normal, expected answer.

Don't confuse with: a verification gate (automatic, between phases) and a checkpoint (the per-unit gate in Construction).

Mob elaboration and mob construction

What it is

From the AWS method: in Inception the whole team validates the AI's questions and proposals together (mob elaboration); in Construction the team resolves technical and architectural choices as they arise (mob construction). The purpose is alignment: the team builds what it intends, not the AI's interpretation of it.

Why AI-DLC has it

Traditional refinement and design reviews are serial handoffs: a document travels between people and loses context at every hop. A mob puts everyone in front of the same AI proposal at the same moment, so objections surface once and decisions are made where the context is. It replaces a chain of meetings with a short, intense session.

How it works in the tool

The tool runs a mob as bounded rounds: the lead agent drafts; collaborator agents (design, developer, quality) respond blind; the lead integrates; one objection round; open judgment calls go to you. 2.4 User Stories is the shipped mob stage; /aidlc --collaborators on invites the support agents (lead-only is the v2.11 default). Contributions are kept under contributions/. The human mob is your team reading the proposal together at the gate.

Example

At 2.4 the product agent drafts the stories; the design agent adds accessibility and flow notes, the developer agent flags a missing API field, the quality agent asks how a story will be tested; the lead merges; Ravi and Meena answer the two open questions at the gate.

In everyday termsEveryone around the kitchen table with the plans: each trade marks up a copy, the architect merges, one round of objections, the owner settles what is left. Not a weekly meeting: one sitting.

You've got it when You can say what a mob changes compared with a review meeting: same proposal, same moment, bounded rounds, decisions recorded.

Don't confuse with: hub-and-spoke (a lead collects contributions, no objection round) and pipeline (links in sequence).

Units of work

What it is

An independently implementable piece of the solution, defined at 2.7 Units Generation: name, boundaries, responsibilities, deployment model (standalone, shared, embedded), size (S/M/L/XL) and kind (service, spec, ui, packaging, library). Units are listed in a dependency graph (an acyclic DAG) with their integration points, and every story or requirement maps to exactly one unit.

Why AI-DLC has it

In the AWS method units replace epics. An epic is a bucket of stories grouped by theme; a unit is cut by what can be built, tested and reviewed on its own, which is what an AI needs to do a bounded job and what a reviewer needs to approve one. The DAG makes order and parallelism explicit instead of discovering them in a sprint.

How it works in the tool

Per unit, Construction runs 3.1–3.5 (design stages as needed, then Code Generation with its plan, verification command and checkpoint). unit-of-work.md, unit-of-work-dependency.md, unit-of-work-story-map.md and traceability.json are the artifacts. Express runs no Units Generation: Code Generation runs once for the whole change (the engine reports “zero Units”). In multi-repo work a unit usually maps to one repo; team convention: one unit = one branch = one PR.

Example

The notification feature in the AWS worked example has three units in a chain: notification-core → notification-preferences → notification-email. The Gold Card run has five, one per repo: contracts, analytics, rules, api, web.

In everyday termsOne room's job that one crew can finish and you can inspect on its own: the kitchen, the bathroom. Not a wall, not the whole house. The plumber must finish before the tiler starts: that is the DAG.

You've got it when Given a feature you can cut it into two or three units and say which must come first and why.

Don't confuse with: a story (a wish, which maps into a unit) and a bolt (a time slice that may carry several units).

Bolts

What it is

A planned Construction delivery slice: one or more dependency-linked units with a definition of done and an expected demo, measured in hours or days. In the AWS method bolts replace sprints: “shorter, more intense work cycles measured in hours or days rather than weeks.”

Why AI-DLC has it

Sprints are sized for human coordination: two weeks to plan, build, test and demo. When the AI does the routine building, the limiting factor becomes human review, so the cycle shrinks to what a person can validate in a sitting. A bolt is that sitting with a visible result at the end. If your organisation keeps sprints, they become a reporting calendar, not the unit of work.

How it works in the tool

2.9 Delivery Planning writes bolt-plan.md: ordered bolts, units per bolt, the walking-skeleton marker, a definition of done and an expected demo per bolt, plus risk-and-sequencing-rationale.md. Runtime order still follows the dependency file; the bolt plan records grouping and rationale. In team (swarm) runs each bolt attempt gets its own worktree at .aidlc/worktrees/bolt-<id>_<slug>.

Example

Gold Card: bolt 1 = contracts + analytics (the skeleton, Mon–Tue), bolt 2 = rules + api (Wed–Thu), bolt 3 = web (Fri). Each ended with a demo a person could run.

In everyday termsA crew's working block with “done by Friday” written on it: a day or two, something you can see at the end. Not the office's two-week calendar.

You've got it when You can describe a bolt without the word sprint: what is in it, what done means, what is demoed.

Don't confuse with: a unit (a piece), a worktree (a folder), a sprint (a calendar, OURS).

The walking skeleton

What it is

The smallest working, integrated slice of the solution, planned as the first unit. It must pass a real end-to-end check with the recorded verification command and be approved by a person before later units begin. A design review alone does not count.

Why AI-DLC has it

Integration risk is the expensive risk: pieces that each work alone and fail together. Building the thinnest end-to-end path first proves the architecture, the contracts and the pipeline while there is little to throw away, and gives every later unit a working place to plug into.

How it works in the tool

2.9 marks the skeleton in bolt-plan.md; with skeleton mode on, Construction builds it first and the ladder prompt (Continue automatically / Review each checkpoint) is only offered after the skeleton checkpoint has passed. The checkpoint shows “Verified with <cmd> (exit 0)”.

Example

Notification example: “an event must reach stored notification data and in-app delivery”: no preferences, no email, but the path works. Gold Card: the contracts package plus one analytics field, consumed by one API endpoint.

In everyday termsFrame, roof, one pipe and one wire running end to end so water comes out of one tap, before any room is finished.

You've got it when You can name the thinnest path through your system that proves it is wired correctly.

Don't confuse with: a PoC (proves an idea; need not integrate) and an MVP (a product increment; much bigger).

Verification: command, checkpoint, matrix, phase checks

What it is

Four layers. The verification command: one project check proposed by the tool, approved by you once, run after every unit. The checkpoint: the per-unit approval that arrives with that command's exit code. The Target Verification Matrix (3.6): which test proves which requirement. The phase checks: automatic traceability checks at the three phase boundaries.

Why AI-DLC has it

“Done” has to mean something the AI cannot assert. Approving a command once and running it every time makes done objective; the matrix makes coverage visible per requirement; the phase checks make sure nothing was skipped or orphaned between phases. Together they replace the trust you would otherwise have to place in the AI's own report.

How it works in the tool

Command: in scopes with units, proposed at 2.9 or at the start of Construction, written to verification-command.txt, authorised only by your Approve. Express has no units, so no per-unit command or checkpoint: the 3.5 plan names the project's own test command and Code Generation runs it before its gate. Checkpoint: “Verified with ./scripts/verify.sh (exit 0) (1) Approve (2) Request Changes”. Matrix: construction/build-and-test/test-results.md. Phase checks: verification/phase-check-<phase>.md; on failure the conductor reports and asks whether to proceed or go back. Minimal test strategy means about one test per requirement; Standard 5–8 per component; Comprehensive 10–15.

Example

Hello-world run (express, no units): Claude ran ./scripts/verify.sh before and after writing the code (3, then 10 tests) and only then asked the Code Generation question; at 3.6 every row FR1 … NFR1 passed and cross-unit-traceability.md said PASS.

In everyday termsOne agreed pressure test run after every room; a snagging list that names which test covers which wish; the building inspector's visit between chapters.

You've got it when You can say what the verification command is for your repo and why its exit code, not a sentence, is the proof.

Don't confuse with: a sensor (automatic check on file writes) and a reviewer (an opinion).

Branches and pull requests: the team's steps

What it is

How a run's code reaches main: a branch, a commit, a pull request, a review and a merge. AI-DLC has no stage for any of it, in any scope. A run ends with code committed where the repo is checked out and a record on disk; the push, the PR and the merge are your team's. Your workspace's CLAUDE.md decides the shape, typically one unit = one branch = one PR.

Why AI-DLC has it

It deliberately doesn't. Teams already have a review process, branch protection and a merge policy, and the method plugs into them instead of replacing them. What it adds is evidence for the reviewer: a code summary that names the intent, the requirements and the verification result, and a record that says who approved what. The PR review is still a person reading code; AI-DLC's gates come before it, not instead of it.

How it works in the tool

Per unit, in a scope with units: (1) the 3.5 plan names the branch and stops for plan approval; (2) Claude makes the branch, writes the code and tests, runs the team's verify script and commits, because CLAUDE.md says so; (3) the unit checkpoint: the engine runs the approved verification command itself and asks “Approve this completed <unit>?”; (4) a person pushes and opens the PR, with construction/<unit>/code-generation/code-summary.md as its description; (5) review and merge, by AI-DLC's default in memory/org.md trunk-based with squash-merge. Three units, three loops, three PRs. Express has no units: one branch, one PR, with the 3.5 and 3.6 gates in place of the checkpoint. The engine makes branches itself only in swarm mode: one worktree per unit on a bolt-<id8>_<slug> branch, merged back locally with no PR.

Example

Hello-world run (express): Claude made request-age/u1-age-api from its plan and committed the code; Kiran pushed and ran gh pr create --body-file …/code-summary.md; Meena reviewed PR #58 and merged it at 11:02, after the run was complete. A feature-scope run of the next request would give three units and three PRs, the third waiting for the first two to merge.

In everyday termsThe kitchen plates each course and the chef signs it off; carrying it to the table is the house's job. The menu never mentions the waiter; the house rules do.

You've got it when You can point to the file in your workspace that says how many PRs a run makes and what their branches are called, and say which steps of the loop are the engine's and which are people's.

Don't confuse with: a gate or checkpoint (the method's approval, recorded in the audit), a bolt (a planned slice, not a branch), a worktree (a folder, swarm mode only), and the tool's claim / publish / land (several people sharing one unit, not a PR).

Context accumulation: the record, state, audit, codekb, knowledge, memory

What it is

Everything the loop produces is written to disk and reused: the intent record (artifacts), the state file (where the run is), the audit trail (every decision, with names), the codekb (what the tool learned by reading the code), knowledge (documents you handed over) and memory (rules the team taught the tool). The AWS method calls this context that lives with the code and grows phase by phase.

Why AI-DLC has it

Chat is a bad place for context: it scrolls away, it is compacted, it belongs to one person. Files next to the code survive sessions, are shared through git, and can be read by the next person or the next run. Each phase inherits richer context than the last, which is what lets the AI make fewer wrong assumptions as the work proceeds.

How it works in the tool

aidlc/spaces/<space>/ holds memory/, knowledge/, codekb/<repo>/ and intents/<id>/ with aidlc-state.md, audit/, verification-command.txt and the phase folders. Resume with /aidlc from any session; compaction is survived by the record plus a recovery breadcrumb. Commit memory/, knowledge/, codekb/**, intents.json, every record; ignore the per-user cursors and runtime scratch.

Example

Yesterday's Python run and today's Java run share nothing in chat, but both read the same holiday rule from docs-in/, and the Java run's 2.1 wrote a fresh codekb/priorauth-api/ the next intent will reuse.

In everyday termsThe folder in the cabinet, the survey of the house, the deeds you handed over, and the house rules the crew has learned. The notebook (chat) can be lost; the cabinet cannot.

You've got it when You can point to the file that answers “where is the run?”, “who approved this?” and “what does the tool know about this repo?”.

Don't confuse with: knowledge (yours) vs memory (rules) vs codekb (the tool's reading of the code).

Scope, depth and test strategy: right-sizing the ceremony

What it is

Scope (workflow profile) decides which of the 33 stages run: express 10, bugfix 9, poc 8, refactor 10, security-patch 10, infra 13, classic 18, mvp 23, workshop 26, feature and enterprise 33. Depth decides how long the artifacts are (minimal, standard, comprehensive). Test strategy decides how many tests (minimal, standard, comprehensive). You choose it by naming it in the command (/aidlc express …), which starts the run without a scope question; without a name, AI-DLC infers one from your request.

Why AI-DLC has it

A method that always runs 33 stages would be ignored for small work. Profiles let the same method shrink to a two-hour bug fix or grow to an audited enterprise feature without changing its shape: the same gates, the same record, fewer or more stages. Conditional stages also skip themselves when their condition does not apply.

How it works in the tool

/aidlc express …, /aidlc feature …, or describe the work and confirm the proposal. Change later with /aidlc --scope, --depth, --test-strategy; add a skipped stage back with /aidlc --stage <slug>. The composer (/aidlc compose "<task>") proposes a tailored plan when no profile fits. Without a name, the keywords decide: "fix" gives bugfix and "CVE" gives security-patch, but most requests fall back to classic (18 stages), so name the scope. All eleven side by side, and what compose proposed for a real bug: Choosing a scope.

Example

Ravi's request was understood and the repo small → express, Minimal depth, Minimal tests: one-page requirements, six tests, under an hour and a half. The Gold Card feature across five repos → feature, Standard, all 33.

In everyday termsFixing a tap, fitting a kitchen, or adding an extension with permits: same architect, same signatures, different amount of paperwork.

You've got it when You can choose a profile for three different requests and justify each in one sentence.

Don't confuse with: depth vs test strategy: documents vs tests.

Operation: the loop closes

What it is

Deploying is part of the lifecycle, not an afterthought: pipeline and rollback (4.1), environments (4.2), the deployment itself with smoke tests and health checks (4.3), observability (4.4), runbooks and incident plans (4.5), performance validation (4.6), and a feedback loop with SLO and cost reports (4.7) whose insights can start a new Ideation cycle.

Why AI-DLC has it

The AWS method puts Operations inside the method so that evidence from production, not opinion, drives the next intent. Every Operation stage is conditional and the whole phase is skipped for mvp and poc, so small or exploratory work is not burdened with it.

How it works in the tool

The tool writes the strategy, the log and the alarms; you press your pipeline's buttons and paste the results. 4.7 is terminal: Approve completes the workflow; Start New Ideation Cycle feeds feedback-loop.md into a new 1.1.

Example

Hello-world Java run: all three skipped. The workspace had no pipeline, container or deploy config, so 4.1, 4.3 and 4.4 found nothing to work on; Claude said so, the engine recorded each skip, and nobody was asked. A workspace that holds the pipeline config or a deploy runbook gives them something to plan, run and watch.

In everyday termsPutting the dish on the menu, the smoke alarm you install and the one you decide not to, and the monthly look at what to change next.

You've got it when You can say which Operation artifacts a one-service change needs and which it does not.

Don't confuse with: a CI pipeline (3.7, Construction) vs a deployment pipeline (4.1, Operation).

What changes for people

What it is

The AWS method says product owners, architects and developers each finish their tasks faster, and developers shift from routine coding to problem solving while gaining business context. In the tool the AI personas carry the routine of each stage; the people own the decisions at the gates, the mob sessions, the verification command, the pipeline buttons and the team conventions the tool does not define (branches, PRs, work tracking).

Why AI-DLC has it

If the AI drafts and builds, the scarce resource becomes judgment: knowing the business, choosing between trade-offs, saying no. The method is designed so that this judgment is exercised often, early and visibly, instead of once at the end in a review.

How it works in the tool

Product owner: answers the questions at 2.3 and 2.4, approves scope and stories. Architect / tech lead: 2.6 decisions, 2.7 units, 2.8 contracts, the 3.5 plans, the checkpoints. Developer: runs the session, reads the code, owns branches and PRs, decides retry / skip / abort on failure. QA: the verification command, the matrix at 3.6, 4.6. Everyone: the mob.

Example

In the hello-world runs Kiran typed every answer, but Ravi decided day-0 and the no-alerting rule, and Meena approved every artifact. The audit shards carry their names, not Kiran's.

In everyday termsThe architect draws; the owner decides; the trades build; the inspector checks; the site manager keeps everyone in order. Nobody's job disappears; the drawing and the digging get faster.

You've got it when You can say, for your own team, who answers which gate.

Don't confuse with: agents (AI personas) vs roles (people).

Traditional → AI-DLC

You used to have	In AI-DLC
Product requirements document	Intent + `requirements.md` (numbered FRs, NFRs, assumptions, out of scope) with explicit open questions
Epic	Unit of work (cut by what can be built and reviewed alone, with a dependency graph)
Story	Story (2.4), mapped to exactly one unit; our Rally stories are created from `stories.md`
Sprint	Bolt (hours or days, definition of done, expected demo); a sprint becomes a reporting calendar
Backlog refinement meeting	Mob elaboration (one sitting over the AI's proposal, bounded rounds, decisions recorded)
Design review	Mob construction (choices resolved as they arise) and the 3.5 plan approval
Definition of done	The verification command exits 0 and a named person approves the checkpoint
Status meeting / board	`aidlc-state.md` (position) and `audit/` (decisions); `/aidlc --status`
Architecture decision record	`decisions.md` in the record (we copy accepted ADRs into each repo's `docs/adr/`)
Test plan	Test strategy level + the Target Verification Matrix in `test-results.md`
Retrospective	The learning loop (stage diaries promoted to rules) and 4.7 Feedback & Optimization
Onboarding document	`codekb/<repo>/` (written by 2.1, reused by every run) plus the knowledge folder

Common misunderstandings

“AI-DLC commits the code and opens the PR.”It writes files where the repo is checked out and stops. Branches, commits, pull requests and merges are your team's steps; the tool's own team mechanism (claim / publish / land) is for several people on one unit.

“A bolt is a short sprint.”A bolt is a delivery slice of dependency-linked units with a definition of done and a demo, measured in hours or days. It is not a calendar; the dependency graph, not the bolt, decides runtime order.

“A unit is a story.”A story is a wish; a unit is a piece of the solution that can be built, tested and reviewed on its own. Several stories map into one unit.

“Express skips testing.”Express runs Minimal test strategy (about one test per requirement) and still runs the project's test command before the Code Generation gate, and the matrix at 3.6.

“Approve is a formality.”Each gate is recorded with the approver's words and name. Request Changes is the normal way to steer; after three rounds you may archive and move on, which is also recorded.

“Mob means another meeting.”A mob is one sitting over one proposal with bounded rounds; the output is a decided artifact, not minutes.

“The chat is the record.”The record is the folder under aidlc/. The chat is compacted and private; the folder is committed and shared.

“Reverse engineering reruns every time.”The codekb lives under the space; later intents reuse it unless you ask for a rescan.

Check yourself

Answer, then open.

1. Ravi asks for the age column on the API too. Is that a new intent or a new unit of the old one?

A new intent: it is a separate outcome with its own record (the old one is complete). A unit is a piece inside one intent.

2. Which stage turns “weekends don't count” into something a test can check, and what is the artifact?

2.3 Requirements Analysis: FR1.1 in requirements.md.

3. What must be true before the checkpoint question is even asked?

The approved verification command ran and exited 0; the question shows “Verified with <cmd> (exit 0)”.

4. Three units: contracts → api → web. Which is the walking skeleton and why?

contracts plus the thinnest api path that uses it: the first integrated slice that proves the wiring end to end.

5. Where do you look to know who approved the requirements and what they said?

The audit shard for 2.3 under audit/, in their words.

6. Your organisation runs two-week sprints. What are they in AI-DLC terms?

A reporting calendar. The unit of delivery is the bolt (hours or days); bolts can be mirrored to iterations for reporting.

7. What does 2 at a gate do?

Request Changes: your comment is recorded, the artifact is rewritten, the same gate is asked again.

8. Which three things are automatic (no person asked) in a run?

Initialization, the phase boundary checks, and sensors (and the reviewer's verdict, which advises). Everything else ends at a gate.

Sources

The AWS whitepaper “AI-DLC Method Definition” is referenced by secondary sources but was not reachable from here; nothing on this page relies on it. Definitions are paraphrases; the analogies and the OURS lines are ours.