-
-
Six numbered stages: incident, local Codex, isolated Git, Docker gates, phone approval, and verified release evidence.
-
A real WebSocket 1012 failure with a healthy HTTP process—the incident BOB Forge is designed to repair.
-
A paired phone reviews the tested bytes and explicitly approves the local deployment.
-
The registered Docker gates pass while the original source tree remains untouched.
-
After deployment and exact rollback, BOB Forge exports a semantically verified evidence pack.
-
Codex proposes a bounded one-file repair; BOB Forge keeps approval and release authority deterministic.
Inspiration
The moment that triggered BOB Forge was simple: an HTTP health check said the service was alive, but its WebSocket feed had already stopped after close code 1012.
A coding agent can propose a convincing fix, but a proposal is not a release. Someone still has to isolate the change, prove what was tested, decide whether those exact bytes may deploy, measure recovery, and preserve a rollback record. I built BOB Forge to explore one question: can an AI repair a real incident without becoming the release authority?
What it does
BOB Forge is a local-first release control plane for a real, intentionally broken reconnect service. The full flow runs on a Windows PC and can be steered from a phone on the same Wi-Fi network:
- The operator submits the stalled-feed incident.
- Locally authenticated Codex and GPT-5.6 inspect an isolated per-task Git copy and return a structured diagnosis and bounded repair proposal.
- BOB Forge validates the proposal, permits only the registered source edit, and applies it outside the model process.
- Fixed compile and reconnect gates run inside hardened local Docker containers while the original source remains untouched.
- A human reviews the result on a paired phone. Approval is bound to five integrity digests: the plan, tested artifact, baseline, candidate, and deployment manifest.
- Only the approved frozen bytes reach the local Docker sandbox. BOB Forge measures recovery, rehearses an exact rollback, and exports a portable evidence pack with a semantic verdict.
The demonstrated repair changes one file. The broken client receives two messages and stops; the tested candidate reconnects with bounded exponential backoff and reaches the required message count.
Why it is different
Most agent demos focus on whether a model can write a patch. BOB Forge focuses on everything that must be true after the patch looks plausible.
Codex owns reasoning. Deterministic software owns file scope, patch validation, commands, tests, approval, deployment, health measurement, rollback, and evidence. There is no automatic switch to a paid API provider, and the default demo uses the user's existing local Codex authentication rather than an OpenAI API key.
This separation is useful for solo developers and small teams that want agentic speed but do not have a dedicated SRE or release engineering function. It turns “the model says the fix works” into a reviewable chain of observed facts.
How I built it
The control plane is written in Python and persists tasks, versioned state transitions, events, artifacts, approvals, deployments, and recovery state in SQLite. Durable server-sent events replay after reload. A responsive HTML, CSS, and JavaScript HUD exposes the same authoritative state on desktop and mobile.
The local Codex provider consumes structured JSONL. A bounded inspector selects context from an isolated Git copy, and the source plus Git metadata are hashed before and after the model turn. The patch engine enforces selected-file membership, expected hashes, exact replacements, path and size limits, secret checks, and Python AST restrictions.
Docker test and deployment commands are fixed by the product, not authored by the model. Approval is versioned and fails closed if any bound digest changes. The exported schema-v2 Evidence Pack can be checked by a standalone verifier without Codex, Docker, an API key, or phone access.
How I used Codex and GPT-5.6
During Build Week, Codex was my implementation and review partner for the independent BOB Forge control plane, reconnect fixture, safe patch boundary, Docker gates, phone workflow, failure handling, tests, and submission packaging.
It accelerated repository inspection, implementation, debugging, security review, and repeated verification. I made the product and release-authority decisions: one honest vertical slice, local Windows execution, explicit human approval, no source merge or push, and no automatic paid-provider fallback.
Inside the product, the local Codex CLI runs GPT-5.6 with ultra reasoning to produce the diagnosis, evidence, bounded plan, selected file, exact edits, requested tests, diff explanation, and risk.
GPT-5.6 cannot apply the patch, choose commands, approve a release, or deploy. BOB Forge records the concrete provider, model, reasoning effort, transport, billing mode, and whether any degraded path was used.
Challenges and lessons
The hardest challenge was not reconnect logic. It was maintaining one trustworthy identity for the candidate across analysis, validation, approval, deployment, rollback, and export.
That led to immutable snapshots, digest-bound approvals, fail-closed state transitions, and a portable verifier that recomputes the evidence verdict.
I also learned that a truthful local-first product needs to survive reloads and long model turns without faking progress. Durable events, resumable state, explicit readiness, and visible failure states became core product features rather than polish.
Build Week disclosure
BOB Forge is a separate repository created during Build Week. Its first provenance commit, 52131cd, preserves a visual HUD foundation imported from my pre-existing Hermes OS project. That visual language, animation system, responsive layout foundation, and service-worker foundation are not claimed as new work.
The BOB-specific control plane, local Codex boundary, isolated Git workspaces, validation engine, Docker gates, phone approval workflow, deployment and rollback system, evidence format, portable verifier, and product workflow were built during Build Week. The repository contains the detailed boundary and dated commit history.
Current scope
The submission intentionally proves one deep vertical slice: reconnect-demo, one permitted source file, and a local Docker target. It does not claim arbitrary-repository autonomy or production deployment.
The rollback rehearsal restores the exact registered broken baseline to prove reversibility; it is not presented as a previous healthy production release.
BOB Forge is built around one principle: an AI-generated patch should not automatically become a release.
Built With
- codex
- css3
- docker
- git
- gpt-5.6
- html5
- javascript
- python
- server-sent
- sqlite
- websockets
- windows
Log in or sign up for Devpost to join the conversation.