@trespies-source/dojo-genesis-plugin 1.0.0

package/skills/seed-library/seeds/04_agent_connect.md

@@ -0,0 +1,106 @@
+---
+seed_id: 04
+name: Agent Connect
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Agent Connect (Routing-First, Not Swarm-First)
+
+## What It Is
+
+A central hub for managing interactions with multiple agents, handling routing, permissions, and task handoff from a single entry point.
+
+## Why It Matters
+
+"Agent sprawl" creates a patchwork of disconnected tools that no one can fully monitor or govern. Users don't need to know which agent does what—they just ask, and the right agent responds.
+
+## The Pattern
+
+### Single Entry Point
+Users interact with one interface (the Supervisor).
+
+### Routing Logic
+Behind the scenes, route to the right agent based on:
+- Context (what is the user asking?)
+- User role and permissions
+- Task complexity
+- Agent availability
+
+### Task Handoff
+Agents can hand off to other agents when needed:
+- Dojo → Librarian (retrieve seed modules)
+- Dojo → Debugger (resolve conflicts)
+- Dojo → Builder (execute code)
+
+### Permission Management
+Leverage existing permission systems:
+- Groups, projects, workspaces
+- Agents access only what the user has access to
+
+### Prevent Sprawl
+Centralized console for IT to deploy and route all agents.
+
+## Revisit Trigger
+
+When adding new specialized agents (Librarian, Debugger, Referee) or coordinating multi-agent workflows.
+
+## Dojo Application
+
+### Supervisor as Router
+- **Single entry point:** User talks to Supervisor
+- **Routing logic:** Supervisor routes to Dojo, Librarian, Debugger, Builder
+- **Transparent handoff:** "Routing to Librarian to retrieve seed modules..."
+
+### Mode-Based Routing (Within Dojo)
+- **Mirror:** Simple reflection, minimal context
+- **Scout:** Explore routes, recommend paths
+- **Gardener:** Identify strong ideas, prune weak ones
+- **Implementation:** Generate concrete next steps
+
+### Agent Roster
+- **Dojo Agent:** Core thinking partnership (Mirror/Scout/Gardener/Implementation)
+- **Librarian Agent:** Semantic search and retrieval from knowledge base
+- **Debugger Agent:** Resolve conflicting perspectives or logical errors
+- **Builder Agent:** Code generation and execution
+
+### Permission Inheritance
+Agents access only what the user has access to:
+- Google Drive files
+- GitHub repositories
+- Project memory
+
+## What It Refuses
+
+Multi-agent swarm where every agent talks to every other agent (coordination complexity explodes).
+
+## Usage Examples
+
+### Example 1: User Asks "What's the DojoPacket schema?"
+**Routing:** Supervisor → Librarian (retrieve schema) → Dojo (explain)
+**Result:** User gets answer without knowing which agents were involved
+
+### Example 2: User Asks "How should we architect the Workbench?"
+**Routing:** Supervisor → Dojo (Scout mode) → analyze routes → recommend
+**Result:** Dojo provides architectural guidance
+
+### Example 3: User Asks "These perspectives conflict"
+**Routing:** Supervisor → Debugger → resolve conflict → Dojo (present resolution)
+**Result:** Conflict resolved transparently
+
+## Checks
+
+- [ ] Single entry point exists (Supervisor)
+- [ ] Routing logic is explicit and documented
+- [ ] Agents can hand off to other agents
+- [ ] Permissions are inherited from user
+- [ ] Handoffs are transparent to user
+- [ ] No agent-to-agent sprawl (all routing through Supervisor)
+
+## Related Seeds
+
+- **Seed 01 (Three-Tiered Governance):** Tactical tier defines routing logic
+- **Seed 10 (Shared Infrastructure):** Routing logic is shared infrastructure
+- **Seed 09 (Mode-Based Complexity Gating):** Routing within Dojo uses mode selection

package/skills/seed-library/seeds/05_go_live_bundles.md

@@ -0,0 +1,40 @@
+---
+seed_id: 05
+name: Go-Live Bundles
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Go-Live Bundles (Reusable Artifacts)
+
+## What It Is
+Lightweight packages that pair technical artifacts with approval evidence, stored centrally for reuse across similar projects.
+
+## Why It Matters
+Teams spend less time renegotiating approvals when trust is embedded in reusable artifacts.
+
+## The Pattern
+- Bundle contents: Project standards, test results, version rollback plans, approval sign-off, lineage, trace logs
+- Central storage: Reviewers know exactly where to look
+- Reuse: Similar projects reuse bundles without starting governance from scratch
+
+## Revisit Trigger
+When exporting Dojo sessions, sharing work across projects, or building trust through repeatability.
+
+## Dojo Application
+- **DojoPacket Schema:** Standardized export format containing perspectives, mode, artifacts, next move, harness trace
+- **Seed Modules:** Reusable thinking modules with triggers and checks
+- **Workbench Storage:** Central hub for all DojoPackets, accessible across sessions
+- **Copy-Paste Memory Patch:** Compact format for transferring context between sessions
+
+## What It Refuses
+One-off sessions that can't be inspected, reused, or learned from.
+
+## Checks
+- [ ] DojoPacket schema is defined and versioned
+- [ ] Sessions are exportable
+- [ ] Exports include trace logs for transparency
+- [ ] Central storage exists (Workbench)
+- [ ] Reuse is encouraged and tracked

package/skills/seed-library/seeds/06_cost_guard.md

@@ -0,0 +1,40 @@
+---
+seed_id: 06
+name: Cost Guard
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Cost Guard (Budget for the Full Iceberg)
+
+## What It Is
+A comprehensive approach to cost management that accounts for system complexity, context explosion, error handling, validation, integration, oversight, and scope expansion—not just API bills.
+
+## Why It Matters
+"Your API bill is just 10% to 20% of your real AI costs." Production costs are 5-10x pilot costs. This isn't failure—it's the cost of reliability, security, scalability, and usefulness.
+
+## The Pattern
+- **Seven hidden layers:** System complexity, context explosion, error handling, validation overhead, integration complexity, human oversight, scope expansion
+- **Budget multiplier:** 5-10x from pilot to production
+- **Strategies:** Start with hardest scenario, build shared infrastructure, make validation efficient, plan for deliberate expansion
+
+## Revisit Trigger
+When planning new features, estimating costs, or justifying infrastructure investments.
+
+## Dojo Application
+- **Token budgeting:** Warning at 80%, hard stop at 100%, offer to export and start new session
+- **Cost estimation:** Show user estimated token usage before running Scout mode
+- **Usage metadata tracking:** Track tokens/cost per mode, roll up to session level
+- **Cost-aware mode selection:** If budget low, prefer Mirror over Scout; if ample, use full capabilities
+
+## What It Refuses
+Simple mental models that assume AI costs = API bills.
+
+## Checks
+- [ ] Budget accounts for 5-10x multiplier (not just API costs)
+- [ ] Token usage is tracked per session
+- [ ] Users are warned before hitting limits
+- [ ] Cost estimation is shown before expensive operations
+- [ ] Mode selection considers budget constraints

package/skills/seed-library/seeds/07_safety_switch.md

@@ -0,0 +1,41 @@
+---
+seed_id: 07
+name: Safety Switch
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Safety Switch (Fallback to Conservative Mode)
+
+## What It Is
+An automated pattern where the system forces fallback to a conservative operating mode and alerts the user when real-time data drifts outside tolerance.
+
+## Why It Matters
+Most failures start small. A prompt tweak siphons tokens, or an embedding model upgrade shifts outputs. Builder-level controls catch these changes before they propagate.
+
+## The Pattern
+- **Trigger:** Real-time monitoring detects drift outside tolerance band
+- **Action:** Automatically fall back to conservative mode
+- **Alert:** Ping user through appropriate channel (Slack, Teams, or in-app)
+- **Recovery:** User reviews, adjusts, and re-enables full mode
+
+## Revisit Trigger
+When context approaching limit, perspectives conflict, or output feels like "smart fog."
+
+## Dojo Application
+- **Context drift:** If context window > 95% → prune and alert
+- **Perspective conflict:** If perspectives contradict → enter Debugger mode
+- **Output validation:** If output doesn't match expected artifact type → trigger "Press to Reality" module
+- **Cost overrun:** If session cost approaching budget → alert and suggest pruning
+
+## What It Refuses
+Silent failures that compound without user awareness.
+
+## Checks
+- [ ] Drift detection is implemented
+- [ ] Fallback mode is defined
+- [ ] Alerts are sent to user
+- [ ] Recovery path is clear
+- [ ] Failures are logged for analysis

package/skills/seed-library/seeds/08_implicit_perspective_extraction.md

@@ -0,0 +1,41 @@
+---
+seed_id: 08
+name: Implicit Perspective Extraction
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Implicit Perspective Extraction
+
+## What It Is
+Treating constraints, metaphors, and scope boundaries as implicit perspectives rather than requiring explicit "Perspective 1/2/3" format.
+
+## Why It Matters
+Asking for numbered perspectives feels like homework. Users naturally provide perspectives through constraints, goals, and context—we just need to extract them.
+
+## The Pattern
+- **User input:** "no autopilot, artifact-first, 11/10 UI, avoid overbuilding"
+- **Extraction:** Identify 4 implicit perspectives (autonomy constraint, output preference, quality standard, scope boundary)
+- **Reflection:** "Captured 4 perspectives: [list]. Need more?"
+- **Benefit:** Reduces context overhead while maintaining perspective-driven approach
+
+## Revisit Trigger
+When users provide rich context but don't explicitly number perspectives.
+
+## Dojo Application
+- **Constraint extraction:** "no X" → perspective about what to avoid
+- **Metaphor extraction:** "Wikipedia of Prompts" → perspective about collaborative, open-source model
+- **Scope extraction:** "Workbench for prompt engineering" → perspective about target use case
+- **Quality extraction:** "11/10 UI" → perspective about design standards
+
+## What It Refuses
+Rigid perspective format that creates friction.
+
+## Checks
+- [ ] Constraints are extracted as perspectives
+- [ ] Metaphors are extracted as perspectives
+- [ ] Scope boundaries are extracted as perspectives
+- [ ] User is asked to confirm extracted perspectives
+- [ ] Extraction reduces overhead (doesn't add it)

package/skills/seed-library/seeds/09_mode_based_complexity_gating.md

@@ -0,0 +1,46 @@
+---
+seed_id: 09
+name: Mode-Based Complexity Gating
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Mode-Based Complexity Gating (3-Question Test)
+
+## What It Is
+A decision framework for determining whether to use simple or complex modes based on three questions about reasoning, data sources, and adaptive processing.
+
+## Why It Matters
+Don't load unnecessary context for simple queries. Match complexity to need.
+
+## The Pattern
+
+### Three Questions
+1. Does this require reasoning across different inputs?
+2. Does this involve multiple data sources?
+3. Does this need adaptive processing?
+
+### Routing Logic
+- **No to all:** Stay simple (Mirror mode, minimal context)
+- **Yes to some:** Moderate complexity (Scout mode, Tier 1+2 context)
+- **Yes to all:** Full complexity (Scout + Debugger, Tier 1+2+3 context)
+
+## Revisit Trigger
+When selecting mode, loading context, or estimating token usage.
+
+## Dojo Application
+- **Simple query** ("What's the DojoPacket schema?"): Mirror mode, retrieve schema, done
+- **Moderate query** ("How should we architect the Workbench?"): Scout mode, analyze routes, recommend
+- **Complex query** ("Reconcile conflicting perspectives on multi-agent coordination"): Scout + Debugger, deep analysis
+
+## What It Refuses
+One-size-fits-all complexity that wastes tokens on simple queries.
+
+## Checks
+- [ ] Three questions are answered for each query
+- [ ] Mode selection matches complexity
+- [ ] Context loading matches mode
+- [ ] Simple queries use minimal resources
+- [ ] Complex queries get full capabilities

package/skills/seed-library/seeds/10_shared_infrastructure.md

@@ -0,0 +1,75 @@
+---
+seed_id: 10
+name: Shared Infrastructure
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Shared Infrastructure (Build Once, Reuse Everywhere)
+
+## What It Is
+
+Building foundational capabilities (validation frameworks, feedback loops, permission management, monitoring, integrations) as shared services that all agents use.
+
+## Why It Matters
+
+Building the same capabilities for every agent is wasteful. Shared infrastructure makes subsequent agents much easier to deploy. Faster iteration, less duplication.
+
+## The Pattern
+
+### Identify Common Needs
+- Validation frameworks
+- Feedback loops
+- Permission management
+- Monitoring and logging
+- Integrations (APIs, databases)
+
+### Build as Shared Services
+- Central implementation
+- Not per-agent duplication
+- Versioned and documented
+
+### Reuse Across Agents
+- Every new agent inherits the foundation
+- Less time rebuilding, more time on unique capabilities
+
+## Revisit Trigger
+
+When adding new agents, building new capabilities, or noticing duplication.
+
+## Dojo Application
+
+### Workbench
+Shared infrastructure for storage, retrieval, and visualization of DojoPackets.
+
+### Shared Context Bus
+Central store for project spines, seed modules, and contracts.
+
+### Trace Explorer
+Unified trace visualization for all sessions (uses Harness Trace format).
+
+### DojoPacket Schema
+Standardized export format for all sessions.
+
+### Perspective Validation
+Reusable check across all modes (Mirror, Scout, Gardener, Implementation).
+
+## What It Refuses
+
+Per-agent duplication of foundational capabilities.
+
+## Checks
+
+- [ ] Common needs are identified before building per-agent solutions
+- [ ] Shared services are versioned and documented
+- [ ] New agents reuse existing infrastructure
+- [ ] Duplication is actively prevented
+- [ ] Infrastructure investment is justified by reuse
+
+## Related Seeds
+
+- **Seed 01 (Three-Tiered Governance):** Operational tier uses shared instruments
+- **Seed 04 (Agent Connect):** Routing logic is shared infrastructure
+- **Seed 06 (Cost Guard):** Shared infrastructure reduces per-agent costs

package/skills/seed-library/seeds/11_voice_before_structure.md

@@ -0,0 +1,74 @@
+---
+seed_id: 11
+name: Voice Before Structure
+version: 1.0
+created: 2026-02-12
+source: Marketplace Build Sprint
+status: experimental
+---
+
+# Voice Before Structure
+
+## What It Is
+
+A practice of reading the project's design language and philosophy documents before writing any structural artifacts — manifests, descriptions, READMEs, schemas.
+
+## Why It Matters
+
+Structure without voice produces generic output. Manifests written without philosophy grounding had to be rewritten. Voice informs structure — the descriptions, the naming, the framing all change when you understand the project's philosophy. The difference between "strategic planning tools" and "begin with a tension, not a solution" is the difference between cargo and cargo with identity.
+
+## The Pattern
+
+### Before Writing Structure
+1. Identify the project's philosophy documents (README, design language, reflections, founding documents)
+2. Read 2-3 of them — enough to hear the voice, not so many that execution stalls
+3. Let the voice inform naming, descriptions, and framing
+4. Check: would someone who knows this project recognize these descriptions as belonging here?
+
+### The Test
+Read the structural artifact aloud. Does it sound like it came from this project, or could it belong to any project? If the latter, you haven't grounded in the voice yet.
+
+## Revisit Trigger
+
+- Starting any ecosystem-level work (plugin builds, marketplace setup, documentation overhauls)
+- Creating manifests, READMEs, or descriptions for a project with established design language
+- When the word "description" appears in a template
+- When writing metadata that carries the project's identity
+
+## Dojo Application
+
+### How Dojo Uses This Pattern
+- Marketplace manifests carry growth language ("planted, cultivated, harvested") because the philosophy documents were read first
+- Plugin descriptions use nature metaphors and governance principles because the Design Language was grounded before structure was written
+- Cruz's mid-sprint interrupt — "before you write the manifest make sure you ground yourself in the philosophy" — was the single highest-leverage moment of the sprint
+
+### In Practice
+Make "read the design language" Step 0 of any ecosystem-level work. Encode this in handoff templates and commission documents.
+
+## What It Refuses
+
+Writing structural artifacts in a vacuum. Treating manifests, descriptions, and READMEs as boilerplate to be filled in generically.
+
+## Usage Examples
+
+### Example 1: Plugin Marketplace Build
+**Without Voice:** Plugin description reads "A collection of strategic planning tools."
+**With Voice:** Plugin description reads "Begin with a tension, not a solution. Scout multiple routes, align on vision, and only then commit to a plan."
+
+### Example 2: Documentation Overhaul
+**Without Voice:** Section headings are functional ("Getting Started", "Configuration", "API Reference").
+**With Voice:** Section headings carry identity — framed in the project's own language and metaphors.
+
+## Checks
+
+- [ ] Philosophy documents identified before writing began
+- [ ] 2-3 documents read (not just skimmed)
+- [ ] Structural artifacts carry the project's voice, not generic language
+- [ ] Someone familiar with the project would recognize the voice
+- [ ] Execution was not delayed indefinitely by reading everything
+
+## Related Seeds
+
+- **Seed 05 (Go-Live Bundles):** Bundles should carry voice too — export artifacts are identity-carrying
+- **Seed 08 (Implicit Perspective Extraction):** Both seeds are about drawing richness from context rather than imposing generic structure
+- **Seed 13 (Granular Visibility):** Both emerged from the same sprint; together they represent "ground first, then track visibly"

package/skills/seed-library/seeds/12_pointer_directories.md

@@ -0,0 +1,81 @@
+---
+seed_id: 12
+name: Pointer Directories
+version: 1.0
+created: 2026-02-12
+source: Marketplace Build Sprint
+status: experimental
+---
+
+# Pointer Directories
+
+## What It Is
+
+Empty directories in a project registry are often intentional references to content that lives elsewhere — not missing content. The instinct to "fill the gap" can produce unnecessary duplication. Understanding why something is empty is more valuable than filling it.
+
+## Why It Matters
+
+During the marketplace build, 7 skill directories appeared to be missing SKILL.md files. The instinct was to create new content for each. Investigation revealed they were intentional pointers — 4 referenced Anthropic Cowork platform skills (docx, pdf, pptx, xlsx), and 3 referenced Dojo Genesis skills installed at the system level (specification-writer, zenflow-prompt-writer, project-exploration). Understanding the provenance eliminated unnecessary work and produced a more accurate changelog.
+
+## The Pattern
+
+### Before Creating Content for Empty Directories
+1. Ask: "Is this directory a pointer or a gap?"
+2. Check if the content exists elsewhere — installed system, platform, external dependency, parent repository
+3. If it's a pointer, copy from the authoritative source rather than writing from scratch
+4. Document the provenance in the changelog
+
+### The Provenance Model
+In any registry system, content may live at multiple levels:
+- **Source:** The original authoring location (e.g., `dojo-genesis/skills/`)
+- **System-installed:** Deployed to runtime (e.g., `.skills/skills/`)
+- **Platform:** Provided by the host platform (e.g., Cowork system skills)
+
+An empty directory at one level doesn't mean the content is missing — it may live at another level by design.
+
+## Revisit Trigger
+
+- Encountering empty directories during an audit or reorganization
+- Finding skills, components, or modules that exist in a registry but have no local content
+- When a coverage metric shows "gaps" that nobody has complained about
+- Before creating content to "fill" something that feels incomplete
+
+## Dojo Application
+
+### How Dojo Uses This Pattern
+- The 49-skill marketplace achieved 100% SKILL.md coverage by copying from authoritative sources rather than writing new content
+- The CHANGELOG documents each skill's provenance (platform vs. system-installed vs. source)
+- Empty directories in `dojo-genesis/skills/` are understood as part of the architecture, not defects
+
+### The Decision
+Rather than writing 7 new SKILL.md files from scratch, the sprint copied content from where it actually lived. This preserved quality, maintained consistency with the Cowork platform, and avoided divergence between the marketplace copy and the authoritative source.
+
+## What It Refuses
+
+- Automatically creating content for every empty directory without investigating why it's empty
+- Treating coverage metrics as the only measure of completeness
+- Duplicating content when a reference to the authoritative source would be more accurate
+
+## Usage Examples
+
+### Example 1: Marketplace Build
+**Without Seed:** Create 7 new SKILL.md files from scratch. Result: divergent content, maintenance burden, potential inaccuracies.
+**With Seed:** Investigate provenance, discover pointers, copy from authoritative sources. Result: consistent content, clear provenance, no maintenance drift.
+
+### Example 2: Monorepo Audit
+**Without Seed:** Report 15 packages as "missing documentation." File bugs for all 15.
+**With Seed:** Check if packages reference docs from a shared documentation system or parent repo. Report only the genuine gaps.
+
+## Checks
+
+- [ ] Empty directories investigated before content creation
+- [ ] Provenance checked at all levels (source, system, platform)
+- [ ] Authoritative source identified and content copied (not rewritten)
+- [ ] Provenance documented in changelog or README
+- [ ] Genuine gaps distinguished from intentional pointers
+
+## Related Seeds
+
+- **Seed 10 (Shared Infrastructure):** Both patterns recognize that content may be shared across multiple consumers
+- **Seed 02 (Harness Trace):** Tracing the provenance of a pointer is analogous to tracing a decision path
+- **Seed 11 (Voice Before Structure):** Both emerged from the same sprint; voice informs what to write, pointers inform what not to write

package/skills/seed-library/seeds/13_granular_visibility.md

@@ -0,0 +1,82 @@
+---
+seed_id: 13
+name: Granular Visibility
+version: 1.0
+created: 2026-02-12
+source: Marketplace Build Sprint
+status: experimental
+---
+
+# Granular Visibility
+
+## What It Is
+
+On complex multi-phase work, maintain granular progress tracking that serves the user's need for visibility — not the agent's preference for tidiness. The user steers the work. Compressed progress updates remove their ability to see what's happening, what's next, and what might need course correction.
+
+## Why It Matters
+
+During the marketplace build, the todo list was compressed from 17 items to 8 mid-sprint. The user explicitly asked to "return to the more complex and complete version." The instinct to simplify felt helpful to the agent but removed the user's ability to monitor and steer. Visibility enables trust. Trust enables delegation. Delegation enables velocity.
+
+## The Pattern
+
+### Progress Tracking Principles
+1. Create granular items from the start — one per discrete deliverable or decision point, not one per phase
+2. Update status in real-time as items complete
+3. If the list feels long, that's a signal the work is complex — the list is accurate, not bloated
+4. Let the user request compression if they want it — don't pre-compress for them
+
+### The Chain
+Granular visibility → User sees progress → User can steer → User trusts the process → User delegates more → Agent moves faster → Better outcomes
+
+### The Anti-Pattern
+Compressed visibility → User can't see progress → User interrupts to check status → Agent stops to explain → Both lose momentum → Trust erodes
+
+## Revisit Trigger
+
+- Any task with more than 10 discrete steps
+- Multi-phase work spanning multiple tool calls or agents
+- When the instinct arises to "simplify" or "clean up" progress tracking
+- When working with a user who values steering over delegation
+
+## Dojo Application
+
+### How Dojo Uses This Pattern
+- The marketplace build maintained a 24-item todo list across 4 phases
+- Each SKILL.md update, each verification step, each version bump had its own line item
+- The user could see at a glance: what's done, what's in progress, what's next
+- Course corrections (like the philosophy grounding interrupt) were possible because the user could see where the work was heading
+
+### The Rule
+Default to granular. Let the user ask for compression, not the other way around. The user's need for visibility outweighs the agent's preference for tidiness.
+
+## What It Refuses
+
+- Pre-compressing progress updates for aesthetic reasons
+- Assuming the user wants less detail
+- Treating "long todo list" as a problem to solve rather than an accurate reflection of complex work
+- Simplifying for the agent's convenience at the cost of the user's steering ability
+
+## Usage Examples
+
+### Example 1: Marketplace Build Sprint
+**Without Seed:** 8-item todo list: "Phase 1: Reorganize", "Phase 2: Improve", etc. User can't see which of 49 skills have been updated.
+**With Seed:** 24-item list: individual items for trigger phrases, version bumps, verification, each plugin's README. User can steer at any point.
+
+### Example 2: Documentation Overhaul
+**Without Seed:** "Update all docs" as one item. Done when done.
+**With Seed:** Separate items for each document group, with progress visible throughout. User notices a section was missed and corrects before completion.
+
+## Checks
+
+- [ ] Todo items represent discrete deliverables or decision points (not phases)
+- [ ] Status is updated in real-time
+- [ ] User has not been asked to accept a compressed view
+- [ ] The list length matches the work complexity
+- [ ] Truly trivial sub-steps (like "read file X") are not individually tracked
+
+## Related Seeds
+
+- **Seed 02 (Harness Trace):** Both seeds are about transparency — traces for decisions, visibility for progress
+- **Seed 01 (Three-Tiered Governance):** Granular visibility is operational governance applied to progress tracking
+- **Seed 11 (Voice Before Structure):** Both emerged from the same sprint; together they represent the mindfulness axis of the work
+- **Meta-Seed (Governance Multiplies Velocity):** Granular visibility is governance that accelerates rather than slows — the user steers faster when they can see

package/skills/seed-library/seeds/meta_governance_multiplies_velocity.md

@@ -0,0 +1,43 @@
+---
+seed_id: meta
+name: Governance Multiplies Velocity
+version: 1.0
+created: 2026-01-12
+source: Dataiku Research
+status: active
+---
+
+# Governance Multiplies Velocity (Meta-Seed)
+
+## What It Is
+The counterintuitive truth that stronger governance accelerates delivery, not slows it.
+
+## Why It Matters
+Organizations that embed AI governance principles shave a full year or more off time-to-value. Trust accelerates delivery because teams spend less time renegotiating approvals.
+
+## The Pattern
+- **Clear contracts** (DojoPacket schema) enable faster reuse
+- **Visible traces** (harness logs) build trust faster
+- **Automated checks** (perspective validation) prevent rework
+- **Shared infrastructure** reduces duplication
+- **Reusable artifacts** (seed modules) compound learning
+
+## Revisit Trigger
+When governance feels like friction or when trust is lacking.
+
+## Dojo Application
+- **Non-negotiable refusals:** Build trust through consistency
+- **Harness trace:** Build trust through transparency
+- **DojoPacket export:** Build trust through inspectability
+- **Seed modules:** Build trust through reusability
+- **Mode contracts:** Build trust through predictability
+
+## What It Refuses
+The false dichotomy between speed and governance.
+
+## Checks
+- [ ] Governance is seen as enabler, not blocker
+- [ ] Trust is measured and tracked
+- [ ] Delivery velocity increases with governance maturity
+- [ ] Teams spend less time renegotiating
+- [ ] Reuse is the norm, not the exception