Kaname Delivery
Kaname is not sprint-based. Work flows continuously through defined stages governed by explicit policies. A delivery cycle begins when Use Cases are committed and ends when the Delivery Gate passes. What happens between those two points is the delivery cycle.
The Board
Backlog
Gate 1
Specify
Spec Owner
spec.md
Gate 2
Plan
Plan Reviewer
plan.md
Gate 3
Implement
Task Implementer
tasks.md
Review
Spec Owner
Gate 4
Done
Delivery Coach
Vertical lines are human gates - work cannot cross them without named human approval.
The Artifact Chain
Four structured markdown files form a chain of constraint. Each artifact governs the one that follows it. constitution.md is the highest authority - nothing in the chain may contradict it.
constitution.md01Technical Contract
Non-negotiable boundaries: architectural decisions, approved technologies, security requirements, quality standards. The highest authority in Kaname. All other artifacts and all AI output must conform to it.
Owner: Constitution Guardian
spec.md02Behavioral Intent
System behavior from the user's perspective. Organized as Use Cases - each describing one meaningful interaction with all successful paths, variants, and failure conditions. Complete when any Task Implementer can execute it without clarification.
Owner: Spec Owner
plan.md03Architecture Alignment
The technical architecture for implementing the specification. Generated by AI from spec.md. Includes component structure, data model, API contracts, and implementation sequence. Complete when every Use Case maps to a defined component.
Owner: Plan Reviewer
tasks.md04Implementation Completeness
Discrete, executable units of work derived from the plan. Each task maps to one Use Case and one plan component. Self-contained: it carries the Use Case reference, acceptance criteria, and component context. Complete when AI output satisfies the linked Use Case.
Owner: Task Implementer
Stage by Stage
Use Cases exist but are not yet Spec-Ready. The Spec Owner is aware of them and may be authoring them, but they have not yet entered the active specification pipeline.
Entry
A stakeholder intent or product need has been identified.
Exit
Use Case is submitted for Spec Review Session assessment.
Specification Gate
Spec Owner + Constitution Guardian verify: Each Use Case is complete, constitutionally aligned, and implementable without clarification.
spec.mdThe Spec Owner writes and refines Use Cases until they meet the Spec-Ready standard: every input, output, variant, and failure condition is defined. The Spec Review Session runs at cadence here.
Entry
Spec Owner pulls the Use Case into active specification.
Exit
Use Case satisfies Behavioral Intent commitment - a Task Implementer can execute it without clarification.
Plan Gate
Plan Reviewer verify: AI-generated plan.md is architecturally sound, constitutionally compliant, and covers all Use Cases in scope.
plan.mdAn AI agent generates plan.md from the approved specification: component structure, data model, API contracts, and implementation sequence. The Plan Reviewer inspects - they do not author.
Entry
Gate 1 cleared. Spec-Ready Use Cases committed to the delivery cycle.
Exit
Plan satisfies Architecture Alignment commitment - every Use Case maps to a technical component, no constitutional violations.
Implementation Gate
Task Implementer verify: AI-generated code satisfies the linked Use Case acceptance criteria. Applied per task, not per delivery cycle.
tasks.mdTask Implementers pull tasks from tasks.md according to WIP limits and execute them with AI coding assistants. Each task carries its Use Case reference and acceptance criteria. Ambiguity returns to the Spec Owner - it is never resolved unilaterally.
Entry
Gate 2 cleared. Task pulled from board as capacity allows.
Exit
AI output reviewed against Use Case acceptance criteria. Task satisfies Implementation Completeness commitment.
The Spec Owner performs end-to-end verification of all implemented Use Cases in the delivery cycle. This is not a code review - it is behavioral verification: does the delivered system do what the spec said it would?
Entry
All tasks in the delivery cycle have passed Gate 3.
Exit
All Use Cases verified end-to-end. Gate 4 is ready to be exercised.
Delivery Gate
Spec Owner verify: All Use Cases in the delivery cycle are satisfied. Release is authorized. Triggers the Delivery Review event.
Gate 4 has passed. The Delivery Review event is triggered - stakeholders inspect the delivered system and provide feedback. Their input enters the next Spec Review Session. The delivery cycle formally closes.
Entry
Gate 4 cleared by Spec Owner.
Exit
Delivery Review concluded. Feedback captured. Cycle closed.
Six Events
Events are formal opportunities to inspect the artifact chain and adapt. They are triggered by defined conditions, by regular cadence, or both. Failure to hold events results in specification drift, unreviewed architectural decisions, or accumulated delivery debt.
Spec Review Session
Trigger: Regular cadence · Facilitated by: Spec Owner
Advance Use Cases toward Spec-Ready quality. Resolve open questions. Agree what to specify next. Prevents the Spec Owner from becoming a bottleneck.
Output: Use Cases assessed. Next Use Cases to specify agreed.
Queue Replenishment
Trigger: When Spec-Ready queue is insufficient · Facilitated by: Delivery Coach
Select Spec-Ready Use Cases for the next delivery cycle and commit them toward Gate 1. No estimation, no technical planning - only prioritized selection.
Output: Use Cases committed to the current delivery cycle.
Plan Review
Trigger: After AI generates plan.md · Facilitated by: Plan Reviewer
Inspect the AI-generated technical plan for architectural soundness, constitutional compliance, and specification coverage before task generation begins.
Output: Plan approved or required revisions recorded.
Delivery Review
Trigger: After Gate 4 passes · Facilitated by: Spec Owner
Stakeholders inspect the delivered system against each implemented Use Case. Gaps, new needs, and changed priorities are captured as input for the next Spec Review Session.
Output: All Use Cases reviewed. Stakeholder feedback recorded. Cycle closed.
Flow Review
Trigger: Regular cadence or when blocked items accumulate · Facilitated by: Delivery Coach
Inspect the system of work - not individual items. Identify policy changes that would improve flow. The output is a change to WIP limits or gate criteria, not an action item for an individual.
Output: Policy change ratified, or explicit record that no change is warranted.
Constitution Review
Trigger: Proposed amendment or post-delivery inspection · Facilitated by: Constitution Guardian
Inspect constitution.md for completeness and continued relevance. Ratify, revise, or reject proposed amendments. Only the Constitution Guardian can ratify changes.
Output: constitution.md updated. Amendment ratified, revised, or rejected.
The four human gates are defined in detail in the Gates section.