KeyTurn: verified password changes for IBM Bob

KeyTurn helps engineers check that a planned database password change is complete. "Complete" means three things: the app works with the new credential, the old one is refused, and reconnects and queued jobs still succeed. IBM Bob investigates and performs the handover; KeyTurn checks the measured result and keeps a handover record. Why this is needed. Editing every copy of the password does not by itself change the live system. The running apps, the connection pool, open sessions and the next deploy still decide what happens. In our lab (real Mastodon, PgBouncer and Postgres; synthetic accounts), a short request led IBM Bob to edit all three copies, including an md5-hashed one, and list the live steps as next steps without taking them. The old password kept working (3 of 3 runs). How it works inside Bob. KeyTurn installs into a Bob workspace: 1. Three custom modes: Inventory finds each copy (KeyTurn counts what was found but never names a miss); Plan picks a method, changing the password in place or moving to a new login; Execute makes the changes with a check after every step. 2. A gate hook refuses covered steps whose order is not ready, and says why. 3. A no-AI MCP checker runs three proofs on the live system, plus restart, reconnect, migration and delayed-job tests. A transition watch samples customer journeys during the change. 4. After Bob's final message, a Stop hook records VERIFIED, FAILED or UNVERIFIED. A later file edit or service restart makes a stored VERIFIED stale until the proofs run again. Evidence, versions kept apart. - Bob with KeyTurn v0.1 (the same short request, one run): the fixed checker passed every item. v0.1's gate was over-strict, and a KeyTurn timeout bug made the run long (35.07 Bobcoins). - Bob with KeyTurn 0.2.1 (one read-only check of a half-changed lab): Bob reported "not complete — all three required proofs fail" and changed nothing; one of its eight next steps rested on a misread hash. - KeyTurn 0.2.1 with a scripted operator (not Bob): 81 unit tests; 69/69 and 55/55 lab checks for the two methods. The demo run shows the refusal, 3 of 10 sampled journeys failing during the change, and VERIFIED turning UNVERIFIED after a later change. - Plain Bob also passed when the request spelled out the outcome (one run, 2.42 Bobcoins). So the value is not that Bob needs KeyTurn. It is reusable completion checks, refusals with reasons, and an inspectable record for the supported workflow. Limits: one deployment shape (apps, PgBouncer, Postgres in Docker); synthetic data and few runs; covered commands only; sampled customers, so no zero-downtime claim; no full handover by Bob with 0.2.1 yet; Bob's Stop hook cannot block "done", so KeyTurn records the verdict. Code, evidence and Bob task summaries: https://github.com/pvgirish/keyturn Demo page (video, real handover record, lab replay): https://pvgirish.github.io/keyturn/