Breakage Probe

A change can pass every status check and still be wrong. The cart returns a total, the login returns success, search returns products. Every request comes back 200. None of that says the number, the password check, or the filter was right. Breakage Probe is for the developer who wants those paths checked before calling a change done. The sample storefront has three quiet failures. Two items at 10 a n d o n e a t 10andoneat15 should total 35 ; t h e c a r t r o u t e a d d s e a c h p r i c e o n c e a n d r e t u r n s 35;thecartrouteaddseachpriceonceandreturns25. The buyer password is shipit-now; the prefix ship still signs in, because the check uses startsWith. A search for category=kitchen should return two kitchen items; the route reads the category and discards it, so all four products come back. Checking those by hand means remembering each expected value, sending each request, and comparing the body. It is easy to skip a path, and easy to take a 200 as a pass. Breakage Probe runs the three checks at once. Each probe knows the right answer: the cart must total 35, the login with ship must be rejected, the kitchen search must return exactly two kitchen items. There are two ways to run it: In IBM Bob. The repository ships a skill, skills/breakage-probe/SKILL.md. Asked to follow it, Bob launches Cart, Auth, and Search probes as three parallel subagents against the running app, writes reports/breakage-latest.json, and names the route file behind each failure. On the dashboard. Press Run parallel probes. Three lanes run together and land red or green, each with the expected value next to what came back, the severity, the file, and the steps to repeat the request. The dashboard also closes the loop. Each planted bug has a fix switch. Tick Fix cart total and run again: the cart lane turns green and says it is now passing, while login and search stay red until they are fixed too. The storefront page uses the same switches, so the bug and its fix can be seen in the app itself. The approach is specific on purpose. A probe is only as good as its expected value, so each one encodes the business rule for its path rather than a generic "did it respond" check. Running them in parallel as separate agents keeps each check small and independent, and a failing lane always points at the file to open. The live demo runs at https://probe-liard.vercel.app. The same checks run from a terminal with npm run probe.