@pantion/dialogs 0.2.1

package/protocol/commands/update.md

@@ -0,0 +1,205 @@
+# /pantion-update — Upgrade the Pantion Protocol itself
+
+This command upgrades the Pantion Protocol itself — the protocol files, commands, rules, and templates.
+It uses the intent documents as source and your (newer) model capabilities to improve the protocol.
+
+---
+
+## WARNING
+
+**This command modifies the protocol, not a project.**
+
+Consequences:
+- New commands may work differently than the previous version
+- Existing canons may not be fully compatible with the new protocol
+- Project specification files (spec/*) generated with the old version may be outdated
+
+**This is NOT backward compatible by default.**
+
+After an update, you must run `pantion_migrate` on every project that used the old version.
+
+---
+
+## WHEN YOU ARRIVE HERE
+
+- You have access to a more powerful model than the one Pantion was originally built with
+- You want to improve the protocol with new insights
+- You want to regenerate the protocol files based on the intent documents
+
+---
+
+## STEP 0: CHECK PREREQUISITES
+
+Verify the intent documents are present:
+
+- [ ] `protocol/pantion-intent.md` — the intent and goals of Pantion
+- [ ] `protocol/pantion-future-prompt.md` — instructions for future rebuilding
+
+If these are missing:
+"I cannot upgrade the protocol without the intent documents. These files describe WHAT Pantion should be — without them I have no source of truth for the rebuild. Do you have them available?"
+
+---
+
+## STEP 1: INVENTORY CURRENT VERSION
+
+Read all current protocol files and produce a snapshot:
+
+```markdown
+## Pantion Version Snapshot
+
+**Date:** [today]
+**Files:** [count]
+**Commands:** [list]
+**Rules:** [list]
+**Skills:** [list]
+
+### Core concepts in current version:
+- [concept 1: short description]
+- [concept 2: short description]
+- ...
+```
+
+Save as `protocol/snapshots/pantion-snapshot-[date].md` (keep this — you'll need it if the update fails).
+
+---
+
+## STEP 2: READ INTENT DOCUMENTS
+
+Read both documents carefully:
+
+### From `protocol/pantion-intent.md` extract:
+- The core principles (what MUST remain)
+- The core promise (the touchstone)
+- The two directions (forward/reverse)
+- The scale levels
+
+### From `protocol/pantion-future-prompt.md` extract:
+- What works well (KEEP)
+- What can be improved (IMPROVE)
+- What you must NOT do
+- The ultimate test
+
+---
+
+## STEP 3: DELTA ANALYSIS
+
+Compare the current protocol files with the intent documents and your own insights:
+
+"Here is my analysis of what can be improved:
+
+**Keep (works well):**
+- [element]: [why it works]
+
+**Improve (can be better with current model capabilities):**
+- [element]: [what can be better] -> [how]
+
+**Add (missing, fits the intent):**
+- [element]: [why it fits]
+
+**Remove (has become redundant):**
+- [element]: [why it's no longer needed]
+
+**Risks of this update:**
+- [risk 1]: backward compatibility impact
+- [risk 2]: ...
+
+Would you like me to proceed with this update? You can also exclude specific items."
+
+**WAIT FOR CONFIRMATION.** Do not proceed without explicit approval.
+
+---
+
+## STEP 4: REGENERATE
+
+After confirmation, regenerate the protocol files:
+
+### Order:
+1. **`pantion-core.md`** first — this is the knowledge base everything depends on
+2. **Commands** in logical order
+3. **Skills**: update bundled dialog files if needed
+4. **Souls**: update bundled soul files if needed
+
+### Rules for regeneration:
+- Each new file must respect the intent documents
+- The core principles are HARD — they must not disappear
+- The core promise is the touchstone: "code is replaceable, intent is rebuildable"
+- New concepts may only be added if they fit the intent
+- The protocol must remain simple — if it needs a 50-page manual, something is wrong
+
+---
+
+## STEP 5: SELF-CHECK
+
+After regeneration, check the new version against the intent documents:
+
+- [ ] Respects the core principles?
+- [ ] Core promise intact?
+- [ ] Not too complex?
+- [ ] No DSL or formal schema introduced?
+- [ ] Not tool-specific?
+- [ ] No features added that nobody asked for?
+- [ ] Ultimate test: can a human produce a buildable canon after one session?
+
+---
+
+## STEP 6: CHANGELOG
+
+Produce a changelog:
+
+```markdown
+# Pantion Changelog — [date]
+
+## Previous version: [snapshot date]
+## New version: [date]
+## Model: [which model performed this update]
+
+### Changed:
+- [file]: [what changed and why]
+
+### Added:
+- [file]: [why]
+
+### Removed:
+- [file]: [why]
+
+### Backward compatibility:
+- [breaking/compatible]: [impact on existing projects]
+
+### Migration needed:
+- [project type]: use `pantion_migrate` with [instruction]
+```
+
+Save as `protocol/snapshots/pantion-changelog-[date].md`.
+
+---
+
+## STEP 7: REPORT
+
+"The Pantion Protocol has been updated.
+
+**Changed:** [N] files
+**Added:** [N] files
+**Removed:** [N] files
+
+**Breaking changes:** [yes/no]
+[if yes: list]
+
+**Previous version saved in:** `protocol/snapshots/pantion-snapshot-[date].md`
+**Changelog:** `protocol/snapshots/pantion-changelog-[date].md`
+
+If you have existing projects that use Pantion:
+Run `pantion_migrate` in each project to update the project files.
+
+Would you like to keep the snapshot as a rollback option, or are you satisfied with the update?"
+
+---
+
+## META NOTE
+
+This command applies Pantion's own principles to Pantion itself:
+- The intent documents are the canon of Pantion
+- The protocol files are the derived implementation
+- `pantion_update` is essentially `pantion_reverse` + `pantion_translate` on the protocol itself
+- The snapshot is the amendment history
+
+The protocol that says "code is replaceable, intent is rebuildable" must apply that to itself as well.

package/protocol/core-advanced.md

@@ -0,0 +1,188 @@
+# Pantion DialogSpec — Advanced Protocol Knowledge
+
+> This file contains advanced protocol knowledge that is loaded on-demand
+> for specific commands (decompose, reverse, redialog, create-dialog, redialog).
+> For core protocol knowledge loaded in every session, see core.md.
+
+## Decomposition — Full Protocol
+
+Three levels:
+- **Architect Canon**: decomposes the system, defines shared boundaries
+- **Interface Canon**: describes the contract between two subsystems
+- **Component Canon**: buildable part with its own convergence
+
+Inheritance: constraints are additive (stricter is allowed, looser is not), authority budget Rights are a ceiling, Consumption is allocatable.
+
+## Interface Canon — Contract Fields
+
+Each Interface Canon describes at minimum:
+- Parties (which subsystems)
+- Delivered value (both directions)
+- Guarantees (what is always true)
+- Expectations (what may the receiver assume)
+- Failure behavior (what if something goes wrong)
+
+Plus five additional fields:
+- **Data Shape**: what is exchanged, described enumeratively (in natural language, not as a schema)
+- **Versioning/Compat**: what breaks compatibility? What is a backward-compatible change?
+- **Error Semantics**: what specific errors may B expect from A? How are they signaled?
+- **Privacy/Classification**: which data is PII, confidential, or classified? Which side may see what?
+- **Rate/Cost Expectations**: what is "normal" usage? What is a peak? Where are the limits?
+
+## Canon Anchors
+
+Canon Anchors are references to specific dialog turns. They enable traceability from derived artifacts (behavior map, acceptance tests, implementation) back to the canonical dialog.
+
+Notation: **H[N]** for HUMAN turn N, **A[N]** for ASSISTANT turn N (1-indexed).
+
+Example: H1 = first human message, A3 = third assistant message.
+
+Canon Anchors are used in:
+- Behavior Maps: every behavior links to the dialog turn that defines it
+- Acceptance Tests: every test cites the dialog turn it validates
+- Traceability Maps: full mapping from Canon Anchor to requirement to test to implementation
+- Implementation code comments: `// Canon Anchor: H3, A4`
+
+## Blind Reconstruction Test
+
+The ultimate validation of a converged canon: can a coding agent, without seeing source code, reconstruct the system from only the canon?
+
+Use `/pantion-reflect` to capture post-build observations. See `protocol/commands/reflect.md` for the full methodology.
+
+## Reverse Pantion (Code → Canon)
+
+In addition to the normal flow (Intent → Canon → Code), Pantion supports the reverse direction: analyzing an existing codebase and reconstructing the intent as a canon.
+
+Core principle: extract **what** the code does, not **how**. The output is a synthetic dialog that reads as if it were originally conducted.
+
+Applications: legacy migration, technology swap, documentation, audit, proof that intent canonization works.
+
+The output is a synthetic dialog that reads as if it were originally conducted. This dialog is the canon. A derived summary is generated alongside it.
+
+The generated canon gets STATUS: CONVERGED (REVERSE) and contains an extra AMBIGUITIES field for "bug or feature?" points. Traceability points in reverse: from canon element to source code location, with a confidence level (high/medium/low).
+
+The ultimate test: Code → Canon → Code' → behavior(Code) ≈ behavior(Code')
+
+## Re-convergence (Canon → Better Canon)
+
+The dialog is conducted by a specific model at a specific time. A newer or more capable model may identify gaps: questions that should have been asked, assumptions that were never made explicit, edge cases that were not explored. The answers to never-asked questions are simply not in the canon.
+
+**Re-convergence** is the solution: a better model reads the existing dialog, produces a gap analysis, and conducts a supplementary dialog with the user to fill those gaps. The original dialog stays intact (append-only).
+
+### How re-convergence differs from other commands
+
+| | Resume | Amend | Reconverge |
+|---|--------|-------|------------|
+| **Entry condition** | DRAFT with open questions | CONVERGED — user wants a change | CONVERGED — model identifies gaps |
+| **Who initiates** | User (wants to finish) | User (wants to change something) | Model (detects gaps) |
+| **Primary action** | Answer remaining open questions | Apply a specific change | Gap analysis → targeted supplementary dialog |
+| **Result status** | CONVERGED | AMENDED | RECONVERGED |
+
+### When to reconverge
+
+- **Model upgrade**: a significantly better model is available
+- **Periodic review**: important canons should be re-evaluated periodically
+- **Dissatisfaction**: the implementation reveals that the original convergence was too shallow
+- **New domain knowledge**: insights that weren't available during the original dialog
+- **Check recommendation**: `/pantion-check` detected thin or missing elements
+
+### Gap analysis dimensions
+
+1. **Unexplored convergence elements** — checklist items that are thin or absent
+2. **Implicit assumptions** — things assumed without being made explicit
+3. **Ambiguous resolutions** — vague answers that should have been probed further
+4. **Missing edge cases** — failure modes, boundary conditions not discussed
+5. **Authority budget gaps** — rights, consumption, or forbidden actions underspecified
+6. **Interface gaps** — contracts between components incomplete (for decomposed systems)
+
+### The future-proof promise
+
+The true future-proofing of Pantion is not just re-derivation (better artifacts from the same dialog) but **re-convergence** (a deeper dialog built on top of the original). The original dialog preserves the user's voice, decisions, priorities, and domain context — a better model uses this as a foundation, not a limitation.
+
+Use `/pantion-redialog` (alias: `/pantion-reconverge`) to initiate a redialog.
+
+## Souls (Interaction Style)
+
+A **soul** is a configurable interaction style that determines *how* the convergence dialog is conducted — the tone, pacing, jargon level, and questioning approach. It does NOT change *what* is discussed: convergence requirements (intent, constraints, success criteria, authority budget) remain identical regardless of soul.
+
+### How souls differ from skills
+
+| | Dialog | Soul |
+|---|-------|------|
+| **Determines** | What convergence elements to cover (domain-specific) | How to communicate during convergence |
+| **Examples** | Software Development, Image Description | Balanced Professional, Beginner Friendly, Young Builder |
+| **Composable** | One skill per session | One soul per session, works with any skill |
+| **Location** | `dialogs/` directory | `souls/` directory |
+
+### Soul structure
+
+```
+souls/{name}/
+├── soul.json     (manifest: name, displayName, description, version)
+└── rules.md      (interaction rules — injected into system prompt)
+```
+
+### Search order
+
+Same as skills: project-local (`souls/`) → user-global (`~/.pantion/souls/`) → bundled.
+
+### Built-in souls
+
+- **default** — Balanced Professional: clear, direct, systematic. Used when no soul is specified.
+- **beginner** — Beginner Friendly: extra explanation, less jargon, smaller steps, understanding checks.
+- **young** — Young Builder: simple language, concrete examples, encouraging tone. For young users building their first project.
+
+### Rules
+
+- Soul rules are injected into the system prompt after skill rules
+- The soul is saved in the session (traceability: which style was used)
+- If no soul is specified, the "default" soul is used
+- Soul rules must never weaken convergence requirements — they only change presentation
+- Custom souls can be created by adding a directory to `souls/` (project-local or `~/.pantion/souls/`)
+
+## Dynamic Skills (Skills from Canons)
+
+Skills can be created through Pantion dialogs, making them **model-proof**. Instead of hand-crafting dialog files, a user converges on domain knowledge through a dialog-builder dialog. The resulting canon is the source of truth from which all dialog files are derived.
+
+### Dialog Canon Structure
+
+Dynamic dialogs store their source canon alongside the derived dialog files:
+
+```
+dialogs/{name}/
+├── dialog.json                 ← DERIVED from skill-canon
+├── convergence-rules.md       ← DERIVED from skill-canon
+├── translate.md               ← DERIVED from skill-canon
+├── prompts/                   ← DERIVED from skill-canon
+│   ├── convergence-intro.md
+│   └── translate-intro.md
+└── canon/                     ← SOURCE (model-proof)
+    ├── dialog.md        ← THE CANON
+    └── summary.md       ← DERIVED
+```
+
+### The Dialog-Builder Meta-Skill
+
+The `dialog-builder` is a bundled meta-dialog that knows how to converge on domain knowledge. It guides the user through: what is this domain? What decisions matter? What do agents get wrong? What output should the dialog produce?
+
+### Dialog Canon Lifecycle
+
+- `pantion_create-dialog`: start a dialog dialog using the dialog-builder
+- `pantion_save-canon` (with `skill_name`): save the dialog canon to `dialogs/{name}/canon/`
+- `pantion_translate`: translate the dialog canon into dialog files
+- `pantion_redialog`: reconverge an existing dialog canon to deepen domain knowledge
+
+### Compatibility
+
+- Existing bundled dialogs (software, image) work exactly as before — no canon needed
+- Dynamic dialogs are loaded by the same registry with `source: 'dynamic'`
+- The three-tier search (project > user > bundled) works for both hand-crafted and dynamic dialogs
+- A dynamic dialog can override a bundled skill (project-local takes priority)
+
+### Rules
+
+- The dialog dialog is the canon — dialog files are derived
+- Dialog canons are stored in `dialogs/{name}/canon/`, NOT in the project `canon/` directory
+- Dialog canons do NOT appear in the project `canon/index.md`
+- Reconvergence on a dialog canon (`pantion_redialog`) uses dialog-builder rules
+- The dialog-builder meta-dialog is bundled and evolves only through protocol updates

package/protocol/core.md

@@ -0,0 +1,274 @@
+# 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 fast variant
+- **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://dialogs/{name}/rules` — dialog-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 (the default), this requires explicit human approval (`pantion_approve`). In dialog mode, 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 full mode (the default), all steps require explicit completion. In dialog mode, steps 2-4 are accelerated: conservative assumptions are made and the canon is auto-approved.
+
+Large projects may remain in DRAFT across multiple sessions. Use `/pantion-resume` to continue converging later.
+