phx-full · diff

git:20260724.daea640 to git:20260724.1e78fba

63 added, 119 removed. Audit A to A.

---
name: phx-full
- description: Deliver a large, cross-domain Phoenix feature or complete end-to-end
- system through planning, implementation, verification, and review. Use when several
- coordinated workflows or contexts must ship together. NOT for an existing plan;
- use phx-work.
+ description: Run a portable sequential plan-work-verify-review-compound lifecycle.
+ Use optional generic workers only when Amp makes them available.
---
-
# Full Phoenix Feature Development
- Execute complete Elixir/Phoenix feature development autonomously: research patterns,
- plan with specialist agents, implement with verification, Elixir code review.
- Cycles back automatically if review finds issues.
+ Run the portable lifecycle: discover → plan → work → verify → read-only review →
+ compound. The filesystem is the state machine; no task API or named orchestrator
+ is required.
## Usage
- ```
+ ```text
phx-full Add user authentication with magic links
- phx-full Real-time notification system with Phoenix PubSub
- phx-full Background job processing for email campaigns --max-cycles 5
- phx-full Add magic-link auth --codex
- ```
-
- **Wrong input guard**: if the argument is a path to an existing plan file
- (`.claude/plans/*/plan.md`), do NOT re-plan it. Say so and run `phx-work {path}`
- instead — the plan phase already happened.
-
- ## Flags
-
- - **`--codex`** — Codex CLI joins the review panel on **every** review
- cycle, matching `phx-review --codex`.
- - **Requires** the `codex` CLI. A missing CLI degrades to a SKIPPED note —
- the cycle never fails.
- - **Consensus** findings (flagged by a Claude agent **and** codex) are
- marked HIGH CONFIDENCE.
-
- ## Workflow Overview
-
- ```
- ┌──────────────────────────────────────────────────────────────────┐
- │ phx-full {feature} │
- ├──────────────────────────────────────────────────────────────────┤
- │ │
- │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
- │ │Discover│→ │ Plan │→ │ Work │→ │ Verify │→ │ Review │→ │Compound│→Done│
- │ │ Assess │ │[Pn-Tm] │ │Execute │ │ Full │ │4 Agents│ │Capture │ │
- │ │ Decide │ │ Phases │ │ Tasks │ │ Loop │ │Parallel│ │ Solve │ │
- │ └───┬────┘ └────────┘ └────────┘ └───┬────┘ └────────┘ └────────┘ │
- │ │ ↑ │ ↑ │ │
- │ ├── "just do it" ────────────┤ │ │ │ │
- │ ├── "plan it" ──┐ │ ↓ │ │ │
- │ │ ↓ │ ┌────────┐│ │ │
- │ │ ┌──────────────┐ │ │Fix ││ ┌─────────┐ │ │
- │ │ │ PLANNING │ │ │Issues │└─│ Fix │←┘ │
- │ │ └──────────────┘ │ └───┬────┘ │ Review │ │
- │ │ │ ↓ │ Findings│ │
- │ │ ┌────┴─────────┐ └────┬────┘ │
- │ │ │ VERIFYING │←──────┘ │
- │ └── "research it" ─────┘ (re-verify) │
- │ (comprehensive plan) │
- │ │
- │ On Completion: │
- │ Auto-compound: Capture solved problems → .claude/solutions/ │
- │ Auto-suggest: phx-document → phx-learn-from-fix │
- │ │
- └──────────────────────────────────────────────────────────────────┘
- ```
-
- ## State Machine
-
- ```
- STATES: INITIALIZING → DISCOVERING → PLANNING → WORKING →
- VERIFYING → REVIEWING → COMPLETED → COMPOUNDING | BLOCKED
- ```
-
- Save state in `.claude/plans/{slug}/progress.md` AND via Claude Code
- tasks. Create one task per phase at start, mark `in_progress` on
- entry and `completed` on exit:
-
- ```
- TaskCreate({subject: "Discover & assess complexity", activeForm: "Discovering..."})
- TaskCreate({subject: "Plan feature", activeForm: "Planning..."})
- TaskCreate({subject: "Implement tasks", activeForm: "Working..."})
- TaskCreate({subject: "Verify implementation", activeForm: "Verifying..."})
- TaskCreate({subject: "Review with specialists", activeForm: "Reviewing..."})
- TaskCreate({subject: "Capture solutions", activeForm: "Compounding..."})
+ phx-full Background email jobs --max-cycles 5 --max-retries 2
```
- Set up `blockedBy` dependencies between phases (sequential).
-
- Run COMPOUNDING phase on COMPLETED to capture solved problems in `.claude/solutions/`.
- Suggest `phx-document` for docs and `phx-learn-from-fix` for quick pattern capture.
-
- ## Cycle Limits
+ If input is an existing `.claude/plans/*/plan.md`, do not re-plan. Ask for the
+ native `phx-work` workflow or execute its portable behavior in this session.
+ Defaults are `--max-cycles 10`, `--max-retries 3`, and `--max-blockers 5`.
- | Setting | Default | Description |
- |---------|---------|-------------|
- | `--max-cycles` | 10 | Max plan→review cycles |
- | `--max-retries` | 3 | Max retries per task |
- | `--max-blockers` | 5 | Max blockers before stopping |
+ ## Lifecycle
- Stop with INCOMPLETE status when limits exceeded. List remaining work and recommended action.
+ 1. **DISCOVERING** — inspect relevant code, tests, prior solutions, and optional
+ Tidewave evidence. Tidewave is optional; local files, logs, and `mix` commands
+ are the complete fallback. Record complexity and proposed depth, then wait for
+ the user's plan/implementation gate. Never auto-select a path that bypasses it.
+ 2. **PLANNING** — invoke the runtime's native `phx-plan` skill when available, or
+ execute its portable research checklist and artifact format in this session.
+ Require `.claude/plans/{slug}/plan.md`. Present it and wait for approval before
+ implementation unless the user already explicitly authorized the full run.
+ 3. **WORKING** — execute the plan sequentially. Task selection occurs only here.
+ The full-run limits override any baseline workflow retry defaults. Before every
+ attempt persist cycle, task retry, and blocker counters; if the next attempt
+ exceeds a limit, do not run it. `--max-retries N` means at most N retries after
+ the initial attempt (N+1 total attempts for that task). Mark `[BLOCKED]` and
+ stop at `--max-blockers`.
+ 4. **VERIFYING** — run `mix format --check-formatted`, compile with warnings as
+ errors, focused tests during work, and the full relevant suite at this gate.
+ A failed gate appends FAIL and returns to WORKING only within the cycle limit.
+ 5. **REVIEWING** — invoke portable `phx-review`, or perform the same read-only,
+ changed-file review sequentially. Generic workers are optional. Review never
+ edits. Findings or failures become plan tasks and return to WORKING.
+ 6. **COMPOUNDING** — only after verification and a clean/accepted review. Do not
+ invoke `phx-compound`. Inline contract: write a solution artifact under
+ `.claude/solutions/` only when the run produced a non-obvious, reusable learning,
+ including problem, root cause, solution, and verification. Otherwise append
+ `COMPOUNDING SKIPPED: no reusable learning` to progress. Never edit CLAUDE.md.
- ## Integration
+ Track `INITIALIZING → DISCOVERING → PLANNING → WORKING → VERIFYING → REVIEWING →
+ COMPOUNDING → COMPLETED`, with `BLOCKED` reachable from every phase. A cycle is
+ one `WORKING → VERIFYING → REVIEWING` pass; increment and persist it before
+ entering VERIFYING. At `--max-cycles`, do not begin another pass: stop INCOMPLETE with remaining tasks,
+ failed evidence, and a concrete resume command for this runtime.
- ```text
- phx-full = phx-plan → phx-work → phx-verify → phx-review → (fix → phx-verify) → phx-compound
- ```
+ ## Iron Laws
- Use Ralph Wiggum Loop for fully autonomous execution:
+ 1. **Honor user gates** — discovery and plan approval are not automatic transitions.
+ 2. **Never skip verification or the read-only review phase.**
+ 3. **Only WORKING edits code**; review findings become explicit plan tasks.
+ 4. **Respect every cycle, retry, and blocker limit; stop when exhausted.**
+ 5. **Persist state before stopping** so plan checkboxes and progress evidence resume.
+ 6. **Do not require hooks, MCP, named agents, background tasks, or a task UI.**
- ```bash
- /ralph-loop:ralph-loop "phx-full {feature}" --completion-promise "DONE" --max-iterations 50
- ```
+ ## Resume Ledger
- ## Iron Laws
+ `progress.md` is the sole state authority. It is append-only: never overwrite or
+ maintain a competing authoritative current-state record. Every event has monotonic
+ `seq`, `phase_visit`, `phase`, `cycle`, `task`, `task_attempt`, cumulative
+ `blockers`, `outcome`, and an `evidence` or `artifact` path. On resume, validate the
+ last valid event against evidence, plan checkboxes, artifacts, and git state, then
+ enter only its legal successor. Any WORKING edit after a VERIFYING or REVIEWING
+ pass invalidates both passes; the next legal phase is VERIFYING.
- 1. **NEVER skip verification** — Every task must pass `mix compile --warnings-as-errors` before moving to the next. Run `mix test <affected>` per-phase, full suite only at final gate
- 2. **Respect cycle limits** — When `--max-cycles` is exhausted, STOP with INCOMPLETE status. Do not continue indefinitely hoping the next fix works
- 3. **One state transition at a time** — Follow the state machine strictly. Never jump from PLANNING to REVIEWING — each state produces artifacts the next state needs
- 4. **Discover before deciding** — Always run DISCOVERING phase to assess complexity. Skipping it for "simple" features leads to underplanned implementations
- 5. **Agent output is findings, not fixes** — Review agents report issues. Only the WORKING state makes code changes
- 6. **Skip redundant review agents** — In REVIEWING phase: skip
- verification-runner (work phase already verified), skip iron-law-judge
- if PostToolUse hooks verified all files. For <200 lines changed,
- spawn only elixir-reviewer + security-analyzer (if auth files)
- 7. **ZERO narration in autonomous mode** — This is a HARD rule, not
- a suggestion. NEVER write "Let me now...", "Now I need to...",
- "I'll now...", "Next, I will...", or any preamble before a tool
- call. Just call the tool. Only output text for: decisions that
- need explanation, errors, or phase transitions. If you catch
- yourself narrating, delete the text and just make the tool call.
- (Post-PR validation: 30% of messages still violated this — the
- instruction was too soft. This stronger wording is required.)
+ Completion requires all required plan tasks checked, no unresolved `[BLOCKED]`,
+ the latest VERIFYING PASS after the last edit, the latest accepted REVIEWING after
+ that verify, and COMPOUNDING passed or explicitly skipped.
## References
- - `references/execution-steps.md` — Detailed step-by-step execution
- - `references/example-run.md` — Example full cycle run
- - `references/safety-recovery.md` — Safety rails, resume, rollback
- - `references/cycle-patterns.md` — Advanced cycling strategies
+ - `references/execution-steps.md` — portable phase gates and outputs
+ - `references/example-run.md` — example lifecycle
+ - `references/safety-recovery.md` — resume and blocker recovery
+ - `references/cycle-patterns.md` — bounded cycle patterns