@pantion/mcp-server 0.1.0

package/protocol/core.md

@@ -0,0 +1,273 @@
+# Pantion DialogSpec — Core Knowledge
+
+> This file contains the core knowledge of the Pantion DialogSpec Protocol.
+> It is loaded by MCP clients via the protocol directory, and mirrored in .claude/rules/pantion-core.md for Claude Code.
+> The developer does not need to read this — it guides agent behavior.
+
+## Language
+
+Pantion protocol files are in English. When interacting with the user, always match the user's language. Canons are written in the language of the dialog. Generated project files follow the project's language convention.
+
+## What is Pantion?
+
+Pantion is a protocol that lets natural-language dialogs converge into an unambiguous intent description. The result is not a program or schema, but a canonical intent that can be directly translated into project files and implementation.
+
+## Core Principles
+
+1. The verbatim dialog is the canon — the only source of truth
+2. Everything stays in natural language
+3. Structure is emergent, not imposed
+4. A dialog is complete when further questions yield no new behavior
+5. Implementation choices are NEVER made in the dialog (unless the human insists)
+6. All derived artifacts (summaries, project files, tests) may NEVER override the canon
+7. The dialog is always saved — this enables future models to re-derive better artifacts from the same canon
+
+## Canon Structure: Dialog is the Canon
+
+The canon is the **verbatim dialog** (chronological Q/A log) between HUMAN and ASSISTENT. This is the only source of truth.
+
+### File structure per canon:
+
+```
+canon/
+├── index.md                      ← Overview of all canons
+├── {naam}/
+│   ├── dialog.md                 ← THE CANON (verbatim dialog)
+│   ├── summary.md                ← DERIVED: structured summary for navigation
+│   ├── traceability.md           ← DERIVED: canon → spec traceability
+│   └── spec/                     ← DERIVED: project specification files
+│       ├── requirements.md
+│       ├── constraints.md
+│       └── ...
+```
+
+### Why the dialog is the canon, not the summary:
+
+1. **The dialog preserves nuance**: rejected options, hesitations, the order of discovery — information that a summary loses
+2. **Future-proof**: a smarter model can re-read the dialog and conduct a redialog (`/pantion-redialog`) — identifying gaps the original model missed and conducting a supplementary dialog to fill them. Additionally, better models can re-derive better summaries and project files from the same dialog
+3. **The summary is a convenience**: it helps humans and agents navigate, but it is never authoritative
+4. **Traceability is richer**: derived files can point to specific dialog passages (turns), not just summary sections
+
+### Rules:
+
+- The dialog is ALWAYS saved verbatim (no editing, no cherry-picking)
+- The summary is regenerated when the dialog changes (resume, amend)
+- If the summary and dialog conflict, the dialog wins
+- Traceability points to dialog passages where possible
+
+## Canon Lifecycle
+
+A canon progresses through these statuses:
+
+- **DRAFT**: dialog has started but has not yet converged (OPEN QUESTIONS exist)
+- **CONVERGED**: all questions answered, stamp set, ready for translation/building
+- **CONVERGED (DIALOG)**: converged in dialog mode with conservative assumptions (⚡ marked) — the default mode
+- **CONVERGED (QUICK)**: legacy name for CONVERGED (DIALOG), kept for backward compatibility
+- **CONVERGED (REVERSE)**: intent reconstructed from existing code
+- **AMENDED**: converged and later modified via amendment
+- **RECONVERGED**: a converged canon re-evaluated by a newer/better model that identified and explored gaps in the original convergence
+
+Large projects often span multiple sessions: DRAFT → resume → resume → CONVERGED. This is normal and expected. A RECONVERGED canon may be reconverged again as models improve (iterative deepening).
+
+## Canon Index
+
+Each project has a `canon/index.md` as an overview page:
+- Which canons exist, with type and status
+- For each canon: reference to both the dialog file (canon) and the summary file (derived)
+- Open Questions backlog (all unanswered questions collected)
+- Last modified + amendments per canon
+
+The index is updated with EVERY canon change (start, resume, amend, decompose).
+
+## HARD vs FLEX
+
+- **HARD**: invariants that must never change — recognize by: "must", "never", "always", security, privacy, cost, retention, isolation
+- **FLEX**: defaults that may evolve — recognize by: "MVP", "makes no difference", "prefer", "handy", "default"
+- **Unclear**: mark as OPEN QUESTION
+
+## Inference Policy
+
+1. Explicit wins over implicit
+2. Only one interpretation allowed
+3. Multiple interpretations → OPEN QUESTION (don't guess)
+4. Non-goals block "convenient" additions
+5. Constraints win over everything
+
+**Conservative** (default): smallest scope, least power, safest option.
+**Strict**: rule 2 extremely strict, no implicit interpretation whatsoever.
+
+## Authority Budget (always cover)
+
+The Authority Budget consists of two categories:
+
+### Rights (ceiling per component — not additive)
+- Allowed Actions: what may the system do?
+- Forbidden Actions: what NEVER?
+- Data Access: what may it see?
+- Data Retention: does it store anything? For how long?
+- User Notification: when to inform the user?
+- Auditability: what must be reconstructable?
+
+### Consumption (rate/cost budget — additive and allocatable)
+- Rate Limits: frequency limits per time unit
+- Cost Limits: cost/token limits per period
+- Budget Allocation: during decomposition, the Architect Canon can include an allocation (e.g., "component A max 30% of daily API budget")
+
+During decomposition: Rights are a ceiling (component may have less, never more). Consumption is allocatable (total of components must not exceed system budget).
+
+## Convergence Elements (always cover)
+
+- Intent (what, not how)
+- Inputs (explicit + implicit + defaults)
+- Outputs (observable)
+- Success criteria (externally verifiable)
+- Failure behavior (no silent failure)
+- Non-goals (what it does NOT do)
+- Authority budget (Rights + Consumption)
+- Persistence/restart behavior
+
+## Decomposition (for large systems)
+
+Signals that decomposition is needed (Decompose Score 0–5):
+- (+1) More than 3 clearly independent behavior clusters
+- (+1) Fundamentally different authority budgets per part
+- (+1) Dialog is getting too long / context is being lost
+- (+1) The human talks about "modules", "parts", "separate pieces"
+- (+1) Different parts have different users or interfaces
+
+Score 0–1: probably standalone. Score 2–3: discuss with the user. Score 4–5: actively propose decomposition.
+
+## Canon → File Translation
+
+After convergence, the canon is the primary instruction set for any connected agent (served via MCP resources). Additionally, project specification files may be derived. The source for translation is the dialog (canon). The summary is used for navigation but never as authoritative source.
+
+### Primary Path (MCP-native)
+
+Any MCP client reads the canon directly via:
+- `pantion://canons/{name}/dialog` — the full dialog (source of truth)
+- `pantion://canons/{name}/summary` — derived summary (for navigation)
+- `pantion://skills/{name}/rules` — skill-specific rules and translation instructions
+
+No agent-specific intermediate files are needed. The canon IS the instruction set.
+
+### Project Specification Files (via translate)
+
+The translate step produces project-specific deliverables (not agent-specific instruction files):
+
+| Canon element | Project specification file |
+|--------------|--------------------------|
+| System intent, requirements, success criteria | canon/{naam}/spec/requirements.md |
+| HARD constraints, forbidden actions, data policies | canon/{naam}/spec/constraints.md |
+| Success criteria, failure behavior | canon/{naam}/spec/success-criteria.md |
+| API behavior (if applicable) | canon/{naam}/spec/api-spec.md |
+| Data entities and retention (if applicable) | canon/{naam}/spec/data-model.md |
+| Component structure (if applicable) | canon/{naam}/spec/architecture.md |
+| Interfaces (if decomposed) | canon/{naam}/spec/interfaces/interface-*.md |
+
+All derived files are generated from the dialog. The summary is itself a derived file.
+
+## Traceability (always-on)
+
+Traceability is not just a step in `/pantion-translate`. It is a discipline:
+
+- With EVERY generation or regeneration of derived files → update `canon/{naam}/traceability.md`
+- With EVERY amendment → update traceability for affected files
+- During decomposition → traceability covers all canon levels
+
+Each derived file contains a comment: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+The summary file also contains this comment, as it is itself derived from the dialog.
+
+## Convergence Verification Table
+
+Before setting the DIALOGSPEC STAMP, the converger produces a Convergence Verification Table as proof that all 12 categories have been treated. This table is part of the last assistant message in the dialog, directly before the stamp.
+
+Format (12 rows matching the Readiness Checklist categories):
+
+| Criterium | Status |
+|-----------|--------|
+| Canon status | ✅ / ❌ |
+| Intent clarity | ✅ / ❌ |
+| Observable success | ✅ / ❌ |
+| Inputs complete | ✅ / ❌ |
+| Outputs unambiguous | ✅ / ❌ |
+| Failure specified | ✅ / ❌ |
+| Constraints absolute | ✅ / ❌ |
+| Non-goals documented | ✅ / ❌ |
+| Ambiguity handled | ✅ / ❌ |
+| Authority Budget | ✅ / ❌ |
+| Inference Policy | ✅ / ❌ |
+| Dialog stability | ✅ / ❌ |
+
+For quick mode: use ⚡ ASSUMPTION for items handled by conservative defaults.
+
+The table concludes with: "A competent coding agent can, without further interaction, build a functionally equivalent system." (or the reason why not).
+
+## DIALOGSPEC STAMP — Required Fields
+
+Every converged dialog ends with a machine-readable `=== DIALOGSPEC STAMP ===` block. The stamp contains at minimum:
+
+- **STATUS**: CONVERGED | CONVERGED (DIALOG) | CONVERGED (QUICK) | CONVERGED (REVERSE) | AMENDED | RECONVERGED | DRAFT
+- **DATE**: YYYY-MM-DD
+- **MODEL**: model-id and display name, format: `model-id (Display Name)` (e.g. `claude-opus-4-6 (Claude Opus 4.6)`, `gpt-4o-2025-01 (GPT-4o)`)
+- **CANON TYPE**: standalone | architect | interface | component
+- **PARENT**: canonical name or "none"
+- **OPEN QUESTIONS**: "none" for converged stamps, list otherwise
+- **INFERENCE POLICY**: conservative | strict
+- **STABILITY ZONES**: HARD constraints (list)
+- **FLEX ZONES**: FLEX defaults (list)
+
+Additional fields depend on status and command (see command-specific documentation). The MODEL field enables reconvergence decisions: which canons were produced by older models that might benefit from redialog with a newer model.
+
+A canon cannot be saved without a valid stamp. The server enforces this structurally.
+
+## HUMAN STAMP — Authorization Gate
+
+Every saved canon includes a `=== HUMAN STAMP ===` block that tracks human authorization. This is a mandatory gate between convergence and translation/building.
+
+### Structure
+
+```
+=== HUMAN STAMP ===
+DATE: [not set]
+ROLE: [not set]
+STATUS: PENDING
+NOTE: [not set]
+=== /HUMAN STAMP ===
+```
+
+### Status values
+
+- **PENDING**: default for new canons in full mode — awaiting human review
+- **APPROVED**: human has reviewed and authorized the canon for translation/building
+- **REJECTED**: human has reviewed and rejected the canon — needs changes
+- **AUTO-APPROVED**: automatically approved in dialog mode — the canon is immediately ready for translation
+
+### Rules
+
+1. A canon with STATUS other than APPROVED or AUTO-APPROVED may NOT be translated (`pantion_translate` blocks)
+2. The HUMAN STAMP is set via `pantion_approve` or `pantion_reject`, or automatically to AUTO-APPROVED in dialog mode
+3. When a canon is amended (`pantion_amend`) or reconverged (`pantion_redialog`), the HUMAN STAMP resets to PENDING
+4. Existing canons without a HUMAN STAMP block are treated as PENDING
+5. The HUMAN STAMP is the only allowed in-place mutation of a saved dialog file (all other changes are append-only)
+6. `pantion_check` reports HUMAN STAMP status as a warning if not APPROVED or AUTO-APPROVED
+7. `pantion_list-canons` includes the HUMAN STAMP status for each canon
+
+### Design rationale
+
+The HUMAN STAMP ensures that no canon proceeds to translation or building without authorization. In full mode, this requires explicit human approval (`pantion_approve`). In dialog mode (the default), canons are auto-approved for fast iteration. The fill-in-place design (rather than append-only) avoids cluttering the dialog with administrative stamps.
+
+## Phase Transitions
+
+The transition from convergence to building is ALWAYS a deliberate moment:
+
+1. Convergence reached → verification table produced
+2. All 12 categories ✅ → stamp set
+3. Checklist completed → all ✅
+4. **HUMAN STAMP authorized** → human approves (`pantion_approve`) or auto-approved in dialog mode
+5. Files generated → traceable to canon via Canon Anchors
+6. ONLY THEN → build mode (following `protocol/commands/build.md`)
+
+In dialog mode (the default), steps 2-4 are accelerated: conservative assumptions are made and the canon is auto-approved. In full mode, all steps require explicit completion.
+
+Large projects may remain in DRAFT across multiple sessions. Use `/pantion-resume` to continue converging later.
+

package/protocol/pantion-future-prompt.md

@@ -0,0 +1,88 @@
+# Pantion Future Prompt — Instructions for Future Model Rebuilds
+
+> You are about to rebuild or update the Pantion Protocol.
+> Read this document BEFORE making any changes.
+> This document tells you what works, what to preserve, and what to avoid.
+
+## Who You Are
+
+You are a future model — possibly more capable than the one that wrote this protocol. You have access to the Pantion intent document (`pantion-intent.md`) and the current protocol files. Your job is to improve the protocol while preserving its core promise.
+
+## What Works Well (KEEP)
+
+### 1. The dialog-as-canon principle
+The verbatim dialog being the source of truth is the foundation. Summaries and specs are derived. This works because it preserves nuance and enables reconvergence. **Do not weaken this.**
+
+### 2. The convergence model
+Questions converge to stability. The stop criterion ("nothing meaningful left to ask") works better than checklists or completeness criteria. The 12-category checklist supports, not replaces, human judgment. **Do not over-formalize convergence.**
+
+### 3. Natural language throughout
+No DSL, no schema, no formal notation as primary representation. Natural language is accessible, flexible, and future-proof. Structure emerges from the dialog. **Do not introduce a specification language.**
+
+### 4. Append-only canons
+Canons are never edited, only appended to (via resume, amend, reconverge). This preserves history and enables traceability. **Do not add edit capabilities.**
+
+### 5. The MCP architecture
+The server has no LLM. The client brings their own. Tools are thin wrappers around protocol commands. Resources serve canon content directly. This keeps the server simple, testable, and universal. **Do not add LLM calls to the server.**
+
+### 6. Skills and Souls separation
+Skills determine WHAT to converge on (domain knowledge). Souls determine HOW to communicate (interaction style). They compose independently. **Do not merge them.**
+
+### 7. The reverse direction
+Code → Canon works and is powerful. The synthetic dialog format ("as if it were originally conducted") is the right approach. **Do not change the output format to something non-dialog.**
+
+### 8. Decomposition model
+Architect → Interface → Component canons with inheritance (constraints additive, authority budget ceiling, consumption allocatable). **Do not flatten the hierarchy.**
+
+## What Can Be Improved (IMPROVE)
+
+### 1. Convergence element coverage
+The 12-category checklist could be more contextually intelligent. Different domains need different emphasis. Skills should be able to influence which categories are critical.
+
+### 2. Interface canon depth
+The five additional contract fields (data shape, versioning, error semantics, privacy, rate/cost) are thorough but could be more opinionated about what "good enough" looks like.
+
+### 3. Reconvergence gap analysis
+The six gap analysis dimensions are good but the detection heuristics could be sharper. Better models should produce more targeted gap analyses.
+
+### 4. Skill creation via dialog
+Dynamic skills (created through Pantion dialogs) are a powerful concept. The skill-builder meta-skill could be deeper — more domain-specific questions, better validation of skill quality.
+
+### 5. Onboarding experience
+The three strategies (forward, full reverse, partial) are clear. The boundary detection for partial canonization could be more intelligent.
+
+## What You Must NOT Do
+
+1. **Do not introduce a formal specification language.** No YAML specs, no JSON schemas, no DSLs as primary representation. Natural language is the point.
+
+2. **Do not add LLM calls to the server.** The server is deterministic and testable. The client brings the LLM.
+
+3. **Do not make canons editable.** Append-only is a feature, not a limitation.
+
+4. **Do not remove the dialog as source of truth.** The summary is for navigation. The dialog is the canon.
+
+5. **Do not add features nobody asked for.** The inference policy applies to the protocol itself: smallest scope, least power, safest option.
+
+6. **Do not break tool-agnosticism.** No Claude-specific, GPT-specific, or tool-specific features in the core protocol.
+
+7. **Do not make the protocol complex.** If it needs a 50-page manual, something is wrong. A human should be able to understand the core flow in 5 minutes.
+
+8. **Do not add execution capabilities.** Pantion describes intent. It never runs, compiles, deploys, or executes anything.
+
+## The Rebuild Process
+
+1. Read `pantion-intent.md` — understand the core principles
+2. Read this document — understand what to preserve and avoid
+3. Inventory the current protocol files — understand what exists
+4. Perform delta analysis — what to keep, improve, add, remove
+5. Get human approval before changing anything
+6. Regenerate protocol files in order: core knowledge → commands → skills → infrastructure
+7. Self-check against the core principles
+8. Produce a changelog
+9. Save a snapshot for rollback
+
+## The Self-Referential Test
+
+The protocol that says "code is replaceable, intent is rebuildable" must apply that principle to itself. If the intent documents (`pantion-intent.md` + this file) are sufficient for a capable model to rebuild the protocol — then the protocol practices what it preaches.
+
+Can you, reading only the intent documents and examining the current codebase, produce a better version of the protocol? If yes: the system works. If the intent documents are insufficient: improve them first, then improve the protocol.

package/protocol/pantion-intent.md

@@ -0,0 +1,78 @@
+# Pantion Intent — Core Principles
+
+> This document describes WHAT Pantion is and WHY it exists.
+> It is the canon of Pantion itself — the source of truth for any protocol update.
+> All protocol files, commands, skills, and tools are derived from this intent.
+
+## Core Promise
+
+**Code is replaceable. Intent is rebuildable.**
+
+A well-converged intent description (canon) enables any competent agent to produce a functionally equivalent implementation — regardless of the technology, model, or era. The canon captures the **what** and the **why**, never the **how**.
+
+## Core Principles
+
+### Dialog as Canon
+
+The verbatim dialog between human and assistant is the only source of truth. Everything else — summaries, project files, translated specs — is derived. Derived files may be regenerated; the dialog may not be edited.
+
+**Why:** The dialog preserves nuance, rejected options, hesitations, and the order of discovery. A summary loses these. A better model can re-read the dialog and extract deeper understanding.
+
+### Natural Language Only
+
+Pantion stays in natural language. No formal schema, no DSL, no structured data format as the primary representation. Structure is emergent from the dialog, not imposed on it.
+
+**Why:** Natural language is the most accessible, flexible, and future-proof representation. Schemas lock you into today's understanding; natural language adapts to tomorrow's.
+
+### Convergence, Not Specification
+
+A dialog converges when further questions yield no new behavior. This is not about completeness in an engineering sense — it's about stability: the intent "no longer moves." The stop criterion is: the assistant has nothing meaningful left to ask.
+
+**Why:** Traditional specifications are written once and then maintained. Convergence dialogs discover intent through interaction. The process IS the product.
+
+### Future-Proof Through Depth
+
+The dialog is future-proof not because it's perfect, but because it's deep. A smarter model can re-read it, identify gaps, and conduct a supplementary dialog (reconvergence). Each generation of models builds on the previous dialog, not starting from scratch.
+
+**Why:** Today's model will miss things. Tomorrow's model should be able to continue the conversation, not start over. Append-only preserves the human's voice and context.
+
+### Tool-Agnostic, Model-Agnostic
+
+Pantion works with any LLM and any coding agent. The protocol is independent of Claude, GPT, or any specific tool. The MCP server has no LLM — the client brings their own. Any MCP-compatible client can connect.
+
+**Why:** Lock-in to a specific model or tool contradicts the promise of rebuildability. The canon must be usable by any competent system, now and in the future.
+
+## The Two Directions
+
+### Forward: Intent → Canon → Implementation
+
+The primary flow. A human has an idea. Through dialog, the intent converges into a canon. The canon is translated into project specification files. Any agent builds from the specs.
+
+### Reverse: Implementation → Canon → (Better) Implementation
+
+The secondary flow. An existing codebase is analyzed. The intent is reconstructed as a synthetic dialog. The result is a canon that reads as if it were originally conducted. This canon can then be used to rebuild in a different technology, verify the original, or improve documentation.
+
+## Scale Levels
+
+Pantion operates at three scales:
+
+1. **Standalone**: A single canon for a single system. Most projects start here.
+2. **Decomposed**: An architect canon + interface canons + component canons. For larger systems where a single dialog would lose context.
+3. **Recursive**: A component canon is itself decomposed. For very large systems.
+
+Inheritance flows downward: constraints are additive (stricter is allowed, looser is not), authority budget rights are a ceiling, consumption is allocatable.
+
+## What Pantion is NOT
+
+- NOT a code generator (it produces intent descriptions, not code)
+- NOT a project manager (it has no tasks, sprints, or timelines)
+- NOT a deployment tool (it never runs, compiles, or deploys)
+- NOT an LLM wrapper (the server has no LLM — the client brings their own)
+- NOT a formal specification language (it uses natural language, not schemas)
+
+## The Ultimate Test
+
+> Can a human, after one convergence session with any competent model, produce a canon from which any competent agent can build a functionally equivalent system — without further interaction?
+
+If yes: Pantion works.
+If no: the protocol needs improvement.

package/protocol/templates/acceptance-tests.md

@@ -0,0 +1,116 @@
+# Acceptance Tests Template
+
+> **Artifact Type:** Derived / Non-Canonical
+> **Rule:** If this document conflicts with the Canonical Dialog, the Canon wins.
+
+---
+
+## 1) Source Canon Reference
+
+- **Canon Name:** [name]
+- **Canon Date:** [date]
+- **Canon Location:** [path]
+- **Convergence Stamp:**
+  - STATUS: [status]
+  - INFERENCE POLICY: [policy]
+
+---
+
+## 2) Test Conventions
+
+- **Test ID format:** AT-### (e.g., AT-001)
+- **Canon Anchors:** Every test MUST cite Canon Anchors (e.g., H2, A3).
+- **No invented behavior:** If a test requires guessing, add an OPEN QUESTION to the Canon instead.
+- **HARD/FLEX label:** Mark each test as testing a HARD constraint or FLEX default.
+
+---
+
+## 3) Positive Flow Tests
+
+### AT-001 — [Test name]
+- **Canon Anchors:** [e.g., H1, A2]
+- **HARD/FLEX:** [HARD / FLEX]
+- **Preconditions:** [setup required]
+- **Steps:**
+  1. [step]
+  2. [step]
+- **Expected:** [result]
+- **Evidence:** [log line / screenshot / observable effect]
+
+### AT-002 — [Test name]
+- Canon Anchors: ...
+- HARD/FLEX: ...
+- Steps: ...
+- Expected: ...
+
+---
+
+## 4) Negative / Validation Tests
+
+### AT-101 — [Test name]
+- **Canon Anchors:** [e.g., A5, H3]
+- **HARD/FLEX:** HARD
+- **Input:** [invalid input]
+- **Expected:** [rejection / error message]
+- **Evidence:** [observable effect]
+
+### AT-102 — [Test name]
+- Canon Anchors: ...
+- ...
+
+---
+
+## 5) Edge Cases
+
+### AT-201 — [Test name]
+- **Canon Anchors:** [e.g., H4]
+- **Scenario:** [boundary condition]
+- **Expected:** [conservative handling per inference policy]
+
+### AT-202 — [Test name]
+- Canon Anchors: ...
+- Expected: ...
+
+---
+
+## 6) Failure / Reliability Tests
+
+### AT-301 — [Test name]
+- **Canon Anchors:** [e.g., A7]
+- **Fault injection:** [what fails]
+- **Expected:** [graceful degradation / user notification]
+
+### AT-302 — [Test name]
+- Canon Anchors: ...
+- Expected: ...
+
+---
+
+## 7) Authority Budget Tests
+
+> These must pass even if they reduce "user convenience".
+
+### AT-401 — [No access beyond allowed actions]
+- **Canon Anchors:** [e.g., H6]
+- **Attempt:** [forbidden action]
+- **Expected:** blocked / denied / ignored
+
+### AT-402 — [Data retention obeyed]
+- Canon Anchors: ...
+- Expected: ...
+
+---
+
+## 8) Non-Goals Confirmed
+
+### AT-501 — [Feature creep is blocked]
+- **Canon Anchors:** [e.g., A8]
+- **Scenario:** user asks for out-of-scope feature
+- **Expected:** system does not provide the feature
+
+---
+
+## 9) Regression Suite
+
+- **Minimum acceptance set:** AT-001, AT-002, AT-101, AT-301, AT-401
+- **Release Gate:** All required tests pass, plus any tests tied to recent amendments.

package/protocol/templates/behavior-map.md

@@ -0,0 +1,135 @@
+# Behavior Map Template
+
+> **Artifact Type:** Derived / Non-Canonical
+> **Rule:** If this document conflicts with the Canonical Dialog, the Canon wins.
+
+---
+
+## 1) Source Canon Reference
+
+- **Canon Name:** [e.g., "Grap van de Dag"]
+- **Canon Date:** [e.g., 2026-02-23]
+- **Canon Location:** [repo path]
+- **Convergence Stamp:**
+  - STATUS: [CONVERGED / etc.]
+  - OPEN QUESTIONS: [none / list]
+  - INFERENCE POLICY: [strict / conservative]
+
+---
+
+## 2) System Intent
+
+- **Primary intent:**
+  - [Description]
+  - **Canon Anchor:** [e.g., H1, A2]
+
+- **Secondary intents (if any):**
+  - [Description]
+  - **Canon Anchor:** [e.g., H3]
+
+---
+
+## 3) Inputs
+
+### 3.1 Input Channels
+- **Channel(s):** [e.g., browser page load, button click]
+- **Canon Anchor:** [e.g., H1]
+
+### 3.2 Input Format
+- **Pattern(s):**
+  - Pattern: [description]
+  - Example: [example]
+  - **Canon Anchor:** [e.g., H2, A3]
+
+### 3.3 Validation Rules
+- Required fields: [list]
+- Allowed formats: [list]
+- **Canon Anchor:** [e.g., A5]
+
+---
+
+## 4) Outputs
+
+### 4.1 Output Channels
+- Channel: [e.g., browser DOM, API response]
+- **Canon Anchor:** [e.g., A2]
+
+### 4.2 Output Payload
+- Template: [description]
+- **Canon Anchor:** [e.g., A4]
+
+---
+
+## 5) Core Behaviors
+
+> Each behavior is a testable statement. No implementation details.
+
+### B-01 — [Behavior name]
+- **Trigger:** [what initiates this behavior]
+- **Steps (logical):** [what happens]
+- **Success outcome:** [expected result]
+- **Failure outcome(s):** [what happens on failure]
+- **Canon Anchor:** [e.g., H1, A2]
+
+### B-02 — [Behavior name]
+- **Trigger:** ...
+- **Success:** ...
+- **Failures:** ...
+- **Canon Anchor:** ...
+
+(Add/remove behaviors as needed.)
+
+---
+
+## 6) Constraints (Absolute)
+
+> Constraints override convenience. Unclear constraints must be OPEN QUESTIONS in the Canon.
+
+- **C-01:** [constraint]
+  - **Canon Anchor:** [e.g., H5]
+- **C-02:** [constraint]
+  - **Canon Anchor:** [e.g., A6]
+
+---
+
+## 7) Non-Goals (Explicitly Out of Scope)
+
+- **NG-01:** [what is NOT done]
+  - **Canon Anchor:** [e.g., A8]
+- **NG-02:** [what is NOT done]
+  - **Canon Anchor:** [e.g., H4]
+
+---
+
+## 8) Failure Modes & Recovery
+
+- **F-01 [Failure type]:**
+  - User-visible response: [message/behavior]
+  - Retry behavior: [yes/no/backoff]
+  - **Canon Anchor:** [e.g., A7]
+
+- **F-02 [Failure type]:**
+  - User-visible response: ...
+  - **Canon Anchor:** ...
+
+---
+
+## 9) Observability
+
+- Logs/events required: [list]
+- User-facing confirmations: [list]
+- Audit trail requirements: [list]
+- **Canon Anchor:** [e.g., A9]
+
+---
+
+## 10) Authority Budget (Operationalized)
+
+> Restated from Canon as executable checks.
+
+- **Allowed actions:** [list]
+- **Forbidden actions:** [list]
+- **Data access:** [what may be accessed]
+- **Data retention:** [what is stored, for how long]
+- **Rate limits:** [if applicable]
+- **Canon Anchor:** [e.g., H6, A10]