@deftai/directive-content 0.55.0

package/context/spec-deltas.md

@@ -0,0 +1,177 @@
+# Spec Deltas
+
+Tracking how requirements evolve across changes using vBRIEF references.
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+**⚠️ See also**: [commands.md](../commands.md) | [vbrief/vbrief.md](../vbrief/vbrief.md) | [context/context.md](./context.md)
+
+---
+
+## Core Principle
+
+Code diffs show *what* changed. Spec deltas show *why* — how the system's requirements shifted. Reviewers can understand a change at the requirement level without reading implementation code.
+
+---
+
+## How It Works
+
+When a change modifies existing requirements (or adds new ones), the change's `specs/` folder captures the delta as a vBRIEF file:
+
+```
+history/changes/add-remember-me/
+└── specs/
+    └── auth-session.delta.vbrief.json  ← New/changed requirements for auth-session
+```
+
+The spec delta is linked to the project's baseline spec via a vBRIEF reference in the change's `tasks.vbrief.json`:
+
+```json
+{
+  "vBRIEFInfo": { "version": "0.5" },
+  "plan": {
+    "title": "add-remember-me",
+    "status": "draft",
+    "references": [
+      {
+        "uri": "file://./vbrief/specification.vbrief.json",
+        "type": "x-vbrief/plan",
+        "description": "Baseline spec this change modifies"
+      }
+    ],
+    "items": [...]
+  }
+}
+```
+
+---
+
+## Writing Spec Deltas
+
+### Format
+
+Spec delta files are vBRIEF v0.5 files with `plan.narratives` capturing requirement changes:
+
+```json
+{
+  "vBRIEFInfo": { "version": "0.5" },
+  "plan": {
+    "title": "auth-session-delta",
+    "status": "draft",
+    "narratives": {
+      "Baseline": "specification.vbrief.json -- auth-session scope",
+      "NewRequirements": "FR-4: The system SHALL support configurable session expiration periods. GIVEN user checks 'Remember me' at login WHEN 30 days have passed THEN invalidate the session token AND clear the persistent cookie.",
+      "ModifiedRequirements": "FR-1 (Session expiration): was: The system SHALL expire sessions after 24 hours without activity. now: The system SHALL expire sessions after a configured duration. Default 24 hours; 30 days with 'Remember me'.",
+      "RemovedRequirements": ""
+    }
+  }
+}
+```
+
+### Rules
+
+- ! Each delta vBRIEF identifies its **Baseline** narrative — the spec or section it modifies
+- ! Separate `NewRequirements` from `ModifiedRequirements` narratives
+- ! For modified requirements, show **was** and **now** explicitly within the `ModifiedRequirements` narrative
+- ! All narrative values MUST be plain strings — never objects or arrays
+- ~ Organize spec deltas by capability: `specs/auth-session.delta.vbrief.json`
+- ~ Use GIVEN/WHEN/THEN scenarios for behavioral requirements within narrative values
+- ~ Use RFC 2119 language (MUST, SHOULD, MAY) within narrative values
+- ⊗ Rewrite the full spec — only capture the delta
+- ⊗ Omit the Baseline narrative — the delta is meaningless without it
+- ⊗ Use markdown spec files (`spec.md`) — all spec deltas must be vBRIEF format
+
+---
+
+## vBRIEF Chain
+
+Spec deltas form a chain via vBRIEF `references`:
+
+```
+specification.vbrief.json (baseline)
+    ↑ referenced by
+history/changes/add-auth/tasks.vbrief.json
+    ↑ referenced by
+history/changes/add-remember-me/tasks.vbrief.json
+```
+
+Each change's `tasks.vbrief.json` references what it builds on:
+
+- For the first change: reference the project's `specification.vbrief.json`
+- For subsequent changes: reference the prior change's `tasks.vbrief.json` if the changes are related, or the baseline spec if independent
+
+### Reference Types
+
+Use the vBRIEF `references` array with `type: "x-vbrief/plan"`:
+
+```json
+"references": [
+  {
+    "uri": "file://./vbrief/specification.vbrief.json",
+    "type": "x-vbrief/plan",
+    "description": "Baseline project specification"
+  },
+  {
+    "uri": "file://./history/changes/add-auth/tasks.vbrief.json",
+    "type": "x-vbrief/plan",
+    "description": "Prior change this builds on"
+  }
+]
+```
+
+### Narratives for Context
+
+Use vBRIEF `narratives` on the plan to capture the **why** of the spec change:
+
+```json
+"narratives": {
+  "Proposal": "Add remember-me checkbox to extend session duration",
+  "Background": "Users report frustration with 24-hour session timeout"
+}
+```
+
+---
+
+## Reading Spec Deltas
+
+When an agent needs to understand the current state of requirements:
+
+1. ! Read the baseline `specification.vbrief.json` (or relevant scope vBRIEFs)
+2. ! Scan `history/changes/*/specs/` for any `*.delta.vbrief.json` files that modify relevant sections
+3. ! Apply deltas in chronological order (directory timestamps or vBRIEF chain order)
+4. ~ Archived changes (`history/archive/`) represent already-merged deltas — skip unless investigating history
+
+---
+
+## When to Create Spec Deltas
+
+- ! When a change adds new behavioral requirements
+- ! When a change modifies existing requirements
+- ~ When a change has non-obvious acceptance criteria worth documenting as requirements
+- ? Skip for pure refactors, dependency bumps, or infrastructure changes that don't alter behavior
+
+---
+
+## After Archiving
+
+When a change is archived via `/deft:change:archive`:
+
+- ! Read each `*.delta.vbrief.json` file's narratives and apply to the target scope vBRIEF
+- ! Apply `NewRequirements` narrative to the scope vBRIEF
+- ! Apply `ModifiedRequirements` narrative — replace **was** with **now** in the scope vBRIEF
+- ! Apply `RemovedRequirements` narrative — remove identified requirements from the scope vBRIEF
+- ~ The archived delta vBRIEF remains as a historical record of *why* the spec changed
+- ! The main spec (scope vBRIEFs) should always reflect the current state of requirements
+- ⊗ Leave spec deltas unmerged after archiving — the scope vBRIEF drifts from reality
+- ⊗ Parse markdown to extract delta content — read vBRIEF narratives directly
+
+---
+
+## Anti-Patterns
+
+- ⊗ Rewriting the full spec in every delta (capture only what changed)
+- ⊗ Spec deltas without a Baseline narrative (orphaned deltas are useless)
+- ⊗ Skipping spec deltas for behavioral changes ("the code is the spec")
+- ⊗ Modifying archived spec deltas (history is immutable)
+- ⊗ Accumulating unmerged deltas after archiving (spec rot)
+- ⊗ Using markdown spec files (`spec.md`) — all spec deltas must be vBRIEF format

package/context/tool-design.md

@@ -0,0 +1,34 @@
+# Tool Design for AI Consumption
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+Principles for designing tools that agents can use effectively.
+
+---
+
+## Minimal, Non-Overlapping Tool Sets
+
+- ~ Provide the **smallest set of tools** that covers required capabilities
+- ≉ Offering multiple tools that do the same thing with slight variations
+- ~ Each tool should have a **single, clear purpose**
+
+## Token-Efficient Outputs
+
+- ~ Support **filtering** — let the caller request only the fields they need
+- ~ Support **pagination** — return bounded result sets with continuation tokens
+- ? Offer a **summary mode** that returns counts/metadata instead of full payloads
+- ≉ Tools that return **unbounded output** without truncation or pagination
+- ~ Default to concise output; offer verbose mode only on request
+
+## Clear Descriptions
+
+- ! **Tool descriptions** should state what the tool does, when to use it, and what it returns
+- ~ **Parameters** should be self-documenting — use descriptive names and include constraints in descriptions
+- ≉ Relying on the agent to infer parameter semantics from names alone
+
+## Error Messages
+
+- ! Return **actionable error messages** — state what went wrong and what to do about it
+- ~ Include the specific invalid input in the error so the agent can self-correct
+- ≉ Returning generic "operation failed" without remediation guidance
+- ? Suggest alternative tool calls or parameter values when possible

package/context/working-memory.md

@@ -0,0 +1,62 @@
+# Working Memory & Scratchpads
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+Patterns for externalizing intermediate state to files.
+
+---
+
+## When to Create a Scratchpad
+
+- ~ **Multi-step tasks** — when a task has 3+ phases or steps that produce intermediate artifacts
+- ~ **Large outputs** — when generated content exceeds what should stay in context
+- ~ **Multi-agent handoffs** — when passing structured state between agents
+- ? Single-step tasks with small outputs — usually not worth externalizing
+
+## Recommended Format: vBRIEF
+
+[vBRIEF](https://vbrief.org) is a token-efficient JSON format for task plans and progress tracking.
+
+**Graduated complexity:**
+1. ~ **Start minimal** — tasks with statuses are enough for simple work
+2. ~ **Add narratives** when tasks need explanation or context for another agent
+3. ~ **Add edges** (`blocks`, `informs`, `invalidates`, `suggests`) when task dependencies matter
+4. ? Use TRON encoding for ultra-compact status representation
+
+### Minimal Example
+
+```json
+{
+  "vBRIEFInfo": { "version": "0.5" },
+  "plan": {
+    "title": "Implement user avatar upload",
+    "status": "running",
+    "items": [
+      { "id": "t1", "title": "Add upload endpoint to API", "status": "completed" },
+      { "id": "t2", "title": "Write image resize utility", "status": "running" },
+      { "id": "t3", "title": "Update user profile component", "status": "pending" },
+      { "id": "t4", "title": "Add integration tests", "status": "blocked" }
+    ]
+  }
+}
+```
+
+## Cleanup
+
+- ! **Remove scratch files** when the task is complete — they are working memory, not artifacts
+- ~ **Persist durable learnings** to [meta/lessons.md](../../meta/lessons.md) before deleting scratch files
+- ≉ Leaving stale scratchpads in the workspace after task completion
+- ? Keep a scratchpad across sessions only if the task spans multiple sessions (see [long-horizon.md](./long-horizon.md))
+
+## vBRIEF Plan, Spec, and Scope Files Are NOT Scratch
+
+The cleanup rule above applies to **ad-hoc scratchpads**, not to vBRIEF files:
+
+- ⊗ Delete `./vbrief/plan.vbrief.json` as a "scratch file" — it is the session-level tactical plan (the *how right now*); when scope vBRIEFs exist, it carries a `planRef` to the scope vBRIEF(s) being implemented
+- ⊗ Delete `./vbrief/specification.vbrief.json` — it is the project-wide source-of-truth spec
+- ⊗ Delete scope vBRIEFs in lifecycle folders (`proposed/`, `pending/`, `active/`, `completed/`, `cancelled/`) — these are durable scope records
+- ⊗ Delete `./vbrief/PROJECT-DEFINITION.vbrief.json` — it is the project identity gestalt
+- ⊗ Delete `./vbrief/playbook-*.vbrief.json` — playbooks are permanent operational knowledge
+- ! Only `./vbrief/continue.vbrief.json` is ephemeral — it is consumed on resume; when scope vBRIEFs exist, it carries a `planRef` to the scope vBRIEF(s) the agent was working on
+
+**See [vbrief/vbrief.md](../vbrief/vbrief.md) for the full taxonomy of durable vs ephemeral vBRIEF files, lifecycle folders, and scope vBRIEF conventions.**

package/contracts/boundary-maps.md

@@ -0,0 +1,65 @@
+# Boundary Maps
+
+Explicit interface contracts between work units — think interfaces before implementation.
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+**⚠️ See also**: [coding/coding.md](../coding/coding.md) (Contract-First) | [verification/verification.md](../verification/verification.md) (Key Links) | [core/glossary.md](../glossary.md)
+
+> Adapted from [GSD](https://github.com/gsd-build/get-shit-done) boundary map model. Extends Deft's Contract-First principle to the planning level.
+
+---
+
+## Core Principle
+
+When planning multi-feature work, every feature declares **what it produces** and **what it consumes** from upstream — with concrete names. No vague references. No silent assumptions.
+
+---
+
+## Boundary Map Format
+
+```
+Feature 1 → Feature 2
+  Produces:
+    types.ts → User, Session, AuthToken (interfaces)
+    auth.ts  → generateToken(), verifyToken(), refreshToken()
+  Consumes: nothing (leaf node)
+
+Feature 2 → Feature 3
+  Produces:
+    api/auth/login.ts  → POST handler
+    middleware.ts       → authMiddleware()
+  Consumes from Feature 1:
+    auth.ts → generateToken(), verifyToken()
+```
+
+## Rules
+
+- ! Every feature declares **produces** — functions, types, endpoints, with names
+- ! Every feature declares **consumes** — what it needs from upstream, with source paths
+- ! Leaf nodes (no upstream) explicitly state `Consumes: nothing`
+- ! Before planning a downstream feature, **verify** that upstream actually produced what the map claims
+- ⊗ Planning downstream work based on assumed/hoped-for upstream outputs
+- ⊗ Vague produces ("auth module") — name the exports
+
+## Verification at Boundaries
+
+- ! On feature completion, check that all declared **produces** actually exist and are exported
+- ! Before starting a consuming feature, check that declared **consumes** are importable
+- ~ Use static verification (Tier 1 from [verification.md](../verification/verification.md)) for boundary checks
+- ~ Flag mismatches immediately — don't let downstream work start on a broken contract
+
+## vBRIEF Integration
+
+- ~ Record boundary maps as narratives on the plan item in `./vbrief/plan.vbrief.json`
+- ~ Use vBRIEF `blocks` edges in `./vbrief/plan.vbrief.json` to express produces/consumes dependencies
+- ~ On boundary verification failure, set downstream items to `blocked` in `./vbrief/plan.vbrief.json` with narrative
+
+---
+
+## Anti-Patterns
+
+- ⊗ "Feature 3 needs a function that feature 1 never exported"
+- ⊗ Guessing what upstream built instead of checking the boundary map
+- ⊗ Horizontal features ("implement the database layer") — prefer vertical features with demo sentences
+- ⊗ Boundary maps without concrete names (functions, types, endpoints)

package/contracts/deterministic-questions.md

@@ -0,0 +1,59 @@
+# Deterministic Questions Contract
+Canonical rule for every structured `ask_user_question` prompt and every numbered-menu prompt rendered in skill prose. Lives once here so individual skills can `!` cross-reference instead of duplicating the rule body. Surfaced by #767 after the 2026-04-30 swarm-planning session where users typed `discuss (user-provided)` to break out of a deterministic question and `wait` at a hard gate -- both honored by convention only.
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+**See also**: [main.md](../../main.md) | [glossary.md](../glossary.md) (deterministic mode entry) | [skills/deft-directive-interview/SKILL.md](../skills/deft-directive-interview/SKILL.md) (canonical interview loop) | [vbrief/completed/2026-04-20-431-deterministic-questions-rc2-defects.vbrief.json](../../vbrief/completed/2026-04-20-431-deterministic-questions-rc2-defects.vbrief.json) (RC2 prior art)
+## Prior art reviewed (#431)
+The RC2 work in #431 (closed; "Deterministic questions (RC2): confirm step, back nav, escape hatch distinct from Other") established three load-bearing properties this contract preserves rather than reimplements:
+1. **Back navigation is a first-class numbered option** -- not a sub-choice of `Other`, not a free-text escape. The agent renders `Back` as the final option in the numbered list and returns to the prior question / decision point on selection.
+2. **Escape hatch distinct from Other** -- `Other` collects free-text answers that fit the same question shape; the escape hatch is a SEPARATE option that exits the deterministic flow entirely.
+3. **Confirmation step before destructive write** -- post-interview confirmation gates (e.g. `skills/deft-directive-setup/SKILL.md` Post-Interview Confirmation Gate) are independent of the option list and ride on top of every deterministic flow.
+This contract EXTENDS that surface by promoting `Discuss` to a peer of `Back` (both are now mandatory final options) and by codifying the Discuss-pause semantic verbatim. It does NOT introduce a separate `Other` option; this contract is purely about adding `Discuss` + `Back` as canonical numbered options. The pre-#767 surface (back navigation, confirm step, Other-vs-escape distinction) remains intact.
+## The rule
+- ! Every structured `ask_user_question` prompt (single-select OR multi-select) and every numbered-menu prompt rendered in skill prose MUST include `Discuss` and `Back` as the final two numbered options, in that order. The numbering is local to the prompt (it does not need to be the literal "N-1" / "N" -- it just needs to be the last two entries presented to the user).
+- ! `Discuss` MUST be a top-level numbered option, NOT a sub-choice of any `Other` / `Custom` option. Honoring #431's escape-hatch principle.
+- ! `Back` MUST return to the prior question or decision point. Selecting `Back` from the very first question of a flow returns to the calling skill's entry-point (or surfaces "Nothing earlier to go back to" and re-asks the current question).
+- ⊗ Render a deterministic numbered menu without `Discuss` and `Back` as the final two options.
+- ⊗ Combine `Discuss` and `Other` into one option. They serve different roles -- `Other` widens the question's answer space; `Discuss` exits the question entirely.
+- ⊗ Render `Discuss` or `Back` only in some skills -- the rule is universal across every deterministic-mode skill.
+## Host-UI portability rule (#1563)
+Host-native structured question tools are allowed only when they preserve the deterministic menu the user actually sees. The visible labels and the fallback mapping are the contract; host UI affordances are not.
+- ! Deterministic flows MUST render the canonical numbered menu in plain chat text unless the host-native structured UI is known to visibly preserve the canonical numeric option labels and return numeric selections or exact displayed option text.
+- ! When a host-native structured question tool is used, each option label MUST visibly include the canonical number (for example, `1. Accept`) and the final two visible labels MUST be `N-1. Discuss` and `N. Back`.
+- ! Agents MUST accept fallback chat replies only when they match the displayed number or the exact displayed option text, after trimming surrounding whitespace and ignoring case for text labels.
+- ⊗ Infer deterministic choices from alphabetic host UI affordances, keyboard shortcuts, or semantic guesses unless those letters were actually displayed as part of the canonical menu labels.
+- ⊗ Treat a bare letter such as `d` or `b` as `Defer`, `Discuss`, or `Back` when the rendered deterministic menu was numbered and did not display those letters as choices.
+## Backend-selection prompts (#1568)
+Backend-selection prompts are deterministic questions. They ask for operator preference and MAY show probe availability as context, but availability is not a default or recommendation.
+- ! A backend-selection prompt MUST render visible numbered options for each stable backend choice before `Discuss` and `Back`.
+- ! The backend options MUST appear before the final two entries, with `Discuss` and `Back` remaining the final two numbered options in that order.
+- ! Probe availability MUST be presented as status beside each backend choice, not as the ordering, recommendation, or default.
+- ⊗ Treat `cursor-cloud` as the implicit default merely because it is probe-available.
+## Discuss-pause semantic (verbatim)
+Documented here as the single normative source so skill prose, tests, and downstream tooling all read the same words.
+- ! When the user selects `Discuss`, the agent MUST pause IMMEDIATELY.
+- ! The agent MUST halt the in-progress sequence -- no further tool calls beyond acknowledging the pause.
+- ! The agent MUST prompt: `What would you like to discuss?`
+- ! The agent MUST resume ONLY when the user explicitly signals readiness. The accepted explicit-resume signals are:
+    1. The user re-asks the original question (paraphrasing is allowed; the user must reference the question that was paused).
+    2. The user says `resume` or `continue` (case-insensitive, optionally followed by punctuation).
+    3. The user re-issues the prior selection (e.g. picks one of the numbered options again).
+- ⊗ Implicit resumption -- the agent MUST NOT auto-resume after a Discuss pause based on time elapsed, topic drift, or its own inference of "the user seems ready". Implicit resumption is forbidden.
+- ⊗ Continue executing the in-progress sequence after the user selects `Discuss`. Halting is unconditional.
+- ⊗ Make additional tool calls during a Discuss pause beyond the single acknowledgment + the resume prompt.
+- ~ The agent MAY ask focused clarification questions during the discussion -- those are part of the discussion, not the original deterministic flow.
+- ~ When the user resumes, the agent SHOULD re-render the original numbered menu before accepting a selection so the user can see the same context they were on when they paused.
+## Back semantic
+- ! When the user selects `Back`, the agent MUST treat the prior question as un-answered and re-render its numbered menu.
+- ! The agent MUST preserve any earlier captured values (the user is rewinding by one step, not aborting the flow).
+- ⊗ Treat `Back` as a Discuss pause -- `Back` is structural rewind; `Discuss` is structural exit.
+## Cross-references in skills
+Each affected skill carries a `!` cross-reference pointing here, mirroring the Rule Authority [AXIOM] block in `main.md` ("deterministic > Taskfile > vBRIEF > RFC2119 > prose; prose is fallback only when no stronger encoding applies"):
+- `skills/deft-directive-swarm/SKILL.md`
+- `skills/deft-directive-setup/SKILL.md`
+- `skills/deft-directive-refinement/SKILL.md`
+- `skills/deft-directive-pre-pr/SKILL.md`
+- `skills/deft-directive-review-cycle/SKILL.md`
+- `skills/deft-directive-release/SKILL.md`
+The `interview` and `build` skills are deliberately not edited under #767 (Agents 2 / 3 own those surfaces); the cross-reference will land there in their PRs and read this contract.
+## Test surface
+`tests/content/test_deterministic_questions.py` scans skill prose for documented numbered menus and asserts that `Discuss` and `Back` are the final two options. The test also asserts that this contract file exists, contains the verbatim Discuss-pause semantic, and is cross-referenced from each affected skill.

package/contracts/hierarchy.md

@@ -0,0 +1,77 @@
+# Contract Hierarchy
+
+Two lenses for reasoning about what to invest in — durability (what survives) and generation (what to write first).
+
+Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.
+
+**⚠️ See also**: [contracts/boundary-maps.md](./boundary-maps.md) | [coding/coding.md](../coding/coding.md) | [meta/philosophy.md](../meta/philosophy.md) | [core/glossary.md](../glossary.md)
+
+---
+
+## Durability Axis — What Survives
+
+Rank artifacts by how long they remain valid. Invest maintenance effort accordingly.
+
+```
+Standards  >  APIs  >  Specifications  >  Code
+(decades)    (years)    (months)         (weeks)
+```
+
+- ! **Standards** — coding conventions, quality gates, testing policies. These outlive any single project and rarely change. Treat them as infrastructure.
+- ! **APIs** — public interfaces, contracts, schemas. These outlive implementation cycles. Breaking changes are expensive; design them carefully.
+- ~ **Specifications** — requirements, acceptance criteria, architectural decisions. These evolve per feature cycle but anchor the work.
+- ~ **Code** — implementation. This is the most renewable layer. If the spec is clear, code can be regenerated.
+
+### Implications
+
+- ! When time is limited, invest in the higher layers first — a good spec with throwaway code beats polished code with no spec.
+- ~ When refactoring, check whether the change belongs at a higher layer (API change? spec change?) before touching code.
+- ⊗ Treat code as the primary intellectual property — specs and contracts are the real IP.
+
+---
+
+## Generative Axis — What to Write First
+
+Rank artifacts by creation order. Each layer generates the next.
+
+```
+Specification  →  Contracts  →  Code
+(what/why)       (boundaries)   (how)
+```
+
+- ! **Specification first** — define what to build and why before anything else. The spec is the source of truth for intent.
+- ! **Contracts second** — define the interfaces, data shapes, and boundaries between components. Contracts are derived from the spec.
+- ! **Code last** — implement to satisfy the contracts. Code is derived from contracts.
+
+### Implications
+
+- ! Writing code before the spec exists is building without a blueprint — the result is accidental architecture.
+- ~ Writing contracts before the spec is premature optimization of boundaries — the interfaces will shift when requirements clarify.
+- ⊗ Skip straight to implementation when requirements are unclear — write the spec first, even if it's rough.
+
+---
+
+## When Each Axis Applies
+
+**Use the durability axis** when deciding where to invest maintenance effort, what to review most carefully, and what to protect from churn.
+
+**Use the generative axis** when deciding what to write next in a development cycle — spec → contracts → code, in that order.
+
+Both axes reinforce the same core principle: **contracts are your IP, code is renewable.**
+
+---
+
+## Examples
+
+**Durability in practice:** A team spends 3 days on a REST API contract review but only 1 day reviewing the handler implementations. This is correct — the API outlives the handlers.
+
+**Generative in practice:** Before implementing a new feature, the agent writes `specification.vbrief.json` (spec), then defines boundary maps between components (contracts), then writes tests and implementation (code). Each layer constrains the next.
+
+---
+
+## Anti-Patterns
+
+- ⊗ Treating code as the deliverable and specs as paperwork — specs outlive code
+- ⊗ Designing APIs after implementation — APIs should be designed from the spec, not reverse-engineered from code
+- ⊗ Investing equally in all layers — the higher the durability, the more review it deserves
+- ⊗ Skipping the generative order — writing code before contracts leads to implicit, undocumented boundaries