Record user intent for visible supervision

User wording with spelling and punctuation corrected. Preserve prior design discussion separately.

Co-Authored-By: Pi/OpenAI <288921227+claudypoo@users.noreply.github.com>
This commit is contained in:
wassname
2026-09-08 07:52:47 +08:00
co-authored by Pi/OpenAI
parent 6b641c7d17
commit 4ebb4d127b
+23 -1
View File
@@ -15,7 +15,29 @@ Run `npm test` before a commit. It includes unit and flow tests plus the RPC rev
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`.
## Intended supervision workflow
## 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)
## 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.