spec-driven-workflow

# Spec-driven workflow (Spec Kit style) ## Before touching code 1. Read `.specify/memory/constitution.md`, then `specs/001-weather-by-city/{spec,architecture,security,plan,phases,tasks}.md`. 2. Find the **current phase** in `phases.md` (first row whose gate is `[ ]`). Work only on tasks in that phase. 3. If the request is not covered by a task, **stop**: propose a spec/tasks amendment first (Constitution I.3). ## Per task (loop) 1. Pick the next unchecked task `T-nnn`; note its `FR`/`SEC` tags. 2. Write the failing test(s) first; run them; confirm they fail for the right reason. 3. Implement the minimum to pass. Follow the matching skill (`spring-grpc-service`, `oauth2-oidc-resource-server`, `open-meteo-client`). 4. Run the module tests (`mvn -q -pl <module> -am test`). Tick the box in `tasks.md`. 5. Keep commits/changes small; mention `T-nnn` in commit messages. ## Phase gate 1. Run `spec-consistency-check`. 2. Run `mvn -q verify` (or the phase's exit command) — show real output, never claim success without it. 3. Tick the gate in `phases.md` only when every exit criterion is demonstrably met. Report failures honestly. ## Never * Skip a phase, skip tests, weaken security to make a test pass, edit `.claude/**` or the constitution, add scope silently. * Invent API behavior: verify against the contract (`contracts/location.proto`) and Open-Meteo docs.