.png&w=256&q=75)
🤓 Latest Submissions
Rehearsal: test the whole rollout
A database migration can succeed while a rolling deployment breaks. New application instances read the renamed column; older instances still use its previous name. A smoke test that exercises only the new version misses that failure. Application rollback becomes harder once the new version has written data. Rehearsal gives developers a repeatable way to inspect this gap before merging a migration. Choose an original synthetic orders scenario, edit the SQL, and run it in a fresh PostgreSQL/PGlite database. Five stages check the original contract, migration execution, the new-version smoke test, mixed old/new writes, and application rollback with the migrated schema retained. Expand any assertion to see the exact SQL, expected rows, actual rows, or database error. Export the report as JSON. The same engine runs behind a local MCP server in IBM Bob IDE. Bob can inspect the contracts, execute a candidate, diagnose failures, write a repair, and rerun unchanged assertions. In the demonstrated rename scenario, the original passes its new-version smoke test but fails seven of thirteen checks. Bob's independent repair passes all thirteen. The public demo includes that actual candidate separately from the supplied reference example. The workflow replaces manual switching between query snippets, migration reasoning, and test output with one executable feedback loop. Developers remain responsible for defining adequate contracts. Three scenarios cover a column rename, a required field, and a money-column conversion. This prototype uses sequential SQL contracts and synthetic records. It does not test concurrent clients, locks, replicas, or real application binaries, and it does not certify production safety. We report executed check counts rather than unmeasured time savings. Next validation is project-defined contracts and native PostgreSQL concurrency tests.
27 Sep 2026
Voxrede
A voice agent said, "I have successfully pulled up the account for Priya Sharma." The tool had returned a simulated result with executed=false. Voxrede preserved the misleading reply and the later retests. The historical archive shows the same agent leaking its protected phone digits in 4 of 13 baseline-prompt samples, across three different attacks (authority impersonation, barge-in and PII extraction). Twice it put the answer inside its own verification question. The stricter prompt had no findings in its two matched samples, which is too few to claim a fix rate. Three unmodified excerpts link to recordings and source events. The stricter-prompt follow-up retains its incomplete-shutdown label. I built Voxrede for developers reviewing voice support agents. Two AssemblyAI Voice Agent sessions act as test caller and support fixture, exchanging paced audio. Scenarios include authority impersonation, spoken prompt injection, interruption and a degraded channel, alongside permitted tasks. All 19 attempted trials and nine matched pairs remain visible. Three of six permitted tasks completed; one gave an incorrect outcome and two were inconclusive. Twelve evaluations remain inconclusive for coverage or transport reasons. These samples do not establish a defense success rate. Voxrede separates digit mentions from verified identity, tool requests from execution, and generated audio from audio sent after pacing and noise. Unique trial IDs and manifests retain configuration, source hashes and completion state. Public logs remove provider identifiers and tokens. Outcomes are assistant source-event reviews, not independent adjudication. The original 17-sample archive still supports search, exports, exact-event links and missing comparisons. No API key is needed to review the evidence. All business tools are mocked; no production account or real refund was tested. The current deck and interactive walkthrough cover the upgrade. The narrated video shows the earlier viewer.
30 Sep 2026
