create-anpunkit 2.1.0 → 2.3.0

package/template/.cursor/commands/infra.md

@@ -1,82 +0,0 @@
-Caveman ULTRA mode. You are the ORCHESTRATOR.
-
-Action: $ARGUMENTS (default: "provision" if INFRA.md missing, "verify" if present)
-
----
-
-## PRE-FLIGHT
-
-1. Check `az account show` — if it fails, STOP.
-   Tell me: "Run `scripts/auth-setup.sh` first."
-
-2. Determine mode from $ARGUMENTS or default logic.
-
----
-
-## PROVISION / UPDATE flow
-
-1. Dispatch `infra-provisioner` with the mode.
-
-2. It returns WHAT-IF READY. Show me:
-   - resource list with SKUs and costs
-   - total monthly cost estimate
-   - what-if detail file path
-   Then ask:
-   > "Review docs/research/infra-whatif-<timestamp>.md. Type 'go' to apply,
-   >  or describe changes to make first."
-   WAIT. Do not proceed until I say "go".
-
-3. On "go": pass APPROVED to `infra-provisioner`.
-
-4. On "make changes": dispatch UPDATE with feedback. Loop to step 2.
-
-5. On APPLIED: tell me INFRA.md ✓, .env.test ✓, and any manual steps remaining.
-   Then run AUTH PROOF (below) before declaring Phase 0 complete.
-
----
-
-## AUTH PROOF (one-time, hard rule 16)
-
-Runs after a successful PROVISION (and on demand via `/infra auth-proof`). Proves
-every credential the project's real tests will use is reusable WITHOUT interaction.
-"Reusable" is defined falsifiably: obtainable headlessly TWICE IN A ROW.
-
-1. Enumerate the credentials in scope: the Entra/MSAL app login, plus every
-   external datasource credential referenced in docs/DATAFLOW.md (external rows)
-   and docs/ENDPOINTS.md (auth column) — Azure SQL, Tableau, etc.
-
-2. Dispatch `infra-provisioner` to run, for EACH credential, a headless obtain
-   twice in a row: first call primes (token fetch / connect), second call must
-   succeed from cache/refresh with ZERO prompts. The Microsoft login UI is never
-   driven (ROPC + dedicated MFA-excluded test account; hard rule 8).
-
-3. Result:
-   - All credentials pass twice headlessly -> write `AUTH PROOF: PASS <timestamp>`
-     to docs/INFRA.md with the per-credential list. Phase 0 may complete.
-   - Any credential prompts or fails the second obtain -> NOT reusable. Write
-     `AUTH PROOF: FAIL` + which credential, STOP, tell me what to fix. Phase 0 is
-     not complete until the proof passes.
-
----
-
-## VERIFY flow
-
-1. Check INFRA.md exists. If missing: tell me to run `/infra provision` first.
-2. Dispatch `infra-provisioner` VERIFY mode.
-3. Return drift report. If the AUTH PROOF marker is missing or stale, re-run AUTH PROOF.
-
----
-
-## REGENERATE-ENV flow
-
-1. Check INFRA.md exists.
-2. Dispatch `infra-provisioner` REGENERATE-ENV.
-3. Confirm .env.test rewritten.
-
----
-
-## Notes
-
-- /infra never touches PLAN.md, STATE.md, ISSUES.md, or DESIGN_LOG.md.
-- Infra errors are AZURE UNAVAILABLE or CONFIG ERROR — do NOT route to debugger.
-- If UNDERSPEC: list missing decisions, ask me to fill them, re-dispatch.

package/template/.cursor/commands/log-decision.md

@@ -1,29 +0,0 @@
-Caveman ULTRA mode.
-
-Append an architectural decision to docs/DESIGN_LOG.md. Change: $ARGUMENTS
-
-WHEN this applies — the change is ARCHITECTURAL:
-- new / removed / renamed agent, hook, or command
-- changed workflow rule (escalation, phase gate, test layering)
-- design decision where alternatives were weighed
-
-WHEN it does NOT apply:
-- code changes, features, phase progress -> HISTORY.md
-- bugs + fixes -> ISSUES.md
-- infra changes -> INFRA.md
-
-Steps:
-1. Read docs/DESIGN_LOG.md.
-2. Append a dated line to `## 0. Changelog`, newest first.
-3. If alternatives were weighed, ALSO append a full entry to §5:
-```
-
-### 5.x <decision title>
-
-Options: <a, b, c>. **Chosen: <x>.** <why it won.>
-
-```
-4. If agent/hook/command/file added or removed, update the file inventory (§6).
-5. NEVER rewrite or delete existing entries — append only.
-
-Confirm back in 2-3 lines: what was logged and where.

package/template/.cursor/commands/log-issue.md

@@ -1,23 +0,0 @@
-Caveman ULTRA mode.
-
-Append an entry to docs/ISSUES.md. Error: $ARGUMENTS
-
-Canonical format:
-```
-
-### <short error title — searchable, literal error keywords>
-
-- [x] open      (or “- [x] resolved”)
-- symptom: <what was observed>
-- root cause: <the REAL underlying cause>
-- solution: <exact fix, or “pending”>
-- failed attempts: <approaches that did NOT work>
-
-```
-Rules:
-- title must contain literal error keywords -> grep finds it.
-- root cause is the real cause, not "the line threw an error".
-- always fill "failed attempts" — stops repeated dead ends.
-- open issues go at the TOP; resolved below; archived oldest at bottom.
-
-Confirm the entry back in 2 lines.

package/template/.cursor/commands/overview.md

@@ -1,145 +0,0 @@
-Caveman ULTRA mode.
-
-Recommended: run from plan mode (Shift+Tab). Planning agents are read-only by
-tool grant; plan mode adds a read-only gate on the main session too. Optional.
-
-Goal: stand up a fresh project workspace with a well-grounded plan.
-
----
-
-## Steps
-
-### Round 1 — Initial grill
-
-1. Run the `grill-me` skill to interrogate me. Goal: understand initial scope.
-   Cover: project purpose, success criteria, external services, Azure services
-   needed (type + sizing), region, deployment target (Azure or local for E2E),
-   known constraints, unknowns. ALSO establish:
-   - **has_frontend**: is there a browser-facing UI? If yes, what is the frontend
-     root path (e.g. `src/web/`, `app/`)? This drives the mandatory-E2E path match.
-   Do not stop early. Do not write OVERVIEW.md yet.
-
-Store the round-1 answers as working context — do NOT write OVERVIEW.md yet.
-
----
-
-### Design research
-
-2. Extract DESIGN TOPICS from the round-1 answers. These are things we need
-   to verify before planning:
-   - Each external service mentioned: what does it support at the relevant tier?
-     Quotas, rate limits, known gaps?
-   - Azure services: any sizing or SKU constraints relevant to the use case?
-   - Auth patterns: any MSAL/Entra constraints for this scenario?
-   - Each external DATASOURCE: its DATA UNDERSTANDING (see step 4).
-   - Any other architectural assumption in the round-1 answers worth verifying.
-
-3. Dispatch `researcher` in DESIGN mode with the DESIGN TOPICS list.
-   It returns a terse summary + file paths. For every external datasource it
-   drafts a DATA UNDERSTANDING to `docs/research/datasource-<name>.md`:
-   grain (one row = what?), the fields likely under test with their meaning and
-   real-world nullability/range, a sample-fixture shape, and the assumption that
-   if wrong makes a test meaningless. Read the design-<slug>.md files only if needed.
-
----
-
-### RESEARCH REVIEW (v2.1 — read-and-confirm, not a grill)
-
-4. Surface the design-research findings to me DIRECTLY, phrased as FALSIFIABLE
-   CLAIMS about my systems — not a passive findings dump. For example:
-   "I understand your Tableau extract refreshes nightly and the API is read-only;
-   the `orders` grain is one row per line-item; `status` is never null in practice."
-   For each external datasource, present its drafted DATA UNDERSTANDING for me to
-   confirm or correct. Then:
-   - Minor corrections -> fold forward as seed context for round-2 grill.
-   - A MATERIAL error (wrong service tier, wrong data model, wrong grain) ->
-     re-dispatch `researcher` with the correction, then re-present. Do not carry
-     a known-wrong research file into grill or OVERVIEW.md.
-   A confirmed datasource understanding is recorded as the BASELINE in its
-   `datasource-<name>.md`. (Per-phase delta-confirms happen later in `/phase`.)
-
----
-
-### Round 2 — Research-informed re-grill
-
-5. Run `grill-me` again — a second focused pass. Seed it with:
-   - The round-1 answers (already established — do not re-ask these)
-   - The design-research key findings and new questions raised
-   - The RESEARCH REVIEW corrections
-
-   This pass MUST explicitly cover DATA STRUCTURE and DATAFLOW, especially the
-   STATE FLOW of each key object: what are the core entities, what states does
-   each move through, what transition triggers each change, who writes it, and
-   does any state map to an external system. The re-grill asks whatever else it
-   needs for complete understanding. Do not re-ask what round 1 established.
-
----
-
-### Write OVERVIEW.md + DATAFLOW.md
-
-6. Write docs/OVERVIEW.md from the COMBINED output of round-1 + design-research
-   + research review + round-2. Include:
-   - Project purpose and success criteria
-   - Scope and constraints (informed by research findings)
-   - External services with confirmed capabilities/limits
-   - "Azure services" section: every service with expected SKU
-   - Deployment target (azure-deployed or local-docker for E2E)
-   - `has_frontend: true|false` and, if true, the frontend root path
-   - Known risks / open questions (if any remain)
-
-   OVERVIEW.md is written HERE — after the re-grill, not before.
-
-7. Write docs/DATAFLOW.md — a state-transition table per key object, driven by the
-   round-2 data/state-flow grill. The data-side analogue of ENDPOINTS.md. Columns:
- ```
- # Dataflow — <project name>
- > Maintained from /overview; updated each phase that changes an object lifecycle.
- > Each transition row is one testable unit (drives the CLOSE coverage gate).
-
- | object | states | transition (from→to) | trigger | who writes | external system |
- |--------|--------|----------------------|---------|------------|-----------------|
- | Order  | draft,submitted,fulfilled | draft→submitted | POST /orders/submit | order-svc | — |
- ```
-   Any row whose `external system` is populated ties to a `datasource-<name>.md`.
-
----
-
-### Plan
-
-8. Hand OVERVIEW.md + DATAFLOW.md + design-research findings to the `planner`
-   subagent. PLAN.md MUST:
-   - Start with Phase 0 (infra setup) as the first entry (always).
-   - End with a final code phase that contains the deploy task block.
-   - For any phase whose `changes` touch the frontend root: include ≥1
-     UI-existence acceptance criterion naming the specific user-visible
-     interactive element the phase introduces (not "page renders 200").
-   - Map each phase to the DATAFLOW transitions it is expected to make reachable.
-
-9. Create docs/STATE.md:
-```
-
-# STATE
-
-phase: 0 (pending)
-completed: project bootstrapped — design research, research review, double grill (incl. data/state flow) done
-next: run /infra to provision Azure infrastructure
-blocker: none
-
-```
-10. Create docs/ISSUES.md with header `# Issues` and `## Archived` section.
-
-11. Create empty docs/HISTORY.md.
-
-12. Create docs/INFRA.md from the template (populated by /infra).
-
-13. Create docs/ENDPOINTS.md:
- ```
- # Endpoints — <project name>
- > Maintained by implementer. Updated each phase.
- > Base URL: (populated after deployment phase)
- ```
-
-Then stop and show me PLAN.md + DATAFLOW.md for approval before any phase starts.
-
-Remind me: "Run `/infra` next to provision the Azure environment (Phase 0) and
-run the one-time AUTH PROOF before starting Phase 1."

package/template/.cursor/commands/phase.md

@@ -1,249 +0,0 @@
-Caveman ULTRA mode. You are the ORCHESTRATOR. Route work to subagents —
-you do NOT implement or debug yourself.
-
-Note: subagents cannot talk to the user. Only YOU can.
-
-Target phase: $ARGUMENTS  (default: the phase marked pending in docs/PLAN.md)
-
----
-
-## 0. PRE-FLIGHT
-
-a. INFRA CHECK (phases > 0):
-   - Read docs/INFRA.md. If Phase 0 not done -> STOP.
-     Tell me: "Phase 0 (infra) not complete. Run `/infra` first."
-   - Exception: if $ARGUMENTS is "0", tell me to run `/infra` directly.
-
-b. PHASE STATE CHECK: Read docs/STATE.md and docs/PLAN.md.
-   - No phase in progress, requested is next pending -> START at step 1.
-   - Same phase in-progress -> RESUME from STATE.md "next action".
-   - Different phase in-progress -> STOP. Tell me which phase is open.
-   - Out of dependency order -> STOP. Warn, proceed only if I confirm.
-   - Phase not in PLAN.md -> STOP. Suggest /overview or /replan.
-
-c. FINAL PHASE CHECK: Read docs/PLAN.md. Is this the last phase (no further
-   pending phases after this one)? Record this as IS_FINAL_PHASE=true/false.
-
-d. AUTH LIVENESS GATE (hard rule 16 — replaces the old soft nudge): if this phase
-   will run a real/E2E suite, confirm every credential it needs is live NOW.
-   - If INFRA.md has no `AUTH PROOF: PASS` marker -> STOP: "Auth never proven
-     reusable. Run `/infra` first."
-   - Run `scripts/auth-setup.sh --check` (Entra token obtainable + not expired)
-     and, for each external system this phase touches (docs/DATAFLOW.md external
-     rows + docs/ENDPOINTS.md auth column), confirm its credential is obtainable
-     headlessly. Any failure -> real/E2E is BLOCKED; tell me what to run; the
-     MOCK suite may still proceed.
-
-e. FRONTEND TRIGGER (hard rule 13): read docs/OVERVIEW.md `has_frontend` + the
-   frontend root. Set FRONTEND_PHASE=true iff `has_frontend: true` AND this
-   phase's `changes` (docs/PLAN.md) include any path under the frontend root.
-   This is a PATH MATCH, not a judgment call. Record FRONTEND_PHASE for the GATE.
-
----
-
-## 1. RESEARCH + TDD APPLICABILITY
-
-Dispatch `researcher` in IMPL mode scoped to this phase.
-Returns terse summary + path. Read the file only if needed.
-Unknowns block the phase -> re-dispatch narrowed. No guessing.
-
-DATASOURCE DELTA (hard rule 15): if this phase tests against an external
-datasource, compare what it touches to the confirmed BASELINE in
-docs/research/datasource-<name>.md. If it touches a NEW table/column beyond the
-baseline -> surface my understanding of just that delta as a falsifiable claim;
-WAIT for confirm; append it to datasource-<name>.md. If it touches only confirmed
-data -> proceed with a one-line note, no stop. Real/E2E against an UNCONFIRMED
-datasource is HARD-BLOCKED (mock still runs).
-
-Then classify the phase:
-
-  `TDD_PHASE` = the phase adds or changes a PUBLIC CALLABLE SURFACE (endpoint,
-  exported function/class, CLI command, message contract) assertable from the
-  acceptance spec. Size is NOT the criterion.
-
-- Clear public surface -> `TDD_PHASE=true` -> run the TDD path (§2 → §3a → §3r → §3b).
-- Pure infra/config/doc, no public surface -> `TDD_PHASE=false` -> run the
-  non-TDD path (§2N → §3N).
-- AMBIGUOUS -> default `TDD_PHASE=true`, but STATE the classification + the reason
-  to me, so I can override to non-TDD BEFORE SCAFFOLD fires. (Hard rule 11: never
-  downgrade a TDD phase just to dodge the RED gate.)
-
-=====================================================================
-## TDD PATH  (TDD_PHASE=true)
-=====================================================================
-
-## 2. SCAFFOLD
-
-Dispatch `implementer` in SCAFFOLD mode: interface stubs only (signatures +
-types; bodies raise NotImplementedError / return 501); NO logic, NO tests.
-Returns the stub files + the interface surface.
-
-## 3a. RED
-
-Dispatch `test-author` to write the REAL API suite (+ mock) BLIND against the
-stubs + acceptance, AND emit docs/test-plan-phase-<n>.md (acceptance criteria →
-test names, plus a mandatory "NOT covered / assumptions" section). Place
-contract/ENDPOINTS/DATAFLOW-transition tests in `tests/regression/`, phase-local
-tests in `tests/phase-<n>/`. Run the suite.
-
-RED GATE = every acceptance test COLLECTS cleanly AND FAILS (assertion /
-NotImplemented).
-- Any test PASSES on stubs -> STOP (spec trivial or test wrong); show me.
-- Collection / import / syntax error -> stub mismatch; re-dispatch SCAFFOLD to
-  fix SIGNATURES (not logic); re-run.
-- UNDERSPEC -> STOP; ask me to sharpen the acceptance spec.
-
-## 3r. TEST REVIEW — human gate (hard rule 12)
-
-STOP. Surface docs/test-plan-phase-<n>.md to me: what each acceptance criterion
-maps to, and the "NOT covered / assumptions" section. GREEN cannot begin until I
-approve. On rejection, classify with me:
-  - MISREAD of an adequate spec -> re-dispatch `test-author` with my feedback as
-    added constraint; re-run RED; re-present the test plan.
-  - UNDERSPEC (the acceptance spec itself is too vague) -> sharpen the acceptance
-    spec in docs/PLAN.md, then re-dispatch `test-author` fresh.
-Loop until I approve. This gate is unskippable on TDD phases.
-
-## 3b. GREEN
-
-Dispatch `implementer` in FILL mode with the phase spec + research + the test
-file paths (it MAY read the tests — frozen before logic, no overfit — but must
-NOT edit them). Fill to green. Budget 3, WARN@2, STUCK@3.
-
-If FRONTEND_PHASE (from PRE-FLIGHT e): dispatch `e2e-runner` — MANDATORY, not
-optional (hard rule 13). It reads INFRA.md target, runs `scripts/e2e-stack.sh up`
-/ Playwright / `down`, and captures a screenshot at EACH UI-existence assertion
-regardless of pass/fail to docs/evidence/e2e-phase-<n>/, with a summary in
-docs/research/e2e-<slug>.md. Acceptance spec has no UI-existence criterion ->
-e2e-runner returns UNDERSPEC -> STOP, sharpen the spec.
-
-PHASE GATE (rule 5) -> go to §4/§5/§6 (see GATE below).
-
-=====================================================================
-## NON-TDD PATH  (TDD_PHASE=false)
-=====================================================================
-
-## 2N. IMPLEMENT
-
-Dispatch `implementer` (legacy mode) with phase spec + research summary.
-Returns STUCK -> go to ESCALATE.
-If IS_FINAL_PHASE: phase spec includes the deploy task; confirm the return
-includes "deployed URL" before proceeding.
-
-## 3N. TEST (blind)
-
-Dispatch `test-author`. It writes MOCK + REAL API suites from the acceptance
-spec — never reads the logic. (No TEST REVIEW gate on the non-TDD path — no
-public surface to mis-test. e2e-runner only if FRONTEND_PHASE.)
-
-=====================================================================
-
-## GATE (both paths)
-
-PHASE GATE = current-phase REAL API suite passes AND (FRONTEND_PHASE) E2E passes
-WITH evidence captured AND the accumulated mock regression corpus stays green AND
-every docs/ENDPOINTS.md entry has a regression test AND every REACHABLE
-docs/DATAFLOW.md transition has a regression test (all checked at CLOSE).
-- GATE PASS -> go to CLOSE.
-- GATE BLOCKED (SERVICE UNAVAILABLE, STACK NOT READY, AZURE UNAVAILABLE, FLAKE)
-  -> tell me, wait. Not a code bug. For AZURE UNAVAILABLE: suggest `/infra verify`.
-- GATE FAIL (LOGIC FAIL) -> go to FIX.
-
----
-
-## 4. FIX
-
-Dispatch `debugger` (isolated context) on the specific failure.
-- FIXED -> re-run TEST (and the regression corpus).
-- SERVICE UNAVAILABLE -> tell me, wait. Suggest `/infra verify` if Azure.
-- WARN (2 attempts failed) -> relay immediately, then let debugger finish attempt 3.
-- STUCK -> go to ESCALATE.
-
----
-
-## 5. ESCALATE — circuit breaker. Mode B.
-
-FIRST STUCK: STOP. Present to me: the problem, 3 failed hypotheses, the
-debugger's recommendation, the debug file path. Ask what to do. Wait. Options:
-  (a) "re-research" -> /unstuck
-  (b) hint -> re-dispatch debugger with hint, budget 3
-  (c) "skip" / "re-slice" -> mark blocked, dispatch planner
-
-SECOND STUCK: STOP completely. Full summary — every hypothesis, current state,
-what to try next. Hand control to me.
-
----
-
-## 6. CLOSE
-
-REGRESSION + COVERAGE GATES (before closing — all FAIL HARD, do not close):
-- Run `scripts/regression.sh` (mock corpus). A failure BLOCKS close -> route to FIX.
-- ENDPOINTS COVERAGE: every `docs/ENDPOINTS.md` entry MUST have >=1 test in
-  `tests/regression/`. Zero coverage -> FAIL HARD.
-- DATAFLOW COVERAGE (hard rule 14): every `docs/DATAFLOW.md` transition whose
-  trigger is REACHABLE in the code shipped so far MUST have >=1 test in
-  `tests/regression/`. Zero coverage on a reachable transition -> FAIL HARD.
-  Unreachable transitions list as PENDING (not failed). IF IS_FINAL_PHASE: any
-  transition still PENDING -> FAIL HARD (everything must be live by the last phase).
-- EVIDENCE (FRONTEND_PHASE only, hard rule 13): docs/evidence/e2e-phase-<n>/ must
-  contain at least the per-UI-existence-assertion screenshots. Empty -> FAIL HARD.
-- IF IS_FINAL_PHASE: additionally run `scripts/regression.sh --real` (full real
-  corpus). A failure blocks close.
-
-Mark phase `done` in docs/PLAN.md.
-
-ARCHITECTURE / DATAFLOW SELF-CHECK:
-- Did this phase add/remove/rename an agent, hook, or command, or change a
-  workflow rule? YES -> run `/log-decision`. NO -> state why not.
-- Did this phase add/change an object's STATE LIFECYCLE? YES -> update
-  docs/DATAFLOW.md (hard rule 9) in this CLOSE, and confirm new reachable
-  transitions are covered. NO -> state why not.
-
-IF IS_FINAL_PHASE — FINAL CLOSE sequence:
-
-  a. Run `/synthesize` — pass the signal that this is the final phase so the
-     synthesizer runs the extended pass (OVERVIEW.md + README.md update).
-
-  b. Read docs/ENDPOINTS.md. Surface a "READY TO USE" summary to me:
-     ```
-     ✅ PROJECT COMPLETE
-
-     Deployed at: <base URL from docs/INFRA.md "Deployed base URL">
-
-     ## Endpoints
-     <paste the full docs/ENDPOINTS.md table>
-
-     ## Quick start
-     - Base URL: <URL>
-     - Auth: <Bearer token / API key / none — from ENDPOINTS.md>
-     - Health check: GET <base URL>/health
-
-     ## Docs
-     - Full endpoint catalogue: docs/ENDPOINTS.md
-     - Object/state flow: docs/DATAFLOW.md
-     - Infrastructure: docs/INFRA.md
-     - Project history: docs/HISTORY.md
-     ```
-  Tell me the project is complete and ready to use.
-
-ELSE (not final phase):
-
-  Run `/synthesize`.
-  Tell me phase done + the next phase. Recommend `/clear` then `/phase` next.
-
----
-
-## STATE CHECKPOINTING
-
-After each step, update docs/STATE.md:
-```
-
-phase: <n> (in progress)
-tdd: <true|false>
-frontend_phase: <true|false>
-completed: <steps done so far>
-next: <exact next step>
-blocker: <none or open issue>
-
-```
-Keep STATE.md small — overwrite, do not append.

package/template/.cursor/commands/quick.md

@@ -1,25 +0,0 @@
-Caveman ULTRA mode. Apply `karpathy-guidelines` skill.
-
-Purpose: skip the orchestration tax for a 5-line fix.
-
-Use `/quick` when ALL hold:
-- change is small (under 30 lines) and obvious
-- no new vertical slice
-- no external service contract change
-- not mid-phase
-
-If any fail -> STOP, tell me, recommend `/phase`.
-(Hard rule 11: never route phase-worthy work through `/quick` to dodge the RED gate.)
-
-Steps:
-1. grep docs/ISSUES.md for anything related.
-2. Make the change. Smallest diff that works.
-3. Run it — lint/typecheck/smoke. Show me result.
-4. REGRESSION GUARD: run `scripts/regression.sh` (mock corpus). A break BLOCKS the
-   `/quick` — surface it to me and stop. No agent chain is added.
-5. Error you cannot fix in 2 tries -> STOP. Recommend `/phase`.
-6. Change revealed a bug -> `/log-issue`.
-7. ARCHITECTURE SELF-CHECK: touched an agent, hook, command, or workflow rule?
-   YES -> `/log-decision`.
-
-No STATE.md rewrite, no synthesize, no /clear needed.

package/template/.cursor/commands/replan.md

@@ -1,73 +0,0 @@
-Caveman ULTRA mode.
-
-Recommended: run from plan mode (Shift+Tab). Optional; the command stops for
-your approval regardless.
-
-Use when PLAN.md no longer matches reality. Change: $ARGUMENTS
-
----
-
-## Steps
-
-1. PRE-FLIGHT. Read docs/STATE.md and docs/PLAN.md.
-   - Phase in progress -> tell me which. Ask: revise around it, or is it the
-     thing being changed? Do not silently rewrite a mid-execution phase.
-   - Done phases are FROZEN. /replan never edits or reorders done phases.
-   - Phase 0 (infra) is ALWAYS frozen once done.
-
-2. DESIGN RESEARCH CHECK. Scan $ARGUMENTS for signals that design research
-   is warranted before re-planning:
-   - A new external service is mentioned (Stripe, Twilio, a new Azure service, etc.)
-   - The change involves architecture (a new integration pattern, auth change, etc.)
-   - A service tier or quota change is implied
-   - A new external DATASOURCE or a change to an object's STATE LIFECYCLE
-
-   If ANY of these signals are present: dispatch `researcher` in DESIGN mode
-   with the specific new service/pattern as the DESIGN TOPICS list. For a new
-   datasource, it drafts a DATA UNDERSTANDING; surface it to me as a falsifiable
-   claim and confirm (baseline) before proceeding. Show me the key findings
-   before step 3.
-
-   If none: proceed directly to step 3 (impl-research may still be dispatched
-   in step 3 for non-trivial changes per the original logic).
-
-3. IMPL RESEARCH if needed. If the change is non-trivial but design research
-   was not needed, dispatch `researcher` in IMPL mode to ground the re-plan
-   in facts.
-
-4. RE-PLAN. Dispatch `planner` with the change + current PLAN.md + DATAFLOW.md.
-   It must:
-   - Keep done phases untouched.
-   - Insert / cut / split / merge / reorder only PENDING phases.
-   - Place new phases in correct DEPENDENCY order.
-   - Keep every phase a vertical slice with its own acceptance spec.
-   - Preserve the UI-existence criterion on any frontend-touching phase.
-   - Ensure the LAST pending phase still contains the deploy task block.
-   - Renumber pending phases if needed; update STATE.md `phase:` pointer.
-
-5. RECONCILE THE REGRESSION CORPUS (scoped to `tests/regression/`):
-   - A CUT phase -> retire its regression tests.
-   - A MERGE -> consolidate the merged phases' regression tests.
-   - A REORDER -> keep the tests as-is (contracts are phase-independent).
-   Do NOT touch phase-local `tests/phase-<n>/` here beyond renumbering dirs.
-   After reconciling, run `scripts/regression.sh --real` to confirm the
-   reconciled corpus still passes against live services. A failure -> surface it
-   and stop before approval.
-
-6. RECONCILE DATAFLOW.md (v2.1). If the re-plan adds, cuts, or re-scopes objects
-   or transitions, update docs/DATAFLOW.md in step:
-   - A CUT/removed object or transition -> remove its row(s) and retire the
-     matching regression test(s).
-   - A new object/transition -> add the row(s); mark them PENDING until the phase
-     that makes them reachable runs. The deploy-last / "no PENDING at final phase"
-     invariant (hard rule 14) still holds.
-   - A reorder must not strand a transition as permanently unreachable.
-
-7. SHOW ME the revised phase list + the regression-corpus changes + the
-   DATAFLOW.md changes, and STOP for approval.
-
-8. ARCHITECTURE SELF-CHECK: re-planning is not normally a kit-architecture
-   change. Only run /log-decision if the workflow itself changed (rare).
-
-Report what changed: phases added / cut / split / reordered, regression tests
-retired / consolidated, and DATAFLOW rows added / removed.