ScribblaZ Verification

This page separates source-confirmed contracts from browser and multi-client evidence that still must be collected.

Docs: Hub · Architecture · Game design · Opcodes · Runbook · Nakama Multiplayer · Games Catalog

Evidence checklist

Manual test record

For every pending row, record the date, route/environment, number of clients, exact observed phase/messages, and any RPC payload. Do not upgrade a pending row based only on source inspection: source confirms intent and implementation visibility, not deployment or interactive behavior.

Current-cycle boundary

Every server-side row above was proven against production Nakama. The module is hostPath-mounted from /home/usr/funday/nakama-modules, so shipping it is npm --prefix nakama-modules run build followed by sudo k3s kubectl -n funday-platform rollout restart deployment/nakama; the runtime confirmed the load with ✅ scribblaz_ts_match registered (TypeScript runtime). Client-side rows were proven on an isolated detached-master worktree served by Vite on 127.0.0.1:5200, proxying /api and /ws to https://funday.gg with the Origin/Referer headers rewritten so the CSRF guard accepts them. Production was deliberately not rebuilt: the shared tree carries other agents’ uncommitted work, which AGENTS.md §01.2/§01.5 forbid shipping.

Three defects were found by running the thing rather than reading it, and all three are fixed in this cycle:

1. The gallery RPCs were unreachable. drawingPersistence.ts posted to /api/rpc/<method>, which no route serves; the platform contract is POST /api/plugins/rpc with a {pluginId, method, payload} envelope, and the gateway rejects any method not prefixed by its plugin id. Both call sites were corrected and the scoped test now asserts the envelope rather than the old URL.
2. The drawer could never resync. matchLeave ended the round the instant the drawer’s presence dropped, so a reloading drawer always came back to a finished round — the re-send branch was unreachable. word_pick is now excluded from both the round-end and the quorum-reset branches and rides out its bounded 10 s window instead, with the quorum rule re-applied at pick expiry so a match can never stall.
3. A reload always dropped the player. The shell creates its Nakama socket lazily from lobby/route actions, while funday:request-match only reads it — so a game asking to rejoin right after mount always got Socket is unavailable, measured 7 refusals over 2.4 s. Retrying in place cannot work; the game now hands the rejoin to the route’s ?join= entry point, once per match per tab.

Nothing from that list remains open: 10.14 was closed on 2026-08-01 with a real two-client round, a real Publish, and a rendered grid.

2026-08-01 cycle — hardening

This cycle shipped to production. master was deployed with scripts/build-atomic.sh and the Nakama bundle was rebuilt and rolled out. Four defects were found by running it, three of which source review had already passed over:

1. Operator authority could be inherited. The gate matched an allowlisted username, and usernames are client-settable here — a renamed or deleted operator freed a name for the next account to claim. Authority is now the Nakama-resolved user id alone.
2. Provisioning silently unresolved every operator. normalizeList lowercased entries, but nk.usersGetUsername matches exactly, so the first live re-provision returned all seven names in unresolved and left one operator id standing. Caught only because the RPC reports unresolved instead of dropping names.
3. The plugin gateway delivered no arguments. client.rpc already JSON-encodes its input, so the gateway’s pre-stringified payload encoded twice and every RPC field read undefined at HTTP 200. It survived the previous cycle because the only RPC exercised through the gateway, scribblaz_get_gallery, defaults every field it reads. A live Publish answered Missing word or lines and exposed it. Its unit test had asserted the buggy contract against a mock.
4. The drawing size cap was unreachable. 512,000 bytes sits above Nakama’s ~256 KB request-body limit, so oversized saves died in the transport with an opaque error and the guard never ran. Measured the ceiling (261,403 accepted / 278,083 refused) and moved the cap to 200 KB.

Operator provisioning (current procedure)

Authority lives in one system-owned object, kanban_admin/operators, with permissionRead: 0, permissionWrite: 0. Its value is { userIds: string[], resolvedFrom: { [username]: userId } }; only userIds authorizes — resolvedFrom is an audit trail. Provision through the runtime HTTP key, which is the only transport Nakama dispatches sessionlessly:

IP=$(sudo k3s kubectl -n funday-platform get svc nakama -o jsonpath='{.spec.clusterIP}')
REAL=$(sudo k3s kubectl -n funday-platform get secret nakama-runtime-secrets -o jsonpath='{.data.runtime_http_key}' | base64 -d)
curl -s -X POST "http://$IP:7350/v2/rpc/kanban_set_operators?http_key=$REAL" \
  -H 'Content-Type: application/json' \
  -d '"{\"userIds\":[\"<uuid>\"],\"usernames\":[\"ExactCaseName\"]}"'

Usernames are case-sensitive and are resolved to ids once, here. Require unresolved: [] in the response; a name that does not resolve has no Nakama account — report it, never invent an id. Re-provision in the same window as a rollout that changes the stored shape, or session-backed operators lose board writes until you do.

⚠️ .agents/skills/funday-game-feedback-kanban/SKILL.md §0 still documents the superseded procedure (no kanban_set_operators, no provisioned user id). Agents must not edit user-authored skills, so this section is the current source of truth.

2026-08-01 cycle — backlog close

The remaining CHECKLIST.md backlog shipped in the same session: reduced-motion and haptics, fluid type and a portrait hint, component extraction with lazy modals, emotes and likes, the Drawing Trainer, and a two-client Playwright spec. 76/77 items are now closed; the one open item is 3.4 animation mode, deferred by design.

Three defects surfaced only by playing the deployed build, and each was invisible to the test suite that “covered” it:

1. A single Like ended the match. likesThisRound was a Set in match state. Nakama does not preserve Set identity between ticks, so it returned as plain data and handleRateDrawing threw TypeError: Object has no member 'has' — and Nakama stops a match whose loop throws. The unit tests passed throughout because vitest keeps a real Set; the regression test now round-trips the state through JSON, which is what actually reproduces the runtime.
2. Emotes could never be sent. Outgoing match state is base64-encoded with btoa, which throws on any code unit above U+00FF, and the send resolves asynchronously so the throw escaped send()’s try. The wire now carries an index into ALLOWED_EMOTES, and send() escapes any remaining non-Latin-1 character — a player typing an emoji into a guess hit the identical wall.
3. The relay handler was dead on arrival. The controller used ALLOWED_EMOTES without importing it, throwing ReferenceError the moment a float mounted. svelte-check reported clean the whole time: games/ is outside the frontend tsconfig, and the platform’s undefined-identifier guard reads .svelte templates only, never .svelte.ts. The rule now lives in a pure decodeEmote() the root runner can execute.

✅ Resolved 2026-08-03: games/micro-racing, games/pacman, games/tetris and games/wolfenfun all have tracked funday-plugin.json manifests (git ls-files --error-unmatch succeeds for each), so the committed game_registry.generated.ts regenerates identically in a clean HEAD worktree. bash scripts/build-atomic.sh --from-head completed with its registry-freshness gate passing inside the deploy worktree and restarted funday-frontend (ActiveEnterTimestamp=Mon 2026-08-03 09:37:02 CEST). The AGENTS.md §01.2 deploy protection is intact.

2026-08-01 cycle — visual review

The previous cycle verified the trainer behaved — it unlocked, scored 7%, and reported its tier — and shipped it. Nobody looked at it. Playing it shows why that is not enough, and player feedback in the lobby chat had already said so: “Drawing Trainer ultra thrashy ui/ux and broken”.

The trainer told the player to “trace the key lines” over an empty canvas. TRAINER_MOTIFS has carried full stroke geometry from the start, but nothing ever rendered it: the UI showed the motif’s emoji on a 24 rem card parked over the drawing area. With no target on the canvas, scoreDrawing was comparing a sketch against an invisible reference — a recognisable star scored 0%. The 7% recorded above was noise, not a score.

The motif is now the interface. It paints onto its own canvas layer and the card is gone.

Two notes for later, deliberately not acted on here:

• renderTrace and scoreDrawing share fitTrace. They must keep sharing it — the moment the ghost is drawn with one mapping and scored with another, the player traces one shape and is graded against a different one. That is the exact class of bug this cycle fixed.
• A player asks in chat: “what the fudge is the 2nd Chat message and where does it even end up using the other chat input?” — ScribblaZ’s in-game GuessChat and the platform drawer chat are two separate inputs with no relationship shown. Real confusion, out of scope for this pass.

⚠️ Free-draw autosave is rejected in production and nothing surfaces it. A single click on the solo canvas fires the debounced POST /api/storage/write, and Nakama answers 400 — "Storage write rejected - permission denied." The drawing is silently not saved. This is not caused by the trace work: a plain page load produces zero failing requests, and the same click reproduces the 400 with the trainer never activated. It contradicts the 10.15 row verified on 2026-07-31, which observed a successful 5771-byte write — so either the write permission changed server-side or the earlier check ran as a differently-privileged account. Needs its own pass; the client should at minimum report the failure rather than discard it.