docs(fleet): refine Mosaic Platform PRD per Jason's review (R1–R7)
All checks were successful
ci/woodpecker/push/ci Pipeline was successful
All checks were successful
ci/woodpecker/push/ci Pipeline was successful
Post-review refinements to the DRAFT PRD set (decisions D1–D12 unchanged): - R1: PRD-permission-relay is now self-contained — its cited design source (guard-rails-capability-permissions.md) is absent from origin/main, so the essential model (prepare-freely/execute-with-approval, permission levels, resource:action grants) is folded in as the authoritative spec. - R2: Phase-1 conversation channel is tmux/CLI via the f4 Phase-1 tmux connector (operator issues /remote-control); Matrix room (J5/K1) is Phase 2. - R3: Jarvis is a Level-0 orchestrator (delegation + subagents, never executes coding/infra); AC-NS-8 latency isolation is a separate-model-capacity guarantee, not just a separate process (NS-10, AC-NS-8, ASM-5). - R4: jarvis-brain reframed as the P0 (prototype) Mosaic Stack; tenant-1 migration targets the proper stack storage layer (vector DB + enhanced memory + flat-file backends). Agent memory/runbooks migrate live into the memory subsystem and are NOT frozen; repo retires read-only only after both PA data and agent memory are verified migrated (X2/X-R7). - R5: homelab→USC promotion is an explicit owner sign-off gate, not an automated metric (X deployment-scope). - R6: verified K1 is covered by f4-matrix-connector.md Phase 2 (no new doc). - R7: clarified always-available Opus ≠ standing cost (idle = no bill) (J-R2). - Also normalized PRD-backlog-providers.md and PRD-webui-fleet-control.md with prettier (whitespace-only) — they were non-conformant as originally pushed and would have re-broken repo-wide format:check on merge. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RMoEx7hfdFGjUiCHuN1RRi
This commit is contained in:
Jason Woltje
@@ -7,45 +7,52 @@
|
||||
|
||||
The trial runs in the **homelab**. Hermes and the primitive-era stack (`mos-claude.service`, jarvis-brain boards) live in the **USC/web1 environment**, which is untouched during the trial. This workstream therefore lands in two stages: **X-in-homelab** (prove parity where the fleet is native — mainly K/P/Q verification plus tenant-1 migration) and **X-at-USC** (post-trial adoption: apply the parity checklist to web1, migrate Mos-on-web1 to `mosaic-agent@orchestrator`, then decommission Hermes there, with `/src/infrastructure` GitOps updates in the same delivery set).
|
||||
|
||||
**Trial go/no-go (D12/ASM-9 gate):** the homelab→USC promotion is **owner-judgment**, not an automated metric. The stage gate is: _Jason instantiates and operates the split-agent stack in the homelab and is satisfied with its operation._ Only on that explicit sign-off does X-at-USC begin. The capability ACs (AC-NS-8…11) are the evidence Jason weighs; they inform the decision but do not auto-trigger USC deployment.
|
||||
|
||||
## Mission
|
||||
|
||||
Retire Hermes entirely. Mosaic becomes the platform for transport (Matrix connector), task board (native backlog + webUI/adapters), approvals (permission relay), and multi-platform reach (mautrix bridges). In the same arc, Jason's jarvis-brain flat-file data migrates into the product as **tenant #1**, making the product's PA feature set the dogfooded default.
|
||||
|
||||
## Parity map (what replaces what)
|
||||
|
||||
| Hermes function | Mosaic replacement | Workstream |
|
||||
|---|---|---|
|
||||
| Messaging bridge (Discord/Telegram/…) | Matrix connector + mautrix bridges | K1, K2 |
|
||||
| Kanban / task board | Native Mosaic Backlog + webUI board + provider adapters | A*, Q, W3 |
|
||||
| Permission relay (`permissions_*`) | Guard-rails engine + approval queue (Matrix + webUI) | P1–P3 |
|
||||
| Cross-platform user reach | mautrix bridges (agents speak Matrix only) | K2 |
|
||||
| Hermes MCP tools in agent sessions | Mosaic-native equivalents (gateway API / MCP) | J2, Q1 |
|
||||
| Hermes function | Mosaic replacement | Workstream |
|
||||
| ------------------------------------- | ------------------------------------------------------- | ---------- |
|
||||
| Messaging bridge (Discord/Telegram/…) | Matrix connector + mautrix bridges | K1, K2 |
|
||||
| Kanban / task board | Native Mosaic Backlog + webUI board + provider adapters | A\*, Q, W3 |
|
||||
| Permission relay (`permissions_*`) | Guard-rails engine + approval queue (Matrix + webUI) | P1–P3 |
|
||||
| Cross-platform user reach | mautrix bridges (agents speak Matrix only) | K2 |
|
||||
| Hermes MCP tools in agent sessions | Mosaic-native equivalents (gateway API / MCP) | J2, Q1 |
|
||||
|
||||
## Requirements
|
||||
|
||||
### Parity checklist + cutover plan (X1)
|
||||
|
||||
| ID | Requirement |
|
||||
|---|---|
|
||||
| ID | Requirement |
|
||||
| ---- | ------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| X-R1 | A written, testable parity checklist per row above; each item verified in production before its Hermes counterpart is disabled. |
|
||||
| X-R2 | Cutover is staged with rollback at every stage; Hermes runs untouched until AC-NS-11 is verified (ASM-8). |
|
||||
| X-R3 | The Matrix charter's live-cutover rules apply: stated window, announce before/after, rollback ready. |
|
||||
| X-R2 | Cutover is staged with rollback at every stage; Hermes runs untouched until AC-NS-11 is verified (ASM-8). |
|
||||
| X-R3 | The Matrix charter's live-cutover rules apply: stated window, announce before/after, rollback ready. |
|
||||
|
||||
### Tenant-1 migration (X2)
|
||||
|
||||
| ID | Requirement |
|
||||
|---|---|
|
||||
| X-R4 | One-shot migrator: `data/projects/*.json`, `data/tasks/*.json`, `data/events/*.json`, `data/tickets.json`, and knowledge-worthy docs → the Jason workspace (Project/Task/Event/KnowledgeEntry entities), preserving ids in metadata for traceability. |
|
||||
| X-R5 | Dry-run mode with a diffable report; Jason ratifies the report before the real run (canonical-data gate — this is the one migration step that is his call). |
|
||||
| X-R6 | External sync jobs (GLPI, Google Calendar, ICS, Gmail) are re-pointed to product integrations; each re-point verified before the flat-file sync job is retired. |
|
||||
| X-R7 | jarvis-brain repo is archived read-only after cutover (history preserved); generated views and brain.py retire. Agent meta-observation flow (OpenBrain/OpenViking) is unaffected — it was never Hermes. |
|
||||
**Framing (ratified 2026-07-09):** jarvis-brain **is the P0 (prototype) Mosaic Stack** — its flat-file data layer is the zeroth implementation of what the product does properly. Migration is therefore _P0 → proper Mosaic Stack_, whose storage layer is **pluggable: vector DB + enhanced memory service + flat-file storage backends**. Two distinct data classes migrate into that layer — they are not the same destination and neither is frozen:
|
||||
|
||||
- **(a) PA data** (projects, tasks, events, tickets, knowledge) → product entities in the Jason workspace (Project/Task/Event/KnowledgeEntry), on the relational + flat-file backends.
|
||||
- **(b) Agent memory & operational knowledge** (runbooks, digests, scratchpads, OpenBrain thoughts) → the proper stack's **enhanced memory subsystem (vector DB + memory service)**. This flow stays **live and writable** throughout — it was never Hermes and must not be frozen by the PA cutover.
|
||||
|
||||
| ID | Requirement |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| X-R4 | One-shot PA migrator: `data/projects/*.json`, `data/tasks/*.json`, `data/events/*.json`, `data/tickets.json`, and knowledge-worthy docs → the Jason workspace entities, preserving ids in metadata for traceability. |
|
||||
| X-R5 | Dry-run mode with a diffable report; Jason ratifies the report before the real run (canonical-data gate — this is the one migration step that is his call). |
|
||||
| X-R6 | External sync jobs (GLPI, Google Calendar, ICS, Gmail) are re-pointed to product integrations; each re-point verified before the flat-file sync job is retired. |
|
||||
| X-R7 | Agent memory/operational knowledge (b) is migrated into the proper stack's memory subsystem **before** any jarvis-brain retirement; the memory write path stays continuously available (no read-only freeze of an active substrate). Only once **both** (a) and (b) are migrated and verified is the jarvis-brain repo retired read-only (history preserved); generated views and brain.py retire. This closes the P0 prototype. |
|
||||
|
||||
### Decommission (X3)
|
||||
|
||||
| ID | Requirement |
|
||||
|---|---|
|
||||
| ID | Requirement |
|
||||
| ---- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| X-R8 | Hermes services stopped, disabled, and removed from infra (GitOps: `/src/infrastructure` updated in the same delivery set); credentials revoked; MCP registrations removed from agent runtimes. |
|
||||
| X-R9 | 30-day observation window between stop and removal; any regression flips back per X-R2 rollback. |
|
||||
| X-R9 | 30-day observation window between stop and removal; any regression flips back per X-R2 rollback. |
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
|
||||
Reference in New Issue
Block a user