@soleri/core 9.12.1 → 9.14.0

package/dist/knowledge-packs/knowledge-packs/salvador/salvador-craft/vault/styling.json

@@ -0,0 +1,44 @@
+{
+  "domain": "styling",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-styling-quick-arbitrary-tailwind-value-blocking-to-enforce-token",
+      "type": "pattern",
+      "domain": "styling",
+      "title": "Arbitrary Tailwind value blocking to enforce token-only spacing",
+      "severity": "critical",
+      "description": "# Arbitrary Tailwind value blocking to enforce token-only spacing\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe forbidden-primitive-tokens rule in chains/rules/enforcement.yaml blocks arbitrary Tailwind values like w-[200px], p-[15px], shadow-[...], and !important. These bypass the design token system and create inconsistent spacing/sizing. Instead, use named Tailwind classes from the design token scale (p-2, gap-4, w-full) which map to the two-layer spacing system (4pt precision + 8pt rhythm). The rule fires as a blocking action on .tsx files.\n\n## Example\n\n```typescript\nBlocked: className='w-[200px] p-[15px]'. Fix: className='w-48 p-4' (uses token scale).\n```\n\n## Why\n\nArbitrary values create visual inconsistency and break theme portability. Token-only spacing ensures all components align to the same grid.",
+      "tags": ["tailwind", "arbitrary-values", "spacing", "tokens", "enforcement"]
+    },
+    {
+      "id": "pattern-styling-two-layer-spacing-system",
+      "type": "pattern",
+      "domain": "styling",
+      "title": "Two-Layer Spacing System (4pt Precision + 8pt Rhythm)",
+      "severity": "critical",
+      "description": "# Two-Layer Spacing System\n\n## Context\n\nSpacing inconsistency is one of the most common design system violations. Teams often debate \"4pt grid vs 8pt grid\" as if they're mutually exclusive. The solution is not choosing one — it's assigning responsibility to each.\n\n## Pattern\n\n**One scale, two layers.** Use a single unified scale with role-based layer assignment:\n\n**Scale:** `4 · 8 · 12 · 16 · 20 · 24 · 32 · 40 · 48`\n\n**4pt precision layer** — handles detail:\n- Icons and text alignment (4px gap)\n- Typography baseline adjustments (4px increments)\n- Internal component spacing (12px, 20px)\n- Fine-grained padding where 8pt is too coarse\n\n**8pt rhythm layer** — creates rhythm:\n- Layout-level spacing (16px, 24px, 32px)\n- Component padding and margins\n- Section spacing (40px, 48px)\n- Page-level divisions\n\n**Baseline grid:** Typography must snap to the 8pt baseline grid. Line-heights should be multiples of 8px (16px, 24px, 32px) so text aligns across columns and components.\n\n**Philosophy:** Parsed, not guessed. Spacing values must be enforced programmatically — never eyeballed.\n\n## Example\n\n```tsx\n// CORRECT: Values from the scale, layers respected\n<Card className=\"p-6\">           {/* 24px: rhythm layer */}\n  <div className=\"flex gap-1\">   {/* 4px: precision layer (icon-text) */}\n    <Icon size={16} />\n    <span>Label</span>\n  </div>\n  <div className=\"mt-4\">         {/* 16px: rhythm layer (content gap) */}\n    <p className=\"leading-6\">     {/* 24px line-height: snaps to 8pt baseline */}\n      Content text here\n    </p>\n  </div>\n</Card>\n\n// WRONG: Random off-grid values\n<Card style={{ padding: '18px' }}>    {/* 18px: OFF GRID */}\n  <div style={{ gap: '5px' }}>       {/* 5px: OFF GRID */}\n    <Icon size={16} />\n    <span>Label</span>\n  </div>\n  <div style={{ marginTop: '29px' }}> {/* 29px: OFF GRID */}\n    <p style={{ lineHeight: '15px' }}> {/* 15px: OFF BASELINE GRID */}\n      Content text here\n    </p>\n  </div>\n</Card>\n```\n\n## Why\n\n- **Consistent grid creates clarity** — users perceive visual harmony even if they can't articulate why\n- **Random values confuse users** — 5px, 7px, 18px, 29px create subtle visual noise that erodes trust\n- **Two layers prevent the false choice** — 4pt and 8pt serve different roles, not competing philosophies\n- **Baseline grid anchors typography** — text that snaps to the grid feels intentional and aligned\n- **Parsed, not guessed** — programmatic enforcement catches violations that the human eye misses",
+      "tags": [
+        "spacing",
+        "grid",
+        "4pt",
+        "8pt",
+        "baseline",
+        "rhythm",
+        "precision",
+        "layout",
+        "design-system"
+      ],
+      "appliesTo": ["all-components", "layouts", "typography"]
+    },
+    {
+      "id": "pattern-styling-quick-token-enforcement-pyramid-blocked-forbidden-prefer",
+      "type": "pattern",
+      "domain": "styling",
+      "title": "Token enforcement pyramid: blocked → forbidden → preferred layers",
+      "severity": "critical",
+      "description": "# Token enforcement pyramid: blocked → forbidden → preferred layers\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador enforces color/token usage via a 3-layer pyramid in chains/rules/enforcement.yaml. Layer 1 (Blocked): hardcoded #hex values, rgb(), rgba(), drop-shadow-*, arbitrary Tailwind values like w-[200px]. Layer 2 (Forbidden): primitive token names text-white, text-black, bg-white, bg-black, and direct primitive imports (import { PRIMARY }). Layer 3 (Preferred): semantic tokens text-error, bg-warning, border-accent. Each layer has increasing strictness from suggestion to blocking action.\n\n## Example\n\n```typescript\nBlocked: style={{ color: '#FF0000' }}. Forbidden: className='text-white'. Preferred: className='text-inverse'.\n```\n\n## Why\n\nThe pyramid provides graduated enforcement — hardcoded values are caught immediately, primitive tokens get warnings, and semantic tokens are the only path that passes all gates.",
+      "tags": ["tokens", "enforcement", "pyramid", "blocked", "semantic-colors"]
+    }
+  ]
+}

package/dist/knowledge-packs/knowledge-packs/salvador/salvador-craft/vault/ux-laws.json

@@ -0,0 +1,36 @@
+{
+  "domain": "ux-laws",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "canonical-ux-border-radius",
+      "type": "pattern",
+      "domain": "ux-laws",
+      "title": "Border Radius Scale",
+      "severity": "critical",
+      "description": "## Rule\n\nAll border-radius values MUST use only the following scale:\n\n| Token | Value | Use Case |\n|-------|-------|----------|\n| radius-none | **0px** | Data tables, code blocks, sharp-edged containers |\n| radius-sm | **4px** | Subtle rounding: inputs, badges, tooltips, chips |\n| radius-md | **8px** | Prominent rounding: cards, modals, dropdowns, buttons |\n| radius-full | **9999px** | Circular elements only: avatars, status dots, icon badges |\n\n### Usage Rules\n\n- **0px** (`radius-none`): Required for data tables (`<table>`), code blocks (`<pre>`, `<code>`), and any element where sharp edges communicate precision or structure.\n- **4px** (`radius-sm`): Default for inline and small interactive elements -- text inputs, select dropdowns, badges, tags, tooltips.\n- **8px** (`radius-md`): Default for container and overlay elements -- cards, dialogs, modals, popovers, dropdown menus, buttons.\n- **9999px** (`radius-full`): Restricted to inherently circular or pill-shaped elements: user avatars, status indicator dots, and small icon badges. Never apply to rectangular content containers, cards, or buttons (use `radius-md` for pill-shaped buttons if needed).\n\n### Forbidden\n\n- Arbitrary values: `2px`, `3px`, `6px`, `10px`, `12px`, `16px`, `20px`, `24px`.\n- Using `rounded-full` on non-avatar, non-badge elements (cards, modals, containers).\n- Mixing different radii on the same element (e.g., `border-radius: 4px 8px 4px 8px`).\n\n## Why\n\n1. **Visual language** -- Consistent corner rounding creates a recognizable shape language. When everything uses the same radii, the interface feels cohesive and intentional.\n2. **Hierarchy signaling** -- The two primary values (4px and 8px) create a subtle hierarchy: smaller elements get less rounding, larger containers get more. This mapping helps users distinguish interactive controls from content containers.\n3. **Avoiding the \"pillow\" effect** -- Unrestricted border-radius leads to over-rounded interfaces where elements look inflated and boundaries between components become ambiguous.\n4. **Design-to-code fidelity** -- A constrained set of values eliminates guesswork when translating designs to code and prevents per-component radius drift.\n\n## Assertions\n\n- No `border-radius` property may resolve to a value outside `[0, 4, 8, 9999]` px.\n- Elements with `radius-full` (9999px) must be one of: avatar, status dot, or icon badge.\n- Data table elements (`<table>`, `<thead>`, `<tbody>`, `<tr>`, `<td>`, `<th>`) must have `border-radius: 0`.\n- Code block elements (`<pre>`, `<code>`) must have `border-radius: 0`.\n- No element may have mixed corner radii (all four corners must use the same value).",
+      "tags": ["border-radius", "shape", "corners", "design-tokens"],
+      "tier": "agent"
+    },
+    {
+      "id": "canonical-ux-loading-states",
+      "type": "pattern",
+      "domain": "ux-laws",
+      "title": "Loading States",
+      "severity": "critical",
+      "description": "## Rule\n\nLoading indicators MUST use the correct pattern based on what is loading:\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| **Content areas** (pages, lists, cards, feeds, dashboards) | **Skeleton loader** | Gray placeholder shapes matching the expected layout |\n| **User-initiated actions** (button click, form submit, toggle) | **Spinner** | Inline spinner within the triggering element |\n\n### Skeleton Loaders (Content)\n\n- Skeleton shapes MUST approximate the dimensions and position of the content they replace: a text line skeleton should be the width and height of a text line, an avatar skeleton should be a circle the size of the avatar.\n- Use a subtle shimmer animation (left-to-right gradient sweep) to indicate activity. Static gray blocks feel broken.\n- Color: `bg-skeleton` token (typically 10-15% opacity of the text color on the surface background).\n- Do not show skeleton state for longer than 10 seconds. If loading exceeds 10 seconds, transition to an explicit \"still loading\" message with a retry option.\n- Remove skeleton elements individually as content loads (progressive reveal), not all at once.\n\n### Spinners (Actions)\n\n- Use spinners **only** for discrete user actions: button submissions, toggle switches, inline saves.\n- The spinner replaces the element's label/icon while maintaining the element's dimensions (no layout shift).\n- Set `aria-busy=\"true\"` on the element or region while loading.\n- Spinner size: 16px for inline/button use, 24px for standalone section loaders.\n- Spinner color: inherit from the parent element's text color token.\n\n### Forbidden Patterns\n\n- **Full-page spinners**: Never block the entire viewport with a centered spinner. Use skeleton loaders for page-level content.\n- **Spinners for content areas**: A spinner in the middle of a card grid or feed provides no spatial context for what will load.\n- **No loading indicator**: Content that takes > 300ms to appear must have a loading indicator. Below 300ms, no indicator is needed (avoid flicker).\n- **Progress bars for indeterminate loads**: Do not show a progress bar unless you can report real completion percentage.\n\n### Timing\n\n- Delay showing any loading indicator by **300ms**. If the content arrives within 300ms, skip the indicator entirely to avoid a flash.\n- After 300ms, show the skeleton or spinner immediately (no fade-in delay).\n\n## Why\n\n1. **Perceived performance** -- Skeleton loaders make the interface feel faster because the user sees a structural preview of the page. Research (Luke Wroblewski, Google) shows skeleton screens reduce perceived wait time by up to 35% compared to spinners.\n2. **Spatial expectation** -- Skeletons set spatial expectations: the user knows where content will appear, so the page feels stable when content fills in. Spinners provide no spatial information.\n3. **Action feedback** -- Spinners within buttons and toggles give immediate feedback that the user's action was received, preventing duplicate submissions.\n4. **Layout stability** -- Skeletons that match content dimensions prevent cumulative layout shift (CLS), which improves both user experience and Core Web Vitals scores.\n\n## Assertions\n\n- Content areas (page sections, card grids, lists, feeds) must use skeleton loaders, not spinners.\n- Button and form-submit loading states must use inline spinners, not skeleton loaders.\n- No full-page spinner overlay may be used as a loading pattern.\n- Skeleton shapes must approximate the dimensions of the content they replace.\n- Loading indicators must not appear for loads completing in < 300ms.\n- Spinner elements must set `aria-busy=\"true\"` on the loading region.\n- Skeleton color must use the `bg-skeleton` design token or equivalent.\n- Loading spinner must not cause layout shift (parent element must maintain its dimensions).",
+      "tags": ["loading", "skeleton", "spinner", "perceived-performance", "ux"],
+      "tier": "agent"
+    },
+    {
+      "id": "canonical-ux-typography-scale",
+      "type": "pattern",
+      "domain": "ux-laws",
+      "title": "Typography Scale",
+      "severity": "critical",
+      "description": "## Rule\n\nAll typographic sizing MUST use only the following three-tier scale:\n\n| Token    | Font Size | Use Case |\n|----------|-----------|----------|\n| text-sm  | **14px** (0.875rem) | Captions, helper text, metadata, labels |\n| text-md  | **16px** (1rem) | Body text, form inputs, list items |\n| text-lg  | **20px** (1.25rem) | Section headings, card titles, emphasis |\n\nNo other font sizes are permitted in the component library.\n\n### Line Height\n\n| Context | Line Height |\n|---------|-------------|\n| Body text (text-sm, text-md) | **1.5** (150%) |\n| Headings (text-lg) | **1.2** (120%) |\n\n### Font Weight\n\nOnly three weights are allowed:\n\n| Token | Weight | Use Case |\n|-------|--------|----------|\n| font-regular | **400** | Body text, descriptions, helper text |\n| font-semibold | **600** | Labels, subheadings, emphasis within body |\n| font-bold | **700** | Primary headings, strong callouts |\n\n### Forbidden\n\n- Font sizes outside `[14, 16, 20]` px (e.g., 10px, 12px, 13px, 18px, 24px, 32px).\n- Font weights outside `[400, 600, 700]` (e.g., 300 light, 500 medium, 800 extrabold).\n- Line heights below 1.2 or arbitrary values like 1.3, 1.4, 1.8.\n\n## Why\n\n1. **Visual hierarchy with restraint** -- Three sizes are sufficient to establish a clear hierarchy (primary, secondary, tertiary) without visual clutter. More sizes dilute the hierarchy and force users to decode subtle differences.\n2. **Readability** -- A 1.5 line height for body text ensures comfortable reading across languages and screen sizes. A 1.2 line height for headings keeps them compact and distinct from body text.\n3. **Consistency** -- Limiting weights to three prevents the \"font-weight soup\" where 300, 400, 500, 600, 700 all appear in the same view with no discernible logic.\n4. **Performance** -- Fewer font variations mean fewer font files to load, improving page load times and reducing layout shifts.\n\n## Assertions\n\n- No `font-size` property may resolve to a value outside `[14, 16, 20]` px or their rem equivalents `[0.875, 1, 1.25]`.\n- No `font-weight` property may resolve to a value outside `[400, 600, 700]`.\n- Body text elements (`<p>`, `<span>`, `<li>`, `<td>`) must have `line-height` of `1.5`.\n- Heading elements and tokens using text-lg must have `line-height` of `1.2`.\n- No `font-size` may use absolute keywords (`x-small`, `small`, `large`, `x-large`).",
+      "tags": ["typography", "scale", "font-size", "line-height", "font-weight"],
+      "tier": "agent"
+    }
+  ]
+}

package/dist/knowledge-packs/knowledge-packs/salvador/salvador-craft/vault/ux.json

@@ -0,0 +1,36 @@
+{
+  "domain": "ux",
+  "version": "1.0.0",
+  "entries": [
+    {
+      "id": "pattern-ux-plan-summary-metadata",
+      "type": "pattern",
+      "domain": "ux",
+      "title": "Always include Plan Metadata in summaries",
+      "severity": "critical",
+      "description": "# Always include Plan Metadata in summaries\n\n## Context\n\nWhen presenting plan summaries to users after salvador_plan iterations\n\n## Pattern\n\nEvery plan summary MUST include a Plan Metadata table at the top with: Plan ID, Check ID, Grade (score/100), Status, and Expiration time\n\n## Example\n\n```typescript\n| Field | Value |\\n|-------|-------|\\n| **Plan ID** | 1770027538557_5cfbd0ba |\\n| **Check ID** | chk_plan_1770027538557_5cfbd0ba |\\n| **Grade** | A+ (95/100) |\\n| **Status** | READY_FOR_APPROVAL |\\n| **Expires** | 30 minutes from creation |\n```\n\n## Why\n\nWithout visible IDs, users cannot: (1) Resume plans after interruption, (2) Reference plans in future sessions, (3) Approve plans for task generation. The _checkId is the key to all plan operations.",
+      "tags": ["planning", "salvador", "presentation", "UX"]
+    },
+    {
+      "id": "pattern-ux-preview-before-confirmation",
+      "type": "pattern",
+      "domain": "ux",
+      "title": "Show preview of changes BEFORE asking for confirmation",
+      "severity": "warning",
+      "description": "# Show preview of changes BEFORE asking for confirmation\n\n## Context\n\nInteractive prompts that ask yes/no should show what will happen first\n\n## Pattern\n\nWhen asking user to confirm a destructive action, first show the list of affected items (files to delete, hooks to remove, etc.), then ask for confirmation.\n\n## Example\n\n```typescript\nconsole.log('Files that will be removed:');\nfor (const f of filesToDelete) {\n  console.log(`  - ${f.path}`);\n}\nconsole.log('(These are safe to remove)');\nconst confirmed = await askQuestion('Proceed? [y/N] ');\n```\n\n## Why\n\nAsking 'Clean up duplicates? [y/N]' without showing WHICH duplicates forces user to guess or abort. Preview builds confidence in the decision.",
+      "tags": ["cli", "ux", "interactive", "confirmation"],
+      "appliesTo": ["scripts/setup-project.js"]
+    },
+    {
+      "id": "anti-pattern-ux-confirm-without-preview",
+      "type": "anti-pattern",
+      "domain": "ux",
+      "title": "Asking for confirmation without showing what will change",
+      "severity": "warning",
+      "description": "# Asking for confirmation without showing what will change\n\n## Context\n\nInteractive yes/no prompts that don't show the affected items\n\n## Anti-Pattern\n\nPrompting 'Clean up duplicates? [y/N]' without first listing which files will be deleted forces users to guess or abort.\n\n## Example (Bad)\n\n```typescript\n// BAD:\nconst confirmed = await askQuestion('Clean up? [y/N] ');\nif (confirmed) deleteFiles(analysis.duplicates);\n```\n\n## Why It's Wrong\n\nUsers don't know what they're agreeing to. They either abort (friction) or blindly confirm (risk). Preview eliminates both problems.\n\n## Correct Approach\n\nSee: [preview-before-confirmation](../../patterns/other/preview-before-confirmation.md)",
+      "tags": ["cli", "ux", "anti-pattern", "interactive"],
+      "appliesTo": ["scripts/setup-project.js"],
+      "context": "Related: preview-before-confirmation"
+    }
+  ]
+}

package/dist/knowledge-packs/knowledge-packs/salvador/salvador-engineering/soleri-pack.json

@@ -0,0 +1,10 @@
+{
+  "id": "salvador-engineering",
+  "name": "Salvador Engineering — Architecture & Tooling",
+  "version": "1.0.0",
+  "description": "Architecture patterns, CLI tooling, TypeScript enforcement, testing strategies, security patterns, and methodology. Extracted from Salvador's production vault.",
+  "domains": ["architecture", "tooling", "testing", "security"],
+  "vault": {
+    "dir": "vault"
+  }
+}

package/dist/knowledge-packs/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/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/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/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/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/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/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/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"]
+    }
+  ]
+}