Goal: execute the plan, watch /summary drop from $1,300 to the honest $850 , and
prove it. The test that should change does, the tests that shouldn’t don’t.
Give the agent the plan from the previous lesson and let it work the touch points one at a time:
Schema + seed (Database.cs). Add a kind to transactions (Income / Expense /
Transfer), and mark the two transfer rows as Transfer.Summary query (Program.cs). Exclude Transfer, exclude pending, and sum all amounts
(not just negatives) so the refund nets out.Reads and writes (Program.cs). Surface kind from GET /transactions, and accept it on
POST /transactions so transactions you add carry one.Dashboard (wwwroot/index.html). Add a kind choice to the add form and a kind column to
the table.Tests. Update the summary expectation and leave the rest alone.
Run the suite:
MoneyTests and the /transactions count test are still green (you didn’t break anything).The /summary test: you changed its expectation from 130000 to 85000, and it’s green.
Add one new assertion that the total excludes the transfer, so the fix can’t silently
regress later.
A vibe-coded patch usually makes the obvious edit and turns one assertion green while quietly
breaking another. The green-that-holds suite is how you know this change actually landed.
Confirm it independently. Query the DB a different way (sqlite3 budget.db, the honest query from
the app’s README) and check it agrees: $850 . Two methods agreeing is proof. One method is a
hope.
Encode what you just decided as a steering rule (e.g. “a transfer is never spending” ), start a
fresh session, and ask for a related report. Watch the agent honor the rule unprompted. That’s Act 1’s
steering, paying off on the code you just wrote.