aiox-core 5.0.4 → 5.0.5

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

@@ -1,391 +0,0 @@
-# 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

@@ -1,87 +0,0 @@
-# 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

@@ -1,44 +0,0 @@
-# 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

@@ -1,56 +0,0 @@
-# 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

@@ -1,59 +0,0 @@
-# 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)