feat(box): passkey fetch, agent key-approval flow, unified lookups, tmux agent UX
- box passkey [show|fetch] (+ muse passkey): documents VM-only passkey (/srv/box/passkey.txt, fallback /etc/netvm/passkey.txt on 34.139.37.135), probes VM over SSH with graceful fallback; --json supported. No secrets on bl. - approvals: request_key_approval / check_node_key_request; KEY_APPROVAL status surfaced in `box approvals check`; allow/deny resolve + audit to box-ctl.jsonl; never auto-approved. New `box approvals request-key <node> --reason`. - box lookup (summary|fleet|threads|unread|approvals|key|docs) and docs-lookup engine with lookup_internal/ database (docs_internal symlink). - muse-tmux: non-TTY attach falls back to scrollback capture; prune NameError fix. - box/muse passthrough for tmux/muse/docs; thread list/view alias + prefix resolve. - Docs: AGENTS.md, AGENT-TOOLING.md, BOX-WEB-SURFACE-GUIDE.md, README. - Tests: key-approval + passkey tests; sync stale sidechat UUIDs and manifest name. - .gitignore runtime trackers (subagent-sessions, conversation-nudge-tracker).
This commit is contained in:
@@ -0,0 +1,87 @@
|
||||
# Master Regex Patterns & Passing Reference
|
||||
|
||||
> **Box is the main surface.** All operator work goes through Box (`box.muse-dev.online`). The web UI, `box` CLI, and agents share the same API endpoints and parsing patterns.
|
||||
|
||||
This document serves as the canonical reference for regular expressions used across NetVM's orchestrators, harvesters, loop state managers, and agent message parsers.
|
||||
|
||||
---
|
||||
|
||||
## 1. Quick Pattern Directory
|
||||
|
||||
| Pattern Key | Purpose | Match Example |
|
||||
|---|---|---|
|
||||
| `work_order` | Parses `[WO:<id>] [from <sender>] ...` | `[WO:7fce46e0] [from super] Audit — Check stats` |
|
||||
| `ack` | Parses `[ACK:<id>] [from <sender>]` | `[ACK:7fce46e0] [from 646]` |
|
||||
| `verb` | Matches `[ACK\|CLAIM\|RESULT\|DECLINE\|NO-ACTION <id>]` | `[CLAIM 7fce46e0]` |
|
||||
| `result` | Parses `[RESULT <id>] <status> <summary>` | `[RESULT 7fce46e0] OK 14 endpoints healthy` |
|
||||
| `tool_call` | Parses inline `[TOOL <op> <args>]` | `[TOOL followup.create {"in_m": 5}]` |
|
||||
| `job_tag` | Matches `[JOB <id>]` | `[JOB ml-646-20261005]` |
|
||||
| `nudge` | Parses followup SLA nudges | `[NUDGE 7fce46e0] [nudge 1/3] Deadline 19:45: ...` |
|
||||
| `fleet_alert` | Parses alert broadcasts | `[fleet-alert] CRITICAL: VM unreachable x2` |
|
||||
| `uuid` | RFC 4122 UUID v4 detector | `dc6d72ca-4b02-4217-bf41-7dbca19c5c24` |
|
||||
| `short_hex` | 6-12 character hex IDs | `7fce46e0` |
|
||||
| `subagent_update`| Subagent status notices | `[SUBAGENT-UPDATE] Subagent 'audit' (4a2b8e) ...` |
|
||||
| `swarm_slot` | Swarm worker slot targets | `[JOB swarm-99a/1]` |
|
||||
|
||||
---
|
||||
|
||||
## 2. Core Patterns & Named Capture Groups
|
||||
|
||||
### 2.1 Work Order Pattern (`work_order`)
|
||||
```python
|
||||
r"^\[WO:(?P<wo_id>[a-f0-9-]+)\]\s+\[from\s+(?P<sender>[a-zA-Z0-9_-]+)\]\s+(?P<title>[^—\n]+?)\s*—\s*(?P<body>.+)$"
|
||||
```
|
||||
* **Flags**: `re.MULTILINE`, `re.DOTALL`
|
||||
* **Groups**:
|
||||
- `wo_id`: The unique tracking ID.
|
||||
- `sender`: Originating identity (`super`, `646`, `pip`, etc.).
|
||||
- `title`: Short task name preceding the em-dash (`—`).
|
||||
- `body`: Instruction payload following the em-dash.
|
||||
|
||||
### 2.2 Standard Verbs (`verb`)
|
||||
```python
|
||||
r"\[(?P<verb>ACK|CLAIM|RESULT|DECLINE|NO-ACTION)\s+(?P<job_id>[A-Za-z0-9_/-]+)\]"
|
||||
```
|
||||
* **Groups**:
|
||||
- `verb`: One of the 5 canonical lifecycle verbs.
|
||||
- `job_id`: Target job, work order, or swarm slot.
|
||||
|
||||
### 2.3 Task Result (`result`)
|
||||
```python
|
||||
r"\[RESULT\s+(?P<job_id>[A-Za-z0-9_/-]+)\]\s*(?P<status>OK|FAIL|DECLINE|SUCCESS|ERROR)?\s*(?P<summary>.*?)(?=\[RESULT\s|\Z)"
|
||||
```
|
||||
* **Flags**: `re.DOTALL`
|
||||
* **Groups**:
|
||||
- `job_id`: Target task ID.
|
||||
- `status`: Optional explicit status keyword.
|
||||
- `summary`: Detailed response text.
|
||||
|
||||
### 2.4 In-Band Tool Directives (`tool_call`)
|
||||
```python
|
||||
r"\[(?P<engine>TOOL|EXEC)\s+(?P<op>[a-zA-Z0-9_.-]+)\s+(?P<args>\{.*?\})\]"
|
||||
```
|
||||
* **Groups**:
|
||||
- `engine`: `TOOL` or `EXEC`.
|
||||
- `op`: Method name (e.g. `followup.create`, `health.check`).
|
||||
- `args`: Embedded JSON argument payload.
|
||||
|
||||
---
|
||||
|
||||
## 3. CLI Pattern Passing & Validation
|
||||
|
||||
The unified CLI allows testing strings directly against these patterns:
|
||||
|
||||
```bash
|
||||
# Test a string against a specific pattern
|
||||
super docs regex result --test "[RESULT 7fce46e0] OK Task complete"
|
||||
box docs regex work_order --test "[WO:8a12bc44] [from super] Audit — verify 200"
|
||||
|
||||
# Parse an agent utterance through ALL registered patterns
|
||||
super docs parse "[RESULT 7fce46e0] OK Verified 14 endpoints"
|
||||
box docs parse "[TOOL followup.create {\"in_m\": 5, \"prompt\": \"check\"}]"
|
||||
|
||||
# View raw JSON pattern definition
|
||||
super docs get regex_patterns work_order --json
|
||||
```
|
||||
|
||||
When run with `--json`, the parser outputs structured dictionary mappings suitable for programmatic ingestion by subagents.
|
||||
Reference in New Issue
Block a user