77 lines
3.2 KiB
Markdown
77 lines
3.2 KiB
Markdown
# Crimson Leaf — Kill Protocol (SOP)
|
||
|
||
> **Read by:** Victor (CEO)
|
||
> **Purpose:** Defines exactly what happens when the incubation pipeline is stopped before bootstrap.
|
||
> **Rule:** A killed concept is never truly dead — it is archived for future reactivation.
|
||
|
||
---
|
||
|
||
## When Does This Protocol Apply?
|
||
|
||
A kill event occurs when ANY of the following conditions fire during the pipeline:
|
||
|
||
| Kill Condition | Phase | Trigger |
|
||
|---|---|---|
|
||
| No viable market opportunity found | Phase 1 | Sarah's research shows saturated market or no demand signal |
|
||
| Operator rejects all concepts | Gate 1 | Operator responds with rejection or redirect |
|
||
| Board issues NO-GO | Phase 2 | Victor calls NO-GO in the boardroom |
|
||
| Operator rejects design direction | Gate 2 | Operator requests fundamental changes or kills concept |
|
||
| Roundtable verdict is KILL | Phase 4 | Board reaches consensus to abandon |
|
||
| Operator withholds green light | Gate 3 | Operator does not reply with approval |
|
||
| Incomplete or unapproved design | Phase 6 | Design spec missing required sections or Victor's GO |
|
||
|
||
---
|
||
|
||
## Kill Procedure
|
||
|
||
When a kill condition fires, Victor MUST do the following in order:
|
||
|
||
### Step 1: Declare the Kill
|
||
In the current task's discussion thread, Victor posts:
|
||
|
||
```
|
||
🛑 KILL DECISION — [Company Working Title]
|
||
|
||
Kill Condition: [Which condition fired]
|
||
Phase Reached: [Phase 1 / Gate 1 / Phase 2 / etc.]
|
||
Kill Reason: [2–4 sentences explaining exactly why this concept is not viable NOW]
|
||
Revival Conditions: [What would have to change for this concept to be viable — market shift, new data, etc.]
|
||
```
|
||
|
||
### Step 2: Archive the Artifacts
|
||
Victor does NOT delete any files. All deliverables generated during the killed pipeline are preserved in `docs/` with a `killed-` prefix if they haven't been named already:
|
||
- `docs/market-pitch-{slug}.md` → preserved as-is
|
||
- `docs/company-design-spec-{slug}.md` → preserved as-is (if it exists)
|
||
|
||
### Step 3: Update the Portfolio Ledger
|
||
Victor adds a row to the **Killed Concepts** table in `rag/portfolio.md`:
|
||
- Working title
|
||
- Industry
|
||
- Phase reached
|
||
- Kill reason (one sentence)
|
||
- Date
|
||
|
||
### Step 4: Close the Task Chain
|
||
Victor closes the task with `rag_update: true`. The kill reason and revival conditions are written to RAG so future market research can cross-reference prior kills.
|
||
|
||
---
|
||
|
||
## Reactivating a Killed Concept
|
||
|
||
A killed concept may be reactivated if:
|
||
1. An operator explicitly requests it (e.g., "revisit the healthcare concept from 3 months ago")
|
||
2. New market data emerges that invalidates the original kill reason
|
||
3. Technology shifts make a previously infeasible concept technically achievable
|
||
|
||
**Reactivation procedure:** Victor spawns a fresh `market_research` task, referencing the archived `market-pitch-{slug}.md` as prior context. The pipeline starts from Phase 1 with fresh research. The old design spec is available as reference but is not reused directly.
|
||
|
||
---
|
||
|
||
## What a Kill Is NOT
|
||
|
||
- A kill is **not a failure**. It is capital preservation.
|
||
- A kill is **not permanent**. Revival conditions must always be documented.
|
||
- A kill does **not delete** files or history. Everything is preserved in `docs/`.
|
||
|
||
Victor's motto: *"Kill fast, archive everything, revive when the market is ready."*
|