Why
This is the piece of the vision that is entirely missing and that you specifically described: a
main panel to see triggers, see the logs of each previous trigger, manage them, change settings, and
turn pi-dispatch on/off. panel/ does not exist. The design is already written
(DES-PANEL-SEPARATE-FROM-RECEIVER, specs/design.md:358) and carries a load-bearing security
correction — read it before starting.
Non-negotiable architecture (DES-PANEL-SEPARATE-FROM-RECEIVER)
- The panel is a separate process on a separate port, bound
127.0.0.1 by default. It is the admin
surface.
- The receiver must NOT carry the panel. The receiver binds
0.0.0.0 (GitHub must reach it from the
internet); mounting the admin surface there publishes the ability to change the model and rewrite
behaviour to the internet. The two have opposite reachability requirements and cannot share a port.
(This is a correction to the original DESIGN.md, which mounted Bull Board on the receiver.)
What to build (panel/)
Scope it as a checklist; the first item is shippable alone:
Explicitly out of scope for the panel (DES-FLOWS-ARE-DATA-PERSONA-IS-CODE): it does not edit
personas, skills, or hard rules — those live in the project's .pi/ and the baked guardrails, in git,
reviewed. The panel changes operational settings, not agent instructions.
Depends on
The run-history / durable logs issue (for "previous triggers + logs"). The on/off switch pairs with
the background-service issue. Observability (Bull Board) can ship as soon as the queue is drainable —
it does not need the receiver.
Acceptance
- The panel binds
127.0.0.1 only; it is not reachable on the receiver's public port.
- An operator can see waiting/active/failed jobs and open any past run's log.
- Toggling "off" stops jobs from running but does not reject new enqueues; toggling "on" resumes draining.
- Changing the model/budget in the panel affects the next job without a restart.
- The panel exposes no control that edits a persona, skill, or hard rule.
Why
This is the piece of the vision that is entirely missing and that you specifically described: a
main panel to see triggers, see the logs of each previous trigger, manage them, change settings, and
turn pi-dispatch on/off.
panel/does not exist. The design is already written(
DES-PANEL-SEPARATE-FROM-RECEIVER,specs/design.md:358) and carries a load-bearing securitycorrection — read it before starting.
Non-negotiable architecture (
DES-PANEL-SEPARATE-FROM-RECEIVER)127.0.0.1by default. It is the adminsurface.
0.0.0.0(GitHub must reach it from theinternet); mounting the admin surface there publishes the ability to change the model and rewrite
behaviour to the internet. The two have opposite reachability requirements and cannot share a port.
(This is a correction to the original
DESIGN.md, which mounted Bull Board on the receiver.)What to build (
panel/)Scope it as a checklist; the first item is shippable alone:
.claude/rules/library-first.md— do notbuild a queue dashboard) for waiting/active/failed jobs, plus a "previous triggers" view with
each run's outcome and logs, reading the run-history read model.
specs/design.md:134), i.e.queue.pause()/ worker pause, not dropping the receiver. Jobs still enqueue while paused; theyjust don't run. (Pairs with the background-service issue for the worker-side mechanism.)
Explicitly out of scope for the panel (
DES-FLOWS-ARE-DATA-PERSONA-IS-CODE): it does not editpersonas, skills, or hard rules — those live in the project's
.pi/and the baked guardrails, in git,reviewed. The panel changes operational settings, not agent instructions.
Depends on
The run-history / durable logs issue (for "previous triggers + logs"). The on/off switch pairs with
the background-service issue. Observability (Bull Board) can ship as soon as the queue is drainable —
it does not need the receiver.
Acceptance
127.0.0.1only; it is not reachable on the receiver's public port.