feat: polish OpenPI UI and stabilize delegate tools - #52
Merged
Conversation
Three full-screen views had each grown their own copy of the same chrome and drifted apart in the details you notice without being able to name: one framed the body in `border`, another in `borderMuted`; one wrote `... 3 more`, another `… 3 more`; hints were a single dim run in which the keys you are meant to press read exactly as faint as the prose describing them. extensions/shared/screen-chrome.ts owns that vocabulary now — screenTitleLine, panelFrame, hintLine, overflowNote — and /subagents, /ps, /workflows, /tasks, the changed-files view, the sessions picker and ask-user all render through it. Keys read a step brighter than their labels, pre-styled labels are passed through instead of repainted, and every added hint row is paid for out of the body so no overlay grew. Quieter status colour below the editor: renderNavigationMetrics paints the metrics tail muted while a run is healthy and borrows the status colour only for the one count that carries a settled outcome. The tasks census drops its bold/dim zebra and its always-zero segments for colour-coded chips (`4 tasks · 3 done · 1 in progress`), and one STATUS_COLOR map ends the widget/list disagreement over what colour in-progress work is. Migrated onto 0.3.1 rather than over it: the subagent dashboard keeps upstream's content-fit height, spinner, activity labels and metadata shedding, and the takeover view keeps its three-rule chrome; only the frame and the hint styling come from the shared module.
The session picker was the last place still painting frames with `border` while its own split-pane frame, the scrollbar's neighbours, and every other OpenPI panel had moved to `borderMuted` — so the compact picker's outer frame and the preview scrollbar read a shade louder than the pane they belong to. A token inventory found these four call sites were the only `border` uses left in the package.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
delegatefamily in one capability load, keeping the model-facing tool schema stable across spawn, settle and cancelWhy
OpenPI should progressively disclose tools at capability boundaries, not at short-lived resource-state boundaries. Once
delegateis loaded, spawning the first subagent should not trigger a second tool-schema change and another avoidable cache rewrite.Validation
bun run check— passed (existing Effect typecheck warnings only)bun run test— 752 Node tests passed, 29 Vitest tests passedorigin/mainwith 3 scoped commitsManual verification
The local Pi development runtime is installed from this branch. A final
/reloadsmoke should confirm the new visual treatment and that spawning after loadingdelegatedoes not expand the active tool set again.