Skip to content

Glossary

Canonical definitions for AI-DLC terminology. All documentation in the User Guide and Developer Reference uses these terms consistently.

Term Definition
Agent One of the 14 shipped personas: 11 domain experts, 2 review-only agents, and the adaptive-workflows composer. The conductor activates each for its specialized stage, review, or composition role.
Approval gate An interactive checkpoint at the end of each stage where you choose to approve the work, request changes, or (after 3 revisions) accept as-is. Initialization stages skip approval gates.
Autonomy mode The setting recorded in aidlc-state.md (Construction Autonomy Mode) after the walking-skeleton ladder prompt. Either autonomous or gated; it defaults to unset. On the default stage-major walk, gated retains stage-level human gates while autonomous skips the remaining Construction stage gates (except halt-and-ask on Code Generation failure and the Build-and-Test loop-back rung 4) and enables eligible swarm routing. Opt-in Construction Iteration: unit-major suppresses the autonomous swarm but retains the per-stage gate cascade: one human approval per stage after the (stage × Unit) grid settles.
Bolt A sprint-like Construction iteration over one or more dependency-linked Units, distinct from the Unit definition, its worktree, and the swarm that may schedule it. Delivery Planning (2.9) records the intended grouping, Definition of Done, confidence hypothesis, and ownership. The default stage-major runtime interleaves these iterations and does not consume bolt-plan.md as a grouping or ordering boundary. Stages 3.6 (Build and Test) and 3.7 (CI Pipeline) run once after all Bolts complete, not per-Bolt. See also: [parallel batch], [walking skeleton], [ladder prompt].
Artifact A versioned markdown document produced by a stage and stored in the intent's record dir (aidlc/spaces/<space>/intents/<YYMMDD>-<label>/). Examples: requirements.md, code-summary.md, initiative-brief.md.
Audit trail The append-only event log in the intent's record dir at audit/, written as per-clone shards (<host>-<clone>.md) that readers glob and merge by timestamp. Records 91 event types with ISO timestamps for full traceability from intent to production.
CLI tool An external command-line utility required by this implementation (bun is the only runtime prerequisite). Not to be confused with Claude Code tools.
Claude Code tool A built-in Claude Code capability such as Read, Write, Edit, Bash, Glob, Grep, Task, or AskUserQuestion. Agents inherit the full session toolset by default; an optional tools: allowlist can narrow it, and disallowedTools: Task is the one shipped restriction.
Codex The OpenAI Codex CLI harness — one of AI-DLC's harness distributions today. Source builds generate its ignored local projection from core/ + harness/codex/ into dist/codex/; releases carry it under runtime/codex/. Invoked with $aidlc. See AI-DLC on Codex CLI.
Command A user-facing invocation of AI-DLC. Harness chat commands use /aidlc (or $aidlc on Codex) for workflows; the native aidlc command provides project, diagnostic, plugin, and machine-lifecycle routes.
Compaction Claude Code's automatic process of summarizing earlier conversation context when the context window fills up. This implementation preserves state across compaction via aidlc-state.md and .aidlc-recovery.md.
Conductor The /aidlc session itself (SKILL.md), running a thin forwarding loop: it calls the Engine for the next move, carries it out (running a stage, asking you a question, fanning out a swarm), reports the outcome, and repeats. It owns execution quality, not routing. See Engine and Skill System.
Control loop The feedforward/feedback pairing of Rules (standing decisions applied before work) and Sensors (deterministic checks fired on outputs) that steers and verifies a stage. (Distinct from a Harness, the CLI distribution sense; the two were once both called "harness".)
Copy channel A manual project installation from a versioned release's aidlc-runtime-X.Y.Z.tar.gz, copying a complete runtime/<harness>/ root. Framework developers may separately generate the Bun-shaped, ignored local dist/<harness>/ projection from source.
Core The hand-authored, harness-neutral source of truth at core/ — the engine, stages, agents, rules, scopes, sensors, knowledge, hooks, and session skills. Every harness distribution is generated from it; you edit here, never in dist/.
Cursor The Cursor harness (cursor.com) — one of AI-DLC's harness distributions today. Source builds generate its ignored local projection from core/ + harness/cursor/ into dist/cursor/; releases carry it under runtime/cursor/. One tree serves both the Cursor IDE and the Cursor CLI (agent); the 14 personas are native subagents in .cursor/agents/, and the orchestrator, runners, and utility shortcuts are native skills in .cursor/skills/. Because Cursor does not expand @-imports, .cursor/rules/aidlc.mdc points to standing method layers and four aidlc-phase-*.mdc rules point to phase layers. Invoked with /aidlc, with /aidlc-status, /aidlc-jump, and /aidlc-scope shortcuts. See AI-DLC on Cursor.
Depth One of three detail levels (Minimal, Standard, Comprehensive) that controls how much detail each stage produces. Scopes have default depths; you can override at any approval gate. See Scopes, Depth, and Test Strategy.
Directive The typed instruction the Engine emits on each next (e.g. run-stage, ask, print, done, invoke-swarm) telling the Conductor exactly what to do next. See Engine and Skill System.
Distribution A generated projection for one harness, produced from the Core by the Packager. Source builds materialize ignored local dist/claude/, dist/codex/, dist/copilot/, dist/cursor/, dist/kiro/, dist/kiro-ide/, and dist/opencode/ trees plus native dist-release/<harness>/ counterparts; releases carry those native projections under runtime/<harness>/ in aidlc-runtime-X.Y.Z.tar.gz. Maintainers never hand-edit generated outputs.
Engine The deterministic orchestration tool (aidlc-orchestrate.ts, with exactly five subcommands: next, continue, report, park, and team-board; continue is internal steering transport and team-board is the read-only Team Construction query) that owns all between-stage routing — scope resolution, stage sequencing, jumps, resume, gate status — and emits a typed Directive the Conductor acts on. See Engine and Skill System.
External tool A third-party tool or service used by a stage (e.g., AWS CLI, Maven, npm). Distinguished from Claude Code tools.
Guardrail The body sections inside a Rule file (## Forbidden, ## Mandated, and the phase-rule guardrail headings) that express prescriptive behavioural constraints. The container is a Rule; "guardrail" names the prescriptive content within it. See Rule.
Harness A CLI distribution of the AI-DLC core — one capable command-line agent that the harness-neutral Core is rendered onto. The set is open and growable (today: Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, GitHub Copilot). Note — "harness" carries four senses in this repo, by context: (1) this canonical CLI-distribution sense; (2) the rule+sensor control loop (older usage, now renamed — see Control loop); (3) the harness/<name>/ source-surface directory; (4) the tests/harness/ test-helper directory. Only sense 1 is "a harness" in user docs.
Hook A TypeScript script that Claude Code runs automatically in response to events. This implementation uses 17 hooks, all registered project-wide in settings.json: the workflow spine (audit logging, sensor dispatch, runtime-graph compile, statusline sync, token-usage folding, state validation on compaction, subagent tracking, loop enforcement on turn-end) plus session lifecycle, human-turn mint, exact dispatch-rule delivery, state-transition, reviewer-scope, review-freeze, and plan-approval guards, and the statusline command. Each self-gates, no-opping when no workflow is active.
Inline execution The default execution mode where the orchestrator loads an agent persona and executes the stage directly in conversation. Supports real-time user interaction.
Intent A unit of work tracked as a row in the space's intents.json registry ({uuid, slug, dirName, scope, repos, status}), with its own [Record dir] at aidlc/spaces/<space>/intents/<YYMMDD>-<label>/. The <YYMMDD> is a compact UTC date prefix (e.g. 260624 = 2026-06-24) so records sort chronologically, and <label> is a short kebab-case essence of the request; a same-day same-label collision resolves with a numeric counter (-2, -3, ...). The canonical, collision-proof id is the time-ordered UUIDv7 stored in the registry row, not the dir suffix. The engine auto-creates the first intent on your first /aidlc; an explicit selector or per-session binding selects it before the shared active-intent cursor. See Space, Record dir.
Kiro The Kiro harness — one of AI-DLC's harness distributions today. Source builds generate ignored local projections at dist/kiro/ (CLI) and dist/kiro-ide/ (IDE); releases carry them under runtime/. The AIDLC method is read from aidlc/spaces/<active-space>/memory/ through CLI agent resources or IDE always-included steering live references. Invoked with /aidlc. See Running AI-DLC on Kiro IDE and Running AI-DLC on Kiro CLI.
Knowledge Reference material loaded by agents at stage start. Two tiers: methodology knowledge (ships with the framework in .claude/knowledge/) and team knowledge (user-managed, space-level domain knowledge at aidlc/spaces/<space>/knowledge/ — free-form, empty at bootstrap, shared across every intent in the space).
Ladder prompt The single prompt shown after the walking-skeleton gate asking you to choose "continue autonomously" or "gate every Bolt". Your choice is recorded as the autonomy mode and governs the rest of Construction.
Learning loop The v0.5.0 mechanism that turns in-stage corrections into durable practices and Sensors. During a stage the orchestrator records observations in memory.md; at the approval gate it surfaces them, you confirm which to keep, and each confirmed learning is written as a practice in aidlc/spaces/<active-space>/memory/project.md (one-click promote to team.md) — or scaffolds a new Sensor — so it applies on the next workflow. See Rules and the Learning Loop.
Lifecycle The AI-DLC methodology as a whole: the AI-Driven Development Life Cycle. A single execution of the methodology is a workflow. The public native surface is config, doctor, version, update, use, and uninstall.
Machine lifecycle command A native aidlc route that manages per-user releases or configuration. It always runs from the active binary rather than following a project's .aidlc-version pin, and it does not mutate project workflow data.
Manifest A harness's harness/<name>/manifest.ts — the declarative contract telling the Packager how to project the Core into that harness's Distribution (dir map, rules rename, authored files, the optional emit plugin). Adding a harness is mostly writing one manifest.
MCP server An external tool server declared in .mcp.json at the project root (beside .claude/) and provisioned to the Claude Code session. This implementation ships five: context7 plus the four AWS servers (aws-mcp, aws-pricing, aws-iac, aws-serverless). Every agent inherits all session MCP servers — there is no per-agent grant; an agent is prevented from using one by narrowing its tools: allowlist to specific mcp__<server>__<tool> ids. A server you have no credentials for is simply unavailable and never blocks a workflow. See Harness Primitives Mapping — MCP Servers and Getting Started.
memory.md The per-stage observation diary at <record>/<phase>/<stage>/memory.md (under the intent's record dir), created by the engine when it emits the run-stage directive and maintained by the orchestrator (never hand-edited). Records Interpretations, Deviations, Tradeoffs, and Open questions; it is the input the learning loop reads at the approval gate.
Mob execution A dispatched mesh (mode: mob) in bounded rounds. The lead drafts, mutually blind collaborators write contribution files in parallel, the lead integrates, and unresolved judgment calls may go to the human. User Stories (2.4) is the shipped mob.
Multi-repo intent An intent whose work spans more than one sibling code repo. The repo set is captured at creation — explicitly via --repos a,b or by sibling auto-discovery (every immediate child of the workspace root holding a .git) — and stored in the intent's intents.json row as repos. Construction anchors each git op to a specific repo via --repo <name>; an intent with no recorded repos is the legacy single-repo case (git runs in the project dir). See Artifacts Reference.
Native channel The recommended per-user installation path: a native aidlc binary plus version-matched harness runtimes under a machine versions directory. Its installer and project bootstrap do not require Bun, Node.js, or Git. Alpine musl hosts first install Bun's and Node.js's shared runtime prerequisite with apk add libgcc libstdc++.
Offline package The release asset set transferred intact for installation without network access. It contains the platform binaries, runtime payload, installers, version.json, checksums.txt, and the aidlc-release.intoto.jsonl provenance bundle.
opencode The opencode harness (opencode.ai) — one of AI-DLC's harness distributions today. Source builds generate its ignored local projection from core/ + harness/opencode/ into dist/opencode/; releases carry it under runtime/opencode/. The engine tree ships at .aidlc/ (opencode auto-imports .opencode/tools/*.ts as custom tools, so the engine cannot live there); .opencode/ carries only the native shell (subagents, the /aidlc command, the hook-adapter plugin), and the AIDLC method is read via the instructions glob in the project-root opencode.json. Invoked with /aidlc. See AI-DLC on opencode.
GitHub Copilot The GitHub Copilot harness — one of AI-DLC's harness distributions today. Source builds generate its ignored local projection from core/ + harness/copilot/ into dist/copilot/; releases carry it under runtime/copilot/. ONE install serves both Copilot surfaces (Copilot CLI and VS Code agent mode — they read the same project files). The engine tree ships at .aidlc/; .github/ carries only aidlc-named native emissions (the hook wiring hooks/aidlc.json, the persona custom agents, the skills tree), merged into your repo's .github/ rather than replacing it; the AIDLC method is read via @-import lines in the project-root AGENTS.md. Invoked with /aidlc. See AI-DLC on GitHub Copilot.
Orchestrator Umbrella term for how a workflow is driven: the deterministic Engine that decides what happens next and the Conductor (SKILL.md) that carries it out. Invoked via /aidlc. See Engine and Skill System.
Packager scripts/package.ts — the build that materializes every ignored local dist/<harness>/, dist-release/<harness>/, and plugin projection from the Core + each Manifest. bun scripts/package.ts builds all; --check builds twice in independent temporary roots and byte-compares the results as the CI determinism guard.
Parallel batch A runtime group of dependency-ready Units from unit-of-work-dependency.md (2.7) that do not depend on each other and can run concurrently. A runtime batch is not a Bolt-plan grouping. Under an autonomous swarm the engine converges every DAG batch and then presents one Code Generation stage gate — not one gate per intermediate batch; SWARM_COMPLETED closes each runtime batch.
Pipeline execution A dispatched chain (mode: pipeline) whose links run in declared order, each seeing all upstream work; every return mints a durable current-attempt receipt, and the final link leaves the artifacts complete. Reverse Engineering (2.1) is the shipped pipeline and requires one complete receipt chain per registered repo.
Phase One of the 5 major divisions of the lifecycle: Initialization (0), Ideation (1), Inception (2), Construction (3), Operation (4). Each phase contains 3-9 stages (Initialization 3, Ideation 7, Inception 9, Construction 7, Operation 7).
Phase boundary verification Automated traceability checks that run at phase transitions to catch missing links, orphaned artifacts, or inconsistencies before downstream stages build on them.
Plane One of the three concerns the framework separates, borrowed from networking architecture: the control plane (stage definitions, Rules, Sensors — the schema of what should run, resolved at compile time), the data plane (the actual stage runs, Bolts, and audit telemetry), and the management plane (/aidlc --doctor, audit queries, CLAUDE.md). See Rules and the Learning Loop for the user-facing orientation and docs/reference/02-plane-architecture.md for the full model.
Project pin The committed .aidlc-version strict-semver file selecting a retained native engine for engine commands. aidlc config --pin validates the complete binary and matching project harness, records a machine-local resolved target, and registers the pin in pins.json so the release is protected from pruning. The stable command launcher starts the active integrity-checking dispatcher, which validates and selects the pinned runtime before project operations run.
Projection stamp Generated tools/data/aidlc-stamp.json identity recording a projected tree's framework version, distribution, and harness directory. Startup and doctor use it to detect version skew.
Record dir The per-intent directory holding one intent's artifacts, per-stage memory.md diaries, aidlc-state.md, and audit/ shards: aidlc/spaces/<space>/intents/<YYMMDD>-<label>/ (written <record>/). Each intent gets its own; an explicit selector or per-session binding wins before the shared active-intent pointer. See Space, Intent.
Recovery breadcrumb The hidden file .aidlc-recovery.md written by the PreCompact hook. Contains the last validated stage and timestamp for detecting state corruption after compaction.
Refresh baseline Init-owned tools/data/aidlc-manifest.json, recording hashes of framework-owned files and typed root contributions. aidlc config uses it to classify refresh actions, detect local edits, remove retired owned content safely, and preserve project-owned data.
Release channel See Native channel. Release payloads are assembled from freshly regenerated local dist-release/<harness>/ projections, authenticated with TLS and SHA-256, and provenance-attested by the release workflow.
Retained version A complete native binary, release manifest, and zero or more harness runtimes stored side by side under the per-user versions directory. Active, rollback, and registered pinned versions are protected from pruning.
Root integration A project-root file contribution reconciled by aidlc config under a declared policy: managed block, JSON map, JSON array, or whole file. Ownership is explicit and unrelated project content is preserved or causes a conflict.
Reviewer A quality-gate agent — aidlc-product-lead-agent (requirements/stories/mockups) or aidlc-architecture-reviewer-agent (technical design) — invoked as a separate sub-agent after a stage body produces its artifacts, when the stage declares reviewer: plus an explicit required Markdown review_artifact:. It appends one owned ## Review verdict (READY / NOT-READY) only to that artifact; request-time artifact/source fingerprints, strict Verdict/Reviewer/Iteration fields, and a stable completion snapshot prevent changed work from being certified. On an adversarial NOT-READY the builder re-runs, looping up to reviewer_max_iterations (default 2) before presenting unresolved findings at the human approval gate. Reviewers run under a hard turn budget (maxTurns: 60 on Claude Code, steps: 60 on opencode, prose elsewhere); an incomplete review retries once, then records terminal NOT-READY. It never blocks — the human always decides. See Agents.
Rule A persistent behavioural rule authored once in the active-space memory layer (aidlc/spaces/<active-space>/memory/) at the workspace root and pulled into context by each harness's native include (Claude @-import stub, Kiro CLI resources or IDE steering, Codex AIDLC_RULES_DIR, opencode instructions glob, Copilot AGENTS.md @-imports), applied to every stage it covers. Rules resolve through a strict-additive five-layer chain — org → team → project → phase → stage — where every applicable rule appears in context; broader layers are never overridden, only added to. Rules are the feedforward half of the control loop and may pair with a Sensor for deterministic verification. See Rules and the Learning Loop.
Runtime graph The per-workflow runtime-graph.json artefact in the intent's record dir: a data-plane mirror of the structural stage graph, materialised from the audit log on every approval gate. Records which stages ran, which Bolts forked, which Sensors fired, and the memory.md entry counts — the queryable execution view doctor and the learning loop read.
Scope One of 11 named configurations (enterprise, feature, mvp, poc, bugfix, refactor, infra, security-patch, classic, workshop, express) that determines which stages execute and at what depth. Can also be auto-detected from freeform intent.
Sensor A deterministic verification check defined by a manifest in .claude/sensors/ (e.g., aidlc-linter.md, aidlc-type-check.md). Sensors run on matching Write/Edit calls or once per existing deliverable at the approval gate and record SENSOR_* audit rows. Gate-fired bindings may be advisory or blocking; blocking findings require correction or an explicit audited override. A stage declares which Sensors fire via its sensors: frontmatter list. Sensors are the feedback half of the control loop; Rules are the feedforward half. See Rules and the Learning Loop.
Test strategy One of three test volume levels (Minimal, Standard, Comprehensive) that controls how many tests are generated and which test types are included. Independent of depth and defaults to the active depth unless a scope declares an override. See Scopes, Depth, and Test Strategy.
Transaction A project or machine mutation staged on the destination filesystem, checked against expected live state, and committed with atomic renames. Failed commits roll back; unrecoverable evidence is retained in a doctor-reported .aidlc-recovery-* quarantine.
Session A single Claude Code conversation in which you run /aidlc. A workflow may span multiple sessions via the resume mechanism.
Skill A Claude Code primitive: a markdown file with YAML frontmatter that registers a slash command. AI-DLC's orchestrator is implemented as the /aidlc skill. In user-facing documentation, prefer "command" over "skill".
Space A per-team workspace at aidlc/spaces/<space>/ holding its own memory/, knowledge/, and intent records (intents/). An explicit selector or per-session binding wins before the gitignored aidlc/active-space pointer, which defaults to default; single-team users only ever see spaces/default/. See Intent, Knowledge.
Stage One of the 33 discrete steps in the lifecycle. Each stage has a lead agent, defined inputs/outputs, and follows the stage protocol. Stages are numbered by phase (e.g., 1.1, 2.4, 3.5).
State file The persistent per-intent workflow state at aidlc/spaces/<space>/intents/<YYMMDD>-<label>/aidlc-state.md (under the intent's record dir). Tracks stage progress, scope, workspace context, and session resume information using six-state checkboxes ([ ] / [-] / [?] / [R] / [x] / [S]).
Subagent execution A dispatched hub (mode: subagent) where the conductor invokes a separate agent context through the harness's dispatch tool. Code Generation (3.5) is a focused one-agent run. Practices Discovery (2.2) is hub-and-spoke: lead draft, three mutually blind support contributions, human interview, then lead integration.
Unit of work The WHAT: an independently implementable piece of the solution, decomposed during stage 2.7 (Units Generation) and listed in unit-of-work-dependency.md. One or more dependency-linked Units supply the scope of a Bolt.
Walk order Separate from the Bolt plan. Default = stage-major (a stage runs for every Unit, then the next stage). Opt-in = Construction Iteration: unit-major (a Unit runs through every per-unit stage, then the next Unit). Runtime batches come from unit-of-work-dependency.md (2.7); bolt-plan.md is the planning artifact. Walking-skeleton stance resolves org.md → team.md → project.md (most-specific non-empty statement wins).
Walking skeleton The planned first Bolt — the thinnest end-to-end slice that exercises every integration point. Always gated and interactive. Under the default stage-major walk, the shipped gate is the first in-scope Construction EXECUTE stage. The ladder prompt fires immediately after approval.
Utility command A terminal flag passed to /aidlc such as --status, --config, --doctor, --version, --stage, --phase, or --scope. These perform a specific query, configuration change, or navigation operation without running a workflow stage.
Worktree The git isolation mechanism used when a Bolt runs under autonomous swarm mode. The worktree and its bolt-<slug> branch host that Bolt's execution; neither is the Bolt itself or the swarm batch.
Workflow A single end-to-end execution of the AI-DLC lifecycle, from /aidlc invocation through stage completion. Scoped to a specific task (feature, bugfix, etc.).
Workflow profile The User Guide's name for a scope: a curated lifecycle for a kind of work, such as Classic, Express, Feature, or Bugfix. The selected profile determines the stage route and defaults stored as Scope in aidlc-state.md. See Workflow Profiles.