@soleri/core 9.12.1 → 9.14.0

package/dist/knowledge-packs/salvador/salvador-engineering/vault/architecture.json

@@ -0,0 +1,143 @@
+{
+  "domain": "architecture",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-architecture-anteater-integration-protocol",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "Anteater + Salvador Integration Protocol",
+      "severity": "critical",
+      "description": "# Anteater + Salvador Integration Protocol\n\n## Context\n\nWhen Salvador is activated and user mentions design system generation, component creation, or Anteater\n\n## Pattern\n\nSalvador and Anteater form a three-pillar ecosystem: Anteater (Generator) creates design system projects with Claude infrastructure, Salvador Vault (Intelligence) stores canonical rules and workflows, Salvador-MCP (Runtime) provides 65+ validation tools. The pipeline flows: Vault → Anteater → MCP with feedback loop.\n\n## Example\n\n```typescript\n# Generate new project\nnpx @adrozdenko/anteater my-design-system --primary \"#1E3A5F\"\n\n# Add components with auto token transformation\nnpx @adrozdenko/anteater add button card dialog\n\n# With vault connection for latest rules\nnpx @adrozdenko/anteater my-project --vault ~/Desktop/salvador\n```\n\n## Why\n\nSalvador must know about Anteater to guide users through the complete design system workflow. Without this knowledge, Salvador cannot properly orchestrate the SIE (Simulated Interactive Environment) loop for component generation and validation.",
+      "tags": ["anteater", "salvador", "ecosystem", "protocol", "design-system", "cli"],
+      "appliesTo": ["CLAUDE.md", ".claude/agents/*", "chains/flows/*"]
+    },
+    {
+      "id": "pattern-architecture-detailed-status-returns",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "Return detailed status objects instead of empty arrays on failure",
+      "severity": "warning",
+      "description": "# Return detailed status objects instead of empty arrays on failure\n\n## Context\n\nFunctions that scan directories or read config files should return status objects with distinct states\n\n## Pattern\n\nInstead of returning empty array on any failure, return { data: [], status: 'not_found' | 'empty' | 'error', message: string }. This allows callers to distinguish between 'directory missing', 'directory empty', and 'error reading directory'.\n\n## Example\n\n```typescript\nfunction getHooksFromDir(dir) {\n  if (!fs.existsSync(dir)) {\n    return { hooks: [], status: 'not_found', message: `Directory does not exist: ${dir}` };\n  }\n  // ... handle empty and error states too\n}\n```\n\n## Why\n\nSilent empty returns force users to guess why nothing was found. Detailed status enables clear error messages and recovery guidance.",
+      "tags": ["cli", "ux", "error-handling", "diagnostics"],
+      "appliesTo": ["scripts/setup-project.js"]
+    },
+    {
+      "id": "pattern-architecture-quick-chain-mappings-are-context-sensitive-same-mode-rou",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "Chain-mappings are context-sensitive — same mode routes to different chains",
+      "severity": "warning",
+      "description": "# Chain-mappings are context-sensitive — same mode routes to different chains\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nIn routing-config.yaml, chain-mappings are keyed by mode AND context. BUILD-MODE + component context → atomic chains (design-component, implement-component), while BUILD-MODE + feature context → DEVELOPER-flow. This means testing the full pipeline requires carefully choosing scenario text to target specific context keywords. Most flows are only reachable via 'feature' or 'default' contexts.\n\n## Example\n\n```typescript\nBUILD-MODE chain-mappings: component → [design-component, implement-component], feature → [DEVELOPER-flow], default → [DEVELOPER-flow]\n```\n\n## Why\n\nWithout understanding context sensitivity, test scenarios may route to atomic chains instead of flows, making flow expansion tests fail unexpectedly.",
+      "tags": ["routing", "chain-mappings", "context-sensitive", "testing"]
+    },
+    {
+      "id": "anti-pattern-architecture-quick-architect-flow-is-unreachable-via-text-based-routi",
+      "type": "anti-pattern",
+      "domain": "architecture",
+      "title": "ARCHITECT-flow is unreachable via text-based routing",
+      "severity": "warning",
+      "description": "# ARCHITECT-flow is unreachable via text-based routing\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Anti-Pattern\n\nIn routing-config.yaml, VALIDATE-MODE maps 'audit' context to ARCHITECT-flow. However, 'audit' is NOT defined in context-keywords, so detectContext() can never return 'audit'. The only defined context keywords are: component, feature, story, test, style, api. This means ARCHITECT-flow is always bypassed in favor of REVIEWER-flow (the default for VALIDATE-MODE). To reach ARCHITECT-flow, an 'audit' context keyword would need to be added to routing-config.yaml.\n\n## Example (Bad)\n\n```typescript\nchain-mappings.VALIDATE-MODE.audit exists but context-keywords has no 'audit' entry\n```\n\n## Why It's Wrong\n\nDead configuration path. Architecture audits always fall through to REVIEWER-flow instead of ARCHITECT-flow.",
+      "tags": ["routing", "architect-flow", "unreachable", "context-keywords"]
+    },
+    {
+      "id": "pattern-architecture-capture-domainpack-architecture-decision-one-pack-multiple",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "DomainPack Architecture Decision: One Pack, Multiple Facades",
+      "severity": "critical",
+      "description": "# DomainPack Architecture Decision: One Pack, Multiple Facades\n\n## Context\n\nCaptured during development session on 2026-03-15\n\n## Pattern\n\nA single domain pack (npm package) can register multiple facades. The pack is the distribution unit (npm install), facades are the runtime unit (MCP tools). Example: @soleri/domain-design registers 3 facades (design, design-rules, design-patterns) from one package. This mirrors how npm scoped packages export multiple modules.\n\n## Example\n\n```typescript\nN/A\n```\n\n## Why\n\nSeparating distribution boundary (pack) from interface boundary (facade) enables both small single-facade packs and large multi-facade packs without interface changes. Avoids forcing artificial 1:1 pack-to-facade mapping.",
+      "tags": ["soleri", "domain-pack", "facade", "architecture-decision"]
+    },
+    {
+      "id": "pattern-architecture-capture-domainpack-primitive-implementation-complete-phase",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "DomainPack Primitive — Implementation Complete (Phase 1)",
+      "severity": "critical",
+      "description": "# DomainPack Primitive — Implementation Complete (Phase 1)\n\n## Context\n\nCaptured during development session on 2026-03-15\n\n## Pattern\n\nImplemented the DomainPack primitive in @soleri/core, @soleri/forge, and @soleri/cli. Key files: domain-packs/types.ts (DomainPack interface, KnowledgeManifest with 3 tiers, validation), domain-packs/loader.ts (dynamic import, topological dependency sort), runtime/domain-ops.ts (extended createDomainFacades with optional packs parameter, pack ops PRIMARY + standard 5 FALLBACK merge strategy). OCP guaranteed: no packs = identical behavior. One pack can register multiple facades via pack.facades[]. AgentConfig extended with domainPacks?: DomainPackRef[]. CLI command: soleri add-pack.\n\n## Example\n\n```typescript\nN/A\n```\n\n## Why\n\nFoundation for Phase 2: extracting Salvador domain intelligence (design, figma, github, playwright) into portable npm packages that any Soleri agent can install.",
+      "tags": ["soleri", "domain-pack", "phase-1", "architecture", "implementation"]
+    },
+    {
+      "id": "principle-architecture-capture-architecture-decision-multi-process-agents-with-sh",
+      "type": "rule",
+      "domain": "architecture",
+      "title": "Architecture Decision: Multi-Process Agents with Shared Vault Layer",
+      "severity": "critical",
+      "description": "# Architecture Decision: Multi-Process Agents with Shared Vault Layer\n\n## Context\n\nResolved from Open Source Gap: Single MCP Server vs Multiple. Three options evaluated: (A) multi-process standalone, (B) single engine with dynamic loading, (C) hybrid. Option A chosen. Rationale: MCP protocol favors multi-server (tool namespacing, UI grouping), standalone agents are portable (no engine dependency), Node.js+SQLite is cheap (~50MB per process), single-engine adds months of complexity (persona routing, context isolation, crash blast radius) for a problem nobody has yet.\n\n## Principle\n\nSoleri agents remain standalone MCP processes (1 agent = 1 process). Cross-agent intelligence is solved at the vault layer (~/.soleri/vault/ with domain namespacing), not the process layer. Config friction is solved via CLI commands (soleri install/uninstall). Single-engine dynamic persona loading is deferred until real user scaling pain is reported.\n\n## Example\n\nImplementation: (1) @soleri/core shared vault at ~/.soleri/vault/ with domain namespacing — all agents read/write, cross-pollinate via global pool. (2) CLI: soleri install <agent> / soleri uninstall <agent> manages claude_desktop_config.json entries. (3) forge auto-installs on scaffold.\n\n## Why\n\nAvoids premature architecture complexity. The two real sub-problems (cross-agent learning, config management) have simpler solutions: shared vault layer and CLI install commands. Single-engine only becomes necessary if MCP protocol adds multiplexing or real users report real scaling pain.",
+      "tags": ["architecture-decision", "mcp", "multi-process", "shared-vault", "scalability"]
+    },
+    {
+      "id": "principle-architecture-capture-editor-hooks-as-installable-plugins-not-creation-t",
+      "type": "rule",
+      "domain": "architecture",
+      "title": "Editor hooks as installable plugins, not creation-time choice",
+      "severity": "suggestion",
+      "description": "# Editor hooks as installable plugins, not creation-time choice\n\n## Context\n\nCaptured during development session on 2026-03-03\n\n## Principle\n\nEditor-specific hooks (Claude Code, Cursor, VS Code) should be managed as installable plugins via `soleri hooks add <editor>` and `soleri hooks remove <editor>`, not baked in during `soleri create`. This keeps the forge modular — users can add/switch/stack editors anytime without recreating the agent. The create wizard may optionally suggest hooks, but they're always manageable independently after creation.\n\n## Example\n\n# Add editor hooks to existing agent\n\nsoleri hooks add claude-code # installs .claude/settings.json with vault-capture, session capture, routing\nsoleri hooks add cursor # future\nsoleri hooks remove claude-code # clean removal\nsoleri hooks list # show installed hook sets\n\n## Why\n\nSoleri's engine is modular and editor-agnostic. Locking editor choice at agent creation time contradicts that philosophy. Users may switch editors, use multiple editors, or add editor support later. A plugin model (`soleri hooks add claude-code`) matches the existing pattern of composable knowledge packs and domain modules.",
+      "tags": ["forge", "hooks", "plugins", "modularity", "editor-agnostic", "CLI"],
+      "context": "Related: idea-architecture-capture-forge-should-scaffold-editor-specific-hooks-alongs"
+    },
+    {
+      "id": "reference-architecture-capture-editor-ecosystem-mapping-for-soleri-hooks-plugin-s",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "Editor ecosystem mapping for Soleri hooks plugin system",
+      "severity": "suggestion",
+      "description": "# Editor ecosystem mapping for Soleri hooks plugin system\n\n## Context\n\nCaptured during development session on 2026-03-03\n\n## Reference\n\nMapping of AI coding editor ecosystems and their configuration capabilities for the `soleri hooks add <editor>` plugin system.\n\n**Full hook support (event-driven lifecycle):**\n\n- Claude Code — .claude/settings.json — PreToolUse, PostToolUse, Stop, SessionStart, UserPromptSubmit, PreCompact. Richest hook system, supports runtime enforcement.\n\n**Rules files only (static instructions, no lifecycle hooks):**\n\n- Cursor — .cursorrules\n- Windsurf — .windsurfrules\n- GitHub Copilot — .github/copilot-instructions.md\n- Cline — .clinerules\n- Aider — .aider.conf.yml + conventions files\n- Continue — .continue/ directory\n\n**Universal connector:** MCP transport works across all editors that support it (Claude Code, Cursor, Windsurf, Cline, Continue). The MCP connection is universal; hooks are the editor-specific glue on top.\n\n**What `soleri hooks add` generates per editor:**\n\n- claude-code → .claude/settings.json (full lifecycle hooks)\n- cursor → .cursorrules (instructions only)\n- windsurf → .windsurfrules (instructions only)\n- copilot → .github/copilot-instructions.md (instructions only)\n\n## Details\n\nN/A\n\n## Why\n\nSoleri is editor-agnostic. Understanding what each editor supports determines how much enforcement the hooks plugin can provide. Claude Code gets full runtime hooks; others get static instruction files. MCP is the universal transport regardless of editor.",
+      "tags": [
+        "forge",
+        "hooks",
+        "editor-ecosystem",
+        "cursor",
+        "windsurf",
+        "copilot",
+        "cline",
+        "aider",
+        "MCP",
+        "portability"
+      ],
+      "context": "Related: principle-architecture-capture-editor-hooks-as-installable-plugins-not-creation-t"
+    },
+    {
+      "id": "workflow-architecture-capture-file-tree-architecture-shift-implementation-comple",
+      "type": "playbook",
+      "domain": "architecture",
+      "title": "File-Tree Architecture Shift — Implementation Complete",
+      "severity": "critical",
+      "description": "# File-Tree Architecture Shift — Implementation Complete\n\n## Context\n\nCaptured during development session on 2026-03-16\n\n## Workflow\n\nSuccessfully implemented the Soleri v7 file-tree architecture shift across 6 phases. Agents are now folders (agent.yaml + instructions/ + workflows/ + knowledge/) instead of generated TypeScript projects. Knowledge Engine (vault, brain, curator, learning) remains as @soleri/core with direct MCP registration via registerEngine(). Forge generates folder trees in <4s instead of TypeScript projects in 40s. Salvador ported to file-tree format at agents/salvador-filetree/ with full capability parity (23 skills, 6 workflows, 4 knowledge bundles). CLI updated: create defaults to file-tree, install detects format, dev watches files. All 792 E2E tests pass.\n\n## Steps\n\nN/A\n\n## Why\n\nCoded routing frameworks (facade factory, TypeScript scaffolder) were operating at the wrong abstraction layer. Claude Code reads files natively and calls MCP tools — the agent definition should be a folder tree, not generated code. The knowledge engine (vault, brain, learning) is the real product that no model update replaces.",
+      "tags": [
+        "soleri",
+        "v7",
+        "file-tree",
+        "architecture",
+        "knowledge-engine",
+        "implementation-complete"
+      ]
+    },
+    {
+      "id": "workflow-architecture-capture-soleri-v7-file-tree-architecture-shift-two-layer-s",
+      "type": "playbook",
+      "domain": "architecture",
+      "title": "Soleri v7: File-Tree Architecture Shift — Two-Layer Split",
+      "severity": "critical",
+      "description": "# Soleri v7: File-Tree Architecture Shift — Two-Layer Split\n\n## Context\n\nCaptured during development session on 2026-03-16\n\n## Workflow\n\nMajor architectural decision to split Soleri from a monolithic coded framework into two layers: (1) File-Tree Layer — agent definitions as plain folder structures (agent.yaml, instructions/*.md, workflows/*, knowledge/*.json) that Claude Code reads natively, no TypeScript generation; (2) Knowledge Engine Layer — vault, brain, curator, learning, memory as a standalone MCP server with direct tool registration (no facade factory dispatch). Forge becomes a mkdir + template copier. CLAUDE.md is auto-generated from agent.yaml + instructions/, never manually edited. Motivated by the file-tree abstraction philosophy: every AI agent maps to folders with instructions + tools + data, and coded routing frameworks are wasted effort when the model + MCP handle routing natively.\n\n## Steps\n\nN/A\n\n## Why\n\nCurrent Soleri generates TypeScript projects with a facade dispatch layer on top of MCP — this is a routing layer on top of a routing layer. The knowledge engine (vault, brain, learning) is the real product; the scaffolding around it should be as thin as possible. File trees are the correct abstraction for agent definitions because Claude Code already reads files and follows markdown instructions natively.",
+      "tags": ["soleri", "architecture", "file-tree", "knowledge-engine", "v7", "breaking-change"]
+    },
+    {
+      "id": "idea-architecture-capture-forge-should-scaffold-editor-specific-hooks-alongs",
+      "type": "pattern",
+      "domain": "architecture",
+      "title": "Forge should scaffold editor-specific hooks alongside agent templates",
+      "severity": "suggestion",
+      "description": "# Forge should scaffold editor-specific hooks alongside agent templates\n\n## Context\n\nCaptured during development session on 2026-03-03\n\n## Idea\n\nWhen `soleri create my-agent` scaffolds a new agent, it should include editor-specific hooks (e.g. .claude/settings.json for Claude Code) alongside vault, brain, memory, and persona templates. This makes agents immediately functional in their target editor without manual hook setup. For Claude Code, this means vault-capture enforcement, session capture, loop gates, and routing hooks ship with the agent.\n\n## Motivation\n\nsoleri create my-agent → generates:\n\n- vault.ts, brain.ts, personas/ (existing)\n- hooks/claude-code/settings.json (NEW — vault-capture, session capture, routing)\n- hooks/cursor/ (future)\n- hooks/vscode/ (future)\n\n## Why\n\nCurrently hooks live in personal ~/.claude/settings.json and aren't portable. If Soleri is agent-agnostic and editor-agnostic, the forge should generate the right hook configuration per editor so agents work out of the box. Users shouldn't have to manually configure hooks after creating an agent.",
+      "tags": [
+        "forge",
+        "scaffolding",
+        "hooks",
+        "claude-code",
+        "agent-creation",
+        "developer-experience"
+      ]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/commercial.json

@@ -0,0 +1,16 @@
+{
+  "domain": "commercial",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "idea-opensource-premium-packs-later",
+      "type": "pattern",
+      "domain": "commercial",
+      "title": "Premium Knowledge Packs — Not Yet",
+      "severity": "suggestion",
+      "description": "# Premium Knowledge Packs — Not Yet\n\n## Context\n\nKnowledge Packs have three planned tiers: Starter (ships with agent), Community (npm registry), and Premium (paid subscription). As of March 2026, only Starter and Community are publicly mentioned.\n\n## Decision\n\nDo not advertise the Premium/paid tier yet. The README and website only show free tiers.\n\n## Why\n\nMentioning a paid tier too early sends the wrong signal for an open-source project still building community trust. The focus right now is adoption, contribution, and building a healthy ecosystem of free community packs. Premium packs are a future monetization path — introduce them once the community is established and there's organic demand.\n\n## When to Revisit\n\n- Community pack ecosystem has traction (multiple contributors, active discussions)\n- Users are asking for curated/premium content\n- Soleri has meaningful adoption numbers",
+      "tags": ["knowledge-packs", "monetization", "community", "timing"],
+      "appliesTo": ["README.md", "website"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/communication.json

@@ -0,0 +1,33 @@
+{
+  "domain": "communication",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-communication-quick-prompt-library-hint-system-for-domain-specific-wor",
+      "type": "pattern",
+      "domain": "communication",
+      "title": "Prompt library hint system for domain-specific workflow loading",
+      "severity": "warning",
+      "description": "# Prompt library hint system for domain-specific workflow loading\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nEach chain-mapping in routing-config.yaml includes a prompt-hint field that loads domain-specific workflow guidance from Salvador's prompt library (55 prompts). When routing returns a prompt-hint like 'component-create', the system calls salvador_get_prompt('component-create') which returns: protocol (step-by-step guidance), mcpTools (mandatory tool calls), and FORBIDDEN rules (patterns that must not appear). Prompts complement planning — they provide domain knowledge while planning provides task management.\n\n## Example\n\n```typescript\nprompt-hint: 'component-create' → loads protocol with shadcn check, contrast validation, component workflow. mcpTools are MANDATORY.\n```\n\n## Why\n\nPrompt hints inject accumulated domain expertise into every workflow without hardcoding knowledge in flow definitions.",
+      "tags": ["prompts", "domain-knowledge", "workflow", "hint-system", "guidance"]
+    },
+    {
+      "id": "pattern-communication-quick-knowledge-gather-before-execute-pattern-in-all-flo",
+      "type": "rule",
+      "domain": "communication",
+      "title": "Knowledge gather-before-execute pattern in all flows",
+      "severity": "critical",
+      "description": "# Knowledge gather-before-execute pattern in all flows\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nEvery Salvador flow begins with a gather-knowledge step that loads relevant vault patterns and anti-patterns before execution begins. Each mode has a dedicated composite: gather-build-knowledge, gather-review-knowledge, gather-test-knowledge, gather-ux-knowledge, etc. The composite expands to vault search + domain-specific chain loading. Output is [vault-patterns, vault-anti-patterns] which feeds into subsequent steps. This ensures decisions are informed by accumulated knowledge, not just the current task context.\n\n## Example\n\n```typescript\nDEVELOPER-flow step 1: gather-knowledge → gather-build-knowledge composite → vault patterns + dev rules + architecture patterns\n```\n\n## Why\n\nWithout vault knowledge loading, each task starts from zero. Gathering first prevents repeating known mistakes and ensures consistency with established patterns.",
+      "tags": ["knowledge-first", "vault-search", "gather", "informed-decisions", "composites"]
+    },
+    {
+      "id": "pattern-communication-quick-handoff-template-format-for-cross-phase-task-trans",
+      "type": "playbook",
+      "domain": "communication",
+      "title": "Handoff template format for cross-phase task transfer",
+      "severity": "warning",
+      "description": "# Handoff template format for cross-phase task transfer\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador generates structured handoff documents in _handoff/*.md when tasks transfer between phases or agents. Standard sections: metadata (mode, flow, confidence), objective, scope, completed work, remaining tasks, acceptance criteria, known risks. Handoffs are triggered by approval gates and flow completion. The format ensures no context is lost between phases — the receiving phase can reconstruct full context from the handoff alone.\n\n## Example\n\n```typescript\n_handoff/button-component.md: { mode: BUILD-MODE, flow: DEVELOPER-flow, phase: design-complete, next: implement, spec: {...} }\n```\n\n## Why\n\nContext loss between phases is the #1 cause of rework. Structured handoffs preserve intent, decisions, and constraints across boundaries.",
+      "tags": ["handoff", "task-transfer", "documentation", "context-preservation"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/component.json

@@ -0,0 +1,16 @@
+{
+  "domain": "component",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-component-successful-custom-loop-score-85",
+      "type": "pattern",
+      "domain": "component",
+      "title": "Successful custom loop (score: 85)",
+      "severity": "suggestion",
+      "description": "# Successful custom loop (score: 85)\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 45 sessions.\nFlow: loop-custom\n## Pattern\n\nSession 2026-03-02-ffa03ef9 completed custom validation with a score of 85 (grade: B). This approach worked well for custom tasks.\n\n## Evidence\n\n- Observed in 45 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `loop-good-score`",
+      "tags": ["loop", "success", "good-score", "custom", "loop-custom"],
+      "appliesTo": ["loop-custom"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/express.json

@@ -0,0 +1,34 @@
+{
+  "domain": "express",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-express-graceful-sigint-handling",
+      "type": "pattern",
+      "domain": "express",
+      "title": "Handle Ctrl+C gracefully in interactive prompts",
+      "severity": "critical",
+      "description": "# Handle Ctrl+C gracefully in interactive prompts\n\n## Context\n\nAny script using readline for interactive prompts must handle SIGINT\n\n## Pattern\n\nAdd SIGINT handler to readline interface that closes properly and exits cleanly. Prevents terminal from staying in raw mode after Ctrl+C.\n\n## Example\n\n```typescript\nconst rl = readline.createInterface({ input, output });\nrl.on('SIGINT', () => {\n  rl.close();\n  console.log('\\nCancelled.');\n  process.exit(0);\n});\n```\n\n## Why\n\nWithout SIGINT handling, Ctrl+C during a prompt can leave terminal corrupted, requiring user to kill the terminal window.",
+      "tags": ["cli", "ux", "readline", "sigint", "terminal"],
+      "appliesTo": ["scripts/setup-project.js"]
+    },
+    {
+      "id": "pattern-express-quick-two-gate-approval-system-for-plan-then-execute-mcp",
+      "type": "pattern",
+      "domain": "express",
+      "title": "Two-gate approval system for plan-then-execute MCP operations",
+      "severity": "warning",
+      "description": "# Two-gate approval system for plan-then-execute MCP operations\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador's planning system uses a 2-gate approval pattern. Gate 1 (plan approval): approve-plan with approvalType:'plan' validates the overall plan before splitting into tasks. Gate 2 (task approval): approve-plan with approvalType:'tasks' validates individual tasks before execution begins. The split-plan chain is GATED — it requires Gate 1's checkId. This human-in-the-loop pattern ensures both strategy and tactics are reviewed before any code is written.\n\n## Example\n\n```typescript\napprove-plan(planId, approvalType:'plan') → split-plan(checkId) → approve-plan(planId, approvalType:'tasks') → execute\n```\n\n## Why\n\nSingle-gate approval lets bad plans spawn many bad tasks. Two-gate catches strategy errors before they multiply into tactical waste.",
+      "tags": ["approval", "two-gate", "planning", "human-in-the-loop", "mcp"]
+    },
+    {
+      "id": "pattern-express-backend-handoff-template",
+      "type": "playbook",
+      "domain": "express",
+      "title": "Backend API Handoff Template",
+      "severity": "suggestion",
+      "description": "# Backend API Handoff Template\n\n## Context\n\nWhen prototype stories define new API endpoints that need backend implementation\n\n## Pattern\n\nGenerate a handoff document from _handoff/templates/backend-api-handoff.md containing endpoints, TypeScript interfaces, request/response examples, validation rules, and test scenarios.\n\n## Example\n\n```typescript\n## API Endpoint: Create Tenant\n\n**Method:** POST\n**Path:** /api/v1/tenants\n\n### Request Body\n```typescript\ninterface CreateTenantRequest {\n  name: string\n  adminEmail: string\n  plan: 'starter' | 'professional' | 'enterprise'\n}\n```\n\n### Response (201 Created)\n```typescript\ninterface CreateTenantResponse {\n  id: string\n  name: string\n  createdAt: string\n}\n```\n```\n\n## Why\n\nHandoff documents ensure backend teams get complete API specifications derived from actual frontend usage, not separate documentation that can drift.",
+      "tags": ["handoff", "api", "documentation", "backend", "contract"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/leadership.json

@@ -0,0 +1,33 @@
+{
+  "domain": "leadership",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-leadership-quick-morph-based-mode-switching-for-cross-flow-collabor",
+      "type": "pattern",
+      "domain": "leadership",
+      "title": "Morph-based mode switching for cross-flow collaboration",
+      "severity": "warning",
+      "description": "# Morph-based mode switching for cross-flow collaboration\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nFlows can morph into other modes at specific steps. The INTEGRATOR-flow morphs to design mode during the configure step (morph: design) to leverage design expertise for token configuration. Auto-morph injects review mode on validation steps in build/fix/deliver flows. Review-only flows (REVIEWER, ARCHITECT, UX-AUDITOR) are excluded from auto-morph to prevent infinite recursion. Morph preserves parent flow context while temporarily adopting the target mode's evaluation criteria.\n\n## Example\n\n```typescript\nINTEGRATOR-flow step 'configure' has morph: design → temporarily adopts The Painter's color/token expertise\n```\n\n## Why\n\nComplex tasks require multiple expertise domains. Morph enables delegation without abandoning the parent workflow context.",
+      "tags": ["morph", "mode-switching", "cross-flow", "collaboration", "delegation"]
+    },
+    {
+      "id": "pattern-leadership-quick-data-driven-architecture-all-logic-in-yaml-none-in",
+      "type": "rule",
+      "domain": "leadership",
+      "title": "Data-driven architecture: all logic in YAML, none in code",
+      "severity": "critical",
+      "description": "# Data-driven architecture: all logic in YAML, none in code\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador's core architectural principle is 100% data-driven behavior. Routing logic lives in routing-config.yaml, workflow steps in flows/*.yaml, quality thresholds in scoring/thresholds.yaml, enforcement rules in rules/*.yaml. The runtime (intent-classifier.js, flow-parser.js) is a generic interpreter that reads YAML — it contains no domain knowledge. This means behavior changes are YAML edits, not code changes, and the entire system is auditable by reading config files.\n\n## Example\n\n```typescript\nAdding a new intent: edit routing-config.yaml (add intent + mode + chain-mapping). Zero code changes needed.\n```\n\n## Why\n\nData-driven architecture enables non-engineers to modify system behavior, makes changes auditable in version control, and eliminates code-level bugs in routing logic.",
+      "tags": ["data-driven", "yaml", "architecture", "separation-of-concerns", "auditability"]
+    },
+    {
+      "id": "pattern-leadership-quick-agent-persona-system-8-specialized-characters-for-",
+      "type": "rule",
+      "domain": "leadership",
+      "title": "Agent persona system: 8 specialized characters for mode-specific guidance",
+      "severity": "warning",
+      "description": "# Agent persona system: 8 specialized characters for mode-specific guidance\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nEach Salvador mode has a dedicated persona that shapes the agent's focus and communication style. The Architect (Build), The Painter (Design), The Critic (Review), The Psychologist (UX), The Scientist (Test), The Curator (Deploy), The Surgeon (Fix), The Weaver (Integrate). Personas are defined in flow YAML metadata and activated via morph. Each persona brings domain-specific vocabulary and evaluation criteria.\n\n## Example\n\n```typescript\nflows/ux-auditor.yaml: metadata.persona: 'The Psychologist'. flows/recovery.yaml: metadata.persona: 'The Surgeon'.\n```\n\n## Why\n\nSpecialized personas improve output quality by constraining the agent's focus. The Critic reviews differently than The Architect builds.",
+      "tags": ["personas", "agent-modes", "specialization", "communication-style"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/methodology.json

@@ -0,0 +1,33 @@
+{
+  "domain": "methodology",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-methodology-quick-multi-phase-weighted-scoring-with-severity-deducti",
+      "type": "pattern",
+      "domain": "methodology",
+      "title": "Multi-phase weighted scoring with severity deductions",
+      "severity": "warning",
+      "description": "# Multi-phase weighted scoring with severity deductions\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nFlow quality is calculated via weighted scoring formulas defined in scoring/thresholds.yaml. Weighted-average: sum(scores[i] * weights[i]) / sum(weights). Pass-rate: passed/total * 100. Severity-weighted: 100 minus deductions (critical: -30, major: -15, minor: -5, info: 0). Each flow defines per-phase weights (e.g., developer.yaml: discovery 10%, design 20%, implementation 40%, validation 30%). Final grade: A+(95+), A(90+), B(80+), C(70+), D(60+), F(<60).\n\n## Example\n\n```typescript\nDeveloper flow: score = discovery(85)*0.10 + design(90)*0.20 + impl(75)*0.40 + validation(80)*0.30 = 80.5 → Grade B\n```\n\n## Why\n\nWeighted scoring prevents gaming — a perfect design score can't compensate for poor implementation when implementation weight is 40%.",
+      "tags": ["scoring", "weighted-average", "severity", "grades", "quality-metrics"]
+    },
+    {
+      "id": "pattern-methodology-quick-universal-flow-gate-system-gate-score-checkpoint-b",
+      "type": "pattern",
+      "domain": "methodology",
+      "title": "Universal flow gate system: GATE, SCORE, CHECKPOINT, BRANCH",
+      "severity": "critical",
+      "description": "# Universal flow gate system: GATE, SCORE, CHECKPOINT, BRANCH\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nEvery flow step terminates with one of 4 gate types defined in scoring/thresholds.yaml. GATE: binary pass/fail, blocks on fail with no retry. SCORE: grades output 0-100 against a min threshold, up to 2 retries with BRANCH-back. CHECKPOINT: saves state for potential rollback, always passes. BRANCH: routes execution based on a condition (on-true/on-false paths). Gates compose into quality ladders: CHECKPOINT → work → SCORE → work → GATE.\n\n## Example\n\n```typescript\ndeveloper.yaml: discover(GATE) → design(SCORE min:70) → validate-design(SCORE min:80) → implement(CHECKPOINT) → validate-impl(SCORE min:80)\n```\n\n## Why\n\nGates enforce quality at each phase boundary. Without them, low-quality output from early phases compounds into failures in later phases.",
+      "tags": ["gates", "quality", "flow-control", "scoring", "checkpoints"]
+    },
+    {
+      "id": "pattern-methodology-quick-intake-router-9-intent-classification-with-confide",
+      "type": "playbook",
+      "domain": "methodology",
+      "title": "INTAKE router: 9-intent classification with confidence scoring",
+      "severity": "critical",
+      "description": "# INTAKE router: 9-intent classification with confidence scoring\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe INTAKE router is the first step for any task. It extracts keywords from user text, matches against 9 intents (CREATE, FIX, REVIEW, PLAN, ENHANCE, DELIVER, INTEGRATE, TEST, UX_AUDIT), maps to modes, selects chain sequences via context-sensitive chain-mappings, and calculates confidence. HIGH confidence (95+): 2+ keywords AND intent match. MEDIUM (70-94): 1 keyword OR intent match. LOW (<70): falls back to DESIGN-MODE with clarification request.\n\n## Example\n\n```typescript\n'Fix the broken hover state on Button' → intent:FIX, mode:FIX-MODE, context:component, chains:[RECOVERY-flow], confidence:HIGH\n```\n\n## Why\n\nCorrect routing is the highest-leverage decision in the pipeline. Wrong intent → wrong mode → wrong flow → wrong output.",
+      "tags": ["intake", "routing", "intent-classification", "confidence", "9-intents"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/monorepo.json

@@ -0,0 +1,33 @@
+{
+  "domain": "monorepo",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-monorepo-quick-cross-repo-atomic-chain-sync-from-mcp-to-vault",
+      "type": "pattern",
+      "domain": "monorepo",
+      "title": "Cross-repo atomic chain sync from MCP to vault",
+      "severity": "critical",
+      "description": "# Cross-repo atomic chain sync from MCP to vault\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nAtomic chains in chains/atomic.yaml are auto-generated from salvador-mcp/src/tools/registry/tool-definitions.ts. The sync command reads MCP tool definitions and generates YAML with chain IDs, tool mappings, output types, related chains, and tags. Consumer projects never edit atomic.yaml directly — it's immutable and regenerated on each sync.\n\n## Example\n\n```typescript\ncd salvador-mcp && npm run sync-chains → generates chains/atomic.yaml with 63 tools across 16 categories\n```\n\n## Why\n\nSingle source of truth for tool→chain mapping prevents drift between MCP server capabilities and vault chain references.",
+      "tags": ["cross-repo", "sync", "atomic-chains", "code-generation", "immutable"]
+    },
+    {
+      "id": "pattern-monorepo-quick-project-specific-rules-directory-for-per-consumer-",
+      "type": "pattern",
+      "domain": "monorepo",
+      "title": "Project-specific rules directory for per-consumer overrides",
+      "severity": "warning",
+      "description": "# Project-specific rules directory for per-consumer overrides\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nVault stores project-specific rules in projects/{project-name}/ with a project.json manifest and rules.md file. When working on a consumer project, Salvador checks for project-level overrides before applying global rules. This allows per-project constraints (e.g., partner-portal has Action Overflow and Dialog vs Page rules) without polluting the global design system rules.\n\n## Example\n\n```typescript\nprojects/partner-portal/project.json: { rules: ['action-overflow', 'dialog-vs-page'], keyFiles: ['src/pages/**'] }\n```\n\n## Why\n\nGlobal rules apply everywhere; project rules apply only in context. Prevents one project's constraints from leaking into another.",
+      "tags": ["project-rules", "overrides", "consumer-projects", "isolation"]
+    },
+    {
+      "id": "pattern-monorepo-quick-hook-export-pipeline-from-vault-rules-to-consumer-",
+      "type": "playbook",
+      "domain": "monorepo",
+      "title": "Hook export pipeline from vault rules to consumer projects",
+      "severity": "critical",
+      "description": "# Hook export pipeline from vault rules to consumer projects\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nRules defined in chains/rules/*.yaml are transformed into runtime hookify rules via a 3-step pipeline: (1) npm run sync-hooks generates .claude/hookify.*.local.md files in the vault. (2) npm run export-hooks pushes these to consumer project's .claude/ directory. (3) Consumer's hookify-plus runtime enforces rules during development. Supports block/warn/remind actions with regex pattern matching on file content and paths.\n\n## Example\n\n```typescript\nchains/rules/enforcement.yaml#no-any-types → .claude/hookify.enforcement.local.md → consumer/.claude/hookify.enforcement.local.md\n```\n\n## Why\n\nCentralizes quality rules in vault while distributing enforcement to consumer projects. Changes propagate on next export without consumer code changes.",
+      "tags": ["hooks", "export", "consumer-projects", "enforcement", "pipeline"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/other.json

@@ -0,0 +1,73 @@
+{
+  "domain": "other",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-other-quick-config-cache-reset-pattern-for-test-isolation",
+      "type": "pattern",
+      "domain": "other",
+      "title": "Config cache reset pattern for test isolation",
+      "severity": "warning",
+      "description": "# Config cache reset pattern for test isolation\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe intent classifier caches parsed routing-config.yaml in a module-level variable for performance. Tests that modify routing behavior must call resetConfigCache() before each test to prevent cross-test contamination. This pattern applies to any module that caches config at import time. In vitest, use beforeEach(() => resetConfigCache()) in test setup. The flow-parser similarly caches loaded flows and must be tested with fresh imports or cache-busting.\n\n## Example\n\n```typescript\nimport { resetConfigCache } from '../runtime/intent-classifier.js'; beforeEach(() => resetConfigCache());\n```\n\n## Why\n\nModule-level caching is good for performance but creates hidden state in tests. Explicit cache reset ensures test independence.",
+      "tags": ["testing", "cache", "isolation", "config", "vitest"]
+    },
+    {
+      "id": "pattern-other-quick-domain-vocabulary-extension-pattern-for-new-proble",
+      "type": "pattern",
+      "domain": "other",
+      "title": "Domain vocabulary extension pattern for new problem spaces",
+      "severity": "suggestion",
+      "description": "# Domain vocabulary extension pattern for new problem spaces\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nNew domains are added by creating a YAML file in chains/domains/ following the ui-components.yaml template. Each domain defines: context-keywords (terms that trigger context detection), entity-synonyms (aliases like modal→dialog), classification levels, and chain-preferences (which chains are relevant per context). After adding a domain file, update routing-config.yaml context-keywords section to reference the new terms. No code changes needed — the runtime reads domains dynamically.\n\n## Example\n\n```typescript\nNew domain: domains/backend-api.yaml with keywords [endpoint, route, api, service, backend] and entity-synonyms [endpoint→route, handler→controller]\n```\n\n## Why\n\nDomain vocabularies make the system adaptable to new problem spaces without modifying core logic. Each domain is a pluggable knowledge module.",
+      "tags": ["extensibility", "domains", "vocabulary", "customization"]
+    },
+    {
+      "id": "pattern-other-quick-escape-hatch-strategy-structured-recovery-from-stu",
+      "type": "pattern",
+      "domain": "other",
+      "title": "Escape hatch strategy: structured recovery from stuck states",
+      "severity": "warning",
+      "description": "# Escape hatch strategy: structured recovery from stuck states\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador defines explicit escape hatches in CLAUDE.md for common stuck states. 'Same error 3x' → change-approach (don't retry the same thing). 'Context growing' → make-smaller (decompose the task). 'Can't define done' → clarify-objective (stop and ask). 'Fighting the system' → step-back (reassess the approach). On final failure, escalate with structured task-format handoff. The recovery flow (flows/recovery.yaml) implements these as formal steps: diagnose → isolate → plan-fix → implement-fix → verify-fix → regression-check.\n\n## Example\n\n```typescript\nIF-STUCK: match 'same error 3x' → action: change-approach. match 'fighting system' → action: step-back.\n```\n\n## Why\n\nAutomated workflows without escape hatches spiral into infinite retries. Explicit recovery strategies bound failure modes.",
+      "tags": ["escape-hatch", "recovery", "stuck", "error-handling", "resilience"]
+    },
+    {
+      "id": "anti-pattern-other-below-threshold-loop-custom",
+      "type": "pattern",
+      "domain": "other",
+      "title": "Below-threshold loop-custom",
+      "severity": "warning",
+      "description": "# Below-threshold loop-custom\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 150 sessions.\nFlow: loop-custom\n## Anti-Pattern\n\nSession 2026-02-27-029a6dfc scored 30 (grade: F), which is below the acceptable threshold. Review the approach and gate failures for improvement opportunities.\n\n## Evidence\n\n- Observed in 150 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `low-score`",
+      "tags": ["low-score", "loop-custom", "custom"],
+      "appliesTo": ["loop-custom"]
+    },
+    {
+      "id": "pattern-other-efficient-custom-loop-passed-on-first-it",
+      "type": "pattern",
+      "domain": "other",
+      "title": "Efficient custom loop — passed on first iteration",
+      "severity": "suggestion",
+      "description": "# Efficient custom loop — passed on first iteration\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 46 sessions.\nFlow: loop-custom\n## Pattern\n\nSession 2026-02-27-01010a83 completed custom validation on the first try (score: 85, grade: B). The initial approach was sufficient without iteration.\n\n## Evidence\n\n- Observed in 46 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `loop-completed-efficiently`",
+      "tags": ["loop", "efficient", "first-try", "custom", "loop-custom"],
+      "appliesTo": ["loop-custom"]
+    },
+    {
+      "id": "pattern-other-high-scoring-promote-hit-approach",
+      "type": "pattern",
+      "domain": "other",
+      "title": "High-scoring PROMOTE-HIT approach",
+      "severity": "suggestion",
+      "description": "# High-scoring PROMOTE-HIT approach\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 2 sessions.\nFlow: PROMOTE-HIT\n## Pattern\n\nSession 2026-03-02-59eab96e achieved a score of 95 (grade: A+). The approach used in this session produced excellent results.\n\n## Evidence\n\n- Observed in 2 sessions across flow `PROMOTE-HIT`\n- Promoted: 2026-03-02\n- Source rule: `excellent-score`",
+      "tags": ["high-score", "PROMOTE-HIT"],
+      "appliesTo": ["PROMOTE-HIT"]
+    },
+    {
+      "id": "pattern-other-successful-custom-loop-score-85",
+      "type": "pattern",
+      "domain": "other",
+      "title": "Successful custom loop (score: 85)",
+      "severity": "suggestion",
+      "description": "# Successful custom loop (score: 85)\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 46 sessions.\nFlow: loop-custom\n## Pattern\n\nSession 2026-02-27-01010a83 completed custom validation with a score of 85 (grade: B). This approach worked well for custom tasks.\n\n## Evidence\n\n- Observed in 46 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `loop-good-score`",
+      "tags": ["loop", "success", "good-score", "custom", "loop-custom"],
+      "appliesTo": ["loop-custom"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/performance.json

@@ -0,0 +1,35 @@
+{
+  "domain": "performance",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-performance-quick-composite-chain-expansion-for-reusable-tool-sequen",
+      "type": "pattern",
+      "domain": "performance",
+      "title": "Composite chain expansion for reusable tool sequences",
+      "severity": "warning",
+      "description": "# Composite chain expansion for reusable tool sequences\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nComposites in chains/composites.yaml define reusable sequences that expand to multiple atomic chains at runtime. Example: design-component expands to [shadcn-available, component-exists, dev-rules, architecture-patterns, component-workflow, contrast]. gather-build-knowledge expands to vault search + dev rules + architecture patterns. Composites prevent duplication across flows — changing a composite updates all flows that reference it. Expansion is recursive (composites can contain other composites).\n\n## Example\n\n```typescript\ncomposites.yaml: design-component: [shadcn-available, component-exists, dev-rules, architecture-patterns, component-workflow, contrast]\n```\n\n## Why\n\nWithout composites, each flow would duplicate the same 6-chain sequence. Composites provide single-point-of-change for shared workflows.",
+      "tags": ["composites", "reuse", "chain-expansion", "deduplication", "recursive"]
+    },
+    {
+      "id": "pattern-performance-quick-pre-weighted-keyword-matching-for-o-n-intent-class",
+      "type": "pattern",
+      "domain": "performance",
+      "title": "Pre-weighted keyword matching for O(n) intent classification",
+      "severity": "warning",
+      "description": "# Pre-weighted keyword matching for O(n) intent classification\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nIntent classification uses pre-computed keyword weights from routing-config.yaml instead of runtime NLP. Each intent has a keyword list with static weights (CREATE: 1.0, ENHANCE: 0.9 to avoid confusion with CREATE). Classification is O(n) string matching against the keyword list, plus regex semantic patterns for contextual signals. This avoids LLM inference costs for routing decisions. The tradeoff is potential substring collisions (e.g., 'implement' matching inside 'implementation').\n\n## Example\n\n```typescript\nclassifyIntent('Create a Button') → keyword 'create' matched (weight 1.0) + semantic pattern matched (weight 0.85) → intent: CREATE, score: 0.925\n```\n\n## Why\n\nLLM-based intent classification adds latency and cost to every request. Pre-weighted keywords give deterministic, fast, auditable routing.",
+      "tags": ["intent-classification", "keyword-weights", "O(n)", "no-llm", "routing"]
+    },
+    {
+      "id": "anti-pattern-performance-empty-array-on-failure",
+      "type": "anti-pattern",
+      "domain": "performance",
+      "title": "Returning empty array for all failure modes",
+      "severity": "warning",
+      "description": "# Returning empty array for all failure modes\n\n## Context\n\nFunctions that scan directories or read files\n\n## Anti-Pattern\n\nReturning [] for 'not found', 'empty', and 'error' states makes it impossible to distinguish between normal (nothing to do) and abnormal (broken config) situations.\n\n## Example (Bad)\n\n```typescript\n// BAD:\nfunction getHooks(dir) {\n  if (!fs.existsSync(dir)) return []; // Not found\n  try { return fs.readdirSync(dir); }\n  catch (err) { return []; } // Error - same as not found!\n}\n```\n\n## Why It's Wrong\n\nUser sees 'No hooks found' but doesn't know if directory is missing, empty, or unreadable. Can't troubleshoot without knowing which case applies.\n\n## Correct Approach\n\nSee: [detailed-status-returns](../../patterns/other/detailed-status-returns.md)",
+      "tags": ["cli", "ux", "anti-pattern", "error-handling"],
+      "appliesTo": ["scripts/setup-project.js"],
+      "context": "Related: detailed-status-returns"
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/prisma.json

@@ -0,0 +1,33 @@
+{
+  "domain": "prisma",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-prisma-quick-yaml-as-schema-for-data-driven-configuration-contr",
+      "type": "pattern",
+      "domain": "prisma",
+      "title": "YAML-as-Schema for data-driven configuration contracts",
+      "severity": "critical",
+      "description": "# YAML-as-Schema for data-driven configuration contracts\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador uses YAML files as the single source of truth for all system behavior. routing-config.yaml defines intent→mode→chain mappings, flows/*.yaml define workflow steps with gates, and scoring/thresholds.yaml defines quality criteria. This eliminates code-level logic — all routing, scoring, and flow decisions are data-driven and auditable.\n\n## Example\n\n```typescript\nrouting-config.yaml: intents.CREATE.keywords → modes.BUILD-MODE.from-intents → chain-mappings.BUILD-MODE.component.chains\n```\n\n## Why\n\nData-driven config is auditable, versionable, and modifiable without code changes. Reduces coupling between behavior logic and runtime.",
+      "tags": ["yaml", "schema", "data-driven", "configuration", "contracts"]
+    },
+    {
+      "id": "pattern-prisma-quick-intelligence-data-file-dependency-graph-via-manife",
+      "type": "pattern",
+      "domain": "prisma",
+      "title": "Intelligence data file dependency graph via manifest",
+      "severity": "warning",
+      "description": "# Intelligence data file dependency graph via manifest\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nintelligence/manifest.yaml catalogs all knowledge files with metadata: version, domain, status (active|deprecated|reference-only), dependencies (other files referenced), and queryPatterns (natural language queries answered). This creates a dependency DAG that validates data integrity — if color-intelligence.json depends on token-definitions.json, both must be present and compatible.\n\n## Example\n\n```typescript\nmanifest.yaml entry: { file: color-intelligence.json, version: 2.1.0, domain: design, dependencies: [token-definitions.json], status: active }\n```\n\n## Why\n\nPrevents stale or broken intelligence data from corrupting vault search results.",
+      "tags": ["manifest", "dependency-graph", "intelligence", "data-integrity"]
+    },
+    {
+      "id": "pattern-prisma-quick-vault-entry-lifecycle-capture-index-search-apply",
+      "type": "playbook",
+      "domain": "prisma",
+      "title": "Vault entry lifecycle: capture → index → search → apply",
+      "severity": "warning",
+      "description": "# Vault entry lifecycle: capture → index → search → apply\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nKnowledge follows a 4-stage lifecycle: (1) Capture via capture_quick/capture_knowledge writes markdown to docs/vault/patterns/ or docs/vault/anti-patterns/. (2) Index builds TF-IDF embeddings (279-term vocabulary). (3) Search uses weighted scoring: semantic 35%, roleMatch 15%, category 15%, temporal 10%, severity 10%, pathMatch 10%, tagOverlap 5%. (4) Apply injects gathered knowledge into flow execution via gather-*-knowledge composites.\n\n## Example\n\n```typescript\ncapture_quick → docs/vault/patterns/testing/my-pattern.md → build-index → search_vault_intelligent returns scored results → compile_prompt injects into flow\n```\n\n## Why\n\nUnderstanding the full lifecycle prevents common issues like captured knowledge not appearing in search (missing index rebuild) or low relevance scores (poor tags/category).",
+      "tags": ["vault", "lifecycle", "indexing", "search", "knowledge-management"]
+    }
+  ]
+}

package/dist/knowledge-packs/salvador/salvador-engineering/vault/product-strategy.json

@@ -0,0 +1,42 @@
+{
+  "domain": "product-strategy",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-product-strategy-quick-maya-principle-guides-design-system-evolution-deci",
+      "type": "rule",
+      "domain": "product-strategy",
+      "title": "MAYA principle guides design system evolution decisions",
+      "severity": "warning",
+      "description": "# MAYA principle guides design system evolution decisions\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador applies Raymond Loewy's MAYA (Most Advanced Yet Acceptable) principle when making design decisions. New components and patterns should push boundaries while remaining familiar enough for immediate adoption. This means: prefer established component APIs (Button, Card, Dialog) over novel abstractions; extend existing patterns rather than replacing them; introduce one new concept per component, not many.\n\n## Example\n\n```typescript\nMAYA check: 'Will users understand this component in 5 seconds?' If not, simplify the API or add familiar affordances.\n```\n\n## Why\n\nDesign systems fail when they innovate too far ahead of consumers. MAYA ensures adoption by balancing novelty with familiarity.",
+      "tags": ["maya", "design-philosophy", "adoption", "progressive-disclosure"]
+    },
+    {
+      "id": "pattern-product-strategy-quick-wu-wei-philosophy-don-t-fight-the-codebase",
+      "type": "rule",
+      "domain": "product-strategy",
+      "title": "Wu Wei philosophy: don't fight the codebase",
+      "severity": "warning",
+      "description": "# Wu Wei philosophy: don't fight the codebase\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador's escape hatch strategy applies Wu Wei (effortless action) as a diagnostic lens. When stuck, ask 'Am I fighting the codebase?' If yes: step back and find the natural flow. Concrete triggers: same error 3x → change approach entirely; context growing uncontrollably → make the task smaller; can't define done → clarify objective before continuing; fighting the system → step back and reassess.\n\n## Example\n\n```typescript\nIF-STUCK: 'same error 3x' → change-approach. 'context growing' → make-smaller. 'fighting system' → step-back.\n```\n\n## Why\n\nPrevents sunk-cost fallacy in automated workflows. Recognizing when to pivot saves more time than brute-forcing a failing approach.",
+      "tags": ["wu-wei", "philosophy", "stuck", "escape-hatch", "recovery"]
+    },
+    {
+      "id": "pattern-product-strategy-quick-token-hierarchy-as-a-product-decision-semantic-con",
+      "type": "rule",
+      "domain": "product-strategy",
+      "title": "Token hierarchy as a product decision: semantic > contextual > primitive",
+      "severity": "critical",
+      "description": "# Token hierarchy as a product decision: semantic > contextual > primitive\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador enforces a 3-tier token hierarchy as a product-level decision, not just a styling convention. Tier 1 (Semantic): text-error, bg-warning — communicates meaning. Tier 2 (Contextual): text-primary, bg-surface — communicates role. Tier 3 (Primitive): BLOCKED via hookify rules. This hierarchy ensures component portability across themes and brands — semantic tokens adapt automatically.\n\n## Example\n\n```typescript\nProduct decision: bg-error (semantic) adapts to red in light theme, dark-red in dark theme. bg-red-500 (primitive) does not adapt.\n```\n\n## Why\n\nToken hierarchy is a product architecture decision that enables multi-brand and multi-theme support without component rewrites.",
+      "tags": ["tokens", "hierarchy", "semantic", "portability", "theming"]
+    },
+    {
+      "id": "roadmap-product-strategy-capture-cold-start-solution-day-one-value-for-every-forged",
+      "type": "pattern",
+      "domain": "product-strategy",
+      "title": "Cold Start Solution — Day-One Value for Every Forged Agent",
+      "severity": "critical",
+      "description": "# Cold Start Solution — Day-One Value for Every Forged Agent\n\n## Context\n\nPromoted from anti-pattern: Open Source Gap — Cold Start Problem. Covers: (1) Knowledge Pack auto-install during forge, (2) first-run wizard that captures user's first pattern, (3) pre-built brain recommendations for common intents, (4) starter vault with 20-30 high-value patterns per domain.\n\n## Objective\n\nNew users get empty vault, zero brain data, no patterns. Value only shows after weeks. Users judge tools in 10 minutes. Solution: pre-seeded domain vaults via Knowledge Packs, guided first-capture flow, starter brain recommendations, and a wow-in-5-minutes onboarding experience.\n\n## Milestones\n\nN/A\n\n## Why\n\nUsers judge tools in the first 10 minutes. Without a wow moment on day one, adoption dies at onboarding. Every other feature is irrelevant if users churn before experiencing accumulated intelligence.",
+      "tags": ["cold-start", "onboarding", "knowledge-packs", "adoption", "ux"]
+    }
+  ]
+}