feat: doctrine stack, agent profiles, and mission template repository (specs 046-058)

[stijn-dejongh]

Summary

Supersedes #305 — rebased, exception-hardened, extended with mission 057+058.

• Doctrine stack (src/doctrine/): 8 artifact types with consistent repository pattern, DoctrineService facade, Pydantic v2 frozen models, ArtifactKind StrEnum
• Agent profiles (spec 048): DDR-011 weighted context matching, hierarchy traversal, cycle detection, CLI surfaces
• Constitution bootstrap (spec 054): ConstitutionInterview, compile_constitution(), MissionStepContract domain model
• Kernel package (spec 057): shared utilities, glossary type shims, init-time doctrine integration
• MissionTemplateRepository (spec 058): sole authority for mission asset access via value objects (TemplateResult, ConfigResult), 5-tier resolver integration, ProjectPaths centralization
• Feature→mission terminology rename (spec 058 WP08): cord-cut backward-compat shims and --feature flags
• Architectural boundary tests: pytestarch-enforced kernel→doctrine→specify_cli layering

Changes since #305

• All 21 bare except Exception handlers in src/doctrine/ narrowed to specific exception tuples (M1 from feat: doctrine artifact domain models, agent profiles, and constitution bootstrap (specs 046, 048, 054) #305 review)
• C1 resolved: doctrine no longer imports specify_cli (glossary imports moved to kernel.*)
• C2 resolved: CI coverage now includes --cov=src/doctrine across all test suites
• M2-M4 resolved: module-level constants, resolution path logging, documented graceful degradation
• All 5 architecture discrepancies from March 26 review addressed in architecture docs
• Mission 057 (kernel + doctrine stack + profile infrastructure) fully integrated
• Mission 058 (MissionTemplateRepository encapsulation + terminology rename) fully integrated

Test plan

• pytest tests/doctrine/ --timeout=30 — 1110 passed
• ruff check src/doctrine/ src/constitution/ — clean
• grep -r "except Exception" src/doctrine/ --include="*.py" — zero results
• pytest -m fast --timeout=30 — full fast suite passes

🤖 Generated with Claude Code

[stijn-dejongh]

PR #348 is the continuation of #305 after rebasing onto the newer main
architecture, so the right comparison is not "did we replay #305 verbatim?"
but "which #305 review concerns survive after aligning with main, and which
ones are now explicitly addressed?"

What from #305 is applied in #348

1. Architectural boundary correction

The most important actionable review item on #305 was the doctrine boundary:
doctrine should not depend on specify_cli.

That is now materially addressed in this branch:

• src/kernel/ exists as the shared dependency floor for path, atomic-write,
  and glossary-boundary primitives.
• doctrine-side shared/glossary primitives were lifted out of specify_cli and
  anchored in kernel.
• specify_cli.runtime.home is now a compatibility shim over kernel.paths.
• package boundary expectations are no longer just prose; they are codified in
  ADRs and enforced by architectural tests (tests/architectural/).

This is the main architectural improvement over #305: the doctrine work is no
longer landing into the old package arrangement, but into an explicitly layered
kernel <- doctrine <- constitution <- specify_cli model.

2. Constitution as pass-through / local router

The branch also moves closer to the intended constitution role as the
project-local router for governance concerns:

• project-local mission path construction now flows through
  ProjectMissionPaths
• doctrine-backed mission/template reads flow through
  MissionTemplateRepository
• constitution-facing code composes those layers instead of having each
  consumer hand-build paths ad hoc

That is the important alignment point: constitution is becoming the local
indirection point for governance and doctrine-aware project state, not just a
document compiler.

3. Doctrine asset expansion and repository encapsulation

The PR still carries forward the core #305 and mission 058 asset work:

• doctrine remains the home of the expanded artifact model
• mission/template access is formalized through
  MissionTemplateRepository
• the rebased branch keeps the doctrine asset migration while fitting it into
  main's newer runtime and shim architecture

This also preserves the March 26-27 review direction: doctrine owns the shipped
assets, while consumers stop reaching into package paths directly.

4. CI and verification improvements

The #305 concern that doctrine work was not properly exercised in CI is also
addressed materially here:

• doctrine is included in coverage paths
• kernel has its own CI test/coverage gate
• architectural dependency checks run as a first-class CI surface
• release/readiness flows were updated for the newer package layout

This is a meaningful improvement over #305 because the new package boundaries
are now tested rather than only argued for.

5. Mission type vs mission run split

The rename work is also more explicit in #348, and this is the practical
response to issue #241:

• issue Rename --feature flag to --mission (with backward compatibility) #241 started as a proposed --feature → --mission rename
• that collided with the existing use of --mission for the workflow kind
• the branch resolves that collision by splitting the concepts instead of
  forcing one overloaded flag
• mission type now means the abstract workflow category and is selected via
  --mission-type
• mission run now means the concrete execution instance and is selected via
  --mission-run

This is a useful clarification over older feature/mission overloading. It
keeps the taxonomy separate from a specific run instance, which matters in the
runtime, CLI, and documentation surfaces.

What from #305 is still relevant

Two architectural comments from #305 remain valid follow-on guidance rather
than "done in this PR":

1. The compiler-backed mission-bundle follow-up is still relevant. The doctrine
   foundation is in place, but the longer-term goal of compiling structured
   mission sources into stable runtime bundles remains a separate step.
2. The separation between shipped product-operation skills and mission-authoring
   doctrine still matters. Skills should help agents operate Spec Kitty
   correctly; they should not become a second authored source of mission
   behavior.

There is also still constitution-routing work left beyond the current mission
path centralization. Using constitution as the local governance router is the
right direction, but this PR does not claim that every constitution, global
runtime, or governance path is fully centralized yet.

Issue #241 is also not "fully done everywhere" yet. The conceptual split is the
right answer and large parts of the runtime/CLI now use it, but a number of
older compatibility surfaces and docs still retain --feature language during
the deprecation period.

Open tasks this PR does not pretend to close

• expand constitution-led path centralization beyond ProjectMissionPaths
• continue burning down residual exception-swallowing / graceful-degradation
  debt in constitution and adjacent surfaces
• carry the compiler-backed mission composition follow-on
• keep reducing remaining runtime/test debt that predates this rebase

Net assessment

#348 should be read as:

• the doctrine / constitution / agent-profile foundation from feat: doctrine artifact domain models, agent profiles, and constitution bootstrap (specs 046, 048, 054) #305
• rebased onto main's newer execution architecture
• corrected around package boundaries through the new kernel layer
• extended with architectural tests, CI coverage, mission-template repository
  encapsulation, and the mission type / mission run split

So the important #305 review comments were not ignored. The concrete ones were
applied in the rebased branch, and the longer-horizon ones remain explicitly
relevant follow-on architecture rather than hidden debt.