@3fn/core 14.0.0 → 15.0.0

package/dist/tokens/semantic/TypographyTokens.js

@@ -45,7 +45,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Small body text for secondary content and compact layouts',
-        description: 'Small body typography with 14px font size, 1.25 line height, body font family, normal weight'
+        description: 'Small body typography with 14px font size, 1.429 line height, body font family, normal weight'
     },
     'typography.bodyMd': {
         name: 'typography.bodyMd',
@@ -71,7 +71,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Large body text for emphasis, lead paragraphs, and prominent content',
-        description: 'Large body typography with 18px font size, 1.75 line height, body font family, normal weight'
+        description: 'Large body typography with 18px font size, 1.556 line height, body font family, normal weight'
     },
     // Heading Hierarchy (H1-H6 following HTML semantics)
     'typography.h1': {
@@ -205,7 +205,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Small button text for compact buttons and tertiary actions',
-        description: 'Small button typography with 14px font size, 1.25 line height, body font family, medium weight'
+        description: 'Small button typography with 14px font size, 1.429 line height, body font family, medium weight'
     },
     'typography.buttonMd': {
         name: 'typography.buttonMd',
@@ -231,7 +231,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Large button text for prominent CTAs and hero buttons',
-        description: 'Large button typography with 18px font size, 1.75 line height, body font family, medium weight'
+        description: 'Large button typography with 18px font size, 1.556 line height, body font family, medium weight'
     },
     'typography.input': {
         name: 'typography.input',
@@ -258,7 +258,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Extra small labels for floating label patterns in form inputs',
-        description: 'Extra small label typography with 13px font size, 1.0 line height, body font family, medium weight for floating labels'
+        description: 'Extra small label typography with 13px font size, 1.538 line height, body font family, medium weight for floating labels'
     },
     'typography.labelSm': {
         name: 'typography.labelSm',
@@ -271,7 +271,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Small labels for compact form fields and UI elements',
-        description: 'Small label typography with 14px font size, 1.25 line height, body font family, medium weight'
+        description: 'Small label typography with 14px font size, 1.429 line height, body font family, medium weight'
     },
     'typography.labelMd': {
         name: 'typography.labelMd',
@@ -301,7 +301,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Floated label state for text input fields with float label pattern',
-        description: `Medium label typography scaled to ${labelMdFloatFontSize}px (fontSize100 × scale088) for floated label state, maintains same lineHeight, fontFamily, fontWeight, and letterSpacing as labelMd to prevent layout shift during animation`
+        description: `Medium label typography scaled to ${labelMdFloatFontSize}px (fontSize100 × scale088) for floated label state, 1.429 line height (lineHeight075, the pairing for the scaled fontSize), body font family, medium weight, default letter spacing — fontFamily, fontWeight, and letterSpacing match labelMd`
     },
     'typography.labelLg': {
         name: 'typography.labelLg',
@@ -314,7 +314,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Large labels for prominent form sections and UI headers',
-        description: 'Large label typography with 18px font size, 1.75 line height, body font family, medium weight'
+        description: 'Large label typography with 18px font size, 1.556 line height, body font family, medium weight'
     },
     // Code Text Size Variants
     'typography.codeSm': {
@@ -328,7 +328,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Small code text for inline code in compact layouts',
-        description: 'Small code typography with 14px font size, 1.25 line height, monospace font family, normal weight'
+        description: 'Small code typography with 14px font size, 1.429 line height, monospace font family, normal weight'
     },
     'typography.codeMd': {
         name: 'typography.codeMd',
@@ -354,7 +354,7 @@ exports.typographyTokens = {
         },
         category: SemanticToken_1.SemanticCategory.TYPOGRAPHY,
         context: 'Large code text for prominent code examples and documentation',
-        description: 'Large code typography with 18px font size, 1.75 line height, monospace font family, normal weight'
+        description: 'Large code typography with 18px font size, 1.556 line height, monospace font family, normal weight'
     }
 };
 /**

package/dist/tokens/themes/dark/SemanticOverrides.js

@@ -17,7 +17,7 @@ exports.darkSemanticOverrides = void 0;
 // ======================================================================
 // FEEDBACK — SUCCESS
 // ======================================================================
-// color.feedback.success.text: { value: 'green400' }
+// color.feedback.success.text: { value: 'green500' }  [OVERRIDDEN below → green300]
 // color.feedback.success.background: { value: 'green100' }
 // color.feedback.success.border: { value: 'green400' }
 // ======================================================================
@@ -76,9 +76,9 @@ exports.darkSemanticOverrides = void 0;
 // ======================================================================
 // TEXT HIERARCHY
 // ======================================================================
-// color.text.default: { value: 'gray300' }
-// color.text.muted: { value: 'gray200' }
-// color.text.subtle: { value: 'gray100' }
+// color.text.default: { value: 'gray300' }  [OVERRIDDEN below → white100]
+// color.text.muted: { value: 'gray200' }  [OVERRIDDEN below → white300]
+// color.text.subtle: { value: 'gray100' }  [OVERRIDDEN below → white500]
 // ======================================================================
 // CONTRAST
 // ======================================================================
@@ -139,6 +139,23 @@ exports.darkSemanticOverrides = void 0;
 // Add populated overrides here as they are confirmed by component specs.
 // Each key must match a semantic token name in the registry.
 exports.darkSemanticOverrides = {
+    // WCAG AA remediation (2026-09-12, Spec 112 audit finding F4)
+    // Light base is green500 (4.72:1 on white100). Against the dark canvas
+    // (color.structure.canvas → gray400) green500 measures only 1.79:1, so dark mode
+    // needs a LIGHTER step: green300 = 4.63:1 on gray400. Guarded by
+    // src/tokens/__tests__/SemanticColorContrast.test.ts.
+    'color.feedback.success.text': { primitiveReferences: { value: 'green300' } },
+    // WCAG AA remediation (2026-09-13, interim dark-text-hierarchy fix; Peter-ratified;
+    // .kiro/issues/2026-09-12-semantic-contrast-adjudication-queue.md)
+    // Light base primitives (gray300/gray200/gray100) render on the dark canvas
+    // (color.structure.canvas → gray400) at 1.536:1 / 2.324:1 / 3.411:1 — all below the
+    // 4.5:1 AA floor for normal text. Remapped to white-ramp steps measured against
+    // gray400: white100 = 8.46:1, white300 = 6.28:1, white500 = 4.53:1. Interim fix —
+    // the other adjudication-queue exemption pairs remain deferred to a future spec.
+    // Guarded by src/tokens/__tests__/SemanticColorContrast.test.ts.
+    'color.text.default': { primitiveReferences: { value: 'white100' } },
+    'color.text.muted': { primitiveReferences: { value: 'white300' } },
+    'color.text.subtle': { primitiveReferences: { value: 'white500' } },
     // Nav-TabBar-Base overrides (Spec 050 Ada R2, 2026-03-17)
     'color.structure.canvas': { primitiveReferences: { value: 'gray400' } },
     'color.action.navigation': { primitiveReferences: { value: 'cyan100' } },

package/dist/tools/integrity/Invariants.d.ts

@@ -11,7 +11,7 @@
  *     This is exactly how Finding 1 hid (216 rgba in both committed and fresh).
  *
  *   - P5 (theme-varying rule): the index's `themeVarying` set must be the
- *     dist base-mode set (5 keys), NOT the registry-wide set (10 keys). A future
+ *     dist base-mode set (EXPECTED_BASE_THEME_VARYING), NOT the registry-wide set. A future
  *     "simplification" that pipes the registry-wide Set through to the index would
  *     reproduce identically committed-vs-fresh while silently re-breaking R5.
  *     (§4.1 residual risk, Task 3 completion.)
@@ -30,14 +30,29 @@
 export declare const SHADOW_COLOR_PRIMITIVES: readonly ["shadowBlack100", "shadowBlue100", "shadowOrange100", "shadowGray100"];
 /**
  * The base-scoped theme-varying set the INDEX must mark `themeVarying: true`
- * (the 5 dist base-mode dark-override keys). This is the readout the index uses;
- * it is deliberately NOT the registry-wide 10 (which over-includes WCAG-only
+ * (the dist base-mode dark-override keys). This is the readout the index uses;
+ * it is deliberately NOT the registry-wide set (which over-includes WCAG-only
  * contrast keys). See Task 3 completion §"Why two theme-varying sets coexist".
+ *
+ * This list grows when a token gains a genuine base-mode DARK override in
+ * src/tokens/themes/dark/SemanticOverrides.ts — that is the invariant holding, not
+ * breaking. It must NEVER grow by absorbing a WCAG_ONLY_OVERMARKS key; that is the
+ * §4.1 regression the anti-conflation sentinel below names.
+ *
+ * 5 → 6 on 2026-09-12: `color.feedback.success.text` gained a dark override
+ * (green500 → green300) as part of the WCAG AA remediation of the Spec 112
+ * completion-claims audit finding F4. See
+ * .kiro/issues/2026-09-12-spec-112-completion-claims-audit.md § F4.
+ *
+ * 6 → 9 on 2026-09-13: `color.text.default`, `color.text.muted`, and
+ * `color.text.subtle` each gained a dark override (white100/white300/white500) as
+ * part of the interim dark-text-hierarchy fix, Peter-ratified. See
+ * .kiro/issues/2026-09-12-semantic-contrast-adjudication-queue.md.
  */
-export declare const EXPECTED_BASE_THEME_VARYING: readonly ["color.action.navigation", "color.background.primary.subtle", "color.icon.navigation.inactive", "color.structure.border.subtle", "color.structure.canvas"];
+export declare const EXPECTED_BASE_THEME_VARYING: readonly ["color.action.navigation", "color.background.primary.subtle", "color.feedback.success.text", "color.icon.navigation.inactive", "color.structure.border.subtle", "color.structure.canvas", "color.text.default", "color.text.muted", "color.text.subtle"];
 /**
- * Sentinel WCAG-only over-marks: keys that the registry-wide set (10) marks but
- * the base-scoped set (5) must NOT. If any of these is `themeVarying: true`, the
+ * Sentinel WCAG-only over-marks: keys that the registry-wide set marks but
+ * the base-scoped set must NOT. If any of these is `themeVarying: true`, the
  * index has been silently re-wired to the registry-wide Set — the §4.1 regression.
  * (This is the anti-conflation guard's negative assertion.)
  */
@@ -63,12 +78,12 @@ export declare function rgbaColorPrimitives(primitivesYaml: string): string[];
  * P5 — theme-varying is the base-scoped set, NOT the registry-wide set.
  *
  * Two assertions (both must hold):
- *   (a) the index's `themeVarying: true` set equals EXACTLY the expected 5 base keys
+ *   (a) the index's `themeVarying: true` set equals EXACTLY the expected base keys
  *       (a missing or extra key is a divergence from the dist base-mode set); and
  *   (b) NONE of the known WCAG-only over-marks is `themeVarying: true` — the
  *       anti-conflation guard. (b) is redundant with (a) when (a) holds, but it
  *       is the explicit, named regression sentinel: if a future change pipes the
- *       registry-wide 10 through to the index, (b) names exactly which over-marks
+ *       registry-wide set through to the index, (b) names exactly which over-marks
  *       reappeared, making the §4.1 re-break legible rather than a generic "extra key".
  */
 export declare function assertThemeVaryingBaseScoped(semanticsYaml: string): InvariantViolation[];

package/dist/tools/integrity/Invariants.js

@@ -12,7 +12,7 @@
  *     This is exactly how Finding 1 hid (216 rgba in both committed and fresh).
  *
  *   - P5 (theme-varying rule): the index's `themeVarying` set must be the
- *     dist base-mode set (5 keys), NOT the registry-wide set (10 keys). A future
+ *     dist base-mode set (EXPECTED_BASE_THEME_VARYING), NOT the registry-wide set. A future
  *     "simplification" that pipes the registry-wide Set through to the index would
  *     reproduce identically committed-vs-fresh while silently re-breaking R5.
  *     (§4.1 residual risk, Task 3 completion.)
@@ -77,20 +77,39 @@ exports.SHADOW_COLOR_PRIMITIVES = [
 ];
 /**
  * The base-scoped theme-varying set the INDEX must mark `themeVarying: true`
- * (the 5 dist base-mode dark-override keys). This is the readout the index uses;
- * it is deliberately NOT the registry-wide 10 (which over-includes WCAG-only
+ * (the dist base-mode dark-override keys). This is the readout the index uses;
+ * it is deliberately NOT the registry-wide set (which over-includes WCAG-only
  * contrast keys). See Task 3 completion §"Why two theme-varying sets coexist".
+ *
+ * This list grows when a token gains a genuine base-mode DARK override in
+ * src/tokens/themes/dark/SemanticOverrides.ts — that is the invariant holding, not
+ * breaking. It must NEVER grow by absorbing a WCAG_ONLY_OVERMARKS key; that is the
+ * §4.1 regression the anti-conflation sentinel below names.
+ *
+ * 5 → 6 on 2026-09-12: `color.feedback.success.text` gained a dark override
+ * (green500 → green300) as part of the WCAG AA remediation of the Spec 112
+ * completion-claims audit finding F4. See
+ * .kiro/issues/2026-09-12-spec-112-completion-claims-audit.md § F4.
+ *
+ * 6 → 9 on 2026-09-13: `color.text.default`, `color.text.muted`, and
+ * `color.text.subtle` each gained a dark override (white100/white300/white500) as
+ * part of the interim dark-text-hierarchy fix, Peter-ratified. See
+ * .kiro/issues/2026-09-12-semantic-contrast-adjudication-queue.md.
  */
 exports.EXPECTED_BASE_THEME_VARYING = [
     'color.action.navigation',
     'color.background.primary.subtle',
+    'color.feedback.success.text',
     'color.icon.navigation.inactive',
     'color.structure.border.subtle',
     'color.structure.canvas',
+    'color.text.default',
+    'color.text.muted',
+    'color.text.subtle',
 ];
 /**
- * Sentinel WCAG-only over-marks: keys that the registry-wide set (10) marks but
- * the base-scoped set (5) must NOT. If any of these is `themeVarying: true`, the
+ * Sentinel WCAG-only over-marks: keys that the registry-wide set marks but
+ * the base-scoped set must NOT. If any of these is `themeVarying: true`, the
  * index has been silently re-wired to the registry-wide Set — the §4.1 regression.
  * (This is the anti-conflation guard's negative assertion.)
  */
@@ -165,12 +184,12 @@ function rgbaColorPrimitives(primitivesYaml) {
  * P5 — theme-varying is the base-scoped set, NOT the registry-wide set.
  *
  * Two assertions (both must hold):
- *   (a) the index's `themeVarying: true` set equals EXACTLY the expected 5 base keys
+ *   (a) the index's `themeVarying: true` set equals EXACTLY the expected base keys
  *       (a missing or extra key is a divergence from the dist base-mode set); and
  *   (b) NONE of the known WCAG-only over-marks is `themeVarying: true` — the
  *       anti-conflation guard. (b) is redundant with (a) when (a) holds, but it
  *       is the explicit, named regression sentinel: if a future change pipes the
- *       registry-wide 10 through to the index, (b) names exactly which over-marks
+ *       registry-wide set through to the index, (b) names exactly which over-marks
  *       reappeared, making the §4.1 re-break legible rather than a generic "extra key".
  */
 function assertThemeVaryingBaseScoped(semanticsYaml) {
@@ -180,7 +199,7 @@ function assertThemeVaryingBaseScoped(semanticsYaml) {
         .filter(([, raw]) => raw.themeVarying === true)
         .map(([name]) => name));
     const expected = new Set(exports.EXPECTED_BASE_THEME_VARYING);
-    // (a) exact-set equality with the base-scoped 5.
+    // (a) exact-set equality with the base-scoped set (EXPECTED_BASE_THEME_VARYING).
     for (const key of expected) {
         if (!actualTrue.has(key)) {
             violations.push({

package/dist/tools/integrity/cli/run-audit.js

@@ -104,7 +104,7 @@ rgbaScan('token-index/primitives.yaml');
 rgbaScan('token-index/semantics.yaml');
 oklchVsRgba('dist/DesignTokens.web.css');
 // CHECK 3 (Task 5.1) — the absolute correctness-property assertions the re-diff cannot catch:
-//   P3 (no rgba except the shadow allowlist) and P5 (theme-varying = base-scoped 5, not registry-wide 10).
+//   P3 (no rgba except the shadow allowlist) and P5 (theme-varying = the base-scoped set, not the registry-wide one).
 // Run against the COMMITTED token-index (repo cwd) — these must hold regardless of drift.
 console.log('\n--- CHECK 3: token-index invariants (P3 no-legacy-color, P5 theme-varying-base-scoped) ---\n');
 const primitivesYaml = readMaybe(path.resolve(repo, 'token-index/primitives.yaml'));

package/dist/types/PrimitiveToken.d.ts

@@ -87,7 +87,21 @@ export interface PrimitiveToken {
     description: string;
     /** Mathematical relationship to family base value */
     mathematicalRelationship: string;
-    /** Whether token aligns with 8-unit baseline grid (spacing/radius families) */
+    /**
+     * Whether the token aligns with the 8-unit baseline grid.
+     *
+     * Predicate (system-wide): `true` iff `baseValue` is an exact multiple of 8 AND the
+     * token's family participates in the baseline grid (dimensional families — spacing,
+     * radius, sizing, blur, shadow offset, tap area, font size). Non-participating families
+     * (border width, breakpoint, density, and all non-dimensional families) always carry
+     * `false`, meaning "not applicable".
+     *
+     * Values on the 4-unit subgrid (4, 12, 20) are `false`: valid values, not grid-aligned
+     * ones. Enforcement of the grid itself is narrower than this flag — ErrorValidator and
+     * PassValidator only *require* alignment for spacing and radius.
+     *
+     * Guarded by `src/tokens/__tests__/BaselineGridAlignmentFlag.test.ts`.
+     */
     baselineGridAlignment: boolean;
     /** Whether token is a strategic flexibility exception within its family */
     isStrategicFlexibility: boolean;

package/dist/types/generated/TokenTypes.d.ts

@@ -6,7 +6,7 @@
  *
  * To regenerate: npm run generate:types
  *
- * Generated: 2026-08-12T03:23:16.669Z
+ * Generated: 2026-10-03T02:14:56.799Z
  */
 /**
  * Union type of all semantic color token names

package/dist/types/generated/TokenTypes.js

@@ -7,7 +7,7 @@
  *
  * To regenerate: npm run generate:types
  *
- * Generated: 2026-08-12T03:23:16.669Z
+ * Generated: 2026-10-03T02:14:56.799Z
  */
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.isColorTokenName = isColorTokenName;

package/dist/types/index.d.ts

@@ -11,5 +11,6 @@ export { SemanticCategory } from './SemanticToken';
 export type { ValidationResult, UsagePatternResult, ConsistencyValidationResult, ValidationLevel } from './ValidationResult';
 export type { TranslationOutput, UnitConversionConfig, FormatGenerationConfig, PathOrganizationConfig, TargetPlatform, OutputFormat } from './TranslationOutput';
 export type { InsetPadding } from './ComponentTypes';
+export type { Oklch } from '../color/OklchConverter';
 export type { ColorTokenName, OpacityTokenName, ShadowTokenName, } from './generated/TokenTypes';
 //# sourceMappingURL=index.d.ts.map

package/governance/AI-Collaboration-Framework.md

@@ -8,7 +8,7 @@ description: Detailed protocols for AI-human collaboration — mandatory bias mi
 # AI Collaboration Framework
 
 **Date**: 2026-01-15
-**Last Reviewed**: 2026-01-15
+**Last Reviewed**: 2026-09-19
 **Purpose**: Detailed protocols for AI-human collaboration with mandatory bias mitigation and candid communication
 **Organization**: process-standard
 **Scope**: cross-project
@@ -114,23 +114,31 @@ This is a common failure mode: humans ask "What do you think about X?" and AI in
 
 ## Mandatory Devil's Advocate Protocols
 
-### Protocol 1: Counter-Argument Requirement
+### Protocol 1: Counter-Argument Requirement (with the fold-back discipline)
 
-**RULE**: For every significant recommendation, AI agents MUST provide at least one strong counter-argument.
+**RULE**: For every significant recommendation, AI agents MUST provide at least one strong counter-argument — and MUST use it before presenting it *(fold-back discipline, ratified 2026-09-19 — `.kiro/docs/ballots/2026-09-19-counter-argument-fold-back.md`)*:
+
+1. **Fold-back first**: run the counter-argument against your own proposal; fold in what it genuinely improves.
+2. **Present the residual**: give the revised proposal with the **surviving** counter-argument — what revision could not absorb — stated plainly. An empty residual signals the counter-argument was too weak, not that the proposal is safe.
+3. **Surface forks**: where the counter-argument exposes a fork between defensible options, surface the fork; never absorb it by picking — the pick is the human's.
+
+**The guard**: never manufacture an absorbable objection to display a revision. The strongest counter-arguments are the ones that survive revision; the residual is the deliverable, not the absorption.
 
 **Correct:**
-> "I recommend implementing the token system because it provides consistency.
+> "I recommend implementing the token system because it provides consistency. Working my counter-argument against the proposal changed it: I dropped the per-component override layer, which existed only to answer the over-abstraction objection and was itself the main source of it.
 >
-> HOWEVER, here's why this might be wrong:
-> - Token systems can create over-abstraction that slows development
-> - The complexity may not be justified for a small design system
-> - Maintenance overhead could exceed benefits
+> HOWEVER, what survives revision:
+> - The complexity may still not be justified for a small design system
+> - Maintenance overhead could exceed benefits at this team size
 >
-> What's your assessment of these risks?"
+> What's your assessment of these residual risks?"
 
 **Incorrect:**
 > "I recommend implementing the token system because it provides consistency and will solve your problems."
 
+**Also incorrect** (the pre-fold-back form — a counter-argument the proposal never absorbed nor survived is decoration):
+> "I recommend implementing the token system. HOWEVER, here's why this might be wrong: [objections the proposal was never tested against]. What's your assessment?"
+
 ### Protocol 2: Risk-First Analysis
 
 **RULE**: AI agents must lead with risks and limitations before presenting benefits.
@@ -251,7 +259,7 @@ This is not about proving anyone right or wrong. It's about preserving options f
 
 **MANDATORY**: All AI agents must implement these behaviors:
 
-- Provide counter-arguments to significant recommendations
+- Provide counter-arguments to significant recommendations — run each against your own proposal first, and present the surviving residual (the fold-back discipline, Protocol 1)
 - Lead with risks and limitations
 - Challenge human assumptions explicitly
 - Ask for evidence to support claims
@@ -268,6 +276,7 @@ This is not about proving anyone right or wrong. It's about preserving options f
 ### AI Anti-Patterns
 
 - Agree with human without providing counter-arguments
+- Present a counter-argument the proposal was never tested against (compliance theater), or manufacture absorbable objections to display a revision
 - Recommend solutions without identifying risks
 - Use confident language without supporting evidence
 - Focus on benefits while minimizing limitations

package/governance/BUILD-SYSTEM-SETUP.md

@@ -125,7 +125,7 @@ The `build:verify` script (`verify-build.js`) checks that:
 
 ### You DON'T need to build when:
 - Running tests with `npm test` (ts-jest handles compilation)
-- Using CLI tools that run via tsx (e.g., the release tool: `npx tsx src/tools/release/cli/release-tool.ts analyze`)
+- Using CLI tools that run via tsx (e.g., the agent generator: `npx tsx tools/agent-generator/generate.ts`)
 - Making changes and running tests immediately
 
 ## Development Workflow
@@ -215,7 +215,6 @@ The build system now enforces full TypeScript type safety:
 ### Option 1: Separate Build Configs
 Create separate `tsconfig.json` files for different parts of the codebase:
 - `tsconfig.tokens.json` - Just token generation code
-- `tsconfig.release.json` - Release analysis code
 
 ### Module-resolution direction (settled — Spec 118)
 *(Supersedes the former "Go Full ts-node" option, which is moot: ts-node is retired from the governed surface.)* The settled direction is **compiled-`dist/` for package own code** (Class A — CLI, generators, exports run as compiled JS) and **scoped `tsx`** as the sole runtime-TS mechanism for consumer `.ts` (Class B). See the Rosetta-System-Architecture "Module-Resolution Contract (Spec 118)" for the full contract; full ESM modernization is a separate, externally-triggered future migration tracked in `docs/roadmap/m0a-deferred-items.md`.

package/governance/Component-Development-Guide.md

@@ -1876,7 +1876,7 @@ Components come with their own unique properties that might include, but are not
 5. **README** (required) - Create comprehensive component documentation
 6. **HTML Canaries** (required) - Create validation examples
 7. **Implementation** (required) - Build component across platforms
-8. **Dark Mode Token Population** (if component has dark mode differentiation) - Coordinate with Ada to populate the component's semantic color token entries in the dark theme file (`src/tokens/themes/dark/SemanticOverrides.ts`). Identify which tokens need Level 2 overrides (different primitive name in dark mode) and populate those entries. Leave Level 1 tokens (same primitive name, different value per mode) as commented-out — they resolve automatically via primitive dark values. Without this step, the component will silently render light-mode fallback values in dark mode for any tokens that need Level 2 overrides. *(Added by Spec 080, Lina R2 F36)*
+8. **Dark Mode Token Population** (if component has dark mode differentiation) - Coordinate with Ada to populate the component's semantic color token entries in the dark theme file (`src/tokens/themes/dark/SemanticOverrides.ts`). Identify which tokens need Level 2 overrides (different primitive in dark mode) and populate those entries. Leave Level 1 tokens as commented-out — Level 1 means the token deliberately resolves to the *same* value in both modes (primitives have no mode dimension, so a commented-out entry falls back to the base/light reference). Without this step, the component will silently render light-mode fallback values in dark mode for any tokens that need Level 2 overrides. *(Added by Spec 080, Lina R2 F36)*
 9. **Demo Page** (if web implementation) - Create or update demo in `demos/` (see Demo Maintenance Checklist)
 
 This workflow produces clearer requirements, better documentation, and validation that ensures documentation stays accurate.

package/governance/Component-Development-Standards.md

@@ -36,7 +36,7 @@ This document provides comprehensive guidelines for creating new component famil
 |-----------|----------|---------|
 | **Shared Purpose** | Do components share a common purpose that doesn't fit existing families? | "Progress indication" doesn't fit Form Inputs or Buttons |
 | **Multiple Variants** | Can you identify at least 3 potential semantic variants? | Loading: Spinner, Progress, Skeleton |
-| **Clear Base Behaviors** | Can you define foundational behaviors that ALL variants share? | All loading indicators: `indicates_loading`, `accessible_label` |
+| **Clear Base Behaviors** | Can you define foundational behaviors that ALL variants share? | All loading indicators: `state_loading`, `accessibility_aria_label` |
 | **Cross-Platform Need** | Is this needed across web, iOS, and Android? | Yes - all platforms need loading indicators |
 
 **Do NOT create a new family when**:
@@ -113,7 +113,7 @@ List the foundational behaviors that ALL semantic variants will inherit.
 **Behavior Identification Checklist**:
 - [ ] What interaction patterns are common to all variants?
 - [ ] What accessibility requirements apply to all variants?
-- [ ] What visual states are shared (focus, error, disabled)?
+- [ ] What visual states are shared (focus, error, loading)?
 - [ ] What token dependencies are universal?
 
 **Template**:
@@ -319,29 +319,28 @@ properties:
     type: string
     required: false
     description: Error message to display
-  disabled:
-    type: boolean
-    required: false
-    default: false
-    description: Whether input is disabled
+  # No disabled prop: disabled states are not supported corpus-wide, zero
+  # exceptions (adjudicated 2026-07-15 — .kiro/issues/button-cta-disabled-state-adjudication.md).
+  # Components declare the standardized `excludes: state_disabled` block in
+  # contracts.yaml instead; use state_loading or validate-on-press/blur.
 
 contracts:
-  - name: focusable
+  - name: interaction_focusable
     description: Can receive keyboard focus via Tab key navigation
     platforms: [web, ios, android]
     required: true
     wcag: "2.1.1"
-  - name: float_label_animation
+  - name: content_float_label
     description: Label animates from placeholder to floating position on focus
     platforms: [web, ios, android]
     required: true
     wcag: "2.3.3"
-  - name: validates_on_blur
+  - name: validation_on_blur
     description: Validation triggers when field loses focus
     platforms: [web, ios, android]
     required: true
     wcag: "3.3.1"
-  - name: error_state_display
+  - name: state_error
     description: Displays error message and visual error indication
     platforms: [web, ios, android]
     required: true
@@ -510,7 +509,6 @@ Add the new family to the Component Family Inheritance Structures document.
 Verify all schemas are valid and complete:
 - [ ] All required fields present
 - [ ] Property types are valid
-- [ ] Contracts reference valid WCAG criteria
 - [ ] Token patterns exist in token system
 - [ ] Platforms list is complete
 
@@ -683,7 +681,6 @@ Complete these checks before starting implementation:
 - [ ] **Schema Location Correct**: `src/components/core/[Component-Name]/[Component-Name].schema.yaml`
 - [ ] **Required Fields Present**: name, type, family, behaviors, properties, contracts, tokens, platforms, readiness
 - [ ] **Property Types Valid**: All properties have valid type definitions
-- [ ] **Contracts Reference WCAG**: Accessibility contracts include WCAG criterion references
 - [ ] **Token Patterns Exist**: All referenced tokens exist in the token system
 - [ ] **Platforms List Complete**: All supported platforms listed (web, ios, android)
 
@@ -803,16 +800,20 @@ This section defines the formal review process for ensuring new component famili
 **Automated Validation Checks**:
 ```yaml
 schema_validation:
+  # Per spec 063, contracts live in contracts.yaml — NOT in the schema. These
+  # five fields are what schema validation actually requires (see
+  # src/__tests__/stemma-system/behavioral-contract-validation.test.ts).
   required_fields:
     - name
     - type
     - family
     - behaviors
-    - properties
-    - contracts
-    - tokens
     - platforms
-    - readiness
+
+  # Authored by convention, but NOT presence-checked by schema validation:
+  #   properties, tokens, readiness (and `inherits` on semantic variants)
+  # Contract-level checks below read the component's contracts.yaml, not the
+  # schema; contracts.yaml must exist and declare at least one contract.
   
   type_validation:
     - type must be: primitive | semantic | standalone
@@ -821,7 +822,7 @@ schema_validation:
   
   contract_validation:
     - Each contract must have: description, platforms, validation
-    - WCAG-referenced contracts must have: wcag field
+    - Allowlisted contracts (exact names + accessibility_*/content_*_label prefixes) must carry a wcag value ('N/A' when genuinely not applicable)
   
   token_validation:
     - All token patterns must exist in token system

package/governance/Component-Family-Avatar.md

@@ -80,13 +80,13 @@ Avatar-Base (Primitive) [IMPLEMENTED]
 
 | Contract | Description | WCAG | Platforms |
 |----------|-------------|------|-----------|
-| `shape_differentiation` | Circle for human, hexagon for agent | 1.4.1 | web, ios, android |
-| `displays_image` | Shows user image when available (human only) | 1.1.1 | web, ios, android |
-| `displays_fallback` | Shows icon when image unavailable or agent type | 1.1.1 | web, ios, android |
+| `visual_entity_shape` | Circle for human, hexagon for agent | 1.4.1 | web, ios, android |
+| `content_displays_image` | Shows user image when available (human only) | 1.1.1 | web, ios, android |
+| `content_displays_fallback` | Shows icon when image unavailable or agent type | 1.1.1 | web, ios, android |
 | `error_handling` | Falls back to icon on image load failure | N/A | web, ios, android |
-| `size_variants` | Supports six size variants (xs-xxl) | N/A | web, ios, android |
-| `interactive_feedback` | Shows hover visual feedback when interactive | N/A | web, ios, android |
-| `decorative_mode` | Hides from screen readers when decorative | 1.1.1 | web, ios, android |
+| `visual_size_variants` | Supports six size variants (xs-xxl) | N/A | web, ios, android |
+| `interaction_hover` | Shows hover visual feedback when interactive | N/A | web, ios, android |
+| `accessibility_decorative_mode` | Hides from screen readers when decorative | 1.1.1 | web, ios, android |
 | `wrapper_delegation` | No onClick/onPress - wrapper handles interaction | 2.1.1 | web, ios, android |
 
 ---

package/governance/Component-Family-Badge.md

@@ -77,24 +77,24 @@ Badge (Family)
 
 | Contract | Description | WCAG | Platforms |
 |----------|-------------|------|-----------|
-| displays_label | Renders text label visibly | 1.3.1 | web, ios, android |
-| non_interactive | Does not respond to user interaction | — | web, ios, android |
-| supports_icon | Optionally displays leading icon via Icon-Base | 1.3.1 | web, ios, android |
-| supports_truncation | Truncates with ellipsis when truncate=true; full text accessible | 1.3.1 | web, ios, android |
-| color_contrast | Meets WCAG AA contrast requirements (4.5:1) | 1.4.3 | web, ios, android |
-| text_scaling | Scales proportionally with user font size preferences | 1.4.4 | web, ios, android |
+| content_displays_label | Renders text label visibly | 1.3.1 | web, ios, android |
+| accessibility_non_interactive | Does not respond to user interaction | — | web, ios, android |
+| content_supports_icon | Optionally displays leading icon via Icon-Base | 1.3.1 | web, ios, android |
+| content_truncation | Truncates with ellipsis when truncate=true; full text accessible | 1.3.1 | web, ios, android |
+| accessibility_color_contrast | Meets WCAG AA contrast requirements (4.5:1) | 1.4.3 | web, ios, android |
+| accessibility_text_scaling | Scales proportionally with user font size preferences | 1.4.4 | web, ios, android |
 
 ### Base Contracts (Badge-Count-Base)
 
 | Contract | Description | WCAG | Platforms |
 |----------|-------------|------|-----------|
-| displays_count | Shows numeric value | 1.3.1 | web, ios, android |
-| truncates_at_max | Shows "[max]+" when count exceeds max | 1.3.1 | web, ios, android |
-| circular_single_digit | Renders circular for single-digit counts | — | web, ios, android |
-| pill_multi_digit | Renders pill shape for multi-digit counts | — | web, ios, android |
-| non_interactive | Does not respond to user interaction | — | web, ios, android |
-| color_contrast | Meets WCAG AA contrast requirements (4.5:1) | 1.4.3 | web, ios, android |
-| text_scaling | Scales proportionally with user font size preferences | 1.4.4 | web, ios, android |
+| content_displays_count | Shows numeric value | 1.3.1 | web, ios, android |
+| content_truncates_at_max | Shows "[max]+" when count exceeds max | 1.3.1 | web, ios, android |
+| visual_circular_shape | Renders circular for single-digit counts | — | web, ios, android |
+| visual_pill_shape | Renders pill shape for multi-digit counts | — | web, ios, android |
+| accessibility_non_interactive | Does not respond to user interaction | — | web, ios, android |
+| accessibility_color_contrast | Meets WCAG AA contrast requirements (4.5:1) | 1.4.3 | web, ios, android |
+| accessibility_text_scaling | Scales proportionally with user font size preferences | 1.4.4 | web, ios, android |
 
 ### Extended Contracts (Badge-Count-Notification)
 
@@ -102,13 +102,13 @@ Inherits all contracts from Badge-Count-Base, plus:
 
 | Contract | Description | WCAG | Platforms |
 |----------|-------------|------|-----------|
-| notification_semantics | Conveys notification/alert meaning through color | 1.3.1 | web, ios, android |
-| announces_count_changes | Announces count changes to screen readers when enabled | 4.1.3 | web, ios, android |
-| pluralized_announcements | Uses correct pluralization in announcements | 4.1.3 | web, ios, android |
+| visual_notification_color | Conveys notification/alert meaning through color | 1.3.1 | web, ios, android |
+| accessibility_announces_changes | Announces count changes to screen readers when enabled | 4.1.3 | web, ios, android |
+| accessibility_pluralized_announcements | Uses correct pluralization in announcements | 4.1.3 | web, ios, android |
 
 ### Contract Details
 
-#### displays_label
+#### content_displays_label
 
 **Description**: Renders the provided text label visibly within the badge container.
 
@@ -121,7 +121,7 @@ Inherits all contracts from Badge-Count-Base, plus:
 
 **WCAG Compliance**: 1.3.1 Info and Relationships
 
-#### non_interactive
+#### accessibility_non_interactive
 
 **Description**: Badge components do not respond to user interaction.
 
@@ -132,7 +132,7 @@ Inherits all contracts from Badge-Count-Base, plus:
 - iOS: No onTapGesture, not focusable
 - Android: No clickable modifier, not focusable
 
-#### announces_count_changes
+#### accessibility_announces_changes
 
 **Description**: When count changes and announceChanges is enabled, screen readers are notified.