OiMy Stabilization Plan — Final, Reconciled

Date: 2026-07-11 Author: Fable 5 (review pass over GPT-5.6's execution plan, at Bharath's request) Status: Final — this is the plan to execute against. Base document: OIMY-STABILIZATION-PLAN-GPT56-20260711.md (GPT-5.6, 2,028 lines, 8 phases) This document: a real adversarial review of that plan — same standard as the gold-standard dataset plan reviews — followed by a small set of concrete amendments. It is not a rewrite. Where GPT-5.6's plan is right, this document says so and defers to it rather than restating it. Where it needs correcting, the correction is stated as a diff: GPT-5.6 said X → should be Y → because Z.

The single unambiguous instruction for whoever executes this: read OIMY-STABILIZATION-PLAN-GPT56-20260711.md in full — it remains the authoritative phase-by-phase engineering spec (schemas, code sketches, exit gates, the release-bar checklist) — and apply the seven amendments in §2 below on top of it. Nothing in §2 contradicts GPT-5.6's schemas or invariants; every amendment is a scoping, sequencing, or completeness correction, not a redesign.

0. Headline verdict

I substantially agree with this plan, and I'm saying that plainly rather than manufacturing disagreement to look thorough. It is well-grounded in this project's actual incident history (not generic best practice bolted on), it correctly distinguishes what's already fixed from what's still broken, and where it touches my own /context design it extends it correctly with zero drift. My disagreements are real but narrow: the plan has no time estimates and is likely to be read as "doable this week" when a more honest read is 1.5–2.5 weeks of engineering plus a genuinely necessary 7-day observation window; the outbox design is probably over-built for current real-user scale in its first cut; and two real gaps exist (a data-migration step for the one real family already in the DB, and an under-weighted recurring risk class this project has already been bitten by twice). None of this is a "stop and redo" verdict — it's "execute this, with seven specific corrections."

1. Where GPT-5.6's plan is right — stated plainly, not restated at length

Grounding in real incident history, not generic hardening. Every one of the plan's ten non-negotiable invariants (§0 of the base doc) maps to a real, specific bug from this project's actual history, not a textbook checklist: invariant 3 (authoritative session identity + context revision) is a direct fix for the Wednesday-night "no first-class session concept" finding; invariant 4 (every async job carries turn/session/revision) is a direct fix for the bridge reach-back bug; invariants 5–8 (durable terminal disposition, no answer living only in memory) generalize the fix for both the bridge-staleness bug and the hermes-agent send_path_degraded silent-drop bug I dealt with separately in the Docker migration doc — the outbox design subsumes that fix rather than duplicating it, which is a genuine synthesis I hadn't made myself. Invariant 10, cited explicitly against the OpenClaw fleet failure I found personally, is the correct bar.

No redundant re-flagging of already-fixed issues. I checked this specifically, since it was one of the things asked. Phase 1.1 explicitly credits the threading.local() fix (api.py:1859–1884) as "technically correct... should not be described as still broken," and argues for RequestContext on forward-looking grounds (a second invocation path is coming via /context; server replacement is unsafe while identity depends on thread affinity) rather than re-litigating a closed bug. That's the right call and the right reasoning. I found no place in the plan where it mistakenly re-flags Wednesday's fixes as still-open.

Zero drift from my own /context design — clean extension instead. Three places worth confirming explicitly, since this was asked directly: - My original /context request/response shape ({user_id, message, include, max_bytes} → {blocks, anchors_delivered, meta}) is a strict subset of GPT-5.6's protocol extension (adds turn_id, conversation_id, external_ingress_id, session_meta). Additive, not a redesign. - The SessionAuthority.HERMES design with gateway-namespaced external sessions (hermes:{gateway_id}:{external_session_id}) is exactly the session_meta-driven, Hermes-authoritative session model I proposed in the reliability/deployment doc, done more rigorously (I hadn't specified the namespacing). - The anchor reservation/confirmation table (reserve on /context, confirm on /context/writeback, release on failure) directly resolves an item I explicitly left open in the original Heavy Hermes doc (§6.4: "V1 accepts [over-marking delivered]... V2: writeback includes a cheap 'anchor actually used?' judgment"). This is that V2, correctly built.

Sequencing is right. RequestContext before the ledger before /context before server replacement before monitoring-completion (with basic monitoring starting immediately) is the correct dependency order, and it matches this project's own established practice of incremental, canary-first, reversible rollouts rather than big-bang rewrites. No changes recommended to the phase order itself.

Phase 5 is the correct, direct answer to what I found in the OpenClaw fleet. The expected_instances reconciliation loop (§5.3) — comparing expected vs. running vs. ready vs. correct-version every 2 minutes — is precisely the control that was missing when 18 of 22 OpenClaw containers crash-looped unnoticed for six weeks. GPT-5.6 cites that incident by name as the design target. I have no changes to propose here; build it as specified.

2. Amendments — the actual corrections

2.1 Add real effort estimates; be honest that this is not a one-week plan

GPT-5.6 said: no time or effort estimate anywhere in the document. Should be: rough per-phase estimates, stated plainly to Bharath before he commits to a timeline against Hermes-heavy and the Mac app. Because: an "execution-ready" plan that omits effort makes it easy to read the whole thing as "this week's work," and it isn't. My own estimate, grounded in this codebase and this team's actual working pattern (Bharath directing focused dispatched-agent engineering sessions, not a multi-engineer team working phases in parallel):

Realistic total: ~1.5–2.5 weeks of engineering plus a 7-day observation window that overlaps the back half of it — not "this week." Say this to Bharath directly rather than let the plan's silence on timing create a surprise later.

2.2 Scope Phase 2's outbox to single-worker for v1; keep the schema, defer the complexity

GPT-5.6 said: a lease-based, multi-worker outbox claiming system (claim_outbox_batch, lease expiration, crashed-worker handoff) as the initial build. Should be: build the exact same schema (outbound_messages, outbound_attempts, the lease columns included), but implement and test it as a single-worker poller for v1. Defer multi-worker lease-contention testing until there is actually more than one process claiming from the outbox. Because: current real production traffic is one real user. A multi-worker lease-claim system is designed for a scale this product isn't at yet, and building and testing the concurrent-claim path (which needs its own crash-point and race tests per §7.4/§7.2) is real scope that isn't load-bearing today. This is a scoping correction, not a schema change — the lease columns stay in the table so multi-worker support is a later, additive change, not a migration.

2.3 Phase 6 needs an explicit backfill migration for the one real family already in the DB

GPT-5.6 said: the authorization scope model (visibility_scope, authorization_revision, role model) as a forward-looking schema, with no explicit migration step for existing rows. Should be: add an explicit backfill migration — every existing fact/profile/conversation/ ledger/reminder row for the one currently-real family gets authorization_revision=1 and a sane default visibility_scope (almost certainly family for most rows, guardian_only where the existing schema already implies it) — run and verified before authorization enforcement goes live on any route. Because: without this, turning on enforcement breaks the one real user's own working data on day one. This is the kind of gap that's invisible in a schema-first document and only shows up at cutover; better to name it now.

2.4 Reuse the existing 17-family gold-standard roster for the longitudinal simulator

GPT-5.6 said: "create at least 20 synthetic families" for the Phase 7.5 longitudinal simulator. Should be: extend the existing 17-family gold-standard roster (42-day arcs, real genomes, real loop-phase0 longitudinal state already built and partially validated) with a handful of new families only for the specific compositions it doesn't already cover (adult-only family, guardian-plus-limited-caregiver, a medication-reminder-focused family) — not a from-scratch build of 20 new families. Because: this roster represents real, already-invested effort (family genomes, tagged days, anchors) that directly serves the same testing goal. GPT-5.6's grounding pass likely didn't have visibility into it. Rebuilding it from scratch is pure lost time against an already-tight schedule.

2.5 Clarify: the two Phase 7 tracks run in parallel, and Hermes-heavy dev work can start before Phase 7 finishes

GPT-5.6 said: two separate "at least seven continuous days" requirements (the longitudinal simulator, §7.5; Bharath's personal Telegram test, §7.6), without stating whether they run concurrently, and doesn't explicitly say when Hermes-heavy build/test work is allowed to start relative to them. Should be: state explicitly — the two 7-day tracks run in parallel (same calendar week, not sequential 14 days), and Hermes-heavy setup and dev-only testing can begin as soon as Phases 1–3 are done (RequestContext, ledger, /context contract), running alongside api.py's Phases 5–7, since Hermes-heavy's own dev testing needs /context to exist and nothing else from Phases 4–7. Only promoting Hermes-heavy to real user traffic must wait for the full alpha-rollout bar on both sides. Because: this is the direct reconciliation of Bharath's stated three-step order ("stabilize → Hermes-heavy setup+test → Mac app") with GPT-5.6's own dependency graph, which already implies this (Phase 7: starts as soon as Phase 1 canary exists; live-traffic controls say "do not enable Hermes-heavy traffic during stabilization" — traffic, not development) but never says it in the one sentence Bharath actually needs. Without this clarification, "Hermes-heavy setup and testing" reads as strictly-after the full 7-phase bar, adding needless calendar time.

2.6 Two additions to the "highest-risk releases" list (§ Live-traffic risk controls)

GPT-5.6 said: four highest-risk releases (JWT key rotation; turn/outbox ownership cutover; HTTP server replacement; /context/writeback enabling real sends), each requiring a dedicated canary and 60-minute observation window. Should be: add two more to the same list, with the same treatment: 5. The Phase 6 authorization backfill migration (§2.3 above) — it directly touches the one real family's existing, working data; a mistake here is user-visible immediately, not theoretical. 6. Any eval/test driver capable of mutating live production config — not a "release" in the traditional sense, but empirically this project's single most-repeated real incident class: the exact failure (an eval script flipping oimy-engine's live systemd environment to a test config, silently, with real users hitting it) happened on 2026-07-03, and the watchdog built to catch it had its own blind spot exploited again on 2026-07-09. Two real incidents beats any hypothetical risk in the current list. The right fix isn't "be more careful" — that's already failed twice — it's hard environment isolation: eval/test drivers should be structurally incapable of writing to the production systemd unit at all, not merely disciplined not to. Because: the original four are all real risks, but they're all future releases this plan proposes. These two are risks with an actual track record on this exact codebase, and a list titled "highest-risk" that omits the thing that has already gone wrong twice is under-weighted by construction.

2.7 Minor: extend the Phase 5.1 script/service audit list

GPT-5.6 said: eight named cron scripts to audit and bring under ownership (container-monitor.sh through voice_outreach.sh). Should be: add oimy-watchdog.service and oimy-hermes-watcher.service — both confirmed running via systemctl list-units earlier in this same investigation, both a different supervision layer (systemd services, not cron jobs) than everything in GPT-5.6's list. Because: they weren't visible from GPT-5.6's own grounding pass (which pulled from crontab -l, not systemctl list-units), and "a cron entry is not monitoring unless it has an owner" applies exactly as much to a systemd unit.

3. What I did not find

Asked directly whether I saw any landmine in the current code that GPT-5.6's plan doesn't account for: none that I can assert with confidence. My own reading of api.py this session was targeted (the ThreadingHTTPServer declaration, DISABLE_BRIDGE/_kimi_jobs, the watchdog cron, the git-tracking state), not a full line-by-line audit of the ~6,000+ line file — I'm not claiming exhaustive landmine-hunting rigor I didn't actually do, and I'd rather say that plainly than imply false completeness. The provider-fallback chain (Ollama/OpenRouter/DeepSeek) isn't explicitly enumerated in the plan's generation model, but its schema (model_provider, model_name columns) is provider-agnostic and should cover it without changes.

4. The final pointer

Execute against OIMY-STABILIZATION-PLAN-GPT56-20260711.md, phases 0 through 7, exactly as written, with the seven amendments in §2 of this document applied on top. Nothing in this review overrides GPT-5.6's schemas, code sketches, or exit gates — every correction here is additive or scoping, stated as a diff against a plan that is fundamentally sound. There is one plan, not two: this document plus the base document, together, are it.