# Trinity Wiring Status

**Date:** 2026-02-12
**Agent:** `agent_b3484fec_genesisprovision`
**Endpoint:** `http://100.101.94.32:8002`
**Purpose:** Track which LockStock task types are fully wired through Trinity's adapter

---

## Section 1: What's Working Now

### Confirmed Working (Tested 2026-02-12)

| Task Type | Endpoint | Chain Stamp | Test Method |
|-----------|----------|-------------|-------------|
| `chat_completion` | `/v1/chat/completions` | YES - verified | Sent 8+ requests via external endpoint, observed chain advance from seq 0 to seq 9 |
| `network` | `/v1/models` | YES - verified | Endpoint exists, mapped in PATH_TASKS, chain advances on request |

### Evidence

**chat_completion:**
- External curl to `http://100.101.94.32:8002/v1/chat/completions` returns Trinity inference
- Chain advances by 1 per request (unidirectional - request stamping only)
- Server and local state match after requests
- Dashboard shows entries with task type `CHATCOMPLETION`

**network:**
- Mapped in adapter's `PATH_TASKS` as `/v1/models` -> `network`
- Not explicitly tested with curl during this session
- Assumed working based on code path

### Current PATH_TASKS Mapping (RunPod Adapter)

```python
PATH_TASKS = {
    "/v1/chat/completions": "chat_completion",
    "/v1/models": "network",
    "/health": None,  # Excluded from chain
    "/lockstock/status": None,  # Excluded from chain
}
```

---

## Section 2: Gap Analysis

### Complete Task Type Inventory

| Task Type | Adapter Endpoint | Dashboard Reflects | Chain Stamp Verified | Notes |
|-----------|------------------|-------------------|---------------------|-------|
| `Deploy` | MISSING | Yes (Guard tier) | No | Infrastructure action |
| `Restart` | MISSING | Yes (Guard tier) | No | Infrastructure action |
| `Backup` | MISSING | Yes (Guard tier) | No | Infrastructure action |
| `Rollback` | MISSING | Yes (Guard tier) | No | Infrastructure action |
| `Heartbeat` | MISSING | Yes (Guard tier) | No | Could add `/v1/heartbeat` |
| `Checkpoint` | MISSING | Yes (Guard tier) | No | Agent state persistence |
| `Teleport` | MISSING | Yes (Guard tier) | No | Agent migration |
| `FileRead` | MISSING | Yes (Guard tier) | No | Trinity reading files on her box |
| `FileWrite` | MISSING | Yes (Guard tier) | No | Trinity writing files on her box |
| `Network` | EXISTS (`/v1/models`) | Yes (Guard tier) | Not explicitly tested | Mapped but not curl-tested |
| `Shell` | MISSING | Yes (Guard tier) | No | Trinity running commands |
| `Database` | MISSING | Yes (Guard tier) | No | Could add `/v1/database` |
| `ChatCompletion` | EXISTS (`/v1/chat/completions`) | Yes (Guard tier) | **YES** | Fully working |
| `ChatCompletionResponse` | MISSING | Yes (Guard tier) | No | Response-side stamping |
| `Handoff` | MISSING | Yes (Guard tier) | No | A2A - requires second agent |
| `Delegate` | MISSING | Yes (Guard tier) | No | A2A - requires second agent |
| `All` | N/A | No (wildcard) | N/A | Admin wildcard, not a real task |

### Summary

- **Working:** 2 task types (chat_completion, network)
- **Missing endpoint:** 14 task types
- **Out of scope (A2A):** 2 task types (handoff, delegate)
- **Wildcard (N/A):** 1 task type (all)

---

## Section 3: Dashboard Discrepancies

### Extra Items on Dashboard (Not in types.rs)

| Dashboard Item | In types.rs | What It Is | Recommendation |
|----------------|-------------|------------|----------------|
| `MONITOR` | NO | UI feature - view metrics | Keep on dashboard, NOT a chain task |
| `AUDIT` | NO | UI feature - view/export audit logs | Keep on dashboard, NOT a chain task |
| `PASSPORT` | NO | UI feature - export/import agent passports | Keep on dashboard, NOT a chain task |

### Source Analysis

Found in `website/dashboard.html` lines 1570-1572:

```javascript
{ id: 'MONITOR', label: 'Monitor', description: 'Access monitoring and metrics' },
{ id: 'AUDIT', label: 'Audit', description: 'View and export audit logs' },
{ id: 'PASSPORT', label: 'Passport', description: 'Export/import agent passports' }
```

### Determination

These are **dashboard UI capabilities**, not chain-stampable task types:

- **MONITOR:** Grants dashboard access to velocity metrics, agent status views
- **AUDIT:** Grants dashboard access to view audit log entries, export compliance reports
- **PASSPORT:** Grants dashboard access to checkpoint/resume/teleport UI functions

They control what a user can SEE and DO in the dashboard, not what actions get chain-stamped. The actual chain operations use the real task types (Checkpoint, Teleport).

**Verdict:** These should STAY on the dashboard as UI permission flags. They should NOT be added to `types.rs` because they are not agent actions - they are user permissions.

---

## Section 4: Implementation Plan

### Quick Wins

Task types where the server already handles them, adapter just needs a route.

#### 1. `heartbeat` via `/v1/heartbeat`

**What:** Periodic keep-alive signal that advances the chain without doing inference.

**Adapter change:**
```python
PATH_TASKS["/v1/heartbeat"] = "heartbeat"

@app.post("/v1/heartbeat")
async def heartbeat():
    # No inference, just chain stamp
    return {"status": "ok", "timestamp": time.time()}
```

**Expected chain stamp:** Task type `HEARTBEAT`, matrix rotation applied.

#### 2. `database` via `/v1/database/query`

**What:** Trinity querying her local Redis/Postgres for consciousness metrics.

**Adapter change:**
```python
PATH_TASKS["/v1/database/query"] = "database"

@app.post("/v1/database/query")
async def database_query(request: DatabaseQueryRequest):
    # Proxy to Trinity's Thalamus or internal DB
    result = await query_internal_database(request.query)
    return result
```

**Expected chain stamp:** Task type `DATABASE`, lower triangular matrix.

#### 3. `chat_completion_response` via response stamping

**What:** Stamp the chain when Trinity RETURNS a response, not just when she receives a request.

**Adapter change:** After proxying to Trinity and receiving response, make a second chain advance with task `chat_completion_response`.

**Expected chain stamp:** Two entries per request - one `CHATCOMPLETION` (in), one `CHATCOMPLETIONRESPONSE` (out).

**Note:** This changes the behavior from unidirectional to bidirectional stamping. Sequence would advance by 2 per chat request.

### Medium Effort

Task types requiring new functionality in the adapter.

#### 4. `file_read` via `/v1/files/read`

**What:** Trinity reading files from her own filesystem (RunPod /workspace).

**Adapter change:**
```python
PATH_TASKS["/v1/files/read"] = "file_read"

@app.post("/v1/files/read")
async def file_read(request: FileReadRequest):
    # Validate path is within allowed directories
    # Read file contents
    # Return contents
```

**Security:** Must whitelist allowed paths (e.g., `/workspace/`, `/tmp/`). No reading `/etc/passwd`.

#### 5. `file_write` via `/v1/files/write`

**What:** Trinity writing files to her own filesystem.

**Adapter change:** Similar to file_read, with write permissions to allowed paths.

**Security:** Same path restrictions. May want approval flow for sensitive paths.

#### 6. `shell` via `/v1/shell/exec`

**What:** Trinity executing shell commands on her box.

**Adapter change:**
```python
PATH_TASKS["/v1/shell/exec"] = "shell"

@app.post("/v1/shell/exec")
async def shell_exec(request: ShellExecRequest):
    # Execute command with timeout
    # Capture stdout/stderr
    # Return result
```

**Security:** EXTREMELY SENSITIVE. Should require explicit capability grant. May want command whitelist.

### Deferred

Task types depending on systems not yet built or external infrastructure.

#### 7. `checkpoint` / `teleport`

**Depends on:** Agent state serialization, passport format, cross-machine transfer protocol.

**Deferred because:** These are agent lifecycle operations that require the full passport/teleport system. Not applicable to a running inference service.

#### 8. `handoff` / `delegate`

**Depends on:** Second agent, A2A protocol, cross-chain references in payload.

**Deferred because:** Out of scope - Trinity first, multi-agent later.

#### 9. `deploy` / `restart` / `backup` / `rollback`

**Depends on:** Infrastructure orchestration layer (CI/CD, Kubernetes, etc.).

**Deferred because:** These are not Trinity actions - they are actions performed ON Trinity by an orchestrator. The orchestrator would stamp these on its own chain, not Trinity's.

---

## Section 5: Test Plan

### Quick Win Tests

All tests use the external endpoint: `http://100.101.94.32:8002`

#### Test 1: Heartbeat

**Prerequisites:** Add `/v1/heartbeat` endpoint to adapter.

**Curl command:**
```bash
curl -X POST http://100.101.94.32:8002/v1/heartbeat \
  -H "Content-Type: application/json" \
  -d '{}'
```

**Expected response:**
```json
{"status": "ok", "timestamp": 1770863500}
```

**Expected chain entry:**
- Task: `HEARTBEAT`
- Sequence: N+1
- Matrix: Rotation applied (0, 65536, 1, 0)

**Verification:**
```bash
curl http://100.101.94.32:8002/lockstock/status
# Check local.sequence incremented
# Check dashboard shows HEARTBEAT entry
```

#### Test 2: Database Query

**Prerequisites:** Add `/v1/database/query` endpoint, connect to Trinity's internal Redis.

**Curl command:**
```bash
curl -X POST http://100.101.94.32:8002/v1/database/query \
  -H "Content-Type: application/json" \
  -d '{"query": "SELECT COUNT(*) FROM perceptions"}'
```

**Expected response:**
```json
{"result": 12345, "query_time_ms": 5}
```

**Expected chain entry:**
- Task: `DATABASE`
- Sequence: N+1
- Matrix: Lower triangular (1, 0, 3, 1)

#### Test 3: Bidirectional Chat Stamping

**Prerequisites:** Modify adapter to stamp both request and response.

**Curl command:**
```bash
# Same as before
curl -X POST http://100.101.94.32:8002/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "trinity", "messages": [{"role": "user", "content": "Test"}], "max_tokens": 10}'
```

**Expected chain entries (TWO):**
1. Task: `CHATCOMPLETION`, Sequence: N+1
2. Task: `CHATCOMPLETIONRESPONSE`, Sequence: N+2

**Verification:**
```bash
curl http://100.101.94.32:8002/lockstock/status
# Check local.sequence incremented by 2 (not 1)
```

#### Test 4: Network (Verify Existing)

**Curl command:**
```bash
curl http://100.101.94.32:8002/v1/models
```

**Expected response:**
```json
{"data": [{"id": "trinity", "object": "model", ...}]}
```

**Expected chain entry:**
- Task: `NETWORK`
- Sequence: N+1

---

## Next Steps

1. **Verify network endpoint** - Confirm `/v1/models` actually stamps the chain (quick test)
2. **Implement heartbeat** - Simplest quick win, no inference required
3. **Implement database** - Second quick win, exposes Trinity's perception data
4. **Decide on bidirectional** - Do we want 2 stamps per chat or keep it at 1?
5. **Security review** - Before implementing file_read/file_write/shell

---

## Document History

- 2026-02-12: Initial audit and gap analysis
