---
description: Guard execution of approved plan/burndown work: forbid reward hacking and feature deletion; require checkpoints, context discipline, safe terminal use, and fresh verification. Apply to approved plan-*.md, complete-everything, or burndown-full runs; binding for any implementation model.
alwaysApply: false
paths:
  - "**/plan-*.md"
  - "**/plans/**"
---

# Composer 2.5 Execution Adapter

You are executing an **already-approved plan** (a `plan-*.md` audit/burndown authored and reviewed with a stronger reasoning model). Your job is faithful, verifiable *implementation* — not re-planning or inventing unrelated scope. When `complete-everything` is explicitly active, its connected closure set (planned + previously parked + discovered blast-radius work) is part of the approved scope. When `burndown-full` is active, repo-wide search determines mechanical scope. These rules are tuned to Composer 2.5's known failure modes and are binding for every change.

## 1. Anti-reward-hacking (highest priority)
Satisfy the **intent**, never just the check. Forbidden:
- Hardcoding expected outputs, asserting trivialities, or narrowing a test so it cannot fail.
- Deleting, skipping, or `.only`-ing a failing test to get green.
- Silencing errors with `@ts-ignore`, `eslint-disable`, broad `try/catch`, or `any` instead of fixing the cause.
- Stubbing/mocking the very thing under test.
- Reconstructing or faking data from caches, snapshots, fixtures, or bytecode to appear correct.

A green suite is necessary, not sufficient. In your trace, state why the change is correct — not just that checks pass.

## 2. Anti-feature-deletion
- Never delete or "simplify away" working code, features, routes, props, handlers, or states to pass checks or reduce scope. If something seems removable, leave it and note it for review.
- When replacing an implementation, preserve the existing public API, behavior, and output unless the approved plan explicitly says otherwise.

## 3. Small, checkpointed units
- Implement one burndown item (or one tight group) at a time. Do not execute the whole plan in a single unattended rollout.
- After each unit: run the relevant tests / typecheck / lint and confirm green.
- **Default mode:** stop at the plan's phase boundaries for review; do not auto-advance.
- **Explicit closure mode:** when the user invokes `complete-everything` or `burndown-full`, a phase boundary is an audit checkpoint, not a permission stop. Persist state, report meaningful progress, and auto-advance until the closure set is empty or a real human gate below is reached.
- If a tool call fails or a step dead-ends, fix that step before continuing — never paper over it and push on.

## 4. Context discipline (200k window)
- Work per-surface / per-module; load only the files needed for the current unit. Do not try to hold the whole repo in context.
- For wide work, build the inventory/checklist first, then iterate through it in batches.

## 5. Terminal caution
- Re-read any shell command before running. For anything destructive (migrations, `rm`, force-push, prod-pointed scripts, DB writes), prefer a dry-run/preview and pause for confirmation. Never run a state-mutating command unless it is in the approved plan.
- Schema DDL, RPCs, edge functions, policies, or buckets explicitly required by the approved plan are not optional follow-ups. With the target environment confirmed, deploy and verify them under `full-stack-ship-discipline`; do not pause solely because the implementation uses a migration.

## 6. Verify-before-trust
- Before each change, state in one line: what behavior must stay identical here — then confirm it does.
- Surface assumptions; if the plan is ambiguous for this item, ask rather than guess.
- Leave a short trace per change (what / why / what was verified) so a human can audit the rollout.

## 7. Follow the plan's conventions
- The target repo is inconsistent by assumption (that's why it was audited). Treat the design-system spec / canonical patterns defined in the plan as the convention — don't invent a new per-file style.

## STOP and ask the human if:
- A real data/contract/endpoint/target is unknown (don't fabricate a substitute).
- A fix would change public behavior/API/output not covered by the approved plan.
- A change touches auth behavior, RLS semantics, secrets/rotation, payments, destructive production-data mutation, or an unconfirmed migration target (consider routing these to a stronger model rather than executing directly).
- Do **not** stop merely because an approved feature requires non-destructive schema DDL on a confirmed target; deploy and verify it under `full-stack-ship-discipline`.
- The only way to pass is a shortcut that doesn't satisfy the real intent.
- Tests would need to be deleted, skipped, or weakened to pass.

When unsure, research before acting (`/research`).