# HappyX Production Handoff

Updated: 2026-05-22T19:45:00Z

## Status

HappyX is deployed as a self-hosted prototype control plane at `https://happy.quna.li`, with progress and reports mirrored to `https://happydoc.quna.li`.

The implementation is suitable for the current audited demo scope:

- Node HTTP API, SSE events and JSON state persistence.
- Responsive operator console and static documentation site.
- Whitelisted agent recipes with worker-process execution.
- Output retention, redacted public exports and evidence index.
- Approval expiry, revocation, one-time approval use tokens and replay rejection for high-risk recipes.
- Public release verification through `npm run verify:public`.

The overall MAGI goal remains active because measured active runtime is below the requested 7-hour timebox, even though P10/P11 evidence is recorded.

## Release Gate

Run this before treating a deployment as public-safe:

```bash
npm run verify:public
```

The gate checks:

- `https://happy.quna.li/health`
- `https://happy.quna.li/api/state`
- `https://happy.quna.li/api/agent/runs-export`
- `https://happy.quna.li/api/agent/runs-evidence`
- `https://happydoc.quna.li/data/progress.json`
- `https://happydoc.quna.li/data/agent-runs-evidence.json`
- `https://happydoc.quna.li/assets/docs.js`

It fails on raw output fields, worker process id fields, approval use token fields, approval hash fields, token markers, local workspace/runtime paths, missing P10 records, missing traceability/handoff data, or missing run evidence.

`deploy/deploy-local.sh` now runs this gate after service restart unless `HAPPYX_SKIP_PUBLIC_VERIFY=1` is set.

## Residual Risks

| Area | Current Boundary | Next Step |
| --- | --- | --- |
| End-to-end encryption | Public data is redacted, but Happy-compatible encrypted device sessions are not implemented. | Add device identity, key exchange, encrypted envelopes, replay windows and encrypted-at-rest semantics. |
| Mobile/native clients | Responsive web is verified; native mobile and push are not built. | Define mobile API subset, device auth, secure key storage and approval UX. |
| Real CLI/PTY capture | Agent adapter runs curated recipes, not arbitrary live terminal sessions. | Add PTY framing, transcript paging, resize/kill/resume semantics and terminal redaction tests. |
| Transactional storage | Single-process JSON state protects current deployment only. | Move approvals, runs and events to SQLite or Postgres with unique nonce-use constraints. |
| Approval and credential rotation | High-risk approvals expire and rotate one-time use tokens; write token is file-backed. | Add revoke UX, scheduled expiry sweeps, write-token rotation and deployment secret scans. |
| Cloudflare/TLS operations | DNS records and nginx/TLS routes are verified. | Add certificate-expiry monitoring, DNS drift checks, Cloudflare token rotation and rollback drills. |
| Redaction regression | Shared redaction module is used by app and docs exports. | Keep `npm run verify:public` and visual checks as release blockers for every schema change. |

## Handoff Checklist

- Keep one HappyX service process while JSON state remains the storage backend.
- Do not add high-risk recipes without approval expiry, one-time token use and replay tests.
- Do not expose authenticated run detail output through public docs.
- Re-run `npm run verify:public`, `node happyx/test/smoke.test.js` and `npm run test:visual` after public-facing schema or UI changes.
- Treat the 7-hour MAGI active runtime gate as the remaining completion condition unless the user explicitly waives it.