doctrina-cli 0.2.1 → 0.3.0

package/templates/decision.md.template

@@ -5,6 +5,16 @@
 - **Deciders:**
 - **Supersedes:** —
 - **Superseded by:** —
+- **Evidence:** —
+
+<!--
+Evidence anchors the decision to reality. Once accepted, cite the file(s)
+that prove this decision is actually implemented, in backticks, e.g.
+"- **Evidence:** `proto/order.proto`, `services/gateway/grpc.ts`".
+`doctrina validate` warns when cited evidence is missing on disk (the
+decision drifted from the code) or when an accepted ADR cites none. For a
+process decision with no code artifact, write "n/a — <why>".
+-->
 
 ## Context
 

package/templates/doctrina/product.md.template

@@ -29,3 +29,15 @@ Out of scope (deferred or rejected):
 ## Success criteria
 
 <!-- How you will know this project is working. Prefer measurable signals. -->
+
+## Delivery order (walking skeleton)
+
+<!--
+Depth before breadth. Name the ONE end-to-end path that must work and be
+verified before any capability fans out — the walking skeleton (e.g.
+auth -> ingest -> ws -> ui). A spec'd capability with no working slice
+through it is breadth bought on credit: build and `doctrina verify` the
+skeleton first, then spec the next capability.
+-->
+
+1.

package/templates/spec.md.template

@@ -1,10 +1,24 @@
 # Spec — {{CAPABILITY}}
 
 **Capability:** {{CAPABILITY}}
-**Status:** active
+**Status:** draft
+**Implementation:** planned
 **Last updated:** {{DATE}}
 **Version:** 0.1.0
 
+<!--
+Two independent axes — keep them honest:
+  Status         — the document:   draft -> active -> deprecated
+  Implementation — the capability: planned -> partial -> implemented -> verified
+Flip Status to "active" only once this spec reflects intended truth.
+Advance Implementation as code lands; "verified" means a test proves it
+(cite the test per acceptance criterion — see `doctrina coverage`).
+An "active" spec left at "planned" is an inventory claim with nothing
+behind it, and `doctrina validate` warns. To record a deliberate gap and
+silence the warning, add a note after the value, e.g.
+"**Implementation:** planned — backend deferred to Q3, see ADR 0007".
+-->
+
 ## Purpose
 
 <!-- One paragraph: what this capability does and why it exists. -->
@@ -43,9 +57,33 @@ Easy Approach to Requirements Syntax. Use one of the five forms per item:
 
 ## Acceptance criteria
 
-<!-- Concrete, observable signals that the capability is correctly implemented. -->
+<!--
+Concrete, observable signals that the capability is correctly implemented.
+Each criterion is also a claim that must be proven: mark it [verified] or
+[unverified] and cite the artifact/test in backticks. `doctrina coverage`
+reports which criteria have no linked evidence — an [unverified] criterion
+with no test is explicit debt, not a fact.
+-->
+
+1. [unverified] <observable signal> — verified by `path/to/test`.
 
-1.
+## Maturity
+
+<!--
+The line between an MVP and a product wishlist. List under MVP only what
+this capability COMMITS to now. Anything aspirational goes under Future and
+is explicitly NOT accepted scope — do not write Future items in EARS as if
+they were already built (no WebGPU/multi-cloud/"50k entities at 30fps"
+smuggled in as committed requirements).
+-->
+
+**MVP (committed):**
+
+-
+
+**Future (aspirational, not committed):**
+
+-
 
 ## Out of scope for this spec