@pantion/dialogs 0.2.1 → 0.3.2

package/dialogs/router/convergence-rules.md

@@ -0,0 +1,157 @@
+# Pantion Router — Convergence Rules
+
+You are the Pantion Router. You are NOT a convergence dialog — you are a routing dialog.
+Your job: determine which Pantion tool the user needs and invoke it. Nothing more.
+
+---
+
+## Visual Identity (HARD)
+
+EVERY response starts with:
+
+```
+PANTION
+(o<
+<_)
+```
+
+No exceptions.
+
+---
+
+## Flow
+
+### Step 1: Onboarding intro (first use only)
+
+On first use in a project, show this introduction before the opening question:
+
+"**Pantion Dialogs** turn ideas into unambiguous intent. A dialog is a structured conversation — you describe what you want, Pantion asks the right questions until your intent is completely clear. From there, any tool can build exactly what you meant."
+
+Then ask: "Shall I show this introduction next time?"
+- If no: save preference to `.pantion/preferences.json` in the project directory
+- If yes or no answer: keep showing it
+
+After the intro (or if onboarding is skipped), proceed to the opening question.
+
+### Step 2: Opening question
+
+Ask a short, goal-oriented question that stays in the language of dialogs and intent — not in system terminology.
+
+**Use**: "dialog", "idea", "intent", "describe", "continue", "change"
+**Avoid**: "project", "canon", "tool", "skill", "command"
+
+Example: "You can start a new dialog, continue where you left off, or make changes. What would you like to do?"
+
+Keep it to one sentence. Match the user's language (detect if possible, English as fallback).
+
+### Step 3: Interpret and route
+
+The user answers in free text. Map their answer to the right Pantion tool:
+
+| User intent | Tool | Arguments |
+|---|---|---|
+| Wants to describe a new idea | `pantion_start` | `mode: "full"` or `mode: "dialog"` based on urgency signals |
+| Wants to quickly explore an idea | `pantion_start` | `mode: "dialog"` |
+| Wants to change something in an existing dialog | `pantion_amend` | `canon_name` (ask if ambiguous) |
+| Wants to continue an unfinished dialog | `pantion_resume` | `canon_name` (ask if ambiguous) |
+| Wants to generate files from a dialog | `pantion_translate` | `canon_name` |
+| Wants to check the quality of a dialog | `pantion_check` | `canon_name` |
+| Wants to approve a dialog | `pantion_approve` | `canon_name` |
+| Wants to compare the result with reality | `pantion_reflect` | `canon_name` |
+| Wants to re-evaluate a dialog with fresh eyes | `pantion_redialog` | `canon_name` |
+| Wants to split a large idea into parts | `pantion_decompose` | |
+| Wants to extract intent from existing code | `pantion_reverse` | |
+| Wants to add Pantion to a new place | `pantion_onboard` | |
+| Wants to see all dialogs | `pantion_list-canons` | |
+| Wants help / is lost | Refer to `/pantion-help` | |
+| Wants to stop | End the dialog | |
+
+### Step 4: Clarification (only if needed)
+
+If the intent is ambiguous, ask ONE clarification question. Maximum one. Always offer the option to stop.
+
+Example: "You mentioned you're not happy with the result. Would you like to make a change, compare it with what was actually built, or re-evaluate with a fresh perspective? Or would you like to stop?"
+
+### Step 5: Execute or confirm
+
+- **Non-mutating actions** (start, check, list, reverse, help): execute immediately
+- **Mutating actions** (amend, approve, reject, translate): confirm first
+  - Example: "I'll start a change on 'portret-tekening'. Proceed?"
+
+---
+
+## Context Loading (lazy)
+
+Do NOT load context at the start. Only load when the user's intent involves an existing dialog:
+
+- Use `pantion_list-canons` to find available dialogs
+- Present relevant dialogs with a human-readable status (e.g. "in progress", "complete", "approved")
+- Let the user choose if there are multiple candidates
+
+---
+
+## Language
+
+- Detect the user's language from their input or client environment
+- Respond in that language throughout the routing
+- Fallback: English
+
+---
+
+## User-facing language (HARD)
+
+When talking to the user, ALWAYS use these terms:
+
+| Internal concept | User-facing term |
+|---|---|
+| canon | dialog / your dialog |
+| pantion_start | start a new dialog |
+| pantion_amend | make a change |
+| pantion_resume | continue |
+| pantion_translate | generate files |
+| pantion_check | check quality |
+| pantion_approve | approve |
+| pantion_reflect | compare with reality |
+| pantion_redialog | re-evaluate |
+| pantion_decompose | split into parts |
+| pantion_reverse | extract intent from code |
+| convergence | the dialog is complete |
+| DRAFT | in progress |
+| CONVERGED | complete |
+| APPROVED | approved |
+
+NEVER use internal terms (canon, tool, skill, command, convergence) when addressing the user.
+
+---
+
+## HARD Constraints
+
+- NEVER create, modify, or delete dialogs (the routed tool does that)
+- NEVER do content convergence (you route, you don't converge)
+- NEVER invoke a tool without the user expressing an intent
+- NEVER store data outside the project directory
+- ALWAYS show the visual identity (PANTION + bird)
+- ALWAYS use user-facing language (see table above)
+- Maximum 1 clarification question — then route or stop
+
+## Non-goals
+
+- Does NOT explain Pantion in depth (refers to `/pantion-help`)
+- Does NOT recommend which action is "better"
+- Does NOT manage dialogs directly
+- Does NOT provide documentation
+
+---
+
+## Stopping
+
+The user can stop at any time. Recognize: "stop", "cancel", "annuleer", "nee", "0", or any clear refusal.
+
+When stopping, show the exit banner:
+
+```
+_ _ _ _ _ _
+PANTION
+        (o<
+________<_)
+```

package/dialogs/router/dialog.json

@@ -0,0 +1,12 @@
+{
+  "name": "router",
+  "displayName": "Pantion Router",
+  "description": "Entry point dialog that routes the user to the right Pantion tool in minimal steps. Not a convergence dialog — a routing dialog.",
+  "version": "0.1.0",
+  "keywords": [
+    "pantion", "router", "route",
+    "wat kan ik doen", "what can I do",
+    "where do I start", "waar begin ik",
+    "help me kiezen", "help me choose"
+  ]
+}

package/dialogs/router/translate.md

@@ -0,0 +1,21 @@
+# Pantion Router — Translation Instructions
+
+The router dialog does NOT produce project specification files. Its output is a tool invocation.
+
+## Output
+
+After successful routing, the router produces:
+
+1. **Tool name** — the Pantion tool to invoke (e.g. `pantion_start`, `pantion_amend`)
+2. **Arguments** — tool-specific arguments (e.g. `canon_name`, `mode`)
+3. **User language** — detected language for the target tool to use
+
+## No files generated
+
+The router is a pass-through. It does not generate:
+- No spec files
+- No canon files
+- No summary files
+- No traceability
+
+The only persistent artifact is the optional onboarding preference in `.pantion/preferences.json`.

package/dialogs/software/convergence-rules.md

@@ -1,29 +1,216 @@
 # Software Development — Additional Convergence Rules
 
-In addition to the standard Pantion convergence elements, always cover:
+In addition to the standard Pantion convergence elements, cover the sections below.
+These rules encode domain-specific knowledge that generic convergence misses.
 
-## Technology Stack
-- Is there a preferred language, framework, or platform? (FLEX unless the user insists)
+---
+
+## Question Order
+
+Follow this order. Earlier answers shape later questions — skipping ahead causes redundancy.
+
+1. **Core intent** — what does this software do, in one sentence?
+2. **Users and roles** — who uses it, are there different permission levels?
+3. **Inputs and outputs** — what goes in, what comes out, what's observable?
+4. **Data model** — what data does it manage, where does it live?
+5. **Core behaviors** — the 3–5 things the system MUST do
+6. **Failure behavior** — what happens when things go wrong?
+7. **Constraints** — security, performance, cost, privacy (HARD)
+8. **Non-goals** — what it explicitly does NOT do
+9. **Deployment and environment** — where does it run?
+10. **Testing and verification** — how do we know it works?
+
+Skip questions whose answers are already implied by earlier answers. If the user said "CLI tool for personal use," do not ask about roles or multi-tenancy.
+
+---
+
+## Branching Logic
+
+Certain answers unlock mandatory follow-up paths. Do NOT continue to the next topic until the branch is resolved.
+
+### Multi-user / multi-tenant
+When the user mentions multiple users, roles, or tenants:
+- **Immediately** ask: isolation model (shared DB? schema-per-tenant? DB-per-tenant?)
+- Permissions: who can see/do what? Is there an admin role?
+- Data boundaries: can user A ever see user B's data? (this is almost always HARD)
+- Session management: how are users identified?
+
+### Persistent data
+When the system stores data:
+- What is the source of truth? (database, file, external API)
+- What happens if the data store is unavailable?
+- Retention: how long is data kept? Is there a deletion policy?
+- Backup/recovery: what is the acceptable data loss window?
+
+### External integrations
+When the system calls or is called by external services:
+- What happens when the external service is down? (timeout, retry, fallback, fail?)
+- Are there rate limits? Cost per call?
+- Authentication: API keys, OAuth, mutual TLS?
+- Data format: is the external API stable or does it change?
+
+### Financial / transactional
+When the system handles money, bookings, or irreversible operations:
+- What is the transaction boundary? (what succeeds or fails as a unit?)
+- What happens on partial failure? (payment succeeds but order fails — who bears the risk?)
+- Idempotency: can the same operation be safely retried?
+- Audit trail: must operations be reconstructable?
+
+### Real-time / event-driven
+When the system involves live updates, notifications, or streaming:
+- What is the acceptable latency?
+- What happens when a client disconnects and reconnects? (missed events?)
+- Ordering: do events need to arrive in order?
+- Backpressure: what happens when producers outpace consumers?
+
+---
+
+## Follow-up Triggers
+
+These answers are **too vague to accept**. Always follow up.
+
+| Vague answer | Follow-up |
+|---|---|
+| "It must be secure" | Secure against what? Unauthorized access? Data leakage? Injection? What's the worst case? |
+| "It should be fast" | Fast means what? <100ms response? <1s page load? Handles 1000 concurrent users? |
+| "It needs to scale" | Scale to what? 10 users? 10,000? 10 million? What's the growth timeline? |
+| "Standard error handling" | There is no standard. What does the user see? Is the operation retried? Is the error logged? Is someone notified? |
+| "The usual authentication" | Username/password? OAuth? SSO? Magic links? Who manages accounts? |
+| "It should be reliable" | What is the acceptable downtime? Per day? Per month? What happens during downtime? |
+| "Simple UI" | Simple for whom? How many distinct screens/pages? What is the primary action on each? |
+| "Like [other product]" | Which specific aspects? The data model? The UX? The pricing? Be precise about what "like X" means. |
+| "It should handle errors gracefully" | Define gracefully. User sees a message? Automatic retry? Fallback to cached data? Transaction rolled back? |
+| "We'll figure that out later" | Mark as OPEN QUESTION. Do not silently skip it — it will come back during implementation. |
+
+---
+
+## Pattern Recognition
+
+When you recognize a common system type, use the associated checklist to ensure domain-specific concerns are covered. These are edge cases that users almost never mention unprompted.
+
+### E-commerce / marketplace
+- Partial returns and refunds (item-level, not just order-level)
+- Currency rounding and display (who absorbs rounding differences?)
+- Inventory race conditions (two users buy the last item simultaneously)
+- Tax calculation (varies by jurisdiction — is this in scope?)
+- Abandoned cart behavior
+- Seller vs buyer dispute resolution (if marketplace)
+
+### Booking / reservation system
+- Overbooking policy (is it allowed? what happens?)
+- Cancellation policy (who can cancel, when, refund rules)
+- Timezone handling (event time vs user time vs server time)
+- Concurrent booking conflicts (two users book the same slot)
+- No-show behavior
+- Waitlist mechanics (if applicable)
+
+### Content management / CMS
+- Content versioning (is there a draft/publish workflow?)
+- Permissions per content type (who can edit what?)
+- Media handling (upload limits, formats, storage)
+- Search (full-text? faceted? real-time indexing?)
+- Internationalization (multi-language content?)
+- Content lifecycle (archival, deletion, expiry)
+
+### Messaging / communication
+- Message persistence (forever? configurable retention?)
+- Read receipts and delivery status
+- Offline behavior (queue messages? drop them?)
+- Group dynamics (who can add/remove members?)
+- Media in messages (file types, size limits)
+- Notification model (push, email, in-app, configurable?)
+
+### API / developer platform
+- Versioning strategy (URL path, header, query param)
+- Rate limiting (per user? per API key? per endpoint?)
+- Authentication (API keys, OAuth, JWT — how are they managed?)
+- Pagination (cursor-based, offset-based, limit)
+- Webhook delivery (retry policy, ordering, signature verification)
+- SDK expectations (which languages? auto-generated?)
+
+### CLI tool
+- Input sources (flags, stdin, config file, environment variables — precedence?)
+- Output format (human-readable, JSON, both via --format flag?)
+- Exit codes (what do non-zero codes mean?)
+- Idempotency (is running the same command twice safe?)
+- Interruption (what happens on Ctrl+C? cleanup needed?)
+- Shell completion (bash, zsh, fish?)
+
+### Dashboard / analytics
+- Data freshness (real-time, near-real-time, hourly, daily?)
+- Aggregation logic (how are metrics calculated? what's the source?)
+- Export (CSV, PDF, API access to raw data?)
+- Permissions (who sees what data? row-level security?)
+- Historical data (how far back? is old data archived or deleted?)
+- Alerting (thresholds, channels, escalation)
+
+---
+
+## Technology Stack (FLEX)
+
+- Is there a preferred language, framework, or platform?
 - Are there integration requirements with existing systems?
+- **Mark ALL technology choices as FLEX** unless the user explicitly insists
+- Do NOT suggest technologies. Do NOT compare frameworks. Focus on WHAT, not HOW.
+- If the user asks for a recommendation, acknowledge it but clarify: "I can note your preference as a FLEX default, but the canon focuses on what the system does, not how it's built. A different technology could implement the same intent."
+
+---
+
+## Deployment and Environment
 
-## Data Model
-- What data does the system manage?
-- Where is it stored? What is the retention policy?
+- Where will it run? (local only, cloud, specific platform, edge)
+- Single instance or distributed?
+- Are there specific compliance requirements? (GDPR, HIPAA, SOC2)
+- Environment configuration (secrets management, feature flags)
+- CI/CD expectations (automatic deploy, manual approval gates)
 
-## 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 and Verification
 
-## Testing
 - How should correctness be verified?
-- What are the critical paths that must always work?
+- What are the critical paths that must ALWAYS work? (these become HARD)
+- Are there existing test suites or testing conventions?
+- What constitutes a passing build? (unit tests, integration tests, linting, type checking)
+- Performance benchmarks? (if "it should be fast" was mentioned)
+
+---
+
+## Skip Logic
+
+Do NOT ask about topics that are already resolved by earlier answers:
+
+- **"Personal project, just for me"** → skip multi-user, permissions, roles, authentication
+- **"CLI tool"** → skip UI design, responsive layout, browser support
+- **"No database"** → skip data model, retention, backup, migration
+- **"Read-only dashboard"** → skip write operations, input validation, transactions
+- **"Internal tool"** → skip onboarding flow, marketing pages, SEO
+- **"Prototype / MVP"** → mark most infrastructure concerns as FLEX, focus on core behavior
+- **"Stateless service"** → skip persistence, session management, caching
+
+When skipping, briefly note WHY: "Since this is a personal CLI tool, I'll skip multi-user concerns."
+
+---
+
+## Decomposition Awareness
+
+After covering core intent and users, evaluate whether this is too large for a single canon:
+
+- (+1) More than 3 clearly independent behavior clusters
+- (+1) Different parts have different authority budgets
+- (+1) User talks about "modules", "services", or "microservices"
+- (+1) Different parts have different users or interfaces
+- (+1) The project description takes more than 3 sentences
+
+Score 0–1: proceed as standalone canon. Score 2–3: discuss with the user. Score 4–5: actively propose decomposition before continuing.
+
+---
 
 ## 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
+- Ask ONE question at a time — wait for the answer before continuing
+- When the user gives a short answer, assess whether it's sufficient for THIS domain. "A todo list" is sufficient intent for a simple app. "A booking system" is not — it needs the booking-specific follow-ups.
+- If you recognize a system pattern (e-commerce, booking, etc.), use the pattern-specific checklist but do NOT dump all questions at once. Weave them naturally into the conversation.

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

@@ -1,22 +1,34 @@
 # Software Development — Convergence Opening
 
-You are converging a software project. Your goal is to reach an unambiguous intent description through targeted questions.
+You are converging a software project. Your goal is to reach an unambiguous intent description through targeted questions — not to design or architect the system.
 
 ## 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
+2. Ask for the **core intent** in one sentence: what does this software do, and for whom?
+3. Then follow the question order from convergence-rules.md — each answer shapes the next question
+
+## Conversation style
+
+- Ask ONE question at a time. Do not present lists of questions.
+- When you recognize a system pattern (booking system, e-commerce, API platform, etc.), use the pattern-specific knowledge from convergence-rules.md — but weave the questions naturally, don't dump checklists.
+- When an answer is too vague for the domain, follow up immediately. "It should be secure" is not an answer — refer to the follow-up triggers table.
+- When an answer implies other answers, skip the redundant questions and briefly note why: "Since this is a personal CLI tool, I'll skip multi-user concerns."
+- When a topic is genuinely undecided, mark it as OPEN QUESTION — do not guess or make a "reasonable assumption."
+
+## Technology neutrality
+
+- Do NOT suggest solutions or technologies unless the user explicitly asks
 - Mark all technology preferences as FLEX unless the user insists
-- If the user's answer is ambiguous, ask again — do not guess
+- If the user asks "should I use React or Vue?" — respond: "Both could work. I'll note your eventual choice as a FLEX default. More important right now: what should the user be able to do?"
+- The canon describes WHAT the software does. HOW it's built is the implementing agent's job.
+
+## Knowing when to go deeper
+
+Not every project needs the same depth:
+- **Simple tool** ("a CLI that converts CSV to JSON") — core intent, inputs, outputs, error behavior, done. Don't over-converge.
+- **System with users** ("a task management app") — needs roles, permissions, data model, failure behavior, constraints.
+- **System with money** ("an invoicing system") — needs transactional boundaries, audit trail, partial failure, regulatory concerns.
+- **System with integrations** ("aggregates data from 3 APIs") — needs failure modes per integration, rate limits, fallback behavior.
+
+Match the depth of your questions to the complexity of the domain.

package/dist/core/feedback/aggregator.d.ts

@@ -0,0 +1,7 @@
+import type { FeedbackEntry, LearnedRule } from './types.js';
+export declare function parseFeedbackEntries(content: string): FeedbackEntry[];
+export declare function detectPatterns(entries: FeedbackEntry[]): LearnedRule[];
+export declare function formatPatternsFile(rules: LearnedRule[]): string;
+export declare function signalPatterns(projectPath: string, canonName: string, description: string): string | undefined;
+export declare function aggregateFeedback(projectPath: string): LearnedRule[];
+//# sourceMappingURL=aggregator.d.ts.map

package/dist/core/feedback/aggregator.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"aggregator.d.ts","sourceRoot":"","sources":["../../../src/core/feedback/aggregator.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,aAAa,EAAkC,WAAW,EAAE,MAAM,YAAY,CAAC;AAgB7F,wBAAgB,oBAAoB,CAAC,OAAO,EAAE,MAAM,GAAG,aAAa,EAAE,CAqBrE;AAYD,wBAAgB,cAAc,CAAC,OAAO,EAAE,aAAa,EAAE,GAAG,WAAW,EAAE,CAsCtE;AAID,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,WAAW,EAAE,GAAG,MAAM,CA2B/D;AAID,wBAAgB,cAAc,CAC5B,WAAW,EAAE,MAAM,EACnB,SAAS,EAAE,MAAM,EACjB,WAAW,EAAE,MAAM,GAClB,MAAM,GAAG,SAAS,CAsBpB;AAID,wBAAgB,iBAAiB,CAAC,WAAW,EAAE,MAAM,GAAG,WAAW,EAAE,CAyBpE"}

package/dist/core/feedback/aggregator.js

@@ -0,0 +1,119 @@
+import { readAllFeedback, readFeedbackConfig, readProjectPatterns, readGlobalPatterns, writeProjectPatterns, writeGlobalPatterns, } from './store.js';
+import { stampDateTime } from '../utils/datetime.js';
+// --- Parse feedback entries from markdown ---
+const ENTRY_REGEX = /> \*\*\[([^\]]+)\]\*\* \((\w+)\) — (.+)\n> (.+)\n> \*\*Suggestion:\*\* (.+)\n> \*Source: (\w+) \| Canon: ([^ |]+) \| Date: ([^*]+)\*/g;
+export function parseFeedbackEntries(content) {
+    const entries = [];
+    let match;
+    // Reset regex state
+    ENTRY_REGEX.lastIndex = 0;
+    while ((match = ENTRY_REGEX.exec(content)) !== null) {
+        entries.push({
+            type: match[1],
+            severity: match[2],
+            domain: match[3].trim(),
+            description: match[4].trim(),
+            suggestion: match[5].trim(),
+            source: match[6],
+            canonName: match[7].trim(),
+            date: match[8].trim(),
+        });
+    }
+    return entries;
+}
+const PATTERN_THRESHOLD = 2;
+export function detectPatterns(entries) {
+    // Group by domain + type
+    const groups = new Map();
+    for (const entry of entries) {
+        const key = `${entry.domain}::${entry.type}`;
+        const existing = groups.get(key);
+        if (existing) {
+            existing.entries.push(entry);
+        }
+        else {
+            groups.set(key, { domain: entry.domain, type: entry.type, entries: [entry] });
+        }
+    }
+    const rules = [];
+    const today = stampDateTime();
+    for (const group of groups.values()) {
+        if (group.entries.length < PATTERN_THRESHOLD)
+            continue;
+        // Find the most common suggestion
+        const suggestionCounts = new Map();
+        for (const e of group.entries) {
+            suggestionCounts.set(e.suggestion, (suggestionCounts.get(e.suggestion) ?? 0) + 1);
+        }
+        const topSuggestion = [...suggestionCounts.entries()].sort((a, b) => b[1] - a[1])[0][0];
+        rules.push({
+            date: today,
+            sources: [...new Set(group.entries.map((e) => e.canonName))],
+            pattern: `${group.type} in ${group.domain} (${group.entries.length} occurrences)`,
+            rule: topSuggestion,
+            domain: group.domain,
+            approved: false,
+        });
+    }
+    return rules;
+}
+// --- Format patterns file ---
+export function formatPatternsFile(rules) {
+    const lines = [
+        '# Learned Patterns',
+        '',
+        `*Generated: ${stampDateTime()}*`,
+        '',
+    ];
+    if (rules.length === 0) {
+        lines.push('No patterns detected yet.');
+        return lines.join('\n');
+    }
+    for (const rule of rules) {
+        const status = rule.approved ? 'APPROVED' : 'PROPOSED';
+        lines.push(`## [${status}] ${rule.pattern}`, '', `- **Rule:** ${rule.rule}`, `- **Domain:** ${rule.domain}`, `- **Sources:** ${rule.sources.join(', ')}`, `- **Date:** ${rule.date}`, '');
+    }
+    return lines.join('\n');
+}
+// --- Signal patterns (lightweight, no writes) ---
+export function signalPatterns(projectPath, canonName, description) {
+    // Read existing patterns from project and global
+    const projectContent = readProjectPatterns(projectPath);
+    const globalContent = readGlobalPatterns();
+    if (!projectContent && !globalContent)
+        return undefined;
+    const combined = [projectContent, globalContent].filter(Boolean).join('\n');
+    // Simple keyword matching against existing patterns
+    const words = description.toLowerCase().split(/\s+/);
+    const patternLines = combined.split('\n').filter((l) => l.startsWith('- **Rule:**'));
+    for (const line of patternLines) {
+        const rule = line.replace('- **Rule:** ', '').toLowerCase();
+        const matchCount = words.filter((w) => rule.includes(w)).length;
+        if (matchCount >= 2) {
+            return `Related pattern found: ${line.replace('- **Rule:** ', '')}`;
+        }
+    }
+    return undefined;
+}
+// --- Full aggregation (rebuild from source data) ---
+export function aggregateFeedback(projectPath) {
+    const config = readFeedbackConfig(projectPath);
+    // Scan all canon dirs for feedback.md (source data)
+    const allFeedback = readAllFeedback(projectPath);
+    // Parse all entries
+    const entries = [];
+    for (const { content } of allFeedback) {
+        entries.push(...parseFeedbackEntries(content));
+    }
+    // Detect patterns
+    const rules = detectPatterns(entries);
+    // Write project patterns (always)
+    const content = formatPatternsFile(rules);
+    writeProjectPatterns(projectPath, content);
+    // Write global patterns (if scope allows)
+    if (config.scope === 'project-and-global') {
+        writeGlobalPatterns(content);
+    }
+    return rules;
+}
+//# sourceMappingURL=aggregator.js.map

package/dist/core/feedback/aggregator.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"aggregator.js","sourceRoot":"","sources":["../../../src/core/feedback/aggregator.ts"],"names":[],"mappings":"AACA,OAAO,EACL,eAAe,EACf,kBAAkB,EAClB,mBAAmB,EACnB,kBAAkB,EAClB,oBAAoB,EACpB,mBAAmB,GACpB,MAAM,YAAY,CAAC;AACpB,OAAO,EAAE,aAAa,EAAE,MAAM,sBAAsB,CAAC;AAErD,+CAA+C;AAE/C,MAAM,WAAW,GACf,uIAAuI,CAAC;AAE1I,MAAM,UAAU,oBAAoB,CAAC,OAAe;IAClD,MAAM,OAAO,GAAoB,EAAE,CAAC;IACpC,IAAI,KAA6B,CAAC;IAElC,oBAAoB;IACpB,WAAW,CAAC,SAAS,GAAG,CAAC,CAAC;IAE1B,OAAO,CAAC,KAAK,GAAG,WAAW,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC,KAAK,IAAI,EAAE,CAAC;QACpD,OAAO,CAAC,IAAI,CAAC;YACX,IAAI,EAAE,KAAK,CAAC,CAAC,CAAiB;YAC9B,QAAQ,EAAE,KAAK,CAAC,CAAC,CAAqB;YACtC,MAAM,EAAE,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE;YACvB,WAAW,EAAE,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE;YAC5B,UAAU,EAAE,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE;YAC3B,MAAM,EAAE,KAAK,CAAC,CAAC,CAA4B;YAC3C,SAAS,EAAE,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE;YAC1B,IAAI,EAAE,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE;SACtB,CAAC,CAAC;IACL,CAAC;IAED,OAAO,OAAO,CAAC;AACjB,CAAC;AAUD,MAAM,iBAAiB,GAAG,CAAC,CAAC;AAE5B,MAAM,UAAU,cAAc,CAAC,OAAwB;IACrD,yBAAyB;IACzB,MAAM,MAAM,GAAG,IAAI,GAAG,EAAwB,CAAC;IAE/C,KAAK,MAAM,KAAK,IAAI,OAAO,EAAE,CAAC;QAC5B,MAAM,GAAG,GAAG,GAAG,KAAK,CAAC,MAAM,KAAK,KAAK,CAAC,IAAI,EAAE,CAAC;QAC7C,MAAM,QAAQ,GAAG,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;QACjC,IAAI,QAAQ,EAAE,CAAC;YACb,QAAQ,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;QAC/B,CAAC;aAAM,CAAC;YACN,MAAM,CAAC,GAAG,CAAC,GAAG,EAAE,EAAE,MAAM,EAAE,KAAK,CAAC,MAAM,EAAE,IAAI,EAAE,KAAK,CAAC,IAAI,EAAE,OAAO,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC;QAChF,CAAC;IACH,CAAC;IAED,MAAM,KAAK,GAAkB,EAAE,CAAC;IAChC,MAAM,KAAK,GAAG,aAAa,EAAE,CAAC;IAE9B,KAAK,MAAM,KAAK,IAAI,MAAM,CAAC,MAAM,EAAE,EAAE,CAAC;QACpC,IAAI,KAAK,CAAC,OAAO,CAAC,MAAM,GAAG,iBAAiB;YAAE,SAAS;QAEvD,kCAAkC;QAClC,MAAM,gBAAgB,GAAG,IAAI,GAAG,EAAkB,CAAC;QACnD,KAAK,MAAM,CAAC,IAAI,KAAK,CAAC,OAAO,EAAE,CAAC;YAC9B,gBAAgB,CAAC,GAAG,CAAC,CAAC,CAAC,UAAU,EAAE,CAAC,gBAAgB,CAAC,GAAG,CAAC,CAAC,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;QACpF,CAAC;QACD,MAAM,aAAa,GAAG,CAAC,GAAG,gBAAgB,CAAC,OAAO,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC;QAExF,KAAK,CAAC,IAAI,CAAC;YACT,IAAI,EAAE,KAAK;YACX,OAAO,EAAE,CAAC,GAAG,IAAI,GAAG,CAAC,KAAK,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC;YAC5D,OAAO,EAAE,GAAG,KAAK,CAAC,IAAI,OAAO,KAAK,CAAC,MAAM,KAAK,KAAK,CAAC,OAAO,CAAC,MAAM,eAAe;YACjF,IAAI,EAAE,aAAa;YACnB,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,QAAQ,EAAE,KAAK;SAChB,CAAC,CAAC;IACL,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC;AAED,+BAA+B;AAE/B,MAAM,UAAU,kBAAkB,CAAC,KAAoB;IACrD,MAAM,KAAK,GAAa;QACtB,oBAAoB;QACpB,EAAE;QACF,eAAe,aAAa,EAAE,GAAG;QACjC,EAAE;KACH,CAAC;IAEF,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;QACvB,KAAK,CAAC,IAAI,CAAC,2BAA2B,CAAC,CAAC;QACxC,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IAC1B,CAAC;IAED,KAAK,MAAM,IAAI,IAAI,KAAK,EAAE,CAAC;QACzB,MAAM,MAAM,GAAG,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,UAAU,CAAC,CAAC,CAAC,UAAU,CAAC;QACvD,KAAK,CAAC,IAAI,CACR,OAAO,MAAM,KAAK,IAAI,CAAC,OAAO,EAAE,EAChC,EAAE,EACF,eAAe,IAAI,CAAC,IAAI,EAAE,EAC1B,iBAAiB,IAAI,CAAC,MAAM,EAAE,EAC9B,kBAAkB,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,EAC3C,eAAe,IAAI,CAAC,IAAI,EAAE,EAC1B,EAAE,CACH,CAAC;IACJ,CAAC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAC1B,CAAC;AAED,mDAAmD;AAEnD,MAAM,UAAU,cAAc,CAC5B,WAAmB,EACnB,SAAiB,EACjB,WAAmB;IAEnB,iDAAiD;IACjD,MAAM,cAAc,GAAG,mBAAmB,CAAC,WAAW,CAAC,CAAC;IACxD,MAAM,aAAa,GAAG,kBAAkB,EAAE,CAAC;IAE3C,IAAI,CAAC,cAAc,IAAI,CAAC,aAAa;QAAE,OAAO,SAAS,CAAC;IAExD,MAAM,QAAQ,GAAG,CAAC,cAAc,EAAE,aAAa,CAAC,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;IAE5E,oDAAoD;IACpD,MAAM,KAAK,GAAG,WAAW,CAAC,WAAW,EAAE,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;IACrD,MAAM,YAAY,GAAG,QAAQ,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,UAAU,CAAC,aAAa,CAAC,CAAC,CAAC;IAErF,KAAK,MAAM,IAAI,IAAI,YAAY,EAAE,CAAC;QAChC,MAAM,IAAI,GAAG,IAAI,CAAC,OAAO,CAAC,cAAc,EAAE,EAAE,CAAC,CAAC,WAAW,EAAE,CAAC;QAC5D,MAAM,UAAU,GAAG,KAAK,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC;QAChE,IAAI,UAAU,IAAI,CAAC,EAAE,CAAC;YACpB,OAAO,0BAA0B,IAAI,CAAC,OAAO,CAAC,cAAc,EAAE,EAAE,CAAC,EAAE,CAAC;QACtE,CAAC;IACH,CAAC;IAED,OAAO,SAAS,CAAC;AACnB,CAAC;AAED,sDAAsD;AAEtD,MAAM,UAAU,iBAAiB,CAAC,WAAmB;IACnD,MAAM,MAAM,GAAG,kBAAkB,CAAC,WAAW,CAAC,CAAC;IAE/C,oDAAoD;IACpD,MAAM,WAAW,GAAG,eAAe,CAAC,WAAW,CAAC,CAAC;IAEjD,oBAAoB;IACpB,MAAM,OAAO,GAAoB,EAAE,CAAC;IACpC,KAAK,MAAM,EAAE,OAAO,EAAE,IAAI,WAAW,EAAE,CAAC;QACtC,OAAO,CAAC,IAAI,CAAC,GAAG,oBAAoB,CAAC,OAAO,CAAC,CAAC,CAAC;IACjD,CAAC;IAED,kBAAkB;IAClB,MAAM,KAAK,GAAG,cAAc,CAAC,OAAO,CAAC,CAAC;IAEtC,kCAAkC;IAClC,MAAM,OAAO,GAAG,kBAAkB,CAAC,KAAK,CAAC,CAAC;IAC1C,oBAAoB,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;IAE3C,0CAA0C;IAC1C,IAAI,MAAM,CAAC,KAAK,KAAK,oBAAoB,EAAE,CAAC;QAC1C,mBAAmB,CAAC,OAAO,CAAC,CAAC;IAC/B,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC"}

package/dist/core/feedback/store.d.ts

@@ -0,0 +1,20 @@
+import type { FeedbackEntry, FeedbackConfig } from './types.js';
+export declare function feedbackFilePath(projectPath: string, canonName: string): string;
+export declare function projectFeedbackDir(projectPath: string): string;
+export declare function projectPatternsPath(projectPath: string): string;
+export declare function globalFeedbackDir(): string;
+export declare function globalPatternsPath(): string;
+export declare function feedbackConfigPath(projectPath: string): string;
+export declare function readFeedbackConfig(projectPath: string): FeedbackConfig;
+export declare function formatFeedbackEntry(entry: FeedbackEntry): string;
+export declare function appendFeedbackEntry(projectPath: string, canonName: string, entry: FeedbackEntry): string;
+export declare function readFeedbackForCanon(projectPath: string, canonName: string): string | null;
+export declare function readAllFeedback(projectPath: string): Array<{
+    canonName: string;
+    content: string;
+}>;
+export declare function readProjectPatterns(projectPath: string): string | null;
+export declare function readGlobalPatterns(): string | null;
+export declare function writeProjectPatterns(projectPath: string, content: string): void;
+export declare function writeGlobalPatterns(content: string): void;
+//# sourceMappingURL=store.d.ts.map

package/dist/core/feedback/store.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"store.d.ts","sourceRoot":"","sources":["../../../src/core/feedback/store.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,aAAa,EAAE,cAAc,EAAiB,MAAM,YAAY,CAAC;AAI/E,wBAAgB,gBAAgB,CAAC,WAAW,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,CAE/E;AAED,wBAAgB,kBAAkB,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAE9D;AAED,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAE/D;AAED,wBAAgB,iBAAiB,IAAI,MAAM,CAE1C;AAED,wBAAgB,kBAAkB,IAAI,MAAM,CAE3C;AAED,wBAAgB,kBAAkB,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAE9D;AAMD,wBAAgB,kBAAkB,CAAC,WAAW,EAAE,MAAM,GAAG,cAAc,CAYtE;AAID,wBAAgB,mBAAmB,CAAC,KAAK,EAAE,aAAa,GAAG,MAAM,CAQhE;AAID,wBAAgB,mBAAmB,CACjC,WAAW,EAAE,MAAM,EACnB,SAAS,EAAE,MAAM,EACjB,KAAK,EAAE,aAAa,GACnB,MAAM,CAaR;AAID,wBAAgB,oBAAoB,CAAC,WAAW,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAE1F;AAED,wBAAgB,eAAe,CAAC,WAAW,EAAE,MAAM,GAAG,KAAK,CAAC;IAAE,SAAS,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC,CAsBlG;AAID,wBAAgB,mBAAmB,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAEtE;AAED,wBAAgB,kBAAkB,IAAI,MAAM,GAAG,IAAI,CAElD;AAED,wBAAgB,oBAAoB,CAAC,WAAW,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,GAAG,IAAI,CAG/E;AAED,wBAAgB,mBAAmB,CAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAOzD"}