ChangeSafe

The Problem Engineering teams ship code changes every day, but the question "what could go wrong downstream?" rarely gets a rigorous answer before merge. Code reviews catch style and logic errors, but they rarely surface cross-module event chain breaks, race conditions introduced by a new column, or security invariants quietly violated by a refactor. The result: incidents that could have been predicted, but weren't — because no structured process existed to ask the right questions before the change landed in production. This problem is especially acute in event-driven, modular architectures. A single change to an order placement handler can silently break payment collection, warehouse stock reservation, and shipping delivery preparation — all downstream consumers of the same domain event — without any obvious compile-time signal. The Solution ChangeSafe: Future Incident Lab is a structured, evidence-first workflow built on IBM Bob that turns proposed code changes into verified, risk-grounded decisions before release. It is not an autonomous code generator. It is a disciplined, human-in-the-loop investigative process. Target users: backend engineers, tech leads, and release engineers working on any Java/Spring Boot codebase with bounded-context or event-driven architecture patterns. How it works: Users invoke /changesafe in IBM Bob's custom changesafe mode. Bob then walks through a 12-phase workflow: clarifying the change, tracing its full downstream impact, enumerating every plausible failure mode, presenting risk hypotheses for human disposition (fix / defer / won't-fix), selecting a single safety contract — a testable invariant that must hold before and after — and running regression tests both before and after any code change. Every claim is grounded in source code, test results, or explicit uncertainty. No speculation is permitted. The output is a structured evidence pack: a change-brief, risk report, before/after test summaries, and a comparison artifact — all validated by a script before the run is considered complete. A live business-rules register accumulates confirmed decisions across runs, so knowledge is never lost between sessions. What makes it unique is the combination of: mandatory human approval gates (no code is written without explicit sign-off), token-budget metering (Bobcoin checkpoints prevent runaway context costs), domain-specific read-only guardian sub-agents (spawned only when cross-module impact justifies the cost), and a two-pass analysis rule that stops early for low-risk changes and deepens only when warranted. It is a repeatable engineering process, not a one-shot prompt. The project ran four recorded Bob sessions against the included e-commerce application. The first planned and built the entire ChangeSafe scaffold (7.48 and 15.61 Bobcoins respectively). The third session ran a broad checkout flow audit that identified 10 risks — including a duplicate-order race condition, a price manipulation vulnerability, and a bypassable idempotency key — fixed 9, deferred 1, and grew the test suite from 24 to 32 passing tests (18.80 Bobcoins, 78% context). The fourth session demonstrated the parallel workflow capability: a focused end-to-end trace of the complete place-order user journey — from the moment a user clicks the checkout button, through filling in delivery information, to final order submission — uncovering additional risks in the sequential checkout path (20.17 Bobcoins, 58% context). Together the four sessions demonstrate that ChangeSafe scales from scaffold construction to broad audit to focused user-journey analysis, each within a predictable Bobcoin budget.