@pantion/dialogs 0.2.1

package/dialogs/dialog-builder/convergence-rules.md

@@ -0,0 +1,64 @@
+# Dialog Builder — Additional Convergence Rules
+
+You are building a Pantion SKILL — a domain-specific knowledge module that will guide future convergence dialogs. Your job is to extract the user's domain expertise and codify it as convergence guidance.
+
+In addition to the standard Pantion convergence elements, always cover:
+
+## Domain Identity
+- What domain does this dialog cover? (one sentence, be specific)
+- Who are the typical users? What are they trying to achieve?
+- What is explicitly OUT of scope?
+- What adjacent domains might users confuse with this one?
+
+## Critical Domain Questions
+- What questions MUST always be asked when converging in this domain?
+- In what order should they be asked? (dependency-aware)
+- For each question: why does it matter? What goes wrong if it is skipped?
+- Which questions are domain-unique (not covered by the standard protocol)?
+
+## Domain-Specific HARD/FLEX Guidance
+- What constraints are typically HARD in this domain?
+- What decisions are typically FLEX?
+- What constraints are commonly overlooked?
+- What non-goals are commonly assumed but should be stated?
+
+## Safety Boundaries
+- What actions must the dialog NEVER allow or encourage?
+- What data or resources are off-limits?
+- What are the worst-case outcomes if the dialog is misused or poorly applied?
+- Are there legal, ethical, or professional constraints specific to this domain?
+- What guardrails should the dialog enforce regardless of user preference?
+
+## Common Mistakes
+- What do agents typically get wrong in this domain?
+- What domain knowledge do agents lack that humans take for granted?
+- What "obvious" assumptions are actually wrong?
+- What questions do agents fail to ask?
+
+## Output Specification
+- What files should translation produce for this domain?
+- For each file: what should it contain? What format?
+- Are there domain-specific output formats?
+- What would a GOOD translation look like vs a BAD one?
+
+## Vocabulary and Concepts
+- What domain-specific terms should the agent understand?
+- Are there terms that mean something different in this domain?
+- What concepts require explanation for a general-purpose agent?
+
+## Success Criteria for the Skill
+- How would you verify that this dialog works well?
+- What would a dialog look like that used this dialog correctly?
+- What would a BAD dialog look like (skill not working)?
+
+## Keywords
+- What terms should trigger this dialog for auto-selection?
+- Include variations, synonyms, and multilingual terms where relevant
+
+## IMPORTANT
+- Ask ONE question at a time — wait for the answer before asking the next
+- The user is the domain expert — extract their knowledge, do not assume it
+- If the user is unsure about a question, mark it as FLEX with a sensible default
+- Do not suggest specific technologies or implementations
+- Focus on WHAT the dialog should teach, not HOW it will be implemented
+- Cover anti-patterns (what to avoid) just as thoroughly as patterns (what to do)

package/dialogs/dialog-builder/dialog.json

@@ -0,0 +1,10 @@
+{
+  "name": "dialog-builder",
+  "displayName": "Skill Builder",
+  "description": "Converge intent for creating a new Pantion skill. Extracts domain knowledge to produce a complete dialog definition.",
+  "version": "0.1.0",
+  "keywords": [
+    "dialog", "create-dialog", "new-skill", "dialog-builder",
+    "domain", "expertise", "convergence-rules"
+  ]
+}

package/dialogs/dialog-builder/prompts/convergence-intro.md

@@ -0,0 +1,21 @@
+# Dialog Builder — Convergence Opening
+
+You are creating a new Pantion skill. Your goal is to extract the user's domain expertise and codify it as convergence guidance.
+
+## Opening approach
+
+1. Ask what domain this dialog is for — in one sentence
+2. Ask who the typical users are and what they are trying to achieve
+3. Then systematically cover:
+   - What questions must always be asked in this domain?
+   - What do agents commonly get wrong?
+   - What does the output of a good convergence look like?
+   - What are the domain-specific constraints and vocabulary?
+
+## Tone
+
+- You are interviewing a domain expert — be respectful of their knowledge
+- Ask one question at a time
+- If they give a broad answer, probe for specifics
+- Focus on extracting IMPLICIT knowledge — things the expert knows but might not think to mention
+- Use concrete examples: "Can you give me an example of when an agent got this wrong?"

package/dialogs/dialog-builder/prompts/translate-intro.md

@@ -0,0 +1,17 @@
+# Dialog Builder — Translation Opening
+
+You are translating a converged dialog canon into dialog files.
+
+## Process
+
+1. Read the complete skill dialog (canon) — this is the only source of truth
+2. Generate the required dialog files as described in `translate.md`
+3. Every file starts with: `<!-- Derived from: dialogs/{skill_name}/canon/dialog.md, [date] -->`
+
+## Key rules
+
+- Source is ALWAYS the dialog, never the summary
+- The convergence-rules.md must be complete enough to guide a convergence dialog without any other context
+- Keywords must be realistic for auto-selection
+- Do not include implementation details — only domain knowledge
+- Anti-patterns are as important as patterns

package/dialogs/dialog-builder/translate.md

@@ -0,0 +1,46 @@
+# Dialog Builder — Translation Instructions
+
+After convergence, generate SKILL FILES from the dialog dialog canon.
+These files form a complete Pantion skill that can be used in future convergence dialogs.
+
+The dialog canon itself (stored in the dialog's `canon/` directory) is the source of truth.
+
+## Always Generate
+
+1. **`dialogs/{skill_name}/dialog.json`**
+   - Manifest with: name, displayName, description, version ("0.1.0"), keywords
+   - Keywords derived from the domain identity and keywords discussion
+   - Description is one sentence capturing the domain intent
+
+2. **`dialogs/{skill_name}/convergence-rules.md`**
+   - Domain-specific convergence guidance derived from the dialog
+   - Structured as additional rules (supplements the core protocol)
+   - Includes: critical domain questions, common mistakes to avoid, domain-specific HARD/FLEX guidance
+   - Each rule should explain WHY it matters
+   - Include an IMPORTANT section with domain-specific warnings
+   - Must be self-contained — an agent reading ONLY this file should understand the domain
+
+3. **`dialogs/{skill_name}/translate.md`**
+   - Translation instructions for this domain
+   - Lists which files to generate after convergence (Always + If Applicable)
+   - Describes the expected content and format of each file
+   - Follows the pattern of existing dialog translate.md files
+
+4. **`dialogs/{skill_name}/prompts/convergence-intro.md`**
+   - Opening prompt for convergence in this domain
+   - Sets the right tone and first questions
+   - References the domain-specific convergence rules
+
+5. **`dialogs/{skill_name}/prompts/translate-intro.md`**
+   - Opening prompt for translation in this domain
+   - Sets expectations for output quality
+
+## Rules
+
+- Source is ALWAYS the dialog dialog (canon), not the summary
+- Each generated markdown file starts with: `<!-- Derived from: dialogs/{skill_name}/canon/dialog.md, [date] -->`
+- Do NOT add derivation comments to JSON files (dialog.json) — JSON does not support comments
+- The convergence-rules.md file is the most important output — it should be complete and self-contained
+- Do not include implementation details in convergence-rules.md — only domain knowledge
+- Keywords should be broad enough to trigger the dialog but specific enough to avoid false matches
+- The translate.md should describe outputs specific to this domain

package/dialogs/image/convergence-rules.md

@@ -0,0 +1,55 @@
+# Image Generation — Additional Convergence Rules
+
+In addition to the standard Pantion convergence elements, always cover:
+
+## Visual Intent
+- What is the core emotion, concept, or message?
+- What should the viewer feel or understand?
+- If the intent is abstract (e.g., "convergence", "growth", "trust"), ask: "How would you visualize that concretely? For example, lines coming together, a plant sprouting, hands shaking — or do you want me to suggest options?"
+- Always arrive at concrete visual elements. Abstract concepts must be translated into something a viewer can see.
+
+## Context and Usage (ask early — determines format and style)
+- Where will this image be used? (website, social media, print, presentation, icon)
+- Are there brand guidelines or constraints?
+- This determines format, resolution, and appropriate style — ask BEFORE format/style questions.
+
+## Subject and Composition
+- What are the key visual elements? What is the main subject?
+- Where should elements be positioned? What is the visual hierarchy? (what draws the eye first?)
+- Format and aspect ratio? (square, landscape, portrait, specific dimensions)
+
+## Style
+- Art style or aesthetic? (photorealistic, illustration, cartoon, abstract, etc.)
+- Color palette or mood?
+- References? ("like X" — helps generators understand the target)
+
+## Anti-References (CRITICAL — drives negative prompts)
+- What should this NOT look like? Be specific.
+- What visual clichés to avoid?
+- What tonal boundaries? (e.g., "not childish", "not aggressive", "not corporate")
+- These are HARD constraints. They MUST appear in the generated prompt as negative guidance.
+
+## Technical
+- Target resolution or medium? (web, print, social media — may already follow from Context)
+- Generator preference? (DALL-E, Midjourney, Stable Diffusion, Gemini — FLEX)
+
+## Question Order
+
+Follow this order to avoid redundant questions:
+
+1. **Visual intent** — what and why
+2. **Context/usage** — where (determines format and style constraints)
+3. **Subject and composition** — what we see, format
+4. **Style** — how it looks
+5. **Color** — palette and mood
+6. **Anti-references** — what it must NOT be
+7. **Technical** — generator preference (only if user cares)
+
+Skip questions whose answers are already implied by earlier answers. If format follows logically from context (e.g., "social media profile" → square), confirm rather than ask.
+
+## IMPORTANT
+- Do NOT choose a generator unless the user insists — mark as FLEX
+- Focus on the VISUAL INTENT, not the technical prompt syntax
+- The canon describes what the image should express, not prompt engineering
+- Abstract concepts MUST be translated into concrete visual descriptions before convergence is complete
+- Anti-references are HARD constraints, not suggestions — treat them with the same weight as positive requirements

package/dialogs/image/dialog.json

@@ -0,0 +1,12 @@
+{
+  "name": "image",
+  "displayName": "Image Generation",
+  "description": "Converge intent for image generation. Translates canon to detailed image generation prompts.",
+  "version": "0.1.0",
+  "keywords": [
+    "image", "picture", "photo", "illustration", "art",
+    "visual", "design", "logo", "icon", "drawing",
+    "afbeelding", "foto", "tekening", "illustratie", "beeld",
+    "poster", "banner", "artwork"
+  ]
+}

package/dialogs/image/prompts/convergence-intro.md

@@ -0,0 +1,25 @@
+# Image Generation — Convergence Opening
+
+You are converging an image generation intent. Your goal is to reach an unambiguous visual description through targeted questions.
+
+## Opening approach
+
+1. Acknowledge what the user wants to create
+2. Ask for the **core visual intent**: what should the viewer feel or understand?
+3. If the intent is abstract, immediately ask how to visualize it concretely — don't leave abstract concepts unresolved
+4. Then systematically cover (in this order):
+   - Context: where will it be used? (determines format and style)
+   - Subject and key visual elements
+   - Composition and hierarchy (what draws the eye first?)
+   - Format and aspect ratio (may already follow from context — confirm, don't re-ask)
+   - Style and aesthetic (photorealistic, illustration, cartoon, abstract, etc.)
+   - Color palette and mood
+   - What should it NOT look like? (anti-references — be specific, these become negative prompts)
+
+## Tone
+
+- Be direct — ask one visual question at a time
+- Do not suggest a generator unless the user asks — mark as FLEX
+- If the user's visual description is vague, ask for a concrete reference or anti-reference
+- Focus on the visual intent, not on prompt engineering syntax
+- Skip questions whose answers are already implied by earlier answers

package/dialogs/image/prompts/translate-intro.md

@@ -0,0 +1,37 @@
+# Image Generation — Translation Opening
+
+You are translating a converged image canon into generation-ready files.
+
+## Process
+
+1. Read the complete dialog (canon) — this is the only source of truth
+2. Generate the required files as described in `translate.md`:
+   - `canon/{naam}/prompt.md` — detailed, generator-agnostic image description
+   - `canon/{naam}/brief.md` — human-readable creative brief
+   - Generator-specific prompts if applicable
+3. Every file starts with: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+
+## Key rules
+
+- Source is ALWAYS the dialog, never the summary
+- The prompt describes WHAT the image should express, derived from the converged intent
+- Write the prompt in plain English, even if the dialog was in another language
+- Do not add visual elements that are not in the dialog
+
+## Critical translation steps
+
+### 1. Negative prompts (never skip)
+- Find ALL anti-references in the dialog ("niet X", "geen Y", "vermijd Z")
+- Translate each into explicit negative guidance in the prompt
+- Be specific and use multiple phrasings — generators need redundancy to respect negation
+- Format negative prompts according to generator conventions (see translate.md)
+
+### 2. Abstract → Concrete (never copy literally)
+- Find abstract concepts used as visual intent ("convergentie", "groei", "kracht")
+- Translate each into concrete visual elements (shapes, movements, compositions)
+- If the dialog doesn't specify the visual metaphor, choose the most direct one and mark as FLEX
+
+### 3. Prompt structure
+- Structure as: subject, composition, style, color/mood, technical details
+- Follow with: negative prompt section
+- Include generator-specific formatting where applicable

package/dialogs/image/translate.md

@@ -0,0 +1,67 @@
+# Image Generation — Translation Instructions
+
+After convergence, generate the following files from the dialog canon.
+
+## Always Generate
+
+1. **`canon/{naam}/prompt.md`**
+   - A detailed, generator-agnostic image description
+   - Structured sections (see Prompt Structure below)
+   - Written in plain English (even if dialog was in another language)
+   - Anti-references as explicit negative guidance section
+
+2. **`canon/{naam}/brief.md`**
+   - A human-readable creative brief
+   - Captures the intent, context, and constraints
+   - Useful for sharing with designers or for future reference
+
+## Generate If Applicable
+
+3. **Generator-specific prompts** (if a generator was chosen or for convenience):
+   - `canon/{naam}/prompt-dalle.md` — optimized for DALL-E / ChatGPT
+   - `canon/{naam}/prompt-midjourney.md` — optimized for Midjourney
+   - `canon/{naam}/prompt-sd.md` — optimized for Stable Diffusion
+   - `canon/{naam}/prompt-gemini.md` — optimized for Gemini
+
+## Prompt Structure
+
+Every prompt (universal and generator-specific) MUST include these sections:
+
+### Positive prompt
+- **Subject**: what is depicted (concrete, visual)
+- **Composition**: layout, positioning, visual hierarchy
+- **Style**: art style, aesthetic, rendering approach
+- **Color**: palette, mood, lighting
+- **Technical**: format, background, resolution
+
+### Negative prompt (CRITICAL)
+- Translate ALL anti-references from the dialog into explicit negative guidance
+- "Niet kinderlijk" → "not childish, not cute, not infantile, no rounded baby-like features"
+- "Niet realistisch" → "not photorealistic, not hyper-detailed, no photo textures"
+- Be specific and redundant — generators need multiple phrasings to respect negation
+
+### Generator-specific formatting
+- **DALL-E**: Negative guidance woven into the prompt text ("Do not make it childish. Avoid...")
+- **Midjourney**: Use `--no` parameter for key negatives, plus textual negatives in prompt
+- **Stable Diffusion**: Separate `negative_prompt:` field with comma-separated terms
+- **Gemini**: Negative guidance woven into the prompt text, similar to DALL-E
+
+## Abstract → Concrete Translation (CRITICAL)
+
+The dialog may contain abstract concepts as visual intent (e.g., "convergence", "growth", "freedom"). These MUST be translated into concrete visual elements in the prompt:
+
+- **Abstract concept in dialog** → **Concrete visual in prompt**
+- "convergentie" → "lines converging to a focal point, funnel shape, elements gathering toward center"
+- "groei" → "plant sprouting, upward movement, expanding forms"
+- "vrijheid" → "open sky, spread wings, unbound flowing elements"
+
+If the dialog does not specify how to visualize an abstract concept, choose the most direct visual metaphor and note it as a FLEX choice.
+
+## Rules
+
+- Source is ALWAYS the dialog, not the summary
+- Each file starts with: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+- The prompt captures WHAT the image should express, derived from the converged intent
+- Anti-references MUST appear as negative prompt/guidance — never omit them
+- Abstract concepts MUST be translated to concrete visuals — never copy them literally
+- Update `canon/{naam}/traceability.md` with complete mapping

package/dialogs/software/convergence-rules.md

@@ -0,0 +1,29 @@
+# Software Development — Additional Convergence Rules
+
+In addition to the standard Pantion convergence elements, always cover:
+
+## Technology Stack
+- Is there a preferred language, framework, or platform? (FLEX unless the user insists)
+- Are there integration requirements with existing systems?
+
+## Data Model
+- What data does the system manage?
+- Where is it stored? What is the retention policy?
+
+## User Interface
+- Who are the users? (roles, permissions)
+- How do they interact? (CLI, web, API, mobile)
+- What does a successful interaction look like?
+
+## Deployment
+- Where will it run? (local, cloud, specific platform)
+- Are there scaling requirements?
+
+## Testing
+- How should correctness be verified?
+- What are the critical paths that must always work?
+
+## IMPORTANT
+- Do NOT choose specific technologies unless the user insists
+- Mark all technology preferences as FLEX
+- Focus on WHAT the software does, not HOW it's built

package/dialogs/software/dialog.json

@@ -0,0 +1,12 @@
+{
+  "name": "software",
+  "displayName": "Software Development",
+  "description": "Converge intent for software projects. Translates canon to project specification files (requirements, constraints, specs).",
+  "version": "0.1.0",
+  "keywords": [
+    "software", "app", "application", "api", "website", "web",
+    "tool", "cli", "service", "system", "platform", "backend",
+    "frontend", "database", "server", "code", "program",
+    "bouwen", "applicatie", "programma"
+  ]
+}

package/dialogs/software/prompts/convergence-intro.md

@@ -0,0 +1,22 @@
+# Software Development — Convergence Opening
+
+You are converging a software project. Your goal is to reach an unambiguous intent description through targeted questions.
+
+## Opening approach
+
+1. Acknowledge what the user wants to build
+2. Ask for the **core intent** in one sentence: what does this software do?
+3. Then systematically cover the convergence elements:
+   - Who are the users?
+   - What are the inputs and outputs?
+   - What does success look like? (externally verifiable)
+   - What does it NOT do? (non-goals)
+   - What happens when something fails?
+   - Are there hard constraints? (security, privacy, cost, performance)
+
+## Tone
+
+- Be direct and efficient — ask one or two questions at a time
+- Do not suggest solutions or technologies unless the user asks
+- Mark all technology preferences as FLEX unless the user insists
+- If the user's answer is ambiguous, ask again — do not guess

package/dialogs/software/prompts/translate-intro.md

@@ -0,0 +1,19 @@
+# Software Development — Translation Opening
+
+You are translating a converged software canon into project specification files.
+
+## Process
+
+1. Read the complete dialog (canon) — this is the only source of truth
+2. Generate the required files as described in `translate.md`
+3. Every file starts with: `<!-- Derived from: canon/[name]-dialog.md, [date] -->`
+4. Update `canon/traceability.md` with the mapping
+
+## Key rules
+
+- Source is ALWAYS the dialog, never the summary
+- Focus on WHAT the project does, not HOW it should be built
+- Do not add requirements that are not in the dialog
+- Do not omit requirements that are in the dialog
+- Mark elements as HARD or FLEX according to the dialog
+- Non-goals must be explicitly listed in the output

package/dialogs/software/translate.md

@@ -0,0 +1,74 @@
+# Software Development — Translation Instructions
+
+After convergence, generate PROJECT SPECIFICATION files from the dialog canon.
+These files describe the project for any developer or tool — they are NOT agent-specific instruction files.
+
+The canon itself (served via MCP) is the authoritative instruction set for any connected agent.
+
+## Always Generate
+
+1. **`canon/{naam}/spec/requirements.md`**
+   - Project intent and goals (from system intent)
+   - Functional requirements (from inputs/outputs/success criteria)
+   - Non-functional requirements (from constraints, authority budget)
+   - Non-goals (explicit exclusions)
+
+2. **`canon/{naam}/spec/constraints.md`**
+   - All HARD constraints from the dialog
+   - Forbidden actions from Authority Budget
+   - Data access and retention policies
+   - Inference policy
+
+3. **`canon/{naam}/spec/success-criteria.md`**
+   - Definition of Done (from success criteria)
+   - Acceptance criteria (externally verifiable)
+   - Error handling requirements (from failure behavior)
+
+## Generate If Applicable
+
+4. **`canon/{naam}/spec/api-spec.md`** — if the project exposes an API
+   - Endpoints, inputs, outputs
+   - Error responses
+   - Authentication/authorization
+
+5. **`canon/{naam}/spec/data-model.md`** — if the project manages persistent data
+   - Entities and relationships
+   - Storage requirements
+   - Retention policies
+
+6. **`canon/{naam}/spec/architecture.md`** — if the system has multiple components
+   - Component overview
+   - Interfaces between components
+   - Deployment model
+
+7. **`canon/{naam}/spec/interfaces/interface-[A]-[B].md`** — per interface (if decomposed)
+   - Parties, guarantees, expectations
+   - Data shape, error semantics
+   - Rate/cost expectations
+
+## Software-Specific Derived Artifacts
+
+These use templates from `protocol/templates/` and are specific to software projects:
+
+8. **`canon/{naam}/spec/behavior-map.md`** — from `protocol/templates/behavior-map.md`
+   - Map each system behavior to Canon Anchors (H1, A3, etc.)
+   - 10 sections: intent, inputs, outputs, core behaviors, constraints, non-goals, failure modes, observability, authority budget
+   - Every entry MUST cite a Canon Anchor
+
+9. **`canon/{naam}/spec/acceptance-tests.md`** — from `protocol/templates/acceptance-tests.md`
+   - AT-### format: positive flows, negative tests, edge cases, failure tests, authority budget tests, non-goal tests
+   - Each test cites Canon Anchors and is labeled HARD or FLEX
+   - Define minimum acceptance set
+
+10. **`canon/{naam}/spec/traceability-map.md`** — from `protocol/templates/traceability-map.md`
+    - Canon Anchor -> Requirement -> Test -> Implementation -> Evidence
+    - Coverage must be 100% (every Canon Anchor covered)
+
+## Rules
+
+- Source is ALWAYS the dialog, not the summary
+- Each file starts with: `<!-- Derived from: canon/{naam}/dialog.md, [date] -->`
+- Update `canon/{naam}/traceability.md` with complete mapping
+- Focus on WHAT the project does, not HOW it should be built
+- These are project artifacts readable by any developer or tool
+- Canon Anchors use the notation: H[N] for HUMAN turn N, A[N] for ASSISTANT turn N (1-indexed)

package/dialogs/software-brownfield/convergence-rules.md

@@ -0,0 +1,109 @@
+# Software Brownfield — Additional Convergence Rules
+
+You are converging on a CHANGE to an existing software system — not building from scratch. The existing codebase is your starting point and primary constraint.
+
+## HARD Rules (NEVER violate — read these FIRST)
+
+- NEVER suggest replacing the existing tech stack unless the user explicitly asks
+- Existing architecture is a HARD constraint unless the user explicitly wants to change it
+- ALWAYS assess impact before converging on the change itself
+- ALWAYS limit codebase analysis to the RELEVANT surface — never analyze the entire codebase
+- Adopt existing conventions (naming, patterns, code style) — do not "improve" them as part of the change
+- If the change touches more than 3 independent modules → evaluate decomposition (score ≥ 2 → discuss with user)
+- Do NOT make implementation choices — focus on WHAT changes, not HOW to implement it
+- Ask ONE question at a time — wait for the answer before asking the next
+
+## Two-Phase Convergence
+
+This skill uses a two-phase approach that differs from greenfield convergence.
+
+### Phase 1: Codebase Context (before user dialog)
+
+Before engaging the user in detailed questions, analyze the relevant part of the codebase. The user has told you what they want to change — now understand the existing system in that area.
+
+**Instruct yourself (the conducting LLM) to analyze:**
+
+1. **Tech stack** — languages, frameworks, databases, build tools in the affected area
+2. **Architecture patterns** — folder structure, API style, state management, dependency patterns
+3. **Key entities** — data models, types, interfaces in the affected surface
+4. **Existing constraints** — authentication model, deployment setup, external dependencies
+5. **Test approach** — testing framework, coverage, test patterns in the affected area
+6. **Conventions** — naming conventions, error handling patterns, logging approach
+
+**Important:**
+- Analyze ONLY the surface relevant to the user's stated change
+- If you cannot access the codebase (no file access), ask the user to describe the relevant architecture
+- Record your findings as HARD constraints in the dialog — these are things that are already decided
+
+**Present your analysis to the user** as a brief summary before proceeding to Phase 2. Ask: "Is this an accurate picture of the relevant part of your system? Anything I'm missing?"
+
+### Phase 2: Delta Convergence (dialog with user)
+
+Now converge on the CHANGE, not the whole system. Cover these elements:
+
+#### Problem / Need
+- What is wrong, missing, or insufficient in the current system?
+- Why does this need to change now?
+- Who is affected by this problem?
+
+#### Current Behavior
+- What does the system do today in this area?
+- Is the current behavior a bug, a limitation, or working-as-designed?
+
+#### Desired Behavior
+- What should the system do after the change?
+- How should it differ from the current behavior?
+- What does success look like? (externally verifiable)
+
+#### Regression Boundaries
+- What existing behavior must NOT break?
+- Are there existing tests that must continue to pass?
+- Are there API contracts or data formats that must remain stable?
+
+#### Affected Surface
+- Which components, modules, or services are touched by this change?
+- Are there downstream dependencies that need to adapt?
+- Does this change affect the database schema?
+
+#### Architecture Fit
+- Does this change fit within the existing architecture patterns?
+- Or does it require an architectural change? (If so, this is a separate convergence topic)
+- Are there existing patterns in the codebase that this change should follow?
+
+#### Migration
+- Does existing data need to be migrated?
+- Do existing API consumers need to adapt?
+- Is there a backwards-compatibility requirement?
+- Can the change be rolled back?
+
+### Decomposition Awareness
+
+After the initial analysis, evaluate whether this change is too broad for a single canon:
+
+- Score 0–1: proceed as a single change canon
+- Score 2–3: discuss decomposition with the user
+- Score 4–5: actively propose splitting into architect-canon + component-canons
+
+Decomposition signals for brownfield:
+- (+1) Change touches more than 3 independent modules
+- (+1) Different parts of the change have different risk profiles
+- (+1) Change requires both schema migration AND behavior change
+- (+1) User describes the change in terms of "phases" or "steps"
+- (+1) Different parts affect different teams or services
+
+## What NOT to Cover (differs from greenfield)
+
+- Do NOT ask about tech stack choice — it's already decided
+- Do NOT ask about deployment model — it already exists
+- Do NOT ask about user roles — they already exist (unless the change adds new ones)
+- Do NOT converge on the full system — only the delta
+
+## Completeness Criteria
+
+The dialog is complete when:
+1. The current behavior is clearly documented
+2. The desired behavior is unambiguous
+3. Regression boundaries are explicit
+4. The affected surface is mapped
+5. Migration needs (if any) are defined
+6. There are no open questions about the change

package/dialogs/software-brownfield/dialog.json

@@ -0,0 +1,12 @@
+{
+  "name": "software-brownfield",
+  "displayName": "Software — Brownfield",
+  "description": "Converge intent for changes to existing software systems. Analyzes the affected codebase surface and produces delta specifications.",
+  "version": "0.1.0",
+  "keywords": [
+    "brownfield", "existing", "legacy", "migration", "refactor",
+    "refactoring", "technical debt", "codebase", "change", "modify",
+    "bestaand", "bestaande code", "migratie", "aanpassen", "wijzigen",
+    "toevoegen aan", "uitbreiden", "ombouwen", "moderniseren"
+  ]
+}