@3fn/core 14.0.0 → 15.0.0

package/governance/DesignerPunk-Integration-Guide.md

@@ -8,7 +8,7 @@ description: Everything a product developer needs to integrate DesignerPunk into
 # DesignerPunk Integration Guide
 
 **Date**: 2026-04-08
-**Last Reviewed**: 2026-05-10
+**Last Reviewed**: 2026-09-26
 **Purpose**: Everything a product developer needs to integrate DesignerPunk into a product repo
 **Organization**: process-standard
 **Scope**: cross-project
@@ -199,7 +199,7 @@ Create `.kiro/settings/mcp.json` at your project root (Kiro reads this file on a
         "./node_modules/@3fn/core/dist/mcp/application-mcp.js"
       ],
       "env": {
-        "COMPONENTS_DIR": "./src/components/core",
+        "COMPONENTS_DIR": "./src/components",
         "PATTERNS_DIR": "./node_modules/@3fn/core/experience-patterns",
         "TEMPLATES_DIR": "./node_modules/@3fn/core/layout-templates",
         "GUIDANCE_DIR": "./node_modules/@3fn/core/family-guidance",
@@ -233,12 +233,19 @@ Once the agent session reconnects, it should show `designerpunk-docs` and `desig
 
 #### 4b. Set up agent prompts
 
-If using the product agent template:
+The agent prompts are generated for your harness, not copied by hand. `npx designerpunk init` emits them for the default target. To add another target, or to wire a repo that `init` did not create, run:
+
 ```bash
-cp -r node_modules/@3fn/core/product-template/agents/ .kiro/agents/
+npx designerpunk attach --target=<cc|kiro>
 ```
 
-Then customize `[CUSTOMIZE]` markers in each prompt file with your product name, human lead, and domain-specific context. See `product-template/agents/README.md` for details.
+`attach` will attach a harness (agents + MCP config + approvals), for one target. It is safe to re-run. To read DesignerPunk without becoming it (MCP config and approvals only, no agents), add `--reference`:
+
+```bash
+npx designerpunk attach --target=<cc|kiro> --reference
+```
+
+After `attach` finishes, restart your agent session so it picks up the MCP servers.
 
 ### 5. Verify — Explore the Component Catalog
 
@@ -308,14 +315,18 @@ This checks semantic reference integrity, required fields, mathematical relation
 
 Produces platform token files in your configured output directory:
 - `DesignTokens.web.css` — CSS custom properties
-- `DesignTokens.ios.swift` — Swift constants + theme protocol
-- `DesignTokens.android.kt` — Kotlin constants + theme data class
+- `DesignTokens.ios.swift` — Swift constants (no theme surface yet; see "iOS and Android" under step 7)
+- `DesignTokens.android.kt` — Kotlin constants (no theme surface yet; see "iOS and Android" under step 7)
 - `ComponentTokens.web.css` / `.ios.swift` / `.android.kt` — component tokens
 - `DesignTokens.dtcg.json` — DTCG standard format
 - `DesignTokens.figma.json` — Figma Variables format
 - `token-index/` — structured YAML index (primitives, semantics, components) loaded by the Application MCP for token queries
 
-If you registered a custom theme, the output includes themed values scoped by `data-theme` attribute (web) or as additional theme structs/instances (iOS/Android).
+**In 15.0.0, a custom theme you register does not yet change this output.**
+- Web: no `[data-theme="<name>"]` block is generated.
+- iOS/Android: no theme structs or instances are generated.
+
+The web output carries DesignerPunk's base light/dark values and the baked `data-theme="wcag"` block. Theme emission is delivered by the consumer-generation completeness spec (`.kiro/issues/2026-10-02-consumer-generation-completeness-spec.md`).
 
 ### Platform Dependencies for OKLCH Color Output
 
@@ -338,7 +349,7 @@ The color system uses OKLCH format. Platform-specific dependencies are needed fo
 import '@3fn/core';
 // or: import '@3fn/core/components';
 
-// Import design tokens
+// Import design tokens: DesignerPunk's base (see "What these two imports are" below)
 import '@3fn/core/tokens.css';
 import '@3fn/core/component-tokens.css';
 
@@ -350,60 +361,38 @@ import '@3fn/core/fonts/rajdhani.css';
 import { BlendCalculator } from '@3fn/core/blend';
 ```
 
-For theming, set the `data-theme` attribute on any HTML element:
-```html
-<div data-theme="my-theme">
-  <!-- All DesignerPunk components inside inherit themed values -->
-</div>
-```
+**What these two imports are.**
+- `@3fn/core/tokens.css` is **DesignerPunk's own base**. It is generated from DesignerPunk's configuration, not yours, and it is the **zero-config evaluation path**: the components render against it with nothing built.
+- `@3fn/core/component-tokens.css` is DesignerPunk's **component token tier**. Keep importing it on every path.
 
-Base theme applies at `:root` with no attribute. Dark-only themes automatically set `color-scheme: dark`.
+**Your own tokens.** After you run `npx designerpunk generate`, import your own `DesignTokens.web.css` from your configured `output` directory **in place of** `@3fn/core/tokens.css`. That file carries your token tier's values. Keep `@3fn/core/component-tokens.css`.
 
-#### iOS (M0a — Manual Copy)
+**Themes, in this version:**
+- **Dark mode** follows the user's preferred colour scheme, through CSS `light-dark()`. Set `color-scheme` on an element to force light or dark.
+- **One theme block is baked in**: `data-theme="wcag"`. It ships in DesignerPunk's base CSS and is generated into yours.
+  ```html
+  <div data-theme="wcag">
+    <!-- DesignerPunk components inside use the WCAG theme's values -->
+  </div>
+  ```
+- **A theme you register in `designerpunk.config.ts` does not yet produce a `[data-theme="<name>"]` block in any generated CSS.** A custom `data-theme` value resolves against nothing in 15.0.0. Theme emission is delivered by the consumer-generation completeness spec (`.kiro/issues/2026-10-02-consumer-generation-completeness-spec.md`).
 
-1. Locate Swift files in the installed package:
-   - `node_modules/@3fn/core/dist/DesignTokens.ios.swift`
-   - `node_modules/@3fn/core/dist/ComponentTokens.ios.swift`
-   - Component platform files: `node_modules/@3fn/core/src/components/core/*/platforms/ios/`
-   - Blend utilities: `node_modules/@3fn/core/src/blend/ThemeAwareBlendUtilities.ios.swift`
+#### iOS and Android (not supported for onboarding in 15.0.0)
 
-2. Copy into your Xcode project's source tree
+**Native onboarding is not supported in 15.0.0.** The package ships DesignerPunk's native component sources and token files, but in this version they do not form a target that compiles in your app:
 
-3. Requirements:
-   - Minimum deployment target: **iOS 17.0+**
-   - Required frameworks: **SwiftUI**, **UIKit**
+- `node_modules/@3fn/core/dist/DesignTokens.ios.swift` and `node_modules/@3fn/core/dist/DesignTokens.android.kt` are DesignerPunk's **un-themed base snapshot**. They are generated from DesignerPunk's own configuration, not yours.
+- `node_modules/@3fn/core/dist/ComponentTokens.ios.swift` and `node_modules/@3fn/core/dist/ComponentTokens.android.kt` are DesignerPunk's **component token tier**. The shipped components require them.
+- The shipped iOS and Android components (`node_modules/@3fn/core/src/components/core/*/platforms/ios/` and `.../platforms/android/`) also read a **theme surface**: `@Environment(\.dpTheme)` on iOS and `LocalDPTheme.current` on Android. **Neither the base files nor your own `npx designerpunk generate` emits that theme surface in this version.**
+- Native token output omits the **14 theme-varying semantic colours**, among them `colorActionPrimary` and `colorStructureCanvas`. Four of them were present in 14.1.0's base files and are absent from 15.0.0's:
+  - Swift: `colorFeedbackSuccessText`, `colorTextDefault`, `colorTextMuted`, `colorTextSubtle`;
+  - Kotlin: `color_feedback_success_text`, `color_text_default`, `color_text_muted`, `color_text_subtle`.
 
-4. Theme consumption:
-   ```swift
-   @Environment(\.{abbreviation}Theme) var theme
-   // Use: theme.colorActionPrimary
-   // Static tokens: DesignTokens.spaceInset100
-   ```
+Copying these files into an Xcode project or an Android module therefore does not yield a compiling target.
 
-**Note**: `npx designerpunk sync:ios` is planned for M0b to automate this process.
+Native onboarding is delivered by the consumer-generation completeness spec (`.kiro/issues/2026-10-02-consumer-generation-completeness-spec.md`). It covers three things: the theme surface, DesignerPunk's component tier harvested by your own `generate`, and per-platform output paths.
 
-#### Android (M0a — Manual Copy)
-
-1. Locate Kotlin files in the installed package:
-   - `node_modules/@3fn/core/dist/DesignTokens.android.kt`
-   - `node_modules/@3fn/core/dist/ComponentTokens.android.kt`
-   - Component platform files: `node_modules/@3fn/core/src/components/core/*/platforms/android/`
-   - Blend utilities: `node_modules/@3fn/core/src/blend/ThemeAwareBlendUtilities.android.kt`
-
-2. Copy into your Android module's source tree
-
-3. Requirements:
-   - Compose BOM version compatibility with component implementations
-   - If using R8/ProGuard: include synced Kotlin files in keep rules
-
-4. Theme consumption:
-   ```kotlin
-   val theme = Local{Abbreviation}Theme.current
-   // Use: theme.colorActionPrimary
-   // Static tokens: DesignTokens.space_inset_100
-   ```
-
-**Note**: `npx designerpunk sync:android` is planned for M0b to automate this process.
+Platform requirements, for reference: **iOS 17.0+** (SwiftUI, UIKit). On Android, the Compose BOM must be compatible with the component implementations.
 
 ---
 
@@ -451,7 +440,7 @@ module.exports = {
 
 ```bash
 npx jest                          # Run all tests
-npx jest src/components/core/     # Run component tests only
+npx jest src/components/          # Run your own component tests, once you've added some
 npx jest --testPathPattern=Button # Run tests matching "Button"
 ```
 
@@ -544,15 +533,14 @@ Runs automatically as part of `npx designerpunk generate` when platform paths ar
 |-------------|-------------|
 | `@3fn/core` | All 34 web components (ESM bundle) |
 | `@3fn/core/components` | Same (alias) |
-| `@3fn/core/tokens.css` | Design tokens as CSS custom properties |
-| `@3fn/core/component-tokens.css` | Component-level tokens as CSS custom properties |
+| `@3fn/core/tokens.css` | DesignerPunk's base design tokens as CSS custom properties: the zero-config evaluation path. After `generate`, use your own `DesignTokens.web.css` instead (see step 7, Build Your Product) |
+| `@3fn/core/component-tokens.css` | DesignerPunk's component-level tokens as CSS custom properties (required on every path) |
 | `@3fn/core/config` | `defineConfig` function with TypeScript types |
 | `@3fn/core/blend` | Blend calculation utilities |
 | `@3fn/core/grid.css` | Responsive grid CSS |
 | `@3fn/core/fonts/figtree.css` | Figtree font family (body/UI) |
 | `@3fn/core/fonts/commit-mono.css` | Commit Mono font family (code/mono) |
 | `@3fn/core/fonts/rajdhani.css` | Rajdhani font family (display) |
-| `@3fn/core/fonts/inter.css` | Inter font family (legacy, deprecated) |
 
 ---
 
@@ -573,9 +561,9 @@ Starts with empty data if no product directory exists (warning, not error).
 
 **Component gap detection** reads `component-meta.yaml` files to validate component references in screen specs. Configure the component source directory:
 - `COMPONENT_DIR` env var (if set)
-- Default: `src/components/core`
+- Default: `src/components` (your own component directory, once you've added components)
 
-**In a product repo** (where DesignerPunk is installed as a package), set `COMPONENT_DIR` to point into the installed package:
+**In a product repo** (where DesignerPunk is installed as a package), set `COMPONENT_DIR` to point into the installed package's own components instead — useful for validating screen-spec references against DesignerPunk's own component set rather than your own:
 ```bash
 COMPONENT_DIR=./node_modules/@3fn/core/src/components/core npx designerpunk mcp:product
 ```
@@ -945,6 +933,14 @@ Agents primarily use MCP queries for design system knowledge. Knowledge bases su
 
 ## Upgrading
 
+> **Note (2026-10-02, ballot `2026-10-02-integration-guide-native-scoping`).** This section describes the `sync` flow from **before 15.0.0**: `--accept-all`, `.kiro/sync-manifest.json`, and `sync` updating tokens and components. 15.0.0 retired that flow.
+>
+> **For the current upgrade path, use 15.0.0's release notes:**
+> - `sync` prints its report before changing anything, and converts the manifest to `designerpunk.manifest.json`.
+> - `sync --migrate-legacy --target=<cc|kiro>` removes what an earlier `init` copied and attaches the generated agent layer, in the same run.
+>
+> Spec 123 Task 19.4 reconciles this section.
+
 After upgrading `@3fn/core` to a new version, run `sync` to detect and apply package changes:
 
 ```bash

package/governance/Figma-Workflow-Guide.md

@@ -159,13 +159,20 @@ npm run figma:push -- --clean
 | Token Type | Figma Artifact | Naming Convention |
 |------------|---------------|-------------------|
 | Primitive variables (space, color, fontSize, etc.) | Figma Variables in "Primitives" collection | `space/100`, `color/purple/300` |
-| Semantic variables (aliases) | Figma Variables in "Semantics" collection | `color/primary`, `space/inset/spacious` |
-| Shadow tokens | Figma Effect Styles | `shadow.elevation200` |
-| Typography tokens | Figma Text Styles | `typography.heading200` |
+| Semantic variables (aliases) | Figma Variables in "Semantics" collection | `color/feedback/success/text`, `space/inset/150` |
+| Shadow tokens | Figma Effect Styles | `shadow.container`, `shadow.modal` |
+| Typography tokens | Figma Text Styles | `typography.bodyMd`, `typography.h1` |
 
 Variables use `/` for Figma's visual grouping hierarchy. Styles use `.` because they appear flat in Figma's style picker.
 
-All variables are pushed to both light and dark modes with identical values (Phase 1), establishing the mode structure for future theme support.
+**Modes.** Each collection declares exactly the modes its variables carry (`src/generators/transformers/FigmaTransformer.ts`, `collectModes()`). Today that is `light` and `dark` for both collections — the DTCG source emits no `wcag` mode entries, so no `wcag` mode is declared. If WCAG-theme emission is added to the DTCG generator, it flows into Figma with no transformer change.
+
+Every variable carries a value in every declared mode:
+
+- **Primitives** are mode-invariant — `light` and `dark` hold the same value.
+- **Semantics** hold the primitive alias in `light`. A token with a dark-theme override (`$extensions.designerpunk.modes.dark`) carries that override's value in `dark`; a token without one mirrors the light alias. Nine semantic color tokens currently differ between modes.
+
+**Known limitation.** A dark override arrives in the DTCG file as a resolved color, not as the overriding primitive's name (`DTCGFormatGenerator` resolves both modes to concrete values). Figma therefore shows a *literal* color in `dark` where `light` shows a variable alias — the value is correct, but the primitive→semantic link is not visible in dark mode. Restoring it requires the DTCG extension to carry the overriding primitive's name. `src/tokens/themes/dark/SemanticOverrides.ts` remains the authoritative source for dark values.
 
 ### Drift Detection
 
@@ -176,7 +183,7 @@ Drift detected: 3 variables have been edited in Figma since last push
 
 Drifted variables:
   - space/300: Expected 24, found 25 (edited in Figma)
-  - color/primary: Expected #B026FF, found #A020E0 (edited in Figma)
+  - color/purple/300: Expected #b322fb, found #a020e0 (edited in Figma)
 
 Resolution options:
   1. Revert changes in Figma, then re-run: npm run figma:push
@@ -459,11 +466,11 @@ Create the Component-Family doc before re-running extraction for better recommen
 **Symptom:** CLI fails with "DTCG token file not found."
 
 **Solution:**
-Run the DTCG generator first:
+Run the token generator first:
 ```bash
-npm run build
+npm run generate:platform-tokens
 ```
-This produces `dist/DesignTokens.dtcg.json` which both push and extraction workflows require.
+This produces `dist/DesignTokens.dtcg.json` (alongside the CSS/Swift/Kotlin outputs), which both push and extraction workflows require. `npm run build` does **not** generate it — `build` compiles TypeScript and bundles the browser/MCP artifacts only.
 
 ---
 

package/governance/Process-Development-Workflow.md

@@ -8,7 +8,7 @@ description: Development workflow and task completion practices — task complet
 # Development Workflow and Task Completion Practices
 
 **Date**: 2025-10-20
-**Last Reviewed**: 2026-07-14
+**Last Reviewed**: 2026-08-12
 **Purpose**: Task completion workflow and git practices for all development work
 **Organization**: process-standard
 **Scope**: cross-project
@@ -32,7 +32,7 @@ description: Development workflow and task completion practices — task complet
 
 **MCP Queries for Detailed Guidance** (query when needed):
 - **Completion Documentation**: `get_section({ path: "completion-documentation-guide", heading: "Two-Document Workflow" })`
-- **Release Detection**: `get_section({ path: "release-management-system", heading: "Release Pipeline Architecture" })`
+- **Releases**: `get_section({ path: "release-management-system", heading: "The Release Recipe" })`
 - **File Organization**: `get_section({ path: "process-file-organization", heading: "Organization Implementation (Conditional Loading)" })`
 - **Hook Operations**: `get_section({ path: "process-hook-operations", heading: "Agent Hook Dependency Chains" })`
 
@@ -109,7 +109,7 @@ get_section({ path: "completion-documentation-guide", heading: "Naming Conventio
 2. **Manually update tasks.md**: Change task status from `[ ]` to `[x]`
 3. **Open the Task PR**: Run `./.kiro/hooks/complete-task.sh "Task Name"` to commit on the task branch, push, and open the PR
 4. **Merge = completion**: Peter merges on green; the merged PR is the verification
-5. **[OPTIONAL]** **Release Analysis**: Run `npm run release:analyze` for detailed local analysis (the standing analysis runs post-merge on `main`)
+5. **[OPTIONAL]** **Release-delta check**: `git log $(git describe --tags --abbrev=0)..main --oneline` shows everything shipped since the last release (squash titles are the changelog spine — see Release Management System)
 
 **When to use this approach:**
 - Quick fixes or minor changes
@@ -246,7 +246,7 @@ get_section({ path: "process-hook-operations", heading: "Quick Reference: Diagno
 
 **Quick Reference - Error Recovery**:
 - If commit fails: Fix issues and re-run the tooling
-- If push fails: Push the TASK BRANCH manually (`git push -u origin <branch>`) — never `main`
+- If push fails: Push the TASK BRANCH manually (`git push -u origin <branch>`)
 - If the PR title is wrong: Edit the PR title on GitHub (squash-merge takes the title as the commit subject)
 
 

package/governance/Process-File-Organization.md

@@ -109,10 +109,7 @@ All files use explicit metadata to declare organizational intent, enabling safe
 **Task**: Associated task number and name (if applicable)
 ```
 
-**Civitas Governance Note:** Steering documents require additional metadata fields (`Last Reviewed`, `Layer`, `Relevant Tasks`, `inclusion` in YAML frontmatter). For the complete steering doc metadata requirements and lifecycle process (creation → review → update → deprecation), see Thurgood's Civitas Steward operational mode or query:
-```
-get_section({ path: ".kiro/steering/Civitas-System-Overview.md", heading: "Governance Processes" })
-```
+**Civitas Governance Note:** Steering documents require additional metadata fields (`Last Reviewed`, `Layer`, `Relevant Tasks`, `inclusion` in YAML frontmatter). For the complete steering doc metadata requirements and lifecycle process (creation → review → update → deprecation), see Thurgood's Civitas Steward operational mode, or the always-loaded Civitas System Overview § "Governance Processes" (an identity doc — never MCP-served, already in every agent's context; no query needed).
 
 #### Optional: `aliases:` frontmatter field (steering docs)
 

package/governance/Process-Hook-Operations.md

@@ -2,7 +2,7 @@
 id: process-hook-operations
 inclusion: manual
 name: Process-Hook-Operations
-description: Agent hook operational guidance — dependency chains, execution order, automatic file organization, troubleshooting, and best practices. Load when debugging hook issues, setting up or modifying hooks, or troubleshooting automation failures. NOTE - Release detection sections are outdated; the release system was rebuilt in Spec 065 as an on-demand CLI tool at src/tools/release/. See Release Management System.md for current architecture.
+description: Agent hook operational guidance — dependency chains, execution order, automatic file organization, troubleshooting, and best practices. Load when debugging hook issues, setting up or modifying hooks, or troubleshooting automation failures. NOTE - Release detection sections are historical; the Spec-065 release CLI was RETIRED 2026-08-12 (Q6 ballot) in favor of the manual release recipe. See Release Management System for current process.
 ---
 
 # Hook Operations Guide
@@ -25,7 +25,7 @@ This document provides detailed operational guidance for working with Kiro agent
 >
 > **2. "Task completion" now means merge (125-A PR-gate).** Since the ratified 125-A workflow, a task is accepted when its unit's **PR is merged** — not when a local status flips. The completion tool is `./.kiro/hooks/complete-task.sh` (opens the PR), which **superseded** the old commit-on-completion tooling. Work reaches `main` only through a merged, branch-protected PR. So the troubleshooting guidance below that frames "direct git commits" as *bypassing hooks* (versus using the `taskStatus` tool) is **Kiro-IDE-specific and predates the branch→PR→merge flow** — under the current workflow, committing and pushing a branch is a *correct, expected* step, not an error to avoid.
 >
-> **3. Release detection here is historical.** As the frontmatter notes, the release system was rebuilt in Spec 065 into an on-demand CLI (`src/tools/release/`); the release-detection-on-task-completion hook content below is retained for Kiro-hook operational history. See [Release Management System](release-management-system) for the current architecture.
+> **3. Release detection here is historical.** The Spec-065 release CLI was itself RETIRED on 2026-08-12 (Q6 ballot: `.kiro/docs/ballots/2026-08-12-q6-release-manager-retirement.md`), and the `release-manager.sh` hook described below was DELETED the same day; this content is retained solely as Kiro-hook operational history. See [Release Management System](release-management-system) for the current release recipe.
 >
 > This doc is preserved for Kiro-runtime hook operations and history. A cross-runtime rework belongs with the 122 agent-generator work (OB-7), not here.
 
@@ -1187,11 +1187,10 @@ Release detection triggers automatically when parent task summary documents are
 - `.kiro/` directory is filtered from Kiro IDE file watching (hooks don't trigger there)
 
 **Quick Reference**:
-- **Summary docs**: `docs/specs/[spec-name]/task-N-summary.md` (triggers hooks)
+- **Summary docs**: `docs/specs/[spec-name]/task-N-summary.md` (release-note source material)
 - **Detailed docs**: `.kiro/specs/[spec-name]/completion/task-N-parent-completion.md` (internal)
-- **Manual trigger**: `./.kiro/hooks/release-manager.sh auto`
 
-**For detailed guidance** on release detection pipeline, troubleshooting, hook debugging, and manual triggers, query Release Management System via MCP:
+**For the current release process** (the manual recipe; the detection hook was deleted 2026-08-12, Q6 ballot), query Release Management System via MCP:
 
 ```
 get_document_full({ path: "release-management-system" })
@@ -1199,8 +1198,8 @@ get_document_full({ path: "release-management-system" })
 
 Or query specific sections:
 ```
-get_section({ path: "release-management-system", heading: "Release Pipeline Architecture" })
-get_section({ path: "release-management-system", heading: "AI Agent Decision Points" })
+get_section({ path: "release-management-system", heading: "The Release Recipe" })
+get_section({ path: "release-management-system", heading: "Discovering What Changed and Why" })
 ```
 
 ---

package/governance/Process-Integration-Methodology.md

@@ -7,7 +7,7 @@ aliases: cross-spec integration dependency management, cross spec integration de
 # Integration Methodology
 
 **Date**: 2026-02-25
-**Last Reviewed**: 2026-02-25
+**Last Reviewed**: 2026-09-19
 **Purpose**: for building 3rd-party integrations in DesignerPunk
 **Organization**: process-standard
 **Scope**: cross-project
@@ -47,7 +47,7 @@ This keeps integrations decoupled from internals, makes the system extensible wi
 
 **Precedents in DesignerPunk:**
 - Rosetta token system → DTCG JSON schema → Figma token sync
-- Stemma component catalog → Component metadata schema → A2UI renderer (in progress)
+- Stemma component catalog → Component metadata schema (Spec 064, complete) → A2UI renderer (not yet started — schema validated against the target; the transformer itself is pending)
 
 ---
 
@@ -124,7 +124,7 @@ Yes. That's why it's versioned and why the governance gate exists. Schema evolut
 
 ## Known Limitations of This Draft
 
-This methodology is based on two implementations (DTCG and agentic UI). It should be treated as a hypothesis until validated against additional integrations. Specific areas likely to need refinement:
+This methodology is based on one full implementation (DTCG: schema + transformer + CLI) and one schema-validated-but-not-yet-transformed target (agentic UI/A2UI — Spec 064 validated the schema against the target; the renderer transformer has not been built). It should be treated as a hypothesis until validated against additional integrations. Specific areas likely to need refinement:
 
 - The right granularity for schema versioning
 - How to handle breaking changes in external tool formats
@@ -138,5 +138,5 @@ This methodology is based on two implementations (DTCG and agentic UI). It shoul
 ## Related Documentation
 
 - `.kiro/docs/agentic-ui-strategy.md` — Strategic context for the agentic UI integration
-- `.kiro/steering/DTCG-Integration-Guide.md` — DTCG format specification (first implementation)
-- `.kiro/steering/Figma-Workflow-Guide.md` — Figma integration workflow (first integration transformer)
+- `governance/DTCG-Integration-Guide.md` — DTCG format specification (first implementation)
+- `governance/Figma-Workflow-Guide.md` — Figma integration workflow (first integration transformer)