@hivecast/fleet-desk (1.1.33)
Installation
@hivecast:registry=npm install @hivecast/fleet-desk@1.1.33"@hivecast/fleet-desk": "1.1.33"About this package
Agents (Fleet Desk)
Agents opens on the coding agents discovered in the home's Registry. Pick a named agent under its machine and HiveDock to read its retained conversation using the shared conversation panels. The header names its machine and project folder. Session events grow the conversation live; the input steers the shown running session, or continues it after it stops. Stop asks once in place. Both the input and Console steering use the same conversation adapter and report its disposition. The exact session status takes precedence over an older session-list projection.
Sessions and About sit beside the conversation. About reads machine, folder, model, thinking effort, repository/branch and sign-in facts from the existing worker, config, credential and development operations. Agent addresses and execution policies appear only in the existing Developer mode. Switching these tabs preserves the conversation and draft.
Work reads the home's durable tickets through system.profile. Timeline uses only filed and
transition moments recorded by the tickets service. The earlier Units and package controls stay
reachable in Advanced. No new conversation owner or recovery operation is introduced.
The browser calls profile.tickets.file, profile.tickets.list, and
profile.tickets.transition. The profile facade binds the page session to the verified home before
forwarding to system.tickets. The page follows home-scoped ticket change events, so every open
board reloads its projection when work changes without a refresh control or interval polling.
Coding-agent calls use the discovered mount and the signed-in person's existing reach; the page
does not add grants or credentials. A denied operation names the refused mount and operation in
plain words. Live transcript events use the agent's exact home-scoped event subject.
The page extends the shared dashboard ConsoleElement and exposes its console.describe,
console.select, console.act, and console.submit contract. The package name, fleet-desk
application key, mount, route, and custom-element tag remain unchanged so existing homes retain the
installed application.
Following a structured Fleet ticket
Work reads the selected worker from the ticket's execution references, not from an unrelated board machine assignment. Its details preserve the Matrix session, native session, worktree, task/attempt and check receipt, followed by separate candidate, combined and served revisions. A check reference is not a deployment claim. Watch opens the retained execution's exact agent mount and Matrix session through the existing Agents view, under the ticket's home authority. The agent must be discovered and available in that home. A missing mount/session, unknown owner or unavailable owner is stated explicitly; a matching machine or display name never substitutes another agent. Board assignment stays separate. Tickets without a central execution retain the ordinary board/dispatcher session route. Watching, closing and reopening only read the retained work; they never start a session, continue a route or reassign the ticket.
On first opening Work, a retained worker says Checking until discovery answers. Each answering worker becomes available independently: a silent neighboring agent does not hold its Watch action back. Registry lease renewals and unrelated app changes do not trigger another fleet-wide read; changed worker activations, availability and HiveDock controls still do. Refused or unavailable exact owners remain unavailable, never substituted by another worker.
In Demos → S30: Run a Fleet ticket through its owners, select the exact route
owner, ticket owner and existing ticket ID. Or explicitly file a new improvement
using the lesson's title, statement, program and package inputs; keep the returned
central ticket ID for continuation. Leave continue-work? false to read
those same central-owner facts without launching anything. Close and reopen Work
to read the retained ticket again. S30's canonical source is
applications/demos/src/catalogue/fleet-workflow.ts; semantic execution is covered
by Smithers' fleet-route.spec.mjs. tests/work-view-model.spec.ts checks the
ticket-to-view projection and repeat reads. tests/fleet-desk-over-the-bus.spec.ts
checks exact Watch navigation, transcript reads, unavailable owners and reopening
without work mutation. Use S30 with continue-work? false, then open the retained
ticket in Work and press Watch to inspect that same execution.
Related UX opportunities
Matrix-native coding fleet and agent control specifies the proposed owned-machine journey, efficient task/model allocation, visible peer messages, and discovered configuration views for harness types, instances and sessions. The research companion distinguishes existing owners from missing integration. Agents remains the work-board surface; this design does not create another queue, coordinator or standalone settings application.
Start with the incremental build-and-use plan: one explicitly placed Claude job using the existing task/attempt and custodian owners, then expose that real native worktree team before generic task matching. Do not require the Explorer first user to migrate to Codex or turn its live development checkout into a package-ticket unit. Full configuration coverage and a larger fleet are later increments, not prerequisites for the first useful job.
For that pilot's help/reply slice, use the same-worker reply refinement: qualify Claude continuation before exposing it, name the real lead/child destination, and distinguish a saved message from worker acceptance and resumed work. This is a proposed extension of the existing views, not a new conversation or notification owner.
Worktree teams sharing one integration environment uses the actual Explorer lead and native Claude workers as the first-user case. Expose parent/child, source/check and exact target relationships through the existing owners; retain native delegation and one integration-environment owner. The exact transition and assessment identify the session/child/result joins that need qualification, rather than assuming readable external sessions are already under Matrix control.
Explain suitability before assignment, then explain the wait refines the existing ticket chooser and dispatcher feedback. It separates task fit, assignment and native start; this is proposed UX for the matching increment, not shipped behavior.
Finish at the result, not just the report identifies the narrower result-projection gap: the ticket contract supports review/release references that the Work view does not carry through. It proposes read-only inspection of supported results, with source-only completion separate from opening a verified running destination. This is a bounded follow-on to the first visible job, not a new review or deployment system.
Resume the work, not merely the app and choose what deserves interruption explore returning to the actual task/attempt and keeping decisions visible without repeating background chatter. These are proposals over existing ticket, agent and Console owners, not a new work queue or a new notification authority.
Dependencies
Dependencies
| ID | Version |
|---|---|
| @open-matrix/contracts | 1.1.33 |
| @open-matrix/conversation | 1.1.33 |
| @open-matrix/core | 1.1.33 |
| @open-matrix/dashboard-components | 1.1.33 |
Development Dependencies
| ID | Version |
|---|---|
| @matrix/test-utils | 1.1.33 |
| @open-matrix/codex-agent | 1.1.33 |
| @open-matrix/hive-pm | 1.1.33 |
| @open-matrix/package-runtime | 1.1.33 |
| @open-matrix/system-platform | 1.1.33 |
| @types/node | ^25.0.10 |
| esbuild | ^0.27.3 |
| linkedom | ^0.16.11 |
| playwright | ^1.61.0 |
| tsx | ^4.15.6 |
| typescript | ^5.7.0 |