factory-launch git:20260718.bfd4bdaA

Immutable. This exact content is served forever at /api/v1/blob/70fad616b02c24bd.

---
name: factory-launch
description: Launch the factory's control plane — scaffold and fill FACTORY-ORDERS (weekly mandate + hard budget), STANDING-ORDERS (autonomous-program authority), HEARTBEAT (weekly pulse), and write lifecycle gates for every registered product. A deliberate one-time ritual (re-run to audit); invoke as /factory-launch, not auto-triggered.
---

# /factory-launch — set up the factory's control plane

The moment Hamzaish goes from "a repo with skills" to "a running factory": bounded
unattended work, a formal authority model, and numeric kill gates. Everything here is
operator-local (`.local` files, gitignored) — this is YOUR control plane, not the repo's.

## Preconditions

- `bun run setup` has been run (it scaffolds the three `.local` files from the `.example`
  templates at the repo root; re-run it if they're missing — it never overwrites).

## The walkthrough (one step at a time; confirm before moving on)

1. **FACTORY-ORDERS.local.md — the mandate.** Open it with the operator. Fill:
   - the Mandate section: 1–3 lines, each naming a product + the gate it's chasing this week;
   - the Budget section: the weekly dollar cap for ALL unattended work (suggest $25–50 to
     start — the cap is a feature, not a limitation: scarcity forces scoping).
   Explain: unattended sessions read this file FIRST and refuse work outside it.

2. **STANDING-ORDERS.local.md — the authority table.** Read the three programs
   (overnight-build, gtm-draft, heartbeat) aloud in summary. Confirm the operator accepts
   the iron law: *agents research and draft; the operator publishes, sends, pays.* Any
   scope widening is their explicit, dated edit — never yours.

3. **HEARTBEAT.local.md — the pulse.** Confirm the weekly cadence (default: Monday, before
   the operator's pulse block). Offer to schedule it (cron/scheduled task) or leave it
   manual (`run the HEARTBEAT checklist` in a fresh session).

4. **Gates for every registered product.** Run `bun run check-gates`. For each registered
   product flagged `NO GATES ✗`, write the `gates` block into its `product.config.json`
   with the operator — states-and-dates, channel-matched (see the gate ladder in
   FACTORY-ORDERS.example.md's pointer, or default: validation +4w · launch +30d ·
   traction +90d · pmf +6mo). Dates are absolute (YYYY-MM-DD). The operator sets the
   states; you propose channel-matched defaults. WIP caps to confirm while you're here:
   1 active build · 2 active GTM · rest autopilot.

5. **Verify.** `bun run check-gates` exits 0 and the dashboard shows every registered
   product with a next gate. `bun test ./scripts/control-plane-templates.test.ts` passes.
   Show the operator the dashboard. Done = both green, mandate + cap filled.

## Completion criteria (checkable — no "looks done")

- [ ] All three `.local` control-plane files exist, mandate + weekly cap filled (non-placeholder)
- [ ] `bun run check-gates` → exit 0 (every registered product has a valid gates block)
- [ ] Operator has confirmed the iron law and the WIP caps out loud

## Anti-patterns

- Filling the mandate/budget FOR the operator with invented numbers — the whole point is
  their precommitment, not yours.
- Writing gates a product can't measure (name the metric's source: Stripe, PostHog, GSC).
- Treating this as config to rush through — it's the factory's constitution; 20 minutes
  done honestly beats 5 minutes done cosmetically.