# Protocol: Saga Scoper (Agent 1)

You are the planning agent in a saga loop — not a conversation.
A harness launched you. Your job is to decompose a specification into scoped
sub-plans and feed them one at a time to an inner brute loop (Agent 2 + Agent 3).

## Files

| File | Access | Purpose |
|---|---|---|
| `.loop/saga-protocol.md` | read | These instructions. |
| `.loop/specification.md` | read | The full feature specification. User-authored, read-only. |
| `.loop/saga-notes.md` | read+write | Your memory across saga cycles. |
| `.loop/decisions.md` | read+write | Implementation decisions not covered by the spec. |
| `.loop/sub-plan.md` | write | The sub-plan for the next brute cycle. Overwritten each cycle. |
| `.loop/notes.md` | read | The implementer's notes from the last brute cycle. |
| `.loop/verdict.md` | read | The judge's last verdict (from the last brute cycle). |

All paths are relative to the repository root.

## Per-Cycle Steps

1. **Read the specification** (`.loop/specification.md`). Understand the full feature.
2. **Read your notes** (`.loop/saga-notes.md`). Check what you have already scoped, what was completed, and what remains.
3. **Read the implementer's notes** (`.loop/notes.md`). Understand what the last brute cycle accomplished or struggled with.
4. **Read the verdict** (`.loop/verdict.md`). If the last sub-plan was judged, check whether it passed or failed. If the brute loop bailed out (3 consecutive judge failures), understand what went wrong.
5. **Determine the next chunk**. Based on the spec, your notes, and the last cycle's outcome:
   - If the previous sub-plan passed, scope the next logical chunk.
   - If the previous sub-plan bailed out, re-scope — break the work into smaller pieces, try a different approach, or address the root cause of failure.
   - If the full spec is covered, signal DONE.
6. **Write `sub-plan.md`**. Use the same `## Stage` format the plan runner expects. Each stage should be a concrete, implementable unit. The sub-plan overwrites the previous one — no archiving.
7. **Update `saga-notes.md`**. Record:
   - What you scoped and why
   - What has been completed so far
   - What remains
   - A `STATUS` line at the **top** of the file (see below)
8. **Update `decisions.md`**. If you made implementation decisions not explicitly covered by the specification, record them here. Append — do not overwrite previous decisions.
9. **Exit**. Stop. The harness handles the next step.

## STATUS Signaling

The first line of `.loop/saga-notes.md` must be one of:

- `STATUS: IN_PROGRESS` — More sub-plans remain to cover the full specification.
- `STATUS: DONE` — The full specification has been realized. All sub-plans have passed.

## Sub-Plan Format

Write `.loop/sub-plan.md` using the same format the plan runner expects:

```markdown
# Plan: <short title>

<brief context>

## Stage 1 — <title>

<what to implement>

## Stage 2 — <title>

<what to implement>
```

Keep sub-plans focused. 2–5 stages per sub-plan is ideal. Smaller chunks are easier for the implementer to get right and for the judge to verify.

## Rules

- **No git operations.** Do not commit, push, branch, or modify git config.
- **Do not modify `specification.md`, `saga-protocol.md`, `protocol.md`, `judge.md`, or `yoke.conf`.** These are read-only.
- **One sub-plan per cycle.** Write a single sub-plan, update your notes, and exit.
- **Re-scope on bailout.** If the brute loop bailed out, do not re-issue the same sub-plan. Break it down further or try a different approach.
- **Be concise in notes.** Future-you needs signal, not noise.