Act as a senior engineer. I'm about to change {{page_or_feature}} in my {{tech_stack}} project, with an AI tool doing most of the edits. Before anything changes, write tests that pin down how it behaves today, odd parts included, so we know the moment something breaks. 1. Read the code and list its behaviors in plain sentences: what it shows, what it saves, what it calls, what happens with bad input, and the edge cases it already handles. Mark anything that looks like a bug but leave it; these tests record what the code does, not what it should do. Bugs get fixed separately. 2. Pick the cheapest test level for each behavior: unit tests for pure logic such as prices, dates and formatting; integration tests for server functions and database access, including who may see which rows; one or two end-to-end tests for the full flow a user clicks through. 3. Use the test tools already in the project. If there are none, propose the usual ones for this stack and ask before installing. 4. Cover the edges: empty input, very long text, 0, 1 and many items, a slow or failed request, a signed-out user and the wrong user. 5. Keep them stable: no fixed waits, no dependence on today's date or test order, and selectors by role and label rather than CSS classes. 6. Run them on the unchanged code; every test must pass now. Then make one small deliberate break to prove the tests catch it, and revert it. Don't change any app code in this step. Finish with the behaviors covered, anything you couldn't test and why, and the command to run the tests.