Blackout Loop

# /blackout-loop
Run the following 6 steps for exactly 500 iterations, then stop.
Stop early ONLY if the user says "stop" or "exit".

**Context:** Blackout — Pixel Forge Jam 2026 (April 18–25)
Stack: TypeScript + Phaser 3 + Web Audio API + Vite
Target: Top 5 placement. Browser-playable on itch.io.
Rule: NO AI-generated art or audio — instant disqualification.

---

**Before EVERY iteration:**
1. Read ALL of ./loop-logs/summary-*.md to recall full history
2. Track iteration number (last summary + 1, or 1 if none)
3. Read THEME.txt — if it has the actual jam theme, all decisions must align to it
4. Read DEPLOY_URL.txt for current live build
5. Play the game via Playwright — observe what actually exists right now

---

## STEP 1 — Autonomous Analysis + Plan

You are a senior game developer AND a Pixel Forge Jam judge.
Do NOT just read the PRD and execute it. THINK independently.

Ask yourself:
- What does the game feel like RIGHT NOW when you run it?
- What is the single biggest gap between the current state and a top-5 game?
- What would a judge notice in the first 30 seconds of playing?
- What would make the itch.io page get clicked over 100 other entries?
- Is anything broken, janky, or unpolished that would hurt the rating?
- Is there a mechanic from the PRD that could be made 2x more interesting?
- Is there something NOT in the PRD that would make this game significantly better?

Use **sequential-thinking MCP** to reason through the above.
Use **context7 MCP** to verify any Phaser 3 or Web Audio API calls before writing them.

Write a concrete ITERATION PLAN to ./loop-logs/plan-N.md:
- Current state assessment (what exists, what's broken, what feels good)
- The ONE highest-leverage improvement for this iteration
- Why this beats all other options right now
- Concrete implementation steps
- Success criteria — how will you know it worked?

The PRD is a reference, not a constraint. If you identify something better than
what the PRD says, build the better thing and update the PRD to match.

## STEP 2 — Self-Verify the Plan

Review the plan as the strictest possible game jam judge.

FAIL if any of these are true:
- The plan is vague ("improve the game feel") with no concrete steps
- The plan touches lower-priority things while critical bugs exist
- The plan would introduce AI-generated assets
- The plan would break something currently working
- The plan is just repeating what was done last iteration
- The success criteria are unmeasurable

If FAIL: throw out the plan and write a better one. Repeat until PASS.

## STEP 3 — Build

Execute the plan. Be bold. Make the change completely, not halfway.

**Autonomous improvement rules:**
- If you find a bug while implementing — fix it, don't skip it
- If you see unrelated janky code — note it in the log but don't touch it now
- If an idea is better than the plan — update the plan, then build the better idea
- If a PRD spec feels wrong in practice — change it and document why

**Code standards:**
- TypeScript strict mode — no `any`, no suppressed errors
- Phaser 3: use RenderTexture or Graphics compositing for darkness layer
- Web Audio: brightness value → oscillator frequency, direct mapping, real-time
- Keep entity files under 150 lines — split if larger
- Profile after every rendering change: must stay at 60fps

```bash
git add -A && git commit -m "feat: iter N — <what actually changed>"

STEP 4 — Test + Screenshot + Play

Run everything. Fix every failure before proceeding.

npx tsc --noEmit
npm run build
npx playwright test --reporter=list 2>&1 | tee ./loop-logs/test-results-N.txt

Playwright must verify:

• Canvas loads, no console errors
• Brightness axis responds (Space = dim, Shift = bright)
• Death triggers restart < 1 second
• Frame time < 18ms average over 180 frames (60fps)
• Mobile viewport 768px renders correctly
• Screenshot every meaningful game state → ./screenshots/

Play the game yourself via Playwright automation:

• Simulate a full Level 1 run: move, dim, encounter a moth, die, restart
• Does it feel good? If not, note what feels bad in the status log
• This is the most important test — technical tests pass but feel tests matter more

Build check:

ls dist/index.html && echo "BUILD OK" || echo "BUILD FAILED — do not deploy"

STEP 5 — Polish Review + Status + Deploy

Visual review (open screenshots, judge every one):

• Is the darkness warm and atmospheric, not flat black?
• Are the moths readable and visually compelling?
• Does the brightness shift feel visceral and immediate?
• Would this screenshot make someone click on itch.io?
• Is there ANYTHING that looks unfinished or janky?

Fix anything that fails the visual review before writing the status log.

Write ./loop-logs/status-N.md:

• What was built and what changed vs last iteration
• Test results and FPS measurement
• Visual review findings and fixes
• Current jam day (calculate from April 18) vs where PRD says you should be
• Is the game completable end-to-end right now? (yes/no)
• One honest sentence: "If submitted right now, this would place ___"
• Top 3 things to tackle next

Discord reminder check:

• Day 2, 4, or 6 of jam → print: "⚠️ POST WIP IN PIXEL FORGE DISCORD NOW"
• Include best screenshot filename to share

Deploy if build is clean:

npm run build && npx vercel --prod --yes 2>/dev/null \
  && echo "Deployed successfully" \
  || echo "⚠ Deploy failed — fix before next iteration"

Write live URL to DEPLOY_URL.txt.

Update the PRD if the game has evolved beyond it:

# Append an iteration note to blackout-prd.md
echo "\n---\n## Iteration $N Changes\n<what changed from original PRD>" >> blackout-prd.md

STEP 6 — Compact + Counter + Loop

Write ./loop-logs/summary-N.md (memory for all future iterations):

• Jam day and iteration number
• Exact state of the game (what levels exist, what enemies work, what's broken)
• What was built this iteration and whether it succeeded
• What f