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 A decision over completed work: a stage, verified Unit, or completed swarm batch. Human-required gates wait for your actual answer. Checkpoint-enabled workflows may automatically approve ordinary completion under a recorded grant; Plan Approval, enabled summary confirmation, verification command selection, and skeleton approval remain human decisions. Summary confirmation applies only when directive.ceremony.summary_confirmation === "on". Initialization and completion-only bookkeeping do not add human approval questions.
Autonomy mode The explicit approval preference stored as Construction Autonomy Mode: unset, gated, or autonomous. In eligible checkpoint workflows, “Continue automatically” records autonomous and “Review each checkpoint” records gated; this controls ordinary completion questions independently of execution order or swarm selection. Plan Approval, enabled summary confirmation, verification command selection, skeleton approval, and failures still require the human. Existing workflows retain their legacy gate policy.
Bolt A planned Construction delivery slice over one or more dependency-linked Units, distinct from a Unit, its worktree, or a swarm batch. Delivery Planning records grouping, Definition of Done, confidence hypothesis, and ownership. Runtime order follows the Unit DAG and recorded iteration choice; bolt-plan.md does not replace them. Build and Test and CI Pipeline run once across the completed Unit work.
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 106 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-engine/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.
Construction Verification Command The intent-level project check reused at every Unit/batch checkpoint. A tool-owned VERIFICATION_COMMAND_RECORDED receipt binds the human's exact offered Approve reply in the invoking SessionStart session to the canonical trimmed single-line command's SHA-256 before the typed state setter records it; an unrelated reply, Request Changes, or a reply from another session does not authorize the receipt. The state field alone does not authorize execution. Delivery Planning proposes it, or the first checkpoint asks after a greenfield deferral; every later change requires a new human receipt. Proofs retain the digest and display label, not raw command text.
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 Bun-shaped aidlc-copy-runtime-X.Y.Z.tar.gz, copying a complete runtime/<harness>/ root. It requires Bun and does not require the native aidlc executable.
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 the dist/ projections in the out-of-band aidlc-copy-runtime-X.Y.Z.tar.gz for manual copy and the dist-release/ projections in the manifest-listed aidlc-runtime-X.Y.Z.tar.gz for native installation. Maintainers never hand-edit generated outputs.
Engine The deterministic orchestration tool (aidlc-orchestrate.ts, with exactly six subcommands: next, continue, report, park, team-board, and wait; continue is internal steering transport and team-board is the read-only Team Construction query, and wait is the bounded read-only wait for dispatched work) 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.
Fence A guard that refuses an action no step of the running workflow calls for. Five exist: plan approval, review freeze, state transition, reviewer read scope, and human presence. The first four are switchable for one piece of work with /aidlc config set guard.<fence> off\|on; on can raise a policy-lowered fence. The reviewer-scope switch affects a dispatched reviewer's read/search boundary, not the mandatory rule that a claimed team checkout cannot write another Unit's construction/ subtree. The human-turn hook applies the person's typed lowering switch at prompt time, using --intent/--space or the hook payload session's workflow selection, writes state and the audit row, and reports AIDLC Guard Policy: ... as hook context on harnesses that inject it. A nonexistent named intent is refused; without a state file, create the piece of work and type the switch again. A picked lower-fence choice only tells the person the exact command to type and executes nothing. CLI setters do not lower from chat on their own: an already-off fence or identical policy word with source you needs no key, and only fenceKeyBypassed permits other CLI lowering through the fixture/harness-launch presence bypass. Memory-held strict refuses first and overrides earlier Guards Off entries; unattended runs suppress prompt-time application and refuse CLI lowering. Hooks run on Windows too, so every harness that forwards the prompt supports the typed switch. Model tools cannot invoke hooks or write aidlc/.aidlc-sessions/ or any .aidlc-plan-approval/ directory, as enforced by the state-transition guard. Codex uses $aidlc instead of /aidlc. Human presence has no per-work switch and is lowered only by AIDLC_SKIP_HUMAN_PRESENCE_GUARD=1. A fence that stands aside records a GUARD_STOOD_ASIDE audit row when an audit ledger exists; notice delivery depends on the harness. See Guard Policy.
Guard Policy The per-intent setting (strict, relaxed, off) that decides how far the guards stand aside for one piece of work: whether a changed input reopens its approval, and which fences hold. Resolved from the scope default, then the intent's own state line, with any memory layer declaring Mode: strict winning over both. If the state carries both Guard Policy and retired Change Control with different words, strict applies with source conflicting state lines and next repeats a notice until a policy choice removes the retired line; if both agree, Guard Policy is used and the next policy write removes the retired line. The human-turn hook applies /aidlc --guard-policy relaxed\|off or guard policy relaxed\|off at prompt time; strict can be set directly by the conductor. Explicit intent create --guard-policy relaxed\|off from chat is refused: create the piece of work, then have the person type the switch; scope defaults apply without asking. Compose creation reads the approved custom scope's guard_policy: <value> or the matched stock scope's own default, with no new scope file for a stock match; the conductor passes --guard-policy only for strict. Flipping a matched proposal's Guard Policy converts it to a custom scope that stores the chosen value, so intent creation applies it without a later setter. The composer leaves an in-flight intent's value unchanged and names the supported policy-change routes instead. Formerly called Change Control; the old spellings are read for one release. See Fence.
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. Workflow-specific work self-gates; session-start records process ancestry, and the human-turn hook applies typed lowering switches to an existing piece of work at prompt time or asks the person to create it first.
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 explicit “Continue automatically” / “Review each checkpoint” choice. In eligible checkpoint workflows it is offered at Construction entry for skeleton-off or after the real skeleton checkpoint for skeleton-on, only when no choice is recorded. On-demand grant/revoke requests remain available. A legacy first-stage ladder does not prove an integrated skeleton has been built.
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 only when the learnings ritual is on, 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-engine/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. Its aidlc-runtime-X.Y.Z.tar.gz payload is 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 writes one review (READY / NOT-READY plus findings) to the review file the request names, never to the artifact; the engine records it as a review record keyed to that artifact, and 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 New source-producing solo Unit workflows default to unit-major: one Unit through every applicable per-unit stage before the next. Explicit stage-major remains available. Eligible skeleton-on work finishes the first integrated Unit before later Units under either order. Legacy, design-only, and team-owned workflows keep their existing paths. Runtime batches come from unit-of-work-dependency.md; bolt-plan.md is planning content.
Walking skeleton The smallest working integrated slice, planned as the first DAG Unit when skeleton-on. In eligible checkpoint-enabled solo work, that Unit completes its applicable design stages and Code Generation, passes the recorded, human-authorized end-to-end verification command, and receives human approval before later Units begin. The legacy first Construction-stage review is a stage gate, not evidence of a working skeleton.
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 for a Unit in swarm execution. Its directory and bolt-<id8>_<slug> branch hold that Unit’s work, scoped by the intent registry UUID like Unit claims. See Bolt identity. Execution may use guided or automatic completion approval. A worktree is neither the planned Bolt nor 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.