Files
box/docs/BRIDGE_SPEC.md
T

110 lines
3.8 KiB
Markdown
Raw Normal View History

# Bridge Spec: Front-Door ↔ muse.ai Side Conversations
## Overview
Metadata bridge (not message relay) linking front-door chat channels
(muse-dev.online) to muse.ai side conversations. Operators manage via
front-door; agents work in muse.ai; the bridge provides organizational
linkage via `channel_id`.
## Architecture
```
Front-Door (muse-dev.online) muse.ai (browser agents)
┌─────────────────────┐ ┌─────────────────────┐
│ #lobby │ │ muse: side chats │
│ #ops │◄── bridge ──►│ pip: side chats │
│ #operators │ (metadata) │ 646: side chats │
│ #fleet-status │ └─────────────────────┘
└─────────────────────┘
▲
Operators manage here;
agents work there.
Bridge = channel_id mapping.
```
## Data Model
### Bridge Mapping
```json
{
"bridge_id": "string (unique)",
"frontdoor_channel": "#ops | #lobby | #operators | #fleet-status",
"muse_side_chat_id": "string (from muse.ai)",
"agent": "muse | pip | 646",
"linked_at": "ISO8601",
"linked_by": "operator | agent",
"status": "active | archived"
}
```
### Query Patterns
- **By channel**: "Show all side chats for #ops" → list of {agent, side_chat_id, purpose, last_activity}
- **By agent**: "Show 646's side chats" → list grouped by channel_id
- **By purpose**: "Find onboarding side chats" → across agents
## Storage
**Location**: `~/Projects/NetVM/bridge/` on bl (operator-managed via SSH)
**Files**:
- `mappings.json` — array of bridge mapping objects
- `channels.json` — front-door channel registry (id, name, purpose)
**Why bl, not the browser**: The browser agents can't reliably persist files.
Operators maintain the bridge via SSH (proven). Agents tag their side chats
with `channel_id`; operators record the mapping.
## API Extensions
### `muse-chat-api.py`
```
sidechat bridge --channel <id> # List side chats linked to a front-door channel
sidechat tag <chat_id> --channel <id> --purpose <str> # Tag a side chat with metadata
```
### Bridge CLI (new: `bin/bridge.py`)
```
bridge list --channel #ops # Show mappings for a channel
bridge add --agent 646 --chat <id> --channel #ops --purpose "incident-123"
bridge remove <bridge_id>
```
## Workflow
### Agent creates side chat
1. Agent (e.g., 646) creates side chat in muse.ai UI
2. Agent tags it: `sidechat tag <id> --channel #ops --purpose "tunnel-debug"`
3. Bridge mapping recorded in `~/Projects/NetVM/bridge/mappings.json`
4. Operator can now query: `bridge list --channel #ops` → sees 646's chat
### Operator queries
1. Operator: "What's happening in #ops?"
2. `bridge list --channel #ops` → shows all linked side chats across agents
3. Operator drills in: `muse-chat-api.py --account 646 sidechat use <id>` → reads messages
### No message relay
- Messages stay in their native system
- Bridge is organizational, not communicative
- Operators context-switch via the API, not via copied messages
## Security
- Bridge files on bl are operator-managed (SSH only)
- Agents can tag their own side chats (via API)
- Agents cannot modify other agents' mappings
- Front-door channel membership controls who can query (e.g., #operators is private)
## Implementation Status
- [ ] `bin/bridge.py` CLI
- [ ] `sidechat tag` command in muse-chat-api.py
- [ ] `sidechat bridge` query command
- [ ] `bridge/mappings.json` schema
- [ ] Documentation
## Notes
- This is v0.1. The metadata model will evolve as 646 documents the DOM.
- The bridge does NOT require muse.ai API changes — it's an operator-layer construct.
- Future: Web UI for the bridge (operator dashboard showing channel → side chats).