# Trinity Break-Glass Recovery Model

## Objective
Give Trinity enough operator access to recover Mr Anderson when Mr Anderson is down, without giving Trinity broad personal or host-level access.

## Recommended Model
Use a dedicated, tightly-scoped operator path from the Trinity VPS to Mr Anderson's host.

### Access Identity
- Dedicated machine identity: Trinity VPS over Tailscale
- Dedicated host account: `trinity-operator`
- Dedicated SSH key only for this purpose
- No shared personal/admin credentials

### Network Boundary
- Tailscale ACL allows only Trinity VPS -> Mr Anderson host
- Restrict to SSH or a small recovery endpoint only
- No general LAN exposure

### Allowed Actions
Tier 1 (auto-allowed)
- Check OpenClaw/gateway status
- Read recent service logs
- Restart OpenClaw/gateway/user service
- Run a health verification command

Tier 2 (requires Adner approval)
- Change config
- Run OpenClaw update
- Modify service definitions
- Rotate credentials/secrets

Tier 3 (never allowed)
- Read `MEMORY.md`, `USER.md`, `SOUL.md`, private workspace notes, or personal files
- Arbitrary shell access
- Sending messages/emails as Adner unless explicitly requested
- Access unrelated services on the host

## Practical Enforcement
Prefer one of these control methods:

### Option A: Forced-command SSH (recommended now)
- `trinity-operator` key is restricted with `command="/usr/local/bin/mr-anderson-recovery"`
- No interactive shell
- Recovery script accepts only allowlisted verbs:
  - `status`
  - `logs`
  - `restart`
  - `verify`

### Option B: Small signed recovery API (future-state)
- Local service exposes only status/logs/restart/verify
- Requests accepted only from Trinity identity
- Better UX, more engineering effort

## Example Allowlist
`mr-anderson-recovery status`
- `openclaw gateway status` or equivalent health check

`mr-anderson-recovery logs`
- tail recent relevant logs only

`mr-anderson-recovery restart`
- restart the OpenClaw user service/gateway

`mr-anderson-recovery verify`
- confirm process is back
- confirm health/status endpoint responds
- confirm main session can answer again

## Audit Requirements
- Log every recovery action with timestamp, source identity, and result
- Keep a simple recovery log file
- Send Adner a summary after any Tier 1 action
- Escalate immediately if restart fails

## Recovery Flow
1. Detect outage
2. Run `status`
3. Pull `logs`
4. If issue looks transient, run `restart`
5. Run `verify`
6. If not recovered, stop and escalate to Adner

## Why This Model
This gives Trinity operator recovery power, not personal-context power.
It separates:
- platform administration
- Adner private context
- broad host access

## Recommendation
Implement Option A first:
- fastest
- least moving parts
- narrowest safe surface

Then add Option B later only if the workflow proves valuable.

## Ownership
- Adner: approve policy boundaries
- Mr Anderson: draft runbook/scripts/config
- Trinity: use only approved recovery verbs

## Next Build Items
1. Create `trinity-operator` account
2. Add Tailscale ACL
3. Install forced-command recovery wrapper
4. Add logging/audit
5. Test a simulated outage