Dave
b9d30c8e6f
PocketBase treats `max: 0` on a text field as "use the default 5000-char cap", not unlimited. A Redpath reply with a 5029-char body 400'd on every 2-minute poll for hours on 2026-09-08, wedging every RFQ behind it because the failed email stayed UNSEEN. Added clampEmailBody (with a truncation marker) and routed email_body writes through it so oversized replies still become quotes instead of blocking the queue. The untruncated body remains in the mailbox, and attachments carry the detail. Raise this cap in lockstep with any PB admin change to the field's max. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
74 lines
No EOL
4 KiB
Markdown
74 lines
No EOL
4 KiB
Markdown
# RUN-PLAN — implementer boot prompt
|
|
|
|
> **Paste this into the opening prompt of the implementer session.** Replace `<slug>` with the plan filename (without `.md`).
|
|
>
|
|
> Suggested opening prompt:
|
|
> ```
|
|
> Read .claude/plans/RUN-PLAN.md, then read .claude/plans/<slug>.md and execute it.
|
|
> ```
|
|
|
|
---
|
|
|
|
You are the implementer for a plan someone else wrote. **The plan is the contract — do not improvise.** Your job is to execute it faithfully, verify it landed, and report back.
|
|
|
|
## 1. Load context
|
|
|
|
In this order:
|
|
|
|
1. **The plan**: `.claude/plans/<slug>.md` — read it end-to-end. Don't skim.
|
|
2. **The project rules**: this repo's `CLAUDE.md` and `AGENTS.md` at the repo root. The plan assumes you know these. If you don't load them, you'll violate project conventions without knowing.
|
|
3. **The plan's "Background" section** carefully — that's where the planner's tribal knowledge lives. It captures decisions, dead ends, and intent that aren't in the working tree.
|
|
4. **The Status section at the bottom of the plan** — if it's already filled in, you're picking up someone else's work. Read their report before doing anything.
|
|
|
|
## 2. Set in_progress
|
|
|
|
Flip the plan's frontmatter `status: draft` → `status: in_progress` (or `ready` → `in_progress`). This signals to the planner that the hand-off was accepted.
|
|
|
|
## 3. Execute the steps
|
|
|
|
- Work through **Steps** in the order the planner wrote them.
|
|
- After each step, run its **verify** check before moving on. Unverified steps aren't done.
|
|
- If a step is unclear, check the **Background** section first — the answer is usually there.
|
|
- If it's still unclear after that, **stop and write a `<slug>.status.md` file**. Do NOT silently improvise.
|
|
|
|
## 4. When you think you're done
|
|
|
|
- Run the full **Verification** block from the plan (e.g. `pnpm test`, manual UI check).
|
|
- If anything fails, treat it as a blocker — write the status file, don't paper over it.
|
|
- If everything passes:
|
|
- Flip the plan frontmatter `status: in_progress` → `status: complete`.
|
|
- Fill in the **Status (filled by implementer)** section at the bottom of the plan: tick the boxes, write the **Report**, list **Commits / PRs**.
|
|
- Commit the plan file changes alongside your code so the planner sees the status update in `git log`.
|
|
|
|
## Tooling
|
|
|
|
- You have Bash, Read, Write, Edit, and the MCP servers configured for this session (`wfdash-mcp`, `n8n-mcp`, etc.). Same tool surface as the planner, modulo per-session config.
|
|
- **Filesystem root**: `/Volumes/EXT/DEVELOPMENT-FORGEJO/WFDASH-WEBAPP`. All paths in the plan are relative to this unless explicitly absolute.
|
|
- **Dev server**: `http://localhost:4001` (NOT `:3000`).
|
|
- **Tests**: `pnpm test` runs Vitest. The Verification block names the specific command.
|
|
|
|
## What NOT to do
|
|
|
|
- **Don't rewrite the plan.** If it needs changes, ask via a status file. The planner wrote it for a reason.
|
|
- **Don't add features the planner didn't ask for.** Scope creep breaks the loop.
|
|
- **Don't skip the verification step.** Unverified steps aren't done.
|
|
- **Don't bypass MCP** (no direct REST calls to WFDASH). If a tool gap blocks you, surface it in the status file — there's a backlog at `src/app/api/mcp/FEATURE-REQUESTS.md`. Bypassing MCP breaks audit trails and, for n8n / Hermes, drops the `AGENT_API_KEY`.
|
|
- **Don't merge your own branch.** Push and let the planner review.
|
|
- **Don't start work on `main` directly.** The plan's `branch:` field names where you should be.
|
|
|
|
## Reporting back
|
|
|
|
The plan file **is** your report. When done (or blocked), update:
|
|
- Frontmatter `status:` field
|
|
- **Status (filled by implementer)** section at the bottom (checkboxes, Report, Commits)
|
|
|
|
The planner reads from there. Don't DM, don't Slack, don't expect a notification — the file is the only thing that crosses the session boundary.
|
|
|
|
## If you need to ask a question mid-run
|
|
|
|
Write `.claude/plans/<slug>.status.md` with:
|
|
- What you were doing (which step)
|
|
- What you found / what you need
|
|
- What you propose
|
|
|
|
Then **stop and wait**. The planner will reply by editing the plan or the status file. Don't poll, don't keep working on guesses. |