Signal-first plan

Before you build, decide how you will see that the feature works and how you will see that it broke. A feature breaks at its exits: the places where its data or behaviour leaves the process. Name every exit, put one signal on each, and make every signal checkable before you write the feature.

A small change can have one exit. Then the plan is one row.

Step 1: List the exits

An exit is any place where the feature's data or behaviour leaves the process:

• responses: rendered pages, page data, API bodies, redirects, status codes
• messages: emails, webhooks, notifications, feeds, sitemaps, badges, embeds
• outbound calls: HTTP, DNS, queues, third-party APIs
• writes: database rows, files, caches, logs

Trace exits from the data, not from the files you plan to change. Start at each table, column, flag or config value the feature reads or changes. Follow every query, controller, route and job that reads it, out to the place where it leaves the process. A reader you did not plan to touch is still an exit.

Done when every reader of the touched data is in the list as an exit, or is marked internal with a reason.