Cadora's AI-DLC method pack, step by step: cadora aidlc-init lays the rules and inputs into a workspace, the method structures work into three phases (inception, construction, operations) with deterministic gates and human-review gates between them, a phased topology declares phase/gate/review on each node, cadora run --hitl drives the phases and pauses at review gates, cadora aidlc-audit reads back the six-state checklist and the 68-event audit trail, and the stable aidlc pack sits beside the EXPERIMENTAL pinned aidlc-v2 pack whose installer strips upstream's provider and cost pins by default.

Cadora · AI-DLC method pack

The method the conductor drives and gates

AI-DLC is not a mode inside Cadora — it is an installable method: rules plus inputs that structure work into three phases. Cadora lays that method into a workspace, drives a phased topology through it, puts deterministic gates and human-review gates between the phases, and reads back a phase-by-phase audit trail. This is that method's journey, from an empty directory to an audited run.

Surface · CLI + phased topologyRole · operator / reviewerPacks · aidlc (v1.0.0) · aidlc-v2 (experimental)
01

Lay the method into a workspace

One command turns an empty directory into an AI-DLC workspace. Cadora installs the rules — the v1 pack vendored in cadora/aidlc_rules/ — as backend-native project memory: core-workflow.md becomes the executor's instruction file (CLAUDE.md for Claude Code, AGENTS.md for Codex), and the detailed per-stage rules land in .aidlc-rule-details/. Your inputsvision.md and the optional tech-env.md — sit beside them.

zsh — cadora aidlc-init
$ cadora aidlc-init myapp --vision vision.md --tech-env tech-env.md AI-DLC workspace ready at myapp (rules 1.0.0) installed: CLAUDE.md, .aidlc-rule-details/, vision.md, tech-env.md next: cadora run examples/aidlc.topology.yaml --executor claude --cwd myapp
myapp/ — what aidlc-init laid down
rulesCLAUDE.md  — AI-DLC core workflow, in a managed <!-- cadora:aidlc --> block
rules.aidlc-rule-details/{inception,construction,operations,common}/
inputvision.md  — your product vision (required)
inputtech-env.md  — technical environment (optional)

Pick the backend with --executor claude|codex|kiro — it only changes which instruction file the rules are written into. The method itself is identical across backends.

02

Three phases, gates between them

The method organizes work into inception → construction → operations — the three directories under .aidlc-rule-details/. Cadora's job is to sit between the phases: a review gate (a node marked review: true) pauses for a human before downstream work starts, and a build-test gate re-runs the real build and tests before a phase is allowed to count as done. The node ids below are the real ones from examples/aidlc-phased.topology.yaml.

localhost:8768/topology/aidlc-phased
phase · inception
requirementsreviewrole · requirements-analysis
designreviewrole · application-design
phase · construction
code-generationgate: build-testrole · code-generation
build-testgate: build-testrole · build-and-test
phase · operations
deploy / operate — the method's third phase (.aidlc-rule-details/operations/); nodes stay on --executor even when construction is routed elsewhere

A node's phase is more than a label: --construction-executor codex routes only the construction-phase nodes to a second backend, leaving inception and operations on --executor.

03

The topology declares the phases

The three-phase model is not hidden in Cadora — it is written in the topology you hand to cadora run. Each node carries a phase, a dependency edge, and — where the method wants a checkpoint — a gate or a review: true flag. Here is examples/aidlc-phased.topology.yaml, prompts elided.

examples/aidlc-phased.topology.yaml
name: aidlc-phased nodes: - id: requirements phase: inception role: requirements-analysis prompt: | # Read vision.md → requirements.md … review: true - id: design phase: inception role: application-design depends_on: [requirements] review: true - id: code-generation phase: construction role: code-generation depends_on: [design] gate: build-test - id: build-test phase: construction role: build-and-test depends_on: [code-generation] gate: build-test

The full per-stage lifecycle — seven inception stages, six construction stages, conditional self-skips — lives in examples/aidlc-stages.topology.yaml. The single-session shape is examples/aidlc.topology.yaml (one node, gate: build-test).

04

Drive it — and pause for review

One command installs the workspace and drives the phased topology through it. With --hitl, Cadora pauses at every review: true node — here requirements and design, both inception — and waits. requirements has finished and its documents are written; design is held at the gate; construction hasn't started. The operator approves, requests a same-stage revision, or aborts before any downstream work begins.

localhost:8768/runs/pr7-aidlc
pr7-aidlcaidlc-hitl · executor claude · 3 nodes
review · design
requirements
inceptionapproved
design
inceptionawaiting review
construction
gate: build-test
review gatedesign · inception — approve before construction starts
Application design written to aidlc-docs/inception/application-design/. Read it, then decide. A revision re-runs design only.
ApproveRequest changesAbortdecision recorded in design/human-review.md

Without --hitl the same topology runs autonomously end to end. Headless? --review-file writes cadora-review-request.json and polls for a decision file — any tool or human can drop it — and fails closed on --review-timeout.

05

Two packs: stable, and experimental

There are two method packs. aidlc is the default — the v1 rules, vendored and stable, with no network fetch. aidlc-v2 is a pinned upstream distribution and is honestly labelled EXPERIMENTAL: the default ref is a tag whose commit hash Cadora verifies after fetching, so a moved tag fails the install rather than silently shipping different code.

aidlc stable · default

  • v1 rules, vendored in cadora/aidlc_rules/core-workflow.md + rule-details/ + RULES_VERSION
  • Laid as CLAUDE.md / AGENTS.md + .aidlc-rule-details/
  • No network fetch; runs on the funding source you chose
  • Backends: claude · codex · kiro

aidlc-v2 experimental

  • Pinned upstream dist — default ref v2.1.7, commit verified after fetch
  • Strips provider/cost pins by default and records exactly what it stripped
  • Five remote MCP servers off unless --keep-mcp
  • GA preview with weekly churn; --executor claude only

Why strip the pins? Upstream's shipped .claude/settings.json silently re-points every session at metered AWS Bedrock on opus[1m] at effortLevel: xhigh — the most expensive configuration. Cadora's guarded installer removes those pins so your run stays on the funding source you picked, and prints exactly what it took out. --keep-provider-pins opts back in.

zsh — cadora aidlc-init --method aidlc-v2
$ cadora aidlc-init myapp-v2 --method aidlc-v2 --vision vision.md aidlc-v2 pack (EXPERIMENTAL) installed at myapp-v2 upstream: https://github.com/awslabs/aidlc-workflows@v2.1.7 (fde1e1af7aae) provider/cost pins stripped (recorded): model, effortLevel, CLAUDE_CODE_USE_BEDROCK, AWS_REGION (upstream default silently switches sessions to Bedrock at opus[1m]/xhigh; funding stays yours — restore with --keep-provider-pins) remote MCP servers NOT installed (opt in with --keep-mcp): 5 upstream servers install record: myapp-v2/.cadora-aidlc-v2.json next: cd myapp-v2 && claude then run /aidlc — inspect any time with: cadora aidlc-audit myapp-v2

Every strip is written to .cadora-aidlc-v2.json — the install record is itself part of the evidence, so "what did Cadora change about upstream?" has a file-level answer.

06

Read the phases back — an audit trail

Because the method writes its own state, Cadora can read it back. cadora aidlc-audit is read-only: it parses the v2 per-intent state file (aidlc-state.md, six-state checkboxes) and the append-only audit trail (audit/<host>-<clone>.md shards, a 68-event taxonomy with ISO timestamps) into one summary — the phase you're in, the stage roll-up, and the count of everything that happened.

zsh — cadora aidlc-audit
$ cadora aidlc-audit myapp-v2 aidlc-v2 intent: 2026-07-16-checkout-service (space: payments) phase=construction current=code-generation next=build-and-test status=in-progress stages: done=6 skipped=2 revising=0 awaiting-approval=1 in-progress=1 not-started=2 audit: 68 events · human_turns=7 · sensors fired/passed/failed=19/18/1 2026-07-16T14:22:07Z stage.approved requirements-analysis 2026-07-16T15:03:44Z gate.passed application-design 2026-07-16T16:41:12Z stage.started code-generation
aidlc-state.md — the six-state checklist the roll-up counts
[x]requirements-analysis  ·  done
[?]nfr-requirements  ·  awaiting-approval
[-]code-generation  ·  in-progress
[ ]build-and-test  ·  not-started
states: [x] done · [-] in-progress · [?] awaiting-approval · [R] revising · [S] skipped · [ ] not-started · pass --json for the full report

aidlc-audit reads the aidlc-v2 workspace's own state files — it is the read-back for the experimental pack. For a v1 run, the same evidence (nodes, gates, per-node cost, review decisions) is in the run archive that cadora report packs.

The frames above reproduce real cadora aidlc-init / run --hitl / aidlc-audit output and the actual node ids from examples/aidlc-phased.topology.yaml, rendered as editable HTML rather than raster captures — lift them into Figma or iterate directly. This is the method layer of Cadora: AI-DLC is installed as rules-plus-inputs, driven as a phased DAG, checkpointed by deterministic and human gates, and — for the experimental v2 pack — read back phase by phase from its own audit trail.