@soleri/core 9.14.0 → 9.15.0

package/src/vault/default-canonical-tags.ts

@@ -0,0 +1,64 @@
+/**
+ * Default canonical tag taxonomy for Soleri agents.
+ *
+ * These tags represent the most common knowledge domains. When a vault is
+ * configured with tagConstraintMode 'suggest' or 'enforce', incoming tags
+ * are mapped to the nearest entry in this list via edit-distance matching.
+ *
+ * To use these defaults in your agent runtime config:
+ *   import { DEFAULT_CANONICAL_TAGS } from '@soleri/core';
+ *   // ...
+ *   canonicalTags: DEFAULT_CANONICAL_TAGS,
+ *   tagConstraintMode: 'suggest',
+ */
+export const DEFAULT_CANONICAL_TAGS: string[] = [
+  'architecture',
+  'typescript',
+  'react',
+  'testing',
+  'workflow',
+  'design-tokens',
+  'accessibility',
+  'performance',
+  'security',
+  'planning',
+  'soleri',
+  'vault',
+  'mcp',
+  'claude-code',
+  'ai',
+  'learning',
+  'gamification',
+  'education',
+  'adhd',
+  'routing',
+  'orchestration',
+  'skills',
+  'automation',
+  'git',
+  'database',
+  'api',
+  'authentication',
+  'subagent',
+  'design-system',
+  'component',
+  'frontend',
+  'backend',
+  'tooling',
+  'monorepo',
+  'refactoring',
+  'debugging',
+  'deployment',
+  'configuration',
+  'documentation',
+  'pattern',
+  'anti-pattern',
+  'principle',
+  'decision',
+  'migration',
+  'plugin',
+  'hook',
+  'schema',
+  'pipeline',
+  'ingestion',
+];

package/src/vault/tag-normalizer.test.ts

@@ -0,0 +1,214 @@
+import { describe, it, expect } from 'vitest';
+import {
+  computeEditDistance,
+  normalizeTag,
+  normalizeTags,
+  isMetadataTag,
+} from './tag-normalizer.js';
+
+// ─── computeEditDistance ────────────────────────────────────────────────────
+
+describe('computeEditDistance', () => {
+  it('returns 0 for identical strings', () => {
+    expect(computeEditDistance('workflow', 'workflow')).toBe(0);
+  });
+
+  it('returns length of b for empty a', () => {
+    expect(computeEditDistance('', 'abc')).toBe(3);
+  });
+
+  it('returns length of a for empty b', () => {
+    expect(computeEditDistance('abc', '')).toBe(3);
+  });
+
+  it('single insertion: workflow → workflows', () => {
+    expect(computeEditDistance('workflow', 'workflows')).toBe(1);
+  });
+
+  it('single deletion: testing → testin', () => {
+    expect(computeEditDistance('testing', 'testin')).toBe(1);
+  });
+
+  it('single substitution: arch → arcs', () => {
+    expect(computeEditDistance('arch', 'arcs')).toBe(1);
+  });
+
+  it("distance 1: architcture → architecture (single insertion - missing 'e')", () => {
+    expect(computeEditDistance('architcture', 'architecture')).toBe(1);
+  });
+
+  it('distance 2: archtecrure → architecture (two edits)', () => {
+    expect(computeEditDistance('archtecrure', 'architecture')).toBe(2);
+  });
+
+  it('large distance: typescript → javascript', () => {
+    expect(computeEditDistance('typescript', 'javascript')).toBeGreaterThan(3);
+  });
+
+  it('is symmetric', () => {
+    expect(computeEditDistance('foo', 'bar')).toBe(computeEditDistance('bar', 'foo'));
+  });
+});
+
+// ─── isMetadataTag ──────────────────────────────────────────────────────────
+
+describe('isMetadataTag', () => {
+  it('returns true when tag matches a prefix', () => {
+    expect(isMetadataTag('source:article', ['source:'])).toBe(true);
+  });
+
+  it('returns true for exact prefix match', () => {
+    expect(isMetadataTag('source:ingested', ['source:'])).toBe(true);
+  });
+
+  it('returns false when no prefix matches', () => {
+    expect(isMetadataTag('typescript', ['source:'])).toBe(false);
+  });
+
+  it('returns false with empty prefix list', () => {
+    expect(isMetadataTag('source:article', [])).toBe(false);
+  });
+
+  it('supports multiple prefixes', () => {
+    expect(isMetadataTag('meta:foo', ['source:', 'meta:'])).toBe(true);
+  });
+});
+
+// ─── normalizeTag ───────────────────────────────────────────────────────────
+
+const CANONICAL = ['architecture', 'typescript', 'workflow', 'testing', 'performance'];
+
+describe('normalizeTag — mode: off', () => {
+  it('returns tag as-is regardless of canonical list', () => {
+    expect(normalizeTag('workflows', CANONICAL, 'off')).toBe('workflows');
+  });
+
+  it('passes through noise words in off mode', () => {
+    expect(normalizeTag('new', CANONICAL, 'off')).toBe('new');
+  });
+});
+
+describe('normalizeTag — noise stripping', () => {
+  it('drops version strings (v1.2)', () => {
+    expect(normalizeTag('v1.2', CANONICAL, 'suggest')).toBeNull();
+  });
+
+  it('drops version strings (v10)', () => {
+    expect(normalizeTag('v10', CANONICAL, 'suggest')).toBeNull();
+  });
+
+  it('drops generic noise word: new', () => {
+    expect(normalizeTag('new', CANONICAL, 'suggest')).toBeNull();
+  });
+
+  it('drops generic noise word: via', () => {
+    expect(normalizeTag('via', CANONICAL, 'suggest')).toBeNull();
+  });
+
+  it('drops generic noise word: raw', () => {
+    expect(normalizeTag('raw', CANONICAL, 'enforce')).toBeNull();
+  });
+});
+
+describe('normalizeTag — mode: suggest', () => {
+  it('returns canonical for exact match', () => {
+    expect(normalizeTag('typescript', CANONICAL, 'suggest')).toBe('typescript');
+  });
+
+  it('maps within edit-distance 2 to canonical', () => {
+    // 'workflows' is distance 1 from 'workflow'
+    expect(normalizeTag('workflows', CANONICAL, 'suggest')).toBe('workflow');
+  });
+
+  it('lowercases tag before matching', () => {
+    expect(normalizeTag('TypeScript', CANONICAL, 'suggest')).toBe('typescript');
+  });
+
+  it('passes through unknown tag with no close canonical (suggest passthrough)', () => {
+    const result = normalizeTag('gamification', CANONICAL, 'suggest');
+    // No match within distance 2 — passthrough
+    expect(result).toBe('gamification');
+  });
+
+  it('returns null for noise even in suggest mode', () => {
+    expect(normalizeTag('one', CANONICAL, 'suggest')).toBeNull();
+  });
+});
+
+describe('normalizeTag — mode: enforce', () => {
+  it('returns canonical for exact match', () => {
+    expect(normalizeTag('testing', CANONICAL, 'enforce')).toBe('testing');
+  });
+
+  it('maps within edit-distance 3 to canonical', () => {
+    // 'archtecrure' is 2 away from 'architecture'
+    expect(normalizeTag('archtecrure', CANONICAL, 'enforce')).toBe('architecture');
+  });
+
+  it('returns null for tag with no match within distance 3', () => {
+    // 'gamification' is far from all CANONICAL entries
+    expect(normalizeTag('gamification', CANONICAL, 'enforce')).toBeNull();
+  });
+
+  it('returns null for noise words', () => {
+    expect(normalizeTag('full', CANONICAL, 'enforce')).toBeNull();
+  });
+});
+
+describe('normalizeTag — empty canonical list', () => {
+  it('suggest mode: passes through non-noise tags', () => {
+    expect(normalizeTag('react', [], 'suggest')).toBe('react');
+  });
+
+  it('enforce mode: drops all tags (no canonical to match)', () => {
+    expect(normalizeTag('react', [], 'enforce')).toBeNull();
+  });
+});
+
+// ─── normalizeTags ──────────────────────────────────────────────────────────
+
+describe('normalizeTags', () => {
+  it('deduplicates tags that map to the same canonical', () => {
+    // Both 'workflows' and 'workflow' normalize to 'workflow'
+    const result = normalizeTags(['workflows', 'workflow'], CANONICAL, 'suggest');
+    expect(result).toEqual(['workflow']);
+  });
+
+  it('preserves metadata tags unchanged', () => {
+    const result = normalizeTags(['source:article', 'typescript'], CANONICAL, 'enforce', [
+      'source:',
+    ]);
+    expect(result).toContain('source:article');
+    expect(result).toContain('typescript');
+  });
+
+  it('metadata tags bypass canonical normalization in enforce mode', () => {
+    // 'source:mytype' does not match any canonical — but it should be kept
+    const result = normalizeTags(['source:mytype'], CANONICAL, 'enforce', ['source:']);
+    expect(result).toEqual(['source:mytype']);
+  });
+
+  it('returns empty array when all tags are noise', () => {
+    const result = normalizeTags(['new', 'via', 'raw', 'v1.2'], CANONICAL, 'suggest');
+    expect(result).toEqual([]);
+  });
+
+  it('in off mode, returns tags unchanged', () => {
+    const input = ['new', 'workflows', 'v1.2'];
+    const result = normalizeTags(input, CANONICAL, 'off');
+    expect(result).toEqual(input);
+  });
+
+  it('batch normalizes a mixed tag list', () => {
+    const result = normalizeTags(
+      ['TypeScript', 'workflows', 'new', 'source:article'],
+      CANONICAL,
+      'suggest',
+      ['source:'],
+    );
+    expect(result).toContain('typescript');
+    expect(result).toContain('workflow');
+    expect(result).toContain('source:article');
+    expect(result).not.toContain('new');
+  });
+});

package/src/vault/tag-normalizer.ts

@@ -0,0 +1,188 @@
+/**
+ * Tag Normalizer — canonical tag taxonomy enforcement.
+ *
+ * Maps raw tags to nearest canonical via Levenshtein edit-distance.
+ * Strips noise words (version strings, single generic words).
+ * Respects metadata tag prefixes (e.g. 'source:').
+ *
+ * Three modes:
+ *   - 'enforce': must match within edit-distance 3, else drop (return null)
+ *   - 'suggest': map to nearest canonical within edit-distance 2 (passthrough if no match)
+ *   - 'off':     no normalization — return tag as-is
+ */
+
+// ─── Noise filter ────────────────────────────────────────────────────────────
+
+/**
+ * Version-string pattern: v1.2, v10, v1.2.3, etc.
+ */
+const VERSION_PATTERN = /^v\d+(\.\d+)*/i;
+
+/**
+ * Generic single words that add no signal.
+ */
+const NOISE_WORDS = new Set([
+  'one',
+  'via',
+  'new',
+  'full',
+  'actual',
+  'raw',
+  'the',
+  'and',
+  'for',
+  'with',
+  'this',
+  'that',
+  'from',
+  'into',
+]);
+
+function isNoisy(tag: string): boolean {
+  if (VERSION_PATTERN.test(tag)) return true;
+  if (NOISE_WORDS.has(tag.toLowerCase())) return true;
+  return false;
+}
+
+// ─── Levenshtein edit distance ───────────────────────────────────────────────
+
+/**
+ * Compute Levenshtein edit distance between two strings.
+ * O(m*n) time, O(n) space using two-row DP.
+ */
+export function computeEditDistance(a: string, b: string): number {
+  if (a === b) return 0;
+  if (a.length === 0) return b.length;
+  if (b.length === 0) return a.length;
+
+  let prev = Array.from({ length: b.length + 1 }, (_, i) => i);
+  let curr = Array.from<number>({ length: b.length + 1 });
+
+  for (let i = 1; i <= a.length; i++) {
+    curr[0] = i;
+    for (let j = 1; j <= b.length; j++) {
+      const cost = a[i - 1] === b[j - 1] ? 0 : 1;
+      curr[j] = Math.min(
+        curr[j - 1] + 1, // insertion
+        prev[j] + 1, // deletion
+        prev[j - 1] + cost, // substitution
+      );
+    }
+    [prev, curr] = [curr, prev];
+  }
+
+  return prev[b.length];
+}
+
+// ─── Metadata tag check ──────────────────────────────────────────────────────
+
+/**
+ * Returns true if the tag starts with any of the given prefixes.
+ * Metadata tags (e.g. 'source:article') are exempt from canonical normalization.
+ */
+export function isMetadataTag(tag: string, prefixes: string[]): boolean {
+  return prefixes.some((prefix) => tag.startsWith(prefix));
+}
+
+// ─── Single tag normalization ────────────────────────────────────────────────
+
+/**
+ * Normalize a single tag against a canonical list.
+ *
+ * @param tag       - Raw tag to normalize
+ * @param canonical - Canonical tag list to map against
+ * @param mode      - Constraint mode: 'enforce' | 'suggest' | 'off'
+ * @returns Normalized tag string, or null if the tag should be dropped.
+ */
+export function normalizeTag(
+  tag: string,
+  canonical: string[],
+  mode: 'enforce' | 'suggest' | 'off',
+): string | null {
+  if (mode === 'off') return tag;
+
+  const lower = tag.toLowerCase().trim();
+
+  // Always drop noise words
+  if (isNoisy(lower)) return null;
+
+  // Derive lowercase canonical for matching; preserve original casing for return
+  const canonicalLower = canonical.map((x) => x.toLowerCase());
+
+  // Exact match in canonical list — return canonical form (original casing)
+  const exactIdx = canonicalLower.indexOf(lower);
+  if (exactIdx !== -1) return canonical[exactIdx];
+
+  if (canonical.length === 0) {
+    // No canonical list configured — pass through in suggest, drop in enforce
+    return mode === 'enforce' ? null : lower;
+  }
+
+  // Find nearest canonical by edit distance
+  let bestMatch: string | null = null;
+  let bestDist = Infinity;
+
+  for (let i = 0; i < canonicalLower.length; i++) {
+    const dist = computeEditDistance(lower, canonicalLower[i]);
+    if (dist < bestDist) {
+      bestDist = dist;
+      bestMatch = canonical[i];
+    }
+  }
+
+  const threshold = mode === 'enforce' ? 3 : 2;
+
+  if (bestDist <= threshold && bestMatch !== null) {
+    return bestMatch;
+  }
+
+  // No close match found
+  if (mode === 'enforce') {
+    return null; // drop the tag
+  }
+
+  // 'suggest' mode — keep original tag unchanged (passthrough)
+  return lower;
+}
+
+// ─── Batch tag normalization ─────────────────────────────────────────────────
+
+/**
+ * Normalize a batch of tags against a canonical list.
+ * Filters out nulls (dropped tags). Deduplicates the result.
+ *
+ * @param tags              - Raw tags
+ * @param canonical         - Canonical tag list
+ * @param mode              - Constraint mode
+ * @param metadataPrefixes  - Tags with these prefixes bypass normalization
+ */
+export function normalizeTags(
+  tags: string[],
+  canonical: string[],
+  mode: 'enforce' | 'suggest' | 'off',
+  metadataPrefixes: string[] = ['source:'],
+): string[] {
+  if (mode === 'off') return tags;
+
+  const seen = new Set<string>();
+  const result: string[] = [];
+
+  for (const tag of tags) {
+    // Metadata tags bypass canonical normalization but are still kept
+    if (isMetadataTag(tag, metadataPrefixes)) {
+      if (!seen.has(tag)) {
+        seen.add(tag);
+        result.push(tag);
+      }
+      continue;
+    }
+
+    const normalized = normalizeTag(tag, canonical, mode);
+    if (normalized !== null && !seen.has(normalized)) {
+      seen.add(normalized);
+      result.push(normalized);
+    }
+  }
+
+  return result;
+}

package/dist/embeddings/index.d.ts

@@ -1,5 +0,0 @@
-export type { EmbeddingProvider, EmbeddingResult, EmbeddingConfig, StoredVector, EmbeddingStats, } from './types.js';
-export { OpenAIEmbeddingProvider } from './openai-provider.js';
-export { EmbeddingPipeline } from './pipeline.js';
-export type { BatchEmbedOptions, BatchEmbedResult } from './pipeline.js';
-//# sourceMappingURL=index.d.ts.map

package/dist/embeddings/index.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/embeddings/index.ts"],"names":[],"mappings":"AAAA,YAAY,EACV,iBAAiB,EACjB,eAAe,EACf,eAAe,EACf,YAAY,EACZ,cAAc,GACf,MAAM,YAAY,CAAC;AAEpB,OAAO,EAAE,uBAAuB,EAAE,MAAM,sBAAsB,CAAC;AAC/D,OAAO,EAAE,iBAAiB,EAAE,MAAM,eAAe,CAAC;AAClD,YAAY,EAAE,iBAAiB,EAAE,gBAAgB,EAAE,MAAM,eAAe,CAAC"}

package/dist/embeddings/index.js

@@ -1,3 +0,0 @@
-export { OpenAIEmbeddingProvider } from './openai-provider.js';
-export { EmbeddingPipeline } from './pipeline.js';
-//# sourceMappingURL=index.js.map

package/dist/embeddings/index.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/embeddings/index.ts"],"names":[],"mappings":"AAQA,OAAO,EAAE,uBAAuB,EAAE,MAAM,sBAAsB,CAAC;AAC/D,OAAO,EAAE,iBAAiB,EAAE,MAAM,eAAe,CAAC"}

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

@@ -1,10 +0,0 @@
-{
-  "id": "salvador-craft",
-  "name": "Salvador Craft — Design & Accessibility",
-  "version": "1.0.0",
-  "description": "Design system intelligence, token priority, accessibility rules, UX patterns, component patterns, and styling enforcement. Extracted from Salvador's production vault.",
-  "domains": ["design", "accessibility", "ux"],
-  "vault": {
-    "dir": "vault"
-  }
-}

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

@@ -1,53 +0,0 @@
-{
-  "domain": "accessibility",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "canonical-a11y-contrast-requirements",
-      "type": "pattern",
-      "domain": "accessibility",
-      "title": "Contrast Requirements",
-      "severity": "critical",
-      "description": "## Rule\n\nAll text and meaningful UI elements MUST meet WCAG 2.1 Level AA contrast ratio requirements:\n\n| Element Type | Minimum Contrast Ratio |\n|---|---|\n| Normal text (below 18px, or below 14px bold) | **4.5:1** |\n| Large text (18px+ regular, or 14px+ bold) | **3:1** |\n| UI components and graphical objects (icons, borders, focus indicators) | **3:1** |\n\n### Specifics\n\n- **Normal text**: Any text rendered below 18px (24 CSS px at default zoom) at regular weight, or below 14px (18.66 CSS px) at bold weight, requires a **4.5:1** contrast ratio against its background.\n- **Large text**: Text at 18px+ regular weight or 14px+ bold weight requires a **3:1** contrast ratio against its background.\n- **Non-text elements**: Interactive component boundaries (input borders, button outlines), focus indicators, and informational icons require a **3:1** contrast ratio against adjacent colors.\n- **Disabled elements**: Disabled controls are exempt from contrast requirements per WCAG, but should still be perceptibly different from their enabled state.\n- **Placeholder text**: Input placeholder text must meet **4.5:1** if it conveys essential information; otherwise treat as supplementary.\n\nReference: [WCAG 2.1 Success Criterion 1.4.3 (Contrast Minimum)](https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html) and [SC 1.4.11 (Non-text Contrast)](https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html).\n\n## Why\n\n1. **Inclusivity** -- Approximately 1 in 12 men and 1 in 200 women have some form of color vision deficiency. Low contrast excludes these users.\n2. **Environmental factors** -- Users view interfaces on screens with varying brightness, in direct sunlight, and on aging displays. Adequate contrast ensures readability in all conditions.\n3. **Legal compliance** -- WCAG 2.1 AA is the accepted legal standard in many jurisdictions (ADA, EN 301 549, Section 508).\n4. **Cognitive load** -- High-contrast text is faster to read for all users, reducing fatigue and errors.\n\n## Assertions\n\n- Every foreground/background color pair used for text must produce a contrast ratio >= 4.5:1 (normal text) or >= 3.0:1 (large text).\n- Every interactive component border color must produce a contrast ratio >= 3.0:1 against adjacent non-interactive surfaces.\n- Focus indicator colors must produce a contrast ratio >= 3.0:1 against the element's unfocused state.\n- No color pair used for informational icons may have a contrast ratio below 3.0:1 against its background.\n- Automated checks must flag any computed contrast ratio below the applicable threshold.",
-      "tags": ["accessibility", "contrast", "wcag", "a11y", "color"],
-      "tier": "agent"
-    },
-    {
-      "id": "canonical-a11y-touch-targets",
-      "type": "pattern",
-      "domain": "accessibility",
-      "title": "Touch Target Sizes",
-      "severity": "critical",
-      "description": "## Rule\n\nAll interactive elements MUST meet minimum touch target sizes:\n\n| Platform | Minimum Target Size | Reference |\n|---|---|---|\n| iOS (Apple HIG) | **44 x 44 pt** | Apple Human Interface Guidelines |\n| Android / Material Design | **48 x 48 dp** | Material Design Guidelines |\n| Web (WCAG 2.5.8, AAA) | **44 x 44 CSS px** | WCAG 2.2 SC 2.5.8 Target Size (Minimum) |\n| Web (WCAG 2.5.5, AA) | **24 x 24 CSS px** minimum, 44 x 44 CSS px recommended | WCAG 2.2 SC 2.5.5 |\n\n### Spacing Between Targets\n\n- Adjacent interactive targets MUST have at least **8px** of non-interactive space between their hit areas.\n- If two targets are closer than 8px, their combined hit areas must not overlap.\n- Inline text links in body copy are exempt from size requirements but should have sufficient line height (>= 1.5) to allow accurate tapping.\n\n### Implementation Details\n\n- The touch target includes padding and any transparent hit-area extensions, not just the visible element.\n- Use CSS `min-height` and `min-width` (not just `padding`) to guarantee the minimum dimensions.\n- Icon-only buttons that render a 16px or 24px icon MUST extend their tappable area to the full minimum size via padding or an invisible hit region.\n- Dropdown menu items, list rows, and navigation links must each meet the minimum height independently.\n\n## Why\n\n1. **Motor accessibility** -- Users with motor impairments, tremors, or limited dexterity need adequately sized targets to interact reliably.\n2. **Mobile usability** -- The average adult fingertip covers roughly 10mm (~40px at standard density). Targets smaller than this cause frequent mistaps.\n3. **Speed and confidence** -- Fitts's Law shows that larger targets reduce the time and error rate for pointing tasks. Meeting minimums improves task completion speed for all users.\n4. **Platform compliance** -- Both Apple and Google reject apps from their stores that fail basic usability checks, including undersized touch targets.\n\n## Assertions\n\n- No interactive element (button, link, checkbox, radio, toggle, select, slider thumb) may have a computed tappable area smaller than 44x44 CSS px on web or 44x44 pt on iOS or 48x48 dp on Android.\n- Adjacent interactive elements must have >= 8px non-interactive separation.\n- Icon-only interactive elements with a visible icon smaller than the minimum target size must have padding or hit-area expansion to meet the minimum.\n- Elements using `onClick` or equivalent touch/click handlers must meet target size requirements.",
-      "tags": ["accessibility", "touch", "mobile", "a11y", "interaction"],
-      "tier": "agent"
-    },
-    {
-      "id": "pattern-accessibility-quick-minimum-44x44px-touch-targets-enforced-via-quality",
-      "type": "pattern",
-      "domain": "accessibility",
-      "title": "Minimum 44x44px touch targets enforced via quality rules",
-      "severity": "warning",
-      "description": "# Minimum 44x44px touch targets enforced via quality rules\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe ux-touch-targets rule in chains/rules/quality.yaml enforces Fitts's Law: all interactive elements must have a minimum 44x44px touch target. This applies to buttons, links, checkboxes, and any clickable area. Smaller targets cause frustration on mobile and accessibility issues for motor-impaired users. The rule fires as a warning during component validation.\n\n## Example\n\n```typescript\nWarning: Button touch target is 32x32px, minimum required is 44x44px. Add p-2 or min-h-[44px] min-w-[44px].\n```\n\n## Why\n\nWCAG 2.5.8 (Target Size) requires 44x44px minimum. This is also a core UX law (Fitts's Law) that Salvador's UX-AUDITOR-flow evaluates.",
-      "tags": ["touch-targets", "fitts-law", "mobile", "motor-accessibility"]
-    },
-    {
-      "id": "pattern-accessibility-quick-tooltip-component-required-instead-of-native-title",
-      "type": "pattern",
-      "domain": "accessibility",
-      "title": "Tooltip component required instead of native title attribute",
-      "severity": "critical",
-      "description": "# Tooltip component required instead of native title attribute\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nThe no-native-title hookify rule blocks any use of title=\"...\" on HTML elements. Native title attributes have poor accessibility: not announced by all screen readers, invisible on touch devices, no styling control. Instead, use the Tooltip/TooltipTrigger/TooltipContent component pattern which provides keyboard support, screen reader announcements, and consistent styling.\n\n## Example\n\n```typescript\nBad: <button title=\"Delete item\">X</button>. Good: <Tooltip><TooltipTrigger><button>X</button></TooltipTrigger><TooltipContent>Delete item</TooltipContent></Tooltip>\n```\n\n## Why\n\nNative title is the most commonly misused accessibility pattern. Blocking it forces the accessible alternative.",
-      "tags": ["tooltip", "title-attribute", "a11y", "screen-reader", "touch"]
-    },
-    {
-      "id": "pattern-accessibility-quick-wcag-contrast-validation-as-a-mandatory-gate-in-de",
-      "type": "pattern",
-      "domain": "accessibility",
-      "title": "WCAG contrast validation as a mandatory gate in design flows",
-      "severity": "critical",
-      "description": "# WCAG contrast validation as a mandatory gate in design flows\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nEvery color pairing must pass WCAG contrast validation before approval. Salvador enforces 3 levels: AA normal text (4.5:1), AA large text (3.0:1), AAA (7.0:1). The contrast chain is included in validate-colors composite and runs in design, review, and UX-audit flows. Known safe combos: bg-dark+text-inverse (19.41:1), bg-surface+text-primary (17.85:1). Known failures: bg-accent+text-inverse (2.98:1).\n\n## Example\n\n```typescript\nsalvador_check_contrast({ foreground: 'text-primary', background: 'bg-surface' }) → { pass: true, ratio: 17.85, level: 'AAA' }\n```\n\n## Why\n\nContrast failures are the most common accessibility violation. Automated gating catches them before they reach code review.",
-      "tags": ["wcag", "contrast", "color", "validation", "a11y"]
-    }
-  ]
-}

package/dist/knowledge-packs/knowledge-packs/salvador/salvador-craft/vault/design-tokens.json

@@ -1,26 +0,0 @@
-{
-  "domain": "design-tokens",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "canonical-design-color-token-priority",
-      "type": "pattern",
-      "domain": "design-tokens",
-      "title": "Color Token Priority",
-      "severity": "critical",
-      "description": "## Rule\n\nAll color usage MUST reference design tokens, never raw color values. The priority order is:\n\n1. **Semantic tokens (highest priority)** -- Tokens that convey meaning and intent.\n   - Examples: `text-primary`, `text-secondary`, `text-warning`, `text-error`, `bg-surface`, `bg-error`, `border-focus`, `icon-success`.\n   - Use these whenever the color communicates a specific purpose.\n\n2. **Contextual tokens** -- Tokens scoped to a component context.\n   - Examples: `button-bg-primary`, `input-border-default`, `card-bg`.\n   - Use when semantic tokens are too generic for a component's specific need.\n\n3. **Primitive tokens (lowest priority)** -- Named palette references.\n   - Examples: `blue-600`, `gray-100`.\n   - Use only when no semantic or contextual token fits, and document the reason.\n\n### Forbidden\n\nThe following are **never** permitted in source code:\n\n- Raw hex values: `#3B82F6`, `#fff`, `#000`\n- RGB/RGBA functions: `rgb(59, 130, 246)`, `rgba(0,0,0,0.5)`\n- HSL/HSLA functions: `hsl(217, 91%, 60%)`\n- Tailwind palette classes used as color decisions: `bg-blue-500`, `text-gray-700`\n- CSS named colors: `red`, `white`, `black`\n\n## Why\n\n1. **Theming** -- Semantic tokens decouple color intent from color value, enabling dark mode, high-contrast mode, and brand theming with zero code changes.\n2. **Consistency** -- When \"error\" always maps to the same token, the error color is guaranteed to be uniform across every component.\n3. **Accessibility** -- Token-level contrast validation ensures all usages meet WCAG requirements when the palette changes.\n4. **Maintainability** -- Changing a brand color updates one token definition rather than hundreds of scattered hex values.\n\n## Assertions\n\n- No source file may contain a literal hex color (`/#[0-9a-fA-F]{3,8}/`).\n- No source file may contain `rgb(`, `rgba(`, `hsl(`, or `hsla(` as a color value.\n- No Tailwind class matching `/bg-(red|blue|green|yellow|purple|pink|indigo|gray|slate|zinc|neutral|stone|orange|amber|emerald|teal|cyan|sky|violet|fuchsia|rose|lime)-\\d+/` may appear in component code.\n- Every color property in CSS/JSX must resolve to a design token reference.\n- Primitive token usage must include a code comment explaining why no semantic token fits.",
-      "tags": ["color", "tokens", "semantic", "design-tokens", "theming"],
-      "tier": "agent"
-    },
-    {
-      "id": "canonical-design-spacing-scale",
-      "type": "pattern",
-      "domain": "design-tokens",
-      "title": "Spacing Scale",
-      "severity": "critical",
-      "description": "## Rule\n\nAll spacing values (margin, padding, gap) MUST use only the following scale:\n\n| Token   | Value |\n|---------|-------|\n| space-1 | 4px   |\n| space-2 | 8px   |\n| space-3 | 12px  |\n| space-4 | 16px  |\n| space-6 | 24px  |\n| space-8 | 32px  |\n\nNo other spacing values are permitted. Allowed values: **4, 8, 12, 16, 24, 32** (in pixels).\n\n- Use `space-1` (4px) for tight inline spacing (icon-to-label gaps, error message offset).\n- Use `space-2` (8px) for related element grouping (form fields within a group).\n- Use `space-3` (12px) for medium internal padding (card content insets).\n- Use `space-4` (16px) as the base unit for standard padding and gaps.\n- Use `space-6` (24px) for section separation within a view.\n- Use `space-8` (32px) for major section breaks and page-level margins.\n\n## Why\n\nA constrained spacing scale based on a 4px grid creates consistent visual rhythm across all screens and components. When every element snaps to the same spatial grid:\n\n1. **Visual consistency** -- Users perceive the interface as polished and intentional. Arbitrary values (e.g., 5px, 13px, 22px) create subtle misalignments that accumulate into visual noise.\n2. **Faster design decisions** -- Designers and developers choose from 6 values instead of infinite possibilities, reducing bikeshedding.\n3. **Predictable responsiveness** -- A base-4 scale divides evenly across common breakpoints and container sizes.\n4. **Maintainability** -- Changing the scale in one place propagates cleanly; random values require auditing every usage.\n\n## Assertions\n\n- No CSS property `margin`, `padding`, `gap`, `top`, `right`, `bottom`, `left`, `inset`, or `row-gap`/`column-gap` may contain a value outside the set `[4, 8, 12, 16, 24, 32]` (px) or their rem equivalents `[0.25, 0.5, 0.75, 1, 1.5, 2]`.\n- Zero (`0`) is always permitted (no spacing).\n- Negative margins are allowed only if the absolute value is in the allowed set.\n- Token names matching `/space-/` must resolve to one of the allowed values.",
-      "tags": ["spacing", "layout", "rhythm", "design-tokens"],
-      "tier": "agent"
-    }
-  ]
-}

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

@@ -1,33 +0,0 @@
-{
-  "domain": "design",
-  "version": "1.0.0",
-  "entries": [
-    {
-      "id": "pattern-design-quick-component-variant-enum-over-boolean-prop-explosion",
-      "type": "pattern",
-      "domain": "design",
-      "title": "Component variant enum over boolean prop explosion",
-      "severity": "warning",
-      "description": "# Component variant enum over boolean prop explosion\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nDesign system components must use a single variant enum prop instead of multiple boolean props. Boolean explosion: isLarge, isBold, isPrimary creates 2^3=8 combinations, most invalid. Variant enum: variant='primary'|'secondary'|'destructive'|'outline'|'ghost' makes valid states explicit and invalid states unrepresentable. This pattern is enforced via api-constraints intelligence data and component dev rules.\n\n## Example\n\n```typescript\nBad: <Button isLarge isPrimary isBold>. Good: <Button variant='primary' size='lg'>\n```\n\n## Why\n\nBoolean props create combinatorial explosion of untested states. Variant enums make the valid state space explicit and testable.",
-      "tags": ["variants", "api-design", "boolean-explosion", "type-safety", "components"]
-    },
-    {
-      "id": "pattern-design-quick-atomic-design-classification-5-levels-from-atom-to",
-      "type": "rule",
-      "domain": "design",
-      "title": "Atomic design classification: 5 levels from atom to page",
-      "severity": "critical",
-      "description": "# Atomic design classification: 5 levels from atom to page\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nSalvador classifies all UI elements into 5 atomic design levels defined in chains/domains/ui-components.yaml. Atom: single-responsibility elements (Button, Input, Icon). Molecule: small groups (FormField = label+input+error). Organism: complex sections (Form, Modal, DataTable). Template: page layouts (DashboardLayout). Page: full screens (LoginPage). Classification drives UX law selection in UX-AUDITOR-flow — atoms get Fitts's Law, organisms get Hick's Law.\n\n## Example\n\n```typescript\nButton (atom) → FormField (molecule) → LoginForm (organism) → AuthLayout (template) → LoginPage (page)\n```\n\n## Why\n\nAtomic level determines which UX laws apply, which validation chains run, and how components compose. Skipping levels creates maintenance debt.",
-      "tags": ["atomic-design", "classification", "component-hierarchy", "ux-laws"]
-    },
-    {
-      "id": "pattern-design-quick-semantic-color-context-mapping-with-depth-levels",
-      "type": "rule",
-      "domain": "design",
-      "title": "Semantic color context mapping with depth levels",
-      "severity": "critical",
-      "description": "# Semantic color context mapping with depth levels\n\n## Context\n\nCaptured during development session on 2026-02-21\n\n## Pattern\n\nColor intelligence uses context-aware depth levels for semantic color assignment. Page (depth 0): broadest context, lightest backgrounds. Card (depth 2): elevated surface, subtle distinction. Surface (depth 3): interactive or nested areas. Button (depth 4): highest contrast. Each depth defines text color hierarchy (primary > secondary > muted) and valid background/foreground pairs. The validate-colors composite checks both light and dark mode variants at each depth.\n\n## Example\n\n```typescript\nPage depth-0: bg-page + text-primary. Card depth-2: bg-card + text-primary. Button depth-4: bg-primary-500 + text-inverse.\n```\n\n## Why\n\nContext-aware colors prevent accessibility failures when nesting components. A text color valid on a page background may fail on a card background.",
-      "tags": ["color", "context", "depth-levels", "semantic", "dark-mode"]
-    }
-  ]
-}