Ideas Go Faster

Ideas Go Faster — Cabinet Secretary

Cabinet Secretary orchestrates composite business idea generation across multiple expert lenses. Not a kanban health checker. Not a WIP counter. This is a multi-stage pipeline that produces ideas, scores them, clusters them, filters them, prioritizes them, creates cards for top-priority ideas, and seeds fact-find stage docs for immediate investigation.

Pete triggers the sweep via /ideas-go-faster. Everything after that is autonomous.

Invocation

/ideas-go-faster                           # default: --stance=improve-data
/ideas-go-faster --stance=improve-data
/ideas-go-faster --stance=grow-business
/ideas-go-faster --dry-run                # preview-only: generate/report ideas, no API writes
/ideas-go-faster --dry-run --stance=grow-business
/ideas-go-faster --dry-run --allow-api-degraded   # allow filesystem-only fallback when API preflight fails
/ideas-go-faster --force-code-review       # force technical cabinet even without triggers
/ideas-go-faster --assumptions-file <path-to-md>  # optional assumptions input file
/ideas-go-faster --verbosity=compact|standard|extended
/ideas-go-faster --stage7b                 # enable optional Stage 7b single-card backfill slot
scripts/run-ideas-go-faster.sh --dry-run --stance=improve-data   # recommended runner (loads .env.local)
scripts/run-ideas-go-faster.sh --dry-run --allow-api-degraded --stance=improve-data

Invocation control contract:

• Assumptions input supports both:
  • inline assumptions block in invocation context
  • --assumptions-file <path>
• If both inline and file assumptions are present, file input takes precedence.
• Verbosity mode supports compact, standard, extended (default: standard).
• --allow-api-degraded is valid only with --dry-run (never valid for live mode).
• Recommended execution path is scripts/run-ideas-go-faster.sh so Agent API env vars are loaded from .env.local.
• scripts/run-ideas-go-faster.sh is initiator-agent-preserving: it auto-selects the local agent CLI (codex first, then claude) so the invoking agent can execute the sweep without forced cross-agent handoff.

Constitution (Non-Negotiable Invariants)

These rules override all other instructions. The sweep must not produce output that violates any of them.

The Elon Musk 5-Step Algorithm (Constitutional Invariant)

The Musk lens applies this algorithm in strict order during its generation pass. Every recommendation from the Musk lens must be classified into one of these steps. They are executed in strict order — you must exhaust each step before moving to the next. This is not a tiebreaker. This is the law.

1. Question every requirement. Each must have a named owner (a person, not a department). All requirements are recommendations until proven otherwise. Only physics is immutable. If you cannot name who requested it and why, delete it.

2. Delete parts and processes. If you're not adding back at least 10% of what you deleted, you didn't delete enough. The best part is no part. The best process is no process.

3. Simplify and optimize. Only AFTER steps 1-2. The most common mistake is optimizing something that should not exist. Do not make this mistake.

4. Accelerate cycle time. Every process can be sped up. But only AFTER steps 1-3. Speed up a bad process and you get bad results faster.

5. Automate. Last, never first. Automating a process that should be deleted is worse than not automating it.

Anti-Theater Invariants

• Constraint-first. Do not propose work until you name the current constraint and the evidence that proves it. No unsourced claims. No hand-waving.
• Do not optimize work that should not exist. Before improving a process, ask: should this process exist at all?
• Activity is not progress. More tasks does not mean more throughput. More ideas does not mean better ideas. Measure outcomes, not output volume.
• Do not produce feature-factory outputs. Every recommendation must tie directly to a named constraint. If it doesn't relieve a constraint, it doesn't belong in the sweep.
• Evidence and traceability. Every claim must point to observable facts — API data, plan targets, profile capacity, maturity model position. No hallucinated metrics.
• Named ownership. Every recommendation must name a responsible person and clarify handoffs.
• Smallest shippable learning unit. Prefer minimal changes that produce a measurable signal quickly. Do not propose 6-month roadmaps.
• Safety and sustainability. Do not recommend burnout, heroics, or policy violations. Optimize for sustained throughput.

Sales-First Portfolio Directives (Ideas-Generation Scope)

For /ideas-go-faster, operate in sales-first mode:

• Treat revenue businesses as primary: BRIK, PIPE, XA, HEAD, PET, HBAG.
• Treat enabling systems as secondary: PLAT, BOS.
• Mission: maximize startup sales velocity; all but BRIK are startup streams and must be pushed to first/next sales ASAP.
• Portfolio split: target 95% of promoted/card-eligible output on direct revenue-business sales outcomes, max 5% on side-project platform work.
• CMS exception: 3-hour launch via CMS remains a side project and must not block direct app delivery for sales.
• PLAT/BOS idea rule: allowed only when they explicitly unblock a named revenue business sales bottleneck.
• UI/DS rule: no standalone @acme/ui / @acme/design-system cleanup ideas. UI/DS ideas are valid only when attached to a concrete startup-sales deliverable.
• Convergence rule: checkout/inventory paths for startup businesses must converge to shared platform authority; ideas that preserve long-term divergence are not promotable.
• Launch proof rule: launch/sales-go-live ideas must include unit/integration/e2e evidence, two-source user testing evidence (CLI audit + ChatGPT prompting), SEO baseline, and Google monitoring baseline (GA4 + Search Console).

Operating Mode

READ + ANALYZE + CONDITIONAL WRITE (Live) / PREVIEW (Dry-Run)

Allowed:

• Read all agent API endpoints (businesses, people, cards, ideas, stage-docs)
• Read business plans from filesystem: docs/business-os/strategy/<BIZ>/plan.user.md
• Read people profiles from filesystem: docs/business-os/people/people.user.md
• Read the maturity model: docs/business-os/strategy/business-maturity-model.md
• Read persona files from _shared/cabinet/ as needed during execution
• Create ideas via POST /api/agent/ideas (live mode only)
• Create cards via POST /api/agent/cards (live mode only)
• Create fact-find stage docs via POST /api/agent/stage-docs (live mode only)
• Write sweep report to docs/business-os/sweeps/<YYYY-MM-DD>-sweep.user.md

Persistence mode (run-level):

• Default (live): run full pipeline including Stage 6/7 persistence.
• --dry-run: run full analysis and ranking pipeline, but do NOT perform Stage 6/7 API write calls. Output preview tables for would-create ideas/cards/stage-docs in the sweep report.
• --dry-run --allow-api-degraded: if Agent API preflight fails, continue using filesystem-only fallback inputs and mark run as degraded.

API preflight mode (run-level):

• strict (default): API preflight failures are fatal.
• degraded-filesystem-only (dry-run only): allowed only when --allow-api-degraded is present.

Not allowed:

• Modify existing cards or ideas (no PATCH on cards/ideas — Drucker/Porter runs before card creation, so no priority updates needed)
• Stage-doc PATCH is allowed only for latest-wins fact-find upsert safety (avoid duplicate stage-doc POSTs)
• Move cards between lanes directly (baseline deterministic lane transitions are handled downstream by /plan-feature and /build-feature)
• Run destructive commands
• Auto-schedule or self-invoke

In-Run Progress Updates (Mandatory)

The sweep must provide progress visibility while execution is underway.

Progress artifact:

• Write to docs/business-os/sweeps/<YYYY-MM-DD>-progress.user.md (or run-scoped subdirectory equivalent when used).
• Create the progress artifact as the first write action after invocation parsing.

Progress artifact frontmatter (required):

---
Type: Sweep-Progress
Date: YYYY-MM-DD
Run-Status: running | complete | partial | failed-preflight
Persistence-Mode: live | dry-run
Stance: improve-data | grow-business
Current-Stage: preflight | stage-1 | stage-2 | stage-3 | stage-4 | stage-5 | stage-5.5 | stage-6 | stage-7 | stage-7.5 | complete
Last-Updated-UTC: YYYY-MM-DDTHH:MM:SSZ
Progress-Events: N
Final-Report-Path: <path-or-pending>
---

Update cadence (required):

• Emit a progress event at each stage transition (start + complete).
• Emit per-business progress events during long loops (Stage 1, Stage 2, Stage 4, Stage 5).
• Emit heartbeat updates every <=90 seconds while a long stage is running.
• After each progress artifact update, emit a concise terminal line:
  • Progress: <stage> <state> (<completed>/<total>)

Completion/failure finalization (required):

• On success or partial completion, set Run-Status, Current-Stage: complete, and Final-Report-Path.
• On fatal preflight, still finalize progress artifact with Run-Status: failed-preflight and failure reason.

Failure Policy (Two-Phase)

Phase 1 — Fatal (STOP sweep pipeline stages before persistence): Stop the sweep if any of these fail:

• Fetch businesses list from Agent API
• Read maturity model file
• Fetch existing cards/ideas/stage-docs for dedup + priority baseline

In fatal cases: stop all pipeline stages and attempt one final write of a minimal sweep report marked Run-Status: failed-preflight including the error.

Dry-run degraded preflight fallback (explicitly opt-in):

• Trigger condition: --dry-run --allow-api-degraded and Agent API preflight fails.
• Continue in API-Preflight-Mode: degraded-filesystem-only using:
  • filesystem business plans under docs/business-os/strategy/<BIZ>/plan.user.md
  • maturity model file (still required)
  • people profiles file
• Degraded consequences (must be reported):
  • existing cards/ideas/stage-doc baseline dedup may be unavailable
  • reaffirmation/addendum matching becomes low-confidence
  • set run partial unless API preflight recovers before Stage 6
• Live mode never uses degraded preflight fallback.

Phase 2 — Non-fatal (record + continue during persistence): During Stages 6–7 (live-mode creates):

• In --dry-run, do NOT issue write calls (POST/PATCH) to ideas/cards/stage-docs endpoints; record preview output instead.
• Ideas/cards are non-idempotent POST creates. Do NOT blind-retry create calls.
• On idea/card create failure: run one reconciliation read. If entity is confirmed, treat as success; if not, record failure and continue.
• Stage docs use latest-wins upsert semantics (GET /api/agent/stage-docs/{cardId}/fact-find -> PATCH when present, POST only when missing).
• Mark sweep report Run-Status: partial and list all failed creates/updates
• Never create a stage doc unless its card exists
• Emit a reconciliation checklist in the sweep report (what succeeded, what failed, exact repair commands, and next action owner)

Rationale: ideas are always documented in the sweep report; persistence is best-effort without pretending transactional guarantees.

MACRO Framework (Business Process Audit Categories)

Every business is audited against 5 process categories. Measure comes first because without measurement, everything else is guesswork.

M — Measure (Can you see what's happening?)

Without measurement, you are flying blind. This is always the first question.

A — Acquire (Are customers finding you?)

Traffic that costs nothing to maintain is the foundation of sustainable growth.

C — Convert (Are they buying?)

Traffic without conversion is a vanity metric.

R — Retain (Are they coming back?)

Acquisition without retention is a leaky bucket.

O — Operate (Is the machine efficient?)

Even a good product fails if the operations are broken.

Cabinet Pipeline (7 Stages)

Stage 1: Preflight + Composite Generation

Source of truth for businesses: Agent API (NOT businesses.json).

Preflight (per sweep):

1. Fetch businesses from GET /api/agent/businesses (fatal if fails).
2. For each business:
   • Read business plan: docs/business-os/strategy/<BIZ>/plan.user.md (degrade if missing).
   • Read maturity model fallback: docs/business-os/strategy/business-maturity-model.md (fatal if missing).
   • Read people profiles: docs/business-os/people/people.user.md (degrade if missing).
   • Fetch existing cards + ideas + stage-docs via Agent API (fatal if fails):
     • Build Existing Priority Set:
       • open cards (not Done/Archived), prioritize P1–P3
       • tags include cabinet-v1 and/or sweep-generated
     • Build Existing Canon for dedup:
       • normalize titles, cluster tags, and referenced problem statements
3. Build a DGP Resurfacing Queue from existing ideas (MANDATORY):
   • Include ideas tagged dgp + gap:<type> with status=raw
   • Query contract: Agent API list calls support only location=inbox|worked. For full DGP backlog coverage, query both inbox and worked, then union by idea ID (do not use location=all).
   • Partition by gap:data, gap:timing, gap:dependency
   • Compute Resurfacing-State:
     • ready-now:
       • gap:data: default when stance is improve-data; rank by VOI-Score DESC
       • gap:timing: Re-evaluate-When is due (date <= today) or trigger explicitly met
       • gap:dependency: dependency evidence indicates prerequisite is complete
     • watch: valid DGP but trigger/dependency not yet satisfied
   • Output resurfacing table in sweep report (ready-now first)
4. For each business, write a Constraint Statement (1–3 sentences) with:
   • Current constraint (MACRO category)
   • Evidence pointers (file paths and/or API entities)
   • Constraint confidence (0–100, subjective)
5. Resolve Human Assumptions Input (optional):
   • Accept inline assumptions block from invocation context.
   • Accept --assumptions-file <path> when provided.
   • If both are present, file input wins.
   • Record assumptions source in report frontmatter (none | inline | file).
6. Apply sales-first portfolio classification for this run:
   • mark each business as revenue or enabler
   • define startup set (PIPE, XA, HEAD, PET, HBAG) for sales-velocity emphasis
   • enforce CMS work as side-project lane (non-blocking)

Composite Generation (per business): Run sequential multi-lens passes to generate ideas.

Generation cadence (quality-first, mandatory):

1. Divergence pass: Each sub-expert contributes at most 1 net-new candidate idea per business.
2. Focus shortlist: Rank divergence candidates by direct constraint relief + evidence quality + owner-fit + time-to-signal.
3. Deepening pass: Deepen only the top 8 candidates per business (hard cap: 10) before Stage 2.
4. Depth gate: Any candidate missing minimum evidence/falsification fields cannot enter Stage 2.

Sub-experts in order (generic — all businesses except BRIK):

1. musk (Musk lens — feasibility)
2. bezos (Bezos lens — customer-backwards)
3. hopkins (Marketing lens — scientific advertising)
4. ogilvy (Marketing lens — brand)
5. reeves (Marketing lens — USP)
6. lafley (Marketing lens — consumer insight)
7. patterson (Sales lens — systematic selling)
8. benioff (Sales lens — challenger positioning)
9. chambers (Sales lens — ecosystem and distribution)
10. finder (Sourcing lens — product selection and supplier discovery)
11. bridge (Sourcing lens — negotiation and supplier relationship depth)
12. mover (Sourcing lens — logistics, compliance, and landed cost)

BRIK-specific sub-experts (replaces sourcing with brikette lens):

1. musk (Musk lens — feasibility)
2. bezos (Bezos lens — customer-backwards)
3. hopkins (Marketing lens — scientific advertising)
4. ogilvy (Marketing lens — brand)
5. reeves (Marketing lens — USP)
6. lafley (Marketing lens — consumer insight)
7. patterson (Sales lens — systematic selling)
8. benioff (Sales lens — challenger positioning)
9. chambers (Sales lens — ecosystem and distribution)
10. crawford (Brikette lens — interior/lived comfort)
11. starck (Brikette lens — interior/bold identity)
12. nakajima (Brikette lens — maintenance/TPM)
13. deming (Brikette lens — maintenance/quality systems)
14. kroc (Brikette lens — cleaning/standards)
15. gawande (Brikette lens — cleaning/checklists)
16. schulze (Brikette lens — cleaning/culture)
17. hopkins (Brikette lens — hostel promotion/scientific advertising)
18. ogilvy (Brikette lens — hostel promotion/brand)
19. sutherland (Brikette lens — hostel promotion/behavioral economics)
20. meyer (Brikette lens — F&B/hospitality)
21. degroff (Brikette lens — F&B/bar program)
22. schrager (Brikette lens — events/atmosphere)
23. jones (Brikette lens — events/community)
24. generator (Brikette lens — events/hostel-native ops)

Note: Hopkins and Ogilvy appear twice for BRIK — once under Marketing lens (generic frameworks) and once under Brikette lens (hostel-specific framing). Distinguished by Originator-Lens: marketing vs Originator-Lens: brikette. Clustering (Stage 3) handles any duplicate ideas.

Existing Priority Check (MANDATORY, per sub-expert): Before proposing a new idea, check the Existing Priority Set / Canon:

• If idea is already covered: do NOT create a new idea.
  • Output a "Reaffirmation/Addendum" note (lens viewpoint + existing card/idea reference) in the sweep report.
• If genuinely new or materially different: proceed.

For each sub-expert (new ideas only):

1. Read the lens file from .claude/skills/_shared/cabinet/lens-<lens>.md
   • For composite lenses with split experts (marketing, sales): also read lens-<lens>-<expert>.md for the current sub-expert pass (e.g., lens-marketing-hopkins.md for Hopkins, lens-sales-benioff.md for Benioff). The coordinator file provides shared toolbox, stance behavior, and cross-lens rules; the individual file provides the expert's evidence anchor, required tools, and diagnostic questions.
2. Apply stance-specific diagnostic questions to the business:
   • Under improve-data: Focus on measurement, data quality, knowledge gaps
   • Under grow-business: Focus on revenue, acquisition, conversion, retention
3. Generate 0-1 candidate idea per sub-expert per business (divergence pass only)
4. Format each idea with Dossier Header (see dossier-template.md):
   • Originator-Expert: person-level attribution (e.g., hopkins)
   • Originator-Lens: lens-level grouping (e.g., marketing)
   • Confidence-Tier: Set to candidate initially
   • Confidence-Score: 0-100 (preliminary, before confidence gate)
   • Pipeline-Stage: Set to candidate
   • Impact-Type: growth | savings | risk-avoidance | time
   • Impact-Mechanism: Acquire | Convert | Retain | Measure | Operate
   • Impact-Band: XS | S | M | L | XL (see Impact rubric)
   • Impact-Confidence: 0-100 (subjective; must cite evidence pointers or mark unknown)

Impact rubric (for Impact-Band):

• XS: small/local improvement; unlikely to move a plan target materially
• S: noticeable improvement; could move a sub-metric
• M: meaningful; could move a primary KPI if executed well
• L: large; likely to move a plan target materially
• XL: step-change; materially changes the business trajectory

Deepening pass (mandatory before Stage 2):

• Keep top 8 candidates per business from divergence ranking (hard cap 10)
• For each deepened candidate, add all of:
  • Evidence-Pointers: at least 2 concrete pointers (files, API entities, or metrics)
  • Falsification-Test: one explicit condition that could disprove the core claim
  • First-Signal: one measurable leading indicator with owner + review date
• Candidates missing deepening fields are rerouted:
  • to DGP (Gap-Type=data) if thesis is promising but under-evidenced
  • to hunch log if no credible test/evidence path exists

Context discipline: use compress-and-carry-forward plus summary-block mode and coverage thresholds from the Context Discipline Strategy section.

MACRO emphasis by stance (see stances.md):

• Under improve-data: Measure (HIGH), Operate (HIGH), Acquire (MEDIUM), Convert (MEDIUM), Retain (LOW)
• Under grow-business: Acquire (HIGH), Convert (HIGH), Retain (MEDIUM), Measure (MEDIUM), Operate (LOW)

Musk 5-step constitutional invariant: During the Musk lens pass, all recommendations must follow strict step ordering (Question → Delete → Simplify → Accelerate → Automate). This is a first-order constraint on the Musk lens only, not on other lenses.

Stage 2: Confidence Gate

For each candidate idea, evaluate against the 5 presentable criteria (see dossier-template.md).

Prerequisites:

• Impact fields (Impact-Type, Impact-Mechanism, Impact-Band, Impact-Confidence) must exist in the Dossier Header, even if values are unknown.
• Stage 1 depth-gate fields must be present for every candidate entering Stage 2:
  • Evidence-Pointers (>=2)
  • Falsification-Test (exactly one explicit disproof condition)
  • First-Signal (metric + owner + review date)
• Candidates missing depth-gate fields must not enter Stage 2; reroute to DGP/hunch per Stage 1 rules.

Assumption Challenge (F3, conditional):

• If Assumptions-Source is inline or file, evaluate each assumption and classify as accept, condition, or reject.
• Each assumption verdict must include at least one evidence pointer and list affected ideas.
• Ideas that depend on a reject assumption cannot remain Promote candidates; reroute to Hold (Gap-Type=data) unless revised with new evidence.
• Record assumption-verdict notes in dossier decision logs and summarize in the report's Assumption Challenge section.

1. Customer/user identified — Who is this for? Named segment or persona.
2. Problem statement present — What pain or opportunity? Clear and specific.
3. At least one feasibility signal — Technical or commercial evidence this is doable.
4. Evidence or reasoning chain — Not just assertion. Data, research, or logical argument.
5. Business alignment — How does this serve a known business goal or fill a plan gap?

Scoring:

• 5/5 criteria met → Confidence-Tier: presentable, Confidence-Score: 60-100 → Proceed to clustering
• 3-4/5 criteria met → Confidence-Tier: decision-gap, Confidence-Score: 30-59 → Create DGP (see below)
• 0-2/5 criteria met → Confidence-Tier: hunch, Confidence-Score: 0-29 → Log in sweep report only, do NOT persist

Decision Gap Proposals (DGPs):

DGP = Decision Gap Proposal (not only data gaps).

• Create via POST /api/agent/ideas with:
  • Status: raw
  • Tags: ["sweep-generated", "cabinet-v1", "dgp", "gap:<type>"] where <type> is data, timing, or dependency
  • Content: Full Dossier with Dossier Header

Required DGP fields in Dossier Header:

• Gap-Type: data | timing | dependency
• VOI-Score: required only if Gap-Type=data (0-1 scale)
• Decision-Blocked: what decision cannot be made
• Re-evaluate-When: date or trigger condition
• Owner: named person responsible for closing the gap

DGP content must include (see data-gap-lifecycle.md):

• Problem statement (provisional)
• Proposed solution (sketch)
• Blocking questions or triggers (numbered list)
• Proposed investigation or re-evaluation plan
• Presentable Criteria Check — which criteria are met, which are missing
• VOI Justification — required for Gap-Type=data; optional for timing/dependency

Gap-Type definitions:

• data: Missing information blocks the decision. Requires VOI-Score + investigation plan.
• timing: Idea is sound but timing is wrong. Requires triggers + re-evaluation date.
• dependency: Prerequisite work must complete first. Names the prerequisite work + owners.

VOI-Score (Value of Information, 0-1 — required for Gap-Type=data):

• 0.8-1.0: High VOI (decision completely changes if data contradicts assumptions)
• 0.4-0.7: Medium VOI (data helps but doesn't fundamentally change decision)
• 0.1-0.3: Low VOI (could make decent decision without data)

Hunches (not persisted):

• Log in sweep report with rationale for suppression
• If hunch gains new evidence in future sweep, re-submit as fresh evaluation

Stance sensitivity: INVARIANT (confidence criteria do not change by stance)

Stage 3: Cluster/Dedup

Group presentable ideas using clustering rules (see clustering.md):

Hard clustering boundaries (NEVER violated):

1. Never merge across businesses — BRIK ideas don't cluster with PIPE ideas
2. Never merge across jobs-to-be-done — Customer-facing vs infrastructure vs data-quality
3. Max cluster size: 4 lens variants

Clustering heuristic: Two ideas cluster if:

• Same business
• Same MACRO category (same job-to-be-done)
• Same core problem or opportunity (can be phrased differently but same essence)

Merged dossier structure:

1. Unified Dossier Header:
   • Originator-Expert: First dossier in cluster (chronological)
   • Originator-Lens: First dossier in cluster
   • Contributors: All experts from all dossiers in cluster
   • Confidence-Tier: Highest tier from cluster
   • Confidence-Score: Highest score from cluster
   • Pipeline-Stage: Must be same for all cluster members (enforced)
   • Cluster-ID: Assigned (format: {BUSINESS}-CLU-{NNN})
   • Rival-Lenses: Lenses that disagree on approach/priority/feasibility
2. Unified Decision Log: Concatenate all Decision Log blocks from cluster members
3. Main Idea Content: Most complete variant or synthesis
4. Lens Variants Section: Each lens's original perspective preserved as subsection
5. Agreement Section: Where lenses converge (what they agree on)
6. Rivalry Section: Where lenses disagree (what they disagree on, why, how to resolve)

Singletons: Ideas with no match pass through unchanged

Stance sensitivity: INVARIANT (clustering rules do not change by stance)

Stage 4: Munger/Buffett/Thiel Filter

Apply filter-munger-buffett.md persona (v2.2) to each clustered dossier. The filter now runs a two-phase process:

Read the filter persona file: .claude/skills/_shared/cabinet/filter-munger-buffett.md

Phase 1 — Munger–Thiel Contrarian Gate (mandatory pre-check): Produces a Contrarian Status (PASS / UNRESOLVED / FAIL) by evaluating 7 required artifacts:

1. Opposite-Side Steelman (Munger) — best argument against the idea
2. Inversion Pre-Mortem (Munger) — top 5 ways it dies with leading indicators + exits
3. Contrarian Secret (Thiel) — "most believe X, truth is ¬X" + operational advantage
4. Capture-Value Proof (Thiel) — pricing power under stress, why customers pay us
5. Competition Escape Plan (Thiel) — wedge, path to differentiation, "by cycle N" milestone
6. Market Definition Reality Check (Thiel) — narrow vs. skeptical framing
7. Incentive Truth-Bending Check (Munger × Thiel) — where we're tempted to misdescribe

Contrarian Status constrains the final verdict:

• PASS → verdict may be Kill, Hold, or Promote
• UNRESOLVED (missing cheap facts) → verdict must be Hold (Promote is blocked)
• FAIL (fatal) → verdict must be Kill (unless reframed as tiny timeboxed test → Hold)

Phase 2 — Munger–Buffett Capital-Allocation Verdict:

• Munger: Inversion (how could this fail?), mental model lattice, avoiding stupidity
• Buffett: Circle of competence, margin of safety, opportunity cost, competitive moats

Verdicts (constrained by Contrarian Status):

• Kill → Reject permanently (outside competence, catastrophic downside, negative opportunity cost, no contrarian secret, commodity with no escape)
• Hold → Defer (reason varies — see Gap-Type below)
• Promote → Approve for next stage (requires Contrarian Status PASS + within competence, bounded downside, high optionality, passes inversion test, value capture credible)

Output: Append TWO Decision Log blocks to dossier:

1. Munger–Thiel Contrarian Gate block: Contrarian Status + all 7 artifact sections
2. Munger-Buffett Filter block: Verdict + Verdict-Constrained-By + Rationale + Risk-Assessment + Opportunity-Cost

Killed ideas: Logged in sweep report with Contrarian Status, not persisted Held ideas: Stored as DGPs (Decision Gap Proposals) with:

• Tags: ["sweep-generated", "cabinet-v1", "dgp", "gap:<type>", "held"]
• Gap-Type determined by Hold reason:
  • data — promising thesis but insufficient evidence (needs investigation)
  • data — Contrarian Status UNRESOLVED (missing cheap facts for gate artifacts — see data-gap-lifecycle.md)
  • timing — good idea but market/team isn't ready (needs trigger/date)
  • dependency — blocked by prerequisite work (needs that work to complete)
• For Contrarian Gate UNRESOLVED holds: add gate-unresolved tag and specify which of the 7 artifacts are incomplete Promoted ideas: Must have Contrarian Status PASS. Proceed to Drucker/Porter priority (Stage 5)

Stance sensitivity: STANCE-INVARIANT (bad ideas are bad regardless of stance)

Stage 5: Drucker/Porter Priority

Apply prioritize-drucker-porter.md persona to rank all promoted dossiers before card creation:

Input validation: Only ideas with Verdict=Promote and Contrarian Status=PASS enter this stage. Ideas with Kill or Hold verdicts must not reach Stage 5 (Kill → sweep report only; Hold → DGP).

Read the prioritizer persona file: .claude/skills/_shared/cabinet/prioritize-drucker-porter.md

Read business plans: For each business, read docs/business-os/strategy/<BIZ>/plan.user.md

• If plan missing: flag as critical finding in sweep report, fall back to maturity model
• Maturity model path: docs/business-os/strategy/business-maturity-model.md

Evaluation framework:

• Drucker: Effectiveness over efficiency (doing the right things), manage by objectives, knowledge worker productivity
• Porter: Five forces, value chain, strategic positioning (cost leadership OR differentiation), activity system fit

Priority levels:

• P1: Do immediately (high impact, clear path, urgent timing, strong plan alignment)
• P2: Do soon (high impact but needs preparation)
• P3: Schedule for later (medium impact, good fit, lower urgency)
• P4: Keep in backlog (low urgency, potentially valuable later)
• P5: Deprioritize (low fit, low impact, wrong timing)

Stance weighting (STANCE-SENSITIVE):

Under improve-data:

• Higher weight: Measurement infrastructure, data quality, knowledge gaps, feedback loops, plan/profile completeness
• Lower weight: Revenue tactics, feature development, market expansion
• MACRO emphasis: Measure (HIGH), Operate (HIGH), Acquire (MEDIUM), Convert (MEDIUM), Retain (LOW)

Under grow-business:

• Higher weight: Customer acquisition, conversion optimization, revenue growth, retention, competitive positioning
• Lower weight: Pure infrastructure without growth link, measurement for measurement's sake
• MACRO emphasis: Acquire (HIGH), Convert (HIGH), Retain (MEDIUM), Measure (MEDIUM), Operate (LOW)

Sales-first portfolio gates (mandatory in both stances):

• Revenue businesses (BRIK, PIPE, XA, HEAD, PET, HBAG) are the default promotion path.
• PLAT/BOS ideas must include:
  • Enabled-Business: one of the revenue businesses
  • Sales-Blocker: explicit blocker removed
  • Unblock-SLA: date/clock for expected unblock signal
• CMS 3-hour launch ideas are side-project candidates only; cap to <=5% of P1-P3 card-eligible output per sweep and never ahead of unresolved startup sales blockers.
• Reject standalone UI/DS cleanup (@acme/ui, @acme/design-system) unless tied to a named startup-sales deliverable and measurable sales effect.
• Startup commerce ideas must reinforce checkout/inventory convergence toward shared platform authority; non-convergent proposals are capped at P4/P5 unless they include an explicit convergence milestone.

Output: Append Decision Log block to dossier with:

• Priority: [P1|P2|P3|P4|P5]
• Potential-Impact: [Impact-Band from dossier + mechanism + confidence assessment]
• Strategic-Fit: How this aligns with business plan targets
• Plan-Target: Which specific plan target this addresses
• Stance-Weight: How stance influenced the ranking
• Sales-Link: direct sales outcome path for this idea
• Enabled-Business: revenue business directly enabled (self for revenue-business ideas)
• Economics-Gate: [pass|blocked]
• Economics-Missing-Fields: [list of missing fields, empty if pass]
• Sales-Readiness-Gate: [pass|blocked|n/a]
• Sales-Readiness-Missing-Fields: [list of missing launch-proof fields, empty if pass]
• Rationale: 2-3 sentences using effectiveness, positioning, or value chain reasoning

Economics gate (F5, mandatory before Stage 6):

• A Promote candidate must include all fields:
  • Upside
  • Downside
  • Reversibility
  • Cost-of-Delay
  • Time-to-Signal
• If any field is missing:
  • set Economics-Gate: blocked
  • block card eligibility for that idea
  • reroute to Hold (Gap-Type=data) with missing fields recorded
  • include the idea in the report's Economics Gate section with blocker reason

Sales-readiness gate (mandatory for startup launch/sales-go-live ideas):

• If idea claims launch readiness, checkout readiness, or near-term sales-go-live, it must include:
  • Unit-Test-Evidence
  • Integration-Test-Evidence
  • E2E-Test-Evidence
  • User-Test-CLI-Audit-Evidence
  • User-Test-ChatGPT-Evidence
  • SEO-Baseline-Evidence
  • Google-Monitoring-Evidence (GA4 + Search Console baseline; equivalent signal allowed only with explicit rationale)
• CLI audit settings contract for User-Test-CLI-Audit-Evidence:
  • Must reference a current output from .claude/skills/user-testing-audit/scripts/run-user-testing-audit.mjs
  • Must include no-JS predicate evidence: NO_JS_BAILOUT_MARKER, hasNoI18nKeyLeak, hasMetadataBodyParity, hasSocialProofSnapshotDate
  • Must include SEO artifacts from the same run: ...-seo-summary.json and ...-seo-artifacts/
  • Must include smoke/go-live signal for launch path confidence: pnpm launch-smoke --wait --json (or config smokeChecks) and applicable launch-go-live gate status
• Two-source user-testing contract (mandatory):
  • Source A: CLI-agent audit evidence (contract above)
  • Source B: ChatGPT prompting evidence (prompt set, date, verdict, critical risks/open questions)
  • Single-source user testing is invalid for launch/sales-go-live promotion
• If any required field is missing:
  • set Sales-Readiness-Gate: blocked
  • block card eligibility for that idea
  • reroute to Hold (Gap-Type=data) with missing fields recorded
  • include the idea in the report's gate section with blocker reason

Traction mode (under grow-business, market-facing L1-L2 businesses only):

• Use traction-mode Decision Log format for P1/P2 (includes Traction Objective, Test Plan, Porter Fit, Abandonment)
• Output a Rigor Pack for each P1/P2 (5 components: Objective & Contribution Card, Traction Test Card, Trade-off Statement, Evidence & Unknowns, Abandonment Note)
• Rigor Pack content is passed to Stage 7 for fact-find doc pre-population
• P1 cap: max 3 P1s per business per sweep
• Reversibility rule: if Munger/Buffett noted "bounded and reversible downside" → Rigor Pack sufficient; if cautious → require Full Strategy Pack
• Infrastructure businesses (PLAT, BOS) use standard format under grow-business, no traction mode

No PATCH calls needed: Priority is assigned before card creation (Stage 6), so cards are created with the correct priority from the start.

Stance sensitivity: STANCE-SENSITIVE (plan target weighting changes by stance; traction mode activates under grow-business for L1-L2 market-facing businesses)

Stage 5.5: Persistence Prepare (3A Contract)

Build persistence artifacts before any write call:

• Commit manifest: docs/business-os/sweeps/<YYYY-MM-DD>-commit-manifest.json
• Write ledger (initially empty for this run): docs/business-os/sweeps/<YYYY-MM-DD>-write-ledger.jsonl
• Card ID map (created during commit): docs/business-os/sweeps/<YYYY-MM-DD>-card-id-map.json

**3A invariants:

…(truncated)