← Readiness ReportProd vs TestReadinessRunbook

Production .86 vs Test — Detailed Comparison

Generated: 2026-05-29 (Eastern) · Prod: paperclip.searskairos.ai (44.205.14.86) · Test: paperclip-test.searskairos.ai (98.84.88.134) · Read-only; prod untouched.

✅ EVERYTHING OK — Test (stock + plugins) faithfully reproduces the production fork. All reference data is identical; the only differences are (a) the intended architecture change (fork → stock + 11 plugins), (b) a deliberate "standby" service posture on test, and (c) a small, expected data-freshness lag that the cutover re-restore closes.

1. Architecture

Aspect Production .86 Test
Codebase Fork — branch shsai_next-2026-05-16, commit 3ccd51db Stock Paperclip v2026.525 — commit 60efa38f (release changelog), detached HEAD
Extension model Monolithic fork; SHS features baked into core UI pages Stock core + 11 plugins, no core fork
Plugins installed (plugins table) 1 16 rows → 11 ready (SHSAI + 1st-party) + 5 stock examples (uninstalled)
Domain data location public (core) schema per-plugin namespaces plugin_shsai_* (+ 3 bridge views)
Result Same features, fork-maintained Same features, zero core fork — the migration goal

2. Service posture (test is deliberately in standby)

Service Production .86 Test Note
paperclip.service active active both healthy
ngrok-paperclip active (prod is exposed via ngrok) inactive flip at cutover
Cron jobs 4 active (hourly backup, daily 12:00 report, weekly Sun report, 30-min primary-health) none flip at cutover
Email sending enabled (live) disabled flip at cutover
MCP sears-kairos-agents active, 74 tools verified live

This is exactly the intended pre-cutover state: test stays dark (no email/ngrok/crons) so it can't send mail or take traffic until you deliberately switch over.

3. Data parity (live row counts, both DBs on :54329)

Dataset Prod .86 Test Δ Notes
companies 13 13 0 ✅ identical
agents 143 143 0 ✅ identical
issue_approvals 33 33 0 ✅ identical
human_agents 261 261 0 ✅ identical
milestones 455 455 0 ✅ identical
frameworks 54 54 0 ✅ identical
email_templates 13 13 0 ✅ identical
knowledge_intake_items 247 247 0 ✅ identical
approvals 123 121 −2 snapshot lag
budget_incidents 44 42 −2 snapshot lag
goals 73 72 −1 snapshot lag
projects 93 89 −4 snapshot lag
issue_comments 14,057 13,446 −611 (−4.3%) transactional growth on prod
cost_events 10,426 9,842 −584 (−5.6%) transactional growth on prod
issues 5,107 4,646 −461 (−9.0%) transactional growth on prod

Interpretation: every reference / domain dataset is identical. The only deltas are in high-velocity transactional tables (issues, comments, cost events) that keep growing on the live prod box — i.e. the test snapshot is simply ~1–2 days old. This matches the migration plan's "~6% older snapshot" note and is closed by Cutover Step 2 (fresh re-restore → re-run bridge-views.sql), for which the idempotent cutover-restore-and-rehydrate.sh is already delivered.

4. UI / functional parity

5. Known difference — 4 write interactions (non-blocking)

Reviews approve / request-changes, invite-human, send-digest currently ship read-only on test. No data is lost; 3 of 4 are restorable on the stock host with no host change, and only send-digest needs a small host email-RPC (or an interim mailer). Full per-feature plan in the readiness report. None block cutover.

6. Verdict

🟢 GREEN — everything checks out. Test is a faithful stock+plugins reproduction of the fork. Differences are intentional (architecture, standby posture) or expected and auto-resolved (data freshness via the cutover restore). Production remains live, healthy, and untouched.