mosaicstack/stack
1
0
Fork 0
Code Issues 81 Pull Requests 1 Actions Packages Projects Releases 15 Wiki Activity

EPIC: Agent Roster + webUI oversight + health watch #796

New Issue
Open
opened 2026-07-16 20:11:17 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-07-16 20:11:17 +00:00
Owner
Copy Link

Epic: Agent Roster + webUI oversight + health watch

Origin: Jason (Discord 2026-07-16 20:01–20:02Z) via Mos. Design-first — this epic tracks design
before any implementation. Priority is below the current MS delivery queue (M5-001 design pivot >
#790 > #791 > #792 > this epic's design phase) unless reprioritized.

Goal

Give every orchestrating agent an always-current roster of the agents it leased/launched, and surface
the live fleet in the webUI for oversight and immediate human intervention — plus a health watch that
alerts on silent service failures.

Sub-issues

  1. Roster data model + event-driven update protocol — every orchestrating agent maintains a roster
    of agents it leased or launched; the Orchestrator (Mos) roster spans all Team-Lead and 1st-class
    sessions. The roster must stay current at all times — event-driven on spawn/kill/lease, not
    periodic polling.
  2. webUI: alias tabs + hierarchy master table + terminal embed — tabbed UI, one tab per
    orchestration agent, tab label = the agent ALIAS (Mos, Mosaic, U-Connect, Flow, …) — never the
    system default like "Orchestrator"; the Project alias names that project's Team-Lead session. A
    Master table renders the full agent-nesting hierarchy; each row links to and opens that agent/project
    tab. Each session is embedded as a live tmux/terminal emulator for oversight + intervention.
  3. Health watch + alerting — a health checker + service health watch that alerts on failures
    like the gitea-pr-watch blackhole. (See coordination note — impl gated on enhance's Part-3.)
  4. Storage evolution: file → DB + RLS — file-form roster is acceptable now iff it is protected
    against malicious corruption (integrity/ownership/permissions); evolve to DB-centric persistence when
    better, with RLS where possible — especially in federated environments.

Coordination / overlaps (do NOT duplicate)

  • stack#791 (agents-dir protection / regen) and #792 (roster.json ENOENT) touch the same roster
    files. The new roster data model (sub-issue 1) must subsume/align with both — coordinate the
    manifest/ownership + regen work with the roster schema so they don't diverge.
  • jarvis-brain infra/fleet fleet.roster + conf files are the current file-form prior art —
    the data model should learn from / migrate that shape.
  • enhance agent's Part-3 "always-on monitoring" proposal (in flight, reports to Mos) overlaps the
    health-watch item (sub-issue 3). Do NOT start health-watch implementation until Mos forwards
    enhance's Part-3 proposal; the two efforts will be connected first.

Security (mandatory — both are secrev surfaces)

  • Roster write-path integrity: a corrupted roster = attacker-controlled terminal embeds in the
    webUI. Ownership/permissions/integrity on the file-form store; RLS on the DB form. secrev on the
    write path.
  • Terminal embed = remote code execution by design. authn/authz gating is mandatory and must be
    Authentik-fronted. secrev on the embed surface.

Acceptance (design phase)

Each sub-issue produces a design doc under docs/design/ before implementation. Standard MS gates apply
to any subsequent implementation (TDD ≥85%, independent review, secrev on the two surfaces above,
trunk-based squash PR, merge + descendant-green + issue close).

## Epic: Agent Roster + webUI oversight + health watch **Origin:** Jason (Discord 2026-07-16 20:01–20:02Z) via Mos. **Design-first** — this epic tracks design before any implementation. Priority is **below** the current MS delivery queue (M5-001 design pivot > #790 > #791 > #792 > this epic's design phase) unless reprioritized. ### Goal Give every orchestrating agent an always-current roster of the agents it leased/launched, and surface the live fleet in the webUI for oversight and immediate human intervention — plus a health watch that alerts on silent service failures. ### Sub-issues 1. **Roster data model + event-driven update protocol** — every orchestrating agent maintains a roster of agents it leased or launched; the Orchestrator (Mos) roster spans all Team-Lead and 1st-class sessions. The roster must stay current **at all times** — event-driven on spawn/kill/lease, not periodic polling. 2. **webUI: alias tabs + hierarchy master table + terminal embed** — tabbed UI, one tab per orchestration agent, tab label = the agent **ALIAS** (Mos, Mosaic, U-Connect, Flow, …) — never the system default like "Orchestrator"; the Project alias names that project's Team-Lead session. A Master table renders the full agent-nesting hierarchy; each row links to and opens that agent/project tab. Each session is embedded as a live tmux/terminal emulator for oversight + intervention. 3. **Health watch + alerting** — a health checker + service health watch that **alerts** on failures like the gitea-pr-watch blackhole. (See coordination note — impl gated on enhance's Part-3.) 4. **Storage evolution: file → DB + RLS** — file-form roster is acceptable now **iff** it is protected against malicious corruption (integrity/ownership/permissions); evolve to DB-centric persistence when better, with **RLS** where possible — especially in federated environments. ### Coordination / overlaps (do NOT duplicate) - **stack#791** (agents-dir protection / regen) and **#792** (roster.json ENOENT) touch the same roster files. The new roster data model (sub-issue 1) must **subsume/align** with both — coordinate the manifest/ownership + regen work with the roster schema so they don't diverge. - **jarvis-brain `infra/fleet`** `fleet.roster` + conf files are the current **file-form prior art** — the data model should learn from / migrate that shape. - **enhance agent's Part-3 "always-on monitoring"** proposal (in flight, reports to Mos) overlaps the health-watch item (sub-issue 3). **Do NOT start health-watch implementation** until Mos forwards enhance's Part-3 proposal; the two efforts will be connected first. ### Security (mandatory — both are secrev surfaces) - **Roster write-path integrity:** a corrupted roster = attacker-controlled terminal embeds in the webUI. Ownership/permissions/integrity on the file-form store; RLS on the DB form. secrev on the write path. - **Terminal embed = remote code execution by design.** authn/authz gating is **mandatory** and must be **Authentik-fronted**. secrev on the embed surface. ### Acceptance (design phase) Each sub-issue produces a design doc under `docs/design/` before implementation. Standard MS gates apply to any subsequent implementation (TDD ≥85%, independent review, secrev on the two surfaces above, trunk-based squash PR, merge + descendant-green + issue close).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#796
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?