ducoterra
95ca3fd1fa
**Final report — phase 07 final verification pass** - **Verified:** all 5 tasks present in `complete/`; app boots (`/healthz` 200, `/` 200, static + atlas + `/api/levels` served); `docs/CLIENT.md` module map matches the on-disk `app/static/` tree; no code defects found. - **Tests/lint/coverage:** `bash .agents/validate.sh` → ruff clean, pyright 0 errors, `undercooked-levels validate` pass, **full pytest 1838 passed, 97.21% coverage (floor 90%)**, slow sim stage 2 passed, repo hygiene clean. `uv run pytest tests/e2e -q` → **53 passed** (all 8 suites added this phase). - **Criteria:** (1) two tabs create→join→ready→start→serve one dish, keyboard only — green via `test_us01/02/03/04` ✔; (2) e2e green ✔; (3) canvas non-blank, pixels change after a move — `test_us04_render_smoke` ✔; (4) HUD score within 200 ms of the `served` event — asserted, green ✔; (5) zero console errors + zero off-origin requests — `test_atlas_loads` / `test_us01_landing_surface` ✔; (6) `docs/CLIENT.md` matches layout ✔; (7) 100% suite + 97.21% ✔; (8) docs pass below ✔; (9) no regression in completed phases (all prior suites green) ✔. - **README.md fixed:** status still said "next pending phase is 07" → now 07 complete, 08 pending; the phase-07 client text buried in the phase-05 bullet → its own "canvas client, art, HUD (phase 07)" bullet; stale "What does not exist yet" (claimed movement/controls missing) → rewritten to phases 08–14; "once the room flow ships" → "live in the browser today"; Layout `app/static/` "renderer arrives with the rest of phase 07" → full shipped-client map; Layout `docs/` "CLIENT lands with phase 07" → `CLIENT.md` listed; added `gen_art_index.py` Layout entry. - **AGENTS.md fixed:** "the eight screens" (7 listed) → "the seven screens" (+ `dom.js` is the shared builder, not a screen); e2e naming line → notes the non-story guard `test_atlas_loads.py`. - **Decisions:** no code changes were needed; only the two doc fixes above. Docs re-verified by `test_docs_commands`/`test_docs_index` (44 passed) plus the final full gate. - **Next pending phase:** `08_client_prediction_and_touch`.
35 lines
1.2 KiB
CSS
35 lines
1.2 KiB
CSS
/* Undercooked palette (phase 07, task 01).
|
|
*
|
|
* The single source of every colour the DOM and the Canvas 2D renderer
|
|
* both use. The canvas half re-exports the same hex values from
|
|
* app/static/js/render/palette.js; tests/unit/test_assets.py asserts the
|
|
* two files agree, so the CSS and the canvas can never drift apart.
|
|
*
|
|
* The four cook colours are what a player sees their own and their
|
|
* teammates' cooks in; [data-palette="cb"] swaps them for the Okabe-Ito
|
|
* set, which stays distinguishable under deuteranopia/protanopia. The
|
|
* semantic colours name the game's state vocabulary (a danger reads red,
|
|
* a ready reads green, dirt reads mud) and are shared by the CSS, the
|
|
* JS module and the SVG var() fallbacks in app/static/assets/.
|
|
*/
|
|
|
|
:root {
|
|
--uc-cook-1: #e0533d;
|
|
--uc-cook-2: #3d84a8;
|
|
--uc-cook-3: #7da84b;
|
|
--uc-cook-4: #b0699a;
|
|
--uc-danger: #ff5a4e;
|
|
--uc-hot: #ffa63d;
|
|
--uc-ready: #67d16c;
|
|
--uc-dirty: #9a8f7a;
|
|
}
|
|
|
|
/* Okabe-Ito cook colours: colourblind-safe (deutan/protan) without
|
|
losing the "four different cooks" signal. */
|
|
[data-palette="cb"] {
|
|
--uc-cook-1: #d55e00;
|
|
--uc-cook-2: #0072b2;
|
|
--uc-cook-3: #009e73;
|
|
--uc-cook-4: #cc79a7;
|
|
}
|