pi-goal-list-loop-audit 0.15.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 dracon
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,252 @@
+# pi-goal-list-loop-audit
+
+> **Goal. Loop. Audit. Done.**
+
+A pi-coding-agent extension that supervises long-running work to verified completion. The plugin writes a durable goal to disk, drives the agent through an `agent_end`-driven loop, and on each `complete_goal` — spawns an **isolated auditor in a fresh pi session** to verify the work is genuinely done.
+
+The auditor runs in a fresh session with no extensions, no skills, no prompts, no editor. It has only `read` / `grep` / `find` / `ls` / `bash`. It cannot see the implementing conversation. It cannot plant evidence. The implementer cannot fool it.
+
+## Why this exists
+
+Most pi goal extensions — `pi-goal`, `pi-goal-x`, `pi-loop-mode`, `ralphi`, `tmustier-pi-ralph-wiggum` — let the same agent that did the work also be the verifier. **That's the bamboozle trap.** The agent that wrote the implementation also says "I'm done", and the loop trusts them.
+
+`pi-goal-list-loop-audit` separates **implementation** from **verification**. Two independent sessions, two independent read paths, two perspectives.
+
+### Architectural guarantee
+
+| Stage | Protection |
+|---|---|
+| Goal intake | Drafting + Confirm/Reject dialog; nothing activates unconfirmed |
+| Implementation | `agent_end`-driven continuation loop with 5-minute hard backoff cap |
+| Completion | Isolated auditor session + **regression_shield**: raw command output required per verification-contract item, enforced orchestrator-side |
+
+## Quick start
+
+Install:
+```bash
+pi install npm:pi-goal-list-loop-audit
+```
+
+Four top-level commands, that's all:
+
+```
+/goal                              # drafting: agent grills, you Confirm
+/goal "audit the repo"             # no contract clause → agent grills you first (propose is gated on it)
+/goal "Step 1. Step 2. Done when: tests pass."   # has contract → starts now
+/goal status                       # show state
+/goal pause                        # pause
+/goal resume                       # resume
+/goal cancel                       # abort
+/goal tweak "<new objective>"      # edit in place (Confirm dialog)
+/goal archive                      # archived goals, newest first
+/gla                               # open the settings UI (or /gla key=value)
+/list add                          # draft a contract (or a whole batch via items[])
+/list add "<objective>"            # queue one directly
+/list add plan.md                  # file detected → bulk import, one Confirm
+/list add <paste a checklist>      # multi-line paste → same batch flow
+
+(Or just say it: "queue these 10 things…" — the agent manages the list too.)
+
+**Order is the default, not the law**: auto-advance takes the head (FIFO), but
+`/list next <n>` or the agent's `list_activate` tool picks any item — with
+subagents, what gets worked next is a choice, not a position. Numbering always
+matches `/list show`.
+/list                              # show active + queue
+/list next                         # skip current, activate next
+/list remove <n>                   # drop item n from the queue
+/list clear                        # empty the queue
+/loop                              # draft the loop (agent grills; measure is test-run before you confirm)
+/loop start "reduce TODOs" measure="grep -c TODO src.txt | head -1" direction=min
+/loop start "shrink the bundle" measure="..." direction=min time=4 tokens=500000   # arbitrary bounds
+/loop start "reduce TODOs" measure="..." direction=min branch=1   # scratch-branch mode
+/loop status                       # iteration, best, stall, recent values
+/loop stop                         # halt with summary
+```
+
+Subcommands match **exactly** — `/goal pause the pipeline` sets an objective
+about a pipeline; only bare `/goal pause` pauses. (Same rule everywhere, so
+your objectives can start with any verb.)
+
+Drafting rules: **no-args drafts, args-without-a-`Done when:`-clause get
+grilled by the agent (proposing is mechanically blocked until you have
+replied at least once), args-with-a-clause start instantly, a file path is
+bulk direct.** A
+sisyphus-style plan file (checklists, bullets, numbered, plain lines) imports
+as-is — headings become nothing, items become goals. And the drafter itself
+batches: asking for "these 50 tasks" in a `/list` drafting session produces
+ONE confirmed batch, not 50 dialogs.
+Note: every queue item is audited individually, so at hundreds of items the
+audit cost per item is the thing to think about.
+
+**Drafting is the default for long-running things.** `/goal`, `/list add`, and
+`/loop` with no arguments all start a grilling turn that ends in a Confirm
+dialog. For `/loop` specifically, the orchestrator **test-runs the proposed
+measure command once** and shows the real number in the dialog — you validate
+the metric before a single iteration burns tokens.
+
+With `branch=1`, all work lands on a scratch branch (`pi-gla-loop/<ts>-<slug>`):
+improvements are committed, regressions are hard-reset (scratch branch only),
+and on stop you return to your original branch with merge instructions.
+Requires a clean working tree.
+
+Loop 3 is metric-driven: the **orchestrator** runs your `measure` command after
+every agent turn. The agent never self-reports progress — the loop only
+believes a number. There is no auditor in loop 3; the metric is the verdict.
+
+**A loop never completes.** Goal = achievement, loop = process: there is no
+`done=` (v0.15.0 removed it — "improve until X" is a `/goal`). A loop runs
+until `/loop stop`, plateau (`window=5` non-improving iterations — the well is
+dry, not "done"), `max=` iterations, or the arbitrary bounds `time=<hours>` /
+`tokens=<budget>`. And the spec is **alive**: mid-loop the agent can call
+`propose_loop_refine` to sharpen the target or swap the measure — you confirm,
+the orchestrator test-runs and re-baselines, and both eras stay in history.
+
+## Which loop? (the decision rule)
+
+**`/goal`** — one thing, judged *semantically*. Research, features, docs,
+anything where "done" needs a reader. The isolated auditor verifies against
+your `Done when:` contract with quoted evidence.
+
+**`/list`** — many things, judged the same way, in turn. Bulk-import a plan
+or just say "queue these 10 things". Order is the default, not the law:
+`/list next <n>` picks any item.
+
+**`/loop`** — one thing, judged *numerically*, as a **process that never
+completes**. ONLY when a shell command can print a number that honestly
+tracks progress: test failures, TODO count, bundle size, coverage %, lint
+warnings, build time, dep count. The metric IS the auditor here — there is
+no semantic judge, so a fake metric (word count, file exists) is worse than
+no loop. There is no finish line (`done=` was removed in v0.15.0 — "improve
+until X" is a `/goal`); the loop runs until you stop it, the metric plateaus,
+or a time/token bound trips. `/loop` with no args drafts one for you:
+the agent proposes a measure, the orchestrator **test-runs it and shows you
+the real number** before you confirm; if no honest metric exists it will
+redirect you to `/goal`.
+
+## Three loops on one state machine
+
+| Loop | Command | Status |
+|---|---|---|
+| 1. Single ordered goal | `/goal "<objective>"` | **shipped v0.1.0** |
+| 2. Queue of goals | `/list add\|show\|next\|remove\|clear` | **shipped v0.2.0** |
+| 3. Forever-polish loop | `/loop start\|status\|stop` | **shipped v0.3.0** |
+
+Each loop is a different policy class on the same status machine.
+
+## What this fixes vs. pi-goal-x
+
+| Flaw in pi-goal-x | Fix in pi-goal-list-loop-audit |
+|---|---|
+| `detailedSummary` is hand-concat strings | Structured JSON state + native markdown renderer |
+| Stuck-counter has no ceiling — 1-hour waits happen | Hard 5-minute backoff cap, fall through to user notification |
+| Auditor can rubber-stamp after `bash true` | **regression_shield** (shipped v0.2.0): auditor must quote raw tool output per verification-contract item; orchestrator rejects evidence-free approvals |
+| `pause_goal` is fire-and-forget | Clear `pauseReason` surfaced in status + agent feedback |
+| Vague objective + weak auditor = rubber-stamp | Drafting phase with Confirm dialog + isolated auditor + shield |
+| Esc mid-audit just dies | Escape dialog: complete-without-audit / continue (shipped v0.2.0) |
+| Auditor can't compact — context exhaustion mid-audit | Compaction enabled (v0.4.0); safe because the shield is orchestrator-side |
+| Agent can grow subtasks indefinitely | `propose_task_list` with 20/5 caps + Confirm dialog (v0.3.0) |
+
+## Live TUI (always know it's on)
+
+A persistent `gla:` status segment + an above-editor widget show the current
+goal/loop at all times: objective, status, elapsed, tokens, next task or loop
+metric, pause reason, and live auditor progress during audits. If something is
+running, you can see it — no command needed.
+
+## Self-watchdog (liveness is built in)
+
+A 15s heartbeat detects the precise stall condition — active goal/loop + idle
+session + nothing scheduled + quiet for 60s — and re-fires the continuation
+itself. Three consecutive zero-tool turns pause the goal / stop the loop.
+No external watchdog plugin needed.
+
+## Config (one global place, rarely opened)
+
+```
+/gla                                # open the settings UI
+/gla model=provider/id              # auditor model override → GLOBAL
+/gla thinking=high                  # auditor thinking → GLOBAL
+/gla notify='cmd "$1"'              # push on complete/pause/stop → GLOBAL
+/gla tokenlimit=10000000            # per-goal token budget (default: off) → GLOBAL
+/gla tokenlimit=0                   # explicitly no cap (the default)
+/gla project tokenlimit=500         # rare per-project override
+```
+
+Resolution per key: **project > global > defaults**. The auditor defaults to
+your pi session model. When the session provider is extension-registered the
+auditor can't auth it — you're told once (info level) with the fix:
+`/gla model=provider/id`, set once, rarely touched again. The plugin never
+picks a model itself. Thinking follows the session too (floor `high`).
+
+## Token guard
+
+Every goal tracks real token usage; crossing the budget pauses the goal.
+Default 10,000,000 per goal — a runaway threshold, not a big-goal threshold
+(real research/feature goals legitimately burn 2-4M). Tune with
+`/gla tokenlimit=<n>`. Loop 3 doesn't need this cap — it has its own brakes
+(max iterations + plateau).
+
+## Compatibility (what goes well, what conflicts)
+
+**The Two-Driver Rule**: any plugin that drives agent turns on `agent_end`
+conflicts — two supervisors scheduling continuations into one session produce
+contradictory turns. One driver at a time:
+
+- **Hard conflicts** (do not install together): `pi-codex-goal`, `pi-loop-mode`,
+  `pi-goal-x`, `pi-goal*`, `ralphi`, `pi-ralph*`, `pi-autoresearch` (active).
+- **Overlap**: `@badliveware/pi-compaction-continue` — our heartbeat covers
+  stalls while a goal/list/loop is active; both installed may double-nudge.
+- **Installed-but-don't-run-simultaneously**: `@tmustier/pi-ralph-wiggum` —
+  fine to keep, never run a ralph loop while a goal/list/loop is active.
+
+**Goes well with it**: `@juicesharp/rpiv-ask-user-question` (drafting uses its
+structured forms), `@tintinweb/pi-subagents` (spawn research/review subagents
+inside goal work), `@tintinweb/pi-tasks` (session-wide DAGs vs our goal-scoped
+task lists — different granularity), `pi-chrome` (the research/search path for
+goals — logged-in browsing with no extra services; standalone search skills
+like `mmx-cli`/`pi-search-skill` are optional conveniences for bulk queries,
+not requirements).
+
+**Two footnotes**: (1) extension-registered providers work in the main session
+but not the auditor's extension-less session — if audits fail auth, set the
+override once with `/gla model=`. (2) `pi-notify-agent` notifies on every turn;
+`/gla notify=` fires only on goal complete/pause/loop stop.
+
+## Files
+
+```
+extensions/
+  loops/goal.ts                # /goal + /list commands, agent tools, loop driver
+  goal-loop-core.ts            # types, JSONL state, pure helpers
+  goal-loop-auditor.ts         # isolated auditor (fresh session, no extensions)
+  goal-loop-shield.ts          # regression_shield (pure, dependency-free)
+  goal-loop-display.ts         # status line + /goal status rendering
+  goal-loop-forever.ts         # /loop measure/parse/plateau helpers
+  goal-loop-backoff.ts         # 5-min hard cap
+prompts/
+  goal-loop-continuation.md    # loop driver prompt
+  goal-loop-draft.md           # drafting prompt
+  goal-loop-forever.md         # /loop driver prompt
+  goal-loop-forever-draft.md   # /loop drafting prompt
+scripts/
+  smoke.sh                     # live integration harness (tmux + real models)
+tests/                         # 150 unit tests, no live pi required
+docs/DESIGN.md                 # architectural decisions
+PLAN.md                        # milestones, decisions, gates
+```
+
+## Detailed design
+
+See `docs/DESIGN.md`. Milestones and decisions live in `PLAN.md`.
+
+## Installation from source
+
+```bash
+git clone https://github.com/DraconDev/pi-goal-list-loop-audit.git
+cd pi-goal-list-loop-audit
+pi install .
+```
+
+## License
+
+MIT

package/docs/DESIGN.md

@@ -0,0 +1,214 @@
+# pi-goal-list-loop-audit — design
+
+This document records the architectural choices and why. v0.1.0 decisions are
+below; later releases append addenda rather than rewrite history.
+
+## Scope
+
+| Loop | Status |
+|---|---|
+| Loop 1 (single ordered goal with auditor) | **shipped v0.1.0** |
+| Loop 2 (list — many goals in a queue) | **shipped v0.2.0** |
+| Loop 3 (loop — metric-driven forever) | **shipped v0.3.0** |
+| Completion release (compaction, token guard, branch mode) | **shipped v0.4.0** |
+
+## Addendum v0.2.0 (list + shield + drafting)
+
+- **`/list` queue**: items are full goals (objective + contract). The active
+  goal and the queue share one `State`; `setGoal`/`archiveCurrentGoal`
+  preserve `state.list` explicitly (an early draft wiped it). Completing a
+  list-sourced goal auto-activates the next item (v0.10.0: aborts no longer
+  auto-advance — `/list next` and `list_activate` pick explicitly).
+- **regression_shield**: the auditor's report must contain an `<evidence>`
+  block quoting raw tool output per verification-contract item. Enforcement is
+  **orchestrator-side** (`goal-loop-shield.ts`, pure): an `<approved/>`
+  without complete evidence becomes a disapproval. This closes the
+  "`bash true` rubber-stamp" hole pi-goal-x documented as accepted-risk.
+- **Drafting**: `/goal` with no args sends a drafting prompt; the agent
+  clarifies, then `propose_goal_draft` opens a real Confirm dialog. Direct
+  activation stays available via `/goal "<objective>"`.
+- **Inline contract extraction**: one-liner objectives
+  (`Create x. Done when: grep -q ok x`) extract the contract — the
+  line-start-only extractor silently disarmed the shield on every one-liner.
+
+## Addendum v0.3.0 (metric loop + tasks + notify)
+
+- **Loop 3 is metric-driven, not vibes-driven** (the anti-doorknob law: the
+  loop only believes a number). The **orchestrator** runs the user's `measure`
+  command after every `agent_end`; the agent never self-reports. Termination:
+  plateau (`window` stalls), iteration cap, `/loop stop`. No auditor in
+  loop 3 — the metric is the verdict. No git auto-revert: on regression the
+  agent is told to undo its own change (safe with uncommitted user work).
+- **`propose_task_list`** with anti-drift caps (20 tasks / 5 subtasks) —
+  pi-goal-x flaw #4. Confirm dialog before the list is set.
+- **`notify=<cmd>`**: fire-and-forget shell-out on goal complete / goal pause /
+  loop stop, message as `$1`. Settings parser is quote-aware.
+
+## Addendum v0.4.0 (completion)
+
+- **Auditor compaction enabled** (flaw #3 — the last open one). Safety:
+  the shield is orchestrator-side, so compaction can only weaken the
+  auditor's evidence → disapproval, never a false approval.
+- **Token guard**: real accumulation from assistant-message `usage.totalTokens`
+  (deduped across replayed `agent_end` history). Crossing `tokenlimit`
+  (default 1M) pauses the goal with a clear reason.
+- **Loop 3 `branch=1`**: scratch branch `pi-gla-loop/<ts>-<slug>`; commit per
+  improvement, `git reset --hard` per regression — scratch branch only.
+  Refuses non-git dirs and dirty trees; returns to the original branch on
+  stop with merge instructions.
+- **Resumption notice** on `session_start` (replaces the impossible
+  "plugin vanished" self-check: absent code cannot run).
+
+## Scope of v0.1.0 (original)
+
+Single loop only — **loop 1**, the single ordered goal.
+
+**Why ship loop 1 first**: the user asked for it, it's the highest-value loop, and getting the auditor + drafting right matters more than breadth.
+
+## Architectural decisions
+
+### Decision 1: Anti-bamboozle via isolated auditor
+
+The single most important property of this plugin is that the implementing agent cannot bamboozle the verifier. The way to achieve this structurally:
+
+1. The auditor runs in a **fresh pi agent session**.
+2. The auditor has **no extensions, no skills, no prompts, no themes**.
+3. The auditor has only **read-only tools**: `read`, `grep`, `find`, `ls`, `bash` (and `bash` is for re-running user's verifier scripts, not arbitrary).
+4. The auditor **cannot see the implementing conversation**.
+
+This is borrowed directly from `pi-goal-x/extensions/goal-auditor.ts:148-156`. The pattern is sound; we don't improve on it in v0.1.0, we just **fork the proven source and add regression_shield**.
+
+### Decision 2: regression_shield in v0.2.0
+
+v0.1.0 ships the same auditor behaviour as pi-goal-x. The author of pi-goal-x documented an honest caveat (verbatim):
+
+> "the guarantee is deliberately just 'the auditor ran at least one successful tool', not 'it inspected the right content': there is no cheap, honest way to tell a requirement-relevant `read` from `bash true`, an empty `grep`, or a read of an executor-planted file."
+
+We accept this caveat for v0.1.0. v0.2.0 will add **regression_shield**: an explicit requirement that the auditor's report must include raw output (a `cat`, a `grep -A 5 <file>`, a `bash <user-script>`) for every item in `verificationContract`. Without that evidence, the auditor's `<approved/>` is rejected by the orchestrator.
+
+### Decision 3: Hard 5-minute backoff cap
+
+The #1 complaint about pi-goal-x in our audit (user-stated) was "1-hour waits". The cause is exponential backoff with no ceiling.
+
+v0.1.0 ships a hard 5-minute cap. After 5 minutes of consecutive backoff:
+1. TUI badge turns red with "Last activity: 5m+".
+2. User can press `r` to force-continue or `s` to skip to next pending task.
+3. Optional: configure Telegram/web push notification.
+
+### Decision 4: No drafting phase in v0.1.0 (deferred to v0.2.0)
+
+The user identified vague-correction as a key strength of pi-goal-x. But shipping it in v0.1.0 doubles the scope and we won't get the auditor right if we split focus.
+
+v0.1.0 ships `/goal "<objective>"` only — same UX as pi-goal-x's `/goal-set`. v0.2.0 adds the drafting protocol with structured `goal_questionnaire` widget.
+
+This is a deliberate trade-off. If the user wants drafting in v0.1.0, say so and I'll prioritise.
+
+### Decision 5: One package per loop (not three packages)
+
+Some alternatives considered:
+- Three packages: `pi-goal-list-loop-audit`, `pi-goal-list-loop-audit-list`, `pi-goal-list-loop-audit-loop`.
+- One package with three subcommands: `/goal`, `/pi-gla-list`, `/pi-gla-loop`.
+
+We choose **one package with subcommands**. Reasoning:
+- Single install (`pi install npm:pi-goal-list-loop-audit`).
+- All three loops share state machine, schemas, scaffolding.
+- v0.1.0 only ships loop 1, but the package already declares loop 2 and loop 3 as `pi.commands` so users see what is coming.
+
+### Decision 6: Forks pi-goal-x rather than reimplements
+
+Why not write from scratch?
+- The auditor pattern is sound and small (one function: `runGoalCompletionAuditor`).
+- The drafting phase logic is sound and small.
+- The continuation loop is sound and small.
+- The compaction discipline is battle-tested.
+
+We fork pi-goal-x 0.19.0 source. We then **simplify by removing the broken parts** (markdown summaries, unbounded backoff) and **clean the seams** (split the single `goal.ts` file into per-loop files).
+
+This is a **clean break** by decision of the user. We do not interop with `pi-goal-x`'s `.pi/goals/` directory.
+
+### Decision 7: Per-loop file split (superseded)
+
+> **Superseded by consolidation (v0.8.0).** The planned per-loop files below
+> never shipped: loops 1+2 live together in `extensions/loops/goal.ts`
+> (one state machine, one loop driver), loop 3's helpers in
+> `extensions/loops/forever.ts`, rendering in `goal-loop-display.ts`,
+> drafting inline in `goal.ts` + `prompts/`. Kept for history.
+
+| File | Purpose | Lines |
+|---|---|---|
+| `extensions/loops/goal.ts` | Loops 1+2 (single goal + list of goals) | shipped |
+| `extensions/loops/forever.ts` | Loop 3 (metric loop helpers) | shipped |
+| `extensions/goal-loop-core.ts` | Shared state machine, types, JSONL | shipped |
+| `extensions/goal-loop-auditor.ts` | Isolated auditor with regression_shield | shipped |
+| `extensions/goal-loop-display.ts` | Status line + /goal status rendering | shipped |
+| `prompts/goal-loop-continuation.md` | Templated continuation prompt | ~80 |
+| `prompts/goal-loop-auditor.md` | Templated auditor prompt | ~80 |
+| `prompts/goal-loop-draft.md` | Templated drafting prompt | v0.2.0 |
+| `schemas/goal.schema.json` | JSON Schema for goal state | ~50 |
+
+### Decision 8: Status machine
+
+```ts
+type Status =
+  | "drafting"        // v0.2.0
+  | "active"
+  | "auditing"
+  | "complete"
+  | "paused"
+  | "aborted";
+```
+
+States owned by the orchestrator:
+- `active` → next iteration
+- `auditing` → auditor running
+- `complete` → archived
+- `paused` → user-resumable
+- `aborted` → user-cancelled
+
+Transitions:
+```
+drafting → active          (user confirms draft)
+active → active            (continue work)
+active → auditing          (complete_goal called)
+auditing → complete        (auditor <approved/>)
+auditing → active          (auditor <disapproved/>; reset iteration counter)
+active → paused            (pause_goal called, or stuck > 5 min, or empty turn)
+paused → active            (user /pi-gla-resume)
+active → aborted           (user /pi-gla-cancel)
+```
+
+### Decision 9: JSONL state (deterministic compaction)
+
+Goal state lives in `.pi-gla/active.jsonl`. Each line is a state transition. On compaction, the summary is rebuilt deterministically from the JSONL (autoresearch pattern).
+
+This protects against model-generated summaries losing fidelity.
+
+### Decision 10: Hard pause + escape hatches
+
+| Trigger | Action |
+|---|---|
+| `Esc` during auditor | Pause; user picks "complete without audit" or "continue" |
+| `Esc` during agent turn | Pause |
+| User `/pi-gla-pause` | Pause |
+| User `/pi-gla-cancel` | Abort (wipes active goal) |
+| Stuck > 5 min | Pause + notify |
+| Empty turn (no tool calls) | Pause (no momentum) |
+
+## Open follow-ups (post-v0.1.0)
+
+| Priority | Item | When |
+|---|---|---|
+| HIGH | Drafting phase with structured Q&A | v0.2.0 |
+| HIGH | regression_shield for auditor | v0.2.0 |
+| MEDIUM | Native TUI form widget | v0.2.0 |
+| MEDIUM | Loop 2 (list) | v0.2.0 |
+| MEDIUM | Loop 3 (loop) | v0.3.0 |
+| LOW | Telegram push | v0.3.0 |
+| LOW | Sub-task auto-close | v0.3.0 |
+
+## Files
+
+- `docs/DESIGN.md` — **this file**
+- `README.md` — quickstart
+- `audit/pi-name-v3-registry-based.md` — naming rationale
+- `audit/pi-goal-loop-design.md` — earlier design (now superseded)