[PROJECT] Kata Mono

[gannonh]

Kata backend UAT project record.

[gannonh]

Project Brief

github UAT proof 20260508145835.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• https://github.com/gannonh/kata/issues/398

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[gannonh]

Requirements: Kata

Defined: 2026-04-28
Last updated: 2026-05-03 after M002 completion
Core Value: Make agent-driven project execution durable, structured, and reusable across harnesses by separating workflow behavior in skills from durable backend effects in the CLI.

Validated Requirements

Phase A Validation Chain

• PHA-01: User can run kata-setup in Pi and confirm Kata is installed/configured for the current harness. Evidence: M001.
• PHA-02: User can run kata-new-project in Pi and create a durable project identity plus project brief through CLI contract operations. Evidence: M001.
• PHA-03: User can run kata-new-milestone after project initialization and create the first active milestone through CLI contract operations. Evidence: M001.
• PHA-04: User can run kata-plan-phase for the active milestone and persist milestone planning artifacts through CLI contract operations. Evidence: M001.
• PHA-05: User can run kata-execute-phase and advance planned work through the CLI-owned execution/task operation surface. Evidence: M001.
• PHA-06: User can run kata-verify-work and persist verification evidence for completed work through CLI contract operations. Evidence: M001.
• PHA-07: User can run kata-complete-milestone and complete the active milestone only after required acceptance evidence is captured. Evidence: M001 and M002.
• PHA-08: User can roll over from kata-complete-milestone to kata-new-milestone to kata-plan-phase without losing project context or violating workflow boundaries. Evidence: M002 followed M001 using durable project context.
• PHA-09: User can use the validated Phase A workflow to continue building Kata with Kata itself. Evidence: M002.

Backend Contract

• CLI-01: Skills perform durable project, milestone, slice, task, artifact, execution, and health interactions only through typed @kata-sh/cli operations. Evidence: M001 and M002.
• CLI-02: Skills do not directly depend on GitHub Projects v2 implementation details; backend details remain encapsulated behind the CLI contract. Evidence: M001 and M002.
• CLI-03: Artifacts are created, read, and updated only through CLI contract operations such as artifact.write and corresponding typed reads. Evidence: M001 and M002.
• CLI-04: CLI operations return structured success/failure responses that skills can treat as workflow gates. Evidence: M001 and M002.
• CLI-05: Failed backend operations block workflow progress until the payload, setup, or backend issue is resolved. Evidence: M001 and M002 workflow gates.

Skill Workflow Behavior

• SKL-01: Skills own workflow behavior, alignment, questioning, sequencing, confirmations, and next-step routing. Evidence: M001 and M002.
• SKL-02: Discussion and alignment happen inside the primary workflow skills instead of separate discuss commands. Evidence: M001 and M002.
• SKL-03: kata-new-project persists only project-level context and routes to kata-new-milestone; it does not create milestones, roadmaps, slices, or tasks. Evidence: M001.
• SKL-04: Skill workflows preserve required gates: health checks, user confirmations, durable writes, status updates, and next-step routing. Evidence: M001 and M002.

Symphony Boundary

• SYM-01: Symphony remains Kata's autonomous project execution layer for planned work. Evidence: M002.
• SYM-02: Phase A validation focuses on the Skills + CLI + GitHub Projects v2 path through Pi without changing Symphony during project initialization. Evidence: M001 and M002.
• SYM-03: Later validation confirms Symphony can continue consuming planned project/task state once the skill/CLI surface is stable. Evidence: M002.

Milestone Closeout

• CF-03: Update kata-complete-milestone so milestone closeout updates project brief and project requirements artifacts before lifecycle completion. Evidence: M002 closeout wrote PROJECT project-brief and requirements before milestone.complete.

M002 Milestone Requirement Coverage

Requirement	Evidence	Status
SYM-01	M002 summary, S006, T016	Validated
SYM-02	M002 summary, S006, T017	Validated
SYM-03	M002 summary, S005, S007, T015, T019-T025	Validated
SYM-04	M002 summary, S007, T019	Validated
SYM-05	M002 summary, S007, T020	Validated
SYM-06	M002 summary, S007, T021	Validated
SYM-07	M002 summary, S007, T022	Validated
SYM-08	M002 summary, S005, T014	Validated
SYM-09	M002 summary, S005, T015	Validated
SYM-10	M002 summary, S008, T026-T030	Validated

Active / Carry-Forward Requirements

• CF-01: Rerun review/comment, PR update/push, checks, and land validation on an open PR with representative comments/checks. Source: M002. Deferred because no current PR existed for the active branch during validation.
• CF-02: Keep merge execution gated behind a disposable/test PR or explicit user approval. Source: M002. Deferred because merge execution requires explicit approval or disposable/test PR context.

Future Requirements

Harness Expansion

• FUT-01: Additional agent harnesses can use the same skills-first workflow model once the Pi + GitHub Projects v2 path is stable.

Backend Expansion

• FUT-02: Additional durable backends can be added behind the CLI contract without changing skill workflow behavior. Source milestone: M002. Deferred reason: M002 focused on the Symphony migration to the validated Pi + Kata CLI backend path.

Out of Scope

Feature	Reason
Creating milestones during project initialization	Milestone creation belongs to kata-new-milestone.
Creating roadmaps, slices, or tasks during project initialization	Planning belongs to milestone and phase-planning workflows.
Calling backend validation done based only on mocks or JSON-only tests	Backend validation requires real backend state when scoped by the milestone.
Centering legacy migration history in durable project identity	The project brief focuses on current target architecture and current status.

Traceability

Requirement	Evidence	Status
PHA-01	M001	Validated
PHA-02	M001	Validated
PHA-03	M001	Validated
PHA-04	M001	Validated
PHA-05	M001	Validated
PHA-06	M001	Validated
PHA-07	M001, M002	Validated
PHA-08	M002	Validated
PHA-09	M002	Validated
CLI-01	M001, M002	Validated
CLI-02	M001, M002	Validated
CLI-03	M001, M002	Validated
CLI-04	M001, M002	Validated
CLI-05	M001, M002	Validated
SKL-01	M001, M002	Validated
SKL-02	M001, M002	Validated
SKL-03	M001	Validated
SKL-04	M001, M002	Validated
SYM-01	M002	Validated
SYM-02	M001, M002	Validated
SYM-03	M002	Validated
CF-01	M002 carry-forward	Active
CF-02	M002 carry-forward	Active
CF-03	M002 closeout	Validated
FUT-01	Project future requirement	Future
FUT-02	M002 carry-forward future requirement	Future

Coverage

• Validated requirements: 22
• Active carry-forward requirements: 2
• Future requirements: 2