War Room

Overview

The War Room convenes multiple AI experts to analyze problems from diverse perspectives, challenge assumptions through adversarial review, and synthesize optimal approaches under the guidance of a Supreme Commander.

Philosophy

"The trick is that there is no trick. The power of intelligence stems from our vast diversity, not from any single, perfect principle."

- Marvin Minsky, Society of Mind

Reversibility-Based Routing

Before deliberation, assess the Reversibility Score (RS) to determine appropriate resource allocation:

RS = (Reversal Cost + Time Lock-In + Blast Radius + Information Loss + Reputation Impact) / 25

Quick Heuristics:

• Can be A/B tested? → Type 2
• Requires data migration? → Type 1
• Public commitment required? → Type 1A+

See modules/reversibility-assessment.md for full scoring guide.

When To Use

• Architectural decisions with major trade-offs
• Multi-stakeholder problems requiring diverse perspectives
• High-stakes choices with significant consequences (RS > 0.60)
• Novel problems without clear precedent
• When brainstorming produces multiple strong competing approaches

When NOT To Use

• Simple questions with obvious answers
• Routine implementation tasks
• Well-documented patterns with clear solutions
• Time-critical decisions requiring immediate action
• Type 2 decisions (RS ≤ 0.40): use Express mode or skip War Room entirely

Expert Panel

Default (Lightweight Mode)

Full Council (Escalated)

Deliberation Protocol

Two-Round Default

Round 1: Generation
  - Phase 1: Intelligence Gathering (Scout, Intel Officer)
  - Phase 2: Situation Assessment (Chief Strategist)
  - Phase 3: COA Development (Multiple experts, parallel)
  - Commander Escalation Check

Round 2: Pressure Testing
  - Phase 4: Red Team Review (all COAs)
  - Phase 5: Voting + Narrowing (top 2-3)
  - Phase 6: Premortem Analysis (selected COA)
  - Phase 7: Supreme Commander Synthesis
  - Phase 8: Discussion Publishing

Delphi Extension (High-Stakes)

For high-stakes decisions, extend to iterative Delphi convergence:

• Multiple rounds until expert consensus
• Convergence threshold: 0.85

Integration

With Brainstorm

War Room is AUTOMATICALLY INVOKED from Skill(attune:project-brainstorming) after Phase 3 (Approach Generation).

The brainstorm skill passes all context to War Room:

• Problem statement and constraints
• Generated approaches with pros/cons
• Comparison matrix
• Reversibility assessment (automatically calculated)

Bypass conditions (only if ALL true):

• RS ≤ 0.40 (Type 2 decision - clearly reversible)
• Single obvious approach with no meaningful trade-offs
• Low complexity with well-documented pattern
• User explicitly declines after seeing RS assessment

# Automatic invocation from brainstorm (do not skip)
/attune:war-room --from-brainstorm

# Direct invocation (standalone)
/attune:war-room "Should we use microservices or monolith for this system?"

With Memory Palace

Sessions persist to the Strategeion (War Palace):

~/.claude/memory-palace/strategeion/
  - war-table/      # Active sessions
  - campaign-archive/  # Historical decisions
  - doctrine/       # Learned patterns
  - armory/         # Expert configurations

With Conjure

Experts are invoked via conjure delegation:

• conjure:gemini-delegation for Gemini models
• conjure:qwen-delegation for Qwen models
• Direct CLI for GLM-4.7 (ccgd or claude-glm --dangerously-skip-permissions)

Usage

Basic Invocation

/attune:war-room "What architecture should we use for the new payment system?"

With Context

/attune:war-room "Best approach for API versioning" --files src/api/**/*.py

Reversibility Assessment Only

Quick assessment without full deliberation:

/attune:war-room "Database migration to MongoDB" --assess-only

Output:

Reversibility Assessment
========================
Decision: Database migration to MongoDB

Dimensions:
  Reversal Cost:      5/5 (months of rework)
  Time Lock-In:       4/5 (migration path hardens)
  Blast Radius:       5/5 (all services affected)
  Information Loss:   4/5 (query patterns, ACID)
  Reputation Impact:  2/5 (internal unless downtime)

Reversibility Score: 0.80
Decision Type: Type 1A (One-Way Door)
Recommended Mode: Full Council

Proceed with full deliberation? [Y/n]

Force Express Mode (Type 2)

Skip to rapid decision for clearly reversible choices:

/attune:war-room "Which logging library to use" --express

Force Full Council

Override RS assessment for critical decisions:

/attune:war-room "Migration strategy" --full-council

Delphi Mode

For highest-stakes irreversible decisions:

/attune:war-room "Long-term platform decision" --delphi

Resume Session

/attune:war-room --resume war-room-20260120-153022

Output

Decision Document

The War Room produces a Supreme Commander Decision document:

## SUPREME COMMANDER DECISION: {session_id}

### Reversibility Assessment
| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Reversal Cost | X/5 | ... |
| Time Lock-In | X/5 | ... |
| Blast Radius | X/5 | ... |
| Information Loss | X/5 | ... |
| Reputation Impact | X/5 | ... |

**RS: 0.XX | Type: [1A+/1A/1B/2] | Mode: [delphi/full_council/lightweight/express]**

### Decision
**Selected Approach**: [Name]

### Rationale
[Why this approach was selected]

### Implementation Orders
1. [ ] Immediate actions
2. [ ] Short-term actions

### Watch Points
[From Premortem - what to monitor]

### Reversal Plan (for Type 1 decisions)
[If this decision proves wrong, here's the exit strategy]

### Dissenting Views
[For the record]

Session Artifacts

Saved to Strategeion:

• Intelligence reports
• Situation assessment
• All COAs (with full attribution after unsealing)
• Red Team challenges
• Premortem analysis
• Final decision

Record the Tradeoff (decision journal)

The Supreme Commander Decision is a tradeoff record by construction: a selected approach, the COAs weighed against it, and the dissenting views. Mirror it into docs/tradeoffs.md so the reasoning stays with the code, not only in Strategeion (draft and confirm):

• If leyline is installed, invoke Skill(leyline:decision-journal) and append

a tradeoff entry. Map directly: Selected Approach to decision, the RS and rationale to a Y-statement, the rejected COAs to options, and Dissenting Views to consequences_negative. Set phase to the originating phase (for example plan). Record the RS in the entry links. Append on confirmation.

• Fallback (leyline absent): append to docs/tradeoffs.md using the in-file

ENTRY TEMPLATE; assign the next TR-NNN id.

If the decision is architectural enough to warrant a numbered ADR in docs/adr/, write the ADR and reference its number from the tradeoff entry rather than duplicating it.

Anonymization

Expert contributions are anonymized during deliberation using Merkle-DAG:

• Responses labeled as "Response A, B, C..." during review
• Attribution revealed only after decision is made
• Hash verification ensures integrity

See modules/merkle-dag.md for details.

Escalation

Automatic (Reversibility-Based)

Deliberation mode is automatically selected based on Reversibility Score:

Manual Override

The Supreme Commander may override automatic classification when:

• High complexity detected (multiple architectural trade-offs)
• Significant disagreement between initial experts
• Novel problem domain requiring specialized analysis
• Precedent-setting decision (future decisions will follow pattern)
• Political/organizational sensitivity beyond technical scope

Escalation requires written justification with RS assessment.

De-escalation

Equally important: identify decisions being over-deliberated:

• If RS ≤ 0.40, recommend Express mode or immediate execution
• Challenge "false irreversibility" ("we can't change this later" without evidence)
• Track de-escalation rate as team health metric

Configuration

User Settings

{
  "war_room": {
    "default_mode": "lightweight",
    "auto_escalate": true,
    "delphi_threshold": 0.85,
    "max_delphi_rounds": 5
  }
}

Hook Auto-Trigger

War Room can be auto-suggested via hook when:

• Keywords detected ("strategic decision", "trade-off", etc.)
• Complexity score exceeds threshold (0.7)
• User has opted in via settings

Agent Teams Execution Mode

Overview

When --agent-teams is specified (or auto-selected for Full Council / Delphi modes), the War Room uses Claude Code Agent Teams instead of sequential conjure delegation. Each expert runs as a persistent teammate with bidirectional messaging, enabling real-time deliberation instead of batch request/response cycles.

Requires: Claude Code 2.1.32+, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, tmux installed.

When Agent Teams Helps

Rule of thumb: Use agent teams only for Full Council and Delphi modes. Lightweight and Express modes don't generate enough inter-expert traffic to justify the coordination overhead.

Team Configuration

# War Room agent team structure
Team: war-room-{session-id}
  Lead: supreme-commander (Opus) — orchestrates phases, final synthesis
  Teammates:
    chief-strategist (Sonnet) — approach generation
    intel-officer (Sonnet) — deep context analysis
    field-tactician (Sonnet) — implementation feasibility
    scout (Haiku) — rapid reconnaissance
    red-team (Sonnet) — adversarial challenge
    logistics (Haiku) — resource estimation

Note: In agent teams mode, all teammates run as Claude Code instances (Opus/Sonnet/Haiku). External LLM experts (Gemini, Qwen, GLM) are not used because agent teams requires the Claude CLI. The trade-off is losing model diversity but gaining real-time inter-expert messaging.

Deliberation Flow with Agent Teams

1. Lead creates team → spawns teammates in tmux panes 2. Phase 1 (Intel): Lead assigns intel tasks to scout and intel-officer via inbox 3. Phase 3 (COA): Lead broadcasts situation assessment; teammates develop COAs independently; messaging allows clarifying questions mid-development 4. Phase 4 (Red Team): Red-team teammate receives all COAs, posts challenges; other teammates can respond to challenges in real-time 5. Phase 5 (Voting): Lead broadcasts ballot; teammates rank via inbox messages 6. Phase 6 (Premortem): All teammates receive selected COA; can build on each other's failure scenarios 7. Phase 7 (Synthesis): Lead collects all artifacts, produces decision 8. Phase 8 (Discussion Publishing): After the Supreme Commander Decision document is finalized, you MUST execute modules/discussion-publishing.md to publish the decision to GitHub Discussions. Publishing is the default. The user can decline with "n". See the "Discussion Publishing (REQUIRED)" section below for the full step-by-step workflow.

Falling Back to Conjure Delegation

If agent teams fails (tmux unavailable, team creation error), the War Room automatically falls back to standard conjure delegation. The deliberation protocol is identical: only the execution backend differs.

Cost Considerations

Agent teams is significantly more token-intensive than conjure delegation (each teammate maintains its own context window). Use only when the coordination value justifies the cost, typically Delphi mode where multiple rounds of revision make persistent teammates worthwhile.

Discussion Publishing (REQUIRED)

After Phase 7 synthesis completes (in any execution mode), you MUST execute the discussion publishing workflow. This is not optional unless the user explicitly declines.

Execute these steps in order:

1. Read modules/discussion-publishing.md for the full GraphQL workflow 2. Ask the user: "Publishing this decision to GitHub Discussions. [Y/n]" 3. If the user says "n", skip to Related Skills. Otherwise proceed with steps 4-6. 4. Run the gh api graphql commands from the module to create a Discussion in the "Decisions" category 5. Post phase summaries as threaded comments on the Discussion 6. Update the local strategeion file with the Discussion URL

If GitHub Discussions are unavailable (non-GitHub platform, Discussions disabled, gh not authenticated), warn the user and skip. Publishing failures never block the war room workflow.

Exit Criteria

• [ ] A Reversibility Score and decision type are computed and recorded.
• [ ] A Supreme Commander Decision document with a selected approach,

rationale, and dissenting views is produced.

• [ ] The decision is mirrored to docs/tradeoffs.md (and to a numbered ADR

in docs/adr/ if architectural).

• [ ] Premortem watch points and, for Type 1 decisions, a reversal plan are

captured.

Related Skills

• Skill(attune:project-brainstorming) - Pre-War Room ideation
• Skill(imbue:scope-guard) - Scope management
• Skill(imbue:rigorous-reasoning) - Reasoning methodology
• Skill(conjure:delegation-core) - Expert dispatch
• Skill(conjure:agent-teams) - Agent teams coordination (Full Council / Delphi)

Related Commands

• /attune:war-room - Invoke this skill
• /attune:brainstorm - Pre-War Room ideation
• /memory-palace:strategeion - Access War Room history

References

Strategic Foundations

• Sun Tzu - Art of War (intelligence gathering)
• Clausewitz - On War (friction and fog)
• Robert Greene - 33 Strategies of War (unity of command)
• MDMP - U.S. Army (structured decision process)
• Gary Klein - Premortem (failure mode analysis)
• Karpathy - LLM Council (anonymized peer review)

Reversibility Framework

• Jeff Bezos - Type 1 vs Type 2 Decisions (Amazon shareholder letters)
• Farnam Street - Reversible and Irreversible Decisions (STOP-LOP-KNOW framework)
• Tapan Desai - One-Way and Two-Way Door Decision-Making (practical application)

Deferred Capture

After Phase 5 (Voting and Narrowing), capture rejected COAs and any future-work items from the Dissenting Views section so nothing valuable is lost.

When to Run

Run this module immediately after the Supreme Commander publishes the final decision document and before the war-room session closes.

Capturing Rejected COAs

For every COA that was eliminated during voting, check whether it received at least one Borda vote. If it did, capture it as a deferred item:

python3 scripts/deferred_capture.py \
  --title "COA: <coa-title>" \
  --source war-room \
  --context "<rejection rationale from Supreme Commander>" \
  --artifact-path "<path to coa file in strategeion>" \
  --session-id "<war-room-session-id>"

A COA that received zero Borda votes across all expert roles does not need to be captured.

Capturing Dissenting-View Items

After capturing rejected COAs, scan the "Dissenting Views" section of the Supreme Commander decision document. For each item that describes future work (identified by phrases such as "should revisit", "worth exploring", "consider in phase N"), capture it using the same script:

python3 scripts/deferred_capture.py \
  --title "COA: <coa-title>" \
  --source war-room \
  --context "<rejection rationale from Supreme Commander>" \
  --artifact-path "<path to coa file in strategeion>" \
  --session-id "<war-room-session-id>"

Use the dissenting view text as the --context value. Omit --artifact-path if no coa file corresponds to the item.

Behavior Rules

• Capture is automatic: do not prompt the user for

confirmation.

• Capture every qualifying COA in a single pass before

closing the session.

• If scripts/deferred_capture.py is not present in the

repository, log a warning and skip capture rather than blocking the war-room close.

• The session ID must match the ID stored in

.attune/war-room-session.json.

Deliberation Protocol

Session Lifecycle

Initialize
    |
    v
+------------------------+
| Phase 0: Reversibility |  <-- Chief Strategist (immediate)
| Assessment             |
+------------------------+
    |
    +---> [RS ≤ 0.40: EXPRESS MODE - skip to Phase 7]
    |
    v
+-------------------+
| Phase 1: Intel    |  <-- Scout + Intel Officer (parallel)
+-------------------+
    |
    v
+-------------------+
| Phase 2: Assess   |  <-- Chief Strategist
+-------------------+
    |
    v
+-------------------+
| Phase 3: COA Dev  |  <-- Multiple experts (parallel, anonymized)
+-------------------+
    |
    v
+-------------------+
| Escalation Check  |  <-- Supreme Commander decides
+-------------------+
    |
    +---> [Escalate to Full Council if needed]
    |
    v
+-------------------+
| Phase 4: Red Team |  <-- Red Team Commander
+-------------------+
    |
    v
+-------------------+
| Phase 5: Voting   |  <-- All active experts
+-------------------+
    |
    v
+-------------------+
| Phase 6: Premortem|  <-- All active experts (parallel)
+-------------------+
    |
    v
+-------------------+
| Phase 7: Synthesis|  <-- Supreme Commander
+-------------------+
    |
    v
Persist to Strategeion

Phase Definitions

Phase 0: Reversibility Assessment

Purpose: Determine appropriate deliberation intensity before committing resources.

Expert: Chief Strategist (Sonnet)

Execution: Immediate, before any other phases

Inputs:

• Problem statement
• Initial context

Step 0a: Threshold Configuration (optional)

Prompt user for custom thresholds:

Reversibility Thresholds (Enter for defaults):
  Express ceiling    [0.40]: _
  Lightweight ceiling [0.60]: _
  Full Council ceiling [0.80]: _

If user presses Enter, use defaults. Otherwise, apply custom thresholds for session.

Step 0b: Dimension Scoring

Score five dimensions (1-5 each): 1. Reversal Cost - Effort to undo the decision 2. Time Lock-In - How quickly decision crystallizes 3. Blast Radius - Scope of systems/people affected 4. Information Loss - Options closed by deciding 5. Reputation Impact - External visibility and trust implications

Outputs:

• Reversibility Score (RS) = Sum / 25
• Decision Type classification (Type 2, 1B, 1A, 1A+)
• Recommended deliberation mode (using configured thresholds)
• Justification for classification

Duration Target: 15-30 seconds (including threshold prompt)

Routing Logic (using configured or default thresholds):

# t = user thresholds or defaults {express: 0.40, lightweight: 0.60, full_council: 0.80}

if RS <= t.express:
    mode = "express"  # Skip to Phase 7 (Synthesis only)
elif RS <= t.lightweight:
    mode = "lightweight"  # Standard 2-round protocol
elif RS <= t.full_council:
    mode = "full_council"  # Invoke all experts
else:
    mode = "full_council_delphi"  # Iterative convergence

Express Mode Fast Path: For Type 2 decisions (RS ≤ 0.40):

• Skip Phases 1-6
• Chief Strategist provides immediate recommendation
• Supreme Commander ratifies or overrides
• Total time: < 2 minutes

---

Phase 1: Intelligence Gathering

Purpose: Gather context and identify terrain before strategy.

Experts: Scout (Qwen Turbo), Intelligence Officer (Gemini Pro)

Execution: Parallel

Inputs:

• Problem statement
• Context files (if provided)

Outputs:

• Scout Report (quick terrain overview)
• Intelligence Report (deep analysis)

Duration Target: 30-60 seconds

Phase 2: Situation Assessment

Purpose: Synthesize intelligence into a concrete assessment.

Expert: Chief Strategist (Sonnet)

Execution: Sequential (after Phase 1)

Inputs:

• All intelligence reports from Phase 1

Outputs:

• Refined problem statement
• Prioritized constraints
• Strategic opportunities
• COA development guidance

Duration Target: 15-30 seconds

Phase 3: COA Development

Purpose: Generate diverse courses of action.

Experts: Variable (based on mode)

• Lightweight: Chief Strategist only
• Full Council: Strategist + Tactician + Logistics Officer

Execution: Parallel, anonymized

Inputs:

• Situation assessment from Phase 2

Outputs:

• 3-5 distinct COAs
• Each with pros, cons, risks, effort estimate

Duration Target: 60-120 seconds

Anonymization: Responses labeled as "Response A, B, C..."

Escalation Check

Purpose: Supreme Commander validates Phase 0 classification or overrides.

Automatic Escalation (based on RS from Phase 0):

• RS > 0.60 → Full Council activated
• RS > 0.80 → Delphi mode enabled

Manual Escalation Triggers: 1. High complexity (multiple architectural trade-offs) 2. Significant expert disagreement (conflicting COAs) 3. Novel problem domain (uncertain reversibility) 4. Precedent-setting decision (future decisions follow pattern) 5. User explicitly requested full council

De-escalation Opportunity: If Phase 0 classified as Type 1 but evidence suggests Type 2:

• Challenge the RS assessment
• Document false irreversibility claim
• Recommend express mode

If Escalated:

• Invoke additional experts (Intel Officer, Tactician, Logistics)
• Gather additional COAs
• Merge with existing COAs
• Update RS assessment with new information

Phase 4: Red Team and Wargaming

Purpose: Challenge assumptions and identify weaknesses.

Expert: Red Team Commander (Gemini Flash)

Execution: Sequential (after all COAs)

Inputs:

• All COAs (anonymized)
• Situation assessment

Outputs:

• Challenge report per COA
• Hidden assumptions identified
• Failure scenarios
• Cross-cutting concerns

Duration Target: 30-60 seconds

Phase 5: Voting and Narrowing

Purpose: Aggregate expert rankings to identify top approaches.

Experts: All active experts

Execution: Parallel

Inputs:

• All COAs with Red Team challenges

Outputs:

• Expert rankings
• Aggregate scores (Borda count)
• Top 2-3 finalists

Voting Method: Borda count (rank-based scoring)

Duration Target: 30-45 seconds

Phase 6: Premortem Analysis

Purpose: Imagine failure to identify risks.

Experts: All active experts

Execution: Parallel

Inputs:

• Selected COA(s) from voting

Outputs:

• Failure mode catalog
• Early warning signs
• Prevention strategies
• Contingency plans

Duration Target: 45-90 seconds

Phase 7: Supreme Commander Synthesis

Purpose: Make final decision with full rationale.

Expert: Supreme Commander (Opus)

Execution: Sequential (final phase)

Inputs:

• All deliberation artifacts
• Full attribution (unsealed)

Outputs:

• Selected approach
• Detailed rationale
• Implementation orders
• Watch points
• Dissenting views acknowledged

Duration Target: 30-60 seconds

Delphi Extension

For high-stakes decisions, iterate until convergence:

Round N:
  - Experts revise positions based on Red Team feedback
  - Re-vote
  - Check convergence score

Convergence Formula:
  score = 1 - (std_dev(rankings) / max_possible_std_dev)

Threshold: 0.85 (configurable)
Max Rounds: 5 (configurable)

Error Handling

Expert Failure

If an expert fails to respond: 1. Log the failure with reason 2. Continue with remaining experts 3. Note gap in synthesis 4. Do not block deliberation

Timeout Handling

Default timeouts:

• External experts: 120 seconds
• Synthesis phases: 180 seconds

On timeout: 1. Use partial response if available 2. Log timeout event 3. Continue deliberation

Session Recovery

Sessions are persisted after each phase:

• Can resume from last completed phase
• Use --resume <session-id> to continue

Agent Teams Execution Path

When --agent-teams is active (Full Council / Delphi only), phases execute through persistent teammates instead of one-shot delegations:

Phase Mapping

Key Differences

Bidirectional messaging (Phases 3-6): In standard mode, experts produce one-shot responses. In agent teams mode, experts can exchange messages mid-phase: the Red Team can ask a COA author to clarify assumptions, and premortem participants can chain failure scenarios.

Delphi persistence: In standard mode, each Delphi round re-invokes all experts from scratch. In agent teams mode, teammates persist across rounds, retaining prior context and positions. This reduces token waste and enables more nuanced position evolution.

Anonymization: Agent teams still uses anonymized COA labeling (Response A, B, C) during Phases 3-5. Attribution is revealed in Phase 7 by the lead agent after de-anonymization.

Graceful Shutdown

After Phase 7, the lead sends shutdown_request to all teammates. Teammates acknowledge and exit. Lead cleans up team config and tmux panes.

Metrics

Track per session:

• Reversibility Score (from Phase 0)
• Decision Type (Type 2, 1B, 1A, 1A+)
• Mode match (did actual mode match RS recommendation?)
• Total duration
• Per-phase duration
• Token usage per expert
• Expert failure count
• Escalation occurred (y/n)
• De-escalation occurred (y/n)
• Convergence rounds (if Delphi)
• Over-deliberation rate (sessions where RS suggested lighter mode)

Discussion Publishing

Publish completed war room deliberations to GitHub Discussions for cross-session discovery.

When This Module Applies

This module activates after Phase 7 (Supreme Commander Synthesis) completes. It is an additional publication channel: the local strategeion archive continues as the primary record.

Prerequisites

• GitHub platform detected (check git_platform session context)
• gh CLI authenticated (gh auth status succeeds)
• Repository has Discussions enabled with a "Decisions" category
• Leyline command-mapping Discussion templates available

Publishing Flow

Step 1: Confirm Publication (Default: Publish)

After the Supreme Commander Decision document is finalized, announce the publication and give the user a chance to opt out:

Publishing this decision to GitHub Discussions. [Y/n]

Publishing is the default action. If the user explicitly declines ("n"), skip all subsequent steps. The local strategeion workflow continues unchanged.

Step 2: Resolve Repository and Category IDs

# Get repository node ID
REPO_INFO=$(gh api graphql -f query='
query($owner: String!, $repo: String!) {
  repository(owner: $owner, name: $repo) {
    id
    hasDiscussionsEnabled
    discussionCategories(first: 25) {
      nodes { id name slug }
    }
  }
}' -f owner="OWNER" -f repo="REPO")

Extract repositoryId and find the category nodeID where slug equals "decisions".

If Discussions are not enabled or the "Decisions" category doesn't exist, warn the user and skip publishing:

⚠ Discussions not available (feature disabled or "Decisions" category missing). Skipping publication.

Step 3: Create the Discussion

Create a Discussion in the "Decisions" category:

gh api graphql -f query='
mutation($repoId: ID!, $categoryId: ID!, $title: String!, $body: String!) {
  createDiscussion(input: {
    repositoryId: $repoId,
    categoryId: $categoryId,
    title: $title,
    body: $body
  }) {
    discussion { number id url }
  }
}' -f repoId="$REPO_ID" -f categoryId="$CATEGORY_ID" \
   -f title="[War Room] $TOPIC" \
   -f body="$BODY"

Title format: [War Room] <topic from session invocation>

Body structure:

## Context

<Context from the Supreme Commander Decision document>

## Decision

**Selected Approach**: <selected approach name>

<Decision rationale>

## Consequences

<Positive, negative, and neutral consequences>

## Reversibility Assessment

| Dimension | Score | Rationale |
|-----------|-------|-----------|
| Reversal Cost | X/5 | ... |
| Time Lock-In | X/5 | ... |
| Blast Radius | X/5 | ... |
| Information Loss | X/5 | ... |
| Reputation Impact | X/5 | ... |

**RS: 0.XX | Type: [1A+/1A/1B/2] | Mode: [delphi/full_council/lightweight/express]**

## Alternatives Considered

<Brief summary of each COA that was not selected>

## Expert Panel

| Role | Model | Key Contribution |
|------|-------|-----------------|
| Supreme Commander | ... | ... |
| Chief Strategist | ... | ... |
| Red Team | ... | ... |

---
*Session: <session_id> | Strategeion: `<local_file_path>`*

Step 4: Post Deliberation Phases as Comments

Post each major phase as a threaded comment on the Discussion. This preserves the deliberation trail without overwhelming the Discussion body.

Comments to post (in order): 1. Intelligence Report: key findings from Phase 1 2. Situation Assessment: Phase 2 analysis summary 3. COA Summary: brief of each Course of Action (Phase 3) 4. Red Team Challenges: key challenges and responses (Phase 4) 5. Supreme Commander Synthesis: the final decision rationale (Phase 7)

Phases 5-6 (War Game execution and Decision Briefing) are internal deliberation artifacts that don't warrant separate comments. Their outputs are incorporated into the Red Team Challenges and Supreme Commander Synthesis.

For each comment:

gh api graphql -f query='
mutation($discussionId: ID!, $body: String!) {
  addDiscussionComment(input: {
    discussionId: $discussionId,
    body: $body
  }) {
    comment { id url }
  }
}' -f discussionId="$DISCUSSION_ID" -f body="### Phase N: <Phase Name>

<Phase summary — keep under 500 words per comment>

*Full details in strategeion: \`<local_file_path>\`*"

Step 5: Mark Synthesis as Answer (Q&A Categories Only)

Skip this step for the "Decisions" category. It uses Announcement format, which does not support answers. The synthesis is already the last comment, so no further marking is needed.

For Q&A-format categories (e.g., "Knowledge"), mark the synthesis comment as the answer:

gh api graphql -f query='
mutation($commentId: ID!) {
  markDiscussionCommentAsAnswer(input: {
    id: $commentId
  }) {
    discussion { id answerChosenAt }
  }
}' -f commentId="$SYNTHESIS_COMMENT_ID"

If the mutation fails (wrong category format), log a warning and continue.

Step 6: Apply Labels

Apply labels to the Discussion for discoverability. Labels must already exist on the repository.

Recommended labels:

• war-room: always applied
• type-1a, type-1b, or type-2: matching the decision type from RS assessment
• Topic-relevant labels (e.g., architecture, performance, security)

Label application requires a separate mutation:

gh api graphql -f query='
mutation($labelableId: ID!, $labelIds: [ID!]!) {
  addLabelsToLabelable(input: {
    labelableId: $labelableId,
    labelIds: $labelIds
  }) {
    labelable { ... on Discussion { id } }
  }
}'

If label application fails (labels don't exist), log a warning and continue.

Step 7: Update Local Strategeion

Add the Discussion URL to the local strategeion session file:

discussion_url: https://github.com/OWNER/REPO/discussions/NUMBER
discussion_number: NUMBER
published_at: YYYY-MM-DDTHH:MM:SSZ

This cross-reference allows future sessions to move from local artifact to the published Discussion and vice versa.

Error Handling

• Network failure during publishing: Log warning, preserve local artifacts. Do not retry automatically: the user can re-publish manually.
• Rate limiting: If GitHub returns 429, warn the user and skip. Do not block the session.
• Missing category: Warn and skip. Do not auto-create categories.
• `gh` not authenticated: Skip with message: "GitHub CLI not authenticated. Run gh auth login to enable Discussion publishing."

Token Conservation

• Discussion body: max 2000 words (NFR-005)
• Phase comments: max 500 words each
• Link to strategeion files for full details rather than duplicating content
• Total published content should be a readable summary, not a transcript

Prior Decision Check

Before starting a new war room session, search for prior decisions on the same topic. See the "Prior Decision Check" section below.

---

Prior Decision Check

When a war room session starts (before Phase 1), search existing Discussions for prior decisions in the same area.

Search Flow

1. Extract topic keywords from the war room invocation argument 2. Search Discussions:

gh api graphql -f query='
query($searchQuery: String!) {
  search(query: $searchQuery, type: DISCUSSION, first: 5) {
    discussionCount
    nodes {
      ... on Discussion {
        number
        title
        url
        createdAt
        body
        answer { body }
      }
    }
  }
}' -f searchQuery="repo:OWNER/REPO category:Decisions TOPIC_KEYWORDS"

3. If matches found, present to user:

Found prior decisions on this topic:
  #42 [War Room] Database migration strategy (2026-02-15)
  #38 [War Room] API versioning approach (2026-02-10)

Review before proceeding? [Y/n/skip]

User Responses

• Y (review): Display the prior decision summary. Then ask:
• "Does this prior decision still apply? [Y/n]"
• Y: Skip war room. Record a note: "Reaffirmed Decision #42. No new deliberation needed."
• N: Proceed with war room. New Discussion will reference the prior: Supersedes: #42
• n (proceed): Start war room without reviewing prior decisions
• skip: Disable prior decision check for this session

No Matches

If no matching Discussions are found, proceed directly to Phase 1 without delay.

Expert Roles Configuration

Expert Registry

EXPERT_CONFIGS = {
    "supreme_commander": {
        "role": "Supreme Commander",
        "service": "native",
        "model": "claude-opus-4",
        "description": "Final decision authority and synthesis",
        "phases": ["synthesis"],
        "dangerous": False,
    },
    "chief_strategist": {
        "role": "Chief Strategist",
        "service": "native",
        "model": "claude-sonnet-4",
        "description": "Approach generation and trade-off analysis",
        "phases": ["assessment", "coa_development"],
        "dangerous": False,
    },
    "intelligence_officer": {
        "role": "Intelligence Officer",
        "service": "gemini",
        "model": "gemini-2.5-pro-exp",
        "command": ["gemini", "--model", "gemini-2.5-pro-exp", "-p"],
        "description": "Deep context analysis with 1M+ token window",
        "phases": ["intel"],
        "dangerous": True,
    },
    "field_tactician": {
        "role": "Field Tactician",
        "service": "glm",
        "model": "glm-4.7",
        "command_resolver": "get_glm_command",
        "preferred_alias": "ccgd",
        "fallback_command": ["claude-glm", "--dangerously-skip-permissions", "-p"],
        "description": "Implementation feasibility assessment",
        "phases": ["coa_development"],
        "dangerous": True,
    },
    "scout": {
        "role": "Scout",
        "service": "qwen",
        "model": "qwen-turbo",
        "command": ["qwen", "--model", "qwen-turbo", "-p"],
        "description": "Rapid reconnaissance and data gathering",
        "phases": ["intel"],
        "dangerous": True,
    },
    "prosecution_counsel": {
        "role": "Prosecution Counsel",
        "service": "native",
        "model": "claude-sonnet-4",
        "description": "Challenges every addition using additive-bias-defense scrutiny questions",
        "phases": ["red_team", "coa_development"],
        "dangerous": False,
    },
    "red_team": {
        "role": "Red Team Commander",
        "service": "gemini",
        "model": "gemini-2.0-flash-exp",
        "command": ["gemini", "--model", "gemini-2.0-flash-exp", "-p"],
        "description": "Adversarial challenge and failure mode identification",
        "phases": ["red_team", "premortem"],
        "dangerous": True,
    },
    "logistics_officer": {
        "role": "Logistics Officer",
        "service": "qwen",
        "model": "qwen-max",
        "command": ["qwen", "--model", "qwen-max", "-p"],
        "description": "Resource estimation and dependency analysis",
        "phases": ["coa_development"],
        "dangerous": True,
    },
}

Prosecution Counsel Role

The Prosecution Counsel is a mandatory panelist when reviewing implementation plans. Their sole job is to argue against additions using the scrutiny questions from leyline:additive-bias-defense:

1. Is this a deviation from the current priority? 2. Is it critical to implement at this juncture? 3. Does a simpler or more elegant solution exist? 4. What evidence proves this is needed? 5. What breaks if we do not add this?

Prompt template for Prosecution Counsel:

You are the Prosecution Counsel. Your job is to

challenge every proposed addition in this plan.

For each new component, abstraction, or capability,

apply the 5 scrutiny questions. If the proposer

cannot provide concrete evidence for questions 4

and 5, recommend removal.

>

Default stance: this addition should not exist.

Prove me wrong.

When active: Always active for plan reviews. Optional for other war-room sessions (activated when leyline:additive-bias-defense findings are provided as input).

Panel Configurations

Lightweight Panel

For quick decisions with lower complexity:

LIGHTWEIGHT_PANEL = [
    "supreme_commander",
    "chief_strategist",
    "prosecution_counsel",
    "red_team",
]

Full Council

For complex, high-stakes decisions:

FULL_COUNCIL = [
    "supreme_commander",
    "chief_strategist",
    "intelligence_officer",
    "prosecution_counsel",
    "field_tactician",
    "scout",
    "red_team",
    "logistics_officer",
]

GLM-4.7 Command Resolution

def get_glm_command() -> list[str]:
    """
    Resolve GLM-4.7 invocation command with fallback.

    Priority:
    1. ccgd (alias) - if available in PATH
    2. claude-glm --dangerously-skip-permissions - explicit fallback
    3. ~/.local/bin/claude-glm - direct path fallback
    """
    import shutil
    from pathlib import Path

    # Check for alias
    if shutil.which("ccgd"):
        return ["ccgd", "-p"]

    # Check for script in PATH
    if shutil.which("claude-glm"):
        return ["claude-glm", "--dangerously-skip-permissions", "-p"]

    # Direct path fallback
    local_bin = Path.home() / ".local" / "bin" / "claude-glm"
    if local_bin.exists():
        return [str(local_bin), "--dangerously-skip-permissions", "-p"]

    raise RuntimeError(
        "GLM-4.7 not available. Install claude-glm or configure ccgd alias.\n"
        "Add to ~/.bashrc: alias ccgd='claude-glm --dangerously-skip-permissions'"
    )

Expert Capabilities

Phase-to-Expert Mapping

Agent Teams Member Mapping

When using --agent-teams, experts map to Claude Code teammates. External LLM diversity is traded for real-time inter-expert messaging.

AGENT_TEAMS_MEMBERS = {
    "supreme_commander": {
        "agent_name": "supreme-commander",
        "model": "opus",
        "role": "Lead agent (not spawned — IS the lead)",
    },
    "chief_strategist": {
        "agent_name": "chief-strategist",
        "model": "sonnet",
        "color": "#4ECDC4",
    },
    "intelligence_officer": {
        "agent_name": "intel-officer",
        "model": "sonnet",
        "color": "#45B7D1",
    },
    "field_tactician": {
        "agent_name": "field-tactician",
        "model": "sonnet",
        "color": "#96CEB4",
    },
    "scout": {
        "agent_name": "scout",
        "model": "haiku",
        "color": "#FFEAA7",
    },
    "red_team": {
        "agent_name": "red-team",
        "model": "sonnet",
        "color": "#FF6B6B",
    },
    "logistics_officer": {
        "agent_name": "logistics",
        "model": "haiku",
        "color": "#DDA0DD",
    },
}

Model Selection Rationale

• Opus for Supreme Commander: highest reasoning for final synthesis
• Sonnet for Strategist, Intel, Tactician, Red Team: strong reasoning at moderate cost
• Haiku for Scout, Logistics: speed-critical roles with simpler reasoning needs

Spawning Example

# Lead spawns chief-strategist teammate
tmux split-window -h "CLAUDECODE=1 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 \
  claude --agent-id chief-strategist@war-room-20260208 \
         --agent-name chief-strategist \
         --team-name war-room-20260208 \
         --agent-color '#4ECDC4' \
         --parent-session-id $SESSION_ID \
         --model sonnet"

Invocation Safety

All external experts are invoked using asyncio.create_subprocess_exec which:

• Does NOT use shell interpretation (no injection risk)
• Passes arguments as a list (safe)
• Captures stdout/stderr separately
• Handles timeouts gracefully

Agent teams teammates are invoked via tmux split-window with CLI identity flags: the same safety model applies (no shell interpretation of user input).

Merkle-DAG Anonymization

Purpose

Research shows LLMs exhibit "self-preference bias" - favoring their own outputs or outputs from the same model family. The Merkle-DAG structure:

1. Anonymizes contributions during deliberation 2. Tracks versions across rounds 3. Verifies integrity via cryptographic hashes 4. Reveals attribution only after decision

Data Structure

from dataclasses import dataclass, field
from datetime import datetime
from hashlib import sha256
from typing import Optional


@dataclass
class DeliberationNode:
    """A single contribution in the deliberation graph."""

    node_id: str           # Short hash (first 16 chars)
    parent_id: Optional[str]  # Previous version (for revisions)
    round_number: int      # Which deliberation round
    phase: str             # intel, coa, red_team, vote, premortem, synthesis

    # Anonymized during deliberation
    anonymous_label: str   # "Response A", "Expert 2", etc.
    content: str           # The actual contribution

    # Revealed after decision (sealed until then)
    expert_role: str       # "Intelligence Officer", "Red Team", etc.
    expert_model: str      # "gemini-2.5-pro", "qwen-turbo", etc.

    # Merkle linkage
    content_hash: str      # SHA-256 of content only
    metadata_hash: str     # SHA-256 of role + model
    combined_hash: str     # SHA-256 of content_hash + metadata_hash

    timestamp: str         # ISO format


@dataclass
class MerkleDAG:
    """Directed Acyclic Graph tracking deliberation history."""

    session_id: str
    sealed: bool = True    # Attribution hidden until unsealed
    root_hash: Optional[str] = None
    nodes: dict[str, DeliberationNode] = field(default_factory=dict)
    label_counter: dict[str, int] = field(default_factory=dict)

    def add_contribution(
        self,
        content: str,
        phase: str,
        round_number: int,
        expert_role: str,
        expert_model: str,
        parent_id: Optional[str] = None
    ) -> DeliberationNode:
        """Add a contribution and compute hashes."""

        # Compute hashes
        content_hash = sha256(content.encode()).hexdigest()
        metadata_hash = sha256(f"{expert_role}:{expert_model}".encode()).hexdigest()
        combined_hash = sha256(f"{content_hash}:{metadata_hash}".encode()).hexdigest()

        # Generate anonymous label
        label = self._generate_label(phase)

        node = DeliberationNode(
            node_id=combined_hash[:16],
            parent_id=parent_id,
            round_number=round_number,
            phase=phase,
            anonymous_label=label,
            content=content,
            expert_role=expert_role,
            expert_model=expert_model,
            content_hash=content_hash,
            metadata_hash=metadata_hash,
            combined_hash=combined_hash,
            timestamp=datetime.now().isoformat()
        )

        self.nodes[node.node_id] = node
        self._update_root_hash()
        return node

    def _generate_label(self, phase: str) -> str:
        """Generate anonymous label for phase."""
        if phase not in self.label_counter:
            self.label_counter[phase] = 0
        self.label_counter[phase] += 1
        count = self.label_counter[phase]

        # Use letters for COAs, numbers for others
        if phase == "coa":
            return f"Response {chr(64 + count)}"  # A, B, C...
        return f"Expert {count}"

    def _update_root_hash(self) -> None:
        """Update root hash from all leaf nodes."""
        if not self.nodes:
            self.root_hash = None
            return

        # Combine all node hashes
        combined = ":".join(sorted(n.combined_hash for n in self.nodes.values()))
        self.root_hash = sha256(combined.encode()).hexdigest()

    def get_anonymized_view(self) -> list[dict]:
        """Return contributions with attribution masked."""
        return [
            {
                "label": node.anonymous_label,
                "content": node.content,
                "phase": node.phase,
                "round": node.round_number,
                "hash": node.node_id,  # Verifiable but not attributable
            }
            for node in self.nodes.values()
        ]

    def unseal(self) -> list[dict]:
        """Reveal full attribution after decision is made."""
        self.sealed = False
        return [
            {
                "label": node.anonymous_label,
                "content": node.content,
                "phase": node.phase,
                "round": node.round_number,
                "expert_role": node.expert_role,
                "expert_model": node.expert_model,
                "hash": node.node_id,
                "verified": self._verify_node(node),
            }
            for node in self.nodes.values()
        ]

    def _verify_node(self, node: DeliberationNode) -> bool:
        """Verify node hash integrity."""
        expected_content = sha256(node.content.encode()).hexdigest()
        expected_meta = sha256(f"{node.expert_role}:{node.expert_model}".encode()).hexdigest()
        expected_combined = sha256(f"{expected_content}:{expected_meta}".encode()).hexdigest()
        return expected_combined[:16] == node.node_id

Version Tracking

When experts revise their positions (Delphi mode):

flowchart LR
    subgraph Round1["Round 1"]
        A["COA-A (v1)<br/>hash: abc123<br/>parent: null"]
    end

    subgraph Round2["Round 2"]
        B["COA-A (v2)<br/>hash: def456<br/>parent: abc123"]
    end

    subgraph Round3["Round 3"]
        C["COA-A (v3)<br/>hash: ghi789<br/>parent: def456"]
    end

    A -->|revises| B
    B -->|revises| C

    C --> Root["Root Hash (Round 3)<br/>SHA256(all_leaf_hashes)"]

Serialization

def to_json(self) -> dict:
    """Serialize DAG for persistence."""
    return {
        "session_id": self.session_id,
        "sealed": self.sealed,
        "root_hash": self.root_hash,
        "nodes": {
            nid: {
                "node_id": n.node_id,
                "parent_id": n.parent_id,
                "round_number": n.round_number,
                "phase": n.phase,
                "anonymous_label": n.anonymous_label,
                "content": n.content,
                "expert_role": n.expert_role if not self.sealed else "[SEALED]",
                "expert_model": n.expert_model if not self.sealed else "[SEALED]",
                "content_hash": n.content_hash,
                "metadata_hash": n.metadata_hash,
                "combined_hash": n.combined_hash,
                "timestamp": n.timestamp,
            }
            for nid, n in self.nodes.items()
        }
    }

Usage in Deliberation

During COA Development (sealed)

# Expert contributions are anonymized
dag.add_contribution(
    content=coa_response,
    phase="coa",
    round_number=1,
    expert_role="Field Tactician",
    expert_model="glm-4.7"
)

# Present to Red Team anonymized
anonymized = dag.get_anonymized_view()
# Returns: [{"label": "Response A", "content": "...", ...}]

During Synthesis (unsealed)

# Supreme Commander sees full attribution
revealed = dag.unseal()
# Returns: [{"label": "Response A", "expert_role": "Field Tactician", ...}]

Integrity Verification

After session, verify no tampering:

def verify_session_integrity(dag: MerkleDAG) -> bool:
    """Verify all nodes hash correctly."""
    for node in dag.nodes.values():
        if not dag._verify_node(node):
            return False
    return True

Reversibility Assessment Framework

Evaluate decision reversibility to calibrate deliberation intensity. Based on Amazon's Type 1/Type 2 framework with quantified scoring.

Core Principle

"Make reversible decisions as soon as possible and make irreversible decisions as late as possible."

(Jeff Bezos)

The Problem: Organizations tend to apply heavyweight Type 1 processes to all decisions, stifling speed and innovation. This framework ensures resources match stakes.

Reversibility Score (RS)

Five Dimensions

Score each dimension on a 1-5 scale:

Calculation

Reversibility Score (RS) = Sum of Dimensions / 25

RS Range: 0.04 (most reversible) to 1.0 (least reversible)

Decision Type Classification

Default Thresholds (can be overridden at session start):

Note: These thresholds are defaults calibrated for general use. Teams with different risk tolerances can adjust at session initialization.

Scoring Guide

Reversal Cost

Time Lock-In

Blast Radius

Information Loss

Reputation Impact

Example Assessments

Example 1: Add retry logic to API client

RS = 6/25 = 0.24 → Type 2 (Express)

Recommendation: Chief Strategist can decide alone. Execute quickly.

---

Example 2: Migrate from PostgreSQL to MongoDB

RS = 20/25 = 0.80 → Type 1A (Full Council)

Recommendation: Convene full council. Extensive Red Team review required.

---

Example 3: Change public API pricing model

RS = 23/25 = 0.92 → Type 1A+ (Full Council + Delphi)

Recommendation: Maximum deliberation. Delphi convergence required. Consider external advisors.

Integration with War Room

Threshold Configuration

At session initialization, the War Room prompts for threshold customization:

War Room Session Initialization
═══════════════════════════════
Problem: [User's decision statement]

Reversibility Thresholds (press Enter for defaults):
  Express ceiling    [0.40]: _
  Lightweight ceiling [0.60]: _
  Full Council ceiling [0.80]: _

Using: express ≤0.40 | lightweight ≤0.60 | full_council ≤0.80 | delphi >0.80

Common Adjustments:

Automatic Mode Selection

def select_deliberation_mode(
    reversibility_score: float,
    thresholds: dict | None = None
) -> str:
    """Map RS to war room mode with configurable thresholds."""
    # Defaults (can be overridden at session start)
    t = thresholds or {
        "express": 0.40,
        "lightweight": 0.60,
        "full_council": 0.80,
    }

    if reversibility_score <= t["express"]:
        return "express"  # Single expert, immediate
    elif reversibility_score <= t["lightweight"]:
        return "lightweight"  # Default panel
    elif reversibility_score <= t["full_council"]:
        return "full_council"  # All experts
    else:
        return "full_council_delphi"  # Iterative convergence

Escalation Override

Supreme Commander may override automatic classification when: 1. Novel domain with uncertain reversibility 2. Precedent-setting decision (future decisions will follow) 3. Compound decisions (multiple sub-decisions with varying RS) 4. Political/organizational sensitivity beyond technical scope

Resource Allocation by Type

Quick Assessment Heuristics

For rapid classification without full scoring:

Likely Type 2 (Two-Way Door)

• Can be A/B tested
• Affects only internal systems
• Has natural rollback mechanism
• No public announcement required
• Team-level decision authority

Likely Type 1 (One-Way Door)

• Requires data migration
• Changes external contracts/APIs
• Involves personnel decisions (hiring/firing)
• Requires public commitment
• Affects security/compliance posture
• Closes off future architectural options

Anti-Patterns

Over-Classification (Most Common)

Symptom: Treating everything as Type 1 Impact: Slow decisions, missed opportunities, innovation stagnation Fix: Default to Type 2 unless specific irreversibility criteria met

Under-Classification

Symptom: Rushing irreversible decisions Impact: Costly mistakes, rework, reputation damage Fix: When uncertain, score the dimensions explicitly

False Reversibility

Symptom: "We can always change it later" without considering cost Impact: Technical debt accumulation, stranded investments Fix: Explicitly score Reversal Cost dimension

STOP-LOP-KNOW Triggers

For Type 1 decisions, finalize when:

1. STOP: Information gathering has plateaued (diminishing returns) 2. LOP: Losing meaningful opportunities by waiting 3. KNOW: Clarity has emerged about the right choice

Do NOT wait for 100% certainty on Type 1 decisions: wait for the right moment.

Audit Trail

All reversibility assessments are logged:

assessment:
  session_id: war-room-20260122-143022
  decision: "Database migration strategy"
  dimensions:
    reversal_cost: 5
    time_lock_in: 4
    blast_radius: 5
    information_loss: 4
    reputation_impact: 2
  reversibility_score: 0.80
  decision_type: "Type 1A"
  deliberation_mode: "full_council"
  assessor: "Chief Strategist"
  override: null
  timestamp: "2026-01-22T14:30:22Z"