Work package state position in the canonical lifecycle FSM. Canonical lanes: planned, claimed, in_progress, for_review, done, blocked, canceled. Alias: doing -> in_progress.
Context
Orchestration
Status
canonical
Applicable to
1.x, 2.x
Mission-Runtime YAML
Definition
Configuration file (mission-runtime.yaml) that defines a mission type's step graph, action ordering, dependencies, and prompt-template bindings.
A markdown file that provides the prompt for a specific mission action. Located in the mission type's template directory and loaded at runtime based on mission type and agent configuration.
The process of finding and loading the correct command template for a given mission action, considering which mission type is active and which agent is running.
JSON-based interface that lets external orchestration tools interact with spec-kitty CLI operations programmatically, without going through the human-facing CLI.
A structured choice presented to the Human-in-Charge (HiC) or their delegated agent during the next-command loop. Each decision describes what needs to happen next and offers options to advance the mission. In event-backed runtimes, a pending Decision is tracked until answered, then closed.
Materialised as a DecisionInboxItem (pending → answered) in the TeamSpace.
Not to be confused with
SaaS Decision (an immutable recorded past collaboration choice); SaaS DecisionPoint (a first-class team-consultation entity that can be widened, deferred, or resolved independently of the loop). See the SaaS domain glossary at architecture/domain-glossary.md.
The type of choice being presented — for example, selecting which step to run next, resolving a conflict, or assigning a work package to an agent. In the spec-kitty next --json contract this is carried as the top-level kind field; DecisionInputRequested events are emitted only for decision_required choices and do not repeat that field.
The event emitted by the runtime when it opens a Decision and requires a response from the HiC or a delegated agent. Carries the question text, candidate options, step context, and a unique decision_id. Opening a Decision Input Request is what makes a Decision "pending".
Context
Orchestration
Status
canonical
Applicable to
2.x, 3.x
Event type
DecisionInputRequested (in spec-kitty-events)
SaaS effect
Creates a DecisionInboxItem row with state=pending.
The event emitted when the HiC or a delegated agent answers a pending Decision. Carries the chosen answer, the actor identity, and the originating decision_id. Answering closes the Decision; the loop continues.
Context
Orchestration
Status
canonical
Applicable to
2.x, 3.x
Event type
DecisionInputAnswered (in spec-kitty-events)
SaaS effect
Updates the matching DecisionInboxItem to state=answered.
The adapter that connects the CLI's decision loop to the mission execution engine. It translates internal runtime decisions into the format the HiC or agent sees while keeping mission identity separate from mission-run identity.
The process of figuring out where a mission currently stands by reading filesystem artifacts and event logs, so the system can determine what mission actions are available next.
Overloaded key with two distinct scopes. (1) At the mission level (branch-context JSON output): alias for target_branch — the branch the mission is rooted in; base_branch and target_branch carry the same value in branch-context output. (2) At the worktree/WP level (WP prompt frontmatter): the specific git branch from which the individual lane worktree was created; this may be a lane branch (e.g. kitty/mission-010-feature-lane-a) rather than the target branch itself. JSON key: base_branch.
The mission-create guard for PR-bound missions that requires an explicit operator or agent decision before planning artifacts are written on a primary branch. Interactive callers may confirm at the prompt; non-interactive callers record the already-made decision with --branch-strategy already-confirmed. When the recommended feature-branch path is chosen, pass --start-branch so the CLI switches before scaffold writes.
The git branch checked out in the main repository at the moment a workflow command is invoked. Read ephemerally from the working tree; never persisted in any mission artifact. Exposed as current_branch / CURRENT_BRANCH in branch-context JSON output. Since WP07 (FR-012), spec-kitty does not use current_branch to derive the mission target — it reads target_branch from meta.json instead, so the branch contract is stable regardless of which branch the operator is on.
A dedicated git branch for PR-bound mission planning and implementation work, typically named feat/<slug> for feature work or fix/<slug> for bug-fix work. It is distinct from the primary branch and is the recommended start point when a mission is expected to become a pull request.
The branch where completed work-package code must ultimately land. Stored in every WP prompt's frontmatter (alongside planning_base_branch) to give implementing agents an explicit merge destination. In meta.json: legacy alias for target_branch, read as a fallback by resolve_planning_branch_from_meta() for pre-WP03 missions. In 3.x all three — target_branch, planning_base_branch, and merge_target_branch — carry the same value; the separation makes intent explicit in agent-facing prompts and prevents the "prep branch leak" (pre-WP07 pattern). JSON key: merge_target_branch.
The branch active in the repository root checkout when WP prompts were generated (at finalize-tasks time). Stored in every WP prompt's frontmatter and in lanes.json to root lane-worktree allocation correctly regardless of which branch the operator is on when running finalize-tasks. In 3.x equals target_branch. Introduced alongside merge_target_branch to close the "prep branch leak" bug (pre-WP07): when finalize-tasks ran from a temporary prep/... branch, that branch leaked into WP frontmatter and crashed lane allocation once the prep branch was deleted. JSON key: planning_base_branch.
The repository's default integration branch, normally resolved from origin/HEAD and commonly named main, master, or develop. The specify branch-context output exposes this value as primary_branch only for branch-strategy recommendation; it is not automatically the mission's target_branch once target_branch has been persisted in meta.json.
A mission expected to land through a pull request rather than direct work on the primary branch. During mission create, --pr-bound activates the branch strategy gate so the branch choice is explicit before planning artifacts are written.
The branch passed to mission create with --start-branch. The CLI creates or switches to this branch before writing mission scaffolding, and it must match --target-branch when both options are supplied so mission metadata and the checked-out branch describe the same planning branch.
The git branch on which a mission's code, planning artifacts, and status events must ultimately land. Persisted in meta.json under the key target_branch at mission create time and never overwritten. Read by resolve_planning_branch_from_meta() as the canonical key; merge_target_branch is its legacy alias in older meta.json fixtures. Since WP07 (FR-012), all downstream commands — finalize-tasks, implement, review, merge — derive the branch contract from this stored value, not from current_branch at invocation time. In branch-context JSON output, target_branch and base_branch carry the same value at the mission level.