@soleri/core 9.14.0 → 9.15.0

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

@@ -1,73 +0,0 @@
-{
-  "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/knowledge-packs/salvador/salvador-engineering/vault/performance.json

@@ -1,35 +0,0 @@
-{
-  "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/knowledge-packs/salvador/salvador-engineering/vault/prisma.json

@@ -1,33 +0,0 @@
-{
-  "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/knowledge-packs/salvador/salvador-engineering/vault/product-strategy.json

@@ -1,42 +0,0 @@
-{
-  "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"]
-    }
-  ]
-}

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

@@ -1,47 +0,0 @@
-{
-  "domain": "react",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "pattern-react-api-simulation-tiered-approach",
-      "type": "pattern",
-      "domain": "react",
-      "title": "Tiered API Simulation for Stories",
-      "severity": "warning",
-      "description": "# Tiered API Simulation for Stories\n\n## Context\n\nWhen writing any story in a design system that involves data\n\n## Pattern\n\nUse a tiered approach: advisory for simple component stories, warning for page stories, strict for prototype-master stories. All tiers prefer API stores over inline mock data.\n\n## Example\n\n```typescript\n// Tier 1 - Simple components: inline data OK\nexport const ButtonVariants: Story = {\n  args: { label: 'Click me' }\n}\n\n// Tier 2 - Page stories: API store recommended\nimport { useUserStore } from '@/api/stores/userStore'\nexport const UsersPage: Story = {\n  render: () => {\n    const { users } = useUserStore()\n    return <UsersPageContent users={users} />\n  }\n}\n\n// Tier 3 - Prototype master: API store required\nimport { useTenantStore } from '@/api/stores/tenantStore'\nexport const Default: Story = {\n  render: () => {\n    const { tenants, isLoading, createTenant } = useTenantStore()\n    return <TenantsPage ... />\n  }\n}\n```\n\n## Why\n\nSimple Button stories don't need API complexity. Page stories benefit from realistic data flow. Prototype masters define contracts - no exceptions.",
-      "tags": ["storybook", "api-simulation", "design-system", "tiered-rules"],
-      "appliesTo": ["src/**/*.stories.tsx", "stories/**/*.stories.tsx"]
-    },
-    {
-      "id": "pattern-react-master-story-protocol",
-      "type": "pattern",
-      "domain": "react",
-      "title": "Master Story Protocol for Prototype Stories",
-      "severity": "critical",
-      "description": "# Master Story Protocol for Prototype Stories\n\n## Context\n\nWhen building prototype master stories (*-prototype-master.stories.tsx) that define page compositions\n\n## Pattern\n\nPrototype master stories must use API hooks (useApiStore, useQuery) instead of inline mock data. This ensures the frontend defines the API contract that backend implements.\n\n## Example\n\n```typescript\n// ✅ CORRECT: Use API store\nimport { useTenantStore } from '@/api/stores/tenantStore'\n\nexport const Default: Story = {\n  render: () => {\n    const { tenants, isLoading } = useTenantStore()\n    return <TenantsPage tenants={tenants} isLoading={isLoading} />\n  }\n}\n\n// ❌ FORBIDDEN: Inline mock data\nexport const Default: Story = {\n  args: {\n    tenants: [{ id: '1', name: 'Test' }]\n  }\n}\n```\n\n## Why\n\nAPI hooks define the contract between frontend and backend. When types are defined in stores, backend implements exactly those shapes - no drift between mock data and real API.",
-      "tags": ["storybook", "api-simulation", "prototype", "contract-first", "handoff"],
-      "appliesTo": ["src/stories/**/*-prototype-master.stories.tsx"]
-    },
-    {
-      "id": "anti-pattern-react-inline-mock-data-in-prototype",
-      "type": "anti-pattern",
-      "domain": "react",
-      "title": "Inline Mock Data in Prototype Stories",
-      "severity": "critical",
-      "description": "# Inline Mock Data in Prototype Stories\n\n## Context\n\nWhen writing prototype master stories\n\n## Anti-Pattern\n\nNever use inline mock data (const mockData = [...] or args: { data: [...] }) in prototype master stories. This creates drift between what frontend expects and what backend provides.\n\n## Example (Bad)\n\n```typescript\n// ❌ ANTI-PATTERN: Inline mock arrays\nconst mockTenants = [\n  { id: '1', name: 'Test Tenant' }\n]\n\nexport const Default: Story = {\n  args: { tenants: mockTenants }\n}\n```\n\n## Why It's Wrong\n\nInline mocks are invisible to backend teams, live only in story files, and inevitably drift from real API responses. API stores make the contract explicit and reusable.\n\n## Correct Approach\n\nSee: [master-story-protocol](../../patterns/react/master-story-protocol.md)",
-      "tags": ["storybook", "mock-data", "anti-pattern"],
-      "appliesTo": ["src/stories/**/*-prototype-master.stories.tsx"],
-      "context": "Related: master-story-protocol"
-    },
-    {
-      "id": "pattern-react-anteater-sie-loop",
-      "type": "playbook",
-      "domain": "react",
-      "title": "SIE Loop: Simulated Interactive Environment for Component Development",
-      "severity": "critical",
-      "description": "# SIE Loop: Simulated Interactive Environment for Component Development\n\n## Context\n\nWhen creating or validating components in an Anteater-generated project\n\n## Pattern\n\nThe SIE Loop is a 6-phase iterative process: 1) Init (load Anteater context), 2) Generate (create with semantic tokens), 3) Observe (WCAG, CVD, hookify, code quality), 4) Reward (composite scoring: Anteater 40% + Hookify 30% + Salvador 25% + Tooling 5%), 5) Improve (fix by priority), 6) Finalize (validated output). Blocking hookify violations = instant fail (score 0).\n\n## Example\n\n```typescript\n# Priority order for improvements:\n1. hookify-blocks (fix blocking violations first)\n2. type-errors (then type safety)\n3. wcag-failures (then accessibility)\n4. token-violations (then token compliance)\n5. code-quality-issues (then clean code)\n6. story-gaps (then coverage)\n7. warnings (then warnings)\n```\n\n## Why\n\nThe SIE loop ensures components meet accessibility, token compliance, and code quality standards before being finalized. It provides measurable quality through composite scoring.",
-      "tags": ["anteater", "sie", "component", "validation", "workflow"],
-      "appliesTo": ["src/components/**/*.tsx", "src/stories/**/*.stories.tsx"]
-    }
-  ]
-}

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

@@ -1,34 +0,0 @@
-{
-  "domain": "security",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "pattern-security-manifest-validation-recovery",
-      "type": "pattern",
-      "domain": "security",
-      "title": "Validate manifest files and provide recovery suggestions",
-      "severity": "critical",
-      "description": "# Validate manifest files and provide recovery suggestions\n\n## Context\n\nAny script that depends on a manifest file should validate it and provide clear recovery steps\n\n## Pattern\n\nCheck for: file exists, file not empty, valid YAML/JSON, expected structure. For each failure mode, provide a specific recovery suggestion (e.g., 'Run npm run sync-hooks to regenerate').\n\n## Example\n\n```typescript\nif (!fs.existsSync(manifestFile)) {\n  return {\n    status: 'manifest_missing',\n    message: 'Manifest not found',\n    recovery: 'Run \"npm run sync-hooks\" to regenerate the manifest.'\n  };\n}\n```\n\n## Why\n\nManifest corruption is a single point of failure. Without recovery guidance, users are stuck with cryptic errors and no path forward.",
-      "tags": ["cli", "ux", "manifest", "recovery", "error-handling"],
-      "appliesTo": ["scripts/setup-project.js", "scripts/export-hooks.js"]
-    },
-    {
-      "id": "pattern-security-quick-ai-attribution-blocking-in-git-commits-via-hookify",
-      "type": "pattern",
-      "domain": "security",
-      "title": "AI attribution blocking in git commits via hookify rules",
-      "severity": "critical",
-      "description": "# AI attribution blocking in git commits via hookify rules\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe no-ai-attribution rule in chains/rules/enforcement.yaml blocks git commits containing AI attribution markers: the robot emoji, 'Generated with Claude', 'Co-Authored-By: Claude', 'noreply@anthropic.com', 'AI-generated', and similar strings. This is enforced as a blocking Bash event rule that fires on git commit commands. Conventional commit format (feat|fix|chore|refactor|docs: description) is the only accepted format.\n\n## Example\n\n```typescript\nBlocked: git commit -m 'feat: add button\\n\\nCo-Authored-By: Claude'. Allowed: git commit -m 'feat: add button component'.\n```\n\n## Why\n\nAI attribution in commits leaks tooling details and may conflict with organizational policies. Clean conventional commits preserve professional standards.",
-      "tags": ["git", "commits", "ai-attribution", "blocking", "conventional-commits"]
-    },
-    {
-      "id": "pattern-security-quick-protocol-enforcement-via-checkid-gates-on-critical",
-      "type": "pattern",
-      "domain": "security",
-      "title": "Protocol enforcement via checkId gates on critical MCP operations",
-      "severity": "critical",
-      "description": "# Protocol enforcement via checkId gates on critical MCP operations\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nCritical MCP tool calls return a _checkId that must be passed to dependent operations. search-components returns _checkId, architecture-patterns returns _checkId, component-workflow returns _checkId. create-component REQUIRES all three checkIds. This creates an unforgeable protocol chain: you cannot create a component without first searching for duplicates, checking architecture, and loading the workflow. The gate is enforced at the MCP server level, not just in YAML config.\n\n## Example\n\n```typescript\nsearch-components() → {_checkId: 'abc'}. create-component({checkIds: ['abc', 'def', 'ghi']}) → validates all 3 present.\n```\n\n## Why\n\nWithout checkId enforcement, agents could skip discovery and create duplicate or non-compliant components. Protocol gates make shortcuts impossible.",
-      "tags": ["checkId", "protocol-enforcement", "gates", "mcp", "unforgeable"]
-    }
-  ]
-}

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

@@ -1,33 +0,0 @@
-{
-  "domain": "testing",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "pattern-testing-quick-scenario-pipeline-test-architecture-for-end-to-end",
-      "type": "pattern",
-      "domain": "testing",
-      "title": "Scenario pipeline test architecture for end-to-end data pipeline verification",
-      "severity": "suggestion",
-      "description": "# Scenario pipeline test architecture for end-to-end data pipeline verification\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nCreated tests/scenarios/scenario-pipeline.test.js with 157 tests that verify the full Salvador data pipeline: user text → resolveRoute() → intent + mode + context → flow loading via loadFlow() → step graph via buildStepGraph(). Uses a runPipeline(text) helper that chains these functions. Tests cover all 9 intents/modes, morph auto-injection specification, context-aware routing, and flow structure validation. Key design decisions: (1) findFlowInChains() extracts flow IDs from chain arrays, (2) morph specs defined as constants (AUTO_MORPH_REVIEW_TARGETS, EXPLICIT_MORPH), (3) review flows excluded from auto-morph injection, (4) INTEGRATOR-flow gets special handling for buildStepGraph failures.\n\n## Example\n\n```typescript\nrunPipeline('Build a new feature') → { routing: { intent: 'CREATE', mode: 'BUILD-MODE' }, flowId: 'DEVELOPER-flow', flow: {...}, graph: {...} }\n```\n\n## Why\n\nProvides regression safety for the routing→flow→step pipeline that controls Claude's behavior. Catches keyword collisions, unreachable flows, and parser edge cases.",
-      "tags": ["testing", "pipeline", "scenario-tests", "end-to-end", "architecture"]
-    },
-    {
-      "id": "anti-pattern-testing-quick-integrator-flow-validationchecks-parsed-as-extra-s",
-      "type": "anti-pattern",
-      "domain": "testing",
-      "title": "INTEGRATOR-flow validationChecks parsed as extra steps by flow-parser",
-      "severity": "warning",
-      "description": "# INTEGRATOR-flow validationChecks parsed as extra steps by flow-parser\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Anti-Pattern\n\nThe flow-parser's extractSteps() function treats INTEGRATOR-flow's validationChecks entries (which use '- id:' format) as additional steps. This means INTEGRATOR-flow has 15 steps instead of the expected 8: 8 main steps + 7 validationCheck entries (pages-not-components, pages-render, api-data-flows, no-style-overrides, token-compliance, no-local-recreations, adapters-correct). Also, buildStepGraph() crashes on INTEGRATOR-flow because validationCheck entries have non-string chain values (objects), causing parseInlineValue() to fail with 'str.replace is not a function'.\n\n## Example (Bad)\n\n```typescript\nloadFlow('INTEGRATOR-flow').steps.length === 15; buildStepGraph(flow) throws TypeError\n```\n\n## Why It's Wrong\n\nTests expecting 8 steps will fail. buildStepGraph tests must handle the INTEGRATOR-flow exception separately.",
-      "tags": ["flow-parser", "integrator-flow", "validationChecks", "bug"]
-    },
-    {
-      "id": "anti-pattern-testing-quick-intent-keyword-substring-collisions-in-classifyint",
-      "type": "anti-pattern",
-      "domain": "testing",
-      "title": "Intent keyword substring collisions in classifyIntent",
-      "severity": "warning",
-      "description": "# Intent keyword substring collisions in classifyIntent\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Anti-Pattern\n\nclassifyIntent() matches keywords as substrings via regex. The word 'implementation' contains 'implement' which is a CREATE keyword, causing 'Review the Button component implementation' to route to CREATE instead of REVIEW. Similarly, 'Create storybook stories' routes to CREATE instead of TEST because CREATE's semantic pattern /(?:create|build|generate|scaffold|set\\s*up)\\s+/i matches with weight 0.85, overpowering TEST's keyword score. When writing scenario text for tests, avoid CREATE trigger words ('create', 'build', 'generate', 'implement') in non-CREATE scenarios.\n\n## Example (Bad)\n\n```typescript\n'Review the Button component implementation' → CREATE (not REVIEW). Fix: 'Review my Button component code'\n```\n\n## Why It's Wrong\n\nSubstring matching means any word containing a keyword triggers that intent. Scenario text must be carefully crafted to avoid unintended keyword matches.",
-      "tags": ["intent-classifier", "keyword-collision", "substring-matching", "testing"]
-    }
-  ]
-}

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

@@ -1,85 +0,0 @@
-{
-  "domain": "tooling",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "pattern-tooling-cli-dry-run-flag",
-      "type": "pattern",
-      "domain": "tooling",
-      "title": "Always provide --dry-run for destructive CLI operations",
-      "severity": "critical",
-      "description": "# Always provide --dry-run for destructive CLI operations\n\n## Context\n\nAny CLI script that creates, modifies, or deletes files should have a --dry-run flag\n\n## Pattern\n\nAdd --dry-run flag that shows exact files to be created/modified/deleted without making changes. Users can preview operations before committing, reducing fear and increasing confidence.\n\n## Example\n\n```typescript\nif (args.dryRun) {\n  console.log(`Would remove ${files.length} files:`);\n  for (const f of files) console.log(`  - DELETE ${f}`);\n  process.exit(0);\n}\n```\n\n## Why\n\nUsers hesitate to run commands when they don't know what will change. Dry-run eliminates this friction by providing a safe preview mode.",
-      "tags": ["cli", "ux", "safety", "preview", "zero-friction"],
-      "appliesTo": ["scripts/setup-project.js", "scripts/export-hooks.js"]
-    },
-    {
-      "id": "pattern-tooling-help-when-to-use",
-      "type": "pattern",
-      "domain": "tooling",
-      "title": "Include 'when to use' guidance in --help output",
-      "severity": "suggestion",
-      "description": "# Include 'when to use' guidance in --help output\n\n## Context\n\nCLI help text should explain not just WHAT flags do, but WHEN to use them\n\n## Pattern\n\nAdd a 'When to use' section after listing options that provides guidance on which flag to use in which scenario.\n\n## Example\n\n```typescript\nWhen to use each flag:\n  --dry-run      Use FIRST to see what will change\n  --interactive  Use for guided cleanup with prompts\n  --cleanup      Use in CI/automation for direct action\n```\n\n## Why\n\nUsers often don't know which flag combination they need. 'When to use' guidance reduces trial-and-error and gets them to the right command faster.",
-      "tags": ["cli", "ux", "documentation", "help"],
-      "appliesTo": ["scripts/setup-project.js", "scripts/export-hooks.js"]
-    },
-    {
-      "id": "pattern-tooling-intelligence-reload-after-vault-update",
-      "type": "pattern",
-      "domain": "tooling",
-      "title": "Reload Intelligence After Vault Updates",
-      "severity": "warning",
-      "description": "# Reload Intelligence After Vault Updates\n\n## Context\n\nAfter modifying intelligence JSON files in the vault\n\n## Pattern\n\nThe MCP server caches intelligence at startup. After updating vault data files, call salvador_reload_intelligence() to refresh the cache without restarting the server.\n\n## Example\n\n```typescript\n// After editing workflow-patterns.json in vault:\nsalvador_reload_intelligence()\n// Returns: { success: true, reloadTime: '9ms', ... }\n```\n\n## Why\n\nThe singleton pattern caches intelligence for performance. Without reload, changes to vault files won't be visible until server restart.",
-      "tags": ["salvador", "mcp", "cache", "reload"],
-      "appliesTo": ["intelligence/data/*.json"]
-    },
-    {
-      "id": "pattern-tooling-readme-defers-to-help",
-      "type": "pattern",
-      "domain": "tooling",
-      "title": "README should defer to --help for CLI documentation",
-      "severity": "suggestion",
-      "description": "# README should defer to --help for CLI documentation\n\n## Context\n\nCLI tool documentation in README.md should be minimal and point to --help\n\n## Pattern\n\nInstead of duplicating all flags in README, show 1-2 common examples and add 'Run --help for complete documentation'. This prevents drift between README and actual CLI behavior.\n\n## Example\n\n```typescript\n```bash\n# Preview what will be exported\nnpm run export-hooks /path --dry-run\n\n# See all options\nnpm run export-hooks -- --help\n```\n\n> Note: Run --help for complete, up-to-date documentation.\n```\n\n## Why\n\nDocumentation in multiple places (README, --help, CLAUDE.md) inevitably drifts. Single source of truth in --help ensures accuracy.",
-      "tags": ["documentation", "cli", "single-source-of-truth"],
-      "appliesTo": ["README.md"]
-    },
-    {
-      "id": "pattern-tooling-unknown-flag-warning",
-      "type": "pattern",
-      "domain": "tooling",
-      "title": "Warn about unknown flags instead of failing silently",
-      "severity": "warning",
-      "description": "# Warn about unknown flags instead of failing silently\n\n## Context\n\nCLI argument parsing should detect and warn about unrecognized flags\n\n## Pattern\n\nTrack unknown flags during parsing and display a warning with the list of valid flags. Continue execution rather than exiting, so automation isn't broken.\n\n## Example\n\n```typescript\nconst VALID_FLAGS = new Set(['--help', '--json', '--dry-run']);\nif (arg.startsWith('--') && !VALID_FLAGS.has(arg)) {\n  args.unknownFlags.push(arg);\n}\n// Later:\nconsole.log(`⚠ Unknown: ${unknownFlags.join(', ')}`);\nconsole.log(`  Valid: ${[...VALID_FLAGS].join(', ')}`);\n```\n\n## Why\n\nUsers often typo flags (--with-herald-company vs --herald-company). Silent ignore means they think a feature is enabled when it's not. Immediate warning prevents confusion.",
-      "tags": ["cli", "ux", "error-handling", "feedback"],
-      "appliesTo": ["scripts/setup-project.js", "scripts/export-hooks.js"]
-    },
-    {
-      "id": "anti-pattern-tooling-silent-flag-ignore",
-      "type": "anti-pattern",
-      "domain": "tooling",
-      "title": "Silently ignoring unknown CLI flags",
-      "severity": "warning",
-      "description": "# Silently ignoring unknown CLI flags\n\n## Context\n\nCLI scripts that store unknown flags but never warn about them\n\n## Anti-Pattern\n\nTracking unknown flags in an array but never displaying a warning means users think features are enabled when they're not.\n\n## Example (Bad)\n\n```typescript\n// BAD:\nelse if (arg.startsWith('--')) {\n  args.unknownFlags.push(arg); // Stored but never warned\n}\n```\n\n## Why It's Wrong\n\nUser types --with-herald-company (wrong), script stores it but continues silently. User thinks Herald is configured with custom company when it's using default.\n\n## Correct Approach\n\nSee: [unknown-flag-warning](../../patterns/other/unknown-flag-warning.md)",
-      "tags": ["cli", "ux", "anti-pattern"],
-      "appliesTo": ["scripts/export-hooks.js"],
-      "context": "Related: unknown-flag-warning"
-    },
-    {
-      "id": "pattern-tooling-anteater-outputs",
-      "type": "pattern",
-      "domain": "tooling",
-      "title": "Anteater Generation Outputs",
-      "severity": "warning",
-      "description": "# Anteater Generation Outputs\n\n## Context\n\nWhen explaining what Anteater generates or checking if a project is Anteater-generated\n\n## Pattern\n\nAnteater generates: .anteater.json (project config), tailwind-preset.js (OKLCH tokens 50-900), .claude/ directory (49 skills, 40+ hookify rules, agent-context.json), .mcp.json (points to salvador-mcp), src/components/ui/ (empty, add via 'anteater add'), tokens.css and base.css (CSS custom properties).\n\n## Example\n\n```typescript\n# Check if Anteater project\nif [ -f \".anteater.json\" ] && [ -f \".claude/agent-context.json\" ]; then\n  echo \"This is an Anteater project\"\nfi\n```\n\n## Why\n\nUnderstanding Anteater's output structure helps Salvador validate projects and guide users to the correct files for customization.",
-      "tags": ["anteater", "generation", "outputs", "structure"]
-    },
-    {
-      "id": "principle-tooling-capture-soleri-development-principle-salvador-is-the-refer",
-      "type": "rule",
-      "domain": "tooling",
-      "title": "Soleri Development Principle: Salvador is the Reference Implementation",
-      "severity": "critical",
-      "description": "# Soleri Development Principle: Salvador is the Reference Implementation\n\n## Context\n\nEstablished during Cognee integration work when feature audit revealed massive gap between generated agents and Salvador capabilities.\n\n## Principle\n\nEvery engine-level feature in Salvador MCP should exist in every Soleri-generated agent. Salvador's code is the blueprint — port features from Salvador into @soleri/core and @soleri/forge, don't reinvent. Generated agents must be Salvador-grade (minus domain-specific design system intelligence). Curator, brain intelligence pipeline, loops, orchestration, identity, governance — all engine features. Currently generated agents have ~36 ops across 2 facades; Salvador has 181+ ops across 14 facades. See GitHub milestones v5.1–v7.0.\n\n## Example\n\nN/A\n\n## Why\n\nWithout this principle, Soleri agents ship as toy demos instead of production-grade knowledge management platforms. Salvador has battle-tested every feature; porting is faster and more reliable than reimplementing.",
-      "tags": ["soleri", "architecture", "salvador-reference", "feature-parity"]
-    }
-  ]
-}

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

@@ -1,34 +0,0 @@
-{
-  "domain": "typescript",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "pattern-typescript-quick-no-any-types-enforcement-unknown-over-any-for-type",
-      "type": "pattern",
-      "domain": "typescript",
-      "title": "No-any-types enforcement: unknown over any for type safety",
-      "severity": "critical",
-      "description": "# No-any-types enforcement: unknown over any for type safety\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe no-any-types hookify rule blocks all forms of TypeScript 'any' usage: ': any' type annotations, 'as any' type assertions, and 'Record<string, any>' generic parameters. Use 'unknown' for truly unknown types and narrow with type guards. Use specific types or union types for known shapes. This rule fires as a blocking action on .ts and .tsx files, preventing commits until fixed.\n\n## Example\n\n```typescript\nBlocked: function parse(data: any). Fix: function parse(data: unknown) { if (isConfig(data)) { ... } }\n```\n\n## Why\n\n'any' silently disables TypeScript's type system. 'unknown' preserves type checking while acknowledging the type is not yet known.",
-      "tags": ["type-safety", "any", "unknown", "enforcement", "hookify"]
-    },
-    {
-      "id": "pattern-typescript-quick-type-safe-tool-registry-with-pre-defined-output-sh",
-      "type": "pattern",
-      "domain": "typescript",
-      "title": "Type-safe tool registry with pre-defined output shapes in YAML",
-      "severity": "warning",
-      "description": "# Type-safe tool registry with pre-defined output shapes in YAML\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nEach atomic chain in chains/atomic.yaml declares its output type as a string template: '{found, id?, similarity?}' for search-components, '{pass, ratio, level}' for contrast checks, '{violations[], score}' for code validation. These output shapes serve as informal type contracts — consumers of chain results know exactly what fields to expect. Related chains and tags enable discovery and composition.\n\n## Example\n\n```typescript\natomic.yaml: search-components: { tool: salvador_search_components, output: '{found, id?, similarity?}', tags: [search] }\n```\n\n## Why\n\nPre-declared output shapes prevent runtime surprises when chaining tools. The YAML acts as a lightweight type system for the data pipeline.",
-      "tags": ["type-safety", "output-shapes", "contracts", "atomic-chains", "yaml"]
-    },
-    {
-      "id": "pattern-typescript-vault-mcp-separation",
-      "type": "pattern",
-      "domain": "typescript",
-      "title": "Vault vs MCP Server Separation",
-      "severity": "warning",
-      "description": "# Vault vs MCP Server Separation\n\n## Context\n\nWhen adding new intelligence data to Salvador ecosystem\n\n## Pattern\n\nSalvador has clear separation: the VAULT (salvador) contains intelligence data (JSON, YAML), while the MCP SERVER (salvador-mcp) provides the API. Updates require changes to both.\n\n## Example\n\n```typescript\n// Step 1: Add data to vault\n// /salvador/intelligence/data/workflow-patterns.json\n{\n  \"masterStoryProtocol\": { ... }\n}\n\n// Step 2: Update MCP tool to expose it\n// /salvador-mcp/src/tools/get-storybook-patterns.ts\npattern: z.enum([..., 'masterStoryProtocol', 'all'])\n\n// Step 3: Rebuild MCP & reload intelligence\nnpm run build\nsalvador_reload_intelligence()\n```\n\n## Why\n\nVault is the source of truth for design system knowledge. MCP is the access layer. This separation allows updating intelligence without changing server code, and vice versa.",
-      "tags": ["salvador", "mcp", "vault", "architecture"],
-      "appliesTo": ["intelligence/data/*.json", "src/tools/*.ts"]
-    }
-  ]
-}

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

@@ -1,46 +0,0 @@
-{
-  "domain": "workflow",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "anti-pattern-workflow-custom-loop-cancelled-after-1-iteration-",
-      "type": "pattern",
-      "domain": "workflow",
-      "title": "custom loop cancelled after 1 iteration(s)",
-      "severity": "suggestion",
-      "description": "# custom loop cancelled after 1 iteration(s)\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 127 sessions.\nFlow: loop-custom\n## Anti-Pattern\n\nSession 2026-03-02-fdbe61c9 was cancelled during custom validation after 1 iteration(s). Frequent cancellations in this mode may indicate unclear requirements or overly ambitious targets.\n\n## Evidence\n\n- Observed in 127 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `loop-abandoned`",
-      "tags": ["loop", "abandoned", "cancelled", "custom", "loop-custom"],
-      "appliesTo": ["loop-custom"]
-    },
-    {
-      "id": "anti-pattern-workflow-custom-loop-hit-max-iterations-failed-to",
-      "type": "pattern",
-      "domain": "workflow",
-      "title": "custom loop hit max iterations — failed to converge",
-      "severity": "warning",
-      "description": "# custom loop hit max iterations — failed to converge\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 19 sessions.\nFlow: loop-custom\n## Anti-Pattern\n\nSession 2026-03-02-f418fb8c exhausted all 2 iterations without reaching the validation target. The custom approach may need a different strategy or lower target threshold.\n\n## Evidence\n\n- Observed in 19 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `loop-failed-to-converge`",
-      "tags": ["loop", "convergence-failure", "max-iterations", "custom", "loop-custom"],
-      "appliesTo": ["loop-custom"]
-    },
-    {
-      "id": "anti-pattern-workflow-score-variance-in-loop-custom-build",
-      "type": "pattern",
-      "domain": "workflow",
-      "title": "Score variance in loop-custom-BUILD",
-      "severity": "suggestion",
-      "description": "# Score variance in loop-custom-BUILD\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 7 sessions.\nFlow: loop-custom-BUILD\n## Anti-Pattern\n\nWide score variance: weakest step \"loop-validation\" (30) vs strongest \"loop-setup\" (85). Focus improvement on the weak step.\n\n## Evidence\n\n- Observed in 7 sessions across flow `loop-custom-BUILD`\n- Promoted: 2026-03-02\n- Source rule: `step-score-variance`",
-      "tags": ["variance", "improvement", "loop-custom-BUILD"],
-      "appliesTo": ["loop-custom-BUILD"]
-    },
-    {
-      "id": "anti-pattern-workflow-score-variance-in-loop-custom",
-      "type": "pattern",
-      "domain": "workflow",
-      "title": "Score variance in loop-custom",
-      "severity": "suggestion",
-      "description": "# Score variance in loop-custom\n\n## Context\n\nAutomatically promoted from proposed knowledge after being observed in 10 sessions.\nFlow: loop-custom\n## Anti-Pattern\n\nWide score variance: weakest step \"loop-validation\" (30) vs strongest \"loop-setup\" (85). Focus improvement on the weak step.\n\n## Evidence\n\n- Observed in 10 sessions across flow `loop-custom`\n- Promoted: 2026-03-02\n- Source rule: `step-score-variance`",
-      "tags": ["variance", "improvement", "loop-custom"],
-      "appliesTo": ["loop-custom"]
-    }
-  ]
-}

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

@@ -1,10 +0,0 @@
-{
-  "id": "salvador-uipro",
-  "name": "Salvador UI Pro — Design Reference Library",
-  "version": "1.0.0",
-  "description": "96 color palettes, 67 UI styles, 13 tech stacks, font pairings, chart recommendations, UX patterns, and landing page patterns. A comprehensive design reference library.",
-  "domains": ["ui-design"],
-  "vault": {
-    "dir": "vault"
-  }
-}