A tool-visible artifact or configuration entry that Spec Kitty installs, verifies, repairs, or packages for a concrete execution tool. This is surfaceSense 1 — the tool-facing sense, one of two unrelated domains that share the word. Realized in code by the ToolSurfaceKind enum in src/specify_cli/tool_surface/enums.py (members COMMAND_SKILL, DOCTRINE_SKILL, CONTEXT_FILE, RULE, HOOK, AGENT_PROFILE, PLUGIN_MANIFEST, NATIVE_CONFIG, COMMAND_FILE), renamed from the bare SurfaceKind per ADR 2026-07-23-1.
Describing install/config/doctor/plugin ownership for Claude Code, Codex, Copilot, Cursor, Windsurf, Kiro, or another concrete tool.
Do NOT use when
Describing logical collaborator identity, assignment, handoff, or role; use Agent or Agent Profile instead. The concept is the physical tree a mission artifact resolves to — use Topology Surface (surfaceSense 2). Never write bare "surface" in governed prose; name the sense ("tool surface" / "topology surface").
An ordered chain of processing steps that run before a mission step produces output. Each layer in the chain can extract terms, check for semantic conflicts, gate generation, prompt the Human-in-Charge for clarification, or resume from a checkpoint.
A mechanism that lets a glossary pipeline pause at a generation boundary and pick up where it left off in a later session. The pause point and its context are saved so no work is lost.
An optional YAML file (.kittify/glossaries/{scope}.yaml) that pre-loads domain glossary terms before the runtime starts extracting new ones. Gives teams a head start by defining known terminology upfront.
The level of Human-in-Charge involvement during a mission step or workflow. Determines how much real-time oversight the HiC provides versus delegating to agents.
The HiC works alongside agents in real time — conducting interviews, pair-developing, micro-prompting, or making decisions as they arise. The HiC is present and actively steering.
Agents operate independently during execution, but the HiC reviews results at defined checkpoints before work is accepted or advanced. The HiC is absent during execution but present for review.
The agentic stack operates asynchronously without the HiC present. Work proceeds until a final Accept/Decline decision point, where the HiC returns to approve or reject the outcome. Also known as "AFK mode."
The resolved set of Charter and Doctrine artifacts active for an operation. Owned by the Governance bounded module. Resolved once per operation and passed down; never re-derived mid-operation.
The resolved set of workspace root, branch name, feature directory, and WP identity for an operation. Owned by mission_runtime/context.py (Open Host Service facade). Resolved once per operation via resolve_action_context; never re-derived from CWD by individual command surfaces. Renamed from ExecutionContext (FR-012) to match the ubiquitous language and disambiguate from the unrelated core/context_validation.py::ExecutionContext(StrEnum).
The resolved set of infrastructure credentials and endpoints for an operation, including git remote URL, CI endpoint, and any external service tokens. Owned by the Execution module.
The Actor realized inside the Execution domain — the execution-bound realization of an Actor that performs actions within a mission run, producing or consuming communication artefacts (commits, PRs, comments). Named concept in docs only; no code type until a concrete actor-kind-mismatch bug triggers materialization.
Context
Execution
Status
canonical
Applicable to
3.x
Materialization trigger
First concrete actor-kind-mismatch bug, or first feature requiring cross-log (status/retrospective/run) actor identity join
A durable artifact produced or consumed by an Effector during a mission run (for example, a commit, a pull request, a review comment). Distinct from planning artifacts (spec, plan, tasks) which are produced before execution begins.
Context
Execution
Status
canonical
Applicable to
3.x
Examples
git commit, pull request, PR comment, CI run result
The canonical repository-root working copy of a project — the single checkout from which planning commands run and against which lane worktrees are created. It is distinct from a lane worktree (an isolated per-work-package checkout under .worktrees/). This is primarySense C; the charter §Branch-Intent Terminology Governance decrees "repository root checkout" as the canonical term for this sense. The retired alias phrases "primary surface" and "primary checkout" describe it.
Context
Execution
Status
canonical
Applicable to
3.x
Symbols unchanged this slice
This entry canonicalizes the prose term only. The underlying code symbols (primary_feature_dir_* and the rest of the Sense-C checkout cluster) are not renamed in this mission; the code rename is Track 2 (#2730).
Do NOT use when
The concept is the artifact-kind partition — use PRIMARY partition. The concept is the repository's default integration branch — use primary branch. The concept is the ref planning artifacts commit to — use Target Ref / Commit Target. Avoid the retired aliases "primary surface" and "primary checkout".
A contributor/maintainer practice for developing Spec Kitty itself: a standalone repository-root checkout of the Spec Kitty codebase whose CLI and runtime state are pinned to that checkout, so it does not interfere with a machine-global install or with sibling checkouts. Isolation has two axes — code (a clone-local .venv editable install placed first on PATH, so spec-kitty runs the checkout's live src/) and state (SPEC_KITTY_HOME pointed at a clone-local root so the offline queue, sync daemon, event journal, auth, gate-locks, and trackers do not land in the shared ~/.spec-kitty). It is the non-containerised isolation option, chosen for speed over the stronger isolation of a container.
Context
Execution
Status
candidate
Applicable to
3.x
Examples
A stable primary checkout backing the machine-global spec-kitty, plus one or more shadow checkouts each activated per-session against its own .venv and SPEC_KITTY_HOME.
Use when
Describing how a maintainer runs several Spec Kitty checkouts on one machine without cross-mission pollution, or the SPEC_KITTY_HOME / clone-local .venv isolation levers that make that safe.
Do NOT use when
The concept is a per-work-package worktree under .worktrees/ inside a single checkout (that is intra-mission execution isolation, not a separate clone). The concept is the canonical repository root checkout of a consumer project rather than a maintainer's isolated development copy of Spec Kitty.