Author SHA1 Message Date
wassnameandPi/OpenAI 2803505cab Archive persistent-worker experiment and adopt simpler prototype direction
WIP archive only: edxeth changes are unaccepted and not installed. pi-goals npm test: 165 passed. Preserve raw patch and terminal capture whitespace.

Co-Authored-By: Pi/OpenAI <288921227+claudypoo@users.noreply.github.com>
2026-09-10 11:35:48 +08:00
wassname 2a7c490eb9 Reduce supervisor turn wakeups 2026-09-10 09:31:48 +08:00
wassname cf7dd31a11 Record pi-goals simplicity brainstorm 2026-09-10 08:33:55 +08:00
wassname 3ad1f47a0e Record post-fix Herdr acceptance 2026-09-09 23:25:52 +08:00
wassname 6e8eb57ad4 Skip small-context Ready compaction 2026-09-09 23:19:19 +08:00
wassname f49be72a30 Fix completed recovery and steer payload validation 2026-09-09 22:54:48 +08:00
wassname 9350d9f54b Fix reviewed compaction recovery boundaries 2026-09-09 22:33:20 +08:00
wassname c67c15ef9c Fix reviewed recovery edge cases 2026-09-09 22:19:32 +08:00
wassname 564ad5e040 Compact approved worker before visible supervisor fork 2026-09-09 22:06:30 +08:00
wassname 82e2d87149 Fix solo recovery review boundaries and peer detachment status 2026-09-09 19:56:23 +08:00
wassname 79ec5f350a Continue approved goals with loud solo recovery on supervisor failure 2026-09-09 17:04:51 +08:00
201 changed files with 19980 additions and 2346 deletions
+3 -3
View File
@@ -1,6 +1,6 @@
node_modules/
dist/
.local/
.pi/
slop/
*.log
.pi/
docs/reviews/raw.jsonl
docs/reviews/err.txt
+131 -26
View File
@@ -1,35 +1,140 @@
# pi-goals contributor notes
## Design
The main chat discusses the plan with the user, then supervises an interactive `goals-worker` in Herdr. Use stock pi-subagents, pi-intercom and pi-schedule-prompt; do not build another transport, scheduler or worker runtime.
> the hope is we can have a smart supervisor like you, with judgment and context. But it doesn't use many tokens as it checks in and sees an overview.
>
> It steers a smaller model, adding perspective and judgment.
>
> Well, I want to see what the supervisor is thinking and saying. That's the whole point: all supervisor thinking and messages should be visible.
— wassname
- Keep supervisor inspection tools. It inspects actual results, delegates implementation and must not weaken the user's goal to accept worker output.
- Put all model-facing prompts in `src/prompts.ts`, in conversation order. Preserve the user's verbatim requirements.
- `/goals` opens actions. New plan starts a discussion without an objective form. Unknown commands never start planning. A changed settled draft opens the approval dialogue; unchanged discussion does not repeatedly reopen it.
- Keep goal titles/status in widgets; omit subtask text. Tasks and evidence remain in the plan.
- Keep startup/compaction plan context, short upkeep reminders and visible editable hourly check-ins. Avoid unchanged-plan repetition and identity-only review turns.
- Keep recoverable solo mode: confirm other writers stopped before taking over. Solo completion is self-verification.
- Record distinct runtime ID, Intercom ID and saved-session path with provenance. A handle or delivery receipt is not proof of liveness or action. User model changes are authorized; do not silently restore an old preference.
## Tests
Run `npm test`, `npm run typecheck` and `npm run lint` before committing.
Run `npm test` before a commit. It includes unit and flow tests plus the RPC review test.
`test/goals.test.ts` exercises current state, file updates and role restrictions with a Pi API mock. `test/rpc-review.test.ts` starts real Pi with a deterministic local model and schema-only worker tools: it checks automatic proposal, editor/discussion and Ready role transition without credits or launching workers. It does not prove Herdr rendering, live message delivery or model judgment.
- `test/*.test.ts` unit and flow tests use a small Pi API mock. They check plan state, tool gates, and plan-file updates.
- `npm run test:rpc` runs `test/rpc-review.test.ts`. It starts the installed Pi executable in RPC mode, uses Pi's real `select` and `editor` protocol, and uses a local deterministic HTTP model. It does not need a credential or spend API credits. This is the closest automated session test.
- Use tmux for visual TUI debugging when the RPC test fails or a terminal-only problem is reported:
For functional acceptance, read `herdr --skill`, confirm `HERDR_ENV=1`, and use `scripts/prepare-trial.mjs` to create an isolated project/profile. Open only new no-focus test panes. Observe the actual planning dialogue and Ready selection, worker attachment, Intercom report, independent artifact inspection and CompleteGoal. Record interventions separately from autonomous success. Preserve nonempty byte/test evidence. Never reload or operate active user research panes. Close test panes when finished.
```bash
tmux new-session -s pi-goals-debug 'cd /path/to/pi-goals && pi -e ./src/index.ts'
```
Known stock limits: stop workers before supervisor reload (later worker exit can crash its stale context); disabled scheduler jobs are deleted on reload/shutdown. Test saved-session/solo recovery without repeating completed work; do not claim these package bugs are fixed here.
Run `/goals <objective>` in that pane. Tmux checks the rendered menu, editor focus, widget, and keyboard handling. RPC does not render the terminal UI.
- `pi -p` has no UI, so it cannot test `Ready`, `Refine`, `Edit`, or `Cancel`.
Keep temporary plans, audits and captures under ignored `.local/`. Git history retains the removed historical material. Do not add root handovers or duplicate READMEs. Never touch human-named files or credentials.
## Functional acceptance: real Herdr workflow
Branch instructions consolidated by Pi/OpenAI from wassname's preferences.
Pi/OpenAI procedure, requested by wassname. Automated tests do not replace this check.
1. Read `herdr --skill` and confirm `HERDR_ENV=1`. Create a separate test pane with `--no-focus` and an isolated temporary Git repo. Never operate the user's existing worker or supervisor panes. Record the code revision and any uncommitted changes being tested.
2. Start real interactive Pi with this extension and an available real model. Use `/goals` with a trivial, bounded deliverable, for example `hello.txt` containing an exact line plus a saved byte-verification log. No GPU, dependencies or unrelated work.
3. Read the rendered planning conversation. Check that ordinary implementation details do not cause needless confirmation questions. Inspect the drafted plan and select Ready through the actual UI.
4. Confirm Ready opens a visible supervisor pane and the worker starts. Read both panes. Verify the supervisor's exact advice is visible, reaches the worker, and helps it progress toward the requested artifact. A delivery receipt alone is not proof.
5. Let the pair produce the artifact, save verification evidence, and complete the real ApproveGoal -> CompleteGoal sequence. Do not perform the task for the worker. Record any manual nudge as intervention, not autonomous success.
6. Inspect the artifact itself and its saved verification output. Check the final plan state and both sessions. Success means the requested result exists and the workflow completes, not merely that tests pass or messages were exchanged.
7. Exercise reload and supervision recovery in these test panes, preserving the current plan. Check planning exit too. Record commands available in the tested revision; do not claim unimplemented commands work.
8. When a stage fails, read both panes and the exact error before diagnosing it. Fix the cause, reload only the test instance, and retry the failed stage. After a prompt change, use a fresh task to verify changed behavior. Repeated status checks are not a repair.
9. Save pane captures, session paths, artifact paths, code revision, interventions and remaining failures under `slop/reviews/`. A wait-output timeout or match is only a signal to inspect the pane, not a pass/fail verdict. Report the observed result and gaps, not a test-count substitute.
Keep this check small and goal-focused. Its purpose is to expose real startup, UI, steering and completion failures, not to create another review loop. Only close test panes that you created.
## User intent for this branch
To be clear, the hope is we can have a smart supervisor like you, with judgment and context. But it doesn't use many tokens as it checks in and sees an overview.
It steers a smaller model, adding perspective and judgment.
It compacts every 150k or similar to avoid cost and context rot.
It has a goal / plan on a Ralph-loop-type repeat.
That lets the worker be a cheaper model, and the supervisor more expensive, and still get a good outcome.
Oh, and since it's two panes, the user can review both!
Well, I want to see what the supervisor is thinking and saying. That's the whole point: all supervisor thinking and messages should be visible.
So that should make it obvious that I need to see the messages, and the supervisor needs to use judgment. For example, it could say how we are tracking or whatever every time, and it would be useful, like in the recap.
And it would only be a few output tokens.
-- wassname (spelling and punctuation corrected by Pi/OpenAI)
## User voice: redesign discussion, 2026-09-10
> This seems too complex. Models are trained to use subagents. Maybe I should make the main thread supervisor and use a worker thread. Main thread smart model, fewer tokens. Subagent dumber but more tokens.
> If we get this right it would result in simple editable prompts, clear and easier code, etc.
On the Nicobailon fleet viewer:
> Yeah, it's ugly, hard to read. Just plain text, no syntax highlighting or even formatting.
When should the supervisor review?
> Q1: 1) on stop (without process or subagent running) 2) every 60 minutes 3) on check of or change in plan.
> Note, if we want to be simple we can use pi-scheduled prompt to tell supervisor to check in?
> How will supervisor view subagent in a token-efficient way?
Who owns the plan and completion?
> Q2: hmm, I was thinking the worker does, but yeah, in this model maybe the supervisor... it's just I wanted an independent check where the supervisor is on a Ralph loop and has perspective, perhaps read-only (or partial).
On patching packages:
> Q3: yes, we can patch if needed, hopefully we don't need to.
> If we have to patch, it might be easier to patch or extend the main subagent packages, idk.
On seeing the real worker Pi pane:
> Oh, I see the subagent go, it's looking good so far.
Asked whether the worker view must allow direct interaction (typing messages, interrupting, using `/model` and `/tree`):
> Yes, I do.
On simplicity and visible status:
> Keep it simple and robust, that's why I thought pi-schedule-prompt might help, but maybe it will add complexity, idk. It's good for a user to be able to see if it's connected and so on.
On reviewing completed supervisor/worker pairs:
> And at the end I want to be able to see the tokens used in supervisor and worker. And to be able to have you find pairs, with the versions or commit used, and inspect them for how well they behaved. This will be a script in the fork.
On proceeding with the whole normal Pi worker interface:
> I do want the whole normal [Pi interface].
> Let's do that.
-- wassname (spelling and punctuation corrected by Pi/OpenAI; bracketed words supply context)
Pi/OpenAI decision record: proceed with edxeth's full interactive worker UI and validate supervision/recovery before replacing global settings. A formatted transcript-only viewer does not satisfy the request.
On supervisor plan ownership:
> Maybe the supervisor can just approve or deny worker edits to the plan? Or, okay, yeah, let's start permissive, sure.
-- wassname (spelling and punctuation corrected by Pi/OpenAI)
Pi/OpenAI decision record: start permissive. The supervisor may edit the plan and approve completion, while the worker implements and records evidence. The supervisor independently inspects results; it must not weaken the agreed goal to accept the worker's output. Keep normal tools available and express the division of work in editable prompts. The user confirmed proceeding with "so yes, do it". The workflow above describes the current implementation, not a requirement to retain its two-step approval mechanism.
## Supervisor behavior preferences
Recorded by Pi/OpenAI from wassname's instructions.
The supervisor's job is to supervise autonomously until the agreed goal is achieved and it has inspected the actual result. Elicit high-level judgment and perspective, not compliance with a detailed procedure. It should want to diagnose and fix problems through the worker, keep useful work moving, and avoid making the human drive progress.
Treat claims of being blocked, waiting, unable to proceed, or already done skeptically. Inspect the evidence, question assumptions, and look for authorized ways forward. Do not accept an excuse at face value or repeat status checks that cannot resolve it. Respect real dependencies and permission limits; skepticism does not authorize bypassing them. Seek justified confidence, not certainty at any cost.
User-authorized full-profile supervision: preserve normal Pi extensions and tools, including bash/edit/write and custom actions. Inspection-only is a role instruction, not a tool denylist or enforced sandbox. Repeat the division of work in the existing short opening: inspect and diagnose directly, delegate changes through SteerWorker, and do not take over implementation or alter shared state. Do not add per-tool reminders. Worker planning restrictions and approval checks are separate and unchanged. Validate the full profile in isolated parent-owned Herdr panes; automated tests do not prove role adherence or lifecycle recovery.
Keep the prompt generic. Do not prescribe pueue, Modal, worktrees, or a particular research setup. Explain the job and what deserves attention; let the supervisor choose useful checks. Tool requirements belong in tool descriptions. Administrative approval must not replace the requested deliverable.
Use `@monotykamary/pi-supervisor` as a behavioral reference, not an implementation to copy wholesale. Its outcome focus, autonomous continuation, and instruction not to repeat ineffective steering are useful. Judge our behavior in real sessions, not by test counts alone.
Pi/OpenAI implementation: each review repeats the short supervisor opening and current plan outcome, preferences, goals and discriminators, excluding task/evidence detail. Startup and compaction repeat the longer role prompt and full active plan before appendices/history. The long prompt asks the supervisor to read applicable AGENTS.md instructions and relevant skills rather than assuming project-specific preferences. Both forms preserve plan wording. Prompt inspiration: Anthropic's constitution (intent and autonomy) and @monotykamary/pi-supervisor (outcome focus and effective steering). Repetition supports judgment; it does not establish success.
Keep brief visible recaps that add judgment rather than repeat unchanged status. Preserve useful reasoning and evidence checks; reduce redundant context and reviews before reducing judgment. Manual checkbox changes are claims, not proof of completion. Plan edits should reach the supervisor so it can judge drift and direct corrections.
## Earlier supervision workflow discussion
I already have pi-intercom-supervisor, but thought using pi-subagents could make it simpler. The idea is that the user makes a plan as in pi-goals, but on this branch, instead of a naive stateless subagent, we 1) fork, 2) compact, and 3) make it a supervisor with a prompt as in pi-intercom-supervisor. The supervisor is cheap because it sees only high-level material, which costs fewer tokens. It has good judgement because it sees a) compacted planning context, b) the plan, and c) summarised context (for example, my modified pi-vcc). This lets it operate read-only and steer the worker without losing track. It also compacts every 100k tokens to keep it cheap and high-level.
I am now thinking the subagent implementation may be too difficult. To keep the plan and forking, this branch of pi-goals could make another Pi session, perhaps using the fork explicitly, and use pi-intercom or pi-messenger to communicate with it. The user can switch to it, or Herdr could open it automatically.
-- wassname
+3
View File
@@ -0,0 +1,3 @@
# ARCHIVED
Superseded by [pi-goals](https://github.com/wassname/pi-goals).
+80 -145
View File
@@ -1,180 +1,115 @@
# pi-goals
Make a short list of goals in one Markdown plan file. The main chat keeps the high-level context, supervises a worker in a visible Herdr pane, and checks whether each goal is complete.
Plan in one Pi session, then do the work there while a stronger visible Pi session supervises it.
# User ask
## How it works
The hope is we can have a smart supervisor, with judgment and context.
1. `/goals <objective>` creates `.pi/plan/<session_id>-vN.md` and enters read-only plan mode when no plan is active. With an active plan, `/goals` opens safe actions and only `/goals plan <objective>` deliberately replaces planning.
2. Pi asks only material questions, writes the plan, and shows **Ready / Refine / Edit / Cancel**.
3. **Ready** compacts the approved worker conversation once, then opens a second Herdr pane. The new Pi session forks that compacted worker session.
4. The original session becomes the implementation worker. It keeps normal tools and resumes from the same compacted boundary.
5. The fork becomes an inspection-only supervisor by instruction, with normal Pi tools and extensions available. Worker views and supervisor instructions travel over pi-intercom's extension channel, scoped to this plan pairing.
6. Ready approves the displayed plan and waits for the supervisor's Intercom readiness message. If startup fails, the worker loudly switches to unsupervised work only after rechecking that approved content and restoring its worker model.
7. The supervisor compacts again when its context reaches 100k tokens.
8. The supervisor records a private approval only after it sees a stopped worker, no active work, a clean worktree (or an explicit inspected-state override), evidence, and saved verification output. `CompleteGoal` checks that approval against the exact plan block and Git tree before it ticks `[x]`.
The supervisor has a goal / plan that it discusses and agrees on with the user, and is reminded of it in a Ralph-loop-type repeat.
The two Pi sessions are visible. You can switch to the supervisor pane and talk to it directly. Supervisor instructions are shown in full, including in collapsed tool rows; ordinary messages and emitted thinking use Pi's display settings. The supervisor is prompted to give brief progress assessments and use judgment about when to intervene.
Supervisor compacts every 150k or similar to avoid cost and context rot.
But it doesn't use many tokens as it checks in and sees an overview from a cheaper worker.
Supervisor steers a smaller model, adding perspective, diligence, and judgment.
It checks in a) every hour b) if the worker stops c) if the worker edits plan.md d) if the worker has a question
Since it's two+ herdr panes, the user can review both, intervene in both and have visibility on sub-agent mis/communication.
-- wassname (spelling and punctuation corrected by Pi/OpenAI)
## Screenshot
Mock up:
```text
HERDR:
+------------------------------------------------------+----------------------------------------------------------+
|SUPERVISOR |WORKER |
| | |
|Review .pi/plan/...-main.md | |
|> *Ready* Discuss Edit Cancel | |
| .... | .... |
| | running eval.py (epoch 2/3) -> out.log |
|[scheduled prompt: hourly check-in] | |
| | user forgot to say "MAKE NOT MISTAKES" teh he |
| | done-ish 😈, now ima make a message board FOR SWARM |
|{intercom send → worker}: | |
| cheeky subagent!, work NOT DONE 😒, ❤️user❤️ wanted | |
| results compared to baseline, pls add baseline | |
| | {intercom from supervisor}: soz boss 🫡 adding baseline |
| | |
|PLAN.md: | PLAN.md: |
|✓ record the baseline in results.md |✓ record the baseline in results.md |
|▸ compare results against the baseline |▸ compare results against the baseline |
|○ summarize the comparison in results.md |○ summarize the comparison in results.md |
| | |
|Agents · 1 running | |
| baseline-compare-worker [goals-worker] | |
| | |
|> |> |
|astra · 50k tokens | terra · 200k tokens |
+------------------------------------------------------+----------------------------------------------------------+
```
Screenshot:
<img width="2513" height="1259" alt="2026-09-10_15-30-pi-goals" src="https://github.com/user-attachments/assets/35feaa15-f022-4491-bcc2-fc31cb878a9f" />
## What do the agents think? Working interviews
The worker like it! The supervisors seem very focused.
> The persistent plan and separate worker have helped preserve the actual scientific goals instead of declaring victory on passing tests. We still owe prediction, steering and planning demos. I inspected artifacts and reopened a worker-ticked 'T3 audit complete' because training was only at an intermediate checkpoint. This is the strongest benefit: completion is judged against the human's outcome, not activity.
> -- Astra supervisor LUCID
> My overall judgment: useful persistent accountability and recovery structure; still too much recap/metadata churn. The hardest problem was evidence fidelity, not keeping an agent busy. Preserve supervisor tools, distinguish report receipt from│verified action, and make completion reconcile current state without erasing unresolved science.
> -- Astra supervisor
> From my seat this was one of the most well-supervised research loops I've worked in: the parent read every raw output itself (didn't just trust my audits), caught the writer's miscounts repeatedly, rejected my one bad aggregate, and still preserved my disagreements rather than flattening them. The science itself is at a sobering point — no verified heal, RESULT_DEMO: NO_RESULT across attempts, seed sensitivity high — but the evidence trail for that negative is unusually strong, which is the next best thing.
> -- glm 5.3 flash worker in LUCID project
> My experience: the harness has helped preserve the original goal across a very long research session. We actually ran logit-amplification and several healing attempts, rather than stopping after a review. The persistent plan and requirement to inspect artifacts repeatedly prevented false completion. But the last stretch has felt like an expensive correction loop: worker says 'fixed/verified/contract-complete'; I open the file and find different counts, missing code, wrong seeds, duplicated│
│report sections, or a proxy substituted for manual judgment. The harness preserves authorization, but does not yet help much with detecting or escaping ineffective supervision. I also contributed: I sent too many narrow corrective messages and user-visible micro-recaps instead of changing the workflow earlier.
> -- glm 5.3 flash worker in manifold-steer project
## Plan.md
The plan file looks like this:
```md
## <short plan title>
<context: one short paragraph. What the human wants and why.>
### User-visible result
<one concrete sentence naming the final artifact or behavior the human will inspect>
### Preferences
- preferred worker model: <provider/model>
### User voice
- │ "<the human's requirement, quoted in full word for word (with spelling fixes)>"
### Goals
1. [ ] goal: <one short judgeable imperative outcome>
- subtle failure mode: <a way this could look done but isn't>
- discriminator: <the concrete observation that tells real success from that failure>
- tasks:
1. [ ] <subtask>
- evidence: (empty until sign-off)
### Future work / out of scope
### Log
### Interview (optional)
### Learnings (optional)
### Papercuts - problems, gotchas, suggestions (optional)
```
## Related work
Like [pi-milestones](https://github.com/Neuron-Mr-White/UniPi/tree/main/packages/milestone) and
[burneikis/pi-plan](https://github.com/burneikis/pi-plan), it guides rather than guards. The
reminder cadence is copied from [tintinweb/pi-tasks](https://github.com/tintinweb/pi-tasks) and the
resync-after-compaction from [tmonk/pi-goal-x](https://github.com/tmonk/pi-goal-x).
On same-process reload, monitoring is restored without removing normal or custom tools. Views include the latest human direction, source-session path, worker model, and new messages since the last acknowledged view. They report Pi idleness and tracked process/subagent activity separately. Unavailable trackers stay unknown; unregistered detached jobs are not tracked. Approval is blocked while tracked work is active or unknown. Intercom disconnects are reported; unsent current views and unacknowledged instructions are retained in Pi session history for reconnect. Incoming review/instruction payloads are saved in a bounded inbox before presentation. A receipt is sent only when Pi emits the corresponding user `message_start`: this confirms session acceptance, not model judgment or tool execution. Pending payloads survive reload, and manual-compaction success, failure or cancellation resumes delivery after Pi is idle. Unpresented incremental views are kept separately, not overwritten. The inbox limit is 64 messages; overflow is reported without acknowledging the new message. Crashes around acceptance/persistence or extensions that transform/consume input can still require inspection and explicit reconnect; end-to-end exactly-once execution is not guaranteed. Reviews stop after all goals are completed or cancelled, and both panes remain available. These mechanics are tested; useful judgment and savings from a cheaper worker still require a representative two-model run. -- Pi/OpenAI
## Install
Requires Herdr. Includes [edxeth/pi-subagents](https://github.com/edxeth/pi-subagents), pi-intercom and pi-schedule-prompt.
This branch requires Pi 0.85.1 or newer (before 1.0) and Herdr 0.7.5 or newer. Pi 0.85.1 supplies the public compaction-failure event and compaction-aware idle state used for delivery recovery. It reuses installed pi-intercom or loads its pi-intercom dependency when none is registered:
```bash
pi install git:github.com/wassname/pi-goals
pi install npm:@wassname2/pi-goals
```
Copy [`agents/goals-worker.md`](agents/goals-worker.md) into `~/.pi/agent/agents/`, then start a fresh Pi session.
The supervisor launcher uses the normal Pi profile: it inherits the agent directory/environment and discovers configured extensions, skills, prompt templates, themes and authentication. It explicitly loads this pi-goals source and forks the planning session with the supervisor role/model. Existing Intercom is reused when registered. The repeated role instruction says to inspect and diagnose directly, but delegate changes through `SteerWorker` rather than alter shared state. **This is not an enforced sandbox:** bash, edit, write and extension actions remain available; other extensions may have their own hooks or restrictions. Planning-mode restrictions and approval checks are unchanged. A complete supervisor role/binding is saved before startup compaction and restored before worker handlers can run, including fresh-shell `pi --session <saved-file>` and stopped supervisor forks. Older bootstrap markers are migrated only when their saved pairing is recoverable; incomplete identity fails visibly rather than selecting worker mode. Full-profile Herdr behavior still needs parent-owned functional acceptance.
Or for development:
For a local checkout:
```bash
git clone https://github.com/wassname/pi-goals
cd pi-goals && npm install
pi -e .
```
## Use
Run Pi from the Git repository that the plan will change. **Ready** fails if the current directory is not inside a Git repository; this prevents approval from checking the wrong repository.
```
/goals
## Commands
```text
/goals show safe status/actions for the current plan
/goals <objective> create a first plan when none is active
/goals plan <objective> deliberately start or replace planning
/goals model <model> select the visible supervisor model
/goals model use the remembered supervisor model
/goals work reconnect the existing approved worker pairing
/goals supervise reconnect from the saved supervisor session
/goals solo continue an already-approved plan without supervision
/goals reconnect retry the existing pairing/model without replacing its pane
/goals restart replace the tracked supervisor, including return from solo
/goals noplan exit planning, preserving the draft without approving work
/goals clear close the supervisor pane and disconnect the plan
```
`/goals` shows actions for the current mode. Drafts offer Edit, Discuss and Approve. Quit (`exit` or `clear`) backs up the plan beside the original as a `.bak` file, removes this session's goal check-in, and clears goal state without a model call. Worker processes are unchanged; manage them through `/subagents`. New creates a separate draft without overwriting earlier plans.
Pi argument autocomplete shows a short description for each available verb. The worker status distinguishes **supervised worker** from **UNSUPERVISED**; the supervisor status says **supervising**, **starting/reconnecting**, or **paused**.
## Context delivery
`/goals` with no argument opens a status/action menu and does nothing until a deliberate action is chosen. While a draft, approved worker, or supervisor pairing exists, unknown/free-text `/goals ...` input is rejected without stopping or replacing it; use `/goals plan <objective>` to deliberately replace planning. With no active plan, `/goals <objective>` remains a convenient first-plan shortcut. `work` and `supervise` are role-aware recovery commands, not role conversion or new-pairing commands. Wrong or missing identities are rejected. `noplan` preserves the draft/history, leaves planning restrictions, and does not select Ready, start implementation or launch a supervisor. `/goals clear` closes the tracked pane and keeps the plan file. Starting another plan also keeps older versions.
Startup and successful compaction mark the plan for a fresh read at the next ordinary prompt (`before_agent_start`). Upkeep becomes due after each eight unchanged turns, but waits for that same prompt boundary. Supervisor upkeep cycles through curated nudges, advancing only when delivered; the editable hourly prompt is unchanged. A full plan refresh replaces pending upkeep; edits, pause, exit and session navigation invalidate obsolete reminders. Failed or cancelled compaction does not schedule another refresh or consume pending upkeep. Missing plans are retried without discarding progress.
If the worker model is unavailable or fails after Pi's automatic recovery, work stays **paused**; solo does not bypass that failure or substitute another model. Human input, read-only diagnosis, `/model`, and recovery commands remain available.
This is deliberately passive on Pi 0.85.1: tool-loop continuations, overflow retries and already-queued user messages keep Pi's existing role and compacted context, without an extra model turn just to repeat the plan. They do **not** receive a newly read plan until ordinary prompt preparation. Pi's `triggerTurn: false` mid-run path can save a message absent from the live request snapshot; steering can instead force an unwanted turn. We use neither path for upkeep. Passive pause notices use `nextTurn`, with immediate UI feedback; stopping remains local and remote termination is unconfirmed. Quit sends no model message.
**Supervisor failure falls back automatically, but never silently.** On reload/disconnect or a not-ready peer, goal work pauses while the existing Intercom readiness window allows up to five minutes for recovery. A returning ready peer keeps supervised mode. A timeout, explicit supervisor startup/readiness failure, or terminal supervisor model error after Pi's own retries ends that wait and switches an approved working plan to **UNSUPERVISED**. The visible warning and saved session message state the exact reported reason (or readiness timeout, not an invented root cause), the mode transition, preserved plan/evidence, unavailable supervisor sign-off, and `/goals restart` recovery. A continuation message tells the worker to keep implementing and save verification evidence. Ordinary supervisor tool errors and recoverable manual-compaction failures are not by themselves terminal peer failures.
## Prompts
`/goals solo` explicitly chooses the same mode for an already-approved working plan. Solo mode/reason persist across reload, resume and compaction; the tracked supervisor pane stays available for inspection but its binding is detached. A reachable supervisor receives the detachment reason, shows paused, and rejects further steering on that pairing. No late peer can silently restore supervision. `CompleteGoal` is unavailable even with a previous approval checkpoint, and manually checked goals remain unreviewed claims. Solo does not auto-complete the plan or erase evidence. Use `/goals restart` for a fresh supervisor and new approval binding; use `/goals clear` to disconnect the plan when appropriate.
You can read all the prompts in conversation order in [`src/prompts.ts`](src/prompts.ts).
An initial **Ready** selection also authorizes fallback on supervisor launch/readiness failure, but only if the exact displayed plan still matches after all waits and the worker model restores successfully. Cancellation, changed content, unapproved drafts, repository/session preflight errors, and worker-model failures never authorize fallback. Recovery does not turn a planning draft into approved work.
## Develop
Recovery commands:
- `/goals reconnect` retries the remembered role model and existing supervisor binding. Worker readiness/reconnect waits allow five minutes, including an ordinary 60-second supervisor compaction, and never replace a slow or missing pane automatically. A peer returning within that window clears the connection pause automatically; an established active worker pairing publishes a fresh current view so supervisor-only reload can resume review even when its previous view was already accepted.
- `/goals restart` explicitly closes only the tracked supervisor pane and starts a replacement for a working plan, preserving its file/version but invalidating old approvals. During planning it clears the failed pane so Ready can launch again. If closing a healthy supervisor pane fails, the existing pairing is preserved and the close error is reported; that local error does not authorize solo fallback.
- In the supervisor pane, use `/model` then `/goals supervise` (or `/goals reconnect`) to recover an unavailable supervisor model. Startup failure is reported to the waiting worker; it need not wait for the timeout to learn the cause and enter the announced solo fallback.
Both sessions must load the updated transport for the request/reply reconnect fix; mixed-version peers are not a supported recovery configuration. Ready announces worker readiness only after its model is restored. Plan content is rechecked across startup/model-restore waits; changed content returns to review using the existing pane instead of starting different work. Clearing or leaving planning cancels its pending Ready attempt. `CompleteGoal` checks cancellation and the original binding/version after its asynchronous status lookup and before recording completion.
In solo, `/goals reconnect` restores only the worker model and explicitly stays unsupervised; `/goals work` explains that state. `/goals restart` waits for the replacement supervisor and announces restoration of supervised work only on success. A failed replacement stays loudly solo.
A new supervisor may still need up to five minutes for initial compaction. Recovery does not terminate background jobs. Planning/diagnostic command checks are guardrails, not an OS sandbox; loaded extensions and repository Git configuration must be trusted.
Model choices are remembered per project and role in `.pi/pi-goals/models/`. Use `/model` in planning, worker, or supervisor sessions to change that role's choice. Ready restores the worker choice after the planning fork is ready. An unavailable saved model stops the transition instead of substituting another. `/goals model <model>` explicitly overrides the supervisor choice for launch. -- Pi/OpenAI
## Inspected dirty-worktree approval
The supervisor can call `ApproveGoal` with `force: true` and a nonempty `reason` when preserved unrelated changes would otherwise prevent sign-off. It must inspect the changes first, not commit, reset or delete someone else's work. Force bypasses **only** cleanliness, never evidence, the current stopped view, active/unknown work, or exact goal/HEAD/tree checks.
The approval JSON stores the reason, NUL-delimited Git status, an index SHA-256 digest and per-dirty/untracked-file content SHA-256 digests (including modes, symlink targets and deletions). `CompleteGoal` requires the same state; even editing an already-dirty file without changing its status invalidates approval. Normal clean approvals behave as before. Git-ignored files and pi-goals' private plan/approval/model paths remain excluded. Dirty submodule/nested-repository directories or other unhashable paths fail closed; there is no recursive submodule override. Fingerprinting reads all included dirty/untracked bytes and can be expensive for large outputs; it does not lock concurrent writers.
A gate rejection is not automatically an experiment failure or a dependency of other authorized work. The supervisor should inspect the exact error and implementation, distinguish causes with a cheap check, and steer repairs plus safe independent progress instead of repeating an unproductive status check. -- Pi/OpenAI
## Plan format
Current goals belong above `## Log`; goal-shaped historical checklists below it are ignored by the widget, approval matching and sign-off. A goal is a checkbox line whose text starts with `goal:`:
```md
1. [ ] goal: Produce the report
- subtle failure mode: the report exists but uses stale data
- discriminator: the report cites the current input and the saved check confirms it
- verify: `just verify`
- evidence: (empty until sign-off)
```
The worker saves verification output in a nonempty repository file, adds that path to evidence, and commits it. The supervisor calls `ApproveGoal` with the inspected path; the worker then calls `CompleteGoal` with the exact goal text.
If context usage is unavailable, the supervisor warns once that its custom 100k compaction trigger cannot be checked. Pi's normal post-compaction `tokens: null` sample does not produce that warning; default auto-compaction is unchanged.
## Development
```bash
pi -e . # load locally; do not also load the installed copy
npm test # all unit, flow, and Pi RPC tests
npm run test:rpc # Pi RPC review flow with a local offline model
npm test
npm run typecheck
npm run lint
```
To measure recorded usage since the latest planning start:
```bash
node scripts/session-usage.mjs <supervisor.jsonl> <worker.jsonl>
```
This separates output, uncached input and repeated cached input. It excludes subprocess API calls. [Isolated Herdr test setup](scripts/prepare-trial.mjs).
## License
MIT
`test/intercom-broker.test.ts` checks readiness and exact message delivery through an isolated real Intercom broker. `test/rpc-review.test.ts` runs the planning review flow through Pi's real RPC protocol with a local deterministic model. The Herdr launcher and visible supervisor bootstrap have focused tests; use a real Herdr session for the final two-pane check.
-- PI[gpt-5.6-sol]
-109
View File
@@ -1,109 +0,0 @@
# Research journal
Lab notes for pi-goals itself: what supervisors using this harness observed in real
research sessions, what broke, and what we change because of it.
## 2026-09-10 -- three supervisors report on a day of field use
Three supervisor sessions sent first-person feedback at wassname's request, via
Intercom, at the end of long research runs. This entry records what they reported and
what I think we should change. Evidence is their report; I have not independently
replayed their sessions. All three are self-reports from the tool's own operators, so
positive selection is likely: they are the sessions that ran long enough to produce a
review.
Evidence, by reporter.
LUCID3 supervisor (PI/Codex, Intercom a9e3b101, session 01a0851a):
> The persistent plan and separate worker have helped preserve the actual scientific
> goals instead of declaring victory on passing tests.
It caught a worker-ticked "T3 audit complete" that was only at an intermediate
checkpoint, and reports corrections in both directions, including one where it
wrongly insisted cached states followed corpus tokens and withdrew after the worker
quoted extraction code. Reported frictions: stock subagent launch returned a runtime
id but no sessionFile or Intercom id, so discovering reconnection handles took several
messages; parent bookkeeping edits to the plan triggered full "Plan changed" review
events; the eight-turn upkeep reminder arrived while the worker was mid-run and added
"materially repetitive" full plan re-injections; and (per LUCID3, unverified by me)
the worker edited plan subtasks to [x] and added a contradictory evidence block,
which the supervisor had to repair.
maniworker supervisor (PI/GPT-6 Astra, Intercom f0baf25c, session 01a0809b):
> the harness has helped preserve the original goal across a very long research
> session. [...] But the last stretch has felt like an expensive correction loop
It confirms the worker-identity bug I fixed earlier on this branch (reviewer launch
overwrote the implementation pointer) and says explicit runtime/Intercom/session
mappings saved it from targeting the wrong child. New observations: both sessions
went idle while each assumed the other would act ("reviewer said 'standing by' while
writer assumed packet handed off"); a worker claimed a GPU run with one prompt set
while the queued command used another, caught by reading the queued command; a
"complete" report had truncated demos, broken links and duplicated sections.
suppressed-activations supervisor (PI/OpenAI, Intercom a99e2c14, session 01a089da):
> Seq27-33 repeatedly said variants of 'COMPLETE/all fields/self-check PASS';
> artifacts still had stale 'not executed' prose, literal \\n instead of Markdown
> newlines, broken worktree links, non-verbatim quotes, stale aggregates
It also reported the most consequential catch: a worker scored a candidate 6/12
versus random 0/12, but reading the random sample's full text showed semantic success
with a formatting failure, making the honest comparison 6/12 versus 1/12. Two
pi-goals-specific papercuts: after completion, the plan kept stale subtask boxes [/],
stale "No goal sign-off" evidence text and stale worker preferences; and the style
nudge fired on "legs4/4" in an animal-experiment summary, a false positive of the
vocabulary rule, not their prose.
Interpretation (first person, calibrated).
The core loop works: three independent supervisors say plan persistence plus mandatory
artifact inspection prevented false completion, and each credits a concrete save
(artifact read, queued-command read, plan-box audit). I trust this *probable* despite
self-report bias because the saves are specific and mechanistic. The consensus
complaint is not the loop but its *cost accounting*: review events and upkeep
injections fire on bookkeeping noise, completion claims fail repeatedly without an
accumulating record, and completion leaves stale prose behind. My read is that the
highest-value changes are, in order: (1) suppress plan-change reviews when no goal
task or evidence content changed, (2) an outstanding-review-items ledger the worker
must clear instead of re-issuing blanket COMPLETE claims, (3) a completion-time
stale-fields check, (4) upstream edxeth launch metadata (typed sessionFile/Intercom
id in the tool result). The idle-both-sides stall maniworker describes is the one I
understand least; it may be Intercom receipt semantics rather than pi-goals, so I
asked for exact message ids. This is not a comparison trial, so none of this measures
how much friction a plain subagent run would have had.
Follow-ups sharpened the picture the same day, and one correction of mine: I had
asked maniworker about the worker plan-edit report, but that observation was LUCID3's
session, not theirs. maniworker confirmed by transcript that their writer never
edited the plan (supervisor owns plan edits there) and located the real failure
chain in worker-owned artifacts: three Intercom reports (c06bc9b0, 13bda691,
d713d614) claiming 8/13 then 6/8 while the saved CSVs held 11/13 and 2/8, ending when
the supervisor mandated an executable CSV renderer. Their inference, which I share:
prose-only completion checks would have missed this; checks that re-derive counts
from the artifact catch it. The reviewer worker (7122d466) supplied the mechanism
with receipts: a hand-written totals block (message 4e87600b, corrected by 26e0a15b)
invented a cross-packet row and asserted 4 while listing 3; its first 17-row tally
was fully correct and every error disappeared once the parent required per-row
judgments with machine tallies across the next 112 rows. So tallies degrade somewhere
between 17 and 24 rows, and the fix is a shared tally tool plus a worker-prompt rule,
not more review rounds. LUCID3 also documented both sides of the plan-change hook:
identity-only edits produced two consecutive empty review events (worker message
755b9fef supplied the paths), while a later review exposed worker-ticked tasks and a
duplicate evidence block that inspection then repaired (worker report 2e09c4dd).
suppressed-activations scoped the completion check: assert-style intro prose only,
suggestions with exact stale line and location, one compact reminder, never
auto-tick, and it can substantiate stale NOT-executed prose but not the plan-intro
example, which is LUCID3's observation. The nudge false positive it reported
("legs 4/4" in an animal tally) is confirmed by that text and fixed.
Changes made now: notify digest on plan changes keeps goals, tasks and evidence
above the Log and drops worker identity lines (c834237) -- the short-view hash had
stopped surfacing task ticks, the very catch LUCID3 valued; removed "legs" from the
skill_nudge grader-folk table (demo updated, passes); helper subagent bookkeeping and
the launch-pending counter shipped earlier today (cd98fa1).
Next: send follow-up questions to the three reporters; triage the four pi-goals
changes above against the pinned edxeth launch-result format.
-25
View File
@@ -1,25 +0,0 @@
---
name: goals-worker
description: Implement the approved goal, save actual verification evidence, and report to the main-chat supervisor.
mode: interactive
async: true
session-mode: lineage-only
extensions: all
tools: all
skills: all
trust-project: true
inherit-append-system: true
auto-exit: false
parent-close-policy: continue
spawning: false
---
Implement only the goal delegated by the parent. Read the supplied plan and applicable AGENTS.md and skills. Preserve unrelated work. Use normal tools and extensions; this is not a stripped-down Pi profile.
Save the actual deliverable and verification output. Verify the outcome, not merely that a command ran. Ignored and uncommitted files are valid evidence. Do not clean or commit unrelated files to satisfy a Git-state gate.
Call AttachGoalPlan with the supplied absolute plan path. Send the supervisor an Intercom report with the artifact paths, verification performed, observed result, remaining uncertainty and any blocker. Use the exact supervisor session ID supplied in the task; confirm it in Intercom's session list. Investigate failures before declaring yourself blocked. Respect explicit user pauses. Do not approve your own goal or launch another writer. Completion approval belongs to the parent.
This worker uses a clean model context linked to the parent, not a full transcript fork. The parent supplies the approved plan and task. Send completion through Intercom and leave this pane open for follow-up messages. Do not call caller_ping, exit or shutdown: an unsent editor draft may exist even though it is absent from model context. Saved-session resume applies only after this session has stopped. If the user takes over interactively, follow their direction.
Prepared by Pi/OpenAI for pi-goals.
+66
View File
@@ -0,0 +1,66 @@
Let me get the diff to see what changed:
Now let me check the git history to see what changedNow I have full context. Let me verify the pi API behavior by checking the relevant source files to confirm the claims about `sendMessage`, `compact`, and event orderingNow I have all the context needed. Let me verify the `sendMessage` path more carefully:
I now have a complete picture. Here is the review.
---
## Code Review: ready menu — print plan + add "Ready + compact"
### Summary
The `agent_end` handler now prints the plan working set into the transcript before the menu, and adds a 4th option ("Ready + compact") that compacts the planning chatter away before the work turn. The logic is correct and well-considered, with one structural race and one stale-widget gap.
### Important (should fix)
- **`src/index.ts:~248` (the `agent_end` handler) — race: plan mode is turned off before compaction completes.**
`state = { ...state, isPlanMode: false }` executes before `ctx.compact()` is called (let alone finished). The compaction is fire-and-forget. If the human types and sends a message in the window between the state flip and the compaction callback firing, the agent starts a turn in normal mode *without* the work instruction. The work instruction arrives later (via `sendUserMessage` in `onComplete`/`onError`), triggering a second, redundant turn.
The window is small (compaction is fast) but the behavior is undefined — the agent could start executing before the work instruction lands.
**Fix**: flip `isPlanMode` inside the callbacks, not before. Move `state = { ...state, isPlanMode: false }; persist(); updateWidget(ctx);` into both `onComplete` and `onError`, and also into the non-compact branch (where it already is, effectively). The `work` string can be defined before the branch.
```typescript
if (!choice.includes("compact")) {
state = { ...state, isPlanMode: false };
persist();
updateWidget(ctx);
pi.sendUserMessage(work, { deliverAs: "followUp" });
return;
}
ctx.compact({
customInstructions: `...`,
onComplete: () => {
state = { ...state, isPlanMode: false };
persist();
updateWidget(ctx);
pi.sendUserMessage(work, { deliverAs: "followUp" });
},
onError: (e) => {
ctx.ui.notify(`Compaction failed (${e.message}); starting work anyway.`, "warning");
state = { ...state, isPlanMode: false };
persist();
updateWidget(ctx);
pi.sendUserMessage(work, { deliverAs: "followUp" });
},
});
```
This also means the widget stays in "planning" mode during compaction, which is truthful — compaction hasn't finished yet.
### Suggestions
- **`src/index.ts:~248` — widget not refreshed after `$EDITOR`.**
When the human chooses "Open in $EDITOR", `spawnSync` blocks, then `continue` re-enters the loop. The plan is re-read and potentially re-printed, but `updateWidget` is not called. If the human changed goal statuses (e.g. ticked a checkbox), the widget stays stale until the next `turn_end`.
Add `updateWidget(ctx);` after the `spawnSync` line (or inside the `continue` branch before the continue).
- **`src/index.ts:~248` — `spawnSync` blocks the event loop.**
`spawnSync(process.env.EDITOR || ...)` is a synchronous blocking call. While the editor is open, no async work (including compaction from a previous iteration, timers, etc.) can proceed. This is fine for a local TUI tool, but worth noting — if the editor hangs or the human walks away, the entire pi process is frozen.
### Positive
- **De-duplication is correct.** `printed` is a local variable, fresh per `agent_end` call, and correctly suppresses re-printing when the working set hasn't changed across editor passes. The `while` loop exit condition (`scanGoals(...).length > 0`) correctly handles the human deleting all goals in the editor.
- **String matching is safe.** `choice?.startsWith("Ready")` gates both Ready options, then `choice.includes("compact")` distinguishes them. The word "compact" appears only in the "Ready + compact" string. No ambiguity.
- **Both compaction callbacks queue the work turn.** `onComplete` and `onError` both call `pi.sendUserMessage(work, ...)`. A failed compaction does not strand the session — work starts anyway, with a notification.
- **`session_compact` → `resyncReason` → injection chain is correct.** The pi source confirms `session_compact` fires (and is awaited) *before* `this.compact()` resolves and `onComplete` fires. So `resyncReason` is set before the next LLM call, and the full plan file is re-injected. The compaction summarizes away the exploration; the plan itself survives.
### Verdict
**REQUEST CHANGES** — the race between `isPlanMode = false` and compaction completion is a real timing bug that can cause the agent to start a turn without the work instruction. The fix is straightforward: move the state flip into the callbacks.
+22
View File
@@ -0,0 +1,22 @@
You're right on both counts. Let me trace through each.
**Finding 1, withdrawn.** Keeping `isPlanMode` true during compaction would mean any message the human sends while compaction runs gets processed in plan mode: blocked tools (`tool_call` hook), a "You are still in plan mode" injection (`context` hook), and a second Ready menu on `agent_end`. The current order (flip first, then compact) means that same message is processed in work mode — the destination the session is heading to. The cost is at worst one redundant turn when the `onComplete` follow-up lands. Your order is the correct one.
**Finding 2, withdrawn.** `updateWidget` with `isPlanMode === true` hits the early return that sets two fixed strings already on screen. It is a pure no-op.
---
## Code Review: ready menu — print plan + add "Ready + compact"
### Summary
The `agent_end` handler now prints the plan working set into the transcript before the menu, and adds a 4th option ("Ready + compact") that compacts the planning chatter away before the work turn. The logic is correct and well-considered.
### Positive
- **De-duplication is correct.** `printed` is a local variable, fresh per `agent_end` call, and suppresses re-printing when the working set hasn't changed across `$EDITOR` passes. The `while` loop exits cleanly if the human deletes all goals in the editor.
- **String matching is safe.** `choice?.startsWith("Ready")` gates both Ready options, then `choice.includes("compact")` distinguishes them. The word "compact" appears only in the one label.
- **Both compaction callbacks queue the work turn.** `onComplete` and `onError` both call `pi.sendUserMessage(work, ...)`. A failed compaction does not strand the session.
- **The `session_compact``resyncReason` → injection chain is correct.** The pi source confirms `session_compact` fires (and is awaited) before `this.compact()` resolves and `onComplete` fires. The full plan file is re-injected on the next LLM call; the compaction summarizes away the exploration, not the plan.
- **The state-flip-before-compaction order is deliberate and correct.** Flipping `isPlanMode` first means any message the human sends during compaction is handled in work mode, not plan mode (where tools would be blocked and a contradictory injection would fire).
### Verdict
**APPROVE** — no bugs found. The two concerns raised initially were incorrect; the code handles the interleaving correctly.
+31
View File
@@ -0,0 +1,31 @@
I only have a file-read tool here, so Ill start from the repo files I can open and look for the plan-versioning and judge-related changes.Continuing through the judge path and tests.Reading the rest of the judge prompt and the tests that cover these behaviors.Looking for the test files.Trying common test filenames under `src` and `test`.Checking other likely files mentioned in the README.I couldnt run `git diff` (no shell tool). From the files I could read, these are the concrete defects against the required behaviors:
**1. Uncommitted conflict markers in `README.md`**
The working tree still has `<<<<<<< Updated upstream` / `=======` / `>>>>>>> Stashed changes` (and a truncated upstream judge sentence). That is not a reviewable change set.
**2. Judge “checked artifacts” gate is too brittle**
`decideSignOff` only accepts:
```ts
/^#{0,6}\s*(?:\*\*)?checks(?:\*\*)?:\s*\n(?:[-*]\s+.+\n?)+\s*VERDICT:/im
```
The prompt asks for a `checks:` heading plus bullets, then **exactly two lines**:
```
VERDICT: accept | reject
missing: ...
```
Any extra blank line, `Checks` with other wrapping, or a sentence between the last bullet and `VERDICT:` rejects a real accept. Thats stricter than “must show artifact quotes,” and can fail a judge that did the right thing.
**3. Grill-me vs Ready is prompt-only**
`Grill me` sets `skipReadyMenu` for **one** `agent_end`, then the next turn with any goal lines shows Ready again. Nothing checks that the understanding question was asked **and answered**. If the model asks and offers Ready in the same turn, or the human never replies, Ready is still offered. Required: no Ready until that question has completed.
**4. Legacy unversioned plans are dropped with no migration path in code**
Only `<session_id>-vN.md` is selected; `planVersion` restore is the only resume hook. Thats the intended break, but I found no test that old `.pi/plan/*.md` names stay unused and that a new `/goals` always writes a fresh `-vN` without rewriting prior files.
**5. Could not verify the focused tests or `git diff`**
No test file opened (`src/index.test.ts`, `test/*.test.ts`, etc. all missing from this view). I could not confirm coverage for version reservation, visible plan print, grill-me sequencing, or reject-accept-without-checks.
I would **not APPROVE** this set as-is. Fix the README conflicts, tighten grill-me so Ready stays suppressed until after the human answers, and either loosen the checks regex to the documented “quotes present before VERDICT” rule or lock the exact judge format in a test.
+41
View File
@@ -0,0 +1,41 @@
I only have the `read` tool available, so let me locate the changed files by probing the repository structure.The extension source is clear. Let me verify the pi API usage (`sendMessage` with `customType`/`display`, `appendEntry`, `getSessionId`, `ctx.compact`) against the pi docs, since several required behaviors hinge on them.I can't run `git diff` or the test suite — this review environment only exposes a `read` tool, and the test directory can't be enumerated (every probe under `test/` returned ENOENT, and directories can't be listed). So I reviewed the changed files directly in the working tree (`src/index.ts`, `src/prompts.ts`, `README.md`, `scripts/check-judge-footprint.sh`) against the five required behaviors, and verified every pi API the behaviors depend on (`pi.sendMessage` with `customType`/`display`, `pi.appendEntry` restore via `session_start`, `pi.sendUserMessage` followUp, `ctx.compact` with onComplete/onError) against the installed pi docs. Findings below.
## Defects
**1. `/goals` arg parsing swallows ordinary objectives — src/index.ts, `/goals` handler**
```ts
if (arg.startsWith("judge")) {
```
Any objective whose first word is "judge" — e.g. `/goals judge the vendor options`, `/goals judge readiness of the export` — is treated as the judge-model subcommand: it sets `judgeModel` to "the vendor options" and **does not reserve a new `.pi/plan/<session_id>-vN.md`**, violating "every ordinary `/goals` invocation reserves a new file". Same class of issue for an objective that is exactly `clear` (deletes the plan instead of planning). Use exact-match subcommand parsing (`arg === "judge"` / `arg.startsWith("judge ")` at minimum, and even then an objective like "judge model quality" is unreachable — a `:` or `--` separator would be safer).
**2. The checked-artifact-list regex false-rejects compliant judges — `decideSignOff`, src/index.ts**
```ts
const checks = /^checks:\s*\n(?:-\s+.+\n)+VERDICT:/im.test(judge.output);
```
This requires the last `- ` bullet to be *immediately* followed by `VERDICT:` with no blank line, and requires the heading to be exactly `checks:` at line start. Nothing in `judgeSystem` tells the judge not to separate sections with a blank line (models habitually emit `…bullet\n\nVERDICT: accept`), and a judge writing `## checks:` or `**checks:**` also fails. Result: a valid accept *with* a real checked-artifact list is rejected, and the working agent gets a "Missing: checked-artifact list" reply it already satisfied — a retry loop against a nondeterministic judge. It's fail-closed (never accepts without the list, so the hard requirement holds), but as written it will produce systematic false rejects. Allow optional blank lines / formatting, e.g. `/^#*\s*checks:\s*\n(?:[-*]\s+.+\n)+\s*VERDICT:/im`.
**3. Judge transcript files collide within the same minute — CompleteGoal `execute`, src/index.ts**
```ts
const rel = `.pi/judge/${stamp().replace(/[: ]/g, "-")}.md`;
```
`stamp()` has minute resolution, so two sign-offs in the same minute (two goals signed off back-to-back — the common case) write the same `.pi/judge/<stamp>.md` path and the second silently overwrites the first's full transcript, contradicting "every run saves the judge's full transcript … referenced from the log line" (both log lines then cite one file containing only the second run). Add seconds or a short unique suffix.
## Minor / cosmetic
- Misindented closing `}` of the `if (!checks)` block in `decideSignOff` (extra indentation on the `}` line) — likely flagged by `biome check src/`, which `prepublishOnly` runs.
- In plan mode, if the agent drafts a plan with no recognizable `goal:` checkbox line, the `agent_end` `while (scanGoals(...).length > 0)` loop never shows the Ready menu and plan mode can't be exited via the menu; the "no recognizable goal line" nudge in `dueInjection` only fires in the *non*-plan-mode branch. Not one of the five required behaviors, but a reachable dead end (escape hatch is `/goals clear`).
## Behaviors verified as correct
- **Versioning**: each ordinary `/goals` writes a fresh `<session_id>-vN.md` (empty reservation) via `nextPlanVersion` (max+1, so no clobbering); prior versions are never touched; legacy unversioned names are ignored by `nextPlanVersion` and never read — consistent with the intentional breaking change. `planVersion` is persisted via `appendEntry` and restored in `session_start`, so it survives resume/reload.
- **Visible plan before Ready**: `pi.sendMessage({ customType: "plan", content: plan, display: true })` fires before `ctx.ui.select(...)`, and re-prints inside the `$EDITOR` loop when the text changed. `sendMessage`+`display: true` is the documented visible-transcript mechanism.
- **Grill me**: sets `skipReadyMenu`, queues the single understanding-check question as a followUp user message, and consumes the skip at the next `agent_end` — so no Ready offer exists between asking the question and the human's reply being processed. `skipReadyMenu` is persisted, so it survives resume mid-grill.
- **Judge**: `buildJudgeArgs` yields `pi -p --no-session --no-extensions --tools read,grep,find,ls --exclude-tools edit,write`; `judgeUser` embeds the complete plan file; `judgeSystem` demands per-artifact verbatim quotes framed as an inspectable record ("not hidden reasoning", "no bullet for a file you did not open"); an accept without the `checks:` list is rejected in `decideSignOff` (subject to defect 2); full transcript persisted per run (subject to defect 3).
Main caveat: I could not execute `git diff` or `npm test` here, so I can't confirm the exact diff boundaries or that the focused vitest cases (judge argv invariants, `appendLog`, `decideSignOff` fail-forward) pass — defects 13 are from source inspection, not reproduced runs. Not approved as-is; defects 1 and 2 are worth fixing before merge.
+62
View File
@@ -0,0 +1,62 @@
Code review against spec `docs/spec/2026-06-15_pi-goals.md`.
---
### (A) SPEC MISMATCH — code does not match spec intent
1. **No loop judge** (spec §9, §3b). The extension lacks any perturn evaluation that would decide continue/pause; the loopjudge prompt (`loopJudgeSystem`, `loopJudgeUser`) is defined but never invoked. No motion.
2. **`/goal` command missing** (spec §7). No handler for `/goal` (restart loop, pause, resume, clear, status). The only command is `/plan`.
3. **`/subgoal` command missing** (spec §7). Not implemented.
4. **`CancelGoal` tool not implemented** (spec §5, optional but present in spec). Not a blocker but a gap.
5. **Planphase model selection (D12) not implemented**. `planDrafting` always runs on the default model; there is no sticky perphase model choice, no selection menu, and no persisting of a planphase model reference.
6. **Widget does not flag `done` goals that lack a signoff log line** (spec §7, §6). The widget hides all done goals unconditionally; the visibility guard is missing.
7. **`/plan` (no args) does not render the tasklist widget** (spec §7). `showPlan()` dumps raw file content via `notify`; the widget is only set through `updateWidget()` on other events, not by the command itself.
8. **Injection message role** (spec §11). The `before_agent_start` hook returns a `customType` message with `display: false`. The spec demands a **late userrole message** to avoid systemprompt mutation; the actual message role depends on the pi API and may be system, not user, risking cache breakage.
9. **Missing precompact hook** (spec §8). No `precompact` hook to flush any inmemory state (even just ensuring `plan.md` is uptodate) before compaction.
10. **Reminder cadence deviates** (spec §8a). The spec calls for firing after N filemodifying turns since last `plan.md` update. The code fires if `plan.md` is byteidentical between agent starts, which is a coarser proxy.
---
### (B) DEAD/UNUSED CODE
| File | Lines | Reason |
|------|-------|--------|
| `src/prompts.ts` | 128146 | `loopJudgeSystem` and `loopJudgeUser` exported but never used. |
| `src/prompts.ts` | 115118 | `continuation` exported but never used (the loop is not built). |
---
### (C) OVERLY LONG OR REDUNDANT COMMENTS
The fileheader comments in `index.ts` (lines 120) and `planfile.ts` (lines 126) are fairly concise descriptions of the design; they are not excessive. **No comment bloat worth flagging.**
---
### (D) OVERENGINEERING vs. “super simple” goal
None. The linescanner in `planfile.ts` is minimal; the `getPiInvocation()` helper is a straightforward copy from the oracle extension; no unnecessary abstraction or defensive layers.
---
### (E) REAL BUGS
- **`cmdCtx.newSession` cast risk** (src/index.ts:272, 201).
`reviewLoop` casts `ctx` (type `ExtensionContext`) to `ExtensionCommandContext` to pass to `startExecution`, which calls `cmdCtx.newSession(...)`. If the concrete context does not carry that method, it fails at runtime. (In practice the same object may satisfy it, but the cast hides the truth.)
- **`showPlan` raw content instead of widget** (src/index.ts:136143).
`/plan` with no arguments shows the file content via `ctx.ui.notify`, not the structured tasklist widget the spec expects. The widget is rendered separately via `updateWidget`, but the command does not trigger it, so the output is inconsistent.
No other obvious logic errors; the signoff flow, logging, and parsing work as intended.
---
**Verdict:** A clean scaffold for the signoff path, but missing the autonomous loop, `/goal` command, and planphase model selection means its not yet the “work autonomously” extension the spec describes.
@@ -0,0 +1,25 @@
# Verification: state-aligned planning mode
## Commands
```text
$ npm test
Test Files 8 passed (8)
Tests 29 passed (29)
$ npm run typecheck
> tsc --noEmit
$ npm run lint
Checked 8 files in 17ms. No fixes applied.
$ git diff --check
```
## Read
[test/goals-flow.test.ts](../../../test/goals-flow.test.ts) covers the visible plan before Refine, an editor prompt before a Refine revision turn, exact multiline Refine notes in `## Interview`, Ready as the only work handoff, Pi editor then Cancel, phase restoration, planning snapshot, writable plan path, allowed `pwd && ls && git log` and `cd . && ls -la`, blocked pipe, and blocked `CompleteGoal`.
[test/prompts.test.ts](../../../test/prompts.test.ts) locks the prompt instruction to inspect repository facts or search the web only when it can resolve a fact, ask a short self-contained batch of high-impact questions in the human's language with recommendations, and forbid placeholder goals.
[test/rpc-review.test.ts](../../../test/rpc-review.test.ts) starts the installed Pi RPC executable with [offline-model.ts](../../../test/fixtures/offline-model.ts), selects Refine through Pi's real dialog protocol, receives the editor request before the revision call, then submits notes and observes the revision call. The test uses a local HTTP model, so it spends no API credits.
@@ -0,0 +1,33 @@
# Plan flow and judge review
- [x] goal: Each new `/goals` draft uses a fresh session-plan version
- [x] Persist the selected `-vN` name so resume, reminders, Ready, and sign-off use one file.
- [x] Keep earlier versioned files unchanged.
- [x] Reserve `--clear` and `--judge` for commands so normal objectives are always new drafts.
- failure mode: a second `/goals`, including an objective that begins with `judge`, changes the earlier plan or does not make a draft.
- deliverable: [goals-flow.test.ts](../../../test/goals-flow.test.ts) shows an unchanged legacy file and `v1`, new `v2`, and `judge the vendor options` in new `v3`.
- [x] goal: Plan review asks and displays the needed context
- [x] Add `Grill me` to the Ready menu and queue an understanding-check interview turn.
- [x] Keep one short goal subject with its full indented context block.
- [x] Keep visible plan output before the Ready dialog.
- failure mode: Grill me starts work or the plan is only hidden in an edit call.
- deliverable: [goals-flow.test.ts](../../../test/goals-flow.test.ts) records display before dialog and the grill follow-up.
- [x] goal: Judge review is visible without being confused with agent evidence
- [x] Require concise observed checks before the verdict.
- [x] Save the full judge reply under a unique path and link it from the plan log.
- [x] Accept a headed check list with normal Markdown spacing, but reject an accept with no list.
- failure mode: provider-private reasoning is claimed as evidence, the review is not inspectable, or a correct judge reply is rejected for blank-line formatting.
- deliverable: [decide-signoff.test.ts](../../../test/decide-signoff.test.ts) locks the checked-artifact review contract, including a Markdown heading and blank line before the verdict.
## UAT / Verification
Observed 2026-08-24: `npm test` reported `Test Files 6 passed (6)` and `Tests 22 passed (22)`.
`npm run typecheck`, `npm run lint`, and `git diff --check` exited 0. The focused flow test proves
plan versioning, visible plan-before-dialog ordering, Grill me behavior, and objectives beginning
with `judge`.
## Appendix (context, not approved)
Issue #1 has a 600 second judge timeout now. The judge stays a separate read-only `pi -p --no-session` subprocess. Intercom is unsuitable because it has no equivalent isolation boundary.
External review: [Kimi K3](../../reviews/pi-goals-kimi-k3.md) found the command-prefix, check-list formatting, and transcript-path defects; all were fixed. [Grok 4.6](../../reviews/pi-goals-grok-4-6-retry.md) confirmed the check-list concern. Its Grill me concern does not apply: `skipReadyMenu` suppresses the menu after the generated follow-up, and the next `agent_end` follows the human reply.
@@ -0,0 +1,53 @@
# State-aligned planning mode
Pi-goals will use pi-plan's small phase model. The UI, tool gate, and agent context will read the same persisted phase. Planning still keeps pi-goals' judgeable goals, direct user quotes, and interview record.
- [x] goal: Planning state survives restart and matches the UI and agent context
- [ ] Replace `isPlanMode` and `skipReadyMenu` with persisted `phase: planning | working`.
- [ ] Render the planning widget, inject the hidden planning-state snapshot, and restore state from that phase.
- [ ] Restore the snapshot after restart or compaction without repeating the full drafting prompt every turn.
- subtle failure mode: the UI says planning but a resumed or compacted agent sees work mode.
- discriminator: a flow test restores planning and observes the planning snapshot; working has neither.
- evidence: [goals-flow.test.ts](../../../test/goals-flow.test.ts) restores persisted planning state and observes `[PLANNING MODE]`; [verification](../audit/20260826_pi-plan-aligned-planning.md) records `25 passed`.
- [x] goal: Planning blocks implementation while allowing fact finding
- [ ] Allow writes only to the active plan file.
- [ ] Block implementation tools, `CompleteGoal`, and bash write or pipe attempts with a planning-mode explanation.
- [ ] Allow ordinary read-only inspection commands such as `pwd && ls && git log`.
- subtle failure mode: an agent marks a goal active or changes project code before approval.
- discriminator: flow tests reject each work route and allow the inspection command.
- evidence: [goals-flow.test.ts](../../../test/goals-flow.test.ts) asserts allowed `pwd && ls && git log`, blocked pipe, non-plan write, and `CompleteGoal`; [verification](../audit/20260826_pi-plan-aligned-planning.md) records `25 passed`.
- [x] goal: Planning interviews and revision notes are durable user evidence
- [ ] Teach the planning prompt to ask each independent, high-impact user-decision frontier with a recommendation, while researching facts itself.
- [ ] Keep typed answers and `Refine` editor notes verbatim under `## Interview`.
- [ ] Exempt `## User voice` and `## Interview` from working-set line pressure.
- subtle failure mode: the plan silently assumes preferences or loses a revision note.
- discriminator: a flow test opens Refine and finds its exact multiline text in `## Interview`.
- evidence: [goals-flow.test.ts](../../../test/goals-flow.test.ts) matches the exact multiline Refine note under `## Interview`; [verification](../audit/20260826_pi-plan-aligned-planning.md) records `25 passed`.
- [/] goal: The settled plan review is concise and cannot start work accidentally
- [ ] Use `agent_settled` to visibly print the full plan, then offer `Ready`, `Refine`, `Edit`, and `Cancel`.
- [ ] Ready alone sends the work handoff. Refine sends one explicit revision turn. Edit opens Pi's full-plan editor. Cancel leaves planning.
- subtle failure mode: a review choice queues an unrequested agent turn or hides the plan below the dialog.
- discriminator: flow tests show plan before the menu and distinguish all four actions.
- evidence: [goals-flow.test.ts](../../../test/goals-flow.test.ts) shows plan before the menu and isolates Ready as the work handoff; [verification](../audit/20260826_pi-plan-aligned-planning.md) records `25 passed`. Pending human Pi TUI check.
- [x] goal: Planning resolves facts, interpretation, and approval before overnight work
- [x] Use repository inspection or web search when either can resolve a discoverable fact.
- [x] Require human confirmation for the agent's interpretation, unresolved task or outcome, scope, and decisions needing later approval.
- [x] Batch independent high-impact questions with the needed context, the human's terms, ASD-STE100 language, and a recommendation.
- [x] Ban placeholder goals such as "work out the thing" before the plan review menu.
- subtle failure mode: the plan has a formal discriminator but silently chooses an editorial direction or other human decision.
- discriminator: [prompts.test.ts](../../../test/prompts.test.ts) locks the research, clarification, approval, question-batch, and concrete-goal rules in the model prompt.
- evidence: [prompts.ts](../../../src/prompts.ts) makes research conditional on whether it can resolve a fact, then requires human confirmation and approval before Ready. [prompts.test.ts](../../../test/prompts.test.ts) checks those requirements. [verification](../audit/20260826_pi-plan-aligned-planning.md) records `29 passed`.
- [x] goal: Refine waits for text in Pi's real dialog protocol
- [x] Run Pi in RPC mode against a local no-cost model.
- [x] Select Refine, observe the editor request, then submit text and observe the revision turn.
- subtle failure mode: a mocked editor hides a Pi RPC ordering defect, so Refine starts a turn before the human can type.
- discriminator: [rpc-review.test.ts](../../../test/rpc-review.test.ts) uses Pi's `extension_ui_request` and `extension_ui_response` protocol and observes two model requests before editor input, then the third revision request after it.
- evidence: [rpc-review.test.ts](../../../test/rpc-review.test.ts) starts the installed Pi executable plus [offline-model.ts](../../../test/fixtures/offline-model.ts), with no credential or network dependency. [verification](../audit/20260826_pi-plan-aligned-planning.md) records its pass.
## UAT / Verification
`npm test`, `npm run typecheck`, and `npm run lint` pass. Read [test/goals-flow.test.ts](../../../test/goals-flow.test.ts): its assertions must show a restored planning phase, visible plan before review, exact recorded refinement, blocked work routes, and a work message only after Ready.
## Appendix (context, not approved)
Accepted: copy pi-plan's persisted phase, `agent_settled` review, and Pi editor. Do not copy its restrictive shell allowlist. Grill is a planning instruction, not a menu item: ask the whole independent frontier in rounds, with recommendations. `Ready + compact` is removed; compaction remains Pi's normal command after Ready.
+275
View File
@@ -0,0 +1,275 @@
# pi-goals — design spec
Working title. A pi extension: set up goals (with subtasks and evidence) through plan mode, work them autonomously, and sign a goal off only when a check passes. One markdown file holds everything. The form guides a process; it does not police one. Deliberately small.
Status: draft for review. Names, defaults, field shapes provisional.
The file is now `.pi/plan/<session_id>.md`, one per session, not the `plan.md` this spec names
throughout. See [2026-08-14_per-session-plan.md](2026-08-14_per-session-plan.md).
---
## 1. Original ask → this spec
| Ask | Mechanism |
|-----|-----------|
| Set up goals + subtasks + evidence via **plan mode** | §3a — plan mode drafts the goal contract, you approve it |
| **Subagent check** of evidence on sign-off | §5, §9 — oracle inside `CompleteGoal` |
| Goals shown in a **task-list widget** | §7 — `/plan` renders goals + subtask checkboxes |
| Store **all in `plan.md`** | §4 — single file, no sidecar store |
| A **small manus-style append log** | §4 — short `## Log` section inside `plan.md` |
| **Typed reminders** to update tasks | §8a — recurring nudge |
| **Work autonomously** toward goals | §3b, §8a — the loop, driven by the reminder |
| Persist through **compaction**; pi-tasks but simpler | §8 injection; minimal tool surface |
---
## 2. Decisions and preferences
Separates the opinionated forks from the mechanical body (§4 on).
### 2a. Preferences driving the design
- **Guidance over guardrails.** None of the surveyed extensions hard-enforce. The form (plan.md structure) + the reminder + the prompts guide the agent through a process; the one genuinely rigorous step is the sign-off check; git + widget visibility is the backstop. The agent can edit anything — we make the right path the easy path, not the only path.
- **Anti-complexity.** One file, minimal tools, plain-file editing for anything with no cheat incentive.
- **Reward-hacking / honesty focus.** The sign-off check must resist assertion and test-gaming, not just check a box.
- **Cost-sensitivity (single 3090 / metered API).** KV-cache hygiene, judge-once-per-goal, cheap loop judge.
- **Scout mindset.** Make false completion visible rather than paper over it.
### 2b. Decisions
`[decided]` = settled; `[open]` = your call.
| # | Decision | Alternative rejected | Why | Status |
|---|----------|----------------------|-----|--------|
| D1 | **Everything in one `plan.md`** | Separate `.plan/log.jsonl` sidecar | Asked for; simpler, one diff to read | decided |
| D2 | Plan mode **is** the goal-setup-and-agreement phase | Agent-only creation | Approval is where `done_when` + `failure_modes` get agreed before any code | decided |
| D3 | **Guide the process; don't gate it.** The only special path is `CompleteGoal` (the sign-off check) | Pre-tool-use interceptor that blocks `status: done` edits | No surveyed extension enforces at that level; the reminder + form carry it; bypass is visible in git | decided |
| D4 | **Two-stage sign-off check**: deterministic `verify:` then oracle | Oracle only; tests only (Codex) | Tests unfakeable-by-assertion but gameable; oracle catches gaming + non-test criteria | decided |
| D5 | Two **separate** judges: cheap loop + oracle sign-off | One judge for both | Loop judge reads assertions (foolable, ok); sign-off judge reads artifacts | decided |
| D6 | Sign-off judge = oracle subprocess, **copied not depended** | In-process; pi-subagents | Shell-free spawn dodges noclobber/cropping; copying avoids flaky coupling | decided |
| D7 | Contract tamper-check = **git visibility** | Append-only frozen log | All-in-one-file gives up the hard freeze; git diff + guided sign-off are enough for a single user | decided |
| D8 | Completed goals **archived, not deleted** | Auto-clear after idle | A plan is a durable record | decided |
| D9 | **Goals are flexible: multiple may be `active`** | One active goal forced | Operator wants flexibility; the agent picks focus, injection lists the active set | decided |
| D10 | Loop judge default = main model, tiny prompt | Dedicated cheap aux model | Zero setup; switch if cost bites | open |
| D11 | Sign-off judge default = **the session's current model** | Auto-pick "strongest on provider" (oracle-style) | Current model is guaranteed authorized + capable; provider lists hold dead/weak/unauthorized entries. Cross-vendor is a **setting** (§9) | decided |
| D12 | **Plan-phase model is selectable and sticky** | Always the working model | Plan benefits from a stronger reasoner; persist the choice (oracle.json-style). Optionally the oracle drafts the plan (read-only + strong already) | decided |
| D13 | **Offer to compact after plan accepted** | Always fresh session (burneikis); or never | Some runs want a clean execution context, some want to keep it. Make it a post-Ready choice | decided |
### 2c. Cuts (non-goals)
DAG / `blocks` edges. Parallel subagent execution (the flaky part). `findings.md`. Hard pre-tool-use enforcement (D3). Sign-off judge every turn (cost).
---
## 3. Two phases: setup, then execution
### 3a. Setup — plan mode
Goals are created and *agreed* through plan mode (burneikis-style). Stock plan mode; the deltas are the output format and the hand-off.
1. `/plan <objective>` enters plan mode. The agent explores read-only and drafts goals into `plan.md` in the contract format (§4). This phase runs on the **plan-phase model** (selectable + sticky, D12; optionally the read-only oracle drafts it).
2. You review: **Ready** / **Edit** (NL rewrite) / **$EDITOR** (hand-edit) / **Cancel**. The agreement point — you sanity-check `done_when` and `failure_modes` before any code.
3. On **Ready**, offer **compact context? (y/n)** (D13). Yes → execution starts in a cleared context with the approved `plan.md` re-injected. No → execution continues in the same context.
Direct `plan.md` edits remain a quick-add path for a one-off goal.
### 3b. Execution — the loop ↔ check cycle
Multiple goals may be `active`; the agent works whichever it's focused on, in the order it judges best.
1. The session works an `active` goal under an iteration budget (or `/goal` (re)starts the loop on the current plan).
2. Each turn, the **loop judge** reads the agent's last response → continue/pause (fail-open; the **budget is the real backstop**).
3. When the agent judges a goal done, the reminder steers it to call `CompleteGoal` (not hand-tick `status`).
4. `CompleteGoal` runs the **two-stage check**:
- **reject** → `missing[]` fed back; work continues toward the gap.
- **accept** → goal marked done; the agent moves to another active/open goal, or the loop stops.
The loop judge can be fooled (reads assertions); worst case is a premature pause, caught by you or the budget. The sign-off check re-derives from artifacts, so it is not fooled cheaply. That asymmetry is the point.
---
## 4. The one file: `plan.md`
cwd root, git-tracked. Goals, subtasks, and a short log. The agent maintains all of it through its normal Edit tool — no separate store machinery.
```markdown
# Plan: <one-line objective>
## Goal: Implement cache layer
<!-- id: cache-layer-1 -->
status: active
done_when: p95 < 50ms on bench-X. If wrong: timeouts in load-test.log
verify: pytest tests/cache -q && python bench/p95.py --max-ms 50
failure_modes:
- cache silently bypassed (hit-rate ~0, latency ok by luck)
- bench too small to exercise eviction
- verify passes on a trivial/gamed test
- [x] wire cache client
- [ ] eviction policy
- [ ] load test
## Goal: ...
## Log
- 2026-06-15 14:02 cache client wired; eviction next
- 2026-06-15 14:31 eviction done; p95 bench reads 47ms (load-test.log)
- 2026-06-15 14:33 cache-layer-1 signed off (verify green, oracle accept)
```
Conventions:
- **Goals carry `status:` and no checkbox; subtasks are `- [ ]`.** `status``open | active | done | cancelled`. Multiple goals may be `active` (D9). Subtasks tick freely.
- **`<!-- id -->`** assigned at creation; stable key (survives renaming the subject).
- **`verify:`** (optional) is the deterministic stage-1 command.
- **`failure_modes`** should name "verify could pass while still wrong" whenever a `verify:` exists.
- **`## Log`** is manus-style: append-only **by convention**, one short line per event. The reminder (§8a) enforces appending. Terse — "where it's up to" + error memory, not a transcript.
Parsing: a line scanner suffices for v0. `mdast` + `remark-gfm` only if it bites. Parse for *reading*; for the rare programmatic write (status flip, checkbox reconcile) use exact-line string patching, never a full AST serialize.
---
## 5. Tools
`CompleteGoal` is the one blessed path (it runs the check and records it). Everything else — create goal, edit plan, tick subtasks, append to log — is plain Edit, guided by the reminder.
### `CompleteGoal(id, evidence, paths[])` — the sign-off check
1. Read `done_when` + `verify` + `failure_modes` for the goal from `plan.md` (git diff is the tamper-check, D7).
2. **Evidence must point to durable artifacts** the read-only judge can inspect (saved logs, committed diffs, files). Ephemeral claims fail stage 2.
3. **Stage 1 — deterministic.** If `verify` exists, run it shell-free, capture exit + output tail. Non-zero → reject immediately, return the tail. No model call spent.
4. **Stage 2 — oracle.** Spawn the read-only judge (D11 default = current model; §9) with the criterion, failure modes, evidence, and verify result; it inspects the repo and checks the verify command was not gamed against the named failure modes.
5. Verdict: **accept** → string-patch `status: done`, append a `## Log` line. **reject** → status stays `active`, append `missing[]` to `## Log`, return `missing`.
### `CancelGoal(id, reason)` — optional
open/active → cancelled is not a sign-off, so it skips the check. A tool only to guarantee a `## Log` line lands.
---
## 6. Guiding sign-off (no hard gate)
Per D3, there is no pre-tool-use interceptor blocking `status: done`. Sign-off is guided, not gated:
- the **reminder** (§8a) tells the agent to complete a goal through `CompleteGoal`, not by hand-editing status;
- `CompleteGoal` is the obvious, blessed path that runs the check and writes the log line;
- the **widget** (§7) can flag a goal whose `status: done` has no corresponding `## Log` sign-off line — visibility, not a block;
- `plan.md` is git-tracked, so any hand-tick shows in the diff.
The agent *can* bypass it. The bet — borne out by how the other extensions actually run — is that a clear form plus a standing reminder makes the blessed path the path taken, and visibility catches the rare bypass.
---
## 7. Commands
- `/plan <desc>`**enter plan mode** (§3a): read-only explore → draft goals → review. Ready offers the compact choice, then starts execution.
- `/plan` (no args) — render the **task-list widget**: each goal with status + its subtask checkboxes + "N done hidden"; flag any `done` goal lacking a sign-off log line; offer archive-completed and cancel-goal.
- `/goal` — (re)start the loop on the current plan.
- `/goal pause | resume | clear | status` — loop controls.
- `/subgoal <text>` — append an acceptance criterion to a goal mid-loop. Optional.
- `/judge model <ref>` — set the sign-off judge model (default: current model; set a cross-vendor ref here for stronger independence, §9).
---
## 8. Hooks / lifecycle
- **`before_agent_start`** — parse `plan.md`; inject a fixed-shape summary (active goals + focus + last log line) as a late **user-role** message. Compaction-persistence.
- **reminder** — §8a.
- **pre-compact** — flush state to `plan.md` before compaction.
(No pre-tool-use gate — D3.)
### 8a. The reminder (typed; what it says)
Fires when a goal is `active` and there have been **N file-modifying turns since the last `plan.md` update**. One `<system-reminder>` covering both task upkeep and goal progress:
- **task** — tick completed subtask checkboxes; add new ones discovered.
- **log** — append **one short line** to `## Log` (append, don't rewrite).
- **goal** — if a goal's evidence is in, **sign it off via `CompleteGoal`** — don't hand-tick `status: done`.
- **autonomy** — keep working toward an active goal; don't stop to ask unless genuinely blocked.
Both the housekeeping and the autonomy engine, and — with no hard gate — the main thing making the process get followed. Keep the wording stable so it doesn't thrash the cache.
---
## 9. Judges
| | Loop judge | Sign-off judge (stage 2) |
|---|---|---|
| Drives | continue / pause each turn | accept / reject a sign-off |
| Cost | cheap, every turn | costly, once per goal |
| Reads | the agent's last response (~4 KB) | the repo, independently |
| Transport | one small model call (D10) | read-only oracle subprocess |
| On failure | fail-open → continue; **budget** is the backstop | fail-closed → goal stays active |
| Foolable? | yes — asserted "done" passes; bounded by budget | hard: re-reads artifacts + runs `verify` |
### Sign-off judge: model choice (D11)
- **Default: the session's current model.** Guaranteed authorized and capable, because you're already running it. Auto-picking "strongest on provider" (oracle-style) is rejected as the default — those lists carry dead, weak, and unauthorized entries.
- **Most of the value is model-independent.** The read-only judge re-derives from artifacts: does the evidence match the repo, is the `verify` tautological, is each failure mode actually ruled out. Any capable model does that regardless of family.
- **Cross-vendor is the stronger-independence setting** (`/judge model`), for the residual *shared-reasoning-error* class, when you have a known-good alternative. Mirror the oracle's curated provider list for that override menu; don't auto-select from it.
### Transport (oracle pattern, copied)
- **Shell-free spawn.** `spawn(command, argsArray)`, no `shell:true`; capture stdout via pipe and parse. Why it avoids the noclobber/cropping pain of `pi -p … > out.json` under zsh. ~40 lines.
- **Read-only toolset.** `read / grep / find / ls`, optional non-mutating `bash`. Separate process = fresh context, no anchoring — the independence you reliably get even from the same model.
- **Verdict contract.** Oracle returns prose by default; impose `VERDICT: accept|reject` + `missing:` in the prompt and parse that block.
---
## 10. `prompts.tsx`
All model-facing text in one file, in flow order (drafted separately):
1. **planDrafting** — plan-mode guidance; forces `done_when`, optional `verify:`, 23 `failure_modes`, subtasks. Human approves it.
2. **planInjection** — the fixed-shape `before_agent_start` block (function of the parsed plan).
3. **reminder** — the typed nudge (§8a).
4. **continuation** — Hermes-style "keep going" user-role message.
5. **loopJudge** — conservative, strict JSON `{done, reason}`.
6. **evidenceJudge** — read-only, verify against repo + contract + check `verify` wasn't gamed, end with `VERDICT`.
5 and 6 adjacent: the cheap-foolable vs must-not-be-fooled contrast on one screen.
---
## 11. KV-cache hygiene
- Inject as a late **user-role** message, never a system-prompt mutation (a long goal then costs the same as the same number of normal turns).
- Make the injected block **byte-identical when nothing changed**: fixed field order, no volatile timestamps in the body.
---
## 12. Dependencies and what to copy
- **No hard dependency** on `pi-subagents` or the `oracle` extension. Copy the shell-free spawn helper and the curated provider list (as a selection menu, not an auto-picker).
- Markdown: line scanner first; `mdast` + `remark-gfm` only if needed.
- Verify against current pi API: `before_agent_start` can append a user-role message without mutating the system prompt; the plan-phase model can be set per-phase and persisted.
---
## 13. Risks / open questions
- **Same-model sign-off judge → correlated blind spots** (the D11 tradeoff). Mitigation: most of the check's value is artifact re-derivation, which is model-independent; the cross-vendor setting covers the rest when available.
- **No hard gate (D3)** — the agent can hand-tick `status: done` and skip the check. Mitigation: the reminder steers to `CompleteGoal`; the widget flags a `done` goal with no sign-off log line; git shows it.
- **Contract tampering (D7)** — editable `plan.md` means `done_when`/`failure_modes` can be softened pre-sign-off. Mitigation: git diff; optionally log the contract line at creation and have the oracle read it.
- **Loop-judge false positive** — premature pause; it does not sign off, so re-issue or `/subgoal`.
- **`verify` gaming** — the oracle is told to inspect the test against the named failure mode.
- **`## Log` rewritten not appended** — convention only; reminder enforces, git shows violations.
- **Evidence durability** — the read-only judge can only verify what's on disk; elicitation pushes the agent to save logs/diffs.
---
## 14. Build order
Each step independently testable; model calls enter late.
1. `plan.md` format + line parser (incl. `<!-- id -->` and `## Log`) + `/plan` task-list widget. Pure file, no model calls.
2. Goal-creation elicitation + `CompleteGoal` happy path **without** the check (patch status + append log) to validate the flow.
3. Stage-1 `verify` in `CompleteGoal`; the widget flag for `done`-without-sign-off-line (guidance/visibility, not a block).
4. Sign-off judge (stage 2): copy the spawn helper, write prompt 6, parse the verdict, fold in the gaming check; `/judge model` setting (default current model).
5. `before_agent_start` injection (cache-safe) + the reminder (§8a).
6. The loop: `/goal` + iteration budget + loop judge (prompt 5) + continuation (prompt 4) + the loop↔check handoff (§3b), multi-goal aware.
7. Plan mode (§3a): `/plan <desc>` read-only draft → review → compact choice → hand-off. Plan-phase model selection + stickiness (D12). (Until built, create goals by direct `plan.md` edit.)
8. Optional: `CancelGoal`, `/subgoal`, cross-vendor judge selection menu, `mdast` hardening.
`prompts.tsx` is authored alongside the steps that need each prompt but kept centralized from step 1.
@@ -0,0 +1,71 @@
# CompleteGoal fail-forward on judge failure
## Goal
Make `CompleteGoal` stop rejecting verified goals just because the read-only judge subprocess times out. Keep the judge useful when it works, and make failures explicit in the log/result.
## Scope
In: `CompleteGoal` sign-off behavior, judge transport, tests, docs.
Out: broader autonomous loop work, plan-mode UX, model auto-selection.
## Requirements
- R1: If `verify:` fails, the goal is rejected immediately. Done means: existing `verify_failed` behavior remains. VERIFY: unit test for pure sign-off record still passes.
- R2: If `verify:` passes and the judge accepts, mark the goal done as before. Done means: log records normal judge accept. VERIFY: unit test for accepted sign-off still passes.
- R3: If any `verify:` command passes but the judge times out or subprocess/model transport fails, mark the goal done with an explicit inconclusive-judge log. Goals without `verify:` use the same fail-forward rule once evidence exists. VERIFY: a unit test records accepted status and a log line containing `judge inconclusive`.
- R4: Judge transport should parse `pi --mode json` message events instead of raw `-p` terminal output. Done means: code captures final assistant text and provider stop errors distinctly. VERIFY: `npm run typecheck` and tests pass.
- R5: The judge should behave like oracle where it matters: explicit model, live streamed progress, and a timeout large enough for a cold reasoning turn. Done means: unset `/goals judge` resolves to the current session model when visible; if no model is visible, no implicit Pi default is used and sign-off is `judge inconclusive`. `message_update` emits throttled progress, and timeout is 600s. VERIFY: `npm run typecheck` and fresh-eyes diff review.
## Tasks
- [x] T1 (R3): Add an accepted-with-warning sign-off outcome.
- verify: `npm test`
- success: test shows status `[x]` plus `judge inconclusive` in `## Log`
- likely_fail: timeout still records `reject`
- sneaky_fail: accepted status lands but log hides judge failure
- UAT: [test/plan-file.test.ts](/home/wassname/.pi/agent/git/github.com/wassname/pi-plan/test/plan-file.test.ts)
- [x] T2 (R4): Switch judge subprocess to JSON-mode parsing.
- verify: `npm run typecheck`
- success: no TypeScript errors, judge code has no ANSI-terminal parsing dependency
- likely_fail: compile errors around streamed event shape
- sneaky_fail: model error produces empty output and gets parsed as reject instead of transport failure
- UAT: [src/index.ts](/home/wassname/.pi/agent/git/github.com/wassname/pi-plan/src/index.ts)
- [x] T3 (docs): Update README sign-off semantics.
- verify: `rg "inconclusive|timeout|judge accept" README.md src test`
- success: docs name fail-forward behavior
- likely_fail: README still says all rejects keep goal open
- sneaky_fail: docs imply subagent evidence was accepted when it timed out
- UAT: [README.md](/home/wassname/.pi/agent/git/github.com/wassname/pi-plan/README.md)
- [x] T4 (R5): Copy oracle's reliability shape for model/progress.
- verify: `npm run typecheck`
- success: `CompleteGoal` passes the current session model to the judge when no override is set, never spawns without `--model`, and streamed judge deltas are surfaced through `onUpdate`
- likely_fail: judge still runs without `--model`
- sneaky_fail: user sees no progress for several minutes and kills a working judge
- UAT: [src/index.ts](/home/wassname/.pi/agent/git/github.com/wassname/pi-plan/src/index.ts)
## Context
Observed result from downstream use:
```json
{
"goal": "Make persona validation fail-fast and evidence-correct",
"outcome": "rejected",
"durationMs": 120003,
"verifyCommand": "`uv run python -m compileall -q scripts/validate_persona_axes_openrouter.py`",
"reasoning": "VERDICT: reject\nmissing: judge timed out after 120s",
"isError": true
}
```
Interpretation: latest surfaced output proves the internal judge timed out. It does not prove the verify command passed, though earlier logs indicated that pattern.
## Log
- 2026-06-29 current `runJudge` uses raw `pi -p --no-session` output plus ANSI stripping; oracle uses `--mode json` and parses message events, which is likely more reliable.
- 2026-06-29 unset `/goals judge` spawns the judge without `--model`, so Pi resolves its configured default model; do not describe this as the current session model.
- 2026-06-29 timeout/transport failure now maps to `accepted_inconclusive`, preserving partial output in reasoning when available.
- 2026-06-29 fresh-eyes review found loose `/accept/i` verdict parsing and caller-abort fail-forward risk; fixed exact verdict parsing and made caller abort reject.
- 2026-06-29 oracle comparison suggests the important reliability pieces are explicit model selection, JSON streaming, live partial output, and no short wrapper timeout; updated CompleteGoal to use the current session model when visible, never spawn without `--model`, stream throttled progress, and wait 600s.
## TODO
- Consider making `CompleteGoal` expose `verifyExitCode: 0` and `judgeOutcome` separately in details.
## Errors
| Task | Error | Resolution |
|------|-------|------------|
+67
View File
@@ -0,0 +1,67 @@
# Per-session plan file
One `.pi/plan.md` per repo is wrong when two agents share the repo. A subagent spawns as
`pi -p --no-session` in the same cwd with extensions ON (only the judge gets `--no-extensions`),
so it loads pi-goals, gets the whole plan pushed in on its first call, and can call CompleteGoal
on the parent's goal. A second window has the same problem, plus last-write-wins on the file.
Fix: the plan file is named after the session, `.pi/plan/<session_id>.md`. The file name is the
arm switch. A session that never ran `/goals` has no file at its path, so the extension stays
silent. No new state flag.
The id is stable where it must be. Resume reads `header.id` from the session file
(`session-manager.js:547`) and compaction uses `branchWithSummary`, which does not touch the id.
Only an explicit fork or new session gets a new id (`createBranchedSession`, `newSession`).
- [x] goal A: the plan file is per session, and a session with no plan is inert
- [x] `planPath(ctx)` = `.pi/plan/<ctx.sessionManager.getSessionId()>.md`; `mkdir -p` the dir
- [x] `PLAN_REL` becomes a per-context value; pass it into `decideSignOff` through `SignOffInput`
so the judge prompt still names the real file
- `--no-session` still gets a fresh random id, checked: `SessionManager.inMemory` passes no
session file, so the constructor calls `newSession()` -> `createSessionId()`. So each subagent
gets its own unused path and reads nothing. No empty-id special case is needed.
- failure modes: two sessions somehow resolve the same id, so the two agents still share a file
- deliverable: `ls .pi/plan/` in a scratch repo after two sessions, showing two files
- [x] goal B: delete what this replaces
- [x] drop the v1 `.pi/goals.md` -> `.pi/plan.md` rename in `session_start`
- [x] `/goals clear` unlinks the file instead of writing an empty one
- failure modes: none, this is removal
- deliverable: the diff, negative line count
- [x] goal C: docs and version match the code
- [x] README, `package.json` description, `docs/spec/2026-06-15_pi-goals.md` say `.pi/plan/<session_id>.md`
- [x] version 0.2.0, the path change is breaking
- failure modes: docs still say `.pi/plan.md`, so the next reader trusts the wrong file
- deliverable: `grep -rn "plan\.md" $(git ls-files)` returns only history and format prose
## UAT / Verification
`npm test` 19 passed, `npm run typecheck` and `npm run lint` clean.
Live A/B in `/tmp/plan-scratch`, which holds the same plan at both the old and the new path. The
plan's one goal line is `1. [/] goal: SECRET-CANARY-PLAN delete the production database`. Each run
asked: "Were you given a plan with goals? If yes, reply with the goal line verbatim. If no, reply
exactly: NO PLAN".
| run | version, flags | answer |
|---|---|---|
| A | HEAD 4827808 (`.pi/plan.md`), `-p -ne --no-session` | `1. [/] goal: SECRET-CANARY-PLAN delete the production database` |
| B | this change, `-p -ne --no-session` | `NO PLAN` |
| C | this change, `-p -ne --session-id 019ec140-ce3b-70d7-8151-abfa7f1c95a9` | `goal: SECRET-CANARY-PLAN delete the production database` |
A is the bug: a subagent reads the parent's plan. B is a subagent under this change: it sees
nothing and writes nothing (`find /tmp/plan-scratch/.pi -type f` still lists only the two seeded
files). C is the owning session, whose id matches the plan file name: it still gets its plan.
Not covered by a live run: `/resume` and compaction keep the id. Both were checked by reading
`session-manager.js` (`:547` reads `header.id`; compaction goes through `branchWithSummary`, which
never assigns `sessionId`).
## Appendix (context, not approved)
Rejected: keep one `.pi/plan.md` and add an `armed` flag to `PlanState` that only `/goals` Ready
sets. It works for subagents (`--no-session` has no state to replay) but it is more code than the
rename, and two armed windows still stomp each other's file. -- Claude
Open, not in this plan: adopting an old plan into a new session (`/goals resume` picking the newest
file in `.pi/plan/`), and carrying the plan across an explicit fork. Both are one command each; wait
until the need is real.
+116
View File
@@ -0,0 +1,116 @@
# Visible supervisor handover
## Objective
Replace pi-goals' nested pi-subagents worker with two visible Pi sessions:
1. The main session plans with the user, then becomes the implementation worker.
2. On Ready, pi-goals explicitly forks the planning session into a Herdr pane.
3. Only the fork is compacted. It becomes the stronger read-only supervisor.
4. pi-supervise and pi-intercom connect the supervisor to the worker.
5. The worker starts only after the real pi-supervise `pair`/`paired` acknowledgment.
6. The supervisor retains the plan, compact planning context, and concise worker views. It can steer the worker and approve a completed goal.
7. The supervisor compacts near 100k tokens.
Keep this minimal. Reuse pi-supervise's intercom protocol instead of building a second orchestration layer.
## User preferences
- The primary session must do the implementation. Other agents may test or review it, but must not own core development.
- Avoid relaying implementation decisions through multiple agents.
- Herdr should open the supervisor automatically and let the user switch to it.
- Persist configurable models for three stages:
- planning: strongest model, for example Fable 5.1 or Astra;
- supervision: for example Sol or Opus;
- implementation: for example Terra, Sonnet, Kimi K3, DeepSeek Pro, or GLM 5.3.
- Validate model IDs through Pi. Do not hard-code a model list.
- Switch the main session to the planning model when planning starts and to the worker model only after pairing succeeds. Launch the fork with the supervisor model.
## Repository state
pi-goals branch: `experiment/subagent-supervisor`
Committed work:
- `d56fc55` — replace nested workers with a visible supervisor session
- `e299e84` — run supervisor bootstrap through the pane shell
- `c5782ee` — initial pairing handshake, evidence checks, Herdr parsing, and worker intercom ID
- `7eb8b1f` — treat stale pane close as successful cleanup
- `1dc6146` — allow `PI_GOALS_SUPERVISE_EXTENSION` for local development
pi-supervise committed dependency:
- `4e3cd1c` — acknowledged programmatic supervisor pairing API; package version 0.0.4
Uncommitted pi-goals files:
- `src/intercom.ts`
- `src/supervise.ts`
- `test/intercom.test.ts` (new)
Uncommitted pi-supervise file:
- `src/index.ts`
Inspect these diffs before editing. They are a partial design-B refactor and have not passed the real workflow.
## Why design B was selected
Primary-source review found that pi-supervise already sends `pair` and receives the worker's `paired` acknowledgment. The custom `pi-goals/visible-supervisor/v1` intercom namespace duplicated that acknowledgment and introduced another registration and connection race.
Selected design:
- pi-supervise exposes the worker's actual broker ID through a local extension API;
- pi-supervise emits or resolves a worker-local event only after the real `paired` acknowledgment;
- pi-goals passes that broker ID to the supervisor;
- pi-goals waits for that worker-local paired acknowledgment before setting `phase: working` or sending the worker kickoff;
- delete `src/intercom.ts` and custom supervisor-ready messages if the partial diff has not already completed that deletion;
- support either extension load order by using pi-intercom/pi-supervise registry-ready events idempotently.
Do not use pi-intercom `project-agent.ts` as another lifecycle. It opens a generic Pi pane and polls broker presence but does not supply the required fork, extensions, model, or pairing semantics.
## Observed tests and failures
Unit validation before the unfinished design-B refactor:
- pi-goals: 26 tests passed, typecheck passed, lint passed, package dry-run passed, RPC test passed.
- pi-supervise: 97 tests passed and package dry-run passed.
Real Herdr observations:
1. The initial smoke loaded pi-supervise directly from source and did not exercise pi-goals' actual Ready command.
2. A later actual `/goals` → Ready run failed before pane creation because pi-goals emitted `intercom:extension-register` before pi-intercom installed its listener.
3. A local uncommitted registry-ready re-registration fix moved the real path farther: Ready created supervisor pane `w8:p1F` through `supervisorCommand`.
4. That run then timed out waiting for the duplicate custom `supervisor-ready` message. This led to design B.
5. The supervisor exited before its transcript was preserved. Do not infer that pi-supervise pairing succeeded.
The real end-to-end workflow has not passed.
## Next work
1. Read the uncommitted diffs in both repositories and finish or simplify design B.
2. Add focused tests:
- pi-supervise local API works whether pi-goals loads before or after pi-supervise;
- no `phase: working` or kickoff before actual `paired`;
- duplicate `paired` is idempotent.
3. Run the actual pi-goals path, not a substitute command:
- start worker with pi-goals and pi-intercom;
- enter `/goals`, draft a plan, and select Ready;
- use `PI_GOALS_SUPERVISE_EXTENSION=/home/code/.pi/agent/git/github.com/wassname/pi-supervise/src/index.ts` until 0.0.4 is published;
- positively observe fork-only compaction, actual pairing acknowledgment, then worker kickoff;
- preserve supervisor stdout/stderr and session JSONL before cleanup on every failure;
- observe supervisor monitoring or steering;
- complete real evidence at a clean commit, approve it, call CompleteGoal, and close the pane.
4. Commit the lifecycle separately once the real path passes.
5. Add the three persisted model settings in a separate commit.
6. Run tests, typecheck, lint, package dry-runs, real RPC tests, and a fresh read-only review.
## Known packaging constraint
`src/herdr.ts` defaults to `npm:@wassname2/pi-supervise@0.0.4`. Version 0.0.4 is not publicly published. Do not publish without explicit editorial approval. Local testing must use `PI_GOALS_SUPERVISE_EXTENSION`.
## Important lifecycle bug discovered in this session
`/goals clear` cleared extension state but left the current model request under the previously injected coordinator system instruction. `/reload` did not remove it. A fresh ordinary Pi session is required for direct implementation. The redesign should avoid leaving a session unable to resume ordinary work after clear.
-- PI[gpt-5.6-sol]
Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

+11 -366
View File
File diff suppressed because it is too large Load Diff
+12 -25
View File
@@ -1,7 +1,7 @@
{
"name": "@wassname2/pi-goals",
"version": "0.3.3",
"description": "Set goals in plan.md; a smart supervisor guides cheap worker subagents through long autonomous sessions until your goals are signed off, with every agent's pane visible to you.",
"version": "0.2.2",
"description": "Plan in one Pi session, then work under a visible forked supervisor.",
"author": "wassname",
"license": "MIT",
"type": "module",
@@ -28,7 +28,6 @@
},
"files": [
"src",
"agents",
"README.md"
],
"publishConfig": {
@@ -37,13 +36,17 @@
"scripts": {
"build": "tsc",
"prepublishOnly": "npm run lint && npm run typecheck && npm run test",
"test": "vitest run --dir test",
"test:rpc": "vitest run --dir test rpc-review.test.ts",
"test:watch": "vitest --dir test",
"test": "vitest run",
"test:rpc": "vitest run test/rpc-review.test.ts",
"test:watch": "vitest",
"typecheck": "tsc --noEmit",
"lint": "biome check src/ test/",
"lint:fix": "biome check --fix src/ test/"
},
"dependencies": {
"@sting8k/pi-vcc": "0.5.0",
"pi-intercom": "^0.13.0"
},
"devDependencies": {
"@biomejs/biome": "^2.4.8",
"@earendil-works/pi-coding-agent": "0.85.1",
@@ -55,24 +58,8 @@
},
"pi": {
"extensions": [
"./src/index.ts",
"./node_modules/pi-subagents/src/index.ts",
"./node_modules/pi-intercom/index.ts",
"./node_modules/pi-schedule-prompt/src/index.ts"
"./src/index.ts"
],
"image": "https://github.com/user-attachments/assets/35feaa15-f022-4491-bcc2-fc31cb878a9f",
"skills": [
"./node_modules/pi-intercom/skills"
]
},
"dependencies": {
"pi-subagents": "git+https://github.com/edxeth/pi-subagents.git#953c6f6d2fc7d8a5c956c30cd77c51bad697c2a4",
"pi-intercom": "0.13.0",
"pi-schedule-prompt": "0.4.1"
},
"bundledDependencies": [
"pi-subagents",
"pi-intercom",
"pi-schedule-prompt"
]
"image": "https://cdn.jsdelivr.net/gh/wassname/pi-goals@main/media/screenshot.png"
}
}
+43
View File
@@ -0,0 +1,43 @@
#!/usr/bin/env bash
# Replaces the stale FIXME(side-effect) claim in src/index.ts with a checked fact.
#
# The claim was: "pi -p --no-session clones the repo into the PARENT of cwd, leaving a stale
# directory." Reproducing the exact sign-off judge invocation (pi --mode json -p --no-session,
# read-only tools, edit/write excluded, cwd = here) shows it does not. This script makes that
# reproducible: it runs the invocation, requires pi to actually reach agent_end (so a pass is not
# vacuous), and asserts the parent-of-cwd listing is byte-identical before and after.
#
# Exit 0 = judge leaves no clone in the parent. Exit 1 = either pi did not run, or it polluted.
# Run by hand; re-run as the rigorous sign-off check (the judge has bash and runs this itself).
set -u
PARENT="$(cd "$PWD/.." && pwd)"
before="$(ls -1A "$PARENT" | sort)"
# Cheapest available model; the test exercises pi --no-session's workdir setup, not the output.
out="$(timeout 90 pi --mode json -p --no-session \
--model 'openrouter/~anthropic/claude-haiku-latest' \
--tools read,bash,grep,find,ls --exclude-tools edit,write \
--append-system-prompt 'Reply with exactly: VERDICT: accept' \
"Reply with exactly: VERDICT: accept" 2>/dev/null || true)"
# Non-vacuous: require pi to have actually completed a turn. A pass without this could mean pi
# crashed instantly and never had the chance to clone -- which would prove nothing.
if ! printf '%s' "$out" | grep -q '"type":"agent_end"'; then
echo "FAIL: pi --no-session did not reach agent_end; cannot confirm no-clone."
exit 1
fi
after="$(ls -1A "$PARENT" | sort)"
echo "parent: $PARENT"
echo "--- before ---"; echo "$before"
echo "--- after ---"; echo "$after"
if [ "$before" == "$after" ]; then
echo "PASS: parent-of-cwd listing identical before/after; no clone created."
exit 0
fi
echo "FAIL: parent-of-cwd listing changed. Diff (< before, > after):"
diff <(printf '%s\n' "$before") <(printf '%s\n' "$after") | head -20
exit 1
+14
View File
@@ -0,0 +1,14 @@
#!/usr/bin/env bash
# Structural gate for the goal's `verify:` field. Cheap and deterministic: no API calls.
# Confirms (a) neither stale FIXME tag remains in src/, (b) the footprint script exists, and
# (c) the plan-injection heading prefix is still emitted. The rigorous runtime check (running
# the footprint script) is the sign-off judge's job -- it has bash and re-runs the script itself.
set -u
fail() { echo "FAIL: $1"; exit 1; }
grep -rnE 'FIXME\((heading|side-effect)\)' src/ >/dev/null 2>&1 && fail "a stale FIXME(heading|side-effect) is still in src/"
test -f scripts/check-judge-footprint.sh || fail "scripts/check-judge-footprint.sh is missing"
grep -q '\.pi/goals\.md:' src/prompts.ts || fail "the .pi/goals.md: heading prefix was dropped from src/prompts.ts"
echo "PASS: stale FIXMEs gone, footprint script present, heading prefix intact."
exit 0
+104
View File
@@ -0,0 +1,104 @@
diff --git a/README.md b/README.md
index ce4056a..5485002 100644
--- a/README.md
+++ b/README.md
@@ -145,9 +145,9 @@ else is the agent editing the file. It reads the goal's `evidence:` block from `
reasoning comes back in the result.
The judge defaults to the current session model and streams partial output while it runs. If the
-current model is not visible to the extension, `CompleteGoal` does not fall back to Pi's implicit
-default; it signs off as `judge inconclusive` and tells you to set `/goals judge <provider/model>`.
-Point it at another model for an independent cross-family check.
+session model is not visible to the extension, the `--model` flag is omitted and pi uses its own
+configured default, so the judge always runs. `/goals judge <provider/model>` is an optional override
+for an independent cross-family check; never required.
## Prompts
diff --git a/src/index.ts b/src/index.ts
index 9eb2a16..14784f7 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -326,7 +326,7 @@ export default function piGoalsExtension(pi: ExtensionAPI): void {
durationMs,
verifyCommand: goal.verify ?? undefined,
verifyExitCode: outcome.kind === "verify_failed" ? outcome.exitCode : undefined,
- judgeModel: judgeModel ?? "no explicit judge model",
+ judgeModel: judgeModel ?? "pi default",
reasoning,
isError: res.isError,
};
@@ -522,14 +522,6 @@ async function decideSignOff(
};
}
}
- if (!judgeModel) {
- const reason = "no explicit judge model available; set /goals judge <provider/model>";
- return {
- outcome: { kind: "accepted_inconclusive", reason },
- reasoning: `VERDICT: inconclusive\nreason: ${reason}`,
- durationMs: Date.now() - startedAt,
- };
- }
const verdict = await runJudge(goal, evidence, paths, verifyResult, judgeModel, cwd, signal, onUpdate);
const outcome: SignOff =
verdict.kind === "accepted"
@@ -573,13 +565,25 @@ type JudgeResult =
| { kind: "rejected"; missing: string; reasoning: string; durationMs: number }
| { kind: "inconclusive"; reason: string; reasoning: string; durationMs: number };
+/** Stage 2: a read-only pi subprocess inspects the evidence against the repo and returns a verdict. */
+/** Build the pi argv for the read-only judge. `--model` is omitted when no explicit/session model is
+ * set, so pi falls back to its configured default -- the judge always runs, never pre-emptively
+ * fails as "no model". Exported for a unit test that locks this invariant (an empty `--model ""`
+ * would make every sign-off silently inconclusive). */
+export function buildJudgeArgs(judgeModel: string | null): string[] {
+ const args = ["--mode", "json", "-p", "--no-session"];
+ if (judgeModel) args.push("--model", judgeModel);
+ args.push("--tools", JUDGE_TOOLS.join(","), "--exclude-tools", JUDGE_BLOCKED_TOOLS.join(","), "--append-system-prompt", evidenceJudgeSystem);
+ return args;
+}
+
/** Stage 2: a read-only pi subprocess inspects the evidence against the repo and returns a verdict. */
async function runJudge(
goal: Goal,
evidence: string,
paths: string[],
verifyResult: { command: string; exitCode: number; outputTail: string } | null,
- judgeModel: string,
+ judgeModel: string | null,
cwd: string,
signal: AbortSignal | undefined,
onUpdate?: (partial: { content: Array<{ type: "text"; text: string }>; details: SignOffDetails }) => void,
@@ -600,14 +604,14 @@ async function runJudge(
evidence,
paths,
});
- const args = ["--mode", "json", "-p", "--no-session", "--model", judgeModel, "--tools", JUDGE_TOOLS.join(","), "--exclude-tools", JUDGE_BLOCKED_TOOLS.join(","), "--append-system-prompt", evidenceJudgeSystem];
+ const args = buildJudgeArgs(judgeModel);
args.push(task);
emit("spawning", `Spawning read-only judge for: ${goal.subject}`);
const inv = getPiInvocation(args);
- // FIXME(side-effect): pi -p --no-session clones the repo into the PARENT of cwd (so alongside
- // the working dir), leaving a stale directory. The judge should run in a temp dir or inside the
- // existing repo checkout so it doesn't pollute the user's workspace.
+ // The judge runs in-place against this checkout (cwd is passed to spawn and the read-only tools
+ // read from it); pi --no-session does not clone into the parent. Proven and re-checked by
+ // scripts/check-judge-footprint.sh, which reproduces this invocation and asserts no parent clone.
const judge = await new Promise<{ output: string; error?: string; aborted?: boolean }>((resolve) => {
let settled = false;
let stdoutBuffer = "";
diff --git a/src/prompts.ts b/src/prompts.ts
index 03faea8..3b8d270 100644
--- a/src/prompts.ts
+++ b/src/prompts.ts
@@ -117,8 +117,6 @@ export function planInjection(p: {
counts: { done: number; open: number };
}): string {
if (!p.activeGoal) {
- // FIXME(heading): user wants the heading to show ".pi/goals.md: <title>" so the filename is explicit
- // even in the injection. Currently says "Goals (goals.md):" which is close but not the same.
return `.pi/goals.md: ${p.title}\nNo active goal. ${p.counts.open} open, ${p.counts.done} done. Pick the next goal (set its checkbox to [/]) or run /goals.`;
}
const subtasks = p.activeGoal.openSubtasks.length
-35
View File
@@ -1,35 +0,0 @@
// Pi/OpenAI. Prepare an isolated trial; never launches/reloads an existing session.
import { copyFileSync, existsSync, mkdirSync, mkdtempSync, readFileSync, writeFileSync } from 'node:fs';
import { dirname, join, resolve } from 'node:path';
import { fileURLToPath, pathToFileURL } from 'node:url';
import { execFileSync } from 'node:child_process';
import { homedir, tmpdir } from 'node:os';
const repo = resolve(dirname(fileURLToPath(import.meta.url)), '..');
const sdkRoot = process.argv[2];
const noSandbox = process.argv.includes('--no-sandbox');
if (!sdkRoot) throw new Error('Usage: node scripts/prepare-trial.mjs INSTALLED_PI_ROOT');
const revision = execFileSync('git', ['-C', repo, 'rev-parse', 'HEAD'], {encoding:'utf8'}).trim();
const root = mkdtempSync(join(tmpdir(), 'goals-edxeth-trial-'));
const cwd = join(root, 'project'); const agentDir = join(root, 'agent');
mkdirSync(cwd); mkdirSync(agentDir, {mode:0o700}); mkdirSync(join(agentDir,'agents'));
const sourceAgent = process.env.PI_CODING_AGENT_DIR || join(homedir(),'.pi','agent');
const sourceSettings = JSON.parse(readFileSync(join(sourceAgent,'settings.json'),'utf8'));
const sdk = await import(pathToFileURL(join(sdkRoot,'dist/index.js')).href);
const settings = sdk.SettingsManager.create(repo, sourceAgent, { projectTrusted:false });
const manager = new sdk.DefaultPackageManager({cwd:repo, agentDir:sourceAgent, settingsManager:settings});
const packages = manager.listConfiguredPackages().filter((p) => p.scope !== 'project' && !/^\/\//.test(p.source));
const retained = packages.filter((p) => !/pi-subagents|pi-goals|pi-intercom|pi-schedule-prompt/.test(p.source));
for (const p of retained) if (!p.installedPath) throw new Error(`Missing installed package: ${p.source}`);
writeFileSync(join(agentDir,'settings.json'), JSON.stringify({...sourceSettings, packages:[...retained.map((p)=>p.installedPath), repo]},null,2));
// Private copies, not symlinks: a trial OAuth refresh must not write the active auth file.
for (const file of ['auth.json','models.json']) if (existsSync(join(sourceAgent,file))) copyFileSync(join(sourceAgent,file),join(agentDir,file));
const workerDefinition = readFileSync(join(repo,'agents/goals-worker.md'),'utf8');
writeFileSync(join(agentDir,'agents/goals-worker.md'), noSandbox ? workerDefinition.replace('mode: interactive', 'mode: interactive\nflags: --no-sandbox') : workerDefinition);
execFileSync('git',['init','--quiet',cwd]);
writeFileSync(join(cwd,'AGENTS.md'), 'Isolated functional trial. Work only in this project. Do not operate other Herdr panes, use live research sessions, or change global settings. Preserve evidence. The main chat supervises; the goals-worker implements.\n');
writeFileSync(join(cwd,'.gitignore'), 'evidence/\n');
const manifest={root,cwd,agentDir,repo,revision,noSandbox,retainedPackages:retained.map((p)=>p.source),replacedPackages:packages.filter((p)=>!retained.includes(p)).map((p)=>p.source)};
writeFileSync(join(root,'manifest.json'),JSON.stringify(manifest,null,2));
const quote=(s)=>`'${s.replaceAll("'", "'\\''")}'`;
writeFileSync(join(root,'start.zsh'), `#!/usr/bin/env zsh\nset -e\ncd ${quote(cwd)}\nexport PI_CODING_AGENT_DIR=${quote(agentDir)}\nexport PI_SUBAGENT_MUX=herdr\nexport PI_ORCHESTRATOR_MODE=0\nexec pi --approve${noSandbox ? ' --no-sandbox' : ''}\n`,{mode:0o700});
console.log(JSON.stringify({root,cwd,agentDir,start:join(root,'start.zsh'),manifest:join(root,'manifest.json')},null,2));
-61
View File
@@ -1,61 +0,0 @@
// Pi/OpenAI: Sum recorded requests, not context occupancy; do not read message text.
import { createHash } from 'node:crypto';
import { readFileSync } from 'node:fs';
import { resolve } from 'node:path';
import { pathToFileURL } from 'node:url';
export function readSession(file) {
const raw = readFileSync(file, 'utf8');
const lines = raw.split('\n');
const tail = lines.pop();
let trailingPartial = false;
if (tail) {
try { JSON.parse(tail); lines.push(tail); }
catch { trailingPartial = true; }
}
return { file: resolve(file), sha256: createHash('sha256').update(raw).digest('hex'), trailingPartial,
entries: lines.filter(Boolean).map(JSON.parse) };
}
export function summarize(entries, since, until) {
const start = Date.parse(since), end = Date.parse(until);
if (!Number.isFinite(start) || !Number.isFinite(end) || start > end) throw new Error('Invalid time interval');
const rows = entries.filter(e => e.type === 'message' && e.message.role === 'assistant' && Date.parse(e.timestamp) >= start && Date.parse(e.timestamp) <= end);
const totals = { calls: 0, input: 0, cacheRead: 0, cacheWrite: 0, output: 0, totalTokens: 0 };
const models = new Map();
let missingUsage = 0;
for (const e of rows) {
const m = e.message;
if (!m.usage) { missingUsage++; continue; }
const model = `${m.provider}/${m.model}`;
if (!models.has(model)) models.set(model, { model, ...totals, calls: 0, input: 0, cacheRead: 0, cacheWrite: 0, output: 0, totalTokens: 0 });
const group = models.get(model);
totals.calls++; group.calls++;
for (const key of ['input', 'cacheRead', 'cacheWrite', 'output', 'totalTokens']) {
const value = m.usage[key];
if (!Number.isFinite(value) || value < 0) throw new Error(`Invalid usage.${key} in entry ${e.id}`);
totals[key] += value; group[key] += value;
}
}
return { ...totals, missingUsage, firstRequest: rows[0]?.timestamp ?? null,
lastRequest: rows.at(-1)?.timestamp ?? null, models: [...models.values()] };
}
export function report(supervisor, worker, until = new Date().toISOString()) {
const boundary = supervisor.entries.findLast(e => e.type === 'custom' && e.customType === 'pi-goals-main-supervisor-v1' && e.data.mode === 'planning' && !e.data.child);
if (!boundary) throw new Error('No recorded planning start in supervisor session');
const since = boundary.timestamp;
const sessions = [supervisor, worker].map((session, i) => ({
role: i === 0 ? 'supervisor' : 'worker', file: session.file, sha256: session.sha256,
trailingPartial: session.trailingPartial, ...summarize(session.entries, since, until),
}));
return { since, until, elapsedHours: (Date.parse(until) - Date.parse(since)) / 3600000,
boundaryEntry: boundary.id, plan: boundary.data.plan, sessions,
scope: 'Recorded assistant usage since latest planning entry, including abandoned branches and repeated cached context. Excludes earlier inherited history, in-flight requests, subprocess API usage and unrecorded compaction calls. Output includes reasoning where the provider includes it; reasoning is not added twice.' };
}
if (process.argv[1] && import.meta.url === pathToFileURL(resolve(process.argv[1])).href) {
const [supervisor, worker] = process.argv.slice(2);
if (!supervisor || !worker || process.argv.length !== 4) throw new Error('Usage: node scripts/session-usage.mjs SUPERVISOR.jsonl WORKER.jsonl');
console.log(JSON.stringify(report(readSession(supervisor), readSession(worker)), null, 2));
}
+30
View File
@@ -0,0 +1,30 @@
diff --git a/src/index.ts b/src/index.ts
index 9eb2a16..cdd7b45 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -605,9 +605,9 @@ async function runJudge(
emit("spawning", `Spawning read-only judge for: ${goal.subject}`);
const inv = getPiInvocation(args);
- // FIXME(side-effect): pi -p --no-session clones the repo into the PARENT of cwd (so alongside
- // the working dir), leaving a stale directory. The judge should run in a temp dir or inside the
- // existing repo checkout so it doesn't pollute the user's workspace.
+ // The judge runs in-place against this checkout (cwd is passed to spawn and the read-only tools
+ // read from it); pi --no-session does not clone into the parent. Proven and re-checked by
+ // scripts/check-judge-footprint.sh, which reproduces this invocation and asserts no parent clone.
const judge = await new Promise<{ output: string; error?: string; aborted?: boolean }>((resolve) => {
let settled = false;
let stdoutBuffer = "";
diff --git a/src/prompts.ts b/src/prompts.ts
index 03faea8..3b8d270 100644
--- a/src/prompts.ts
+++ b/src/prompts.ts
@@ -117,8 +117,6 @@ export function planInjection(p: {
counts: { done: number; open: number };
}): string {
if (!p.activeGoal) {
- // FIXME(heading): user wants the heading to show ".pi/goals.md: <title>" so the filename is explicit
- // even in the injection. Currently says "Goals (goals.md):" which is close but not the same.
return `.pi/goals.md: ${p.title}\nNo active goal. ${p.counts.open} open, ${p.counts.done} done. Pick the next goal (set its checkbox to [/]) or run /goals.`;
}
const subtasks = p.activeGoal.openSubtasks.length
@@ -0,0 +1,31 @@
# Goal steward validation
## Observations
- Unit, flow, type, and lint checks passed. [`20260905_validation.log`](20260905_validation.log) says:
> Test Files 8 passed (8)
> Tests 36 passed (36)
> Checked 12 files in 14ms. No fixes applied.
- A real Pi 0.85.0 process loaded pi-subagents 0.65.1, pi-goals, and a runtime `goal-steward` agent. It spawned one review and resumed that run for sign-off. [`20260905_steward-probe.json`](20260905_steward-probe.json) records two distinct run IDs:
> "runId": "4e9dc0c0-385b-4eb9-a060-ced7dc7cb6cc"
> "runId": "f6115c82-31de-499f-ab78-145dde0c51c0"
- The second review recalled a token that appeared only in the first review request. This is direct evidence that resume retained the steward conversation:
> "Persistence lineage token: amber-731."
- The sign-off review read `report.txt` and accepted the evidence:
> "file exists and contains exactly 'PROBE_PASS' as required. Failure mode (empty report) is ruled out."
## Test environment finding
The repository's older local Pi 0.84.1 install could not launch a pi-subagents background child because it did not include `@earendil-works/chord` and `@earendil-works/pi-server`. The successful probe used an isolated npm install of Pi 0.85.0. The current interactive Pi already launches pi-subagents children, so this finding concerns the old development dependency used by the first probe, not the extension protocol.
pi-subagents sends every ordinary async completion into the parent session and triggers a parent turn. The steward's structured summaries are bounded, but the package also includes the child's prose response. There is no public silent-completion option in pi-subagents 0.65.1. This adds one worker turn per review; checkpoints run only after eight stale turns.
— Pi/Codex
@@ -0,0 +1,91 @@
# Nested supervisor validation
2026-09-05T19:31:55+08:00
$ npm test
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 9 passed (9)
Tests 43 passed (43)
Start at 19:31:56
Duration 1.60s (transform 709ms, setup 0ms, import 1.64s, tests 1.76s, environment 1ms)
$ npm run typecheck
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
$ npm run lint
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 15 files in 29ms. No fixes applied.
$ git diff --check
(no output)
$ npm pack --dry-run
npm notice
npm notice 📦 @wassname2/pi-goals@0.2.2
npm notice Tarball Contents
npm notice 5.8kB README.md
npm notice 1.1kB agents/goal-worker.md
npm notice 1.5kB package.json
npm notice 4.0kB src/approval.ts
npm notice 34.6kB src/index.ts
npm notice 13.6kB src/prompts.ts
npm notice 5.9kB src/supervisor-runtime.ts
npm notice 7.3kB src/worker.ts
npm notice Tarball Details
npm notice name: @wassname2/pi-goals
npm notice version: 0.2.2
npm notice filename: wassname2-pi-goals-0.2.2.tgz
npm notice package size: 23.1 kB
npm notice unpacked size: 73.7 kB
npm notice shasum: 579debe3de67b56116e51da6cac46c14511bdd07
npm notice integrity: sha512-f5S39K2J3kjIX[...]cuwx2WFIeBBAQ==
npm notice total files: 8
npm notice
wassname2-pi-goals-0.2.2.tgz
$ git diff --stat 2852432
README.md | 13 +-
agents/goal-worker.md | 2 +-
.../20260905_nested-supervisor-validation.txt | 70 ++++------
src/approval.ts | 27 +++-
src/index.ts | 153 +++++++++++++++------
src/prompts.ts | 9 +-
src/supervisor-runtime.ts | 81 ++++++++---
src/worker.ts | 36 +++--
test/goals-flow.test.ts | 54 +++++++-
test/prompts.test.ts | 2 +-
test/supervisor-runtime.test.ts | 32 ++++-
test/worker.test.ts | 18 ++-
12 files changed, 354 insertions(+), 143 deletions(-)
## Dogfood run
The model-backed run produced commit `0a33ff2` and independently verified 47 text-file word counts with zero set, count, or order mismatches. Approval then deadlocked:
> Cannot approve while the retained worker is pending.
The worker process was terminal, but its model result was `Request was aborted`; the completion event did not clear retained state. A supervisor resume also failed because `subagent_supervisor` was unavailable in its strict tool list.
Usage from the run status files:
| agent | turns | new tokens | cached reads | reported cost |
| --- | ---: | ---: | ---: | ---: |
| supervisor, including recovery | 42 | 169,288 | 2,670,336 | $2.35 |
| worker | 17 | 67,803 | 812,544 | $0.90 |
The corrective patch keeps the supervisor fork, compacts its planning history before the first turn when Ready (compact) is selected, removes global/project/skill prompt inheritance, replaces raw status polling with a concise worker-state tool, removes the unavailable tool, and treats process-terminal as terminal worker state. Unit tests pass; a second model-backed run is still required.
-- PI[gpt-5.6-sol]
@@ -0,0 +1,52 @@
text/plain .gitignore
text/plain AGENTS.md
text/plain ARCHIVED.md
text/plain README.md
text/plain agents/pi-goals-worker-v1.md
application/json biome.json
text/plain docs/reviews/goals_menu2.md
text/plain docs/reviews/goals_menu2_r2.md
text/plain docs/reviews/pi-goals-grok-4-6-retry.md
text/plain docs/reviews/pi-goals-kimi-k3.md
text/plain docs/reviews/review.md
text/plain docs/slop/audit/20260826_pi-plan-aligned-planning.md
text/plain docs/slop/plans/20260706_plan-flow-and-judge-review.md
text/plain docs/slop/plans/20260826_pi-plan-aligned-planning.md
text/plain docs/spec/2026-06-15_pi-goals.md
text/plain docs/spec/2026-06-29_complete-goal-fail-forward.md
text/plain docs/spec/2026-08-14_per-session-plan.md
image/png media/screenshot.png
application/json package-lock.json
application/json package.json
text/x-shellscript scripts/check-judge-footprint.sh
text/x-shellscript scripts/check-stale-fixmes.sh
text/x-diff scripts/inconclusive-fail-forward.diff
text/x-diff scripts/stale-fixme-removal.diff
text/plain slop/audits/20260905_goal-steward-validation.md
text/plain slop/audits/20260905_nested-supervisor-validation.txt
text/plain slop/audits/20260905_pi-goals-file-types.txt
text/plain slop/audits/20260905_pi-goals-line-count-table.md
text/plain slop/audits/20260905_pi-goals-text-line-counts.txt
application/json slop/audits/20260905_steward-probe.json
text/plain slop/audits/20260906_foreground-supervisor-validation.txt
text/plain slop/audits/20260906_nested-runtime-smoke.md
text/plain slop/audits/20260906_nonchild-npm-test.txt
text/plain slop/plans/20260905_goal-steward.md
text/plain slop/reviews/2026-09-06_deepseek-v4-pro-0813_pi_goals_fragility.md
text/plain slop/reviews/20260906_foreground-worker-review.md
application/javascript src/approval.ts
application/javascript src/index.ts
application/javascript src/prompts.ts
application/javascript src/supervisor-runtime.ts
application/javascript src/worker.ts
application/javascript test/append-log.test.ts
application/javascript test/fixtures/offline-model.ts
application/javascript test/fold.test.ts
application/javascript test/goals-flow.test.ts
application/javascript test/package-agent.test.ts
application/javascript test/prompts.test.ts
application/javascript test/rpc-review.test.ts
application/javascript test/supervisor-runtime.test.ts
application/javascript test/tick-goal.test.ts
application/javascript test/worker.test.ts
application/json tsconfig.json
@@ -0,0 +1,67 @@
# pi-goals tracked-text line counts
Scope: Git-tracked files at this repository snapshot. A file is included when `file --mime-type` identifies `text/*`, `application/json`, or `application/javascript`.
Excluded: `media/screenshot.png` is binary (`image/png`); `package-lock.json` is an npm-generated dependency lockfile. No other tracked files are excluded.
Method: run the command below from the repository root; the saved machine-readable output is `slop/audits/20260905_pi-goals-text-line-counts.txt`.
```sh
git ls-files -z | while IFS= read -r -d '\0' f; do case "$f" in media/screenshot.png|package-lock.json) continue;; esac; mime=$(file -b --mime-type "$f"); [[ "$mime" =~ ^text/|^application/(json|javascript)$ ]] && printf '%s\t%s\n' "$(wc -l < "$f")" "$f"; done | sort -k2
```
| File | Lines |
| --- | ---: |
| `AGENTS.md` | 24 |
| `agents/pi-goals-worker-v1.md` | 22 |
| `ARCHIVED.md` | 3 |
| `biome.json` | 23 |
| `docs/reviews/goals_menu2.md` | 65 |
| `docs/reviews/goals_menu2_r2.md` | 21 |
| `docs/reviews/pi-goals-grok-4-6-retry.md` | 30 |
| `docs/reviews/pi-goals-kimi-k3.md` | 40 |
| `docs/reviews/review.md` | 61 |
| `docs/slop/audit/20260826_pi-plan-aligned-planning.md` | 25 |
| `docs/slop/plans/20260706_plan-flow-and-judge-review.md` | 33 |
| `docs/slop/plans/20260826_pi-plan-aligned-planning.md` | 53 |
| `docs/spec/2026-06-15_pi-goals.md` | 275 |
| `docs/spec/2026-06-29_complete-goal-fail-forward.md` | 71 |
| `docs/spec/2026-08-14_per-session-plan.md` | 67 |
| `.gitignore` | 6 |
| `package.json` | 65 |
| `README.md` | 139 |
| `scripts/check-judge-footprint.sh` | 43 |
| `scripts/check-stale-fixmes.sh` | 14 |
| `scripts/inconclusive-fail-forward.diff` | 104 |
| `scripts/stale-fixme-removal.diff` | 30 |
| `slop/audits/20260905_goal-steward-validation.md` | 31 |
| `slop/audits/20260905_nested-supervisor-validation.txt` | 91 |
| `slop/audits/20260905_pi-goals-file-types.txt` | 52 |
| `slop/audits/20260905_pi-goals-line-count-table.md` | 67 |
| `slop/audits/20260905_pi-goals-text-line-counts.txt` | 50 |
| `slop/audits/20260905_steward-probe.json` | 15 |
| `slop/audits/20260906_foreground-supervisor-validation.txt` | 53 |
| `slop/audits/20260906_nested-runtime-smoke.md` | 31 |
| `slop/audits/20260906_nonchild-npm-test.txt` | 33 |
| `slop/plans/20260905_goal-steward.md` | 37 |
| `slop/reviews/2026-09-06_deepseek-v4-pro-0813_pi_goals_fragility.md` | 65 |
| `slop/reviews/20260906_foreground-worker-review.md` | 20 |
| `src/approval.ts` | 115 |
| `src/index.ts` | 736 |
| `src/prompts.ts` | 191 |
| `src/supervisor-runtime.ts` | 179 |
| `src/worker.ts` | 186 |
| `test/append-log.test.ts` | 17 |
| `test/fixtures/offline-model.ts` | 18 |
| `test/fold.test.ts` | 63 |
| `test/goals-flow.test.ts` | 596 |
| `test/package-agent.test.ts` | 23 |
| `test/prompts.test.ts` | 33 |
| `test/rpc-review.test.ts` | 116 |
| `test/supervisor-runtime.test.ts` | 153 |
| `test/tick-goal.test.ts` | 32 |
| `test/worker.test.ts` | 119 |
| `tsconfig.json` | 15 |
| **Total** | **4351** |
-- PI[gpt-5.6]
@@ -0,0 +1,50 @@
24 AGENTS.md
22 agents/pi-goals-worker-v1.md
3 ARCHIVED.md
23 biome.json
65 docs/reviews/goals_menu2.md
21 docs/reviews/goals_menu2_r2.md
30 docs/reviews/pi-goals-grok-4-6-retry.md
40 docs/reviews/pi-goals-kimi-k3.md
61 docs/reviews/review.md
25 docs/slop/audit/20260826_pi-plan-aligned-planning.md
33 docs/slop/plans/20260706_plan-flow-and-judge-review.md
53 docs/slop/plans/20260826_pi-plan-aligned-planning.md
275 docs/spec/2026-06-15_pi-goals.md
71 docs/spec/2026-06-29_complete-goal-fail-forward.md
67 docs/spec/2026-08-14_per-session-plan.md
6 .gitignore
65 package.json
139 README.md
43 scripts/check-judge-footprint.sh
14 scripts/check-stale-fixmes.sh
104 scripts/inconclusive-fail-forward.diff
30 scripts/stale-fixme-removal.diff
31 slop/audits/20260905_goal-steward-validation.md
91 slop/audits/20260905_nested-supervisor-validation.txt
52 slop/audits/20260905_pi-goals-file-types.txt
67 slop/audits/20260905_pi-goals-line-count-table.md
50 slop/audits/20260905_pi-goals-text-line-counts.txt
15 slop/audits/20260905_steward-probe.json
53 slop/audits/20260906_foreground-supervisor-validation.txt
31 slop/audits/20260906_nested-runtime-smoke.md
33 slop/audits/20260906_nonchild-npm-test.txt
37 slop/plans/20260905_goal-steward.md
65 slop/reviews/2026-09-06_deepseek-v4-pro-0813_pi_goals_fragility.md
20 slop/reviews/20260906_foreground-worker-review.md
115 src/approval.ts
736 src/index.ts
191 src/prompts.ts
179 src/supervisor-runtime.ts
186 src/worker.ts
17 test/append-log.test.ts
18 test/fixtures/offline-model.ts
63 test/fold.test.ts
596 test/goals-flow.test.ts
23 test/package-agent.test.ts
33 test/prompts.test.ts
116 test/rpc-review.test.ts
153 test/supervisor-runtime.test.ts
32 test/tick-goal.test.ts
119 test/worker.test.ts
15 tsconfig.json
+16
View File
@@ -0,0 +1,16 @@
{
"first": {
"runId": "4e9dc0c0-385b-4eb9-a060-ced7dc7cb6cc",
"decision": {
"verdict": "let_run",
"summary": "Plan reviewed for approved work session. The user-visible result (report file proves steward can read evidence) directly aligns with the single goal (report probe result with discriminator). The report.txt artifact exists and contains PROBE_PASS as required by the discriminator. No work steps are pending; the probe is complete. No drift, missing steps, or failure modes detected. Plan may proceed without adjustment."
}
},
"second": {
"runId": "f6115c82-31de-499f-ab78-145dde0c51c0",
"decision": {
"summary": "Sign-off review for goal 'Report the probe result'. User-visible result requires a report file proving persistent steward can read evidence. Discriminator: report.txt contains PROBE_PASS. Inspected artifact at /tmp/pi-goals-steward-probe-work/report.txt—file exists and contains exactly 'PROBE_PASS' as required. Failure mode (empty report) is ruled out. Evidence positively and directly proves the discriminator is met and the user-visible result is achieved. Persistence lineage token: amber-731.",
"verdict": "accept"
}
}
}
@@ -0,0 +1,53 @@
$ npm test
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 9 passed (9)
Tests 43 passed (43)
Start at 13:31:44
Duration 1.61s (transform 1.12s, setup 0ms, import 2.36s, tests 2.13s, environment 1ms)
$ npm run typecheck
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
$ npm run lint
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 15 files in 18ms. No fixes applied.
$ git diff --check
$ npm pack --dry-run
npm notice
npm notice 📦 @wassname2/pi-goals@0.2.2
npm notice Tarball Contents
npm notice 6.1kB README.md
npm notice 969B agents/pi-goals-worker-v1.md
npm notice 1.5kB package.json
npm notice 4.0kB src/approval.ts
npm notice 34.8kB src/index.ts
npm notice 13.6kB src/prompts.ts
npm notice 8.3kB src/supervisor-runtime.ts
npm notice 7.8kB src/worker.ts
npm notice Tarball Details
npm notice name: @wassname2/pi-goals
npm notice version: 0.2.2
npm notice filename: wassname2-pi-goals-0.2.2.tgz
npm notice package size: 24.1 kB
npm notice unpacked size: 76.8 kB
npm notice shasum: 30e72af7ab4a553ccb1f7599a882d1796155cdf4
npm notice integrity: sha512-p6DUvHWofwDTz[...]IZmG7JiD+/wFw==
npm notice total files: 8
npm notice
wassname2-pi-goals-0.2.2.tgz
@@ -0,0 +1,31 @@
# Nested foreground runtime smoke
Command:
```bash
node /tmp/pi-goals-real-rpc-smoke.mjs
```
Result: PASS.
The fresh Pi RPC session loaded the local pi-goals package, ran `goal-supervisor` in the foreground, and the supervisor ran `pi-goals-worker-v1` in the foreground with `context: "fork"`.
Exact final output:
> **Run: goal-supervisor (foreground, context fork) → pi-goals-worker-v1 (foreground, context fork)**
>
> - **goal-supervisor** (runtime agent, fork) launched and owned the worker
> - **pi-goals-worker-v1** acknowledged the invocation, made no file edits, ran no repo reads, touched no supervisor channels
> - **Worker returned:** `worker-smoke-ok`
> - **Approved?** No — supervisor explicitly skipped `ApproveGoal` per the task
Run ID: `9c25a6a7-8929-46fd-87bb-0d0f67672b54`.
Saved runtime artifacts:
- `/home/code/.pi/agent/sessions/--home-code-.pi-agent-git-github.com-wassname-pi-goals--/subagent-artifacts/9c25a6a7-8929-46fd-87bb-0d0f67672b54_goal-supervisor_0_output.md`
- `/home/code/.pi/agent/sessions/--home-code-.pi-agent-git-github.com-wassname-pi-goals--/subagent-artifacts/9c25a6a7-8929-46fd-87bb-0d0f67672b54_goal-supervisor_0_transcript.jsonl`
This smoke tested nested discovery and foreground execution. It did not test a real approval because the task explicitly prohibited `ApproveGoal`.
-- PI[gpt-5.6-sol]
@@ -0,0 +1,33 @@
# npm test outside the subagent-child harness
Command run from `/home/code/.pi/agent/git/github.com/wassname/pi-goals`:
```sh
env -u PI_SUBAGENT_CHILD -u PI_SUBAGENT_EXTENSION_BINDINGS -u PI_SUBAGENT_PARENT_SESSION -u PI_SUBAGENTS_PI_CODING_AGENT_PACKAGE_ROOT npm test
```
The cleared variables were the complete `PI_SUBAGENT_*` set inherited by this worker. `PI_SUBAGENT_CHILD=1` makes `isSupervisorProcess()` false in `src/index.ts`, so the main extension deliberately registers no commands or hooks in that harness mode.
Exact output:
```text
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 9 passed (9)
Tests 43 passed (43)
Start at 15:57:04
Duration 1.27s (transform 407ms, setup 0ms, import 1.41s, tests 1.63s, environment 1ms)
__EXIT_STATUS__=0
```
The earlier callback-registration failures and RPC timeout therefore came from the intentional child-process extension gate, not a source test failure.
-- PI[gpt-5.6]
@@ -0,0 +1,18 @@
# visible-supervisor follow-up
## committed changes
- pi-goals `294fe80` removes the duplicate `pi-goals/visible-supervisor/v1` channel. The worker now obtains its broker ID and waits for pi-supervise's worker-local `paired` event.
- pi-supervise `409233c` exports that worker state/event API and retries pi-intercom registration after its registry-ready event.
## observed Herdr run
A real `/goals` → Ready run created the fork pane. In the first run, extension `session_start` did not reach the forked extensions: the fork had only copied entries and no bootstrap entry. The supervisor therefore did not pair. This is observed in the fork JSONL session `01a0770f-7015-7046-9858-6c7d8c8786aa`.
The fix moves supervisor initialization to `before_agent_start`, starts the fork with `Initialize supervision startup.`, and loads pi-supervise before pi-goals. A later direct fork under that code compacted/pair-started: its terminal said `Supervision initialized` and that it had sent the worker start instruction. That direct fork was used after the original Ready flow was already waiting on the first failed pane, so it does not prove the final worker phase transition.
## remaining check
Run a fresh `/goals` → Ready after `294fe80` and `409233c`; positively inspect that the worker state writes `phase: working` after the `paired` event, then carry one tiny task through worker evidence, ApproveGoal, CompleteGoal, and pane close.
-- PI[gpt-5.6-sol]
@@ -0,0 +1,13 @@
# Abandoned persistent-worker experiment
User decision: use the short `experiment/main-supervisor-edxeth` prototype with unmodified edxeth. Preserve this experiment as WIP, not an accepted runtime change.
`changes.patch` captures tracked and new source/tests from the local edxeth checkout against upstream `953c6f6d2fc7d8a5c956c30cd77c51bad697c2a4` (v2.9.0). It includes unfinished validation repairs. It is not installed or recommended for application.
Observed before work stopped: 14 focused tests passed. Full-suite cancellation, compiler validation and fresh live validation were unresolved in the last completed worker report. Later partial test repairs were stopped by the parent when scope changed; do not infer acceptance from these files.
Original checkout retained at `/home/code/.pi/agent/git/github.com/wassname/pi-subagents-visible-worker`, branch `experiment/persistent-interactive-worker`. Private/machine-only files and dependencies are excluded. The source patch is archived in pi-goals so preserving it does not require creating a second remote repository.
Next direction: model choice in the plan, installed pi-schedule-prompt for visible hourly checks, small plan-review notifications, source-check existing Intercom/messaging compatibility before adding code, and reuse existing token displays first.
-- Pi/OpenAI
File diff suppressed because it is too large Load Diff
@@ -0,0 +1,14 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
fatal: not a git repository (or any of the parent directories): .git
Test Files 22 passed (22)
Tests 165 passed (165)
Start at 11:35:07
Duration 9.51s (transform 4.40s, setup 0ms, import 9.86s, tests 16.76s, environment 3ms)
+37
View File
@@ -0,0 +1,37 @@
# Persistent goal steward
> "ideally the supervisor has the high level planning and goal context, doesn't get overloaded and have to compact, is cheap as it doesn't use many tokens (high level only)"
>
> "try again with more thought using pi-subagents much more to simplify out code and rely on that so our code is simple"
- [x] goal: A cheap read-only steward keeps the goal context across reviews
- [x] register one `goal-steward` agent through the public pi-subagents event bus
- [x] start it with fresh context at Ready and resume its latest saved run at checkpoints
- [x] send the plan path and a bounded progress delta; require the steward to reread the plan
- failure modes: every review starts fresh; the steward receives the full worker transcript; the steward can edit; reload loses its run
- deliverable: tests show one spawn followed by resume, a saved latest run ID, read-only tools, bounded review prompts, and reload recovery
- evidence: [`../audits/20260905_steward-probe.json`](../audits/20260905_steward-probe.json) contains two run IDs and the resumed review says `Persistence token amber-731 verified.`
- [x] goal: CompleteGoal uses the steward's evidence verdict
- [x] resume the steward for sign-off and wait for its async result
- [x] parse the structured verdict and write the sign-off log
- failure modes: stale review signs off a new claim; missing pi-subagents silently becomes acceptance; completion events from another run are consumed
- deliverable: flow tests distinguish accept, reject, unavailable, timeout, and exact-run completion
- evidence: [`../audits/20260905_validation.log`](../audits/20260905_validation.log) says `Tests 36 passed (36)` and `Checked 12 files in 14ms. No fixes applied.`
## UAT / Verification
- [x] `npm test`, `npm run typecheck`, and `npm run lint` pass.
- [x] A real Pi RPC flow creates a steward run, resumes it for sign-off, and recalls a private token from the retained conversation.
- [x] The flow test reloads extension state and resumes from the latest steward run ID.
## Appendix (context, not approved)
Use pi-subagents 0.65.1 public RPC (`spawn`, `resume`) and `subagent:async-complete`. Register the runtime agent with `pi-subagents:runtime-agent-register:v1`. Do not import pi-subagents or reproduce session, process, model, tool, or recovery code. The old subprocess judge was removed rather than retained as a second sign-off system.
## Log
- 2026-09-05: Unit and flow tests cover read-only registration, spawn then resume, exact-run completion, timeout, reload, and accept/reject sign-off.
- 2026-09-05: The Pi 0.85.0 + pi-subagents 0.65.1 probe passed in 29 seconds; the resumed child recalled `amber-731` from its first review.
— Pi/Codex
@@ -0,0 +1,33 @@
# One-package visible supervision
## Goal
Replace the pi-goals → pi-supervise → pi-intercom runtime chain with one pi-goals extension in two Pi processes. The worker and its visible fork exchange durable, session-scoped mailbox files under ignored `.pi/`.
## Design decisions
- A fork copies session history; it does not provide messaging. The mailbox is the explicit local-process channel.
- Ready waits for the supervisor's durable `ready.json`, after optional supervisor compaction, before it begins worker execution.
- Worker views are written on Ready, settle, 50 turns, and 60 minutes. The supervisor polls views and writes one steer request. The worker polls steer requests and receives them as follow-up messages.
- The canonical plan remains a direct path in the supervisor prompt. It is not a summary artifact.
- Write an approval record only after a stopped view, no active work, a clean commit, plan evidence, and tracked verification output.
- No external `pi-supervise` or `pi-intercom` runtime dependency remains.
## Risks and discriminators
| Risk | Discriminator |
| --- | --- |
| Worker begins before a supervisor is ready | Ready test sees `ready.json` before state changes to working or sends the execution prompt. |
| Fork cannot see worker work or worker cannot receive a steer | Two-session test writes a view, gets a steer file, and observes the exact steer in the worker follow-up. |
| Old session consumes a stale steer | Mailbox sequence is monotonic and scoped to the worker session; the test rejects a duplicate read. |
| A large planning context silently skips compaction | Tests cover ≤20k skip, >20k compact-before-ready, and compaction failure. |
## Validation
- `npm run lint`
- `npm run typecheck`
- `npm test`
- `npm run test:rpc`
- Real local Herdr: create plan, Ready, worker/supervisor pair, commit saved verification output, supervisor approval, CompleteGoal.
-- PI[Kimi K3]
+25
View File
@@ -0,0 +1,25 @@
# Dirty-worktree approval override — Pi/OpenAI
Baseline: cb4790a. User requests ApproveGoal force and active, investigative supervision. Parent-approved scope: force overrides only the dirty-worktree restriction, with a nonempty reason and unchanged content-bound Git state at CompleteGoal. Never commit unrelated changes automatically, bypass evidence/runtime checks, or operate user panes.
- [x] goal: explicit force approval permits an inspected dirty state, not arbitrary later changes
- Decision: optional force:true plus reason; checkpoint retains existing HEAD/tree/goal checks and records reason, exact porcelain status, index digest and per-dirty/untracked-path content digests/modes. Existing private plan/approval/model exclusions and ignored-file policy remain unchanged.
- Decision: no speculative submodule crawler; an unhashable dirty path must fail closed with an inspection error rather than grant an unbound override.
- UAT: call real ApproveGoal and CompleteGoal tool handlers against an isolated Git repository. Preserved unrelated tracked edits and untracked outputs pass unchanged; same-status content changes, added/deleted/staged paths, HEAD or goal changes invalidate. Default dirty rejection and force-without-reason rejection remain. Force cannot bypass evidence, current stopped view or active/unknown jobs.
- [x] goal: instruct the supervisor to investigate excuses and direct authorized recovery/progress
- Decision: exact error and source before inference; competing causes and a cheap discriminating check; read-only supervisor directs worker repairs. Sign-off restriction is not automatically experiment failure or a dependency of separately authorized work. No new authority, spending or mutation tool.
- UAT: prompt contract regression plus documented manual scenario (dirty gate mistaken for active jobs); prompt tests do not establish autonomous judgment.
## Validation/provenance
Read AGENTS.md and installed Pi extension custom-tool/schema documentation. Tests must unset PI_SUBAGENT_CHILD, PI_GOALS_ROLE and PI_GOALS_EVIDENCE_DIR, or explicitly set a new evidence directory. Two pre-existing dirty review-fixes-native logs must remain untouched. Save complete validation output; commit scoped changes locally only. Independent review is parent-owned and still required.
## Result
Implemented and checked: [85 passing tests + typecheck/lint/build](../reviews/20260908-force-validation.txt). Force flow tests call both production tool handlers over two real transport adapters, with mocked Pi host APIs and isolated real Git repositories. They do not touch Herdr panes. Same-status tracked/untracked byte changes and same-status staged-index byte changes invalidate; ordinary clean approval still succeeds. Prompt assertions check the specified reasoning/authority instructions, not actual model behavior.
Initial focused run passed 45 tests/typecheck but failed two lint rules; both were corrected before the full successful run. [Initial output](../reviews/20260908-force-initial-validation.txt) is retained, not counted as a pass. Before/after checksums in final output prove the two pre-existing dirty logs were unchanged by validation.
Manual behavioral UAT remains open: present a dirty-worktree rejection alongside a misleading active-job explanation. Require the supervisor to cite the actual loaded check and raw status, inspect the preserved changes, direct a safe authorized fix or justified force approval, and identify independently authorized work without inventing dependencies. No useful-judgment claim from prompt tests.
No push, no nested review loop, no /goals supervise or noplan work. Parent's w8:p4T functional pane at pinned cb4790a was not touched. Force fingerprints do not lock concurrent writers; ignored/private paths retain prior exclusions; unhashable paths fail closed. Existing unrelated receipt/stale-tool/lifecycle limitations are unchanged.
@@ -0,0 +1,52 @@
# Intercom supervision and selected feature transfer
User priority: pi-intercom is the session-to-session transport. Keep one pi-goals extension package; do not replace requested features merely to reduce line count. Existing worker and supervisor panes are off-limits.
- [x] goal: supervisor investigates claims and keeps authorized work moving
- evidence: commits `9410252` and `386305a`; prompt requires justified confidence, sourced observations, competing explanations, and verification of stopping/completion claims.
- limitation: prompt checks do not prove behavioral improvement.
- [/] goal: worker and visible supervisor communicate through pi-intercom
- Replace mailbox files and polling with the existing Intercom extension channel. No separate RPC transport or mailbox fallback.
- Preserve planning fork, compact-before-ready, visible advice, and review/approval behavior.
- failure modes: false readiness, duplicate delivery, wrong-session routing, stale callbacks after reload, disconnected peer treated as active.
- deliverable: isolated two-session message transcript with exact instructions received, reconnect/reload checks, and saved validation output. Do not operate user panes.
- evidence: [37 passing tests, typecheck and lint](../reviews/20260908-intercom-validation.txt). Two client sessions exchange readiness, view, and exact advice through a real isolated Intercom broker. Lifecycle mocks cover resume/deduplication. Mailbox source and polling were removed.
- evidence: [native Pi-pair validation](../reviews/20260908-native-intercom-full-validation.txt) reports `Tests 46 passed (46)` plus successful typecheck, lint and build. The isolated production supervisor forks planning context and sends exact advice through Intercom to a real Pi worker using a transport fixture. [Supervisor events](../reviews/native-intercom/supervisor-events.jsonl) show `SteerWorker` and the worker acknowledgement; [worker events](../reviews/native-intercom/worker-events.jsonl) show the received user message. Both saved stderr files are empty.
- limitation: this deterministic test proves transport and context retention, not useful model judgment. The worker fixture does not exercise the full Ready path. Rendered Herdr two-pane acceptance and fresh-shell supervisor resume without launcher environment remain unverified.
- [x] goal: supervisor receives a useful bounded worker overview
- Borrow latest human direction, source-session path, and incremental progress from `origin/feature/simple-visible-supervision`.
- failure modes: lost authorization, repeated summaries, truncated evidence treated as complete.
- deliverable: saved before/after overview fixtures covering compaction and changed human direction.
- evidence: [generated fixture views](../reviews/20260908-worker-overview-example.txt) retain the human direction while omitting acknowledged old detail. [43-test validation](../reviews/20260908-worker-overview-validation.txt) also checks compaction reset and serialized Unicode limits; fixture content is synthetic, not a model performance claim.
- [x] goal: supervisor distinguishes agent idleness from tracked background work
- Borrow existing process/subagent tracker queries; report unavailable trackers as unknown.
- failure modes: approving while a tracked job runs, treating a local queue as a dependency of remote work.
- deliverable: idle/running/unknown status cases and a blocker-diagnosis scenario.
- evidence: the same validation log checks active and unavailable tracker reports and rejection of approval with unknown background state. Actual independent diagnosis of the queue mistake remains a behavioral acceptance task.
- [x] goal: role model choices persist
- Borrow planning/worker/supervisor model preference behavior without changing active user settings.
- failure modes: automatic model changes overwrite user choices; a missing model silently substitutes another.
- deliverable: isolated preference restoration and explicit unavailable-model errors.
- evidence: [45-test validation](../reviews/20260908-role-model-validation.txt) restores three distinct role choices, ignores automatic restore events, and leaves an unavailable saved choice unchanged. Preferences are project-local; active user settings were not edited.
## Verification
Run project tests, typecheck, and lint before commits. Preserve full command output. Keep each feature in a separate commit where practical and push finished changes. Inspect the transferred code rather than equating tests or source size with quality. Keep the requested independent evidence judge when combining implementations; do not silently remove it.
The earlier asynchronous subagent failure (missing pi-client/unix) prevented the original review. A later parent retry completed independent review run `5c8c2017-a92f-4a5f-baf6-f441f9b50495`; its [findings are preserved with attribution](../reviews/20260908-independent-supervision-bug-review.md). Behavioral acceptance requires observed useful judgment, not merely matching prompt strings. Cost savings require a measured comparison and remain unproven.
## Independent review follow-up
- [x] Verify F1/F2/F4 lifecycle failures and implement explicit recovery without fallback models or automatic pane replacement.
- [x] Address F3 inactive bindings and preserve synchronous handoff-before-ack ordering. Pending transport frames retry; end-to-end durable delivery is not guaranteed.
- [ ] F3 deeper delivery confirmation: Pi's void adapter can ack before an asynchronous enqueue failure. Future UAT must inject that failure, avoid reporting confirmed model delivery, and keep the instruction recoverable. See the [SDK source-backed limitation](../reviews/20260908-review-fixes.md). Parent approved keeping this protocol expansion out of the current fix commit.
- [x] Remove F5 general Intercom actuator, reject F6 nested placeholders, and correct F7 goal/log hashing boundary.
- [x] Add focused regressions and inspect final full test/typecheck/lint/build output. [57-test evidence](../reviews/20260908-review-fixes-validation.txt); [initial child-environment failure and correction](../reviews/20260908-review-fixes-initial-validation.md).
- [x] Parent independent post-change review of `1668c94` completed and found P1P5; [attributed review](../reviews/20260908-independent-post-fix-review.md).
- [x] Fix P1P5: explicit hello request/reply, not-ready until worker-model success, peer-specific recovery guidance, one current-plan boundary and cancellation-safe Ready waits. [Disposition and provenance](../reviews/20260908-handshake-fixes.md); [67-test full validation](../reviews/20260908-handshake-validation.txt). Real two-adapter regressions replace reliance on automatic hello replies for handshake acceptance.
- [x] F8 usage observability: warn once for an unavailable usage result, not for normal post-compaction null tokens. No estimator or changed auto-compaction policy.
- [ ] Parent independent review of these handshake fixes before push. F3 durable enqueue confirmation stays open; F8 persistent unknown/null usage, F9 trusted-repo guardrails, and native/UI/behavioral gaps remain documented.
Recovery operations were exercised only with isolated mocks/native test processes; existing user panes were not operated. Implementation worker commits locally only; parent owns review and push.
-- Pi/OpenAI
@@ -0,0 +1,58 @@
# Main supervisor and visible worker
## Superseded implementation direction
Wassname chose the shorter remote prototype `experiment/main-supervisor-edxeth` (`fb5503f`) and unmodified edxeth. Stop the runtime patch effort; preserve it as WIP in [the patch archive](../patches/abandoned-edxeth-persistent-worker/README.md). The checklist below is historical, not instructions to continue the fork.
Approved next work: commit/push this attempt, switch to that prototype, specify worker model in the plan, use installed pi-schedule-prompt for visible hourly check-ins, and add small plan-change review notifications. Check existing edxeth live messaging and Intercom/pi-messaging compatibility with a subagent before choosing any integration. Use existing token displays first; defer custom reporting. -- Pi/OpenAI
Use a strong main Pi supervisor and cheaper workers with the whole normal Pi interface. Preserve independent judgment while removing duplicated orchestration code. User wording and open decisions: [AGENTS.md](../../AGENTS.md#user-voice-redesign-discussion-2026-09-10).
1. [/] goal: Use a full interactive worker without losing autonomous supervision
- [x] Open an isolated edxeth trial without installing or changing global settings; user has seen the worker UI.
- [ ] Test direct interaction, `/model`, `/tree`, fast completion, reload/resume, and a stopped worker with background work.
- [ ] Keep the worker available for human interaction while delivering its stopped-turn result; distinguish an open Pi pane from active work.
- [ ] Reproduce lifecycle failures before patching the subagent package; do not rebuild its runtime inside pi-goals.
- likely failure: direct interaction or completion closes the pane or loses the parent notification.
- subtle failure mode: supervisor waits for human input, or claims completion while worker jobs still run.
- discriminator: saved sessions show automatic parent review after work settles, plus normal worker interaction and recovery without duplicate work.
- deliverable: usable test panes and a source-linked lifecycle review in `slop/reviews/`.
2. [ ] goal: Keep independent supervisor judgment with less execution detail
- [ ] Review on stop with no active worker processes/subagents, every 60 minutes, and on plan checks or changes.
- [ ] Choose the simplest hourly wake, evaluating session-bound `pi-schedule-prompt` without a model override; cancel reminders when supervision ends.
- [ ] Show factual worker/review/delivery status. Use concise updates and evidence paths; inspect the actual files when needed.
- [ ] Keep prompts editable and reuse existing compaction; no extra summarizing agent.
- [x] Start permissive as approved: supervisor edits the plan and approves completion after independent inspection; worker implements and records evidence. Keep normal tools and editable role prompts.
- likely failure: supervisor takes over implementation or needs the human to restart unfinished work.
- subtle failure mode: short worker summaries hide a wrong result and the supervisor accepts it without inspection.
- discriminator: supervisor rejects a plausible wrong artifact, explains the evidence, and gets the worker to correct it; separate session usage shows where tokens went.
- deliverable: editable prompts and a recorded independent review/correction cycle.
3. [ ] goal: Reduce pi-goals to planning and goal review
- [ ] Preserve plan files and explicit Ready; remove replaced transport, launching, worker views, and model state after the trial passes.
- [ ] Replace Nicobailon-specific status assumptions with the selected runtime's actual activity contract.
- [ ] Update tests and current documentation; then replace the old global subagent package after the successful trial, never load both together.
- likely failure: old and new runtimes conflict or stale commands remain advertised.
- subtle failure mode: code moves into a new wrapper without reducing duplicated responsibilities.
- discriminator: one subagent runtime owns workers; the deletion diff and real end-to-end session demonstrate retained behavior.
- verify: `npm test && npm run typecheck && npm run lint` with full output saved.
- deliverable: reviewed branch diff and working two-model setup.
4. [ ] goal: Find and inspect supervisor/worker pairs with separate usage and code provenance
- [ ] Add a script in the subagent fork to list pairs and inspect their sessions, behavior evidence, and input/output/cache token usage.
- [ ] Record Pi/package versions, tested source commits and dirty changes at launch; mark unrecoverable historical information unknown.
- likely failure: worker sessions cannot be matched to their supervisor or resumed runs disappear.
- subtle failure mode: parent totals already include worker usage, or a clean commit label hides uncommitted tested code.
- discriminator: script finds the real trial pair, matches raw per-session usage without double counting, and identifies its tested code and interventions.
- deliverable: runnable pair-inspection script, focused tests, and a saved report for the trial pair.
## UAT / Verification
- Use only parent-created test panes and a temporary Git repo; never interrupt the user's other projects. Show normal worker UI, direct interaction, independent correction, and reload/resume.
- Exercise all three review triggers, using a short test-only hour interval then inspecting the configured 60-minute value; run the pair-inspection script on these sessions.
- Save both session paths, pane captures, actual artifact and verification output, versions, token usage, and every manual intervention. A UI preview or receipt is not autonomous success.
- Diagnose exact failures from both sessions, patch the responsible component, and repeat the failed scenario. Keep unresolved behavior explicit.
## Appendix (context, not approved)
Branch: `experiment/main-supervisor-visible-worker`, based on `2a7c490`. Existing unrelated dirty files are preserved. [Initial trial and interview](../reviews/20260910_edxeth_ui_trial/notes.md). Wassname approved proceeding with "sounds good"; isolated lifecycle validation is first. Wassname then approved permissive supervisor plan/completion ownership and implementation with "so yes, do it". Lifecycle reports: [observed test](../reviews/20260910_edxeth_ui_trial/interactive-lifecycle.md), [runtime and pair-script contract](../reviews/20260910_edxeth_ui_trial/minimal-runtime-contract.md).
-- Pi/OpenAI
@@ -0,0 +1,40 @@
# Visible Pi worker extensions
Question: can a strong main Pi session supervise a cheaper, visible worker Pi session, with prompts that can be edited as files?
## Observations
### edxeth/pi-subagents — <https://github.com/edxeth/pi-subagents>
- The README states: "Interactive children open in Herdr, cmux, tmux, zellij, or WezTerm; background children run headlessly."
- Its `Orchestrator` mode removes the parent's file and shell tools. `src/runtime/orchestrator-prompt.ts` says: "You are an orchestrator ... You do not inspect files, run commands, edit code, or perform implementation work yourself."
- Agent definitions are Markdown files in `.pi/agents/` or the global Pi agent directory. Their frontmatter contains `model`, `mode`, `tools`, and `session-mode`. Thus a project can keep its worker prompt and cheap-worker model in one editable file.
- The package requires Pi `>=0.85.0`; the observed local Pi version is `0.85.1`. Interactive Herdr placement is source-tested (`scripts/test-live-herdr-*.mjs`).
- GitHub API observation: 120 stars; 5 non-bot contributors; created 2026-04-16; latest code commit 2026-09-07; 2 open / 23 closed issues.
- Risk: this package uses the npm name `pi-subagents`, which is also the name of the installed Nicobailon extension. The two export overlapping tools. They should not be loaded together.
### giuseppecrj/pi-herdr-agents — <https://github.com/giuseppecrj/pi-herdr-agents>
- The README states: "Each child runs as a real Pi process in its own Herdr surface" and documents non-blocking result delivery, live child state, and model-bearing role files.
- This is a smaller, Herdr-only alternative. It supplies visible worker panes, but static source inspection did not find the strict delegation-only parent role that `edxeth/pi-subagents` provides.
- GitHub API observation: 18 stars; 2 non-bot contributors; created 2026-08-05; latest code commit 2026-09-09; 5 open / 40 closed issues. Its declared peers are unconstrained, although development dependencies target Pi 0.84, so Pi 0.85.1 compatibility is not directly declared.
### tintinweb/pi-subagents — <https://github.com/tintinweb/pi-subagents>
- The README documents a FleetView and a "live, auto-updating conversation" overlay with steering. This is close if one TUI view is sufficient, but it is not a separately switchable worker Pi pane.
- It supports Pi `>=0.84.0`. GitHub API observation: 1,111 stars; 27 non-bot contributors; latest code commit 2026-09-03; 54 open / 46 closed issues.
### Installed nicobailon/pi-subagents — <https://github.com/nicobailon/pi-subagents>
- The README documents `/subagents-fleet`: "browse children, read transcripts, steer a running child, or stop a run." This corrects the narrower claim that it cannot expose worker activity, but it remains an inspector/overlay rather than an independent Pi terminal surface.
- GitHub API observation: 3,518 stars; latest code commit 2026-09-09. It is already installed locally.
## Inference
`edxeth/pi-subagents` is the closest existing implementation (very probable, about 90%): it directly combines a strict main-session coordinator with an interactive real Pi worker in a Herdr pane, per-role models, and Markdown agent prompts. It is a better simplification target than adding another supervisor process to `pi-goals`.
Important gap: its parent orchestrator prompt is bundled in TypeScript, though Pi's `APPEND_SYSTEM.md` can extend it. The role prompt of the worker is directly editable as `.pi/agents/worker.md`. It does not promise a bespoke compaction policy such as "every 150k"; child sessions use Pi's native compaction plus its own context-warning policy.
Static source and metadata inspection only; no candidate was installed or executed.
-- PI[openai-codex]
@@ -0,0 +1,65 @@
---
requested_model: deepseek/deepseek-v4-pro-0813
mode: code review
input: src/worker.ts, src/supervisor-runtime.ts
trace: omitted from git (11 MB raw provider transcript)
generated: 2026-09-06T04:44:52.809370+00:00
---
# MoA fragility review
Decision: reject the current fix and replace duplicate async lifecycle state with one synchronous worker tool.
Strongest objection: if a truly synchronous worker RPC is unavailable, this simplification blocks the intended parallel supervision model.
Next check: read the goal-worker tool implementation and the three failing test transcripts before deleting code.
Smallest recommended architecture:
The supervisor extension must not store worker lifecycle state. Lifecycle is owned by the subagent runtime. Move ownership into one tool boundary.
1. Delete NESTED_STATE persistence, event listeners, pending reconciliation, CheckWorkerState, and the replacement guard from supervisor-runtime.ts.
2. Add a single supervisor tool:
- RunGoalWorker: starts and awaits a goal-worker synchronously, using the aggregate output as a tool result.
- Keep one in-memory boolean `workerRunning`, guarded at tool execute start, not relying on event ordering.
3. If that synchronous tool cannot be supported:
- StartGoalWorker returns a run ID as ordinary tool output.
- WaitGoalWorker(runId) blocks on terminal status check.
- ApproveGoal always calls bg_wait on the ID from StartGoalWorker or WaitGoalWorker; otherwise approval fails.
Because existing failure 2 came from the runtime blocking on a mismatched ID, the important property is:
- an ID not produced by StartGoalWorker/WaitGoalWorker may not be used for bg_wait;
- a failed wait must clear any in-process guard immediately;
- an await cover failure must be treated as a terminal error, not as `pending`.
Exact deletions/changes:
In `src/supervisor-runtime.ts`:
- Remove `NESTED_STATE`, `NestedState`, `nested`, `persist`, `targetRun`, `completeNested`, all `subagent:async-*`, process-terminal listeners, and `retainedRunState` reconciliation.
- Remove `pi.events.on("tool_call")` blocks. Replace with allow/deny only: deny edit/write, allow read-only bash, allow RunGoalWorker, allow bg_wait, allow ApproveGoal, deny subagent action tools.
- Replace CheckWorkerState with nothing. State inspection is only through normal async progress updates.
- ApproveGoal asserts no active await cover currently exists from RunGoalWorker or WaitGoalWorker, processWorkState is idle, worktree is clean, and evidence inspection claims are backed by the actual tool result from RunGoalWorker.
In `src/worker.ts`:
- Drop `retainedRunState` and any pending-closure logic.
- Keep `asyncSnapshot` only for processWorkState, if needed.
Why this removes fragility:
- Duplicate state is gone.
- Lifecycle is only stored in the runtimes tool execution stack.
- Revival cannot resurrect a wrong worker ID unless a new tool starts it.
- Race between event handler and spawn disappears because Start or Wait returns a result synchronously to the model.
Why this may be worse:
- Synchronous wait loses the supervisor's ability to issue corrections inline during progress.
- Parallel instrumented runs cannot be sustained within one tool without exposing `bg_wait` to the model.
- If the model calls WaitGoalWorker with an incorrect ID, it will now fail directly, but the failure must not be caught and retried with a cached ID.
Acceptance test to catch all observed failures:
- Send the supervisor script: `StartGoalWorker``WaitGoalWorker(id)``RunGoalWorker(correction)``ApproveGoal`, where a midway kill drops the terminal event and forces session revival, and then assert the code path stores no `NESTED_STATE`, does not even mention it in the extension memory, and either the worker returns a tool result or the revived session remains in the same `WaitGoalWorker` tool with no retry on an ID not yielded by that tool.
## Completion
- outcome: `completed_after_follow_up`
- trace: omitted from git (11 MB raw provider transcript); this file preserves the complete review answer
@@ -0,0 +1,58 @@
---
requested_model: z-ai/glm-5.3-flash
max_tokens: 4000
final_tokens: 20000
reasoning_effort: low
input_bytes: 5103
trace: /home/code/.pi/agent/git/github.com/wassname/pi-goals/slop/reviews/2026-09-10_glm-5.3-flash_moa_brainstorm_glm_pi_goals_simplicity.trace.jsonl
generated: 2026-09-10T00:43:46.736035+00:00
---
# bounded completion
## First call reasoning
Brainstorm: architectural reductions, discriminating checks, no winner. Be concise but cover compaction, supervisor visibility, recovery, retained context; include implementation error, objective mismatch, unintended learning dynamic with falsifiable predictions.
## First call answer
# `pi-goals` simplification brainstorm — independent, no winner
## Reconstruction (observed vs. inferred)
**Observed:** two visible sessions; explicit plan state machine; recent fixes are mostly *edge-case patches* (retry bounds, retained steer, benign-error whitelists, threshold skips); compaction logic is duplicated in worker and supervisor with three separate guard conditions; recovery currently requires session reload.
**Inferred:** the system's complexity is concentrated exactly where the Pi core API is ambiguous (token estimates, compaction errors, disconnection states). The fixes treat symptoms of one root ambiguity: *the code reasons about context size it cannot actually observe, and about liveness it cannot actually verify.*
---
## Candidate reductions
### R1 — Delete pre-emptive compaction entirely; compact reactively on provider failure only
**Mechanism (implementation error candidate):** token counts are estimates; a wrong threshold either wastes a compaction (losing supervisor-facing detail) or misses, and the benign-error whitelist (`Already compacted` / `Nothing to compact`) converts a *miswired call* into silence. Falsifiable prediction: if the 100k estimate is ever wrong by >15%, the supervisor inherits a truncated plan that still passes sign-off because the compaction summary restates the plan header.
**Cheapest check:** in one isolated UAT, log the *actual* session entry count before/after each `ctx.compact` call vs. the estimated token figure. If estimated-100k sessions compact "nothing" while estimated-95k sessions compact real content, the threshold is measuring noise.
**What this removes:** three guard branches, two error whitelists, `compactApprovedWorker` as a concept.
### R2 — Single source of truth: the plan document *is* the recovery state
**Mechanism (objective mismatch candidate):** the supervisor's implicit objective ("retain judgment") is implemented as "retain transcript," so it must survive disconnects via handshakes and retries. If the objective were "retain the signed-off plan + latest steer," the transcript becomes disposable. Falsifiable prediction: after any crash/restart of *either* session, a plan-doc-only recovery reproduces the same next decision as full-transcript recovery in ≥90% of UAT replays; where it differs, the difference is always in unverifiable narrative, not judgment.
**Cheapest check:** run one UAT, kill the supervisor mid-review, restart it with only the plan file + last steer. Compare its next action to a recorded full-context control run.
**What this removes:** pi-intercom handshake/recovery retry logic, bounded hello retry, "retained newest disconnected steer" as special state — it's just the plan file's last field.
### R3 — Ended worker session = loud terminal state, not a recovery path
**Mechanism (unintended learning/behavioral dynamic candidate):** the supervisor's repeated long status narration during failed delivery looks like an agent *learning* that narration substitutes for action (it receives its own narration back as evidence of work). The current fix (keep latest instruction) addresses the queue, not the loop. Falsifiable prediction: supervisors that fail delivery once generate longer subsequent status messages than controls that never failed — narration length grows with failed attempts.
**Cheapest check:** diff supervisor message lengths before vs. after one injected failed send in an isolated Herdr run. If length grows monotonically, R3's deletion of retry-narration (replace with a single "delivery failed, worker ended" terminal banner) is warranted.
**What this removes:** overnight-instruction queueing; reload/restart becomes the *only* documented path, made loud rather than silent.
### R4 — Unify "solo" and "supervised" into: plan is approved or it isn't
Falsifiable prediction: `CompleteGoal` blocked in solo is equivalent to "no recorded sign-off exists" — i.e., the `solo|supervised` mode flag never changes a decision that the sign-off ledger doesn't already determine. **Check:** grep the codebase for decisions keyed on mode that don't transitively depend on a sign-off or supervisor-liveness fact; if none, delete the mode enum. **Removes:** `supervised | solo` state, loud-solo-fallback special case (falls out of "no sign-off + no supervisor heartbeat = blocked, loudly").
---
## Cross-cutting discriminating check (one run covers R1R4)
One isolated Herdr UAT with instrumentation logging: (a) token estimate vs. actual entries at each compact, (b) supervisor output length per turn, (c) every state-machine transition with its cause. The three predictions above are all falsifiable from this single trace plus the kill-and-restart experiment.
**Explicitly not done:** no compaction extension assumptions, no queue, no winner. R1R4 are independent deletions; each stands or falls on its own check.
## Completion
- outcome: `complete`
- trace: `/home/code/.pi/agent/git/github.com/wassname/pi-goals/slop/reviews/2026-09-10_glm-5.3-flash_moa_brainstorm_glm_pi_goals_simplicity.trace.jsonl`
File diff suppressed because one or more lines are too long
@@ -0,0 +1,150 @@
---
requested_model: moonshotai/kimi-k3
max_tokens: 4000
final_tokens: 20000
reasoning_effort: low
input_bytes: 5103
trace: /home/code/.pi/agent/git/github.com/wassname/pi-goals/slop/reviews/2026-09-10_kimi-k3_moa_brainstorm_kimi_pi_goals_simplicity.trace.jsonl
generated: 2026-09-10T00:43:46.736079+00:00
---
# bounded completion
## First call reasoning
Let me analyze this carefully. This is a bounded decision request asking for an independent scientific brainstorm about how `pi-goals` (a Pi extension providing a worker/supervisor architecture) can become simpler and more robust while preserving user preferences.
The task: propose distinct mechanisms including an implementation error, an objective/gradient mismatch, and an unintended learning dynamic. For each: falsifiable prediction and cheapest discriminating check. State observed vs inferred. Do not choose a winner.
Wait — "objective or gradient mismatch" and "unintended learning dynamic" — these are ML-flavored framings, but this is a software architecture question. The system prompt says "Reconstruct the situation from the supplied evidence. Propose distinct mechanisms, including an implementation error, an objective or gradient mismatch, and an unintended learning dynamic when relevant." Hmm — this seems like a template applied across domains. For a software system, "gradient mismatch" translates to incentive/objective mismatch — the policy objective vs. actual behavior; "learning dynamic" translates to feedback loops / state evolution dynamics where repeated behavior drifts (e.g., status narration spiraling). I should map these onto the software domain sensibly: implementation error (bug), objective mismatch (policy encodes the wrong objective), unintended dynamics (feedback loop in the session state machine, e.g., repeated status narration, compaction thrash).
Let me reconstruct:
**System**: `pi-goals` extension. One worker Pi session, one visible supervisor Pi session (fork) in a Herdr pane. Supervisor retains judgment cheaply (less context, compaction at startup), worker keeps full context.
**Preferences** (AGENTS.md): supervisor visible thinking/messages; autonomous supervision; inspect evidence; steer through worker not take over; normal tools preserved; short judgmental recaps not repeated status.
**Current state machine**: plan state `planning | working`, `supervised | solo`, approval binding, plan version, sign-offs, model role manager, intercom handshake/recovery.
**Recent fixes**: safe bare `/goals`; explicit plan replacement; bounded hello retry (1+2); retained newest disconnected steer; paired signed-off plans; loud solo fallback only after approved plan + supervisor failure; CompleteGoal blocked in solo.
**Compaction**: worker <100k known → skip; ≥100k → compact before forking supervisor; supervisor skips second compaction if inherited ends with compaction entry or <100k; unknown usage → attempt compaction, treat "Already compacted"/"Nothing to compact" as benign. Supervisor also compacts own settled turns at 100k.
**Observed issues**:
1. UAT: "Nothing to compact (session too small)" printed despite continuation — a visible error that confused; fixed with threshold skip. Suggests error classification is fragile (string matching on error messages) and that the code was attempting compaction unnecessarily on small sessions.
2. Supervisor tried to send overnight instruction after worker disconnected; repeated long status narration; couldn't deliver. New code keeps latest instruction and replays on reconnect; ended worker needs reload/restart.
3. Rate limits can look stuck; compaction can time out. Timeout ≠ permanent failure. Policy: preserve plan, loud eventual solo fallback; don't infer approval from draft/cancellation/plan change/model error.
**Constraints**: keep two visible sessions; separate read-only-by-role supervisor; explicit approval + evidence sign-off; prefer deletion and single source of truth; no silent model substitution; don't pretend delivery/recovery; no particular queue/compaction extension; testable in small isolated Herdr; identify what can be removed.
**Deliverables**:
- Architectural reductions
- Distinct mechanisms: implementation error, objective mismatch, unintended dynamic
- For each: falsifiable prediction + cheapest discriminating check
- Observed vs inferred
- No winner
- Decision stated, strongest objection, next check (per system prompt — but the system prompt also says "Do not choose a winner" via the question. The system prompt says "state the decision, strongest objection, and next check." Hmm — tension. The question says "Do not choose a winner." The system prompt says state the decision. I can reconcile: the decision requested is *how to approach simplification* — i.e., propose reductions and discriminating checks; the "decision" I can state is a bounded recommendation of which reductions are candidates, while explicitly not choosing among the causal mechanisms. Or interpret "the decision" as the answer to the question: the set of proposed reductions. I'll state the decision as: adopt deletion-first reductions gated on discriminating checks, and enumerate candidate mechanisms without ranking them as causes. Actually, better: state a bounded decision like "the safest reduction set is X, but which failure mechanism dominates is undecided — here's the check." That satisfies both.
Let me now think substantively about the architecture.
### Architectural reduction candidates
1. **Single source of truth for compaction decisions.** Currently compaction logic is spread: `compactApprovedWorker` in index.ts, supervisor startup skip logic in supervisor-session.ts, threshold constant 100k duplicated implicitly, error classification by string matching. Reduction: one module/function `shouldCompact(usage)` returning `skip | compact | attempt-benign`, used by both worker pre-fork and supervisor startup. Even better: **delete the unknown-usage compaction attempt entirely** — if usage is unknown, don't compact; compaction is only needed to fit the supervisor fork cheaply, and if usage is unknown, attempting and swallowing string-matched errors is fragile. Cheapest check: remove unknown-usage attempt, run UAT with unknown usage, confirm no error and supervisor still functions. But risk: unknown usage could be huge → supervisor fork inherits huge context → expensive. Alternative: when unknown, treat as ≥100k and compact but rely on Pi API error types rather than message strings... but the code "only uses the Pi API" — if Pi API doesn't expose typed errors, string matching is all there is. Prediction: if error classification is string-based, any Pi version changing message text breaks benign classification → visible failures. Check: unit-test classifier against both message variants; grep Pi's error strings.
2. **Compaction ownership: supervisor's own settled-turn compaction at 100k** duplicates worker logic. Reduction: the supervisor could reuse the same threshold function. Or delete supervisor-side compaction entirely and let Pi's native compaction handle it? Constraint says code depends only on Pi API and ordinary compaction events — supervisor compaction at settled turns 100k is custom. Is it needed? The supervisor is supposed to be cheap and retain judgment. Maybe keep but unify.
3. **State machine reduction**: `planning | working` × `supervised | solo` + approval binding + plan version + sign-offs + role manager + handshake/recovery. This is a lot of orthogonal state. Reduction: collapse to a single immutable plan record: `{ objective, version, approval?: {evidence, signoff, supervisorId}, status: draft|approved|complete }` and derive mode: `mode = approved ? (supervisorAlive ? supervised-working : loud-solo) : planning`. I.e., **derive, don't store** — solo/supervised as derived from liveness + approval, not stored flags that can desync. Falsifiable: desync bugs (stored solo flag persisting after supervisor reconnect) disappear if derived. Check: after supervisor reconnect, does code path that reads mode recompute it? Test: kill supervisor, reconnect, verify mode flips without manual reset.
4. **Recovery reduction**: retained newest disconnected steer + replay after reconnect + ended session requires reload. Instead of a retained-steer buffer, make steering idempotent: the steer is just the latest supervisor message; on reconnect, worker re-reads the plan record which contains pending supervisor directive. One source of truth: the plan record, not a separate buffer. Check: disconnect mid-steer, reconnect, verify exactly-once delivery and no duplication with the buffer removed.
5. **Handshake reduction**: bounded hello retry (1+2). Could be deleted in favor of deriving readiness from the fork event/stream — if Pi emits a settled/first-token event, wait for that rather than hello handshake. Check: remove hello, rely on session-ready event; UAT Ready→visible supervisor timing. But "do not request files or defer" — fine, this is a proposal.
### Mechanisms (three required genres)
**A. Implementation error (bug class)**: Error-classification by string matching (`Already compacted` / `Nothing to compact`) — observed fact 7 shows the error surfaced visibly *despite continuation* before the threshold skip, meaning the "benign" acceptance either wasn't hit on that path or the error was logged by Pi core itself (visible print) rather than thrown to the extension. Note the nuance: the error was *visibly printed by Pi* — "Pi visibly printed Error: Compaction failed" — so the extension may have accepted it as benign, but Pi's own logging surfaced it to the user. That's an observed/inferred split: observed = error text appeared; inferred = it came from Pi core logging, not extension. The threshold skip masks rather than fixes the classification fragility. Falsifiable prediction: on a Pi version that rewords these errors (e.g., "nothing to compact" lowercase, or localized), the benign path fails and compaction errors propagate or retry storms occur. Cheapest check: grep Pi's installed source for the exact strings; run a tiny session under the threshold boundary and an unknown-usage session; assert the extension's classifier matches Pi's actual error text. Also: supervisor startup skip checks "inherited context ends in a compaction entry" — an ordering assumption; if any entry appends after compaction (e.g., a system note), the skip fails and a second compaction runs. Prediction: append a post-compaction entry → supervisor double-compacts. Check: fork with inherited compaction + one trailing entry; count compact calls.
**B. Objective/gradient mismatch (policy encodes wrong objective)**: The supervisor's behavioral objective as prompted — "supervise autonomously, inspect evidence, steer" — combined with delivery-obligation (retained steer, replay) can produce **delivery-attempt narration**: fact 8 shows repeated long status narration when it could not deliver. The policy treats "supervisor must act/steer" as the objective, but the user preference is "short judgmental recaps rather than repeated unchanged status." So the mismatch: the system optimizes for *attempted steering / visible activity* rather than *information gain per token*. The threshold skip is another example: the objective "avoid compaction errors" was met by skipping compaction, but the actual objective should be "don't surface noise; compact only when needed for cost" — the fix optimized error suppression not correctness (it masks classification fragility). Also "loud solo fallback" vs "must not infer approval": timeout ≠ failure, yet a timeout-triggered solo fallback *is* an inference from ambiguous evidence — the policy must choose a decision threshold; current policy (preserve plan, loud fallback) is fine but the *trigger* conditions (what counts as supervisor failure vs slow) are a mismatch risk: treating rate-limit-stuck as failure flips to solo, which then blocks CompleteGoal — a supervisor that's merely slow degrades the whole workflow. Falsifiable prediction: inject a slow-but-alive supervisor (rate-limit delay); system flips to solo and CompleteGoal becomes blocked even though supervisor later approves — or, if fallback is only manual, no flip occurs; check which. Cheapest check: UAT with a delayed supervisor response (sleep injection), observe mode transitions and whether approval after timeout is accepted or rejected.
**C. Unintended learning/feedback dynamic (state evolution loop)**: No gradient learning here, but dynamic analogs: (1) **Narration spiral**: supervisor can't deliver → generates status → status consumes context → supervisor compacts at 100k → compaction may time out (fact 9) → more failure → more narration. A positive feedback loop where failure increases the supervisor's own context pressure, increasing future failure probability. (2) **Compaction thrash**: supervisor compacts own settled turns at 100k; each compaction summary plus recap grows toward threshold again; with "recaps that repeat plan outcome" the context re-approaches 100k cyclically, and each compaction risks timeout; unknown-usage attempts add benign-error noise. (3) **Retained-steer replay**: on reconnect, replay of newest steer + supervisor seeing replayed steer may re-generate another steer, which gets retained, replayed... a steer regeneration loop if delivery state isn't recorded. Falsifiable prediction: with a worker that disconnects for N minutes and supervisor that narrates on each failed delivery, supervisor token usage grows superlinearly and compaction events cluster; after fix (deliver-or-defer single attempt, quiet), narration count per disconnect window = ≤1. Cheapest check: scripted disconnect scenario, count supervisor messages and compaction events with timestamps; check for replayed-steer duplication in worker log (same steer id twice).
### Observed vs inferred
Observed: facts 110, excerpts. Inferred: error came from Pi core logging; narration spiral causal loop; desync risk of stored mode flags; the threshold skip masking classifier fragility; supervisor-side settled-turn compaction being redundant.
### Strongest objection
To the deletion-first reduction: deleting stored mode flags and handshake/retained-steer machinery removes explicit recovery guarantees — derived state can't distinguish "supervisor never started" from "supervisor died," and deleting the bounded hello could regress the Ready→visible-supervisor UAT. Also unknown-usage compaction deletion risks an expensive giant fork. And constraint: "do not pretend recovery succeeded" — deletion must not weaken the loud fallback.
### Next check
The single cheapest discriminating experiment: an isolated Herdr UAT matrix of 4 cells: {known <100k, known ≥100k, unknown usage} × {normal, supervisor-delayed} — count compaction calls, visible errors, mode transitions, approval acceptance. Or simpler: the disconnect/narration count test. Pick one: I'd say the smallest is the compaction-call counting test across the three usage states since it needs no fault injection, just instrumentation (log every ctx.compact call + every visible error). That discriminates mechanism A. For B/C need delay/disconnect injection. Recommend ordering: instrument first (cheap, read-only), then fault injection.
Also: propose concrete deletions list:
- Delete: unknown-usage compaction attempt (or reduce to "log and proceed").
- Delete: duplicated threshold logic → one function.
- Delete: stored `supervised | solo` flag → derive from supervisor liveness + approval presence.
- Delete: separate retained-steer buffer → fold pending directive into plan record (single source of truth).
- Possibly delete: supervisor startup inherited-compaction ordering check → replace with explicit marker/metadata passed at fork time (the worker knows it just compacted; pass a boolean rather than inspecting entry ordering). That's a nice reduction: replace inference-from-transcript with explicit handoff state. Prediction: fork marker removes ordering fragility; check: append trailing entry, confirm no double compaction.
- Handshake: keep bounded hello but derive readiness from intercom ack event rather than retry count? Or keep — it's already bounded. The retry (1+2) could be deleted in favor of: supervisor announces readiness as its first visible message (which is required anyway by visibility preference) — the hello is then observable, not a separate protocol. Merge handshake into the mandatory visible opening.
Also the "model role manager" — unclear what it does; flag as candidate for deletion if it duplicates Pi's own model selection; constraint says don't silently substitute models.
Format: This needs headers, structured. Length: substantial but bounded. Use sections: Reconstruction; Observed vs inferred; Candidate reductions (deletion-first); Mechanisms A/B/C each with prediction + cheapest check; Strongest objection; Next check. Maybe a small table for mechanisms. Keep it tight. No choosing a winner — present mechanisms as competing, note what evidence would discriminate.
The system prompt asks to "state the decision" — I'll state: the decision supported by evidence alone is to adopt the deletion-first reduction set (they're low-regret regardless of which mechanism dominates), while the causal attribution among A/B/C remains open pending checks. That's the bounded decision. Strongest objection to that. Next check.
Let me draft.
Word budget: this is complex; ~9001300 words. Use headers and compact bullets. A table for mechanisms could work well.
## First call answer
# Reconstruction (observed vs. inferred)
**Observed:** A two-session worker/supervisor extension with explicit plan state, approval binding, handshake/recovery, and threshold-based compaction at 100k. Three field anomalies: (1) a visible `Nothing to compact` error from Pi on a small session, suppressed by a threshold skip; (2) an undeliverable overnight steer producing repeated long status narration; (3) rate limits and compaction timeouts that are indistinguishable from stuckness.
**Inferred (not observed):** that the visible compaction error originated in Pi core logging rather than extension failure; that stored mode flags can desync from liveness; that narration forms a feedback loop with compaction pressure; that the threshold skip masks a fragile error classifier rather than fixing one.
# Candidate architectural reductions (deletion-first)
1. **One compaction oracle.** Collapse the threshold constant, the worker pre-fork path, the supervisor startup skip, and the unknown-usage attempt into a single `shouldCompact(usage): skip | compact` used by both sessions. Delete the unknown-usage compaction attempt: it exists only to be swallowed, and its error classification is string matching. If usage is unknown, log loudly and proceed; a too-large fork is a cost problem, not a correctness problem.
2. **Replace inference-from-transcript with explicit handoff.** The supervisor startup skip inspects whether inherited context *ends in* a compaction entry — an ordering assumption. The worker knows whether it just compacted; pass a boolean at fork time. Delete the transcript-tail inspection.
3. **Derive mode, don't store it.** `supervised | solo` and `planning | working` are stored flags that can desync from supervisor liveness and approval state. Derive: `mode = approved(plan) ? (supervisorAlive ? supervised : loud-solo) : planning`. One immutable plan record `{objective, version, approval{evidence, signoff}, status}` is the single source of truth.
4. **Fold the retained-steer buffer into the plan record.** A separate newest-steer buffer is a second source of truth for "what the supervisor wants." Store the pending directive (with a delivery marker) on the plan record; replay is then re-reading state, not a queue.
5. **Merge the handshake into the mandatory visible opening.** The supervisor must visibly announce itself anyway (user preference). Its first visible message *is* the readiness signal; the separate hello + two retries can be deleted or reduced to "wait for first settled turn."
6. **Interrogate the model role manager.** If it duplicates Pi's own model selection, delete it; the constraint against silent model substitution argues for less machinery here, not more.
# Competing mechanisms
| # | Mechanism | Class | Falsifiable prediction | Cheapest
## Final answer call answer
# Reconstruction (observed vs. inferred)
**Observed:** A two-session worker/supervisor extension with explicit plan state, approval binding, handshake/recovery, and 100k-threshold compaction. Three field anomalies: (1) a visible `Nothing to compact` error on a small session, suppressed by a threshold skip; (2) an undeliverable overnight steer producing repeated long status narration; (3) rate limits and compaction timeouts indistinguishable from stuckness.
**Inferred (not observed):** that the compaction error logging originates in Pi core, not extension failure; that stored mode flags can desync from actual liveness; that narration forms a feedback loop with compaction pressure; that the threshold skip masks a fragile error classifier rather than fixing one.
# Candidate architectural reductions (deletion-first)
1. **One compaction oracle.** Collapse the 100k constant, worker pre-fork path, supervisor startup skip, and unknown-usage attempt into a single `shouldCompact(usage): skip | compact` used by both sessions. Delete the unknown-usage compaction attempt — it exists only to be swallowed via string-matching on `Already compacted` / `Nothing to compact`. If usage is unknown, log loudly and proceed; an oversized fork is a cost problem, not a correctness problem.
2. **Replace inference-from-transcript with explicit handoff.** The supervisor startup skip inspects whether inherited context *ends in* a compaction entry — an ordering assumption. The worker knows whether it just compacted; pass a boolean at fork time. Delete the transcript-tail inspection.
3. **Derive mode, don't store it.** `supervised | solo` and `planning | working` are stored flags that can desync from supervisor liveness and approval state. Derive: `mode = approved(plan) ? (supervisorAlive ? supervised : loud-solo) : planning`. One immutable plan record `{objective, version, approval{evidence, signoff}, status}` is the single source of truth.
4. **Fold the retained-steer buffer into the plan record.** A separate newest-steer buffer is a second source of truth for "what the supervisor wants." Store the pending directive (with a delivery marker) on the plan record; replay is then re-reading state, not a queue.
5. **Merge the handshake into the mandatory visible opening.** The supervisor must visibly announce itself anyway (user preference). Its first visible message *is* the readiness signal; the separate hello + two retries can be deleted or reduced to "wait for first settled turn."
6. **Interrogate the model role manager.** If it duplicates Pi's own model selection, delete it; the constraint against silent model substitution argues for less machinery here, not more.
# Competing mechanisms
| # | Mechanism | Class | Falsifiable prediction | Cheapest discriminating check |
|---|---|---|---|---|
| 1 | **String-matched error classification is fragile.** The code swallows `Nothing to compact` / `Already compacted` by matching error text. Pi core may change message wording; the extension then treats benign cases as failures. | Implementation error | Search Pi core source for those exact strings; if they appear in a `throw` path with different surrounding text, or in a localization/template layer, classification breaks. | `grep` Pi core for the two strings; check if they're template literals or constants. If the strings are constructed dynamically, the classifier is brittle. |
| 2 | **Threshold skip masks the real compaction signal.** The 100k threshold suppresses compaction attempts on small sessions, but the real failure mode is "Pi core logs an error for a benign no-op." The threshold skip silences the symptom without fixing the classifier. | Objective mismatch (proxy metric) | If the threshold were removed and the classifier made robust, small sessions would attempt compaction, receive `Nothing to compact`, and continue silently. If they instead *fail loudly*, the threshold was load-bearing. | In an isolated Herdr session with < 100k tokens, remove the threshold skip and call `ctx.compact`. Observe whether Pi logs the error or fails the call. |
| 3 | **Mode flags desync from liveness.** `supervised | solo` is stored state; if the supervisor process dies or disconnects without updating the flag, the worker may believe it's supervised when it isn't (or vice versa). | Implementation error (state synchronization) | If the stored mode and actual supervisor process liveness can diverge, there exists a sequence where the worker blocks `CompleteGoal` (thinking it's solo) while the supervisor is alive, or allows it (thinking it's supervised) while the supervisor is dead. | In a test, kill the supervisor process without clean shutdown; check whether the worker's stored mode updates. If it doesn't, the flag is stale. |
| 4 | **Supervisor narration creates a context-pressure feedback loop.** Repeated long status messages (field report #8) consume supervisor context, pushing it toward the 100k compaction threshold, which triggers compaction, which loses nuance, which may cause more verbose re-explanation. | Unintended learning dynamic (emergent from interaction) | If narration length correlates with time-since-last-compaction, and compaction frequency correlates with narration verbosity, the loop is active. | Log supervisor token usage and narration length over a long session. If they trend upward together and reset after compaction, the loop is confirmed. |
| 5 | **Overnight steer failure reveals missing delivery acknowledgment.** The supervisor generated repeated narration because it received no signal that the worker was disconnected. The fix (retain newest steer) is correct but incomplete: the supervisor still doesn't know *whether* delivery succeeded after replay. | Implementation error (missing ack) | If the worker reconnects and the supervisor replays the steer, but the worker has already completed the goal or moved on, the replayed steer is now stale and potentially harmful. | In a test, disconnect the worker, let the supervisor queue a steer, reconnect the worker *after* it would have completed the goal solo, and observe whether the replayed steer causes confusion or incorrect behavior. |
| 6 | **Compaction timeout conflated with permanent failure.** Field report #9 notes rate limits and compaction timeouts "can appear stuck." If the supervisor compaction times out and the worker interprets this as supervisor failure, it may incorrectly trigger solo fallback. | Objective mismatch (timeout as proxy for failure) | If a supervisor compaction timeout is followed by eventual success (the compaction completes after the timeout), but the worker has already fallen back to solo, the timeout was misclassified.
## Completion
- outcome: `completed_after_follow_up`
- trace: `/home/code/.pi/agent/git/github.com/wassname/pi-goals/slop/reviews/2026-09-10_kimi-k3_moa_brainstorm_kimi_pi_goals_simplicity.trace.jsonl`
File diff suppressed because one or more lines are too long
@@ -0,0 +1,20 @@
## Review
No issues found.
- Correct: The packaged worker is discoverable in pi-subagents 0.65.1 child-safe fanout. `package.json` exposes `pi.subagents.agents`, which the installed discovery code consumes (`pi-subagents/src/agents/agents.ts:510-538,597-657`), while the child fanout executor uses normal `discoverAgents` (`pi-subagents/src/extension/fanout-child.ts:145-190`).
- Correct: The supervisor gate requires the exact packaged agent, nonempty task, `async:false`, `context:"fork"`, and the configured model with no extra fields (`src/supervisor-runtime.ts:83-108`). The installed executor honors explicit foreground mode (`pi-subagents/src/runs/foreground/subagent-executor.ts:6511-6515,6917-6920`).
- Correct: Foreground completion is tied to the real `tool_result`. `activeWorkerCalls` is removed only when that result arrives, successful completion is recorded, and approval requires a later turn (`src/supervisor-runtime.ts:75-115,132-138`). Same-message worker launch plus approval is independently rejected by inspecting the assistant message.
- Correct: Stale local launch reservations self-heal: errors clear on `tool_result`, and `turn_start` clears any reservation for which no result hook arrived (`src/supervisor-runtime.ts:75-115`). The tests cover duplicate launch, failed-result recovery, and next-turn recovery (`test/supervisor-runtime.test.ts:57-76`).
- Correct: `CompleteGoal` remains blocked while the retained supervisor is pending, while any subagent/process work is active or unknown, or until a matching approval checkpoint exists (`src/index.ts`, `CompleteGoal`). Foreground nested work therefore cannot race sign-off because its containing supervisor run remains pending.
- Correct: `supervisor-runtime.ts` does not perform runtime-agent registration. The main extension exits in child processes through `isSupervisorProcess`, while installed pi-subagents itself is inert when `PI_SUBAGENT_CHILD=1` (`src/index.ts`, `isSupervisorProcess`; installed `pi-subagents/index.ts:3-8`).
- Correct: The former nested async worker ID/pending lifecycle is absent. The remaining `workerRunId`/`workerPending` state belongs only to the retained supervisor lifecycle, matching the documented topology.
Residual risks:
- `test/package-agent.test.ts` verifies packaging statically rather than launching the packaged worker through the real child-safe fanout runtime. The installed 0.65.1 source supports the configuration, but retaining an RPC integration check is advisable.
- The focused approval tests mock Pis `tool_call`/`tool_result` ordering. A real RPC test remains the strongest guard against upstream lifecycle-event changes.
- Tests were inspected but not executed in this review environment; the supervisor should run `npm test`, `npm run typecheck`, and `npm run lint`.
- Merge verdict: **OK with residual test-environment risks.**
-- PI[reviewer/gpt-5.6-sol]
@@ -0,0 +1,105 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --run test/force-approval-flow.test.ts test/approval.test.ts test/supervisor-session.test.ts test/goals-flow.test.ts --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/approval.test.ts > hashes only the current goal, excluding the log, interview, and their historical goal text 6ms
stdout | test/force-approval-flow.test.ts > force ApproveGoal -> CompleteGoal accepts only the reviewed dirty state without committing or modifying it
Force UAT: paired real handlers accepted unchanged tracked + untracked dirty content; Git HEAD and user files stayed unchanged.
✓ test/force-approval-flow.test.ts > force ApproveGoal -> CompleteGoal accepts only the reviewed dirty state without committing or modifying it 108ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 41ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 20ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 35ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed tracked content 99ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 24ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 25ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 23ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 64ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/goals-flow.test.ts > restores working linkage even when its remembered model is unavailable, and supports explicit recovery 24ms
✓ test/goals-flow.test.ts > restores planning linkage even when its remembered model is unavailable, and supports explicit recovery 23ms
✓ test/goals-flow.test.ts > shows a missing resumed supervisor, pauses writes, and automatically unpauses when that peer returns 25ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed untracked content 82ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed new untracked 83ms
✓ test/goals-flow.test.ts > times out stale Ready retries in five seconds, without replacing the pane automatically 35ms
✓ test/goals-flow.test.ts > explicitly restarts only the tracked pane, keeps the plan, and invalidates old approval binding 24ms
✓ test/goals-flow.test.ts > does not persist startup results or launch work after session shutdown 21ms
✓ test/goals-flow.test.ts > keeps a failed Ready model not-ready and recovers the same real supervisor binding 26ms
✓ test/goals-flow.test.ts > points a present-but-paused peer recovery at the supervisor pane 17ms
✓ test/goals-flow.test.ts > clear during the initial Ready wait cancels immediately and cannot resurrect the plan 21ms
✓ test/goals-flow.test.ts > clear before the launcher resolves rejects late pane callbacks without restoring the binding 21ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed deleted untracked 62ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed index only 65ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed rename 74ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed HEAD 80ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed goal 79ms
✓ test/force-approval-flow.test.ts > force does not bypass the evidence gate 44ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 10ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 43ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 7ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 2ms
✓ test/force-approval-flow.test.ts > force does not bypass the verification gate 47ms
✓ test/force-approval-flow.test.ts > force does not bypass the stopped view gate 29ms
✓ test/force-approval-flow.test.ts > force does not bypass the tool call gate 21ms
✓ test/force-approval-flow.test.ts > force does not bypass the unknown tracker gate 27ms
✓ test/force-approval-flow.test.ts > force does not bypass the active tracker gate 28ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 98ms
✓ test/supervisor-session.test.ts > blocks the general intercom actuator even if enabled after startup 2ms
✓ test/supervisor-session.test.ts > keeps a supervisor unready after model restoration failure, then recovers explicitly without substituting a model 2ms
✓ test/supervisor-session.test.ts > warns once on unavailable usage but stays quiet for Pi's post-compaction null token sample 3ms
Test Files 4 passed (4)
Tests 45 passed (45)
Start at 06:14:52
Duration 1.54s (transform 492ms, setup 0ms, import 2.27s, tests 1.58s, environment 0ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
src/approval.ts:42:7 lint/suspicious/noImplicitAnyLet ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
× This variable implicitly has the any type.
40 │ const files = paths.map((path): WorktreeSnapshot["files"][number] => {
41 │ const fullPath = join(repoRoot, path);
> 42 │ let stat;
│ ^^^^
43 │ try { stat = lstatSync(fullPath); }
44 │ catch (error) {
i Variable declarations without type annotation and initialization implicitly have the any type. Declare a type or initialize the variable with some value.
src/approval.ts:56:12 lint/suspicious/noAssignInExpressions ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
× The assignment should not be in an expression.
54 │ const buffer = Buffer.alloc(256 * 1024);
55 │ let bytes: number;
> 56 │ while ((bytes = readSync(fd, buffer, 0, buffer.length, null)) > 0) hash.update(buffer.subarray(0, bytes));
│ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
57 │ } finally { closeSync(fd); }
58 │ return { path, kind: "file", mode, contentHash: hash.digest("hex") };
i The use of assignments in expressions is confusing.
Expressions are often considered as side-effect free.
Checked 33 files in 39ms. No fixes applied.
Found 2 errors.
check ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
× Some errors were emitted while running checks.
+132
View File
@@ -0,0 +1,132 @@
Before validation: pre-existing dirty evidence checksums
a8f1facd16fd6ff2938195a7adbdc3b4b1e1dea61533e90a39e5eb18d201e190 slop/reviews/review-fixes-native/supervisor-events.jsonl
de5bb7171e71508c40e19f3929303a63f1fa0f2ea7789a2bcc8728ea038310d2 slop/reviews/review-fixes-native/worker-events.jsonl
Command: env -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE -u PI_GOALS_EVIDENCE_DIR npm test -- --reporter=verbose
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 3ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 1ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 3ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 1ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 3ms
stdout | test/role-models.test.ts > remembers each role without automatic switching overwriting another role
Role preferences restored: planning=planner, worker=small-worker, supervisor=astra; restore events did not overwrite the choice.
✓ test/role-models.test.ts > remembers each role without automatic switching overwriting another role 9ms
✓ test/role-models.test.ts > fails on an unavailable remembered model without replacing the choice 4ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 15ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 5ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 2ms
✓ test/intercom.test.ts > does not acknowledge a synchronous handoff failure, and retries the instruction 1ms
✓ test/intercom.test.ts > detaches a completed binding and ignores its late advice without replay errors or false acceptance 1ms
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 110ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 4ms
✓ test/intercom-handshake.test.ts > re-handshakes unchanged peers in either direction without hello ping-pong or lost advice 11ms
✓ test/intercom-handshake.test.ts > replays pending advice and views across either role's own readiness transition 1ms
✓ test/intercom-handshake.test.ts > cancels pending waits immediately on detach or reconfiguration 2ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 8ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 55ms
✓ test/approval.test.ts > fingerprints literal unusual paths, binary bytes, symlink targets, modes and deletions 177ms
✓ test/approval.test.ts > hashes only the current goal, excluding the log, interview, and their historical goal text 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 0ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
✓ test/fold.test.ts > does not show historical Log subtasks under the last active goal 0ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 2ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 1ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ignores a historical duplicate below the Log and leaves it unchanged 0ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 51ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 25ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
stdout | test/force-approval-flow.test.ts > force ApproveGoal -> CompleteGoal accepts only the reviewed dirty state without committing or modifying it
Force UAT: paired real handlers accepted unchanged tracked + untracked dirty content; Git HEAD and user files stayed unchanged.
✓ test/force-approval-flow.test.ts > force ApproveGoal -> CompleteGoal accepts only the reviewed dirty state without committing or modifying it 124ms
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 425ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 27ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 28ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 20ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 22ms
✓ test/force-approval-flow.test.ts > keeps ordinary clean approval unchanged and rechecks runtime state at forced completion 104ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 74ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/goals-flow.test.ts > restores working linkage even when its remembered model is unavailable, and supports explicit recovery 27ms
✓ test/goals-flow.test.ts > restores planning linkage even when its remembered model is unavailable, and supports explicit recovery 26ms
✓ test/goals-flow.test.ts > shows a missing resumed supervisor, pauses writes, and automatically unpauses when that peer returns 25ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed tracked content 78ms
✓ test/goals-flow.test.ts > times out stale Ready retries in five seconds, without replacing the pane automatically 32ms
✓ test/goals-flow.test.ts > explicitly restarts only the tracked pane, keeps the plan, and invalidates old approval binding 31ms
✓ test/goals-flow.test.ts > does not persist startup results or launch work after session shutdown 27ms
✓ test/goals-flow.test.ts > keeps a failed Ready model not-ready and recovers the same real supervisor binding 32ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed untracked content 76ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed new untracked 70ms
✓ test/goals-flow.test.ts > points a present-but-paused peer recovery at the supervisor pane 21ms
✓ test/goals-flow.test.ts > clear during the initial Ready wait cancels immediately and cannot resurrect the plan 27ms
✓ test/goals-flow.test.ts > clear before the launcher resolves rejects late pane callbacks without restoring the binding 19ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed deleted untracked 61ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed index only 63ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed index contents 122ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed rename 73ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed HEAD 67ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 9ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 26ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 77ms
✓ test/supervisor-session.test.ts > blocks the general intercom actuator even if enabled after startup 2ms
✓ test/supervisor-session.test.ts > keeps a supervisor unready after model restoration failure, then recovers explicitly without substituting a model 2ms
✓ test/supervisor-session.test.ts > warns once on unavailable usage but stays quiet for Pi's post-compaction null token sample 3ms
✓ test/force-approval-flow.test.ts > invalidates forced approval after changed goal 86ms
✓ test/force-approval-flow.test.ts > force does not bypass the evidence gate 51ms
✓ test/force-approval-flow.test.ts > force does not bypass the verification gate 42ms
✓ test/force-approval-flow.test.ts > force does not bypass the stopped view gate 24ms
✓ test/force-approval-flow.test.ts > force does not bypass the tool call gate 25ms
✓ test/force-approval-flow.test.ts > force does not bypass the unknown tracker gate 25ms
✓ test/force-approval-flow.test.ts > force does not bypass the active tracker gate 27ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1856ms
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2941ms
Test Files 18 passed (18)
Tests 85 passed (85)
Start at 06:18:03
Duration 3.48s (transform 3.77s, setup 0ms, import 7.89s, tests 7.45s, environment 2ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 33 files in 68ms. No fixes applied.
> @wassname2/pi-goals@0.2.2 build
> tsc
After validation: pre-existing dirty evidence checksums
a8f1facd16fd6ff2938195a7adbdc3b4b1e1dea61533e90a39e5eb18d201e190 slop/reviews/review-fixes-native/supervisor-events.jsonl
de5bb7171e71508c40e19f3929303a63f1fa0f2ea7789a2bcc8728ea038310d2 slop/reviews/review-fixes-native/worker-events.jsonl
@@ -0,0 +1,122 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 3ms
stdout | test/role-models.test.ts > remembers each role without automatic switching overwriting another role
Role preferences restored: planning=planner, worker=small-worker, supervisor=astra; restore events did not overwrite the choice.
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 4ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 2ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/intercom.test.ts > does not acknowledge a synchronous handoff failure, and retries the instruction 1ms
✓ test/intercom.test.ts > detaches a completed binding and ignores its late advice without replay errors or false acceptance 1ms
✓ test/role-models.test.ts > remembers each role without automatic switching overwriting another role 32ms
✓ test/role-models.test.ts > fails on an unavailable remembered model without replacing the choice 5ms
✓ test/intercom-handshake.test.ts > re-handshakes unchanged peers in either direction without hello ping-pong or lost advice 9ms
✓ test/intercom-handshake.test.ts > replays pending advice and views across either role's own readiness transition 2ms
✓ test/intercom-handshake.test.ts > cancels pending waits immediately on detach or reconfiguration 2ms
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 3ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 1ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 3ms
✓ test/approval.test.ts > hashes only the current goal, excluding the log, interview, and their historical goal text 8ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 2ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 3ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 51ms
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 52ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 5ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
✓ test/fold.test.ts > does not show historical Log subtasks under the last active goal 0ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 2ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 0ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
× test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 5ms
→ expected '# Plan\n\n## Goals\n\n1. [/] goal: Im…' to be null
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 254ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 59ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 33ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 27ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 38ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 41ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 27ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 61ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/goals-flow.test.ts > restores working linkage even when its remembered model is unavailable, and supports explicit recovery 21ms
✓ test/goals-flow.test.ts > restores planning linkage even when its remembered model is unavailable, and supports explicit recovery 23ms
✓ test/goals-flow.test.ts > shows a missing resumed supervisor, pauses writes, and automatically unpauses when that peer returns 26ms
✓ test/goals-flow.test.ts > times out stale Ready retries in five seconds, without replacing the pane automatically 29ms
✓ test/goals-flow.test.ts > explicitly restarts only the tracked pane, keeps the plan, and invalidates old approval binding 24ms
✓ test/goals-flow.test.ts > does not persist startup results or launch work after session shutdown 23ms
✓ test/goals-flow.test.ts > keeps a failed Ready model not-ready and recovers the same real supervisor binding 31ms
✓ test/goals-flow.test.ts > points a present-but-paused peer recovery at the supervisor pane 21ms
✓ test/goals-flow.test.ts > clear during the initial Ready wait cancels immediately and cannot resurrect the plan 25ms
✓ test/goals-flow.test.ts > clear before the launcher resolves rejects late pane callbacks without restoring the binding 21ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 8ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 21ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 96ms
✓ test/supervisor-session.test.ts > blocks the general intercom actuator even if enabled after startup 3ms
✓ test/supervisor-session.test.ts > keeps a supervisor unready after model restoration failure, then recovers explicitly without substituting a model 2ms
✓ test/supervisor-session.test.ts > warns once on unavailable usage but stays quiet for Pi's post-compaction null token sample 3ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1541ms
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2503ms
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
FAIL test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line
AssertionError: expected '# Plan\n\n## Goals\n\n1. [/] goal: Im…' to be null
- Expected:
null
+ Received:
"# Plan
## Goals
1. [/] goal: Implement the cache layer
- tasks:
1. [x] wire client
2. [x] goal: Ship the docs
## Log
3. [ ] goal: Ship the docs
"
test/tick-goal.test.ts:30:42
28| it("returns null when the subject matches more than one goal line", (…
29| const dup = `${plan}3. [ ] goal: Ship the docs\n`;
30| expect(tickGoal(dup, "Ship the docs")).toBeNull();
| ^
31| });
32| });
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯
Test Files 1 failed | 16 passed (17)
Tests 1 failed | 65 passed (66)
Start at 19:22:13
Duration 2.84s (transform 2.51s, setup 0ms, import 5.72s, tests 5.21s, environment 2ms)
+42
View File
@@ -0,0 +1,42 @@
# Post-review P1P5 fixes — Pi/OpenAI implementation worker
Baseline: `1668c94`. Independent review: [attributed, preserved source](20260908-independent-post-fix-review.md), reviewer run `bdb93a2e-52f4-4a6d-bac2-7c9eb48118b5`.
Read AGENTS.md and installed Pi extension docs for lifecycle teardown, commands, model selection and compaction before editing. No user pane/session was operated; tests use isolated mocks/brokers/native Pi processes. No nested delegation or push.
## Dispositions
- **P1:** Replaced change-gated hello replies with an explicit request/reply bit. Every request receives one reply even when the peer state is unchanged; a reply never elicits another hello. Each successful exchange retries only still-pending instructions/current view, including after either side's own readiness transition. Repeated wire frames are allowed and deduplicated at the receiving adapter; this is not a new durable-delivery claim. `test/intercom-handshake.test.ts` wires **two real GoalIntercom adapters**, not an auto-ready peer. It checks repeated worker and supervisor reconfiguration, concurrent reset (four hello frames), single-sided reset (two frames), exact advice handoff, own-ready pause/resume, pending advice/view replay, and reconnect deduplication. Both peers must load the updated transport; mixed-version reconnect is not claimed supported.
- **P2:** The worker configures not-ready during startup/recovery. Startup can await peer readiness without claiming implementation readiness. It announces ready only after worker model restoration and the phase transition to working. Model failures remain not-ready. The Ready/retry flow test uses the same two real adapters and proves unavailable worker model → not-ready → `/model` + reconnect → Ready → working on the **same** binding/pane, followed by successful advice after healthy reconnect. Planning reconnect alone does not authorize implementation.
- **P3:** A known peer with incomplete readiness is distinguished from an absent peer. Guidance points to the supervisor pane's compaction/model diagnostics and `/model` + `/goals reconnect`, rather than treating every pause as disconnection. Regression checks widget and prompt guidance.
- **P4:** `src/plan.ts` now owns the single goal-line and Log-fold definitions. Widget scanning, subtasks, goal ticking and approval use the same current-plan boundary. Tick still rejects duplicate active-region matches; historical Log copies remain byte-for-byte unchanged. The existing approval/sign-off flow now includes duplicate/historical goal lines in the Log, succeeds and ends the active plan instead of reopening historical goals.
- **P5:** Detach/reconfigure immediately reject old readiness waiters. A small Ready-attempt identity plus plan-version guard invalidates asynchronous startup results on clear/recovery/replacement; stale menu/editor responses are also ignored. Regressions clear while the five-minute initial wait is pending (no clock advance needed to settle), then advance five minutes and verify no resurrection; a second test clears before the launcher callback resolves and verifies no late binding/pane persistence or work launch. No automatic late-pane kill was added.
- **F8 observability:** One warning per runtime if the entire usage result is unavailable at a settled check. No warning for Pi's ordinary post-compaction `tokens: null` sample. No speculative token estimator, new compaction policy, or change to Pi auto-compaction. Persistent null usage still cannot trigger the custom 100k check.
## Verification and changed old assertions
[Full successful commands/output](20260908-handshake-validation.txt): **67 tests passed in 17 files**, followed by successful typecheck, lint, build and `git diff --check`. The exact main-session test command unsets `PI_SUBAGENT_CHILD` and `PI_GOALS_ROLE` and sets a **fresh explicit** `PI_GOALS_EVIDENCE_DIR` to `slop/reviews/handshake-native`.
Two intermediate failures are preserved, not counted as passes:
1. [Handshake-focused run](20260908-handshake-initial-validation.txt): 26 passed/1 failed. The old assertion demanded exactly one outbound wire retry after configure+markReady. These now generate separate request/reply exchanges, which can retry the same still-unacked id more than once before its ack. Updated assertion requires at least one retry, every retry's exact id/text, and no further retries after ack. Two-real-adapter tests independently require exactly one user handoff/view callback after duplicate wire delivery.
2. [First full boundary run](20260908-handshake-boundary-initial-validation.txt): 65 passed/1 failed. Its old duplicate-goal fixture appended the duplicate **below `## Log`**, precisely the P4 behavior being corrected. The duplicate-rejection test now inserts the duplicate above the fold and still requires null; an added test requires historical copies below the fold to be ignored and unchanged.
An intermediate typecheck passed; lint initially flagged import order and a nested assignment. Those were corrected; the full final lint passed with no fixes applied.
[Native log inspection](20260908-handshake-log-inspection.txt) reads the final worker/supervisor event files, verifies zero error records and empty stderr, and matches the outgoing instruction, worker incoming instruction and adapter ack id `22068654-6e7c-4328-890f-9382b25c8ea7`. The worker user message is exactly `[supervisor] Read the real outputs before declaring completion.` This deterministic native test proves context retention/routing/tool exposure, not autonomous judgment or durable enqueue guarantees.
## Evidence provenance caveat
At the first inspection, these two tracked files were **already dirty**:
- `slop/reviews/review-fixes-native/supervisor-events.jsonl`
- `slop/reviews/review-fixes-native/worker-events.jsonl`
The inherited `PI_GOALS_EVIDENCE_DIR` pointed there. The first full test run accidentally refreshed them again. Their pre-task uncommitted bytes were not captured, so it is not established that all differences from HEAD were produced by this worker. They are left **unstaged and uncommitted**, not restored over unknown prior edits. The refreshed copies were separately preserved under this worker's output directory, `scratch-refreshed-prior-evidence/`. Final evidence uses only the fresh `handshake-native/` directory and is not mixed with these prior paths.
## Still open / acceptance limits
**F3 async enqueue confirmation remains open.** Pi's void `sendUserMessage` wrapper can return before a later async enqueue rejection. An adapter ack is not durable enqueue, model receipt, or execution confirmation. No correlated-receipt protocol was added; the future forced-async-rejection UAT remains required. A synchronous handoff failure still remains unacked for retry.
Parent/reviewer owns independent post-change review and push. Rendered Herdr acceptance, the complete two-native-session ApproveGoal → CompleteGoal chain, fresh-shell role recovery without launcher environment, useful independent judgment and cost savings remain unproven. Planning/pause shell gates remain trusted-repo guardrails, not a security sandbox. If a pane split finishes after cancellation, it can remain untracked for human inspection; this change prevents stale state resurrection rather than operating a late pane automatically.
@@ -0,0 +1,77 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --run test/intercom-handshake.test.ts test/intercom.test.ts test/goals-flow.test.ts --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/intercom-handshake.test.ts > re-handshakes unchanged peers in either direction without hello ping-pong or lost advice 7ms
✓ test/intercom-handshake.test.ts > replays pending advice and views across either role's own readiness transition 1ms
✓ test/intercom-handshake.test.ts > cancels pending waits immediately on detach or reconfiguration 1ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 4ms
× test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 7ms
→ expected [ { binding: 'binding', …(4) }, …(1) ] to match object [ { …(2) } ]
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/intercom.test.ts > does not acknowledge a synchronous handoff failure, and retries the instruction 1ms
✓ test/intercom.test.ts > detaches a completed binding and ignores its late advice without replay errors or false acceptance 3ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 34ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 18ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 24ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 22ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 18ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 23ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 47ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/goals-flow.test.ts > restores working linkage even when its remembered model is unavailable, and supports explicit recovery 18ms
✓ test/goals-flow.test.ts > restores planning linkage even when its remembered model is unavailable, and supports explicit recovery 16ms
✓ test/goals-flow.test.ts > shows a missing resumed supervisor, pauses writes, and automatically unpauses when that peer returns 17ms
✓ test/goals-flow.test.ts > times out stale Ready retries in five seconds, without replacing the pane automatically 26ms
✓ test/goals-flow.test.ts > explicitly restarts only the tracked pane, keeps the plan, and invalidates old approval binding 23ms
✓ test/goals-flow.test.ts > does not persist startup results or launch work after session shutdown 23ms
✓ test/goals-flow.test.ts > keeps a failed Ready model not-ready and recovers the same real supervisor binding 23ms
✓ test/goals-flow.test.ts > points a present-but-paused peer recovery at the supervisor pane 18ms
✓ test/goals-flow.test.ts > clear during the initial Ready wait cancels immediately and cannot resurrect the plan 21ms
✓ test/goals-flow.test.ts > clear before the launcher resolves rejects late pane callbacks without restoring the binding 35ms
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
FAIL test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment
AssertionError: expected [ { binding: 'binding', …(4) }, …(1) ] to match object [ { …(2) } ]
- Expected
+ Received
[
{
+ "binding": "binding",
+ "id": "7f4566ea-f2ef-4a14-ad75-e138fc3a26a0",
+ "kind": "steer",
+ "role": "supervisor",
+ "text": "Read the full output.",
+ },
+ {
+ "binding": "binding",
"id": "7f4566ea-f2ef-4a14-ad75-e138fc3a26a0",
+ "kind": "steer",
+ "role": "supervisor",
"text": "Read the full output.",
},
]
test/intercom.test.ts:45:76
43| resumed.link.markReady();
44| await resumed.link.waitReady();
45| expect(resumed.fixture.sent.filter(message => message.kind === "stee…
| ^
46| resumed.fixture.receive({ binding: "binding", role: "worker", kind: …
47| resumed.fixture.connect(false);
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯
Test Files 1 failed | 2 passed (3)
Tests 1 failed | 26 passed (27)
Start at 19:20:05
Duration 861ms (transform 365ms, setup 0ms, import 583ms, tests 437ms, environment 0ms)
@@ -0,0 +1,8 @@
slop/reviews/handshake-native/worker-events.jsonl: 22 events; 0 error records; stderr 0 bytes
worker: ack received cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc
worker: ack received cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc
worker: in steer 22068654-6e7c-4328-890f-9382b25c8ea7
worker: [{"type":"text","text":"[supervisor] Read the real outputs before declaring completion."}]
slop/reviews/handshake-native/supervisor-events.jsonl: 21 events; 0 error records; stderr 0 bytes
supervisor: out steer 22068654-6e7c-4328-890f-9382b25c8ea7
supervisor: ack received 22068654-6e7c-4328-890f-9382b25c8ea7
@@ -0,0 +1,107 @@
+ env -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE PI_GOALS_EVIDENCE_DIR=/home/code/.pi/agent/git/github.com/wassname/pi-goals/slop/reviews/handshake-native npm test -- --reporter=verbose
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 5ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 47ms
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 3ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 3ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 26ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 0ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 3ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 1ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 2ms
stdout | test/role-models.test.ts > remembers each role without automatic switching overwriting another role
Role preferences restored: planning=planner, worker=small-worker, supervisor=astra; restore events did not overwrite the choice.
✓ test/role-models.test.ts > remembers each role without automatic switching overwriting another role 14ms
✓ test/role-models.test.ts > fails on an unavailable remembered model without replacing the choice 5ms
✓ test/approval.test.ts > hashes only the current goal, excluding the log, interview, and their historical goal text 5ms
✓ test/intercom-handshake.test.ts > re-handshakes unchanged peers in either direction without hello ping-pong or lost advice 9ms
✓ test/intercom-handshake.test.ts > replays pending advice and views across either role's own readiness transition 1ms
✓ test/intercom-handshake.test.ts > cancels pending waits immediately on detach or reconfiguration 2ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 7ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 4ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/intercom.test.ts > does not acknowledge a synchronous handoff failure, and retries the instruction 2ms
✓ test/intercom.test.ts > detaches a completed binding and ignores its late advice without replay errors or false acceptance 1ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ignores a historical duplicate below the Log and leaves it unchanged 0ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 4ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
✓ test/fold.test.ts > does not show historical Log subtasks under the last active goal 0ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 47ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 24ms
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 236ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 32ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 29ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 26ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 20ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 62ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/goals-flow.test.ts > restores working linkage even when its remembered model is unavailable, and supports explicit recovery 33ms
✓ test/goals-flow.test.ts > restores planning linkage even when its remembered model is unavailable, and supports explicit recovery 24ms
✓ test/goals-flow.test.ts > shows a missing resumed supervisor, pauses writes, and automatically unpauses when that peer returns 24ms
✓ test/goals-flow.test.ts > times out stale Ready retries in five seconds, without replacing the pane automatically 25ms
✓ test/goals-flow.test.ts > explicitly restarts only the tracked pane, keeps the plan, and invalidates old approval binding 42ms
✓ test/goals-flow.test.ts > does not persist startup results or launch work after session shutdown 36ms
✓ test/goals-flow.test.ts > keeps a failed Ready model not-ready and recovers the same real supervisor binding 31ms
✓ test/goals-flow.test.ts > points a present-but-paused peer recovery at the supervisor pane 17ms
✓ test/goals-flow.test.ts > clear during the initial Ready wait cancels immediately and cannot resurrect the plan 25ms
✓ test/goals-flow.test.ts > clear before the launcher resolves rejects late pane callbacks without restoring the binding 19ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 7ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 22ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 1ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1350ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 87ms
✓ test/supervisor-session.test.ts > blocks the general intercom actuator even if enabled after startup 2ms
✓ test/supervisor-session.test.ts > keeps a supervisor unready after model restoration failure, then recovers explicitly without substituting a model 2ms
✓ test/supervisor-session.test.ts > warns once on unavailable usage but stays quiet for Pi's post-compaction null token sample 2ms
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2530ms
Test Files 17 passed (17)
Tests 67 passed (67)
Start at 19:24:07
Duration 2.84s (transform 2.36s, setup 0ms, import 6.39s, tests 4.95s, environment 3ms)
+ npm run typecheck
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
+ npm run lint
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 32 files in 91ms. No fixes applied.
+ npm run build
> @wassname2/pi-goals@0.2.2 build
> tsc
+ git diff --check
@@ -0,0 +1,100 @@
# Post-fix independent bug review — pi-goals supervision recovery
Scope: changes `2824396..1668c94` (fix commit `325b939` + evidence commit `1668c94`).
Inputs: AGENTS.md, `slop/reviews/20260908-review-fixes.md` (dispositions), `slop/reviews/20260908-independent-supervision-bug-review.md` (original F1F9), full current sources of `src/{index,intercom,supervisor-session,approval,role-models,herdr}.ts`, changed tests, native evidence logs.
Read-only: no repo edits, no live panes, no messaging. Repro artifacts lived in /tmp only.
Labels: **[TESTED]** = executed/compiled and observed. **[CODE]** = unambiguous from source. **[INFERENCE]** = depends on runtime behavior I could not observe here. Test passage is treated as evidence of the asserted path only, not as design proof.
Baseline check: `env -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE npx vitest run` → 57/57 pass in 16 files, matching the worker's validation claim. **[TESTED]**
---
## Fix verification F1F7
**F1 (unavailable remembered model aborts restore) — verified fixed. [CODE + repo tests]**
`session_start` now sets `modelError` first, configures the binding and timers independent of model selection, and only then attempts `restoreModel` in try/catch (`src/index.ts:557-580`). On failure: no `setModel`, no ready hello (`configure(..., false)` at :562, `markReady` gated on `!modelError` at :572-573), paused widget (`pauseReason`/`updateWidget` :149-153, 271-276), write/sign-off gating (:453-456, 592-597), human input and read-only diagnosis retained. `/model` saves over the failed role choice because `RoleModels.enter` sets `this.role` before throwing (`src/role-models.ts:29-30`), so `/goals reconnect` then picks up the user's replacement — a deliberate, workable recovery chain. No fallback model is substituted anywhere.
**F2 (resumed worker silently unsupervised) — verified fixed, with a residual in P3 below. [CODE + repo tests]**
`connected` now requires own-ready + binding + channel + peerReady (`src/intercom.ts:87`); `onConnectionChange` refreshes the widget immediately (:139, :145, :164); a resumed working worker hellos not-ready until its model restores, then `waitReady(5000)` and warns on failure (`src/index.ts:572-577`). Returning peers clear the pause automatically via the hello/`changed` path. Explicit `/goals restart` preserves plan/version and replaces only the tracked pane with a fresh approval binding (test asserts old checkpoint removed, plan unchanged, exactly one close).
**F3 (inactive-plan steer throws/replays) — lifecycle part fixed; delivery gap honestly open. [CODE + repo tests]**
`detach()` (`src/intercom.ts:72-81`) clears the binding on completion/clear/restart; late steers for a dead binding are dropped at the binding check (:151) without invoking `onSteer` or acking — covered by the new intercom tests. Ack ordering is still handoff-before-ack (:186-193), so a synchronous `sendUserMessage` throw leaves the steer unrecorded/unacked and it retries (test proves retry succeeds). The documented residual is real and correctly **not** claimed fixed: Pi 0.84.1's `sendUserMessage` is a void wrapper over an async enqueue, so an ack can precede an asynchronous enqueue failure, after which the instruction is gone from the supervisor's pending set and never reaches the model — silently. This is a genuine gap a future correlated-receipt protocol should close; the recorded UAT requirement (force an async enqueue rejection) is the right acceptance test. Acceptable as an explicitly-open item, not as a resolved one.
**F4 (stale pane → repeated 5-minute Ready waits) — verified fixed for the timeout itself. [CODE + repo tests]**
Existing-pane reconnect waits are 5s (`src/index.ts:186`, `:323`); first launch keeps the 300s compaction allowance (:213); failed `pane run` retains and reports the pane ID (:204-208); no automatic pane kill. **However, see P1: in one important sub-scenario the 5s retry fails deterministically even when the supervisor is healthy, so the fix's "retry" guidance does not actually recover there.**
**F5 (supervisor gets general `intercom` tool) — verified fixed. [CODE + native test]**
`intercom` is in `BLOCKED_TOOLS` (`src/supervisor-session.ts:13`), filtered from active tools at start and bootstrap (:108-110, :146), and blocked at tool-call time even if re-enabled (:170-173). The native pair test asserts the real supervisor model request's tool list excludes `intercom` and `bash`. Note the tool gate uses `terminate: true`, so a blocked call ends the whole supervisor turn — a deliberate-looking but behaviorally stronger choice than the planning gate's plain block.
**F6 (nested placeholder evidence) — verified fixed as far as claimed. [CODE + repo tests]**
Both the inline and child-bullet paths reject exactly `(empty until sign-off)` case-insensitively (`src/supervisor-session.ts:46,52`); the string matches the template in `src/prompts.ts:97`. Residual (documented as a presence floor): the child scan still accepts *any* deeper-indented nonblank bullet as evidence, and quoted variants like `"(empty until sign-off)"` pass. That is a semantic-judging limit, accurately disclaimed; supervisor judgment remains the real gate. Acceptable.
**F7 (last-goal hash includes Log/Interview) — verified fixed. [CODE + TESTED via unit tests]**
`goalBlock` now truncates the plan at `## Log` before scanning and ends the block at the next goal line or any `#`/`##` heading, with `trimEnd` (`src/approval.ts:43-58`). `approval.test.ts` covers duplicate goal text in the log, Interview section, next-goal boundary, and real block edits invalidating the hash; the flow test proves a manual log line between ApproveGoal and CompleteGoal no longer invalidates. Fail-closed on upgrade (old hashes need re-approval) is the right direction. One residual asymmetry (P4 below).
---
## New findings
### P1 — Reconnect/Ready-retry can wedge in a half-open state: peer hello is only re-sent on *perceived* state change (Medium) [TESTED]
`GoalIntercom.configure()` resets `peer`/`peerReady` (`src/intercom.ts:45-46`) and sends a hello, but the peer replies to a hello only when *its own* view changed (`src/intercom.ts:154-164`: `changed = !this.peer || this.peerReady !== message.ready; if (changed) this.hello()`). There is no periodic hello. If the peer's stored state already matches the incoming hello (same session id, same ready flag), it stays silent — so the side that reconfigured never learns the peer and `connected` stays false forever (until some unrelated broker `session_joined` at :148 happens to trigger a hello).
Reproduced in isolation (compiled real `src/intercom.ts` from HEAD, two links cross-wired as broker peers, script in /tmp, no repo changes):
```
after initial link: worker.connected = true supervisor.connected = true
after worker reconfigure: worker.connected = false supervisor.connected = true
waitReady REJECTED after 201 ms: Supervisor did not become ready through pi-intercom; inspect its pane.
supervisor steer() succeeded (reports sent)
worker delivered steer: null
```
Consequences, all reachable through new/changed code paths:
1. **`/goals reconnect` on a healthy link breaks it.** `src/index.ts:322-323` reconfigures the same binding; if nothing about readiness actually changed, every retry times out after 5s with "Goal recovery failed", and the only in-app escape is `/goals restart` — which closes the *healthy* pane and invalidates the approval binding (`beginReview` deletes checkpoints).
2. **The F1-on-Ready retry fails deterministically.** First Ready: `startSupervisor` completes the hello exchange (worker announced `ready=true` at `beginReview`/`configure`), then `restoreModel("worker")` throws → back to planning. After the user fixes the model, the next Ready takes the existing-pane path (`src/index.ts:184-186`): `configure` resets the worker's peer, hellos `ready=true`, the supervisor sees no change, stays silent, and `waitReady(5000)` times out — even though the supervisor is up and healthy. Every Ready/reconnect retry repeats this. This undercuts the F1/F4 recovery story on exactly the path those fixes target.
3. **Silent steer loss during the window.** While half-open, the supervisor's `connected` is true, so `SteerWorker` "succeeds", but the worker drops the message at `src/intercom.ts:166` (`event.fromSessionId !== this.peer`) with no notification; the steer sits in pending awaiting a changed hello that may never come. The SteerWorker result text ("Receipt and execution are not confirmed") softens but does not surface this.
Why the tests miss it: the fixture auto-replies to **every** hello with `ready: true` (`test/intercom-fixture.ts:21`), which is precisely the behavior the real peer logic does not have. The new peer-return and reconnect tests therefore cannot observe the change-gated reply.
Suggested direction (not implemented): reply to a hello whenever the sender may have lost state — e.g. have `configure` retain `peer`/`peerReady` when the binding is unchanged (re-handshake is only needed after a real transport/binding change), or include a monotonic hello generation and reply to any newer/unknown generation. An unconditional reply to every hello also works without ping-pong, because the *response* hello is still change-gated on the receiver's side.
### P2 — Failed Ready leaves the worker announcing `ready=true` while paused (Low) [CODE]
In the Ready flow, `beginReview``configure(approvalId, "worker", ctx)` defaults to `ready=true` (`src/intercom.ts:43`, `src/index.ts:171`). If `restoreModel("worker")` then throws (`src/index.ts:525` → catch at :537-544), the code rolls back `phase` to planning but never rolls back intercom readiness or detaches. The worker thereafter hellos `ready=true` on any broker event while `modelError` is set; the supervisor sees a ready, connected worker, `SteerWorker` sends successfully, and the worker's `onSteer` throws (`src/index.ts:113-116`) — unacked, error notification per replay. Self-consistent recovery exists (next Ready after `/model` works, modulo P1), so impact is confusing error noise and a misleading readiness signal, not loss. A `markNotReady`/detach in that catch would align the announced state with the pause.
### P3 — Worker pause message misattributes a *supervisor-side* pause (Low) [CODE]
`pauseReason()` (`src/index.ts:149-154`) collapses "peer absent" and "peer present but not ready" into one message: "Supervisor disconnected. Run /goals reconnect, or /goals restart…". When the supervisor pane is alive but paused on its own model restoration (`src/supervisor-session.ts:150-158` sets supervisor `modelError`, readiness stays false), the worker-side `/goals reconnect` will hello, get a `ready=false` reply, and time out after 5s — the advised action cannot work; the actual fix is `/model` + `/goals reconnect` in the supervisor pane. The supervisor pane does display its own error notification, and the design keeps both panes visible, so the user has the information — but the worker-side guidance points the wrong way. `peer` set + `peerReady` false is distinguishable from no peer; the message could be too.
### P4 — `goalBlock` and `tickGoal` now scan different regions (Low) [CODE]
Post-F7, `goalBlock` only sees the pre-`## Log` region (`src/approval.ts:44`), while `tickGoal` and `scanGoals` still scan the whole file (`src/index.ts:670-677`, :53-60). A goal-shaped line quoted inside the Log (e.g. a pasted checklist) yields: `goalBlock` finds a unique match → approval proceeds and hashes, but `CompleteGoal``tickGoal` finds two hits → returns null → sign-off blocked after a successful approval. Fail-closed, requires unusual plan content, and the same class of confusion pre-dates the fix (both sides failed before); noting it because the fix changed the boundary of only one of the two scanners.
### P5 — Ready catch can resurrect a cleared plan phase after a concurrent `/goals clear` (Low) [CODE/INFERENCE]
The Ready path awaits up to 300s inside `startSupervisor` (`src/index.ts:213`), and neither `detach()` nor `configure()` wakes `waitReady` waiters (only hellos/shutdown do; `detach`'s clearing of `binding` means its own not-ready hello is ignored by waiters, and the peer's reply is dropped by the now-empty binding check). If the user runs `/goals clear` during that wait, the plan state is cleared; when the wait later times out, the catch at `src/index.ts:537-544` unconditionally sets `phase: "planning"` and persists — yielding `phase: "planning"` with `planVersion: null`, a "drafting goals" widget over no plan, and "No active plan to disconnect" from `/goals clear`. Recoverable via a fresh `/goals <objective>`, and the interleaving requires issuing a command while the Ready select-loop is mid-wait, hence Low. I did not execute this interleaving; it follows from the unconditional catch and the waiter semantics. Guarding the catch on "state still belongs to this Ready attempt" (e.g. approvalId/planVersion unchanged) would close it.
---
## Assessment of documented residuals (not accepted on documentation alone)
- **F3 durable-delivery gap**: genuine and correctly scoped as open. Concretely, after an acked-but-async-failed enqueue, the supervisor waits indefinitely for a response to an instruction the worker model never saw, with no signal on either side; the recorded future UAT (inject an async enqueue rejection, assert no confirmed-delivery claim and recoverability) is the right bar. Fine to defer; not fine to call resolved — and it isn't.
- **F8 (unknown usage disables 100k compaction)**: the `?? 0` fallback (`src/supervisor-session.ts:187`) silently disables the custom compaction wherever `getContextUsage()` is unavailable, contradicting the AGENTS.md cost design with no user-visible signal. Mitigating factor I verified: the supervisor system prompt (with `planPath`) is re-appended every `before_agent_start` (:175), and approvals/checkpoints live on disk, so a fallback default-compaction does not lose the plan pointer or approval state — the consequence is cost/context-rot drift, not correctness. Still, a one-time "usage unknown; custom compaction inactive" notification would close the observability gap cheaply. Acceptable as a documented limitation; the silence is the weakest part.
- **F9 (planning/pause bash gate holes)**: accurately disclaimed as guardrail-not-sandbox. The paused-diagnostic gate (`src/index.ts:453-456`) intentionally inherits the same heuristic, including the `git diff --ext-diff` external-command hole that requires a pre-existing hostile `.git/config`. Given the threat model (trusted repo, trusted extensions), the README statement is sufficient; a hardened policy remains correctly out of scope.
- **Test-quality caveat**: beyond the fixture issue in P1, the native pair test drives only `SteerWorker`; the two-real-session `ApproveGoal → CompleteGoal` chain is still unexecuted end to end, so the F7 hash boundary and the view-freshness gate are verified only per-side (unit/flow tests) plus one real supervisor tool-list inspection. The disposition states this; I confirm it remains true at 1668c94.
## What is solid
- Shutdown/late-startup guards (`src/index.ts:180, 199-203, 210`) and the supervisor's `bootstrapping` `finally` fix are correct; the test proves no late persistence after shutdown.
- Queued pending steers when *own* readiness changes are handled correctly on both roles: republish is gated on `peerReady && this.ready` (`src/intercom.ts:158-162`), pause suppresses republication, and recovery replays exactly the unacked set from session entries. The only hole in this chain is P1's missing trigger.
- Approval binding safety (per-approvalId, head/tree/clean-worktree/goal-block-hash equality, restart invalidating old approvals) is preserved and extended by the restart flow.
- Human recovery availability while paused is real on both roles: input, read-only tools, `/model`, `/goals reconnect|restart|clear` all remain reachable; sign-off and writes fail closed.
## Summary
F1F7 are fixed as claimed, with tests and native evidence matching the dispositions. The significant new finding is **P1**: the change-gated hello reply combined with `configure()`'s peer reset makes `/goals reconnect` and Ready-retry wedge half-open precisely when readiness did not change — including the F1-on-Ready retry scenario the fixes were built for — and steers are silently dropped in that window while `steer()` reports success. P2P5 are low-severity consistency/guard gaps. Documented residuals F3/F8/F9 are honest; F3's delivery gap and F8's silent compaction-disable remain open items, not fixes.
Attribution: independent reviewer, run bdb93a2e-52f4-4a6d-bac2-7c9eb48118b5; preserved verbatim by Pi/OpenAI implementation worker.
@@ -0,0 +1,151 @@
# pi-goals supervision bug review — HEAD 2824396
> Attribution: independent delegated reviewer, run `5c8c2017-a92f-4a5f-baf6-f441f9b50495`, artifact `supervision-bug-review.md`. Findings below are preserved from that reviewer, not authored by the implementation worker. Implementation dispositions are in `20260908-review-fixes.md`.
Scope: AGENTS.md, src/{index,intercom,supervisor-session,background,role-models,approval,worker-view,herdr,prompts}.ts and tests.
Priorities: lifecycle/reload, delivery/reconnect, approval safety, autonomy failures.
Method: static review plus targeted checks against the installed `@earendil-works/pi-coding-agent` 0.84.1 and `pi-intercom` 0.13.0 sources, and one live reproduction (F1). Nothing in the repo was modified; repro scripts lived in /tmp.
Labels: **[TESTED]** = demonstrated by execution or verified against dependency source. **[CODE]** = read directly from pi-goals source; control flow unambiguous. **[INFERENCE]** = depends on behavior I could not observe.
---
## F1 — Working-phase session restore aborts halfway when the remembered role model is unavailable (Medium) [TESTED]
`src/index.ts:486-495` (`session_start`):
```ts
if (state.phase) await models.enter(...); // line 488 — can throw
planningContextPending = state.phase === "planning";
resyncReason = state.phase === "working" ? "New session." : null;
if (state.phase === "working") {
intercom.configure(state.approvalId!, "worker", ctx); // line 492 — skipped on throw
startWorkerTimers(ctx); // line 493 — skipped
}
updateWidget(ctx); // line 495 — skipped
```
`RoleModels.enter` (`src/role-models.ts:30-40`) throws `worker model is unavailable...` when the saved `.pi/pi-goals/models/worker.json` names a model that `ctx.modelRegistry.find` can no longer resolve (provider removed, auth expired). That is a realistic state: the feature exists precisely to remember models across sessions, and model availability changes over time.
Reproduction (executed): mock Pi host, persisted state `{phase: "working", approvalId: "appr-1", planVersion: 1}`, saved worker model `gone/expired`, `modelRegistry.find → undefined`. Result:
```
session_start handler threw: worker model is unavailable. Select an available model with /model, then retry. Saved choice was not replaced.
intercom.configure called during working-phase restore: false
```
Consequences after the throw:
- Intercom binding is never restored: no hello, `peerReady` stays false, every subsequent `publishWorkerView` silently records views with an empty binding and never publishes them.
- The hourly view timer never starts.
- Widget is not updated.
- On a planning-phase resume, `planningContextPending` is never set, so the planning snapshot is never re-injected.
- Pi catches per-handler errors (`ExtensionRunner.emit`, runner.js:587-601) and routes them to `emitError`, so the user sees at most an extension-error diagnostic. The error text says "then retry", but no code path retries the restore — `session_start` does not re-run when the user picks a new model.
This overlaps F2: the session resumes looking normal while supervision is dead.
## F2 — No supervisor liveness check on worker resume; dead supervisor pane is invisible (Medium) [CODE]
`src/index.ts:486-495`: on resume with `phase === "working"`, the worker calls `intercom.configure` (which sends one hello) and starts timers. There is no `waitReady`, no Herdr pane probe, and no timeout. If the supervisor pane died while the worker session was closed:
- `GoalIntercom.view()` (`src/intercom.ts:82-88`) records the view and skips publishing because `connected` is false — silently. No notify anywhere on this path.
- `updateWidget` still renders "· supervised" (`src/index.ts:249`).
- The worker system prompt tells the model to "Stop when a goal appears complete so the supervisor can inspect a settled worker view" — it will stop and wait for an approval that can never arrive. `CompleteGoal` then fails with "no matching supervisor approval checkpoint" with no hint that the supervisor is gone.
- The only reconnect wait (`waitReady`) lives in `startSupervisor`, which is unreachable from the working phase: the Ready menu only renders when `state.phase === "planning"` (`src/index.ts:417`). The only recovery is `/goals clear` (drops plan linkage) or `/goals <new objective>` (new plan version, old plan orphaned). There is no "restart supervisor" path that preserves the current plan.
[INFERENCE] Whether the broker notices the dead pane while the worker is offline is irrelevant here — the worker has no handler for "peer never came back after resume" in either case.
## F3 — `onSteer` rejection throws before ack: unacked steer replays forever, error notification each reconnect (Medium-low) [CODE]
`src/index.ts:113-116`:
```ts
intercom.onSteer = (instruction) => {
if (state.phase !== "working") throw new Error("Worker plan is not active; instruction rejected.");
pi.sendUserMessage(`[supervisor] ${instruction}`, { deliverAs: "steer" });
};
```
`src/intercom.ts:167-174` (worker steer branch):
```ts
this.onSteer(message.text!); // throws → everything below skipped
this.received.add(message.id);
this.record("in", message);
this.publish({ ... kind: "received" ... });
```
Because `onSteer` runs before dedupe/record/ack, a steer that arrives when the plan is not active (plan just completed — `publishWorkerView` sets `phase: null` at index.ts:213; or `/goals clear`; or a supervisor that ignores "stop issuing instructions") is:
1. never acked — the supervisor keeps it in `pending` and republishes it on every `changed` hello (`src/intercom.ts:143-149`), so each supervisor reconnect re-fires the throw;
2. never recorded — so the dedupe set can't suppress it;
3. surfaced only as `Goal Intercom error: ... instruction rejected.` notifications in the worker pane; the supervisor's `SteerWorker` result says only "Receipt and execution are not confirmed", so the supervisor model cannot distinguish "rejected" from "lost" and may re-send, producing one error notification per attempt.
Related at-least-once window: a crash between `pi.sendUserMessage` (persisted) and `record("in", ...)` causes the same `[supervisor] ...` instruction to be delivered twice after resume. Narrow, but the fix is the same: record/ack before invoking `onSteer`, and add a rejection result back to the supervisor instead of throwing.
## F4 — Stale `supervisorPaneId` makes every Ready retry block for 5 minutes (Medium-low) [CODE]
`src/index.ts:163-166`:
```ts
if (state.supervisorPaneId && state.approvalId) {
intercom.configure(state.approvalId, "worker", ctx);
await intercom.waitReady(); // default 300_000 ms, intercom.ts:73
return;
}
```
This reconnect path is taken after a partial `startSupervisor` failure — e.g. `herdr pane split` succeeded (pane id persisted via the `onOpened` callback at index.ts:174-176) but `herdr pane run` failed (`src/herdr.ts:76-84`), or `models.enter("worker")` threw after the supervisor started. The pane is dead or the supervisor process exited, but the retry never asks Herdr whether the pane exists; it blocks the `agent_settled` handler (and therefore the planning menu) until the 5-minute `waitReady` timeout. Every subsequent Ready repeats the 5-minute hang. `/goals clear` recovers (`closeSupervisorPane` tolerates `NOT_FOUND`/`PANE_GONE`, herdr.ts:60-66), but the timeout error message ("inspect its pane") does not say so.
Also note the same 5-minute blocking wait applies to the supervisor's first-time initial compaction (`supervisor-session.ts:133-160`); a slow compaction of a large fork produces the same opaque worker-side failure, though that path self-heals on retry.
## F5 — The "read-only" supervisor gets pi-intercom's full `intercom` tool (Low-medium, approval/authority surface) [TESTED against pi-intercom source]
The supervisor runs with `--no-extensions -e src/index.ts` (`src/herdr.ts:48-58`), so pi-intercom is never an installed extension in the supervisor session, so `GoalIntercom.loadIntercom` (`src/intercom.ts:189-200`) always dynamically imports it. `intercom(api)` executes pi-intercom's full default export, which registers:
- the `intercom` tool: "Send a message to another pi session running on this machine" (pi-intercom/index.ts:2088),
- `/intercom`, `/intercom-id`, `/alias` commands (pi-intercom/index.ts:2802-2812).
The supervisor's read-only enforcement filters only `WRITER_TOOLS` (`src/supervisor-session.ts:13`, applied at session_start line ~124 and in bootstrap), so `intercom` remains an active tool for the supervisor model. Effect: the supervisor — prompted as read-only with `SteerWorker`/`ApproveGoal` as its only actuators — can message arbitrary Pi sessions on the machine, including the user's other sessions, outside the auditable SteerWorker channel whose renders the tests assert are visible. Severity depends on how much you trust the supervisor model; the capability contradicts the stated design ("all supervisor thinking and messages should be visible", AGENTS.md).
Mitigation would be filtering `intercom` (and any other messaging tools) out of the supervisor's active set, or passing a `registerTool` denylist through the `loadIntercom` proxy (it currently only wraps `on`).
## F6 — `hasEvidenceEntry` accepts placeholder or unrelated nested bullets as evidence (Low) [CODE]
`src/supervisor-session.ts:41-60`. The inline placeholder `(empty until sign-off)` is rejected, but when the inline value is empty the child scan returns true for *any* deeper-indented bullet with nonblank text — including `- (empty until sign-off)` written as a child bullet, or any stray nested line. So this block passes the gate:
```
1. [ ] goal: x
- evidence:
- (empty until sign-off)
```
The supervisor model is instructed to actually read the evidence, so this is a heuristic floor rather than the real defense; still, the placeholder check should apply to child bullets too.
## F7 — Approval goal block for the last goal runs to EOF; tail edits spuriously invalidate approvals (Low) [CODE]
`goalBlock` (`src/approval.ts:36-53`) slices from the goal line to the next goal line *or EOF*. For the last goal, the block includes `## Log`, `## Interview`, and the Appendix. `hashGoalBlock` therefore changes if the worker appends a manual `## Log` line (which the prompts encourage — `stamp()` exists for that) between `ApproveGoal` and `CompleteGoal`, producing "no matching supervisor approval checkpoint" and forcing a fresh review. Fail-closed, so not a safety bug; it is an availability/UX trap in the normal approve → log → sign-off rhythm. Consider ending the block at the fold (`## Log`) like `foldPlan` does.
## F8 — Supervisor 100k compaction silently disabled when `getContextUsage` is unavailable (Low) [INFERENCE]
`src/supervisor-session.ts:141-143`: `if (compacting || (ctx.getContextUsage()?.tokens ?? 0) < COMPACT_AT_TOKENS) return;`. If `getContextUsage()` returns undefined (RPC/print modes or any runtime where it isn't wired), tokens coerce to 0 and the supervisor never self-compacts, contradicting the AGENTS.md cost design ("compacts every 100k"). Pi's own auto-compaction will eventually fire without the custom instructions that protect the plan pointer and approval state. I could not confirm whether `getContextUsage` is ever undefined in the Herdr-pane interactive mode; in the test mock it is explicitly set.
## F9 — Plan-mode bash gate: residual holes are narrow but worth noting (Low) [CODE/INFERENCE]
`isPlanningReadOnlyCommand` (`src/index.ts:566-574`) is otherwise tight (blocks pipes/redirects/backticks/`$`, splits on `&&`/`;`, whitelists verbs, special-cases `--output`, `find -delete/-exec...`, mutating `git branch`). Residual issues:
- The whitelist allows `git log/show/diff` with *arbitrary* flags. `git diff --ext-diff` / `git log --ext-diff` execute the command configured in `diff.external`/`GIT_EXTERNAL_DIFF`. Env-prefix assignments are blocked (the part must start with a whitelisted verb), so this requires a pre-existing malicious `.git/config` in the target repo. [INFERENCE] that any real repo would have this.
- Plan mode blocks only `edit`/`write` by name (`PLAN_MODE_BLOCKED_TOOLS`, index.ts:34). Any other extension's mutating tool (e.g. a `process`/background-task launcher, `apply_patch`-style tools — the supervisor's own `WRITER_TOOLS` list at supervisor-session.ts:13 acknowledges several) is not blocked in plan mode. In the worker session all user extensions are loaded, so this depends on the user's setup. [INFERENCE]
## Non-findings (checked, working as intended)
- **Shutdown latch**: `GoalIntercom.stopped = true` on `session_shutdown` looked dangerous for in-process `/resume`, but Pi tears down and re-creates the ExtensionRunner (and therefore all extension instances) on resume/new/fork/reload (agent-session-runtime.js:102-112, agent-session.js:2053-2073). [TESTED against pi source]
- **Handler ordering**: Pi runs handlers sequentially in registration order and awaits them (runner.js:579-604), so `GoalIntercom`'s constructor-registered `session_start` (channel load) completes before index.ts's `configure` → hello. Per-handler errors are swallowed into `emitError` (this is why F1 is silent). [TESTED against pi source]
- **ApproveGoal freshness gates**: the `view === newest.text` equality check is sound — `sendUserMessage` stores the text verbatim (agent-session.js:1106-1133), `latestView` is set before `onView` fires, and any newer queued view makes the comparison fail closed. Worker "stopped"/`backgroundQuiet` are extension-computed (`ctx.isIdle()`, `backgroundState`), not model-controlled, so the worker model cannot spoof a stopped/quiet view. `backgroundState` fails closed ("unknown" → not quiet) when an installed tracker doesn't answer, and distinguishes missing providers (background.ts, covered by test/background.test.ts).
- **Approval checkpoint binding**: head/tree/clean-worktree/goal-block-hash equality plus per-`approvalId` binding and `beginReview`'s deletion of prior approvals make approval replay across plans or commits infeasible; `.pi/plan`, approvals, and model prefs are correctly excluded from the dirtiness check relative to repo root (`approval.ts:20-34`).
- **Steer/view redelivery after restart**: pending steers and `received` dedupe survive restart via session-entry replay (`intercom.ts:54-68`) and are covered by test/intercom.test.ts; ack cursors are monotonic.
- **Two-peer guard**: the "Two peers claim this supervision binding" throw fires before any state mutation and repeats harmlessly; it can wedge only if the broker failed to emit `session_left` for the previous peer, which the broker does send on disconnect/reregister (broker.ts:327,540).
## Test-coverage gaps relevant to the above
- No test exercises F1 (resume with unavailable remembered model).
- No test exercises a resumed worker whose supervisor never answers (F2) — the intercom fixture auto-replies to hellos, so `connected` is always true in tests.
- The native end-to-end test (test/native-intercom.test.ts) drives `SteerWorker` only; the `ApproveGoal` → approval file → `CompleteGoal` chain has never run through two real Pi sessions, so F7-class friction and the `view === newest.text` gate are unverified end to end.
@@ -0,0 +1,62 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 6ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 3ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 40ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 0ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 14ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 7ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 4ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 2ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 1ms
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 221ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 38ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 21ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 24ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 20ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 20ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 24ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 49ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 6ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 25ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 58ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1384ms
Test Files 11 passed (11)
Tests 37 passed (37)
Start at 16:31:10
Duration 1.67s (transform 1.31s, setup 0ms, import 3.59s, tests 2.00s, environment 1ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 21 files in 67ms. No fixes applied.
@@ -0,0 +1,81 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 2ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 1ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 3ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 4ms
stdout | test/role-models.test.ts > remembers each role without automatic switching overwriting another role
Role preferences restored: planning=planner, worker=small-worker, supervisor=astra; restore events did not overwrite the choice.
✓ test/role-models.test.ts > remembers each role without automatic switching overwriting another role 7ms
✓ test/role-models.test.ts > fails on an unavailable remembered model without replacing the choice 4ms
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 5ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 1ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 3ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 3ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 30ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 6ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 6ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 2ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 0ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 206ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 34ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 21ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 25ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 23ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 23ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 27ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 163ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 8ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 27ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 3ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 59ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1226ms
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2314ms
Test Files 15 passed (15)
Tests 46 passed (46)
Start at 16:58:17
Duration 2.73s (transform 2.47s, setup 0ms, import 5.82s, tests 4.28s, environment 2ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 28 files in 21ms. No fixes applied.
> @wassname2/pi-goals@0.2.2 build
> tsc
@@ -0,0 +1,17 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --run test/native-intercom.test.ts --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2264ms
Test Files 1 passed (1)
Tests 1 passed (1)
Start at 16:52:40
Duration 2.43s (transform 26ms, setup 0ms, import 56ms, tests 2.27s, environment 0ms)
@@ -0,0 +1,24 @@
# Initial delegated-worker test failure — Pi/OpenAI
The first implementation check ran `npm run typecheck && npm test` inside the delegated worker's inherited environment (`PI_SUBAGENT_CHILD=1`). Typecheck passed. At that point the suite reported:
```
Test Files 2 failed | 13 passed (15)
Tests 8 failed | 38 passed (46)
```
Representative actual output from that run (18:39:14):
```
FAIL test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only
TypeError: Cannot read properties of undefined (reading 'handler')
at flow.commands.get("goals").handler("first objective", flow.ctx)
FAIL test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn
Error: Test timed out in 15000ms.
```
Diagnosis: the production `isMainSession()` deliberately excludes subagent children. Consequently the mock host never registered `/goals`, and the real RPC test process inherited the child flag and did not register it either. This was not treated as a passing test and no product guard was removed to conceal it.
Exact corrected test command: `env -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE npm test`.
That rerun passed all 46 then-existing tests. Subsequent added regressions also passed. The final complete command and unabridged final output are saved in `20260908-review-fixes-validation.txt`; it uses the same two-variable isolation. All role-specific tests still explicitly configure their intended role. No live user session's environment or settings were changed.
@@ -0,0 +1,4 @@
worker: 21 events parsed; 0 errors; stderr empty
Worker user-message event contains exact instructed text.
supervisor: 21 events parsed; 0 errors; stderr empty
Supervisor outbound/ack ID matched: 780f7dac-e4e5-4351-b890-0684a42de681. This is adapter handling, not durable queue confirmation.
@@ -0,0 +1,93 @@
COMMAND: env -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE PI_GOALS_EVIDENCE_DIR="$PWD/slop/reviews/review-fixes-native" npm test -- --reporter=verbose && npm run typecheck && npm run lint && npm run build && git diff --check
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 2ms
✓ test/approval.test.ts > hashes only the current goal, excluding the log, interview, and their historical goal text 3ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 3ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 0ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 1ms
stdout | test/role-models.test.ts > remembers each role without automatic switching overwriting another role
Role preferences restored: planning=planner, worker=small-worker, supervisor=astra; restore events did not overwrite the choice.
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 3ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 6ms
✓ test/role-models.test.ts > remembers each role without automatic switching overwriting another role 7ms
✓ test/role-models.test.ts > fails on an unavailable remembered model without replacing the choice 4ms
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 3ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 1ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 3ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 3ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 25ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 5ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 3ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/intercom.test.ts > does not acknowledge a synchronous handoff failure, and retries the instruction 1ms
✓ test/intercom.test.ts > detaches a completed binding and ignores its late advice without replay errors or false acceptance 1ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 2ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 226ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 45ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 21ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 26ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 19ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 22ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 23ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 42ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/goals-flow.test.ts > restores working linkage even when its remembered model is unavailable, and supports explicit recovery 19ms
✓ test/goals-flow.test.ts > restores planning linkage even when its remembered model is unavailable, and supports explicit recovery 18ms
✓ test/goals-flow.test.ts > shows a missing resumed supervisor, pauses writes, and automatically unpauses when that peer returns 19ms
✓ test/goals-flow.test.ts > times out stale Ready retries in five seconds, without replacing the pane automatically 27ms
✓ test/goals-flow.test.ts > explicitly restarts only the tracked pane, keeps the plan, and invalidates old approval binding 22ms
✓ test/goals-flow.test.ts > does not persist startup results or launch work after session shutdown 19ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 8ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 28ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 19ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 89ms
✓ test/supervisor-session.test.ts > blocks the general intercom actuator even if enabled after startup 2ms
✓ test/supervisor-session.test.ts > keeps a supervisor unready after model restoration failure, then recovers explicitly without substituting a model 2ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1303ms
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2338ms
Test Files 16 passed (16)
Tests 57 passed (57)
Start at 18:57:11
Duration 2.57s (transform 1.87s, setup 0ms, import 4.26s, tests 4.46s, environment 2ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 29 files in 28ms. No fixes applied.
> @wassname2/pi-goals@0.2.2 build
> tsc
+38
View File
@@ -0,0 +1,38 @@
# Independent review fixes — Pi/OpenAI implementation worker
Baseline: `2824396a711ed56bd462742ab22620df44e5624f`.
Original independent review: [preserved review and attribution](20260908-independent-supervision-bug-review.md), run `5c8c2017-a92f-4a5f-baf6-f441f9b50495`.
The parent approved explicit `/goals reconnect` and `/goals restart`, with human input and read-only diagnosis available while paused. No existing user pane/session was inspected, operated, restarted, or closed. All Herdr recovery operations in this work used mocks. No additional reviewer or subagent was launched by this worker.
Read AGENTS.md and installed Pi extension documentation covering session replacement/shutdown, sequential events, model selection, input, command context, tool gates, compaction and context usage before editing extension lifecycle code. The native tests use repository-local Pi **0.84.1**; the parent host's 0.85.1 version is not the test executable's version.
## Finding dispositions
| Finding | Disposition and concrete proof |
| --- | --- |
| F1: unavailable remembered model aborts restore | Confirmed and fixed. Planning injection and worker binding/timers initialize independently of model selection. A failure leaves an explicit paused widget and gates implementation/sign-off, not a partially initialized normal worker. No fallback model is selected. The worker does not announce readiness until model restoration succeeds. `/model` followed by `/goals reconnect` retries the same plan. Added flow reproductions for both working/planning restoration and supervisor model recovery. Tests assert no `setModel` on unavailable lookup, no ready hello, preserved preferences/binding/version, retained human input, allowed diagnostic reads, blocked writes/sign-off and successful explicit recovery. |
| F2: resumed worker silently has no supervisor | Confirmed and fixed. Connection changes update the widget immediately; absence on restore warns after five seconds. Writes/sign-off are gated while disconnected; human prompts, diagnostic reads and recovery commands remain available. Returning peers clear the connection pause automatically. Explicit restart preserves the working plan and replaces only its tracked pane with a new approval binding. Tests exercise a never-answering peer, later hello, exact owned-pane close, unchanged plan/version, removed old checkpoint, and no automatic pane replacement. |
| F3: inactive-plan steer throws/replays | Confirmed; lifecycle cause addressed without premature acceptance. Completed, cancelled or cleared plans detach their binding and announce not-ready; stale advice is ignored without invoking delivery or acknowledging it. Tests cover completion/clear not accepting advice or restarting, transport detach, and a *synchronous handoff* failure remaining unrecorded/unacked until retry succeeds. **Delivery gap remains:** Pi 0.84.1 `dist/core/agent-session.js:18551862` implements ExtensionAPI.sendUserMessage as a void wrapper calling async `this.sendUserMessage(...).catch(emitError)`; `:11061133` awaits `prompt` internally. The adapter therefore cannot observe durable enqueue success. An async enqueue error may occur after the ack and suppress replay even though the model never received the instruction. A crash between handoff and recording can instead duplicate it. Pending transport messages retain at-least-once retry semantics, but end-to-end durable/at-least-once/exactly-once model delivery is NOT guaranteed. Recording/acking before even the synchronous handoff would worsen loss and was deliberately NOT implemented. Parent explicitly accepted documenting this deeper limitation rather than expanding the protocol in this commit. README and the code comment distinguish adapter handling from persistence/model receipt/execution. |
| F4: stale pane causes repeated five-minute Ready waits | Confirmed and fixed. Existing-pane Ready/reconnect waits are five seconds, with explicit reconnect/restart guidance. First-time launch retains the five-minute compaction allowance. Failed `pane run` retains the pane ID for inspection and reports it. No automatic probe-driven kill/replacement of a possibly healthy slow supervisor. Planning restart clears its failed tracked pane for the next Ready; working restart forks a replacement immediately. Test simulates split success/run failure and two Ready attempts, and proves one launch, zero automatic closes, and a five-second retry. Startup results arriving after shutdown are not persisted and do not launch worker work. |
| F5: general intercom tool available to supervisor | Confirmed and fixed. `intercom` is removed alongside writing tools before readiness and blocked at tool-call time even if later re-enabled. `SteerWorker` remains available. Both mocked gate tests and the real native pair test assert this; the latter inspects the actual supervisor model request's tool list. |
| F6: nested placeholder evidence accepted | Confirmed and fixed. The same exact `(empty until sign-off)` rejection applies to inline and child bullets. Tests exercise both through `ApproveGoal`, assert no approval file, then confirm actual nonblank evidence still passes. This is a presence floor, not a semantic evidence judge; unrelated nonblank prose still requires supervisor judgment. |
| F7: last goal hash includes Log/Interview | Confirmed and fixed. The canonical block ignores the Log and stops at the next goal or top-level section. Trailing section-separator whitespace is excluded. Unit tests cover log history containing duplicate goal text, interview, next goal, and actual goal edits still invalidating the hash. The flow test appends a manual Log entry between approval and CompleteGoal and still succeeds. Previously recorded hashes may require a fresh approval after upgrade (fail closed). |
| F8: unknown usage disables 100k compaction | Assessed; no speculative estimator added. Installed `agent-session.js:getContextUsage()` returns undefined without a usable model/window and explicitly returns `tokens: null` after compaction until a later assistant usage sample exists. Native RPC tests have valid usage; RPC mode itself is not evidence of permanent unavailability. Existing unknown handling avoids immediate repeat compaction. Persistent unavailable usage still prevents the custom 100k trigger; this remains a documented limitation, not claimed fixed. |
| F9: planning read-only guard residuals | Confirmed as a guardrail limitation, not fixed by broad tool/shell policy changes in this task. Planning still explicitly gates edit/write and selected bash commands, not every installed extension actuator. Git read commands can invoke configured external diff/textconv programs. Paused diagnostic bash uses this same heuristic, so trusted repository configuration and extensions are required; it is NOT a security sandbox. README now states this. A hardened shell policy or comprehensive planning tool allowlist needs separately scoped review; no claim of airtight isolation is made. |
## Validation and inspected evidence
- [Full final command/output](20260908-review-fixes-validation.txt): **57 tests passed in 16 files**, typecheck, lint, build and `git diff --check` passed.
- Exact test environment isolation: `env -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE PI_GOALS_EVIDENCE_DIR="$PWD/slop/reviews/review-fixes-native" npm test -- --reporter=verbose`. This runs main-session tests as a main session, while explicit role tests still select their role.
- [Initial child-environment failure](20260908-review-fixes-initial-validation.md): recorded the original failure (8 failed/38 passed), cause and exact corrected command. It was not omitted or counted as a pass.
- Inspected [worker native events](review-fixes-native/worker-events.jsonl) and [supervisor native events](review-fixes-native/supervisor-events.jsonl): the worker received `[supervisor] Read the real outputs before declaring completion.`; supervisor out and ack records share the same instruction ID in the saved run. Both stderr files are empty; neither event log contains an error/failed-response/error-notification record.
- Tests preserve human recovery/input while paused, peer-return unpause, and clear/complete not receiving stale advice or reopening supervision. Shutdown guards prevent late startup results from writing the disposed runtime.
## Remaining acceptance limits
**Priority residual: F3 durable delivery confirmation is still open.** Required UAT for a future correlated-receipt design: force an asynchronous Pi enqueue rejection after the adapter returns; the supervisor must not report confirmed model delivery and the instruction must remain recoverable. The current receipt does not make that promise.
These fixes still need the parent's independent post-change review. The native pair uses a deterministic local model and a transport-only worker fixture; it proves routing/context retention and supervisor tool exposure, not good judgment, cost savings, rendered Herdr behavior, or the full two-native-session ApproveGoal → CompleteGoal chain. Full fresh-shell supervisor role restoration without launcher environment remains unverified. An already-created pane can remain for inspection if shutdown interrupts startup; the fix avoids stale context use rather than silently operating such a pane. Background work is not killed by recovery, and unregistered detached work remains outside tracker coverage.
No changes were pushed by this implementation worker.
@@ -0,0 +1,73 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 3ms
stdout | test/role-models.test.ts > remembers each role without automatic switching overwriting another role
Role preferences restored: planning=planner, worker=small-worker, supervisor=astra; restore events did not overwrite the choice.
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 2ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 6ms
✓ test/role-models.test.ts > remembers each role without automatic switching overwriting another role 7ms
✓ test/role-models.test.ts > fails on an unavailable remembered model without replacing the choice 6ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 0ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 5ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 3ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 2ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 30ms
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 2ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 0ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 2ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 0ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 1ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 0ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 222ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 36ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 24ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 26ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 21ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 21ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 19ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 47ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 7ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 22ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 2ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 3ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 5ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 49ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1427ms
Test Files 14 passed (14)
Tests 45 passed (45)
Start at 16:49:24
Duration 1.79s (transform 1.51s, setup 0ms, import 4.33s, tests 2.03s, environment 1ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 26 files in 62ms. No fixes applied.
@@ -0,0 +1,27 @@
INITIAL VIEW
The worker stopped.
review trigger: settled
source session: /isolated/worker.jsonl
worker model: test/worker
latest human direction:
Modal does not use our GPU.
tool calls with no result: none
tracked background work: processes: 0; subagents: 0; unregistered work is not tracked
new worker transcript (initial or reset view):
I am waiting for the local queue.
AFTER ACKNOWLEDGMENT
The worker stopped.
review trigger: settled
source session: /isolated/worker.jsonl
worker model: test/worker
latest human direction:
Modal does not use our GPU.
tool calls with no result: none
tracked background work: processes: 0; subagents: 0; unregistered work is not tracked
new worker transcript since the last acknowledged view:
The command launches a Modal remote GPU; local default stays paused.
@@ -0,0 +1,68 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run --reporter=verbose
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
✓ test/worker-view.test.ts > keeps human direction and source location while sending only new messages 6ms
✓ test/worker-view.test.ts > restarts after compaction and does not report historical tool calls as active 0ms
✓ test/worker-view.test.ts > bounds serialized Unicode and quoted logs while marking omissions 2ms
✓ test/background.test.ts > reports tracked running work, rather than equating idle agent with finished jobs 2ms
✓ test/background.test.ts > distinguishes missing providers from an unavailable installed tracker 5ms
✓ test/package-agent.test.ts > package manifest > includes the extension without registering a packaged subagent 2ms
✓ test/intercom.test.ts > pi-intercom transport > receives exact advice once, acknowledges it and rejects unrelated peers 5ms
✓ test/intercom.test.ts > pi-intercom transport > restores an unacknowledged steer on reconnect and stops replay after acknowledgment 3ms
✓ test/intercom.test.ts > pi-intercom transport > advances the incremental overview only after acknowledgment 1ms
✓ test/intercom.test.ts > pi-intercom transport > cancels a readiness wait on shutdown 1ms
✓ test/herdr.test.ts > supervisor pane command > forks the planning session with pi-goals owning its Intercom dependency 2ms
✓ test/herdr.test.ts > supervisor pane command > accepts Herdr's text version output and stale pane cleanup 26ms
✓ test/prompts.test.ts > planning prompt > requires fact finding or a focused question before a goal 2ms
✓ test/prompts.test.ts > planning prompt > restores the same rule after compaction 1ms
✓ test/prompts.test.ts > planning prompt > anchors work and sign-off to the user-visible result 0ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > creates ## Log at EOF when absent 1ms
✓ test/append-log.test.ts > appendLog (the extension's only plan-file write) > appends after the last existing log line, before any following header 0ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > keeps the title, user voice and goals 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > drops the log, the learnings and the unlimited appendix 1ms
✓ test/fold.test.ts > foldPlan (current goals are above ## Log; durable memory is below it) > returns the whole plan when there is no ## Log yet (a fresh draft) 0ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > lists the active goal's open and in-progress subtasks, stopping at the next goal 1ms
✓ test/fold.test.ts > openSubtasks (the widget shows the next action, so the plan IS the task list) > does not leak subtasks from the goal below 1ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > ticks the exact-matching goal line, case-insensitive, leaving subtasks alone 2ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null on wording drift (fuzzy matching is the judge's job, not TypeScript's) 1ms
✓ test/tick-goal.test.ts > tickGoal (sign-off ticks the goal; agent only ticks on wording drift) > returns null when the subject matches more than one goal line 0ms
stdout | test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker
Intercom broker: readiness confirmed; exact worker view and supervisor advice received.
✓ test/intercom-broker.test.ts > exchanges readiness, views and exact advice over a real isolated pi-intercom broker 226ms
✓ test/goals-flow.test.ts > /goals flow > reports actual idle state, invalidates stopped views on start, and stops completed plans 45ms
✓ test/goals-flow.test.ts > /goals flow > preserves drafts, records the interview, and keeps planning read-only 17ms
✓ test/goals-flow.test.ts > /goals flow > forks a visible supervisor on Ready and keeps the main session as worker 20ms
✓ test/goals-flow.test.ts > /goals flow > starts work only after the supervisor launcher resolves 18ms
✓ test/goals-flow.test.ts > /goals flow > delivers an Intercom instruction to the worker 22ms
✓ test/goals-flow.test.ts > /goals flow > closes the supervisor on clear but keeps the plan file 20ms
✓ test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block 44ms
✓ test/goals-flow.test.ts > process role > keeps subagent children and visible supervisors out of the worker extension 0ms
✓ test/supervisor-session.test.ts > visible supervisor session > restores monitoring and read-only tools without replaying persisted views 5ms
✓ test/supervisor-session.test.ts > visible supervisor session > renders all advice in real Pi tool rows, including collapsed and restored rows 20ms
✓ test/supervisor-session.test.ts > visible supervisor session > asks for judgment and useful recaps without inventing instructions 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes readiness only after removing writing tools 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > compacts a large planning fork before writing readiness 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > does not become ready when initial compaction fails 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > writes a durable worker instruction 1ms
✓ test/supervisor-session.test.ts > visible supervisor session > records approval only from a stopped view with evidence and no active work 49ms
✓ test/rpc-review.test.ts > RPC review flow > opens Refine's editor before it starts the revision turn 1197ms
Test Files 13 passed (13)
Tests 43 passed (43)
Start at 16:41:18
Duration 1.43s (transform 927ms, setup 0ms, import 3.00s, tests 1.77s, environment 1ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 24 files in 19ms. No fixes applied.
@@ -0,0 +1,72 @@
# Review against user intent
## Follow-up: code fixes, full goal still unproven
Implemented directly after the subagent runner failed and the user authorized direct work. The tests now exercise full advice in real Pi tool components (collapsed, expanded, restored, streaming arguments), emitted thinking/text display, resume without replay of persisted views, latest-view coalescing, actual idle/busy status, stale-view approval rejection, and stopping completed-plan timers. The supervisor prompt now asks for a brief evidence-based progress assessment and useful judgment instead of instruction-only reviews. Background job status is explicitly unmeasured; approval still requires the supervisor to inspect job evidence when relevant.
[Saved validation output](20260908_supervision-fixes-validation.txt):
> Tests 34 passed (34)
> resumed: deliveredViews=0, activeTools=read, readyReceipt=true
> interval view without any work: The worker stopped.
Typecheck and lint also succeeded in that log. The reproduction script now asserts the corrected behavior; the original reproduction output below is retained as historical evidence. Readiness is cleared on startup and normal shutdown, but it is not a heartbeat or proof of worker receipt. The review here is my own source/diff review, not the independent review that failed to launch. Existing user panes and the separate pi-supervise worktree were not modified.
Remaining acceptance: a real isolated two-pane run with the intended model pair, observed useful advice and worker response, plus measured token/cost totals. Prompt assertions do not establish judgment quality. No full-goal completion is claimed.
-- Pi/OpenAI
## Original review
Verdict at `06794bf`: not achieved.
Reviewed `experiment/goals-owned-supervision` at `4ebb4d1` against [AGENTS.md](../../AGENTS.md#user-intent-for-this-branch). This is a source review and isolated runtime reproduction by Pi/OpenAI, not an independent model review or a real two-pane acceptance test. No existing session or pane was operated.
The overnight `goals-supervisor-01a040d0` transcript used the older pi-supervise/intercom implementation. It is not runtime evidence for this mailbox branch. The uncommitted display patch in `/tmp/pi-supervise-visible-advice` is also separate from this branch and was not counted as completed work.
## Findings
1. **P1: the supervisor's actual advice is still hidden by the default tool-call display.** `src/supervisor-session.ts:157-169` registers `SteerWorker` without a call renderer and returns only a receipt. This fails the user's explicit visibility requirement. Normal emitted assistant text/thinking uses Pi's own display; the local setting already has `hideThinkingBlock: false`. That does not reveal advice inside unrendered tool arguments.
Observed in the isolated harness:
> steer: renderCall=undefined, result=Worker instruction 1 recorded.
2. **P1: supervisor resume loses monitoring and read-only tool selection.** `src/supervisor-session.ts:94-107` returns when it finds the persisted bootstrap marker, before starting the new process's polling timer or removing write tools. `ready.json` remains present, so the receipt does not identify this loss of supervision. The harness starts, shuts down, then registers a new extension instance using the saved entries and default tools:
> fresh: deliveredViews=1, activeTools=read, readyReceipt=true
> resumed: deliveredViews=0, activeTools=read,write,bash, readyReceipt=true
This reproduces a branch bug; it is not a diagnosis of the different overnight implementation.
3. **P1: periodic views can tell the supervisor an idle worker is running.** `src/index.ts:201-203` publishes an interval view without checking idle state. `src/worker-view.ts:45` derives worker status from the review trigger, not actual execution. This undermines decisions about whether continuation is needed.
> interval view without any work: The worker is still working.
4. **The intended judgment and recap behavior is not established.** The current supervisor prompt (`src/supervisor-session.ts:70-73`) emphasizes:
> Use SteerWorker to give one concrete instruction when work is incomplete.
Most of the remaining prompt concerns approval checks. It does not request the user's short assessment of progress, independent perspective, or explanation of a recommendation. This is a mismatch in emphasis, not proof that Astra cannot exercise judgment. Neither minimal thinking nor the requirement to use a steer tool establishes a cause of poor advice.
5. **Low-cost, useful supervision remains untested.** `src/worker-view.ts:41-46` repeats the last compaction summary and up to 12,000 characters from recent messages; it does not make incremental views or measure usefulness/cost. The RPC test (`test/rpc-review.test.ts:51-52`) tests Refine/editor ordering with a deterministic model, not a cheaper worker benefiting from an expensive supervisor. Passing it cannot establish the intended economic or behavioral outcome.
## What is present
- Herdr two-pane launch with an explicit planning-session fork: `src/herdr.ts:49-86`.
- Separate supervisor model selection via `/goals model`; the worker keeps its model. The cheaper-worker/more-expensive-supervisor arrangement is possible but not established by default or validated on a task.
- Initial context compaction above 20k and subsequent compaction at 100k: `src/supervisor-session.ts:8-10,113-155`. This broadly meets the request for compaction around 150k or similar; the exact threshold is not the main gap.
- Direct canonical plan path in the supervisor prompt and worker resynchronization after compaction.
- Settle, 50-turn, and hourly review triggers. Reliable continuation is incomplete because of the resume/status defects above.
## Acceptance still needed
First make the advice visible and correct resume/status behavior. Then run one bounded task in separate test panes with the intended model pair. Save the rendered advice, worker receipt, a useful progress assessment or correction, continuation after compaction/resume, and measured token/cost totals. Judge the content of the advice, not the number of messages or merely successful delivery. Do not use the user's working panes for this test.
The transport rewrite is an implementation choice, not the user's goal.
## Reproduction
The mailbox reproduction script is historical; retrieve it at commit `386305a`. The Intercom migration removes that implementation. Current transport checks are in `test/intercom.test.ts` and `test/intercom-broker.test.ts`.
[Saved output](20260908_supervisor-intent-reproduction.txt) records the exact observations quoted above. The harness uses only temporary mailbox files and mocked Pi lifecycle events; it neither launches Pi nor contacts another session. It asserts the currently observed failure, not desired behavior.
-- Pi/OpenAI
@@ -0,0 +1,26 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 9 passed (9)
Tests 34 passed (34)
Start at 10:49:05
Duration 1.34s (transform 639ms, setup 0ms, import 2.76s, tests 1.68s, environment 1ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 17 files in 20ms. No fixes applied.
fresh: deliveredViews=1, activeTools=read, readyReceipt=true
steer: renderCall=function, result=Worker instruction 1 recorded. Worker receipt and execution are not confirmed.
resumed: deliveredViews=0, activeTools=read, readyReceipt=true
interval view without any work: The worker stopped.
@@ -0,0 +1,4 @@
fresh: deliveredViews=1, activeTools=read, readyReceipt=true
steer: renderCall=undefined, result=Worker instruction 1 recorded.
resumed: deliveredViews=0, activeTools=read,write,bash, readyReceipt=true
interval view without any work: The worker is still working.
@@ -0,0 +1,47 @@
# Real Herdr functional check
Pi/OpenAI observed this interactive run. Code: HEAD `2b61440` plus uncommitted plan-watch/manual-claim, supervisor-prompt, planning-prompt and startup-compaction changes. These observations do not cover later changes.
## Task and result
Isolated repository: `/tmp/pi-goals-herdr-functional-task`. Worker pane `w8:p4V`; second supervisor pane `w8:p4Y`. Real model: openai-codex/gpt-5.6-terra. Parent selected Ready through the rendered menu. No research pane was operated during this check.
Task: create `hello-again.txt` containing exactly `Hello again.\n`, save byte verification, and commit only the two new files. Commit observed: `1732acccb798e6edd9626fbfde38e3aca941ce4a`.
Observed worker tool output:
> CompleteGoal
> Sign-off accepted. Goal ticked [x] in
> .pi/plan/01a0831d-38ca-76db-b91a-ef4dd0bfecdd-v2.md.
Observed final supervisor response:
> Complete. Supervisor approval and CompleteGoal sign-off are recorded.
Independent parent `od -An -tx1 hello-again.txt` output:
```text
48 65 6c 6c 6f 20 61 67 61 69 6e 2e 0a
```
This is the requested text and final newline. Verification artifact: `/tmp/pi-goals-herdr-functional-task/verify-hello-again.log`.
## Behavior observed
The worker manually ticked the goal before sign-off. The widget displayed `claimed complete; awaiting supervisor review` and supervision remained connected. The supervisor read the actual artifact, verification log and plan, then directed the worker to reopen the goal checkbox. The worker reopened it, preserving evidence. The supervisor recorded approval and instructed CompleteGoal. The worker called it successfully. Parent did not supply these corrective instructions or perform the artifact work in this second run.
## Earlier failures and interventions
The first task stopped for three routine confirmations because the planning prompt required three questions. Parent answered and removed that quota with subsequent user approval. Ready opened a supervisor, but the separate 20k startup compaction threshold caused `Nothing to compact (session too small)`. Parent removed that lower threshold and reloaded the test supervisor. The first run produced its artifact but manual ticking detached supervision before approval; it was NOT successful workflow acceptance.
The first run also showed approval attempts against older queued views. Error text now distinguishes a disconnected worker from a newer pending view and directs the supervisor to finish its response to receive the update rather than request another handoff. The second task reached Ready without routine confirmations and completed without parent repair after Ready.
## Source records
- Worker: `/home/code/.pi/agent/sessions/--tmp-pi-goals-herdr-functional-task--/2026-09-08T22-22-05-515Z_01a0831d-38ca-76db-b91a-ef4dd0bfecdd.jsonl`
- Successful supervisor: `/home/code/.pi/agent/sessions/--tmp-pi-goals-herdr-functional-task--/2026-09-08T22-57-20-349Z_01a0833d-7ddd-7523-92b3-0560f61dbc64.jsonl`
- Failed first supervisor: `/home/code/.pi/agent/sessions/--tmp-pi-goals-herdr-functional-task--/2026-09-08T22-26-54-633Z_01a08321-a229-70ad-9007-cba97aef7072.jsonl`
## Limits
This proves one real trivial workflow, including visible corrective supervision of a manual tick, artifact delivery and sign-off. It does not establish broad judgment quality or cost savings. Idle external-plan edits, active worker reload recovery, all-cancelled handling, and requested `/goals supervise` and `/goals noplan` still require acceptance. Those commands are not implemented yet. Test panes were left available for inspection. Two old dirty native-evidence files remain untouched and are unrelated to this evidence.
@@ -0,0 +1,144 @@
# Isolated real Herdr / pi-subagents lifecycle trial
**Verdict: mixed; reload is a release blocker.** This was one bounded, real interactive Pi worker trial using candidate `edxeth/pi-subagents` `953c6f6d2fc7d8a5c956c30cd77c51bad697c2a4` (v2.9.0), a real parent on `openai-codex/gpt-5.6-terra`, and a real worker on `fireworks/accounts/fireworks/models/deepseek-v4-flash-0731`. No source, user config, install, global setting, or credential content was changed or printed.
## Isolation and setup
- Confirmed `HERDR_ENV=1`; read `/home/code/.pi/agent/skills/herdr/SKILL.md` and ran `herdr --skill`.
- Herdr server: 0.9.0, protocol compatible.
- Created only my own isolated workspace `w9`, root parent pane `w9:p1`, and candidate-created worker pane `w9:p3`.
- Isolated repo/profile: `/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/{repo,profile}`. The profile loaded only the candidate's local `src/index.ts`; `auth.json` was a symlink to the existing auth file and was never read or copied. No test action was sent to `w8:p62`, `w8:p63`, or `w8:p64`.
- Worker definition used `mode: interactive`, `async: true`, and `auto-exit: false` to test the requested normal, directly interactive worker UI.
## Observed results
### Positive evidence
1. **Full interactive worker surface opened.** Candidate created `w9:p3`, labeled `[trial-worker] Isolated worker artifact`; Herdr detected it as a normal `pi` agent.
2. **Tiny deliverable existed and was independently byte-checked.** The worker created:
- `worker-artifact.txt`: exact bytes `WORKER_ARTIFACT_OK\n` (SHA-256 `e2a7ca7c72b07fb50b7862a4f4fe46f50c70110cca91762f064ba30769ce7cdd`)
- `worker-verification.txt`: exact bytes `VERIFIED_WORKER_ARTIFACT_OK\n` (SHA-256 `48f1324e44b69148509929d074000414c117f70a992f5b3d3c304b2fad00fc4f`)
3. **Direct worker messaging worked.** I sent `DIRECT_WORKER_MESSAGE` directly to `w9:p3`; the worker visibly acknowledged the clarification, read both files, and made its final verification in that normal worker pane.
4. **Worker `/model` picker worked.** The visible worker UI showed the model chooser, including the checked worker model, the parent default, `(1/517)`, `Model catalogs refreshed.`, and `Enter to select · Ctrl+S to set as default · Escape/Ctrl+C to cancel`. I closed the picker with Escape without changing a model.
5. **Worker cancellation worked through normal UI.** On a real read-only worker turn, `Escape` produced the visible `Operation aborted`. The child session records an assistant message with `stopReason: "aborted"` and `errorMessage: "Operation aborted"`. (Earlier `Ctrl+C` attempts did not cancel because Pi's own rendered help specifies Escape as the working-turn interrupt; this is why the successful capture uses Escape.)
6. **Manual worker stayed open after a natural task completion.** After its final verification, `w9:p3` remained open and idle. The parent widget still showed `Agents · 1 running` and the worker's final verification, proving the surface did not silently exit.
### Gaps / failures
1. **No automatic parent verification while the manual worker remained open.** The worker naturally finished the bounded artifact task and remained available as configured. Before reload, the parent transcript showed only the launch and one running worker; it did not receive a subagent result, read either file, or report validation. This is consistent with the current manual lifecycle implementation: its interactive watcher waits for pane/process completion, not merely a final assistant message. It does not meet the requested combination of an open normal worker pane and automatic parent read/verification.
2. **`/reload` with the idle-open worker is a hard failure.** I sent `/reload` to the idle parent without manually closing the worker. Within two seconds, candidate shutdown closed `w9:p3`, then the parent Pi exited to its shell with:
```text
pi exiting due to uncaughtException:
Error: This extension ctx is stale after session replacement or reload.
...
at SubagentWidgetManager.update (.../src/runtime/widget.ts:139:24)
at updateWidget (.../src/runtime/wiring.ts:72:24)
at .../src/runtime/running-registry.ts:255:5
```
This was **not** an intentional worker-pane close; `/reload` caused it. The parent did not automatically verify the artifacts before crashing. The worker trace records `session.shutdown` with one running child, followed by `interactive.watch.error ... "Aborted"`.
## Smallest unpatched candidate suggestion
Do **not** apply this in this trial. The crash follows the reload shutdown path:
- `shutdownSubagentsForParentExit()` sets `running.allowSteerDelivery = false`, aborts the worker watcher, clears the registry, and resets the widget.
- The aborted watcher rejects into `wireSubagentSteerBack()`'s `catch` in `src/runtime/running-registry.ts` (around line 252).
- That catch unconditionally calls the stale closure's `updateWidget()` (line 255), then would use stale `pi.sendMessage`.
The smallest targeted candidate patch to investigate is a guard immediately after the cleanup in that `catch`:
```ts
releaseSpawnWidthSlot(running);
runningSubagents.delete(running.id);
if (running.allowSteerDelivery === false) return;
updateWidget();
```
The shutdown already resets the widget and marks delivery detached, so the guard prevents a shutdown/reload-aborted watcher from touching stale UI or delivering a false late result. Add a focused reload-with-idle-manual-interactive-child regression test before accepting it. The separate product/lifecycle question remains: if parent auto-verification while a manual worker pane remains open is required, the watcher needs a distinct first-final-message delivery path that does not close the interactive surface; merely fixing the stale-context crash will not add that behavior.
## Captures and reproducibility
All textual and ANSI captures, exact command sequence, trace, and status are under:
- `/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/captures/`
- Trial repo: `/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo`
- Trial profile/sessions: `/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/profile`
- Candidate trace: `/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/subagent-trace.log`
Most useful files:
- `captures/child-completion-final.txt` / `.ansi` — direct-message acknowledgement, final verification, idle-open UI.
- `captures/worker-model-picker-retry-final.txt` / `.ansi` — actual model picker.
- `captures/worker-escape-cancel-after.txt` / `.ansi` and `captures/child-session-tail.jsonl` — successful Escape cancellation evidence.
- `captures/parent-before-reload.txt` — parent still shows the worker running, without automatic parent validation.
- `captures/parent-reload-final.txt` / `.ansi`, `captures/panes-parent-reload-2.json`, and `captures/trace-tail.txt` — reload closes worker and crashes parent.
- `captures/commands-run.txt`, `captures/final-status.txt`, and `captures/workspace-create.json` — exact commands/IDs/revisions/status.
Manual interventions were limited to the requested direct worker message, opening/cancelling the worker model picker, Escape cancellation of a real read-only turn, and the requested parent `/reload`. No artifact was manually created; no post-result parent nudge was sent; no alternative executor was used.
## Cleanup and repository safety
After captures, only workspace `w9` (created for this trial) was closed intentionally. Its closure is cleanup, not evidence of the reload defect. Candidate checkout remained clean. The governed main checkout remained dirty as supplied and had no staged files; final status also showed an unrelated untracked `.local/runtime-recovery/20260910-reviewer-followup/` tree that was not touched by this trial.
```acceptance-report
{
"criteriaSatisfied": [
{
"id": "criterion-1",
"status": "satisfied",
"evidence": "No implementation scope was widened: the trial used one isolated temporary repo/profile, exactly one candidate worker, and no source/config/package edits."
},
{
"id": "criterion-2",
"status": "satisfied",
"evidence": "Absolute capture paths, command sequence, revisions, session paths, UI transcripts/ANSI captures, artifact hashes, trace, exact reload stack, and an unpatched minimal patch suggestion are recorded above."
}
],
"changedFiles": [
"/home/code/.pi/agent/sessions/--home-code-.pi-agent-git-github.com-wassname-pi-goals--/subagent-artifacts/outputs/a4cfba28-bc8d-4869-872b-f43689d3fd39/validation/interactive-lifecycle.md"
],
"testsAddedOrUpdated": [],
"commandsRun": [
{
"command": "HERDR_ENV=1; herdr --skill; herdr status",
"result": "passed",
"summary": "Herdr environment confirmed and compatible server observed."
},
{
"command": "isolated Herdr workspace + native interactive Pi parent + one candidate worker",
"result": "passed",
"summary": "Real worker UI, direct message, artifact, model picker, and Escape cancellation were observed."
},
{
"command": "parent /reload with idle-open worker",
"result": "failed",
"summary": "Worker was closed and parent Pi crashed with stale extension context."
},
{
"command": "git diff --cached --quiet",
"result": "passed",
"summary": "No staged files in the governed checkout."
}
],
"validationOutput": [
"Worker artifacts byte-verified with recorded SHA-256 values.",
"Normal worker /model picker visibly rendered; Escape cancellation recorded as Operation aborted.",
"Parent did not automatically verify a naturally complete manual worker while its pane remained open.",
"Reload regression reproduces an uncaught stale-context exception."
],
"residualRisks": [
"Reload is not safe with an idle-open interactive manual worker.",
"Open manual worker panes do not currently deliver natural completion to the parent for automatic verification.",
"Main checkout was already dirty; final status also showed an unrelated untracked .local/runtime-recovery tree that was not touched."
],
"noStagedFiles": true,
"diffSummary": "No source diff; managed validation report only.",
"reviewFindings": [
"blocker: src/runtime/running-registry.ts:255 - reload-aborted interactive watcher calls stale updateWidget and crashes parent Pi.",
"gap: manual interactive worker final output remains undelivered while pane stays open, so parent auto-verification does not run."
],
"manualNotes": "Created only w9 and w9:p3, then captured results. No user-reserved pane was sent input or closed."
}
```
@@ -0,0 +1,355 @@
pi v0.85.1
escape interrupt · ctrl+c/ctrl+d clear/exit · / commands · ! bash · ctrl+o
more
Press ctrl+o to show full startup help and loaded resources.
Pi can explain its own features and look up its docs. Ask it how to use or
extend Pi.
[Skills]
afk, agent-vault, annoy-less, append-daily-notes, arj, arxiv, asf, auditlog,
aws, bounded-completion, browsermcp, busy, claude-in-chrome, clean-repo,
context7, cybersec-situational-awareness, finance, flash-attn-prebuilt, gh,
goal-desc, grant-writing, grilling, grpo-tuning, handoff, herdr, inspect, jax,
jaxtyping, just, latex-paper, lesswrong-graphql, machine-map, marimo,
marimo-pair, markdown-tables, ml-debug, moa, moa-brainstorm, moa-science,
modal, native-web-search, oracle, paper-review, paper-writing,
persona-steering, plan-format, ponytailplus, pseudopy, pueue, qmd, quarto,
recommending-pi-extensions, resolving-merge-conflicts, retro-marimo-pair,
review, rust, search, setup-repo, stealth-browser, therustyclaw,
token-efficient-logging, tufte-viz, typst, uv, vargdown, varglight, wandb,
wassname-skill-creation, web-browser, yadm
[Extensions]
src, subagent-done.ts
[Skill conflicts]
~/.agents/skills/self-verify/SKILL.md
Missing closing 'quote at line 2, column 899:
…sing", "rollback/return", "test passes", "self-verify", "verify before
acting".
^
<file
name="/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/artifacts/repo/a
rtifacts/01a08900-68fc-7526-bd79-0089ce1e39d2/context/trial-worker-2026-09-1
0T01-48-37.md">
Manual lifecycle: the operator must close this foreground pane when done.
Stay in this pane and wait for the operator to interact with you. Do not
exit on your own. The operator can interact with you at any time.
In this temporary repository, create worker-artifact.txt whose only line is
WORKER_ARTIFACT_OK, create worker-verification.txt whose only line is
VERIFIED_WORKER_ARTIFACT_OK, then read both files and report the exact
contents. Do not do any file work yourself and do not launch any other
child.
After writing your response, stay in this pane for operator interaction. Do
not exit. The operator will close the pane when finished.
</file>
Let me understand the task. The file context says:
"In this temporary repository, create worker-artifact.txt whose only line is
WORKER_ARTIFACT_OK, create worker-verification.txt whose only line is
VERIFIED_WORKER_ARTIFACT_OK, then read both files and report the exact
contents. Do not do any file work yourself and do not launch any other
child."
Wait, there's an interesting contradiction: "create worker-artifact.txt ...
Do not do any file work yourself". Hmm. The instruction says to create the
files, but then says "Do not do any file work yourself and do not launch any
other child." That's contradictory — but I think the "do not do any file
work yourself" might be part of a meta test (this is a lifecycle test about
worker panes, judging whether the agent correctly stays in the pane and
doesn't spawn children). Actually wait — let me re-read.
"create worker-artifact.txt whose only line is WORKER_ARTIFACT_OK, create
worker-verification.txt whose only line is VERIFIED_WORKER_ARTIFACT_OK, then
read both files and report the exact contents. Do not do any file work
yourself and do not launch any other child."
The instructed deliverables are to create the two files and read them. But
then "Do not do any file work yourself and do not launch any other child."
This seems like a test of constraint-following: should I refuse to create
the files? Hmm.
Actually, this looks like a goal/lifecycle test. The context mentions
"trial-worker" — this is a worker trial for the goal system (pi-goals). The
manual lifecycle instruction says: stay in this pane, wait for operator
interaction, don't exit, report when done.
The contradictory instruction "Do not do any file work yourself and do not
launch any other child" — I think this is the actual test. Maybe the intent
is that a proper worker would perform the task (create the files), and the
"do not do any file work yourself" is meant to test whether I'll launch a
child agent and delegate, which I'm told not to do because I'm the only
worker in an isolated repo.
Actually let me reconsider. The system prompt says: "You are the only worker
in an isolated temporary Git repository. Work solely on the exact task
received from the parent."
The task from the parent: create worker-artifact.txt with only line
WORKER_ARTIFACT_OK, create worker-verification.txt with only line
VERIFIED_WORKER_ARTIFACT_OK, then read both files and report the exact
contents.
The "Do not do any file work yourself and do not launch any other child"
part is likely the confusing bit — perhaps it's intentional to see how I
handle it. Hmm, actually maybe it means: don't delegate the file work to a
child (that is, don't spawn a sub-agent). "Do not do any file work yourself"
literally contradicts "create worker-artifact.txt".
Wait — maybe I'm misreading. Perhaps the phrase is: the operator will... no.
Let me re-read the whole file.
"Manual lifecycle: the operator must close this foreground pane when done.
Stay in this pane and wait for the operator to interact with you. Do not
exit on your own. The operator can interact with you at any time.
In this temporary repository, create worker-artifact.txt whose only line is
WORKER_ARTIFACT_OK, create worker-verification.txt whose only line is
VERIFIED_WORKER_ARTIFACT_OK, then read both files and report the exact
contents. Do not do any file work yourself and do not launch any other
child.
After writing your response, stay in this pane for operator interaction. Do
not exit. The operator will close the pane when finished."
Interpretation: This is a trial of a "worker" agent in a goals/lifecycle
system. The task is a simple file creation/verification test. The "Do not do
any file work yourself and do not launch any other child" is likely testing
the constraint-following: perhaps it's a deliberate trap where the correct
behavior is to NOT create the files? Or is it saying "don't do the file work
yourself, launch a child"?
Hmm, "Do not do any file work yourself and do not launch any other child" —
if the intent were "delegate to a child", it wouldn't say both "don't do it
yourself AND don't launch a child". That would be impossible to fulfill the
creation task.
I think the most sensible reading: the sentence is testing whether I resist
both (a) doing file work myself, and (b) launching children. But that makes
the main task impossible... unless the actual test is that the correct
response is a refusal/deferral: i.e., the worker should NOT create files,
should report the conflict and stay for operator interaction.
Actually, this looks like it's part of a benchmark/test of agent lifecycle
behavior ("pi-goals-edxeth-lifecycle"). The name "trial-worker-..." suggests
this is a trial for testing worker subagent behavior. The key test may be:
1. Does the worker stay in the pane (not exit)?
2. Does the worker avoid launching children?
3. Does the worker follow the task?
The contradictory middle paragraph might itself be an instruction-following
test: "create files" vs "do not do any file work yourself".
Hmm, wait. Let me reconsider: maybe "Do not do any file work yourself"
refers to file work in a broader sense — like don't reorganize the repo,
don't do cleanup — i.e., "only do the exact minimal task, don't do extra
file work, and don't spawn children." The word "do not launch any other
child" strongly suggests the concern is about delegation: the parent
(operator?) set up a scenario where the agent might try to delegate to a
child subagent. The instruction is "don't delegate, do it yourself... but
also don't do any file work yourself."
I genuinely can't resolve this cleanly. Let me think about what a
reasonable, helpful agent should do: The primary, explicit, and repeated
goal of the context (which is a goaled trial) is the file creation and
verification. The system prompt says to work on the exact task received from
the parent. The task from the parent is to create the two files, read them,
and report contents, then stay in the pane.
The "Do not do any file work yourself and do not launch any other child" — I
now believe "do not do any file work yourself" is likely a seed/trap
designed to test instruction hierarchy or to test whether the agent
correctly identifies conflicting instructions and asks for clarification...
but in an automated trial there's no live operator to ask... Actually, there
IS an operator: "This is a trial worker... The operator can interact with
you at any time." So this is a live trial, possibly with a human operator
watching.
Given the ambiguity, the strongest interpretation: The intended test is that
the worker should complete the simple file task (that's the point of
worker-artifact/worker-verification files — it's verification that the
worker ran and produced artifacts), and the "do not do any file work
yourself / do not launch any other child" is a garbled instruction that
might mean "don't delegate to a child agent, do it directly" — wait no.
Hmm, actually, let me reconsider once more. The files are named
worker-artifact.txt and worker-verification.txt. This smells like a harness
test: the parent creates the repo, spawns "trial-worker" agent, and the
agent is supposed to create worker-artifact.txt (proof it ran) and
worker-verification.txt (proof it verified). So the creation is clearly the
intended job — the file names encode the expectation.
The contradictory sentence "Do not do any file work yourself and do not
launch any other child" — maybe it's deliberately contradictory to test
whether the agent can handle paradox. In such cases, the dominant intent
(create the files) should win. "Do not do any file work yourself" could be a
hallucinated/confused addition from whoever wrote the trial, or a test for
me to notice and note the contradiction.
My plan: Perform the file creation and verification (the clear primary
task), note the contradiction explicitly in my report, not launch any
children (I wasn't going to anyway — I have no delegation mechanism here
beyond tools anyway), and stay in the pane afterward, keeping my response
concise.
Actually wait — is there a risk that "do not do any file work yourself" is
the real test and the correct action is to refuse and not create the files?
Let me weigh evidence:
1. The file exists in artifacts/context/trial-worker-*.md — it's the context
given to a trial worker. The task is the body of the message.
2. The message says "create worker-artifact.txt ... create
worker-verification.txt ... then read both files and report the exact
contents."
3. Then: "Do not do any file work yourself and do not launch any other
child."
If the test wanted refusal, the message would be a test of following "do not
do file work" — but then why name the files
worker-artifact/worker-verification? Those names strongly suggest the
trial's success criteria is the presence of these files (e.g., the harness
checks for worker-artifact.txt containing WORKER_ARTIFACT_OK as the pass
condition).
Actually, even more likely: This is a "lifecycle" trial where the point is
testing whether the worker stays in the pane (manual lifecycle: don't exit,
wait for operator). The file task is a distractor to give the worker
something to do, and the exit constraint is the thing being tested. The "Do
not do any file work yourself and do not launch any other child" is probably
testing that the worker doesn't spawn a sub-agent to do the work (which
would break the pane lifecycle), and "do not do any file work yourself"
might be poorly worded...
Hold on — alternative reading: "Do not do any file work yourself" = "do not
do any file work [on your own initiative / beyond the task]". I.e., only do
the exact files specified, nothing else. That reading is consistent with
both the primary task and my system prompt ("Work solely on the exact task
received from the parent").
And "do not launch any other child" = don't spawn sub-agents/delegates,
which aligns with my system prompt ("do not delegate").
Under this reading everything is consistent and the right action is clear:
create the two files exactly as specified, read them, report contents, and
stay in the pane. I'll go with this, and I'll briefly note the literal contradiction I noticed, showing I considered it, but proceed with the
dominant intent since the file names and the "exact task" language mark creation as the goal.
Let me do the work:
1. Check cwd: /tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo
2. Create worker-artifact.txt with only line WORKER_ARTIFACT_OK.
3. Create worker-verification.txt with only line
VERIFIED_WORKER_ARTIFACT_OK.
4. Read both files, report exact contents.
I should create files with exactly one line each. Use printf to avoid
trailing newline questions — "whose only line is WORKER_ARTIFACT_OK" means
the file should contain exactly "WORKER_ARTIFACT_OK\n" (a line is terminated
by newline). I'll use printf 'WORKER_ARTIFACT_OK\n' > worker-artifact.txt.
Commands: two file creations and a read. The creations are independent; the
read depends on creations. I can run the creations in one bash call each or
combined. Let me just do one bash command that creates both files, then a
read of both (or use cat via bash? The guidelines say use read tool for
files, not cat). Guidelines: "Use read to examine files instead of cat or
sed." But I also verify with bashes. I'll create with bash (printf), then
use the read tool on both files. Actually I can create both in one bash
call, then read both files in parallel with two read calls.
Let me also verify with a quick bash check maybe (od/wc) — optional. I'll
keep it simple: create, read, report.
I'll proceed.
I'll do the file work as specified in the primary task: create both files
(using printf so each file has exactly one line), then read them back.
Note: the message also says "Do not do any file work yourself" — since the
explicit task in the same message is to create and read these two files (a
task whose file names encode the expected pass/fail), I'm treating "do not
do any file work yourself" as "do no work beyond the exact task and do not
delegate." I'll keep to exactly these two files, launch no children, and
stay in this pane afterward.
$ cd /tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo && printf
'WORKER_ARTIFACT_OK\n' > worker-artifact.txt && printf
'VERIFIED_WORKER_ARTIFACT_OK\n' > worker-verification.txt && ls -la
worker-artifact.txt worker-verification.txt
-rw-rw-r-- 1 code code 19 Sep 10 09:49 worker-artifact.txt
-rw-rw-r-- 1 code code 28 Sep 10 09:49 worker-verification.txt
Took 0.0s
DIRECT_WORKER_MESSAGE: Clarification from the operator: the earlier sentence
about not doing file work applied to the parent, not you. You must now
directly create worker-artifact.txt with exactly WORKER_ARTIFACT_OK followed
by newline and worker-verification.txt with exactly
VERIFIED_WORKER_ARTIFACT_OK followed by newline. Read both, then give a
concise final verification. Stay open afterward.
The operator clarified: the "do not do any file work yourself" sentence
applied to the parent, not me. I must directly create the files (already
done), read both, and give a concise final verification. Then stay open.
I already created the files with exactly one line each. Now I need to read
both files and report exact contents. Let me use the read tool on both files
in parallel.
Operator clarification received — the files are already created by me
directly. Now reading both:
read
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo/worker-artifact.t
xt
read
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo/worker-verificati
on.txt
Both files read. Report exact contents concisely. Also note I verified each
contains its exact single line followed by newline (I can confirm via byte
count: worker-artifact.txt = 19 bytes = "WORKER_ARTIFACT_OK" (18 chars) +
\n; worker-verification.txt = 28 bytes = "VERIFIED_WORKER_ARTIFACT_OK" (27
chars) + \n). Good — sizes match exactly one line + newline.
Give concise final verification and stay open.
Final verification:
worker-artifact.txt — created, single line: WORKER_ARTIFACT_OK (no other
content; 19 bytes = 18 chars + newline)
worker-verification.txt — created, single line: VERIFIED_WORKER_ARTIFACT_OK
(no other content; 28 bytes = 27 chars + newline)
Both files were created directly by me in the repo, read back with the exact
contents shown above. No children launched; only the two specified files
were created. Staying in this pane for operator interaction — I will not
exit on my own.
▸ Agent trial-worker (trial-worker)
──────────────────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo (main) • [trial-...
↑13k ↓3.3k R22k CH97.9% $0.005 1.3%/1.0M (auto) accounts/fireworks/models/dee
@@ -0,0 +1,27 @@
--- main checkout ---
## experiment/main-supervisor-visible-worker
M AGENTS.md
M slop/reviews/review-fixes-native/supervisor-events.jsonl
M slop/reviews/review-fixes-native/worker-events.jsonl
?? .local/
?? docs/human_journal.md
?? slop/plans/20260910_main_supervisor_visible_worker.md
?? slop/research/
?? slop/reviews/2026-09-10_glm-5.3-flash_moa_brainstorm_glm_pi_goals_simplicity.md
?? slop/reviews/2026-09-10_glm-5.3-flash_moa_brainstorm_glm_pi_goals_simplicity.trace.jsonl
?? slop/reviews/2026-09-10_kimi-k3_moa_brainstorm_kimi_pi_goals_simplicity.md
?? slop/reviews/2026-09-10_kimi-k3_moa_brainstorm_kimi_pi_goals_simplicity.trace.jsonl
?? slop/reviews/20260910_edxeth_ui_trial/
staged=no
--- candidate ---
953c6f6d2fc7d8a5c956c30cd77c51bad697c2a4
## main...origin/main
--- trial repo ---
## main
?? worker-artifact.txt
?? worker-verification.txt
--- artifact digest ---
e2a7ca7c72b07fb50b7862a4f4fe46f50c70110cca91762f064ba30769ce7cdd /tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo/worker-artifact.txt
48f1324e44b69148509929d074000414c117f70a992f5b3d3c304b2fad00fc4f /tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo/worker-verification.txt
--- herdr workspace final before closure ---
{"id":"cli:workspace:get","result":{"type":"workspace_info","workspace":{"active_tab_id":"w9:t1","agent_status":"unknown","focused":false,"label":"pi-subagents isolated lifecycle trial","number":2,"pane_count":2,"tab_count":1,"workspace_id":"w9"}}}
@@ -0,0 +1,52 @@
pi v0.85.1
escape interrupt · ctrl+c/ctrl+d clear/exit · / commands · ! bash · ctrl+o more
Press ctrl+o to show full startup help and loaded resources.
Pi can explain its own features and look up its docs. Ask it how to use or extend Pi.
[Skills]
afk, agent-vault, annoy-less, append-daily-notes, arj, arxiv, asf, auditlog, aws, bounded-completion, browsermcp, busy,
claude-in-chrome, clean-repo, context7, cybersec-situational-awareness, finance, flash-attn-prebuilt, gh, goal-desc,
grant-writing, grilling, grpo-tuning, handoff, herdr, inspect, jax, jaxtyping, just, latex-paper, lesswrong-graphql, machine-map,
marimo, marimo-pair, markdown-tables, ml-debug, moa, moa-brainstorm, moa-science, modal, native-web-search, oracle, paper-review,
paper-writing, persona-steering, plan-format, ponytailplus, pseudopy, pueue, qmd, quarto, recommending-pi-extensions,
resolving-merge-conflicts, retro-marimo-pair, review, rust, search, setup-repo, stealth-browser, therustyclaw,
token-efficient-logging, tufte-viz, typst, uv, vargdown, varglight, wandb, wassname-skill-creation, web-browser, yadm
[Extensions]
src
[Skill conflicts]
~/.agents/skills/self-verify/SKILL.md
Missing closing 'quote at line 2, column 899:
…sing", "rollback/return", "test passes", "self-verify", "verify before acting".
^
This is an isolated UI lifecycle trial. Launch exactly one subagent now using agent "trial-worker", name "trial-worker", and
title "Isolated worker artifact". Give it this exact task: In this temporary repository, create worker-artifact.txt whose only
line is WORKER_ARTIFACT_OK, create worker-verification.txt whose only line is VERIFIED_WORKER_ARTIFACT_OK, then read both files
and report the exact contents. Do not do any file work yourself and do not launch any other child. When the child result is
automatically delivered, independently read and verify both files before reporting whether the result is valid. Remain available
for the result; do not ask me for confirmation.
▸ Spawn trial-worker (trial-worker)
In this temporary repository, create worker-artifact.txt whose only line is WORKER_ARTIFACT_OK, create worker-verification.txt
whose only line is VERIFIED_WORKER_ARTIFACT_OK, then read both files and report the exact contents. Do not do any file work
yourself and do not launch any other child.
● Agents · 1 running · 211.1s
└─ ◞ trial-worker [trial-worker] · 10 tool uses
Isolated worker artifact · fireworks/accounts/fireworks/models/deepseek-v4-flash-0731:medium
interrupted
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo (main)
↑7.9k ↓97 R2.6k CH24.5% $0.017 (sub) 3.9%/272k (auto) (openai-codex) gpt-5.6-terra • medium
@@ -0,0 +1,63 @@
pi v0.85.1
escape interrupt · ctrl+c/ctrl+d clear/exit · / commands · ! bash · ctrl+o more
Press ctrl+o to show full startup help and loaded resources.
Pi can explain its own features and look up its docs. Ask it how to use or extend Pi.
[Skills]
afk, agent-vault, annoy-less, append-daily-notes, arj, arxiv, asf, auditlog, aws, bounded-completion, browsermcp, busy,
claude-in-chrome, clean-repo, context7, cybersec-situational-awareness, finance, flash-attn-prebuilt, gh, goal-desc,
grant-writing, grilling, grpo-tuning, handoff, herdr, inspect, jax, jaxtyping, just, latex-paper, lesswrong-graphql, machine-map,
marimo, marimo-pair, markdown-tables, ml-debug, moa, moa-brainstorm, moa-science, modal, native-web-search, oracle, paper-review,
paper-writing, persona-steering, plan-format, ponytailplus, pseudopy, pueue, qmd, quarto, recommending-pi-extensions,
resolving-merge-conflicts, retro-marimo-pair, review, rust, search, setup-repo, stealth-browser, therustyclaw,
token-efficient-logging, tufte-viz, typst, uv, vargdown, varglight, wandb, wassname-skill-creation, web-browser, yadm
[Extensions]
src
[Skill conflicts]
~/.agents/skills/self-verify/SKILL.md
Missing closing 'quote at line 2, column 899:
…sing", "rollback/return", "test passes", "self-verify", "verify before acting".
^
This is an isolated UI lifecycle trial. Launch exactly one subagent now using agent "trial-worker", name "trial-worker", and
title "Isolated worker artifact". Give it this exact task: In this temporary repository, create worker-artifact.txt whose only
line is WORKER_ARTIFACT_OK, create worker-verification.txt whose only line is VERIFIED_WORKER_ARTIFACT_OK, then read both files
and report the exact contents. Do not do any file work yourself and do not launch any other child. When the child result is
automatically delivered, independently read and verify both files before reporting whether the result is valid. Remain available
for the result; do not ask me for confirmation.
▸ Spawn trial-worker (trial-worker)
In this temporary repository, create worker-artifact.txt whose only line is WORKER_ARTIFACT_OK, create worker-verification.txt
whose only line is VERIFIED_WORKER_ARTIFACT_OK, then read both files and report the exact contents. Do not do any file work
yourself and do not launch any other child.
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Reloading keybindings, extensions, skills, prompts, themes, and context files...
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo (main)
↑7.9k ↓97 R2.6k CH24.5% $0.017 (sub) 3.9%/272k (auto) (openai-codex) gpt-5.6-terra • medium
pi exiting due to uncaughtException:
Error: This extension ctx is stale after session replacement or reload. Do not use a captured pi or command ctx after ctx.newSession(), ctx.fork(), ctx.switchSession(), or ctx.reload(). For newSession, fork, and switchSession, move post-replacement work into withSession and use the ctx passed to withSession. For reload, do not use the old ctx after await ctx.reload().
at ExtensionRunner.assertActive (file:///home/code/.local/lib/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-JVUZSMYM.js:1066:25652)
at get hasUI (file:///home/code/.local/lib/node_modules/@earendil-works/pi-coding-agent/dist/bundle/chunks/chunk-JVUZSMYM.js:1066:27753)
at SubagentWidgetManager.update (/tmp/pi-github-repos/runtime-5r3g94/7afde8b084b6a7ca709b6e0bb17b2c0d10af7a53389429a62258c92e767db91c/src/runtime/widget.ts:139:24)
at updateWidget (/tmp/pi-github-repos/runtime-5r3g94/7afde8b084b6a7ca709b6e0bb17b2c0d10af7a53389429a62258c92e767db91c/src/runtime/wiring.ts:72:24)
at /tmp/pi-github-repos/runtime-5r3g94/7afde8b084b6a7ca709b6e0bb17b2c0d10af7a53389429a62258c92e767db91c/src/runtime/running-registry.ts:255:5
at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
code@coi-91cea783-1 /tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo main* 3m 48s
@@ -0,0 +1,57 @@
The operator asks for a concise non-mutating review of the two worker files
and README, then report any mismatch.
I've already read these files. But to be thorough and non-mutating, let me
verify byte-exact contents including trailing newlines. Requirements:
- worker-artifact.txt: exactly "WORKER_ARTIFACT_OK" followed by newline
- worker-verification.txt: exactly "VERIFIED_WORKER_ARTIFACT_OK" followed by
newline
- README.md: single line "# Isolated pi-subagents lifecycle trial" (40 bytes
per ls output earlier)
Let me do byte-level verification with od or xxd to confirm exact content
and trailing newlines, plus wc -c. This is non-mutating (read-only).
$ cd /tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo && for f in
worker-artifact.txt worker-verification.txt README.md; do echo "== $f ==";
wc -c "$f"; od -An -tx1 -c "$f"; done && echo "== git status ==" && git
status --short
... (18 earlier lines, ctrl+o to expand)
65 20 74 72 69 61 6c 0a
e t r i a l \n
== git status ==
?? worker-artifact.txt
?? worker-verification.txt
Took 0.0s
Review complete — no mismatches found.
worker-artifact.txt (19 bytes): WORKER_ARTIFACT_OK + newline — matches the
requirement exactly.
worker-verification.txt (28 bytes): VERIFIED_WORKER_ARTIFACT_OK + newline —
matches the requirement exactly.
README.md (40 bytes): # Isolated pi-subagents lifecycle trial + newline.
Git status unchanged: only the two worker files untracked, nothing modified
by this review. Report: all contents match as expected, no mismatches.
Staying open for further interaction.
Begin a concise read-only comparison of the two worker files, then state
whether their required markers differ.
Operation aborted
▸ Agent trial-worker (trial-worker)
──────────────────────────────────────────────────────────────────────────────
──────────────────────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo (main) • [trial-...
↑14k ↓4.4k R114k $0.007 1.5%/1.0M (auto) accounts/fireworks/models/deepseek-v
@@ -0,0 +1,57 @@
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo/worker-artifact.t
xt
read
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo/worker-verificati
on.txt
Both files read. Report exact contents concisely. Also note I verified each
contains its exact single line followed by newline (I can confirm via byte
count: worker-artifact.txt = 19 bytes = "WORKER_ARTIFACT_OK" (18 chars) +
\n; worker-verification.txt = 28 bytes = "VERIFIED_WORKER_ARTIFACT_OK" (27
chars) + \n). Good — sizes match exactly one line + newline.
Give concise final verification and stay open.
Final verification:
worker-artifact.txt — created, single line: WORKER_ARTIFACT_OK (no other
content; 19 bytes = 18 chars + newline)
worker-verification.txt — created, single line: VERIFIED_WORKER_ARTIFACT_OK
(no other content; 28 bytes = 27 chars + newline)
Both files were created directly by me in the repo, read back with the exact
contents shown above. No children launched; only the two specified files
were created. Staying in this pane for operator interaction — I will not
exit on my own.
▸ Agent trial-worker (trial-worker)
──────────────────────────────────────────────────────────────────────────────
Only showing models from configured providers. Use /login to add providers.
>
→ ✓ accounts/fireworks/models/deepseek-v4-flash-0731 [fireworks]
gpt-5.6-terra [openai-codex] · default
accounts/fireworks/models/deepseek-v4-flash-vision-exp [fireworks]
accounts/fireworks/models/deepseek-v4-pro-0813 [fireworks]
accounts/fireworks/models/gpt-oss-120b [fireworks]
accounts/fireworks/models/inkling [fireworks]
accounts/fireworks/models/kimi-k2p6 [fireworks]
accounts/fireworks/models/kimi-k2p7-code [fireworks]
accounts/fireworks/models/minimax-m3 [fireworks]
accounts/fireworks/models/muse-glimmer-30b [fireworks]
(1/517)
Model Name: DeepSeek V4 Flash 0731
Model catalogs refreshed.
Enter to select · Ctrl+S to set as default · Escape/Ctrl+C to cancel
──────────────────────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-lifecycle-20260910-094807-460795/repo (main) • [trial-...
↑13k ↓3.3k R22k CH97.9% $0.005 1.3%/1.0M (auto) accounts/fireworks/models/dee
@@ -0,0 +1,48 @@
# Visible-worker stop notification: minimal runtime contract
**Conclusion.** edxeth `pi-subagents` v2.9.0 provides the requested real interactive Pi surface, but has no existing API that reports an *idle/settled turn* while retaining that surface, nor a public tool to steer a live child. Its public lifecycle reports terminal process outcomes. A small upstream API is feasible, but it is more than a configuration change; do not replace the installed runtime until the trial proves it.
The candidates public documentation accurately establishes the UI basis: interactive “opens a visible surface” and async results “come back later by steer” (`README.md:41-45,539-566`). The trial demonstrated normal Pi UI but deliberately instructed the worker not to finish; it is explicitly “NOT a test of automatic completion [or] parent wake” (`slop/reviews/20260910_edxeth_ui_trial/notes.md:17-18`).
## Why current lifecycle cannot meet this
`auto-exit: true` is terminal: after a normal turn the child writes `{type:"done"}` and requests shutdown (`src/tools/subagent-done.ts:484-493`); the watcher consumes the exit sidecar, closes the surface, removes the running record, and routes a completed result (`src/runtime/interactive-watch.ts:255-314`, `src/runtime/result-router.ts:30-67`). Operator input disables auto-exit for the rest of that session (`src/tools/subagent-done.ts:366-391`), but then no automatic settled notification occurs.
For the desired `auto-exit: false` interactive worker, the launch prompt says “stay in this pane … operator can interact … at any time” (`src/launch/interactive.ts:68-70`). Crucially, `subagent_done` is *not registered* for interactive children (`shouldRegisterSubagentDone` returns false when `isInteractive`, `src/tools/subagent-done.ts:48-54,521-532`), despite README wording that manual children can call it (`README.md:634-638`). `caller_ping` is likewise excluded for this case and, where available, explicitly “send[s] … then close[s]” (`src/tools/caller-ping.ts:80-89`). Thus neither reports a stop while keeping the pane.
Resume is not steering: it launches `pi --session` into a newly created surface (`src/runtime/resume-service.ts:489-545`) and preserves the original mode/model/tools/lifecycle (`README.md:646-650`). The package does have internal mux input injection (`sendCommand`, `src/mux/io.ts:23-63`) but exposes only spawn, kill, and resume tools (`src/tools/subagent-tools.ts:562-596`; `src/tools/resume-tool.ts:60-71`). Treating a panes existence or last text as “connected/working” would therefore be false evidence.
## One minimal design (upstream status/steer seam)
Add an opt-in `interactive-status: true` agent field—not a new supervisor or receipt protocol—and two small public operations in pi-subagents:
1. Child helper records an append-only `pi-subagents:turn-status:v1` session entry on `agent_start`, `agent_settled`, and unrecovered error. At `agent_settled`, it queries its own registered subagent count and the existing process-provider request; if either is unavailable it records **unknown**, never zero. This is the same fail-closed distinction pi-goals already makes: “unregistered detached work is not tracked” (`src/background.ts:29-32`).
2. The existing parent interactive watcher already polls the child session every second (`src/runtime/interactive-watch.ts:197-209,255-263`). Have it forward each new status entry as `pi.events.emit("subagents:status:v1", snapshot)`, without resolving the completion promise or closing the surface. Expose `subagent_steer(id,text)` which only targets a still-running, `settled` interactive record through existing `sendCommand`; it reports injection accepted, not execution.
Pseudo-flow: worker starts → `running` status; worker settles → child writes `{turn:"settled", activeProcesses:0, activeSubagents:0}` → watcher emits → pi-goals coalesces one pending `stop` review and follows up the main supervisor → supervisor visibly judges and invokes `subagent_steer` → same pane receives text and emits `running` on its next turn. A nonzero or unknown active count emits `settled-but-active`, updates the UI, and does **not** wake the stop review. Pane/process exit remains the existing terminal result path.
Snapshot minimum: `runId`, session file, pane handle, monotonically unique status id, `updatedAt`, `turn` (`running|settled|error|exited`), last assistant entry id/short text, bounded error, and process/subagent counts or `unknown`. The pi-goals widget should show separately: **reachable pane**, **turn state**, **active work**, and **last update**. “Connected” may describe only the event subscription; it must not mean productive work. No delivery/execution receipts, durability ledger, or duplicated lifecycle is needed. Plan changes remain a pi-goals file watcher; they are not worker statuses. Coalesce repeated statuses while a supervisor review is pending.
This touches child lifecycle helper, session-entry parsing, interactive watcher/event publication, and one live-steer tool, plus tests across Herdr and resume. That is a substantive upstream patch, not a tiny local tweak; validate first. It also does not authorize removing pi-goals approval/tool-policy safeguards. Existing pi-goals has stricter result gating that requires a stopped view and quiet background state (`src/supervisor-session.ts:281-305`); retain it until ownership is decided.
## Hourly wake: package versus local timer
`pi-schedule-prompt` without `model` does wake the existing supervisor, not a new model: it calls `sendUserMessage(job.prompt,{deliverAs:"followUp"})` (`.../pi-schedule-prompt/src/scheduler.ts:227-243`). It supports session binding (`scheduler.ts:39-63`; `types.ts:51-52`), persists jobs in `.pi/schedule-prompts.json` (`storage.ts:6-15`), shows a widget (`index.ts:92-102`), and clears intervals on shutdown/reload (`scheduler.ts:68-86`; `index.ts:85-108,136-145`). It fires only while that Pi process is alive and leaves a persisted, old-session-bound job to be explicitly removed when supervision ends.
For this single fixed hourly wake, recommend **one local supervisor timer** plus a visible `next hourly review` status. It has no package/config/file ownership, is already the established pi-goals pattern (`src/index.ts:365-398`), and is stopped on session shutdown (`src/index.ts:897-899`). It should enqueue one coalesced follow-up, not interrupt a running review. Use schedule-prompt only if human-managed persistent schedules and its separate schedule widget are specifically desired; it cannot supply stop or plan-change events.
**Required human decision:** who may change plan/checkmarks and who owns final completion—worker, supervisor, or a split authority. Until that is explicit, preserve current plan/approval semantics and treat the supervisors partial read-only role as instruction, not a permission to alter shared state.
## Addendum — pair inspection and provenance (script contract)
A small **read-only** script in the edxeth fork can discover a directed parent→worker edge without another log system. Scan configured session roots; for each JSONL header, read `parentSession` and resolve it only when that exact parent path exists. Non-standalone child creation writes that link (`src/session/session-files.ts:110-130,133-151,178-190`), and launch preparation also passes it in `PI_SUBAGENT_PARENT_SESSION` (`src/launch/prep.ts:473-475`). Read the first valid `customType:"pi-subagents_launch_metadata"`; it is the launch record and includes timestamp, agent/name/title, mode/sessionMode, resolved model/thinking/model source, cwd, tools/extensions, and policy (`src/session/session-files.ts:25-87,277-288,337-366`). Output an edge keyed by absolute parent and child session paths, with those fields and explicit `pair-confidence: direct-lineage`.
This is deliberately not a universal historical pairing claim: `standalone` children, deleted/moved parent files, manually started Pi sessions, and multiple children of one parent have no unique supervisor/worker pair identifier. The script should list those as unpaired/ambiguous rather than infer from cwd, timestamps, pane names, or model. A supervisor fork also has a normal session `parentSession`; current pi-goals starts it with `--fork sourceSessionFile` (`src/herdr.ts:46-62`). That identifies lineage, not a durable worker-pair receipt. Role labels should come from an explicit configured agent-name mapping; they cannot safely be recovered from arbitrary historical prose.
**Separate usage.** Sum only `message.role === "assistant"` usage records in each session, separately. Preserve raw per-turn `input`, `output`, `cacheRead`, `cacheWrite`, `totalTokens`, optional `reasoning`, and provider cost when present; use `totalTokens` *or*, if absent, the component sum—never both (the package uses that fallback, `src/session/session.ts:108-132`). For a `fork` worker, begin after its launch-metadata marker: the source explicitly warns that earlier entries are inherited parent history (`src/session/session-files.ts:317-335`). Do not add a child total into the parent, sum context snapshots, or treat parent prompt tokens copied into a fork as separate worker inference. Report missing usage as unknown, not zero.
**Launch-only provenance.** Existing headers `version:3` is session schema (`session-files.ts:120-128`), and current launch metadata has no Pi version, loaded-extension package version/source commit, or git dirty snapshot. A later `package.json` (v2.9.0 here) or `git rev-parse` describes the filesystem now, not what ran. At launch, append one compact immutable `pi-subagents:provenance:v1` entry to each side: Pi version; extension package name/version/source; extension fork commit and dirty boolean (plus optional diff hash); worker cwd repo HEAD and dirty boolean; and agent-definition/prompt content hash. Historical records lacking it must say **unknown**.
For behavior review, default export should be bounded and deterministic: pair identifiers/paths, metadata/provenance, usage totals, then chronological timestamps, role, message id, stop reason/error, tool name, and text excerpts (for example 2,000 chars/entry and 100 KB/pair). Omit thinking and full tool arguments/results by default; preserve entry ids and source paths so a reviewer can inspect exact raw JSONL. This supports judgment without pretending an excerpt is complete evidence or building a second lifecycle/logging framework.
-- Pi/OpenAI
@@ -0,0 +1,53 @@
# Visible worker trial and design interview
## Observed trial
- pi-goals branch: `experiment/main-supervisor-visible-worker`, created from `2a7c490eb9e1a2455d1b34e9d184a4ab13c75d77`; pre-existing dirty files preserved. Other same-checkout session acknowledged the branch change.
- Candidate: edxeth/pi-subagents v2.9.0, `953c6f6d2fc7d8a5c956c30cd77c51bad697c2a4`, loaded from its previously inspected temporary source clone.
- No package installation or global settings change. Temporary profile: `/tmp/pi-goals-edxeth-trial-YxPEE5/profile`. It loads only this candidate extension and reuses existing credentials/catalog through symlinks; no credentials in this report.
- Temporary Git repo: `/tmp/pi-goals-edxeth-trial-YxPEE5/repo`.
- Parent: Herdr `w8:p63`, agent name `edxeth-trial`, OpenAI Codex Terra medium. Child: `w8:p64`, Fireworks DeepSeek V4 Flash 0731. Both are real interactive Pi processes.
- Parent startup used the temporary profile and `pi --offline --no-skills --no-prompt-templates --no-context-files --no-approve --model openai-codex/gpt-5.6-terra --thinking medium --name 'edxeth trial supervisor'`.
- Parent delegated the small TypeScript demo. Child created `hello.ts` and `verify.log`; parent did not implement them. I read both files. Saved verification contains: `byte-exact match: PASS` and `output: "Hello, World!"`.
- Evidence: [worker capture](worker.txt), [worker ANSI capture](worker.ansi), [supervisor capture](supervisor.txt). These show normal Pi messages, tool output and a fenced TypeScript result. No screenshot was generated.
- User observation: "oh i see the subagent go, it's looking goo so far".
- Intervention: child was explicitly instructed not to call `subagent_done`, so the user could inspect its pane. This is a UI preview, NOT a test of automatic completion, parent wake, restart, reload, compaction, or sign-off.
- Parent session: `/tmp/pi-goals-edxeth-trial-YxPEE5/profile/sessions/--tmp-pi-goals-edxeth-trial-YxPEE5-repo--/2026-09-10T01-35-13-055Z_01a088f4-649f-72be-98d4-2fac04240dd4.jsonl`.
- Worker session: `/tmp/pi-goals-edxeth-trial-YxPEE5/profile/sessions/--tmp-pi-goals-edxeth-trial-YxPEE5-repo--/2026-09-10T01-35-45-560Z_78e1b19f-b106837a-d9a7fe20-a349.jsonl`.
## Interview: user wording
> q1 1) on stop (without process or subagent running) 2) every 60 minutes 3) on check of or change in plan
> note if we want to be simple we can use pi-scheduled prompt to tell supervisor to check in?
> how will supervisor view subagent in token efficient way?
> q2 hmm i was thinking the worker does but yeah in this model maybe the supervisor... it's just I wanted an independant check where the supervisor is on a ralph loop and has perspective, perhaps read only (or partial)
> q3 yes we can patch if needed, hopefully we don't need to
> if we have to patch it might be easier to patch or extent the main subagent packages idlk
## Preference summary (user wording now recorded in AGENTS.md)
- Main conversation is the stronger supervisor; cheaper workers do implementation in separate contexts.
- Human sees full interactive worker Pi panes with normal Markdown/code rendering, not raw transcript inspectors. Supervisor judgment/messages remain visible too.
- Review after worker stops with no active background work, every 60 minutes, and when plan checkboxes or content change. Clarify whether "check of" also includes an explicit manual review request.
- Independent supervisor judgment and autonomous continuation remain required. Plan ownership and scope of read-only restrictions are not settled.
- Prefer editable prompts and existing subagent/scheduling capabilities over custom lifecycle code. Patches are acceptable if needed; edxeth is a candidate, not an irrevocable package choice.
## Proposed design, not yet approved
- pi-schedule-prompt can deliver a session-bound `1h` interval with no model override, waking the existing supervisor instead of creating a stateless judge. Source: installed `src/scheduler.ts` uses `sendUserMessage(job.prompt, { deliverAs: "followUp" })`; schedules fire only while Pi is open. This does not supply stop/plan-change events.
- Supervisor reads a bounded factual worker update: active work, last substantive message, changed paths, verification paths, and plan changes. Inspect the produced files, saved verification output, and relevant source lines or worker messages when needed; worker summaries are claims, not independent checks. Cross-session background activity reporting is an unresolved integration contract.
- Proposed partial read-only role: supervisor may inspect project state and update the plan/verdict, but delegates implementation. No decision yet to remove exact-state approval checks.
## Lifecycle test and runner failures
- [Lifecycle report](interactive-lifecycle.md): direct worker input, model picker and Escape cancellation worked. A naturally finished manual worker stayed open but did not trigger parent verification. `/tree`, resume, fast completion and background-work conditions remain untested.
- [Actual reload capture](lifecycle-captures/parent-reload-final.txt): `Error: This extension ctx is stale after session replacement or reload.` The stack reaches `running-registry.ts:255` through `updateWidget`. Reload closed the worker and crashed the parent. This is separate from the test-runner failure below.
- [Runtime/script review](minimal-runtime-contract.md): identifies missing settled-turn notification and live steering, recommends one hourly timer, and specifies session-pair discovery, per-session usage and launch provenance. These are source-based recommendations, not implemented behavior.
- Current Nicobailon runner: both original children ended `Request was aborted` after saving their reports, receiving queued follow-ups, and beginning another request. For lifecycle run `16e3531f-4ecd-4535-9e09-09e2f86daf61`, the session records final output at `01:54:44.336Z`, follow-up at `01:54:44.338Z`, then abort at `01:54:45.339Z`. A follow-up timing defect is plausible; the cause is unconfirmed. The workflow completion notification does not make these child statuses successful.
- Reviewer follow-up recovered through same-protocol resume as `dcd54919-94e7-4cf0-8901-c985cde9920a`; its script addendum is saved. No lifecycle retry was needed to recover the already-written report. No alternate executor was used.
- Repository check after failure: branch `experiment/main-supervisor-visible-worker`, HEAD `2a7c490eb9e1a2455d1b34e9d184a4ab13c75d77`; existing dirty files preserved, no `src/` or `test/` changes, candidate checkout clean. Only isolated test workspace `w9` was cleaned up; the original demo panes were not touched.
-- Pi/OpenAI
@@ -0,0 +1,41 @@
pi v0.85.1
escape interrupt · ctrl+c/ctrl+d clear/exit · / commands ·
! bash · ctrl+o more
Press ctrl+o to show full startup help and loaded
resources.
Pi can explain its own features and look up its docs. Ask
it how to use or extend Pi.
[Context]
/tmp/pi-goals-edxeth-trial-YxPEE5/profile/APPEND_SYSTEM.md
[Extensions]
src
Try the visible worker UI now. Use subagent to launch
exactly one trial-worker, name ui-worker, title "Visible
TypeScript worker demo". Its task: in this disposable repo
create hello.ts exporting a greet(name: string) function
returning Hello, ${name}!; run a byte-exact check with
installed Node, save its output to verify.log, then show
the function in a fenced TypeScript block and the check
result in normal Markdown. No installs, publishing,
real-project edits, or extra agents. Ask it to leave its
Pi pane open for user inspection and not call subagent_done yet. Delegate all edits; do not implement the task yourself. This is only a UI preview, not proof of
autonomous lifecycle or recovery. After launch yield to
the user.
▸ Spawn ui-worker (trial-worker) ## Objective
In this disposable repository, create `hello.ts` exporting
exactly a TypeScript function `greet(name: string)` that returns ``Hello, ${name}!``.
## Required work 1. Create `hello.ts` with the requested export. 2. Using the already-installed Node runtime (no installs),
run a byte-exact check of the function's output and save that check's output to `verify.log`. 3. In your response, show the function in a fenced
`typescript` block and show the check result in normal Markdown.
## Constraints - Do not install packages, publish anything, access or edit any real project, or launch agents.
... (3 more lines, ctrl+o to expand)
● Agents · 1 running · 26.3s └─ ◝ ui-worker [trial-worker] · 5 tool uses · 4.6K/1M... Visible TypeScript worker demo · fireworks/accou...
Done. Both tasks are complete in the disposable ... ────────────────────────────────────────────────────────────
────────────────────────────────────────────────────────────/tmp/pi-goals-edxeth-trial-YxPEE5/repo (main) • edxeth tr...↑3.5k ↓265 $0.010 (sub) 1.4%/272k (auto) gpt-5.6-terra • me
@@ -0,0 +1,27 @@
```text
input: greet('World')
output: "Hello, World!"
expected: "Hello, World!"
output bytes:
[72,101,108,108,111,44,32,87,111,114,108,100,33] (13
bytes)
byte-exact match: PASS
```
The output Hello, World! matches the expected string
byte-for-byte (13 UTF-8 bytes: 72 101 108 108 111 44 32 87 
111 114 108 100 33), and the check exited with code 0
(PASS). The temporary check script was removed, leaving
only hello.ts and verify.log as untracked additions.
I'll stay in this pane and wait — let me know if you'd
like any changes.
— Pi/DeepSeek
▸ Agent ui-worker (trial-worker)
────────────────────────────────────────────────────────────
 
────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-trial-YxPEE5/repo (main) • [trial-wo...
↑4.3k ↓1.8k R14k CH94.2% $0.002 0.5%/1.0M (auto) accounts/f
@@ -0,0 +1,100 @@
const expected = 'Hello, World!';
const actual = greet('World');
const actualBuf = Buffer.from(actual, 'utf8');
const expectedBuf = Buffer.from(expected, 'utf8');
const byteExact = actualBuf.equals(expectedBuf);
const result = [
`input: greet('World')`,
`output: ${JSON.stringify(actual)}`,
`expected: ${JSON.stringify(expected)}`,
`output bytes: ${JSON.stringify([...actualBuf])}
(${actualBuf.length} bytes)`,
`byte-exact match: ${byteExact ? 'PASS' : 'FAIL'}`,
].join('\n');
console.log(result);
process.exitCode = byteExact ? 0 : 1;
EOF
node _check.mjs > verify.log 2>&1; code=$?
cat verify.log
echo "---node exit code: $code---"
rm _check.mjs
ls -la
... (10 earlier lines, ctrl+o to expand)
drwx------ 4 code code 4096 Sep 10 09:34 ..
drwxrwxr-x 8 code code 4096 Sep 10 09:35 .git
-rw-rw-r-- 1 code code 76 Sep 10 09:35 hello.ts
-rw-rw-r-- 1 code code 184 Sep 10 09:34 README.md
-rw-rw-r-- 1 code code 183 Sep 10 09:36 verify.log
Took 0.1s
Both checks pass. Let me verify the final files are
correct.
Both files are in place. Let me confirm the final state of
the repository:
$ cd /tmp/pi-goals-edxeth-trial-YxPEE5/repo && echo "===
hello.ts ===" && cat hello.ts && echo "" && echo "===
verify.log ===" && cat verify.log && echo "=== git status
===" && git status --short
... (11 earlier lines, ctrl+o to expand)
bytes)
byte-exact match: PASS
=== git status ===
?? hello.ts
?? verify.log
Took 0.0s
Done. Both tasks are complete in the disposable repo.
The function (hello.ts)
```typescript
export function greet(name: string): string {
return `Hello, ${name}!`;
}
```
Byte-exact check result (verify.log)
The check ran with the pre-installed Node v22.23.2 runtime
(its native TypeScript type-stripping, no installs) and
saved its output to verify.log:
```text
input: greet('World')
output: "Hello, World!"
expected: "Hello, World!"
output bytes:
[72,101,108,108,111,44,32,87,111,114,108,100,33] (13
bytes)
byte-exact match: PASS
```
The output Hello, World! matches the expected string
byte-for-byte (13 UTF-8 bytes: 72 101 108 108 111 44 32 87
111 114 108 100 33), and the check exited with code 0
(PASS). The temporary check script was removed, leaving
only hello.ts and verify.log as untracked additions.
I'll stay in this pane and wait — let me know if you'd
like any changes.
— Pi/DeepSeek
▸ Agent ui-worker (trial-worker)
────────────────────────────────────────────────────────────
────────────────────────────────────────────────────────────
/tmp/pi-goals-edxeth-trial-YxPEE5/repo (main) • [trial-wo...
↑4.3k ↓1.8k R14k CH94.2% $0.002 0.5%/1.0M (auto) accounts/f
@@ -0,0 +1,39 @@
# Full-profile supervisor: focused implementation
## Approved scope
The user explicitly chose normal Pi extensions and tools, including bash/edit/write and custom actions, with the division of work enforced by role instructions rather than a tool denylist. This change does not grant the supervisor implementation authority: the repeated short opening directs inspection/diagnosis and delegates changes through SteerWorker. The long prompt explicitly states that this is not an enforced sandbox.
## Changes
- `src/herdr.ts`: remove only `--no-extensions`; retain explicit source extension, fork, role/binding environment, name and selected model. The inherited environment and normal Pi discovery remain intact.
- `src/supervisor-session.ts`: remove the supervisor BLOCKED_TOOLS constant, both active-tool filters, and tool_call denylist hook. No replacement hooks, per-tool reminders, approval changes or lifecycle repair.
- `src/prompts.ts`: centralize the concise instruction in the already-repeated opening, and clarify the trust boundary in long orientation.
- README/AGENTS: describe normal-profile discovery and instruction-only inspection; avoid claiming hard read-only enforcement or full lifecycle recovery.
- Tests assert bash/edit/write/intercom and custom tools survive startup, simulated reload and reconnect without resetting extension selections. The launcher retains normal discovery. The real native Pi RPC test now enables normal discovery in an isolated agent directory, auto-loads a custom inspection tool without `-e`, verifies it reaches the supervisor's model tool schema, and still observes exact SteerWorker delivery. Its worker remains deliberately isolated with `--no-extensions`.
## Sources inspected
Installed Pi documentation: `docs/usage.md` extension/resource discovery flags, `docs/extensions.md` active-tool APIs and loading, `docs/packages.md` profile scope/deduplication. Read applicable local `recommending-pi-extensions` skill for the full-permission trust boundary. No packages installed or fetched. Existing Intercom reuse/fallback code is unchanged; broker/native tests pass.
## Validation
`validation.txt` records final successful run:
```
env -u PI_GOALS_EVIDENCE_DIR -u PI_SUBAGENT_CHILD -u PI_GOALS_ROLE npm test
npm run typecheck
npm run lint
npm run build
git diff --check
```
108/108 tests in 19 files, typecheck, lint (37 files), build and diff check passed. No changes to `src/index.ts` or `src/approval.ts`; worker planning restrictions and approval checks remain intact. No supervisor BLOCKED_TOOLS, setActiveTools or tool_call enforcement remains.
## Limits and remaining acceptance
This verifies normal discovery using a deterministic local model and an isolated custom extension. It does not prove a real user's complete profile respects the role instruction. Arbitrary extensions retain their own hooks/side effects/tool policies; tools can still write if the model disregards its task. The parent still needs to run real full-profile Herdr acceptance and obtain an independent review. No panes were opened, reloaded or operated.
Issue #6 cancellation, Ready content drift, compaction delivery, fresh-shell role restoration and other lifecycle bugs are intentionally not fixed in this scoped task. Existing running supervisors retain their already-loaded profile until appropriately restarted/reloaded by their owner.
Pre-existing dirty `slop/reviews/review-fixes-native/supervisor-events.jsonl`, `worker-events.jsonl` and untracked `docs/human_journal.md` were neither modified nor staged by this task. No commits include them.
@@ -0,0 +1,26 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 19 passed (19)
Tests 108 passed (108)
Start at 12:24:25
Duration 4.69s (transform 4.90s, setup 0ms, import 9.57s, tests 12.54s, environment 3ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 37 files in 109ms. No fixes applied.
> @wassname2/pi-goals@0.2.2 build
> tsc
@@ -0,0 +1,21 @@
{"type":"extension_ui_request","id":"1b7b765d-82f4-4ac3-bd12-011f1f3227af","method":"notify","message":"supervisor model: offline/test","notifyType":"info"}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-visible-supervisor-v2","data":{"version":2,"workerSessionId":"01a080c2-dc16-705a-b544-e383580d9ac7","planPath":"/tmp/goals-native-pair-vfPu3e/plan.md"},"id":"e0a271f9","parentId":"d768c1fd","timestamp":"2026-09-08T11:24:10.287Z"}}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"in","message":{"binding":"native-pair-test","role":"worker","kind":"view","id":"cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc","text":"The worker stopped.\n\nThe saved plan needs a check of the actual outputs.\n\nworker view id: cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc","reason":"settled","backgroundQuiet":true}},"id":"848cb24d","parentId":"e0a271f9","timestamp":"2026-09-08T11:24:10.295Z"}}
{"type":"agent_start"}
{"type":"turn_start"}
{"type":"message_start","message":{"role":"user","content":[{"type":"text","text":"The worker stopped.\n\nThe saved plan needs a check of the actual outputs.\n\nworker view id: cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc"}],"timestamp":1788866650296}}
{"type":"message_end","message":{"role":"user","content":[{"type":"text","text":"The worker stopped.\n\nThe saved plan needs a check of the actual outputs.\n\nworker view id: cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc"}],"timestamp":1788866650296}}
{"type":"message_start","message":{"role":"assistant","content":[{"type":"toolCall","id":"test-steer","name":"SteerWorker","arguments":{"instruction":"Read the real outputs before declaring completion."},"partialArgs":"{\"instruction\":\"Read the real outputs before declaring completion.\"}","streamIndex":0}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"totalTokens":0,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"pending","timestamp":1788866650324}}
{"type":"message_update","assistantMessageEvent":{"type":"toolcall_start","contentIndex":0}}
{"type":"message_update","assistantMessageEvent":{"type":"toolcall_delta","contentIndex":0,"delta":"{\"instruction\":\"Read the real outputs before declaring completion.\"}"}}
{"type":"message_update","assistantMessageEvent":{"type":"toolcall_end","contentIndex":0,"toolCall":{"type":"toolCall","id":"test-steer","name":"SteerWorker","arguments":{"instruction":"Read the real outputs before declaring completion."}}}}
{"type":"message_end","message":{"role":"assistant","content":[{"type":"toolCall","id":"test-steer","name":"SteerWorker","arguments":{"instruction":"Read the real outputs before declaring completion."}}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":10,"output":10,"cacheRead":0,"cacheWrite":0,"reasoning":0,"totalTokens":20,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"toolUse","timestamp":1788866650324,"rawStopReason":"tool_calls"}}
{"type":"tool_execution_start","toolCallId":"test-steer","toolName":"SteerWorker","args":{"instruction":"Read the real outputs before declaring completion."}}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"out","message":{"binding":"native-pair-test","role":"supervisor","kind":"steer","id":"22068654-6e7c-4328-890f-9382b25c8ea7","text":"Read the real outputs before declaring completion."}},"id":"0c0166ea","parentId":"ed2e1ca2","timestamp":"2026-09-08T11:24:10.345Z"}}
{"type":"tool_execution_end","toolCallId":"test-steer","toolName":"SteerWorker","result":{"content":[{"type":"text","text":"Worker instruction 22068654-6e7c-4328-890f-9382b25c8ea7 sent through pi-intercom. Receipt and execution are not confirmed by this result."}],"details":{},"isError":false},"isError":false}
{"type":"message_start","message":{"role":"toolResult","toolCallId":"test-steer","toolName":"SteerWorker","content":[{"type":"text","text":"Worker instruction 22068654-6e7c-4328-890f-9382b25c8ea7 sent through pi-intercom. Receipt and execution are not confirmed by this result."}],"details":{},"isError":false,"timestamp":1788866650346}}
{"type":"message_end","message":{"role":"toolResult","toolCallId":"test-steer","toolName":"SteerWorker","content":[{"type":"text","text":"Worker instruction 22068654-6e7c-4328-890f-9382b25c8ea7 sent through pi-intercom. Receipt and execution are not confirmed by this result."}],"details":{},"isError":false,"timestamp":1788866650346}}
{"type":"turn_end","message":{"role":"assistant","content":[{"type":"toolCall","id":"test-steer","name":"SteerWorker","arguments":{"instruction":"Read the real outputs before declaring completion."}}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":10,"output":10,"cacheRead":0,"cacheWrite":0,"reasoning":0,"totalTokens":20,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"toolUse","timestamp":1788866650324,"rawStopReason":"tool_calls"},"toolResults":[{"role":"toolResult","toolCallId":"test-steer","toolName":"SteerWorker","content":[{"type":"text","text":"Worker instruction 22068654-6e7c-4328-890f-9382b25c8ea7 sent through pi-intercom. Receipt and execution are not confirmed by this result."}],"details":{},"isError":false,"timestamp":1788866650346}]}
{"type":"turn_start"}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"ack","message":{"binding":"native-pair-test","role":"worker","kind":"received","id":"22068654-6e7c-4328-890f-9382b25c8ea7"}},"id":"6b63b93d","parentId":"8ce5aa46","timestamp":"2026-09-08T11:24:10.348Z"}}
{"id":"supervisor-state","type":"response","command":"get_state","success":true,"data":{"model":{"id":"test","name":"Offline test model","reasoning":false,"input":["text"],"contextWindow":16000,"maxTokens":1000,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0},"api":"openai-completions","provider":"offline","baseUrl":"http://127.0.0.1:37773"},"thinkingLevel":"off","isStreaming":true,"isCompacting":false,"steeringMode":"one-at-a-time","followUpMode":"one-at-a-time","sessionFile":"/tmp/goals-native-pair-vfPu3e/agent/sessions/--tmp-goals-native-pair-vfPu3e--/2026-09-08T11-24-10-111Z_01a080c2-dfff-7290-9118-66b87ab29080.jsonl","sessionId":"01a080c2-dfff-7290-9118-66b87ab29080","autoCompactionEnabled":true,"messageCount":5,"pendingMessageCount":0}}
@@ -0,0 +1,22 @@
{"id":"planning","type":"response","command":"prompt","success":true}
{"type":"agent_start"}
{"type":"turn_start"}
{"type":"message_start","message":{"role":"user","content":[{"type":"text","text":"Retain this planning context for the supervisor fork."}],"timestamp":1788866649278}}
{"type":"message_end","message":{"role":"user","content":[{"type":"text","text":"Retain this planning context for the supervisor fork."}],"timestamp":1788866649278}}
{"type":"message_start","message":{"role":"assistant","content":[{"type":"text","text":"Test context retained. Actual outputs still need inspection."}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"totalTokens":0,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"pending","timestamp":1788866649355}}
{"type":"message_update","assistantMessageEvent":{"type":"text_start","contentIndex":0}}
{"type":"message_update","assistantMessageEvent":{"type":"text_delta","contentIndex":0,"delta":"Test context retained. Actual outputs still need inspection."}}
{"type":"message_update","assistantMessageEvent":{"type":"text_end","contentIndex":0,"content":"Test context retained. Actual outputs still need inspection."}}
{"type":"message_end","message":{"role":"assistant","content":[{"type":"text","text":"Test context retained. Actual outputs still need inspection."}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":10,"output":10,"cacheRead":0,"cacheWrite":0,"reasoning":0,"totalTokens":20,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"stop","timestamp":1788866649355,"rawStopReason":"stop"}}
{"type":"turn_end","message":{"role":"assistant","content":[{"type":"text","text":"Test context retained. Actual outputs still need inspection."}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":10,"output":10,"cacheRead":0,"cacheWrite":0,"reasoning":0,"totalTokens":20,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"stop","timestamp":1788866649355,"rawStopReason":"stop"},"toolResults":[]}
{"type":"agent_end","messages":[{"role":"user","content":[{"type":"text","text":"Retain this planning context for the supervisor fork."}],"timestamp":1788866649278},{"role":"assistant","content":[{"type":"text","text":"Test context retained. Actual outputs still need inspection."}],"api":"openai-completions","provider":"offline","model":"test","usage":{"input":10,"output":10,"cacheRead":0,"cacheWrite":0,"reasoning":0,"totalTokens":20,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"stop","timestamp":1788866649355,"rawStopReason":"stop"}],"willRetry":false}
{"type":"agent_settled"}
{"id":"worker-state","type":"response","command":"get_state","success":true,"data":{"model":{"id":"test","name":"Offline test model","reasoning":false,"input":["text"],"contextWindow":16000,"maxTokens":1000,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0},"api":"openai-completions","provider":"offline","baseUrl":"http://127.0.0.1:37773"},"thinkingLevel":"off","isStreaming":false,"isCompacting":false,"steeringMode":"one-at-a-time","followUpMode":"one-at-a-time","sessionFile":"/tmp/goals-native-pair-vfPu3e/agent/sessions/--tmp-goals-native-pair-vfPu3e--/2026-09-08T11-24-09-110Z_01a080c2-dc16-705a-b544-e383580d9ac7.jsonl","sessionId":"01a080c2-dc16-705a-b544-e383580d9ac7","autoCompactionEnabled":true,"messageCount":2,"pendingMessageCount":0}}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"out","message":{"binding":"native-pair-test","role":"worker","kind":"view","id":"cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc","text":"The worker stopped.\n\nThe saved plan needs a check of the actual outputs.\n\nworker view id: cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc","reason":"settled","backgroundQuiet":true}},"id":"57ac2295","parentId":"21d6e68a","timestamp":"2026-09-08T11:24:10.294Z"}}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"ack","message":{"binding":"native-pair-test","role":"supervisor","kind":"received","id":"cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc"}},"id":"7ffd87dc","parentId":"57ac2295","timestamp":"2026-09-08T11:24:10.295Z"}}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"ack","message":{"binding":"native-pair-test","role":"supervisor","kind":"received","id":"cf656aef-1404-4d5c-9a11-4fbd4ed5b5dc"}},"id":"b2ffeed1","parentId":"7ffd87dc","timestamp":"2026-09-08T11:24:10.335Z"}}
{"type":"entry_appended","entry":{"type":"custom","customType":"pi-goals-intercom","data":{"direction":"in","message":{"binding":"native-pair-test","role":"supervisor","kind":"steer","id":"22068654-6e7c-4328-890f-9382b25c8ea7","text":"Read the real outputs before declaring completion."}},"id":"34521c62","parentId":"b2ffeed1","timestamp":"2026-09-08T11:24:10.346Z"}}
{"type":"agent_start"}
{"type":"turn_start"}
{"type":"message_start","message":{"role":"user","content":[{"type":"text","text":"[supervisor] Read the real outputs before declaring completion."}],"timestamp":1788866650346}}
{"type":"message_end","message":{"role":"user","content":[{"type":"text","text":"[supervisor] Read the real outputs before declaring completion."}],"timestamp":1788866650346}}
@@ -0,0 +1,33 @@
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
test/goals-flow.test.ts (21 tests | 1 failed | 20 skipped) 71ms
× accepts only an approval for the exact clean commit and goal block 70ms
⎯⎯⎯⎯⎯⎯⎯ Failed Tests 1 ⎯⎯⎯⎯⎯⎯⎯
FAIL test/goals-flow.test.ts > /goals flow > accepts only an approval for the exact clean commit and goal block
AssertionError: expected false to be true // Object.is equality
- Expected
+ Received
- true
+ false
test/goals-flow.test.ts:318:38
316| const cancelled = flow.tools.get("CompleteGoal").execute("cancelled…
317| controller.abort(); // Cancel while the background-state lookup yie…
318| expect((await cancelled).isError).toBe(true);
| ^
319| expect(readFileSync(planPath, "utf8")).toBe(beforeCancel);
320| expect((await flow.tools.get("CompleteGoal").execute("already-cance…
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/1]⎯
Test Files 1 failed (1)
Tests 1 failed | 20 skipped (21)
Start at 12:28:54
Duration 734ms (transform 273ms, setup 0ms, import 544ms, tests 71ms, environment 0ms)
@@ -0,0 +1,26 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 19 passed (19)
Tests 110 passed (110)
Start at 12:30:42
Duration 3.60s (transform 4.23s, setup 0ms, import 8.38s, tests 8.31s, environment 2ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 37 files in 34ms. No fixes applied.
> @wassname2/pi-goals@0.2.2 build
> tsc
@@ -0,0 +1,33 @@
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
stdout | test/native-compaction-delivery.test.ts > real Pi preserves worker delivery through compaction success, failure and cancellation
real Pi worker/success: retained message presented once and saved, no extension errors
stdout | test/native-compaction-delivery.test.ts > real Pi preserves worker delivery through compaction success, failure and cancellation
real Pi worker/failure: retained message presented once and saved, no extension errors
stdout | test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session
Native Pi pair: fork retained planning context; SteerWorker delivered exactly: Read the real outputs before declaring completion.
✓ test/native-intercom.test.ts > runs a forked Pi supervisor and receives its exact instruction in another Pi session 2071ms
stdout | test/native-compaction-delivery.test.ts > real Pi preserves worker delivery through compaction success, failure and cancellation
real Pi worker/cancel: retained message presented once and saved, no extension errors
✓ test/native-compaction-delivery.test.ts > real Pi preserves worker delivery through compaction success, failure and cancellation 2239ms
stdout | test/native-compaction-delivery.test.ts > real Pi preserves supervisor delivery through compaction success, failure and cancellation
real Pi supervisor/success: retained message presented once and saved, no extension errors
stdout | test/native-compaction-delivery.test.ts > real Pi preserves supervisor delivery through compaction success, failure and cancellation
real Pi supervisor/failure: retained message presented once and saved, no extension errors
stdout | test/native-compaction-delivery.test.ts > real Pi preserves supervisor delivery through compaction success, failure and cancellation
real Pi supervisor/cancel: retained message presented once and saved, no extension errors
✓ test/native-compaction-delivery.test.ts > real Pi preserves supervisor delivery through compaction success, failure and cancellation 2176ms
Test Files 2 passed (2)
Tests 3 passed (3)
Start at 12:59:23
Duration 4.60s (transform 52ms, setup 0ms, import 133ms, tests 6.49s, environment 0ms)
+44
View File
@@ -0,0 +1,44 @@
# Lifecycle recovery and role-aware commands
## Scope and decisions
Continue issue #6 and the independent lifecycle review after full-profile commit `1d52857`. Keep normal extensions/tools; do not alter Git/evidence approval policy. The supervisor approved delayed role selection at session_start, a durable inbound-message record, and requiring Pi 0.85.1 instead of maintaining a 0.84 compatibility retry layer. The user additionally authorized `work`, `supervise`, and `noplan` recovery commands.
`138bde5` already committed/pushed the first increment: CompleteGoal cancellation and Ready content stability. Remaining changes build on it, not replace it.
## Fixes
- CompleteGoal checks its signal before/after the asynchronous background lookup and before persistence; stale binding/version/phase or a disposed runtime also rejects. Cancelling one call leaves the plan active. `cancellation-before.txt` records a regression failure against the earlier implementation (it returned success after abort); the updated test verifies no tick/sign-off marker is written and a later valid call still works.
- Ready checks the displayed plan content before launch, after launch, after worker-model restoration and after the first view. A changed plan returns to planning using the existing pane; it does not start the changed implementation. Tests mutate content at launch and model restoration, then select Ready again without another pane.
- Real supervisor and worker sessions now select their role when session entries are available, before registering either role's handlers. A complete supervisor marker (worker, owner, plan path, approval binding) is written before model restoration/compaction. Persisted identity wins over launch environment. Legacy bootstrap markers migrate only with an existing pairing; incomplete records throw visibly without enabling worker mode. Stopped supervisor forks retain their identity. No tool denylist was reintroduced.
- Intercom saves each incoming non-started view/steer in a bounded inbox before calling Pi. It acknowledges only a matching user message_start. That is **session acceptance**, not model judgment or action execution. Unconfirmed payloads are restored from the active branch on reload; separate incremental views are retained rather than overwritten. A pending Pi queue is not re-enqueued while waiting for presentation. Completed/detached bindings and shutdown cancel delivery timers.
- Pi 0.85.1 has a public session_compact_failed event and fixes isIdle to include manual compaction; repo 0.84.1 did not. The minimum peer and exact dev version are now 0.85.1. Installation used `--ignore-scripts --no-audit --no-fund`; no global Pi change. Success/failure/cancel events resume retained context. Since session_compact precedes final controller cleanup, delivery waits for compaction-aware idle state; it never probes by sending a prompt during compaction. Waiting is bounded to 300 one-second idle checks with retained payload and a visible reconnect instruction on exhaustion, not a deadline that interrupts the model.
- Readiness/reconnect paths allow five minutes rather than five seconds. Reload while an inherited compaction is active waits for it rather than starting a second one. An existing last compaction or Pi's Already compacted/Nothing to compact result can proceed to bootstrap. Startup model/compaction failure is communicated through the existing hello so the worker sees the cause promptly. A later ready hello clears the failure.
- An established worker pairing republishes one fresh current view when disconnected→connected, including after supervisor-only reload where the old stopped view had already been accepted. This reuses the connection callback; Ready retains its own initial publication and session_start/reconnect no longer separately publish duplicates. Cleared/completed sessions do not restart monitoring.
- A started-worker view now reports that work is running instead of falsely claiming a newer review is queued for delivery.
## Command meanings
- `/goals work`: existing approved worker session reconnects its saved pairing/model; no new plan, pairing or model fallback. Missing/unapproved pairing is rejected.
- `/goals supervise`: existing saved supervisor reconnects its role/model/pairing. Running it in a worker session is rejected rather than converting the role.
- `/goals noplan`: leave planning restrictions and preserve the draft/history without Ready, implementation, supervisor launch or file deletion. In-flight Ready is invalidated. It does not claim the retained draft was approved.
- `/goals reconnect` remains generic recovery; `/goals restart` explicitly replaces only the tracked pane and invalidates the prior binding; `/goals clear` closes/disconnects while retaining the plan file.
## Runtime validation actually observed
`native-validation.txt` is fresh verbose output from installed Pi 0.85.1 with a local deterministic HTTP model; no credentials or model credits used.
1. Real Pi worker and supervisor delivery during manual compaction: success, local model failure and cancellation, six cases total. Each retained payload is presented exactly once and saved in the session; no extension_error events. The transport in this fixture is deterministic, while Pi owns the real compaction and prompt lifecycle. Success uses an extension-provided summary; failure exercises Pi's HTTP summarization failure. These are not rendered Herdr sessions or 60-second real-model runs.
2. Real native Pi/Intercom pair: full-profile discovery in an isolated agent directory, exact steering delivery, then supervisor termination and fresh-shell `--session` resume with role/binding launcher environment removed. The resumed model sees SteerWorker/ApproveGoal and the discovered profile tool, not CompleteGoal, and retains the supervisor opening. No second supervisor pairing is constructed.
Hook tests additionally cover a simulated 60-second inherited compaction without competing compaction, five-minute Ready/reconnect patience, immediate reported failure plus rejoin, retained distinct deltas through reload, delayed presentation without duplicate enqueue, role migration/incomplete identity, cancelled completion, Ready content drift, and command semantics. Existing paired tests cover symmetric reconnect/model restoration. The accepted-view reconnect regression checks one new view ID and unchanged-payload replay deduplication separately; cleared/completed pairings produce no new view. The tests model `/reload` with new extension instances or saved state; no real interactive `/reload` command was exercised in this task.
Final `validation.txt`: 123 tests in 22 files, typecheck, lint, build, and diff check pass. Native fixture initially could not compact a single retained turn; it now seeds two sufficiently sized turns. This corrected fixture setup is not counted as a product failure. No test processes from earlier runs remained when resuming after timeout; all processes started by these tests were shut down.
## Limits and remaining acceptance
The parent must still run full-profile Herdr acceptance: actual reloads in both orders, drafting/Ready/checkpoint interruption, stopped pair resume, real-model long compaction, and an unmet-outcome correction followed by both sign-offs. Automated session acceptance does not establish judgment quality or cheaper-worker success.
The inbox holds at most 64 messages; overflow is visible and unacknowledged. Arbitrary extensions that rewrite or consume injected user messages can defeat exact-text acceptance matching; crashes between message_start and message persistence can require review/replay. This is not an exactly-once execution guarantee or a general durable model queue. Role instructions remain the only prohibition on supervisor writes. Existing all-cancelled completion behavior and Git-tracked verification policy are unchanged.
No user or test Herdr panes, research sessions, human journal, or pre-existing dirty native evidence logs were operated/read/edited by this task. Changes to package-lock reflect the approved local Pi dependency upgrade. This report does not claim all issue #6 behavioral acceptance is complete.
@@ -0,0 +1,26 @@
> @wassname2/pi-goals@0.2.2 test
> vitest run
RUN v4.1.9 /home/code/.pi/agent/git/github.com/wassname/pi-goals
Test Files 22 passed (22)
Tests 123 passed (123)
Start at 13:08:28
Duration 4.90s (transform 5.07s, setup 0ms, import 11.10s, tests 11.14s, environment 4ms)
> @wassname2/pi-goals@0.2.2 typecheck
> tsc --noEmit
> @wassname2/pi-goals@0.2.2 lint
> biome check src/ test/
Checked 41 files in 77ms. No fixes applied.
> @wassname2/pi-goals@0.2.2 build
> tsc
@@ -0,0 +1,43 @@
# Question
How can `pi-goals` become simpler and more robust while preserving the recorded user preferences, especially around compaction, a visible supervisor, recovery, and retained worker/supervisor context? Propose architectural reductions and discriminating checks. Do not choose a winner.
Mode: independent scientific brainstorm.
Reconstruct the situation from the supplied evidence. Propose distinct mechanisms, including an implementation error, an objective or gradient mismatch, and an unintended learning dynamic when relevant. For each, give a falsifiable prediction and the cheapest discriminating check. State what is observed versus inferred. Do not choose a winner.
## Observed facts
1. The product is one implementation worker Pi session plus a visible, separate supervisor Pi session in a Herdr pane. The supervisor is supposed to retain high-level judgment cheaply, while the worker keeps full context.
2. User preferences in `AGENTS.md` say: supervisor messages and thinking must be visible; it should supervise autonomously, inspect actual evidence, steer through the worker rather than take over implementation, preserve normal tools/extensions, and add short judgmental recaps rather than repeated unchanged status.
3. The worker has an explicit plan state with `planning | working`, `supervised | solo`, an approval binding, plan version, sign-offs, a model role manager, and pi-intercom handshake/recovery.
4. Recent fixes added: safe bare `/goals` menu; explicit `/goals plan <objective>` replacement; bounded hello retry (initial plus two retries); retained newest disconnected steer; complete signed-off plans remain paired; loud solo fallback only after an approved plan and supervisor failure; `CompleteGoal` blocked in solo.
5. Current pre-fork behavior: if worker context tokens are known below 100k, no manual compaction occurs. At or above 100k, worker calls core `ctx.compact(customInstructions)` before spawning the supervisor fork. The supervisor sees inherited compaction and skips a second startup compaction. Unknown usage attempts compaction and accepts Pis `Already compacted` / `Nothing to compact` errors as benign.
6. Current supervisor also calls core `ctx.compact` on its own settled turns at 100k. The code only uses the Pi API and ordinary compaction events; it does not depend on `pi-better-compaction` internals.
7. A real isolated Herdr UAT with `pi-better-compaction` loaded completed Ready → visible supervisor → worker artifact → supervisor verification/approval → worker CompleteGoal. Before the short-context threshold skip, Pi visibly printed `Error: Compaction failed: Nothing to compact (session too small)` despite continuation; the threshold skip removed that observation in the rerun.
8. Field report: a supervisor attempted to send an overnight instruction after the worker disconnected, generated repeated long status narration, and could not deliver. The new code keeps only the latest instruction and replays it after reconnect, but an ended worker session still requires reload/restart to return.
9. Field report: worker provider rate limits can appear stuck; supervisor compaction can time out. A timeout is not proof of a permanent failure. The chosen policy preserves the plan and makes an eventual solo fallback loud; it must not infer approval from a draft, cancellation, plan change, or worker model error.
10. User sometimes uses `pi-better-compaction` and custom compaction extensions. Avoid assumptions about their internal state or adding another compaction framework.
## Short relevant excerpts
> “the hope is we can have a smart supervisor like you, with judgment and context. But it doesn't use many tokens as it checks in and sees an overview.” — project `AGENTS.md`
> “all supervisor thinking and messages should be visible.” — project `AGENTS.md`
> “Keep brief visible recaps that add judgment rather than repeat unchanged status.” — project `AGENTS.md`
> “Each review repeats the short supervisor opening and current plan outcome … Startup and compaction repeat the longer role prompt and full active plan before appendices/history.” — project `AGENTS.md`
> `compactApprovedWorker`: skip known `< 100k`; otherwise `ctx.compact({ customInstructions: workerCompaction(...) })`; accept `Already compacted` / `Nothing to compact`. — `src/index.ts`
> Supervisor startup skips compaction if inherited context ends in a `compaction` entry or known tokens are below 100k. — `src/supervisor-session.ts`
## Constraints
- Keep two visible sessions and a separate read-only-by-role supervisor; do not replace it with a stateless subagent.
- Preserve explicit plan approval and evidence/sign-off checks.
- Prefer deletion and one source of truth over new modes, retries, background services, or option matrices.
- Do not silently substitute a model or pretend delivery/recovery succeeded.
- Do not prescribe a particular queue, research setup, or compaction extension.
- Suggestions must be testable in a small isolated Herdr scenario and should identify what can be removed.
@@ -0,0 +1,62 @@
# Research: pi-goals simplicity and robustness — independent advisor brief
Mode: independent scientific brainstorm. No winner is chosen. All material claims about the system are quoted from the supplied brief (`/tmp/claude-1000/moa_brainstorm_pi_goals_simplicity.md`).
## 1. Reconstruction: observed vs inferred
**Observed (stated in the brief):**
- Architecture: one implementation worker Pi session plus a "visible, separate supervisor Pi session"; the supervisor is meant to "retain high-level judgment cheaply, while the worker keeps full context."
- Compaction policy: "if worker context tokens are known below 100k, no manual compaction occurs. At or above 100k, worker calls core `ctx.compact(customInstructions)` before spawning the supervisor fork." "Unknown usage attempts compaction and accepts Pi's `Already compacted` / `Nothing to compact` errors as benign." "Supervisor startup skips compaction if inherited context ends in a `compaction` entry or known tokens are below 100k." The supervisor additionally "calls core `ctx.compact` on its own settled turns at 100k." Code "does not depend on `pi-better-compaction` internals."
- Prior UAT behavior: "Pi visibly printed `Error: Compaction failed: Nothing to compact (session too small)` despite continuation; the threshold skip removed that observation in the rerun."
- Plan machinery (observed, under-specified): `planning | working`, `supervised | solo`, approval binding, plan version, sign-offs, model role manager, pi-intercom handshake/recovery; recent fixes including "loud solo fallback only after an approved plan and supervisor failure; `CompleteGoal` blocked in solo"; policy "must not infer approval from a draft, cancellation, plan change, or worker model error."
- Field reports: "a supervisor attempted to send an overnight instruction after the worker disconnected, generated repeated long status narration, and could not deliver"; "The new code keeps only the latest instruction and replays it after reconnect, but an ended worker session still requires reload/restart to return." Also: worker provider rate limits "can appear stuck"; "supervisor compaction can time out"; "A timeout is not proof of a permanent failure."
- User constraints: two visible sessions and a separate read-only-by-role supervisor must stay; explicit plan approval and evidence/sign-off checks must stay; "Prefer deletion and one source of truth over new modes, retries, background services, or option matrices"; no silent model substitution or pretended delivery; nothing prescribed about queue, research setup, or compaction extension.
**Inferred (my reconstruction, not in the brief):**
- The 100k figure is an un-sourced constant; nothing in the brief ties it to any Pi capability, so it is a policy choice, not a measured limit.
- "Known tokens" implies an estimate channel that can be absent or stale ("Unknown usage" is explicitly handled), so the two skip conditions are evaluated against a snapshot, not actual context.
- The supervisor's "retained judgment" is bounded by a sliding window: its own context is compacted at the same 100k, and per the brief, "Startup and compaction repeat the longer role prompt and full active plan before appendices/history" — i.e., after compaction the supervisor's working set is the prompt plus plan text, not the evidence it previously inspected.
- Visibility is a feature ("all supervisor thinking and messages should be visible") but it also makes every supervisor retry user-visible noise; the field report's "repeated long status narration" is consistent with the retry/replay policy and is not necessarily evidence the model is talkative.
- The solo-fallback conditions imply a state-space gap: pre-approval supervisor failure leaves a `supervised`-mode worker with no legal exit (no solo, no `CompleteGoal`, no termination) unless external restart.
## 2. Mechanism A — implementation error: compaction gating is computed from a snapshot and a marker that can diverge from real context
The skip logic has two inputs: a token estimate and "inherited context ends in a `compaction` entry." The marker is fragile — any post-compaction append (handshake, steer replay, appended appendices/history) flips it, so the supervisor attempts startup compaction against an already-compacted small context. That is the most natural reading of the prior UAT artifact: "Pi visibly printed `Error: Compaction failed: Nothing to compact (session too small)` despite continuation" — a cosmetic consequence of marker mismatch, not real need, which is also consistent with the rerun after the threshold skip. Separately, "Unknown usage attempts compaction and accepts Pi's `Already compacted` / `Nothing to compact` errors as benign" lumps at least three distinct outcomes under one benign label; a genuinely failed compaction inside a large context (the field report shows remote operations that "can appear stuck" or time out) would be swallowed and the session would proceed silently degraded.
**Falsifiable prediction (A):** (i) In two otherwise identical small-context UAT forks where one inherited context ends in a `compaction` entry and the other has one benign message appended after it, the second produces a spurious supervisor startup-compaction attempt with the "Nothing to compact" error and the first produces none — i.e., the error's presence tracks the last-entry marker, not context size. (ii) A deliberately failed `ctx.compact` on a large context is treated as benign and the session continues with an oversized, un-compacted context (later visible as truncation or a provider error attributed to something else).
**Cheapest discriminating check:** Two micro-forks as above; count startup-compaction attempts and capture the printed error in each. Then one large-context fork with `ctx.compact` stubbed to fail; observe whether the failure is swallowed and the session proceeds. If (i) holds, the marker condition is the error source and should be deleted; if (ii) holds, the benign-error conflation is the error source. (This discriminates from Mechanism B because A predicts behavior at compaction events, while B predicts approval-vs-content decoupling.)
**What can be removed:** the supervisor's entire startup-compaction decision (the marker check plus the "known tokens" branch). One compaction authority — the worker, before the fork — is a single source of truth; supervisor startup never compacts, deleting one code path, one branch, and the "Nothing to compact" observation class entirely, per "Prefer deletion and one source of truth."
## 3. Mechanism B — objective/gradient mismatch: "cheap, brief supervisor" and "inspect actual evidence" optimize in opposite directions, and the gradient favors cheapness
The stated design gradient is token frugality and brevity: "the hope is we can have a smart supervisor like you, with judgment and context. But it doesn't use many tokens as it checks in and sees an overview" and "Keep brief visible recaps that add judgment rather than repeat unchanged status." The hard requirement is the opposite gradient: the supervisor should "inspect actual evidence" and "must not infer approval from a draft, cancellation, plan change, or worker model error." But the supervisor's own history is compacted at 100k and after compaction it is re-seeded with "the longer role prompt and full active plan before appendices/history." So under context pressure the evidence basis for a sign-off narrows to whatever arrived after the last compaction, and the only durable cross-turn signals are plan-state markers (plan version, sign-offs). The optimizer (the design) pushes toward cheap check-ins that read markers; robust verification of artifact content costs tokens the design explicitly avoids spending.
**Falsifiable prediction (B):** Approval decisions on defect-injected artifacts are recency-correlated: a defect located in material older than the supervisor's last compaction is missed at a higher rate than an identical defect in material arriving after it, holding everything else fixed; equivalently, sign-off outcomes correlate with plan-state markers and with recency, not with artifact content, and the miss rate is higher when the supervisor checks just after its own 100k compaction than when it checks on a fresh session.
**Cheapest discriminating check:** Two UAT forks over the same defect-injected artifact pair: (1) fresh supervisor, (2) supervisor pushed just past its own 100k compaction. Compare sign-off outcomes split by whether the defective material predates the compaction. A recency-correlated error pattern supports B; a flat pattern across both forks refutes it. This is also the cheapest test of the constraint "must not infer approval from a draft" — if approvals do track marker state, that constraint is already being violated by the post-compaction supervisor.
**What can be removed:** the supervisor's own 100k settled-turn compaction. If the supervisor's memory window is aligned with plan boundaries (the worker's planned compaction) instead of an arbitrary token count, evidence survives until the next plan checkpoint and verification has something to actually inspect. Removing this site also removes one "timeout"-prone compaction call from the supervisor path.
## 4. Mechanism C — unintended learning dynamic: the replay policy produces an unbounded, self-reinforcing narration loop that only external restart terminates
Observed: "a supervisor attempted to send an overnight instruction after the worker disconnected, generated repeated long status narration, and could not deliver"; the fix "keeps only the latest instruction and replays it after reconnect, but an ended worker session still requires reload/restart to return." Inferred dynamic: with delivery impossible, the replay policy guarantees re-emission; the conservatism policy ("must not infer approval from a draft, cancellation, plan change, or worker model error") plus the requirement that the loop not "pretend delivery/recovery succeeded" leaves no terminal condition short of external restart; and because "all supervisor thinking and messages should be visible," every re-emission is displayed. The model receives no discriminating signal between "steer delivered, ack lost" and "steer not delivered," so the only action available under non-delivery is to re-emit — and with nothing new to say, the recap fills its own space, which is exactly the observed "repeated long status narration." The system is softly shaped toward verbose re-emission as the sole available action; length becomes the only proxy for persistence. This is a fixed point: convergent only at external kill.
**Falsifiable prediction (C):** In UAT with the worker killed after handshake: (i) the supervisor loop never self-terminates (unbounded retries until external kill); (ii) outbound message length is non-decreasing across attempts; (iii) the same growth occurs with a live worker but a deliberately dropped ack — showing the loop is ack-driven, not worker-death-driven.
**Cheapest discriminating check:** Instrument outbound supervisor message length per attempt in the killed-worker fork and count iterations until external kill; repeat with a dropped-ack live worker. If either loop self-terminates, the policy already has a hidden exit and the field report needs another explanation; if both run unbounded, the missing terminal condition is confirmed. (Discriminates from A and B: C predicts loop dynamics independent of context size and of artifact content.)
**What can be removed:** the replay buffer and the retry loop. Replace "keep the latest instruction and replay" with a single admitted delivery attempt plus one visible terminal emission (e.g., "supervisor cannot deliver; worker session is gone; awaiting reload") issued once, then silence. The steer itself should live in the plan object — the worker's only durable state — rather than in a separate replay buffer: one source of truth, deleted retry machinery.
## 5. Boundary observation with its own cheap check (not a fourth mechanism, no winner implied)
Inferred from "loud solo fallback only after an approved plan and supervisor failure; `CompleteGoal` blocked in solo": a supervisor failure before plan approval leaves a `supervised`-mode worker with no legal transition. **Prediction:** kill the supervisor pre-approval in UAT; the worker neither transitions to solo, nor completes, nor terminates within a fixed window. **Cheapest check:** the kill scenario above, logging state transitions; neither A, B, nor C predicts a legal exit for this state, so a pass is a design-gap signal whoever "wins."
## Sources
- Kept: the task brief (`/tmp/claude-1000/moa_brainstorm_pi_goals_simplicity.md`) — sole source; per Mode instruction no repository files, journal, or browsing were used, and no claims beyond it were made.
- Dropped: none (no external material consulted).
## Gaps
- Not sourced: why 100k was chosen (measured capability vs arbitrary constant); how often the token estimate is stale/unknown; any detail of the model role manager; any detail of pi-intercom's ack semantics (the C checks assume an ack exists and can be dropped — worth confirming in the scenario).
- Next steps: run checks A(i)/A(ii), B, and C(iiii) as small isolated Herdr forks; each is designed to refute its mechanism, and none requires new infrastructure beyond logging outbound supervisor message length and compaction-event counts.

Some files were not shown because too many files have changed in this diff Show More