Skip to content

Round 5: hook relay, reply queue, runway cockpit#2

Draft
lacraig2 wants to merge 9 commits into
mainfrom
round-5-cockpit
Draft

Round 5: hook relay, reply queue, runway cockpit#2
lacraig2 wants to merge 9 commits into
mainfrom
round-5-cockpit

Conversation

@lacraig2

@lacraig2 lacraig2 commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Round-5 mobile-cockpit work, split into feature commits on top of main (round-4 was merged in).

What's here

  • feat(api) — shared data contracts (models, TS types, client surface) the rest build on.
  • feat(runway)/api/runway budget cockpit: spend vs budget per rate-limit window, burn rate, projected exhaust; subscription ceiling learned by observing limit hits; per-model context-window inference.
  • feat(hooks) — Claude Code hook relay for instant session-state events (muse hooks install), with tick de-duplication.
  • feat(autopilot) — three controller loops: end-of-turn reply queue (/api/queue), tmux layout snapshots for restore, and the limit-hit observer feeding the runway ceiling.
  • feat(slash)/-command autocomplete in the composer.
  • feat(profiles) — launch profiles from ~/.muse/profiles.toml.
  • feat(panes) — window topology (stable ids, activity, opt-in previews), grouped windows, key-combo send, layout restore.
  • feat(viewer) — reader mode, tool-run grouping, term-key input + vitest/testing-library harness.
  • feat(ui) — wires it all into the Panes/Drive/Board/Alerts pages, styles, PWA.

Notes on the split

Commits are feature-scoped. Two cross-cutting cases: the shared declaration blocks (models/types) landed together as feat(api); controller.py/store.py interleave the queue + snapshot + limit-observer loops so those cohere as feat(autopilot). The tmux router serves the slash/profile/panes endpoints and lives in feat(panes).

Tests

  • Backend: 415 passed
  • Frontend: 89 passed (17 files)

lacraig2 added 9 commits July 8, 2026 18:40
Shared shapes the round-5 cockpit features build on, landed together since
they cross the wire as one contract:
- QueuedReply/QueueView, SlashCommand, Runway* (session/window/response),
  Hooks status, Profile/ProfileParam, layout Snapshot* models
- TmuxPane gains window_id, last_activity, queued, and the split
  preview/preview_tail (heavy full screen ships only on ?previews=1)
- matching TS interfaces + api client methods
/api/runway reports spend vs budget in each rate-limit window, trailing
burn rate, and projected exhaust time. Subscription plans publish no $
ceiling, so it's learned by observation: a limit-hit records the window's
spend at that moment (usage_history.limit_hit), and the recent max becomes
the effective cap. Context-window occupancy is inferred per model from the
largest prompt seen. TTL-cached over the mtime-cached usage scan so the
cockpit can poll it cheaply.
A relay script posts Stop/Notification/etc. hook events straight to muse,
so session-state transitions surface immediately instead of waiting for the
polling tick. `muse hooks install` writes the relay + wires settings.json;
the server refreshes the endpoint file on start (port/token can change) and
keeps a recent-events ring. Hook-driven alerts suppress the tick's duplicate
for a short window so the same transition doesn't fire twice.
…erver

Three controller-loop behaviors that share the autopilot store & tick:
- Reply queue: messages queue and deliver only when a session is genuinely
  idle (turn ended, no pending menu), one batch per cooldown; /api/queue +
  QueueChips/ReplyBox drive it, hold_reason explains a held reply.
- Layout snapshots: the controller captures tmux topology on change (pruned
  history ring) so a fleet can be restored after a reboot.
- Limit observer: when a rate-limit banner appears, _observe_limit anchors
  the 5h window (on_reset) and reports the hit (on_limit) so the runway can
  calibrate its observed ceiling.
slash_commands lists a session's available Claude Code slash commands
(built-in + user-global + project-local, subdir commands namespaced with
":"); SlashMenu surfaces them as "/"-triggered autocomplete in the reply
box. Endpoint is served from the tmux router.
A profile is a reusable template for opening a new window — command, cwd,
declared params substituted as {key}, optional teardown. Adds tomli for
TOML parsing on Python < 3.11. The launch/list endpoints are served from
the tmux router.
tmux capture gains stable window ids (@<n>) and last-activity for
most-recent sort; a one-line preview_tail always ships while the full ANSI
screen is opt-in (?previews=1). The tmux router is the pane control
surface: grouped windows (safe-alphabet group names), key-combo send
(_resolve_key), window/session guards, layout snapshot restore, plus the
slash-command and profile-launch endpoints.
… harness

Reader utilities distill a raw session transcript into a clamped, readable
view; toolRuns groups consecutive tool calls; termKeys maps key combos for
sending to a pane; typeToFocus/useLongPress/useIsDesktop are the mobile
interaction primitives. ConversationView/ccInline render it. Brings up the
vitest + testing-library harness (jsdom) the round-5 tests run on.
Panes/Drive/Board/Alerts pages compose the round-5 pieces — runway bar,
queue chips, slash menu, grouped windows, reader view — into the mobile
cockpit, with the styles that back them and service-worker refinements.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant