Software for three small screens.

You are helping me build and ship a small app. Work in small, verified steps, and do not write code until we have agreed on a spec.

Step 1. Ask me these questions first, one message, then wait for my answers:
1. What does the app do, in one sentence, and who is it for?
2. What platform does it run on, and what are its hard limits (screen size, inputs, storage, network)?
3. What data does it touch: what it reads, what it stores, where it sends anything?
4. Where will it be released, and what does that store or host check before accepting it?
5. What is the smallest version worth shipping?

Step 2. Write SPEC.md, one page. It covers the purpose, the smallest shippable version, the layout stated in exact numbers (sizes, limits, counts), the data the app handles, and what is out of scope. If a screen cannot be written as boxes and numbers, it is not designed yet. Show me the spec and wait for my approval.

Step 3. Write CLAUDE.md for this project. Include: the platform constraints, what is deliberate and must not be changed by accident, the rule that credentials never go inside a shipped package, and the rule that a check which could not run must never be reported as a pass.

Step 4. Build in small steps. After each step, run the app or its tests and tell me what you actually exercised and what you did not. Commit each working step with a message saying what changed.

Step 5. Write a gate script, check.sh or similar, that runs before any release: build succeeds, tests pass, no secrets or keys in the package, version numbers match, the privacy page exists. A failing gate blocks the release. Treat a failure as the finding, not something to route around. Confirm that any tool the gate uses really parsed its input, because an empty result from a tool that read nothing looks exactly like a clean one.

Step 6. Write PRIVACY.md from the code, not from the spec. List every piece of data read, stored or sent, with the file and function that does it. Then do a separate pass that checks each sentence against the code and removes or corrects anything the code does not support.

Step 7. Keep UNCONFIRMED.md. Any claim nobody has verified (device behaviour, performance, compatibility) goes there instead of into the docs or store listing. Report its count before each release.

Step 8. Keep CHANGELOG.md. One dated entry per version: what was asked, what broke, the root cause, what was fixed, and what was not tested before release. Untested behaviour is not a reason to hold a release. It is a reason to say so in the entry.

Step 9. When the gate passes, package the build and cut a tagged release with the built file attached, in the same session. Committed but unreleased is unfinished.