arkaos 2.55.0 → 2.57.0

package/VERSION

@@ -1 +1 @@
-2.55.0
+2.57.0

package/departments/kb/skills/persona-build/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: kb/persona-build
 description: >
-  Build a persona from content: extract DISC, Enneagram, Big Five, MBTI, mental models.
+  Build or refine a callable persona from KB content. Extracts beliefs, voice
+  signature, expertise domains, decision patterns, and the 4-framework
+  behavioral DNA (DISC + Enneagram + Big Five + MBTI). Produces a callable
+  advisor YAML.
 allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
 ---
 
@@ -21,12 +24,188 @@ does not replace the vault.
 
 # Persona Build — `/kb persona <name>`
 
-> **Agent:** Clara (Knowledge Director) | **Framework:** Persona DNA Framework (4 frameworks)
+> **Lead:** Clara (Knowledge Director) | **Cross-dept:** Pedro (Research Analyst) + Eduardo (Copy Director) | **Frameworks:** Persona DNA (DISC + Enneagram + Big Five + MBTI) + Voice Pattern Extraction + Source-Cited Belief Inventory
 
-## What It Does
+## What ships
 
-Build a persona from content: extract DISC, Enneagram, Big Five, MBTI, mental models.
+A production callable persona in 7 deliverables:
 
-## Output
+1. **Source inventory** — every input file/URL tagged by type + date
+2. **Belief inventory** — core beliefs with source citations per belief
+3. **Voice pattern** — N-gram signature + recurring phrases + structural rhythm + no-go words
+4. **Expertise map** — deep / surface / no-go domain classification
+5. **Decision pattern catalogue** — characteristic evaluation patterns with cited examples
+6. **4-framework Behavioral DNA** — DISC + Enneagram + Big Five + MBTI scored from evidence
+7. **Callable advisor YAML** — ready to invoke from any /arka command
 
-Persona profile in Obsidian with full behavioral DNA and mental model catalog
+## Source Inventory Format
+
+Every persona source is tagged:
+
+```yaml
+sources:
+  - id: source-001
+    url: <url or local path>
+    type: talk | interview | written | social | podcast | book
+    date: YYYY-MM-DD
+    weight: high | medium | low   # based on persona's intent + content depth
+    summary: <one-line description>
+```
+
+Minimum source diversity for a credible persona: 5 sources across at least 3 types, spanning at least 6 months of date range.
+
+## Belief Inventory (cited extraction)
+
+A belief is a claim the persona has made consistently across multiple sources. Format:
+
+```yaml
+beliefs:
+  - statement: "<the belief in plain language>"
+    strength: load-bearing | supporting | aspirational
+    citations:
+      - source: source-003
+        quote: "<verbatim>"
+      - source: source-007
+        quote: "<verbatim>"
+    counter-position: <what this belief rejects, if explicit>
+```
+
+Beliefs without 2+ citations are dropped — single-mention statements are not strong enough to be a persona trait. Load-bearing beliefs (the ones the persona cannot abandon without becoming someone else) require 4+ citations.
+
+## Voice Pattern Extraction
+
+The voice signature has 4 layers:
+
+### 1. Lexical signature (vocabulary)
+- **Proprietary terms** — words the persona uses unusually often or coined
+- **Forbidden words** — words the persona never uses (often due to belief)
+- **N-gram patterns** — 2-3 word phrases that recur in characteristic positions
+
+### 2. Syntactic signature (sentence structure)
+- Average sentence length
+- Clause complexity (simple / compound / complex preferred)
+- Sentence-opening patterns (3-5 typical openers)
+- Sentence-closing patterns (3-5 typical closes)
+
+### 3. Rhetorical signature (argumentation pattern)
+- Preferred argument structure (claim-evidence-warrant vs Socratic vs analogy-driven vs storytelling)
+- Use of qualifiers (hedged vs declarative)
+- Use of self-disclosure (front-loaded / withheld / never)
+
+### 4. Tonal signature (emotional register)
+- Default warmth (cold / neutral / warm)
+- Default certainty (hedged / measured / declarative)
+- Humor pattern (none / wry / direct / self-deprecating)
+- Confrontation pattern (avoided / oblique / direct)
+
+Each layer must be derivable from at least 3 source examples.
+
+## Expertise Map
+
+Three concentric domains:
+
+```yaml
+expertise:
+  deep:
+    - domain: <area>
+      evidence: <which sources prove deep expertise>
+      sub-domains: [<list>]
+  surface:
+    - domain: <area>
+      evidence: <touched briefly in sources>
+  no-go:
+    - domain: <area>
+      reason: <why this persona refuses to opine here>
+      citation: <source where they explicitly declined>
+```
+
+A persona that opines on everything has no persona — the no-go list is as important as the deep list.
+
+## Decision Patterns
+
+Extract characteristic decision-making patterns with cited examples:
+
+```yaml
+decision_patterns:
+  - pattern: "<named pattern>"
+    description: <plain language>
+    example:
+      context: <the decision>
+      reasoning: <how they thought about it>
+      source: <cited>
+    inverse: <what they would NOT do in that context>
+```
+
+Examples of named patterns: "Optimises for irreversibility avoidance", "Prefers small-bet portfolio over big-bet concentration", "Refuses to publish until idea has been steel-manned".
+
+## Behavioral DNA (4-framework score)
+
+Score each framework based on source evidence, NOT speculation. Each scored dimension cites the source.
+
+### DISC profile
+- D (Dominance): 0-100 with source evidence
+- I (Influence): 0-100 with source evidence
+- S (Steadiness): 0-100 with source evidence
+- C (Conscientiousness): 0-100 with source evidence
+- Type: Dominant pair (D+C, S+C, I+D, etc.)
+
+### Enneagram
+- Type: 1-9
+- Wing: w-X
+- Health level evidence: 1-9 from sources
+- Core motivation cited: <source>
+- Core fear cited: <source>
+
+### Big Five (OCEAN)
+- Openness: 0-100
+- Conscientiousness: 0-100
+- Extraversion: 0-100
+- Agreeableness: 0-100
+- Neuroticism: 0-100
+Each with 2+ source citations.
+
+### MBTI
+- 4 letters with cited preference per letter
+- Cognitive function stack derivation
+
+## Callable Advisor YAML (production output)
+
+The final deliverable is a YAML that any /arka command can load:
+
+```yaml
+id: <persona-slug>
+name: <display name>
+canonical_reference: <real human, redacted if confidentiality requires>
+expertise_domains_deep: [<list>]
+expertise_domains_surface: [<list>]
+expertise_domains_nogo: [<list>]
+voice_pattern:
+  lexical_signature_path: <obsidian link>
+  syntactic_signature_path: <obsidian link>
+  rhetorical_pattern: <name>
+  tonal_signature: <warmth + certainty + humor + confrontation>
+beliefs:
+  load_bearing: [<list with source IDs>]
+  supporting: [<list with source IDs>]
+decision_patterns: [<named patterns>]
+behavioral_dna:
+  disc: { D: X, I: X, S: X, C: X }
+  enneagram: { type: X, wing: X }
+  big_five: { O: X, C: X, E: X, A: X, N: X }
+  mbti: <4 letters>
+invocation_examples:
+  - context: <when to call this persona>
+    expected_output: <what this persona would produce>
+```
+
+## Common Failure Modes
+
+1. **Persona without no-go domains** — a persona that opines on everything reads as a generic AI, not a specific human
+2. **Beliefs without citations** — single-source claims are not beliefs, they're moments. Drop them
+3. **Voice signature copied from prose, not patterns** — describing the voice ("authoritative", "direct") doesn't replicate it. Extract structural N-grams
+4. **DNA scored from speculation** — every behavioral score must trace to source evidence
+5. **Persona that's actually a category** — "Tech founder" is not a persona, "Paul Graham" is. Personas need a named reference human
+
+## Output → Obsidian: `WizardingCode/Personas/<name>/`
+
+Delivers: source inventory + belief inventory (cited) + voice pattern (4 layers) + expertise map (deep/surface/no-go) + decision patterns + 4-framework DNA + callable advisor YAML + invocation examples.

package/departments/kb/workflows/persona.yaml

@@ -0,0 +1,131 @@
+id: kb-persona
+name: Persona Build
+description: Build or refine a persona from the KB — extract beliefs, voice, expertise, decision patterns; produce a callable advisor profile
+department: kb
+tier: enterprise
+command: "/kb persona"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Persona Brief
+    description: Define who the persona represents — real human reference, target use cases, advisor context
+    agents:
+      - agent_id: kb-curator-clara
+        role: Frame the persona — named reference human, role, decision domains, advisor use cases
+    gate:
+      type: user_approval
+      description: User confirms persona scope and reference
+
+  - id: source-gathering
+    name: Source Gathering
+    description: Collect all KB sources for the persona — talks, interviews, writings, transcripts, social posts
+    agents:
+      - agent_id: kb-curator-clara
+        role: KB source enumeration with date range and source-type tagging
+    gate:
+      type: user_approval
+      description: User approves source set
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Personas/Sources/"
+        description: Source inventory per persona
+
+  - id: belief-extraction
+    name: Belief & Frame Extraction
+    description: Extract the persona's core beliefs, mental models, and recurring frames from sources
+    agents:
+      - agent_id: kb-curator-clara
+        role: Belief extraction with source citation per belief
+      - agent_id: research-analyst-pedro
+        role: Pattern detection across sources — what recurs, what's load-bearing
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves belief inventory
+
+  - id: voice-pattern
+    name: Voice & Vocabulary Pattern
+    description: Map the persona's voice — sentence rhythm, vocabulary signature, characteristic phrases, no-go words
+    agents:
+      - agent_id: kb-curator-clara
+        role: Voice analysis with N-gram patterns + recurring phrases + structural signatures
+      - agent_id: copy-director-eduardo
+        role: Voice replication test — would a current reader recognise this voice?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves voice pattern
+
+  - id: expertise-domains
+    name: Expertise Domains
+    description: Map what the persona knows deeply vs surface-level vs explicitly avoids
+    agents:
+      - agent_id: kb-curator-clara
+        role: Expertise mapping — 3-5 deep domains, 5-10 surface domains, explicit no-go domains
+    gate:
+      type: user_approval
+      description: User approves expertise map
+
+  - id: decision-patterns
+    name: Decision Patterns
+    description: Extract characteristic decision patterns — how the persona evaluates trade-offs, what evidence they accept, what they refuse
+    agents:
+      - agent_id: kb-curator-clara
+        role: Decision pattern extraction with example decisions cited from sources
+    gate:
+      type: user_approval
+      description: User approves decision pattern map
+
+  - id: advisor-profile
+    name: Callable Advisor Profile
+    description: Compile the persona into a callable advisor YAML — voice + beliefs + expertise + decision patterns + bio
+    agents:
+      - agent_id: kb-curator-clara
+        role: Advisor profile YAML compilation
+    gate:
+      type: user_approval
+      description: User approves callable advisor profile
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the persona — would the reference human recognise themselves? Are beliefs cited? Are no-go domains enforceable?
+    agents:
+      - agent_id: kb-curator-clara
+        role: Self-test — generate 3 sample advisor outputs and verify voice + beliefs
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Voice fidelity, vocabulary signature accuracy, no-clichés
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Source citation integrity, expertise domain boundaries, decision pattern falsifiability
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Persona Package Delivery
+    description: Compile the persona package — sources + beliefs + voice + expertise + decisions + advisor YAML
+    agents:
+      - agent_id: kb-curator-clara
+        role: Full persona package + advisor invocation guide
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Personas/"
+        description: Complete persona — sources + beliefs (cited) + voice pattern + expertise map + decision patterns + advisor YAML + invocation guide

package/departments/pm/skills/roadmap-build/SKILL.md

@@ -1,7 +1,10 @@
 ---
 name: pm/roadmap-build
 description: >
-  Product roadmap: outcome-based (not feature-based), NOW/NEXT/LATER format.
+  Outcome-driven product roadmap — North Star + outcome tree + 3-horizon
+  map (Now/Next/Later) + bet selection + capacity allocation + audience-
+  specific communication. Replaces feature-list roadmaps with measurable
+  bets.
 allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
 ---
 
@@ -21,12 +24,114 @@ does not replace the vault.
 
 # Roadmap Build — `/pm roadmap <product>`
 
-> **Agent:** Carolina (Product Manager) | **Framework:** Outcome-Driven Roadmaps (Cagan)
+> **Lead:** Carolina (Product Manager) | **Cross-dept:** Tomas (Strategy) + Francisca (Tech) + Eduardo (Copy) | **Frameworks:** Marty Cagan Outcome-Driven Roadmaps + Three Horizons + Bets vs Promises
 
-## What It Does
+## What ships
 
-Product roadmap: outcome-based (not feature-based), NOW/NEXT/LATER format.
+A production roadmap in 6 deliverables:
 
-## Output
+1. **North Star metric** — the one number the product team optimises
+2. **Outcome tree** — 3-5 outcomes that decompose the North Star, each measurable
+3. **Three-horizon map** — Now (committed) / Next (validating) / Later (exploring)
+4. **Bet selection** — 1-3 bets per outcome with hypothesis + success criteria
+5. **Capacity allocation** — team mapping with fixed-time vs fixed-scope policy
+6. **Per-audience communication** — exec / engineering / sales / customer views
 
-Product roadmap with outcomes, time horizons, and success metrics
+## North Star Metric (the math constraint)
+
+The North Star is **one number**, not a dashboard. Properties of a valid North Star:
+
+- **Lagging enough** — represents customer value, not just activity. "Active users" is leading; "Active users who completed the core action 3 times in 7 days" is closer to value.
+- **Leading enough** — moves on quarterly cadence, not yearly. Revenue is too lagging for product team decisions.
+- **Causal to revenue** — a working North Star explains revenue movement with 90-day lag.
+- **Movable by product** — the team can affect it with shipped work, not just marketing or sales.
+
+Examples that work: Airbnb's "Nights Booked", Slack's "Messages sent in active teams", Stripe's "Payment volume processed".
+
+Examples that fail: NPS (too lagging, hard to move), "Number of users" (vanity), "Engineering velocity" (internal, not customer).
+
+## Outcome Tree (decomposition)
+
+Decompose the North Star into 3-5 outcomes. Each outcome is a number, not a description. The math should hold: if all outcomes move, the North Star moves.
+
+```
+NORTH STAR: Active teams using core feature 3+ times/week
+
+  OUTCOME 1: Trial-to-paid conversion rate (currently 6%, target 12%)
+    BET 1.1: Improve onboarding completion rate
+    BET 1.2: Reduce time-to-first-value
+
+  OUTCOME 2: Weekly active rate per paid team (currently 60%, target 80%)
+    BET 2.1: Habit loop in core workflow
+    BET 2.2: Notification system that drives return
+
+  OUTCOME 3: Feature adoption depth (currently 1.4 features per active team, target 2.5)
+    BET 3.1: Discoverability improvements
+    BET 3.2: Cross-feature integration
+
+  OUTCOME 4: Team-to-team expansion (currently 5% of paid teams expand, target 15%)
+    BET 4.1: Multi-team workflow
+    BET 4.2: Admin tools for organisations
+```
+
+Each outcome must answer: *if this number moves by X, does the North Star move by Y? Show the math.*
+
+## Three Horizons (commitment-by-horizon)
+
+| Horizon | Time | Commitment | Communication |
+|---|---|---|---|
+| **Now** | Current quarter | High — committed, in flight | Specific bets named, in-progress |
+| **Next** | Following quarter | Medium — validating, scoped | Bets shaped, not yet started |
+| **Later** | 2-4 quarters out | Low — exploring, hypothesis-stage | Directional only, "we believe X matters" |
+
+The rule: **the further out, the lower the commitment**. Roadmaps that promise specific Q4 features at Q1 confidence lose all credibility when they slip.
+
+## Bets vs Promises (Shape Up alignment)
+
+A bet has:
+- **Appetite** (time budget, fixed)
+- **Hypothesis** (if we ship X, Y will change)
+- **Success criteria** (Y moves by Z)
+- **Failure criteria** (if Y doesn't move by Z by date W, we stop)
+
+A promise has:
+- Date
+- Specific deliverable
+- No falsification path
+
+Roadmaps with promises are commitments to specific outputs. Roadmaps with bets are commitments to specific *learning*. Bets compound; promises break.
+
+## Capacity Allocation Policy
+
+Each bet has a policy on what's fixed vs variable:
+
+- **Fixed time, variable scope** (Shape Up default) — appetite is the constraint. Scope is whatever fits.
+- **Fixed scope, variable time** (legacy waterfall) — only use when externally constrained (regulatory, contractual).
+- **Fixed both** — invalid. Pick one. Trying to fix both produces death marches.
+
+Typical mix for a product team: 60% Fixed Time (Now horizon), 30% Discovery (Next horizon), 10% Exploration (Later horizon, hypothesis testing).
+
+## Per-Audience Communication
+
+The same roadmap presents differently to different audiences. Same data, different framing.
+
+| Audience | What they see | What's redacted |
+|---|---|---|
+| **Exec / Board** | Outcomes + North Star projection + bet portfolio | Specific feature lists, internal team names |
+| **Engineering** | Bets with appetite + technical context | Sales-speak, customer logo lists |
+| **Sales / GTM** | What's shipping + when (Now horizon only) | Discovery hypotheses, failed bets |
+| **Customer-facing** | Public-safe directional ("We're investing in X") | Specifics, dates, anything we might not ship |
+
+The mistake: showing customers the same roadmap as engineering. Customers see dates and treat them as promises; engineering sees dates and treats them as appetite. Different commitment levels need different framings.
+
+## Common Failure Modes
+
+1. **Feature roadmap disguised as outcome roadmap** — list of features renamed "outcomes". The test: can you measure success without shipping a specific feature? If no, it's a feature roadmap.
+2. **North Star that doesn't move** — picking a metric that takes 6+ months to respond. The team can't tell if work is working.
+3. **Promising the Later horizon** — exposing speculative quarters as commitments. When they slip, the team loses credibility on the Now horizon too.
+4. **No falsification on bets** — bets without failure criteria become marathons. Set the kill-switch date upfront.
+5. **Same view for all audiences** — engineering sees customer-facing directional language and treats it as imprecision. Customers see engineering specificity and treat it as promise.
+
+## Output → Obsidian: `WizardingCode/Product/Roadmap/<product>-<date>/`
+
+Delivers: North Star definition + outcome tree (3-5 outcomes with metrics) + three-horizon map + bet definitions (hypothesis + success criteria + appetite per bet) + capacity allocation + per-audience roadmap views + 1-page executive summary.

package/departments/pm/workflows/discover.yaml

@@ -0,0 +1,136 @@
+id: pm-discover
+name: Product Discovery
+description: Continuous product discovery using Opportunity Solution Tree (Teresa Torres) — interviews + assumption tests + outcome alignment
+department: pm
+tier: enterprise
+command: "/pm discover"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Discovery Brief
+    description: Define product outcome, the question we're answering, current evidence base, runway for discovery
+    agents:
+      - agent_id: product-director-carolina
+        role: Frame outcome, question, current evidence, time budget
+    gate:
+      type: user_approval
+      description: User confirms outcome statement and discovery question
+
+  - id: opportunity-mapping
+    name: Opportunity Mapping
+    description: Map the Opportunity Solution Tree — desired outcome at top, opportunities (customer needs) in middle, solution candidates at bottom
+    agents:
+      - agent_id: product-director-carolina
+        role: OST construction with explicit opportunity definitions
+      - agent_id: ux-designer-sofia-d
+        role: Customer journey lens — where do opportunities surface?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves OST structure
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Discovery/OST/"
+        description: Opportunity Solution Tree with opportunity definitions
+
+  - id: interview-plan
+    name: Interview Plan
+    description: Plan 5-10 customer interviews — recruit criteria, script, capture format
+    agents:
+      - agent_id: product-director-carolina
+        role: Interview script with story-based question structure (specific recent moments, not opinions)
+    gate:
+      type: user_approval
+      description: User approves interview plan and recruit criteria
+
+  - id: interview-execution
+    name: Interviews + Synthesis
+    description: Run interviews; synthesize into opportunity additions/refinements to the OST
+    agents:
+      - agent_id: product-director-carolina
+        role: Run interviews, capture verbatim notes, synthesize into opportunity refinements
+    gate:
+      type: user_approval
+      description: User approves interview synthesis
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Discovery/Interviews/"
+        description: Interview synthesis with opportunity refinements
+
+  - id: opportunity-selection
+    name: Opportunity Selection
+    description: Pick the target opportunity using impact × confidence × ease prioritisation
+    agents:
+      - agent_id: product-director-carolina
+        role: Opportunity selection with explicit prioritisation matrix and rationale
+    gate:
+      type: user_approval
+      description: User approves target opportunity
+
+  - id: assumption-tests
+    name: Assumption Mapping & Tests
+    description: For the chosen opportunity, list assumptions (desirability / viability / feasibility / usability) and design tests for the riskiest
+    agents:
+      - agent_id: product-director-carolina
+        role: Assumption map + test design for top 3 riskiest assumptions
+      - agent_id: tech-director-francisca
+        role: Feasibility-assumption test feasibility check
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves the top 3 assumption tests
+
+  - id: experiment-execution
+    name: Experiment Execution Plan
+    description: Concrete 2-week experiments — what to do, success criteria, failure criteria, owner
+    agents:
+      - agent_id: product-director-carolina
+        role: 2-week experiment plan per top-3 assumption
+    gate:
+      type: user_approval
+      description: User approves experiment execution plan
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test discovery — does the chosen opportunity tie to the outcome? Are assumption tests falsifiable?
+    agents:
+      - agent_id: product-director-carolina
+        role: Coherence check
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Interview script quality, synthesis prose, no leading questions
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Assumption test rigour, feasibility math, falsifiability
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Discovery Package Delivery
+    description: Compile discovery package — OST + interviews + opportunity selection + assumption tests + experiment plan
+    agents:
+      - agent_id: product-director-carolina
+        role: Full discovery package + 1-page executive summary
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Discovery/"
+        description: Complete discovery package — OST + interview synthesis + opportunity selection + assumption tests + 2-week experiment plan + exec summary

package/departments/pm/workflows/roadmap.yaml

@@ -0,0 +1,127 @@
+id: pm-roadmap
+name: Outcome-Driven Roadmap
+description: Outcome-driven product roadmap (3 horizons) — replaces feature-list roadmaps with measurable outcomes and bets
+department: pm
+tier: enterprise
+command: "/pm roadmap"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Roadmap Brief
+    description: Define product vision, current state, time horizon, owner organisation, stakeholders
+    agents:
+      - agent_id: product-director-carolina
+        role: Frame vision, current state, horizon, stakeholders
+    gate:
+      type: user_approval
+      description: User confirms vision and horizon
+
+  - id: outcome-definition
+    name: North Star + Outcome Tree
+    description: Define the North Star metric and 3-5 derived outcomes that decompose it
+    agents:
+      - agent_id: product-director-carolina
+        role: North Star + outcome tree definition with measurable per-outcome metrics
+      - agent_id: strategy-director-tomas
+        role: Strategic coherence — does the North Star align with company strategy?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves North Star and outcome tree
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Roadmap/NorthStar/"
+        description: North Star + outcome tree with metrics per outcome
+
+  - id: three-horizons
+    name: Three Horizons (Now / Next / Later)
+    description: Map work across the 3 horizons — Now (committed), Next (validating), Later (exploring)
+    agents:
+      - agent_id: product-director-carolina
+        role: Three-horizon mapping with explicit commitment levels per horizon
+    gate:
+      type: user_approval
+      description: User approves horizon mapping
+
+  - id: bet-selection
+    name: Bet Selection
+    description: For each outcome, select 1-3 bets (large, named, time-boxed efforts) with hypothesis + success criteria
+    agents:
+      - agent_id: product-director-carolina
+        role: Bet selection with hypothesis + success criteria per bet
+      - agent_id: strategy-director-tomas
+        role: Bet-outcome coherence and competitive context check
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves bet selection
+
+  - id: capacity-allocation
+    name: Capacity Allocation
+    description: Allocate team capacity across bets — fixed-time vs fixed-scope policy per bet
+    agents:
+      - agent_id: product-director-carolina
+        role: Capacity allocation with team mapping
+      - agent_id: tech-director-francisca
+        role: Technical feasibility + capacity math
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves capacity allocation
+
+  - id: communication-plan
+    name: Communication Plan
+    description: Internal stakeholder communication strategy — what each audience sees, how often, what's redacted
+    agents:
+      - agent_id: product-director-carolina
+        role: Per-audience roadmap view (exec / engineering / sales / customer-facing)
+      - agent_id: copy-director-eduardo
+        role: Per-audience copy adaptations
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves communication strategy
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the roadmap — are bets falsifiable? Does capacity match commitments? Are outcomes measurable?
+    agents:
+      - agent_id: product-director-carolina
+        role: Coherence check across outcomes / bets / capacity / horizons
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Outcome prose, bet hypothesis clarity, no clichés
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Capacity math, feasibility, measurement integrity
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Roadmap Package Delivery
+    description: Compile the roadmap package + audience-specific versions
+    agents:
+      - agent_id: product-director-carolina
+        role: Full roadmap + audience-specific views + 1-page executive summary
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Roadmap/"
+        description: Complete roadmap — North Star + outcome tree + 3-horizon map + bet definitions + capacity allocation + per-audience communication

package/departments/pm/workflows/shape.yaml

@@ -0,0 +1,136 @@
+id: pm-shape
+name: Shape Up Pitch
+description: Shape Up pitch (Basecamp method) — appetite + problem + solution sketch + rabbit holes + no-gos for a 6-week build cycle
+department: pm
+tier: enterprise
+command: "/pm shape"
+requires_branch: false
+requires_spec: false
+quality_gate_required: true
+
+phases:
+  - id: brief
+    name: Shaping Brief
+    description: Define the raw problem, the appetite (2 / 4 / 6 weeks), the people who'll build it
+    agents:
+      - agent_id: product-director-carolina
+        role: Frame raw problem, set appetite, name the build team
+    gate:
+      type: user_approval
+      description: User confirms problem, appetite, and team
+
+  - id: setting-boundaries
+    name: Setting Boundaries
+    description: Define what's IN scope and what's OUT — appetite is the constraint, fixed time variable scope
+    agents:
+      - agent_id: product-director-carolina
+        role: Scope definition — IN list, OUT list, explicit no-gos
+    gate:
+      type: user_approval
+      description: User approves scope boundaries
+
+  - id: rough-solution
+    name: Rough Solution
+    description: Sketch the solution at the right altitude — fat marker level, not pixel level. Just enough to commit
+    agents:
+      - agent_id: product-director-carolina
+        role: Solution sketch with fat-marker fidelity
+      - agent_id: ux-designer-sofia-d
+        role: User flow at fat-marker level
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves rough solution
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Shape/Solutions/"
+        description: Fat-marker solution sketch with user flow
+
+  - id: rabbit-holes
+    name: Rabbit Holes
+    description: Identify rabbit holes — risks, unknowns, technical debt traps — and either eliminate them in shaping or surface as risks
+    agents:
+      - agent_id: product-director-carolina
+        role: Rabbit hole identification + mitigation strategy per hole
+      - agent_id: tech-director-francisca
+        role: Technical rabbit holes (data, integration, dependency)
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves rabbit hole mitigation strategy
+
+  - id: no-gos
+    name: No-Gos
+    description: Explicitly name what's NOT being built — features that look related but aren't part of this bet
+    agents:
+      - agent_id: product-director-carolina
+        role: No-gos list with rationale per item
+    gate:
+      type: auto
+
+  - id: pitch-document
+    name: Pitch Document
+    description: Compile the pitch — problem + appetite + solution + rabbit holes + no-gos + nobody-decisions
+    agents:
+      - agent_id: product-director-carolina
+        role: Full Shape Up pitch document with all 5 sections
+      - agent_id: copy-director-eduardo
+        role: Pitch readability — does it commit the reader to a decision?
+        parallel: true
+    gate:
+      type: user_approval
+      description: User approves pitch document before betting table
+
+  - id: betting-decision
+    name: Betting Table Decision
+    description: Decide GO / NO-GO / RESHAPE at the betting table — does the appetite, solution, and team fit the next cycle?
+    agents:
+      - agent_id: product-director-carolina
+        role: Betting decision with rationale
+      - agent_id: strategy-director-tomas
+        role: Strategic alignment check
+        parallel: true
+    gate:
+      type: user_approval
+      description: User makes the betting decision (GO / NO-GO / RESHAPE)
+
+  - id: self-critique
+    name: Self-Critique
+    description: Stress-test the pitch — is the appetite realistic? Are rabbit holes fully named? Are no-gos enforced?
+    agents:
+      - agent_id: product-director-carolina
+        role: Pitch coherence check
+    gate:
+      type: auto
+
+  - id: quality-gate
+    name: Quality Gate
+    model_override: opus
+    description: Mandatory quality review
+    agents:
+      - agent_id: cqo-marta
+        role: Orchestrate quality review
+      - agent_id: copy-director-eduardo
+        role: Pitch prose, no over-promise, decision-forcing language
+        parallel: true
+      - agent_id: tech-director-francisca
+        role: Appetite × scope feasibility, rabbit hole completeness
+        parallel: true
+    gate:
+      type: quality_gate
+      required_verdict: APPROVED
+
+  - id: delivery
+    name: Pitch Package Delivery
+    description: Compile the pitch package — pitch doc + rabbit hole register + betting decision + handoff to build team
+    agents:
+      - agent_id: product-director-carolina
+        role: Full pitch package + handoff brief for build team
+    gate:
+      type: auto
+    outputs:
+      - type: document
+        format: markdown
+        obsidian_path: "WizardingCode/Product/Shape/"
+        description: Complete pitch package — pitch doc + rabbit hole register + no-gos + betting decision + build-team handoff

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "arkaos",
-  "version": "2.55.0",
+  "version": "2.57.0",
   "description": "The Operating System for AI Agent Teams",
   "type": "module",
   "bin": {

package/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "arkaos-core"
-version = "2.55.0"
+version = "2.57.0"
 description = "Core engine for ArkaOS — The Operating System for AI Agent Teams"
 readme = "README.md"
 license = {text = "MIT"}