aiox-core 5.0.2 → 5.0.3

package/pro/squads/design/docs/dave-malouf-research-validation.md

@@ -0,0 +1,391 @@
+# Dave Malouf DesignOps Frameworks - Research Validation Report
+
+> **Research Date:** 2026-02-02
+> **Agent File:** `/Users/alan/Code/mmos/squads/design/agents/dave-malouf.md`
+> **Research Method:** Web search across multiple sources including O'Reilly, Medium, NN/g, Rosenfeld Media, SlideShare, and industry publications
+
+---
+
+## Executive Summary
+
+The Dave Malouf agent file contains **mostly accurate** information with some important nuances and corrections needed. The core frameworks (Three Lenses, Maturity Model) are **validated as real** but with different terminology than what Dave Malouf originally documented. Some frameworks appear to be **synthesized from industry best practices** rather than explicitly attributed to Malouf.
+
+### Overall Assessment: 7.5/10
+
+| Category | Status |
+|----------|--------|
+| Three Lenses Framework | PARTIALLY VALIDATED - Real but different terminology |
+| Maturity Model (5 Levels) | VALIDATED - Aligns with industry models |
+| Team Topology | INDUSTRY STANDARD - Not uniquely Malouf's |
+| Metrics Stack | VALIDATED - Documented in his work |
+| DesignOps Pillars | SYNTHESIZED - Industry composite |
+| Scaling Phases | VALIDATED - Common in his talks |
+
+---
+
+## Validated Frameworks
+
+### 1. Three Lenses of DesignOps
+
+**Status:** PARTIALLY VALIDATED - Terminology differs
+
+**What the agent file says:**
+- "How We Work" (workflow, tools, processes)
+- "How We Grow" (skills, careers, development)
+- "How We Thrive" (culture, community, well-being)
+
+**What research found:**
+
+Dave Malouf's Three Lenses are documented differently in his original Medium article ["The different lenses of Design Operations"](https://medium.com/amplify-design/the-different-lenses-of-design-operations-c29086cf907f). His three lenses are:
+
+1. **Product Design Lifecycle Management (Program Management)** - Focus on workflow and activity streams, "How can I make my team more successful at getting work done?"
+
+2. **Community Manager** - Practice managers focused on coalescing design practice across embedded designers; people operations focus
+
+3. **Business Operational** - Chief of Staff type role supporting design leadership; most holistic lens
+
+**Important:** The "How We Work, How We Grow, How We Thrive" terminology is actually from the **Nielsen Norman Group DesignOps Framework**, not Dave Malouf:
+- "How we work together" - team organization and collaboration
+- "How we get our work done" - processes and quality
+- "How our work creates impact" - measurement and sharing
+
+**Correction Needed:** The agent conflates NN/g terminology with Malouf's original framework. Consider either:
+- Crediting NN/g for the Work/Grow/Thrive terminology
+- Using Malouf's original lens names (Program Management, Community Manager, Business Operational)
+
+**Sources:**
+- [The different lenses of Design Operations - Medium](https://medium.com/amplify-design/the-different-lenses-of-design-operations-c29086cf907f)
+- [DesignOps 101 - NN/g](https://www.nngroup.com/articles/design-operations-101/)
+
+---
+
+### 2. DesignOps Maturity Model (5 Levels)
+
+**Status:** VALIDATED - Aligns with documented models
+
+**What the agent file says:**
+- Level 1: Ad Hoc
+- Level 2: Emerging
+- Level 3: Defined
+- Level 4: Managed
+- Level 5: Optimized
+
+**What research found:**
+
+Malouf's O'Reilly book ["What Is DesignOps?"](https://www.oreilly.com/library/view/what-is-designops/9781492083023/) explicitly includes a chapter on "DesignOps Maturity Models." The 5-level maturity model is a common framework in operations disciplines (CMM, DevOps maturity, etc.) and the terminology used aligns with industry standards.
+
+The [Nielsen Norman Group research](https://www.nngroup.com/articles/designops-maturity-low/) validates the concept of DesignOps maturity levels and found:
+- Only 10% of respondents at Level 4 or 5
+- Majority at Levels 2 and 3
+- 20% have dedicated DesignOps roles
+
+**Validation:** The 5-level maturity model (Ad Hoc, Emerging, Defined, Managed, Optimized) is consistent with industry standards and Malouf's documented work.
+
+**Sources:**
+- [What Is DesignOps? - O'Reilly](https://www.oreilly.com/library/view/what-is-designops/9781492083023/)
+- [DesignOps Maturity: Low in Most Organizations - NN/g](https://www.nngroup.com/articles/designops-maturity-low/)
+
+---
+
+### 3. Metrics Stack (Output, Outcome, Impact)
+
+**Status:** VALIDATED - Explicitly documented
+
+**What the agent file says:**
+- Output Metrics (what the team produces - activity and deliverables)
+- Outcome Metrics (what the team achieves - quality and effectiveness)
+- Impact Metrics (business value created - strategic contribution)
+
+**What research found:**
+
+Dave Malouf has extensive documented work on DesignOps metrics:
+- [Measuring DesignOps - Medium](https://medium.com/amplify-design/measuring-designops-d9d922c9cfbe)
+- [Measuring & Evaluating Your DesignOps Practice - SlideShare](https://www.slideshare.net/dmalouf/measuring-evaluating-your-designops-practice)
+- [Valuing Design & DesignOps Practice - SlideShare](https://www.slideshare.net/dmalouf/valuing-design-designops-practice)
+
+Key validated concepts:
+- "Vital Signs" - top 3-5 metrics that indicate health
+- Warning against "Vanity Metrics"
+- Cascading use of data: Metric -> Correlation -> Interpretation -> Threshold -> Trend -> Milestone
+- Focus on "success assessment" over ROI
+- Warning: "Outputs valued over outcomes" as anti-pattern
+
+His O'Reilly book includes chapter: "A Metrics Stack"
+
+**Validation:** The Output/Outcome/Impact framework is validated and well-documented in Malouf's work.
+
+**Sources:**
+- [Measuring DesignOps - Medium](https://medium.com/amplify-design/measuring-designops-d9d922c9cfbe)
+- [Assessing Your Current DesignOps Practice - SlideShare](https://www.slideshare.net/slideshow/assessing-your-current-designops-practice-a-heuristic-model-dave-malouf/141118185)
+
+---
+
+### 4. Team Topology (Centralized, Embedded, Federated, Hybrid)
+
+**Status:** INDUSTRY STANDARD - Not uniquely Malouf's
+
+**What research found:**
+
+Team topology models (Centralized, Embedded, Federated, Hybrid) are **industry-wide frameworks** used across design, data, and engineering organizations. Key sources:
+
+- [Team Models for Scaling a Design System - Nathan Curtis/EightShapes](https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0)
+- [Design Team Structures - Superside](https://www.superside.com/blog/design-team)
+- [Design System Governance Models - UX Planet](https://uxplanet.org/design-system-governance-models-f66a97367ad5)
+
+The Salesforce team describes a "Cyclical" model combining Centralized + Federated.
+
+**Assessment:** While Malouf certainly discusses these topologies, they are not his original creation. Attribution should be to "Industry Best Practices" rather than specifically to Malouf.
+
+**Recommendation:** Update agent to say "Dave Malouf / Industry Best Practices" (which it correctly does) but clarify this is a synthesis, not original framework.
+
+---
+
+### 5. Scaling Phases (0-5, 5-15, 15-50, 50-150, 150+)
+
+**Status:** VALIDATED - Consistent with his talks
+
+**What research found:**
+
+The scaling phases concept is consistent with Malouf's documented approach to design team growth. His principle "Scale through systems, not just headcount" is well-documented.
+
+Key principles validated:
+- "Document before you scale - tribal knowledge doesn't scale"
+- "Culture is fragile at scale"
+- "Build the system before hiring"
+- "Hire one level ahead"
+
+**Sources:**
+- [DesignOps Essentials Workshop](https://www.designops.lol/workshop/)
+- [DesignOps Summit presentations](https://rosenfeldmedia.com/designopssummit2023/people/dave-malouf/)
+
+---
+
+## Incorrect or Unverified Claims
+
+### 1. "DesignOps Assembly Co-founder"
+
+**Status:** NOT VERIFIED
+
+**What the agent file says:**
+- "Co-fundou DesignOps Assembly"
+
+**What research found:**
+
+I could not find verification that Dave Malouf co-founded an organization called "DesignOps Assembly." What IS documented:
+- He is a **programming committee member** for the **DesignOps Summit** (Rosenfeld Media)
+- He is a **founder/co-founder of IxDA** (Interaction Design Association)
+- He is a **co-founder of Enterprise UX conference**
+
+The term "DesignOps Assembly" may be a confusion with DesignOps Summit or a community group, but I found no evidence of a formal organization with this name that Malouf co-founded.
+
+**Correction Needed:** Remove or verify the "DesignOps Assembly Co-founder" claim. Update to accurate affiliations:
+- Programming committee for DesignOps Summit
+- Founder of IxDA (Interaction Design Association)
+- Co-founder of Enterprise UX conference
+
+---
+
+### 2. "DesignOps Pillars" (5 Pillars Framework)
+
+**Status:** SYNTHESIZED - Not uniquely Malouf's
+
+**What the agent file says:**
+Five pillars: Workflow Operations, Governance, Tools & Technology, Growth & Development, Community & Culture
+
+**What research found:**
+
+This appears to be a synthesis of multiple DesignOps frameworks rather than a specific Malouf framework. It's a reasonable organizational structure but I found no source attributing these specific "5 Pillars" to Dave Malouf.
+
+**Recommendation:** Either remove specific attribution to Malouf or label as "Synthesized from Industry Best Practices"
+
+---
+
+### 3. "Projects, Process, People" Framework
+
+**Status:** REFERENCED BUT NOT DETAILED
+
+**What research found:**
+
+The O'Reilly book description mentions "frameworks including the DesignOps Canvas and Projects, Process, People" but I could not find detailed documentation of a specific PPP framework from Malouf. The NN/g framework uses "People, Processes, and Morpheus."
+
+**Recommendation:** This needs verification or removal from the agent if claimed as a major framework.
+
+---
+
+## Missing Methodologies
+
+### 1. DesignOps Canvas
+
+**Status:** SHOULD BE ADDED
+
+The DesignOps Canvas is a visual planning tool documented by XPLANE and referenced in Malouf's work. It helps map:
+- Who we are (stakeholders)
+- What we do (value propositions)
+- What constrains us
+
+The canvas process can take 15 minutes to 2 days depending on depth.
+
+**Sources:**
+- [Design Ops Canvas - XPLANE](https://xplane.com/worksheet/design-ops/)
+- [Design Ops Canvas - Mural Template](https://www.mural.co/templates/design-ops-canvas)
+
+---
+
+### 2. IxDA Founding and Community Building
+
+**Status:** SHOULD BE MENTIONED
+
+Dave Malouf is one of the **primary founders** of the Interaction Design Association (IxDA) and served as its first Vice President. He has been a global representative for 15+ years. This is a significant part of his design community legacy that informs his DesignOps community-building philosophy.
+
+**Sources:**
+- [Dave Malouf - Interaction17 - IxDA](https://interaction17.ixda.org/speaker/dave-malouf/index.html)
+- [Dave Malouf - Fast Company](https://www.fastcompany.com/user/dave-malouf)
+
+---
+
+### 3. Assessment Package / Heuristic Model
+
+**Status:** SHOULD BE ADDED
+
+Malouf has published a "Design & Research Operations Assessment Package" on Medium that provides structured assessment methodology.
+
+**Source:**
+- [Design & Research Operations Assessment Package - Medium](https://medium.com/@daveixd/design-operations-assessment-package-1aea3350bcf7)
+
+---
+
+### 4. "Vital Signs" Concept
+
+**Status:** SHOULD BE EMPHASIZED
+
+Beyond general metrics, Malouf specifically promotes the concept of "Vital Signs" - the top 3-5 metrics that tell you something might be wrong. Examples include:
+- Number of UX stories not deployed
+- Attrition rate vs org average
+- Time spent designing/researching
+
+This should be more prominent in the metrics task.
+
+---
+
+### 5. DesignOps Summit Involvement
+
+**Status:** SHOULD BE ADDED
+
+Malouf is part of the **programming committee** for Rosenfeld Media's DesignOps Summit, one of the premier conferences in the field. He has presented at multiple summits (2018, 2023, 2024).
+
+**Sources:**
+- [Dave Malouf - DesignOps Summit 2023](https://rosenfeldmedia.com/designopssummit2023/people/dave-malouf/)
+- [Dave Malouf - DesignOps Summit 2024](https://rosenfeldmedia.com/designops-summit/2024/people/dave-malouf/)
+
+---
+
+## Recommendations for Agent Enrichment
+
+### High Priority Corrections
+
+1. **Fix Three Lenses Attribution**
+   - Current: Presents "How We Work/Grow/Thrive" as Malouf's framework
+   - Reality: This is NN/g terminology; Malouf's lenses are Program Management, Community Manager, Business Operational
+   - Action: Either correct to Malouf's original terminology OR credit NN/g for the Work/Grow/Thrive framework
+
+2. **Remove "DesignOps Assembly Co-founder" claim**
+   - Cannot verify this organization exists
+   - Replace with verified affiliations: IxDA founder, DesignOps Summit programming committee member
+
+3. **Add DesignOps Canvas**
+   - Real tool referenced in his work
+   - Create new task: `designops-canvas-workshop.md`
+
+### Medium Priority Additions
+
+4. **Add Vital Signs concept**
+   - Enhance `designops-metrics-setup.md` with Vital Signs methodology
+   - Include example vital signs from Malouf's presentations
+
+5. **Add Assessment Package methodology**
+   - Reference his published assessment package
+   - Could enhance the maturity assessment task
+
+6. **Emphasize IxDA founding**
+   - Add to authority_proof_arsenal
+   - Shows community-building credentials
+
+### Low Priority Enhancements
+
+7. **Add caveat to Pillars framework**
+   - Mark as "synthesized from industry best practices"
+   - Not a core Malouf original framework
+
+8. **Add DesignOps Summit talks**
+   - Reference specific presentations
+   - Adds credibility and content sources
+
+---
+
+## Updated Authority Proof Arsenal
+
+Based on research, verified accomplishments:
+
+| Claim | Verified | Source |
+|-------|----------|--------|
+| Co-author DesignOps Handbook | YES | Amazon, InVision |
+| Author "What Is DesignOps?" O'Reilly | YES | O'Reilly Library |
+| Founder/Co-founder IxDA | YES | IxDA, Fast Company |
+| Programming Committee DesignOps Summit | YES | Rosenfeld Media |
+| Co-founder Enterprise UX Conference | YES | Intersection Conference bio |
+| VP/Director Design Operations roles | YES | LinkedIn, multiple sources |
+| 25+ years design experience | YES | Multiple bios |
+| Coined term "DesignOps" | CLAIMED | Superside article claims this |
+| DesignOps Assembly co-founder | NOT VERIFIED | No sources found |
+
+---
+
+## Task/Checklist Validation Results
+
+### designops-maturity-assessment.md
+- **Framework accuracy:** 7/10 (terminology correction needed)
+- **Practical utility:** 9/10 (well-structured assessment)
+- **Recommendation:** Update Three Lenses terminology or add attribution note
+
+### design-team-scaling.md
+- **Framework accuracy:** 8/10 (scaling phases validated)
+- **Practical utility:** 9/10 (comprehensive planning tool)
+- **Recommendation:** Add DesignOps Canvas as complementary tool
+
+### designops-maturity-checklist.md
+- **Framework accuracy:** 8/10 (maturity levels validated)
+- **Practical utility:** 9/10 (detailed criteria)
+- **Recommendation:** Add Vital Signs concept
+
+### designops-implementation-workflow.md
+- **Framework accuracy:** 8/10 (well-synthesized)
+- **Practical utility:** 10/10 (excellent end-to-end guide)
+- **Recommendation:** Minor attribution updates only
+
+---
+
+## Conclusion
+
+The Dave Malouf agent and supporting files are **substantially accurate** and represent a solid foundation for DesignOps guidance. The main issues are:
+
+1. **Attribution confusion** between Malouf's original Three Lenses and NN/g's Work/Grow/Thrive framework
+2. **One unverified claim** (DesignOps Assembly co-founder)
+3. **Missing tools** (DesignOps Canvas, Vital Signs emphasis)
+
+The frameworks themselves are practical, well-structured, and aligned with industry best practices. With the corrections noted above, the agent would be highly accurate.
+
+---
+
+## Sources Referenced
+
+- [What Is DesignOps? - O'Reilly](https://www.oreilly.com/library/view/what-is-designops/9781492083023/)
+- [The different lenses of Design Operations - Medium](https://medium.com/amplify-design/the-different-lenses-of-design-operations-c29086cf907f)
+- [Measuring DesignOps - Medium](https://medium.com/amplify-design/measuring-designops-d9d922c9cfbe)
+- [DesignOps 101 - NN/g](https://www.nngroup.com/articles/design-operations-101/)
+- [DesignOps Maturity: Low in Most Organizations - NN/g](https://www.nngroup.com/articles/designops-maturity-low/)
+- [DesignOps Essentials Workshop - DesignOps LOL](https://www.designops.lol/workshop/)
+- [Dave Malouf - DesignOps Summit](https://rosenfeldmedia.com/designopssummit2023/people/dave-malouf/)
+- [DesignOps Handbook - InVision](https://s3.amazonaws.com/designco-web-assets/uploads/2019/05/InVision_DesignOperationsHandbook.pdf)
+- [Team Models for Scaling a Design System - EightShapes](https://medium.com/eightshapes-llc/team-models-for-scaling-a-design-system-2cf9d03be6a0)
+- [Design Ops Canvas - XPLANE](https://xplane.com/worksheet/design-ops/)
+- [Dave Malouf - Interaction17 IxDA](https://interaction17.ixda.org/speaker/dave-malouf/index.html)

package/pro/squads/design/docs/tool-discovery-report.md

@@ -0,0 +1,87 @@
+# Tool Discovery Report - Design Squad
+
+## Metadata
+- Date: 2026-02-17
+- Squad: `design`
+- Domain: design-system
+- Policy: internal-first (`internal-infrastructure-library.yaml`)
+
+## Internal Coverage Summary
+
+### Internal assets validated first
+1. `workspace/domains/design-system/*` (tokens, components, guidelines, MCP handlers)
+2. `squads/design/scripts/design-system/*` (manifest sync, metadata generation/validation, MCP checks)
+3. `squads/design/*` (tasks, checklists, workflows, protocols)
+4. `.aios-core/infrastructure/*` (generic validation and dependency tooling)
+
+### Capabilities fully covered internally
+- DS token catalog and component metadata
+- DS manifest synchronization and drift validation
+- MCP skeleton and MCP tool validation
+- Task/checklist governance validation
+- Accessibility/process governance checklists
+
+### Capabilities partially covered internally
+- Visual regression baseline execution across browsers/cloud
+- Figma file ingestion and live sync at scale
+- Cross-repo design telemetry aggregation
+
+### External-only or enhancement gaps
+1. Managed visual regression service integration
+2. Official design-file API sync hardening (Figma org-level workflows)
+3. Optional cloud artifact storage/CDN for DS assets
+
+## External Discovery Scope (only for real gaps)
+
+### MCP / APIs
+- Figma API / MCP bridge (enhancement for `ds-figma-pipeline`)
+- GitHub API (PR checks for DS governance automation)
+
+### CLI / Tooling
+- Playwright (fallback/enhancement for visual checks)
+- Chromatic or Percy (managed visual regression)
+
+### Libraries
+- Storybook test runner ecosystem (if squad chooses Storybook-first baseline)
+
+## Internal vs External Decisions
+
+### Internal primary (required)
+1. `squads/design/scripts/design-system/sync_design_manifest.cjs`
+2. `squads/design/scripts/design-system/validate_design_manifest_drift.cjs`
+3. `squads/design/scripts/design-system/generate_components_metadata.cjs`
+4. `squads/design/scripts/design-system/validate_components_metadata.cjs`
+5. `squads/design/scripts/design-system/validate_task_checklist_bindings.cjs`
+6. `squads/design/scripts/design-system/validate_mcp_skeleton.cjs`
+7. `squads/design/scripts/design-system/test_mcp_tools.cjs`
+
+### External fallback/enhancement (optional)
+1. Playwright (`ds-visual-regression`) when native baselines are insufficient
+2. Chromatic/Percy for managed diff pipelines
+3. Figma API for enterprise sync scenarios
+
+## Prioritized Recommendations
+
+### Quick Wins
+1. Keep internal scripts as mandatory quality gate before any external tool.
+2. Wire visual regression tasks to prefer local Playwright path first.
+3. Keep Figma integration optional and triggered only by explicit design-file workflows.
+
+### Strategic
+1. Add unified wrapper task to orchestrate metadata + manifest + MCP health in one command.
+2. Add explicit fallback matrix in `ds-visual-regression.md` by cost tier.
+
+### Avoid for now
+1. Replacing internal DS governance pipeline with third-party SaaS.
+2. Adding external tools that duplicate existing internal checks.
+
+## Sources
+- `workspace/domains/design-system/mcp/config.json`
+- `workspace/domains/design-system/metadata/components.json`
+- `workspace/domains/design-system/metadata/tokens/index.json`
+- `squads/design/scripts/design-system/sync_design_manifest.cjs`
+- `squads/design/scripts/design-system/validate_design_manifest_drift.cjs`
+- `squads/design/scripts/design-system/validate_task_checklist_bindings.cjs`
+- `squads/design/scripts/design-system/validate_mcp_skeleton.cjs`
+- `squads/design/config.yaml`
+- `squads/design/README.md`

package/pro/squads/design/docs/tool-integration-plan.md

@@ -0,0 +1,44 @@
+# Tool Integration Plan - Design Squad
+
+## Objective
+Keep Design Squad execution internal-first and integrate external tooling only where internal coverage is partial.
+
+## Wave 1 (Immediate)
+1. Enforce internal quality chain as baseline:
+   - `generate_components_metadata.cjs`
+   - `validate_components_metadata.cjs`
+   - `sync_design_manifest.cjs`
+   - `validate_design_manifest_drift.cjs`
+   - `validate_task_checklist_bindings.cjs`
+   - `validate_mcp_skeleton.cjs`
+2. Require this chain before `ds-*` delivery completion.
+3. Add structural AST baseline for MCP/contracts:
+   - `npm run ast:scan:design-system`
+   - output: `.aios/ast/design-system-structural-model.json`
+
+## Wave 2 (Short-term)
+1. In `ds-visual-regression`, prioritize local Playwright baseline path.
+2. Add explicit cost/benefit gate before adopting managed visual regression SaaS.
+3. Keep `ds-figma-pipeline` external integration optional and capability-driven.
+
+## Wave 3 (Optional)
+1. Introduce managed visual regression provider (Chromatic/Percy) only for teams needing multi-browser cloud snapshots and PR UX.
+2. Introduce enterprise Figma API automation only for orgs with approved app governance.
+
+## Task Wiring (Internal-first)
+- `ds-setup-design-system`: internal scripts + metadata registry
+- `ds-generate-documentation`: local metadata/guideline sources
+- `ds-validate-ai-readiness`: internal MCP health first
+- `ds-visual-regression`: local path first, managed provider as optional enhancement
+- `ds-figma-pipeline`: explicit opt-in integration
+
+## Success Metrics
+1. 100% DS task completions pass internal quality chain.
+2. 0 external tool usage for capabilities already covered internally.
+3. External tools adopted only with documented gap justification.
+
+## Validation Checklist
+- [ ] Internal capability used as primary for each mapped capability
+- [ ] External tools tagged as fallback/enhancement
+- [ ] Cost and access constraints documented before external adoption
+- [ ] `tool-discovery-report.md` and `capability-tools.yaml` synchronized

package/pro/squads/design/protocols/ai-first-governance.md

@@ -0,0 +1,56 @@
+# AI-First Governance Protocol (Design Squad)
+
+## Purpose
+
+Prevent research drift, contradictory claims, and non-canonical references by enforcing behavior at agent/task/workflow level.
+
+## Mandatory Rules
+
+1. Canonical Source Hierarchy
+- `workspace/system/*` for global policy/governance.
+- `workspace/ui/registry.json` for component distribution truth.
+- `workspace/domains/design-system/*` for DS metadata and glossary.
+- `squads/design/data/*` for squad-local knowledge and guides.
+- `docs/research/*` is supporting evidence, never final source of truth.
+
+2. Evidence Contract
+- Every recommendation must include explicit evidence pointers:
+  - artifact path
+  - status (`implemented`, `partial`, `concept`)
+  - date (`YYYY-MM-DD`)
+- If evidence is missing, mark as `assumption` and do not present as fact.
+
+3. Contradiction Guard
+- Never claim completion if any dependency is `partial` or `concept`.
+- If two artifacts conflict, prefer canonical source hierarchy and log conflict.
+
+4. Research-to-Execution Handshake
+- Before proposing execution, map:
+  - `Existing` (what already exists)
+  - `Gap` (what is missing)
+  - `Decision` (what will be done now)
+- Output must include unresolved items explicitly.
+
+5. Language for Status Claims
+- Use only:
+  - `Implemented`
+  - `Partially implemented`
+  - `Concept only`
+- Avoid absolute statements like "100% complete" unless all dependencies are `Implemented`.
+
+## Required Output Block (for agents/tasks)
+
+```yaml
+governance_check:
+  protocol: squads/design/protocols/ai-first-governance.md
+  canonical_sources_checked:
+    - path: ""
+      status: "implemented|partial|concept"
+      date: "YYYY-MM-DD"
+  evidence:
+    - claim: ""
+      source: ""
+  contradictions_found: []
+  unresolved_items: []
+```
+

package/pro/squads/design/protocols/governance-execution-boundary.md

@@ -0,0 +1,59 @@
+# Governance-Execution Boundary Protocol
+
+## Purpose
+
+Define the strict boundary between governance (rule-making) and execution (rule-using) within the Design Squad.
+
+## Principle
+
+> "Governance creates, execution uses."
+
+No execution agent may create new governance artifacts (rules, tokens specs, protocols, checklists). No governance agent should implement components or run audits directly.
+
+## Ownership Matrix
+
+### Governance Agents (Create Rules)
+
+| Agent | Owns | Creates |
+|-------|------|---------|
+| @design-chief | Orchestration, routing | Quality gate definitions, routing rules |
+| @dave-malouf | DesignOps, process | Maturity models, scaling protocols, operational checklists |
+| @dan-mall | Adoption, stakeholder | Adoption frameworks, narrative guidelines |
+
+### Execution Agents (Use Rules)
+
+| Agent | Owns | Uses |
+|-------|------|------|
+| @brad-frost | Architecture, components | Token specs, component matrix, WCAG checklists |
+| @nano-banana-generator | Visual support | Visual spec templates, brand tokens |
+
+## Artifact Ownership
+
+| Artifact Type | Owner (Governance) | Consumer (Execution) |
+|---------------|-------------------|---------------------|
+| Token specifications | @design-chief | @brad-frost |
+| Component matrix | @dave-malouf | @brad-frost |
+| WCAG checklists | @dave-malouf | @brad-frost |
+| Prompt injection templates | @design-chief | All agents |
+| Registry schema | @design-chief | @brad-frost |
+| Handoff protocols | @dave-malouf | All agents |
+| Visual specs | @design-chief | @nano-banana-generator |
+
+## Decision Escalation
+
+1. **Execution agent needs new rule** → Request to @design-chief
+2. **Governance conflict** → @design-chief mediates
+3. **Cross-squad governance** → Follow handoff protocol
+4. **Emergency override** → @design-chief with documented justification
+
+## Enforcement
+
+- Agents MUST check their role before creating artifacts
+- Governance agents MUST NOT implement code directly
+- Execution agents MUST cite governance source for every decision
+- Violations are logged and reviewed in squad retrospectives
+
+## Related
+
+- [AI-First Governance](ai-first-governance.md)
+- [Handoff Protocol](handoff.md)