verify

Topics in the source

• Map every feature, prove it like a user
• The verification guide
• The feature map
• Prove, never weaken
• Keep it honest

An agent arriving cold does not know what "working" means in this product. The feature map writes it down once, from the user's side, so any agent can prove behavior instead of trusting a green API. Create docs/verify/README.md in the project, written for the next agent: Launch: the exact command that starts the app for verification, and how to tell it is usable (not just that a process answers). Include seed data and teardown. Health check: one read-only check that answers "is this instance worth driving?": right version, our port, valid session. Drive: how to operate it the way a person does: browser automation, a terminal session, plain HTTP for services. Use stable handles (accessible names, roles, routes), never CSS classes or positions. Evidence: what to capture (screenshot of the action and of the result, the row written, the message sent) and where it is kept. Cleanup: stop only what you started; never delete the evidence. docs/verify/features/README.md lists the features; each has its own file with four sections: Start with the three to five features people use most. When a feature has several entry points (screen, API, link), proving one of them is an incomplete proof. Ru

This is an excerpt. Refer to the complete source and its current requirements.