⛩ TORII CONTINUUM

Torii Quest v0.2.497-alpha

Project oversight dashboard
PROJECT OVERSIGHT · STATIC · READ-ONLY
Live: torii-quest.pplx.app · godMode false · build truth (live trails — manual deploy) · packaged: 2026-08-16T13:58:40.869Z

Active focus

What the project is pointed at right now — read this first.
15-hour proof-of-concept route — shooter is maintenance-only unless demo-breaking; the active MVP is the freedom-tech loop (gateway/NAP-to-NAP preview → Plebeian/Nostr product panel → leaderboard preview → torii.quest update-check). Polish comes after PoC validation.

Handoff / release control panel

HANDOFF READY · MVP BLOCKER PENDING (USER PLAYTEST + OK) GENERATED HANDOFF / RELEASE CONTROL PANEL · LOCAL · READ-ONLY · ONE-GLANCE PICKUP
Read this FIRST. One read-only surface to pick up the project safely: current version + live URLs, the latest app-entry and oversight-dashboard cloud smokes, the one manual blocker (user runs the live-browser MVP playtest + explicitly approves), the next safe no-blocker task, the actions NOT to take without user input, and the project's practical operating principles. GREEN here means the handoff surface is complete — NOT that the MVP is approved.
Versionv0.2.497-alpha
Live gamehttps://torii-quest.pplx.app
Live dashboardhttps://torii-quest.pplx.app/dashboard.html
Entry smokePASS @ v0.2.230-alpha (3/3 checks; implies approval: no)
Dashboard smokePASS @ v0.2.231-alpha (4/4 checks; implies approval: no)
Manual blockerPENDING — PLAYTEST DOCS INCOMPLETE
MVP approvalAPPROVED
Next safe taskContinue the read-only oversight loop — next safe infra/dashboard slice
Do NOT (without user OK)
  • Do NOT deploy, publish, or push — the maintainer performs the manual deploy.
  • Do NOT create a git tag, GitHub release, or announcement.
  • Do NOT perform any live Nostr write (no signing, no relay publish) beyond the existing read-only NIP-07 reads.
  • Do NOT make a payment or move real value — alpha sats are fake.
  • Do NOT mark the MVP approved — only the user can, after running the live-browser playtest.
  • Do NOT enable godMode or any debug capability in shipped runtime — godMode stays false.
  • Do NOT add network calls, auto-update, or external redirects to the oversight surfaces.
Workflow invariants
  • Do NOT cancel a useful in-progress job halfway through — finish it first, THEN process the user's next request. Cancelling useful work wastes compute time and money.
  • Exception — explicit cancel: the user explicitly asks to cancel or abandon the job.
  • Exception — immediate conflict: the running job conflicts with an immediate user request (e.g. it would clash with edits the new request needs now).
  • Exception — safely resumable: the work can be safely resumed later from where it left off, so stopping loses nothing.
  • Exception — stale/hung & already shipped: the job is stale or hung AND its output has already been committed, shipped, pushed, synced, and smoke-tested — stopping it only avoids further waste.
Operating principles
  • Self-sovereignty: the user owns their identity (their npub) and their data; the project never holds the keys to a user.
  • Consent first: nothing signs, publishes, pays, or navigates on the user's behalf without an explicit, informed action.
  • Privacy by default: collect nothing by default; no surveillance, no tracking, no telemetry phoned home.
  • Open protocols: build on Nostr, Bitcoin, and ecash so the user can leave and take their identity and value with them.
  • Free and open source: the code is FOSS so anyone can read, fork, verify, and self-host it — no black boxes.
  • No vendor lock-in: interoperable by design; data and identity stay portable across clients and relays.
  • Local circular economics: favour voluntary, peer-to-peer value exchange over extractive, ad-funded, or rent-seeking models.
  • No dark patterns: no manipulation, no coercive monetization, no engagement traps — the user stays in control.
  • Reversible, user-controlled actions: prefer actions the user can undo and explicitly trigger over irreversible automatic ones.
  • Community agency: tools should grow the community's capability to act for itself, not centralise control.
  • Truthful status reporting: dashboards and handoffs report the real posture — a pass is never claimed without the evidence behind it.
EthicsThese are practical operating principles, not dogma: Torii Quest exists to give people self-sovereign, consent-driven freedom tech on open protocols (Nostr, Bitcoin, ecash) with no surveillance, no dark patterns, and no lock-in. When a decision is ambiguous, choose the option that keeps the user in control of their identity, data, and value, and that reports status truthfully.
Handoff / release control panel — the single read-only surface a fresh agent or human reads first to pick up the project safely: current version + live URLs, the latest app-entry and oversight-dashboard cloud smokes, the one manual blocker (the human must run the live-browser MVP playtest and explicitly approve), the next safe no-blocker task, the exact actions NOT to take without user input, the standing workflow invariants (e.g. finish a useful in-progress job rather than cancelling it), and the project's practical non-religious operating principles. GREEN means this surface is COMPLETE + trustworthy, NOT that the MVP is approved: a smoke pass is not approval, a dashboard pass is not a completed human playtest, and no live Nostr write is ever implied. It approves/releases/deploys/publishes NOTHING.

Ship readiness

NOT READY GENERATED SHIP READINESS · LAST GATE · READ-ONLY
The last local release-readiness verdict (npm run release:status) and the next safe task to pick up — read-only; the gate stays the authority.
Next safe task ▸ Continue the read-only oversight loop — next safe infra/dashboard slice
Keep shipping no-runtime-risk tooling/docs that make AI handoff faster and the gate harder to get wrong (e.g. package the release:status verdict as a build artifact, or add a docs-freshness signal). SEC-gated live-relay / world-hop work stays parked behind SEC-1/2/3 and a manual deploy — not a safe pick yet.
SignalStateDetail
Version syncokconfig v0.2.497-alpha / pkg 0.2.497-alpha
Test profilesblockedfast 5 · foundation 25 file(s)
Regression gateok21 / 21 checks
Bundle baselineskippedno dist/ — build then bundle:report
/zone/* fallbackblockedmissing or unreadable doc: VPS_INSTALL.md (must document the /zone/* SPA fallback); missing or unreadable doc: torii-quest-handoff.md (must document the /zone/* SPA fallback)
Docs consistencyblockedmissing core doc: torii-quest-todo.md; missing core doc: torii-quest-progress.md; missing core doc: torii-quest-handoff.md
Blockers: tests, zoneFallback, docs
The last local release-readiness verdict (run: npm run release:status) plus the recommended next SAFE task. Read-only oversight — it mirrors the gate, never runs a deploy/publish. GENERATED at packaging time from the live signals; LAST-KNOWN (last green gate) when not regenerated this build. The regression gate stays the authority. Verdict for v0.2.497-alpha. Full gate: npm run test:release.

RC / release manifest

ARTIFACTS INCOMPLETE GENERATED RC / RELEASE MANIFEST · LOCAL · READ-ONLY
Release-candidate artifact posture — manifest + RC-doc coverage, test count, and the manual validation still outstanding. Read-only; release/tag/publish stay manual + user-approved.
Source versionv0.2.497-alpha
Release manifest
  • INCOMPLETE
  • 3/6 required present
  • 1/6 optional present
RC package docs0/7 present
Tests2637 passing / 196 files
Test profiles
  • fast ~5
  • foundation ~25
  • full
Manual validation remaining7 live-browser checks pending
Last release gateNOT READY
Release-candidate artifact posture — the release-artifact MANIFEST (required/optional present) and RC package-doc coverage, the curated test count, the manual validation still outstanding, and the last local release-gate verdict, folded into one read-only band. GENERATED at packaging time from on-disk artifact presence; LAST-KNOWN when not regenerated this build. It releases/tags/publishes/deploys NOTHING — manual live-browser validation and explicit user approval stay required (run: npm run rc:snapshot / npm run release:manifest).

MVP approval

MVP APPROVED GENERATED MVP APPROVAL · LOCAL · READ-ONLY · PENDING UNTIL EXPLICIT USER OK
The single auditable approval gate (MVP_APPROVAL_STATE.json). Local gates are green, but the MVP is NOT approved until a human runs the live-browser playtest and explicitly says "MVP approved". Read-only.
Approval statusAPPROVED
Versionv0.2.497-alpha
Approved bynpub1a3um269aaf3u5cy37kuykrrrnsg2pyv7za06pxjduv25lq5sdujs2qmdj6
Approved at2026-07-27T13:05:00Z
Next stepnone — MVP approved
MVP approval state — the single auditable record (MVP_APPROVAL_STATE.json) of whether a human has EXPLICITLY approved the live-browser MVP. Local automated gates are green, but approval is a manual step: the user must run the playtest and say "MVP approved" (which also records approved_by + approved_at). Status stays PENDING until then and can never silently flip — there is no --approve path in the read-only CLI (npm run approval:state). GENERATED at packaging time from the on-disk record; LAST-KNOWN when not regenerated this build. It approves/releases/tags/publishes/deploys NOTHING.

MVP approval gate

MVP APPROVED (EXPLICIT HUMAN OK RECORDED) GENERATED MVP APPROVAL GATE · LOCAL · READ-ONLY · GREEN CHECKS ≠ HUMAN APPROVAL
The rubric for sign-off. Automated tests, the release gate, and the cloud smokes are CONFIDENCE signals — green means the code and deployed surfaces look healthy, NOT that the MVP is approved. Approval is a separate explicit step: a human runs the live-browser playtest and says "MVP approved". Read-only.
Gate verdictAPPROVED
Release gatenot yet (confidence only, not approval)
Entry smokegreen (confidence only, not approval)
Dashboard smokegreen (confidence only, not approval)
Test suitegreen — 2637 passing / 196 files
Explicit approvalAPPROVED by npub1a3um269aaf3u5cy37kuykrrrnsg2pyv7za06pxjduv25lq5sdujs2qmdj6 @ 2026-07-27T13:05:00Z
How approval works
  • Automated tests and cloud smokes are CONFIDENCE signals: green means the code and the deployed surfaces look healthy — it is NOT approval.
  • MVP approval still requires an EXPLICIT human OK: a person (Chiefmonkey / the user) runs the live-browser playtest and says "MVP approved".
  • A smoke pass is not MVP approval and a dashboard pass is not a completed human playtest — the gate stays PENDING until the explicit sign-off is recorded.
Manual playtest focus
  • Entry flow: title screen loads, ENTER ARENA and LOGIN WITH NOSTR give visible feedback, pointer-lock engages.
  • Shooter feel: the core shoot → hit → respawn loop feels responsive and fair.
  • Hit registration / headshots: connecting shots register, and headshots vs body shots resolve as expected.
  • Bot behaviour: bots move, react, take damage, die, and respawn without freezing or stalling.
  • Movement / footsteps: WASD + jump are smooth, walls hold, and footstep feedback tracks motion.
  • Reload feel: reload triggers, feels snappy, and refills ammo to the magazine size.
  • Mirror / reflection: the mirror is coherent (no garble / recursion meltdown) and not a framerate sink.
  • Crates: crates are solid under movement and fire and do not jitter, launch, or sink through the floor.
  • NAP monkey: crossing the torii gate into the Non-Aggression zone disables the weapon and bots do not follow.
  • Dashboard clarity: dashboard.html renders the version, test status, and active slice clearly and matches the build.
  • Subjective fun / feel: any game-feel blocker that makes the proof unconvincing, even if every automated check is green.
MVP approval gate — the rubric that keeps automated green from being mistaken for human game-feel approval. The automated tests, the release gate, and the two cloud smokes are CONFIDENCE signals: green means the code and the deployed surfaces look healthy, NOT that the MVP is approved. Approval is a separate, explicit step: a human (Chiefmonkey / the user) runs the live-browser playtest — judging entry flow, shooter feel, hit registration / headshots, bot behaviour, movement, reload, mirror, crates, the NAP monkey, dashboard clarity, and overall fun / feel — and then says "MVP approved", which records the approver and timestamp in MVP_APPROVAL_STATE.json. A smoke pass is not approval and a dashboard pass is not a completed playtest. This card approves/releases/deploys/publishes NOTHING.

Playtest results

PLAYTEST NOT RUN · NO RESULTS RECORDED YET LAST-KNOWN MVP PLAYTEST RESULTS · LOCAL · READ-ONLY · NOT RUN UNTIL TESTER RECORDS · NOT AN APPROVAL
Whether the actual manual playtest results have been recorded (MVP_PLAYTEST_RESULTS.md), and what they said. Ships blank → NOT RUN. A recorded result never implies approval — that stays a separate explicit user gate. Read-only.
Results statusNOT-RUN
Recordedno — results file still blank
Itemsnone recorded
Implies approvalno — approval is a separate explicit user gate
Next stepUser: run the live-browser playtest, then record results in MVP_PLAYTEST_RESULTS.md
MVP playtest results state — read from the source-controlled MVP_PLAYTEST_RESULTS.md, the one place a tester records the actual manual live-browser playtest outcomes. It ships BLANK, so a fresh build reads NOT RUN. A recorded result is NECESSARY but NOT SUFFICIENT for MVP approval: even an all-PASS playtest still needs the explicit user "MVP approved" (the separate MVP-approval gate above). This card can never imply approval — approvalImplied is pinned false. GENERATED at packaging time from the on-disk file; LAST-KNOWN when not regenerated this build. It approves/releases/tags/publishes/deploys NOTHING.

Playtest verdict

NO VERDICT RECORDED YET LAST-KNOWN MVP PLAYTEST VERDICT · LOCAL · READ-ONLY · TESTER VERDICT ≠ MVP APPROVAL
The one-line live-browser verdict: Chiefmonkey reports "MVP OK" or "blockers: …" in MVP_PLAYTEST_VERDICT.md. Every reported blocker stays visible here. A tester verdict is a confidence signal — it NEVER approves the MVP; approval is the separate explicit user step. Read-only.
Verdictpending (not reported)
Blockersnone reported
Reported by(not recorded)
How to report
  • Report MVP OK (no blockers found): write a line `Verdict: MVP OK`.
  • Report blockers: write a line `Verdict: blockers: <comma- or semicolon-separated list>`.
  • Reporting a verdict NEVER approves the MVP — approval is the separate explicit step recorded in MVP_APPROVAL_STATE.json.
Focus to judge
  • Entry flow: title screen loads, ENTER ARENA and LOGIN WITH NOSTR give visible feedback, pointer-lock engages.
  • Shooter feel: the core shoot → hit → respawn loop feels responsive and fair.
  • Hit registration / headshots: connecting shots register, and headshots vs body shots resolve as expected.
  • Bot behaviour: bots move, react, take damage, die, and respawn without freezing or stalling.
  • Movement / footsteps: WASD + jump are smooth, walls hold, and footstep feedback tracks motion.
  • Reload feel: reload triggers, feels snappy, and refills ammo to the magazine size.
  • Mirror / reflection: the mirror is coherent (no garble / recursion meltdown) and not a framerate sink.
  • Crates: crates are solid under movement and fire and do not jitter, launch, or sink through the floor.
  • NAP monkey: crossing the torii gate into the Non-Aggression zone disables the weapon and bots do not follow.
  • Dashboard clarity: dashboard.html renders the version, test status, and active slice clearly and matches the build.
  • Subjective fun / feel: any game-feel blocker that makes the proof unconvincing, even if every automated check is green.
Implies approvalNO — a tester verdict is a confidence signal; approval is the separate explicit user OK in MVP_APPROVAL_STATE.json
MVP playtest verdict — the one-line capture for the live-browser playtest. Chiefmonkey (or the user) edits MVP_PLAYTEST_VERDICT.md to report ONE of "Verdict: MVP OK" or "Verdict: blockers: <list>". Every reported blocker stays visible here and in NEXT_ACTION_STATE.json so it can be fed back into todo/progress. A verdict of MVP OK means the tester found no blockers — it is NOT MVP approval: approval is the separate explicit user step (approved + approver + timestamp in MVP_APPROVAL_STATE.json). This card approves/releases/deploys/publishes NOTHING.

Manual validation

PLAYTEST DOCS INCOMPLETE GENERATED MANUAL VALIDATION · MVP PLAYTEST · READ-ONLY
Local automated gates are green, but the MVP playtest is a human, live-browser task. This separates what is no-blocker (local gates) from what still needs manual input (the playtest + explicit approval). Read-only.
Local automated gatesNOT READY
Manual playtest
  • PENDING
  • live-browser run + explicit user approval required
Playtest checklist
  • 13 sections
  • 17 items
Severity coverage
  • 4 blocker
  • 5 major
  • 8 minor
Playtest docs
  • checklist MISSING
  • results template MISSING
Manual validation areas
  • Launch / title screen
  • Shooter loop
  • Movement / footsteps
  • Aim / hit feedback / headshots / body shots
  • Reload feel
  • Gun / reflection / mirror sanity
  • Continuum dashboard + release/update prompt + Nostr read + gateway shell
Manual-validation / MVP-playtest readiness — the one thing the local automated gates can NOT prove. Local checks are green, but a human must still run the live-browser playtest (see the highest-level areas above) and explicitly approve before any release. GENERATED at packaging time from the playtest-checklist section/item/severity counts + on-disk doc presence; LAST-KNOWN when not regenerated this build. It releases/tags/publishes/deploys NOTHING (run: npm run playtest:checklist / npm run playtest:results to refresh the docs).

No-blocker queue

NO-BLOCKER WORK AVAILABLE · MANUAL PLAYTEST AWAITS USER GENERATED NO-BLOCKER QUEUE · SAFE NEXT WORK · READ-ONLY
What an AI agent can pick up next WITHOUT user input — the next safe no-runtime-risk slice plus the active/next/archive queue, separated from the one item parked on the human (the MVP playtest + approval). Read-only.
Next safe taskContinue the read-only oversight loop — next safe infra/dashboard slice
Why safe
  • infra
  • no runtime risk
  • no deploy
  • no gate to unlock
Awaiting userMVP playtest + explicit approval (manual, live-browser) — the ONLY user-gated item
Active now42 in progress
Next up
  • 12 queued
  • next-12
Archive / done
  • 11 landed clusters
  • 27 done (24h)
  • 0 struck markers
No-blocker queue — what an AI agent can pick up NEXT without any user input. The next safe task is a no-runtime-risk infra/docs/tooling slice (no deploy, no gate to unlock); the active/next/archive counts are DERIVED from the same parsed torii-quest-todo.md/torii-quest-progress.md the rest of the dashboard uses (no second source of truth). The ONLY thing waiting on a human is the MVP playtest + explicit approval (see the Manual validation card). GENERATED at packaging time; LAST-KNOWN when not regenerated this build. It queues/runs/deploys NOTHING.

Milestones

4
The one true ACTIVE milestone vs. clearly-labelled SEED/future roadmap.
Total milestones: 4 — 1 active, 3 seed/future SEED · not yet tracked
15-hour proof-of-concept routeACTIVE
The one true ACTIVE milestone — the freedom-tech loop: gateway/NAP-to-NAP travel → Plebeian/Nostr product panel → leaderboard → torii.quest update-check.
47% complete (directional estimate)0 / 5 tasks done
  • 5 tasks total
  • 0 done
  • 4 active
  • 1 pending
Live relay I/O + event signingSEED · future
Gated by SEC-1/2/3 — explicit consent, handoff verification, and URL validation must clear before any wire write or live navigation.
Open-world NAP-to-NAP federationSEED · future
Real in-world portals plus a formalised NAP zone registry, beyond the inert travel preview.
Component / Plebeian market economySEED · future
A CMP component marketplace and real Plebeian.Market listings over the read-only product-panel shells.
One real ACTIVE milestone (its tasks are the 15-hour MVP slices, DERIVED from the route states); the rest are SEED/future milestones — labelled as such, not pretending to carry real task counts yet. Future hook: derive seed milestones from torii-quest-strategy.md.

MVP loop click-through

MOCKUP · READ-ONLY · PROOF ONLY LAST-KNOWN MVP LOOP · CLICK-THROUGH MOCKUP · READ-ONLY · PROOF ONLY
A thin, read-only mockup of the freedom-tech loop (Gateway → Product → Leaderboard → Update → Console). Every screen is a PROOF/MOCKUP card — no navigation, no live data, no actions. Live promotion is gated behind SEC-1/2/3 + manual deploy.
Screens5 mockup views
Proof state
  • 4 proof
  • 1 mockup
Live datanone — read-only mockup, no live surfaces
Actionsnone — no navigation, no writes, no signing
Promotion gateSEC-1 / SEC-2 / SEC-3 + manual deploy (deferred)
Next stepPromote a view to live only behind its SEC gate + explicit approval
1/5 · Gatewayproof
NAP-to-NAP travel handoff: read, confirm, consent, plan, execute chain (inert, same-origin).
Confirmed hop over an injected window/host (v0.2.178) — needs a real same-origin host router + portal mesh to ACT in 3D.
2/5 · Productproof
Read-only Plebeian/Nostr listing preview: title, price (sats), seller npub, and Plebeian.Market link as TEXT.
Shells + visible title-screen preview; needs an in-world mesh + a real listing (no checkout/pay/zap).
3/5 · Leaderboardproof
Unsigned score-event helpers + publisher adapter + read-only view + relay-read proof (kind 30000).
Needs a real NIP-07 signer (SEC-1 explicit consent first) + relay read. No signing/publishing wired.
4/5 · Updateproof
GitHub update-check helper + view-model + release source/status; read-only, actionable:false, no auto-update.
Needs a read-only releases fetch (CSP-scoped) + in-world update-prompt mesh.
5/5 · Consolemockup
Read-only oversight continuation of the dashboard surface — no admin actions, no live writes.
Mockup only — thin read-only console view; admin actions stay explicitly gated and out of scope.
A thin, read-only click-through mockup of the MVP freedom-tech loop (Gateway to Product to Leaderboard to Update to Console). Every screen is a PROOF/MOCKUP card — no navigation, no live data, no actions, no network. Live promotion of any view is gated behind SEC-1/2/3 and a manual deploy, so this section stays MOCKUP until a view is explicitly promoted. GENERATED at packaging time from the curated view set; LAST-KNOWN when not regenerated.

At a glance

7
Build truth: source version, test/gate status, and the headline progress rings.
Source versionv0.2.349-alpha (build truth; live trails — manual deploy)
Tests
  • 2637 passing / 196 files (profiles: test:fast ~5 curated
  • test:foundation:list ~25 curated
  • test:foundation = vitest --changed origin/main)
Regression check21 / 21 GREEN
Bundle (advisory)~2.9 MB raw / ~1022 KB gzip (rapier chunk >700 KB, expected)
Gates
  • SEC-1 / SEC-2 / SEC-3 intact
  • godMode false
  • torii-quest CSP enforced
Smoke (entry + dashboard)Both cloud smokes consolidated into the Handoff / release control panel at the top of this page — app-entry v0.2.349-alpha PASS 3/3, oversight-dashboard v0.2.349-alpha PASS 4/4. A smoke pass does not imply MVP approval or a completed human playtest.
Active slicev0.2.244 HOST-SAFE CANONICAL ZONE ROUTE (game slice) — fixes the v0.2.243 follow-up: the live rendered screenshot of /zone/plebeian-market-bazaar/ STILL showed the JSON 404 ("No static asset at /zone/plebeian-market-bazaar"). ROOT CAUSE: the published exact-path static host (torii-quest.pplx.app) has NO SPA rewrite and NO directory index and normalises BOTH /zone/<slug> AND /zone/<slug>/ to an exact static-asset lookup → 404, so EVERY /zone/* PATH strategy fails (v0.2.242 extensionless → octet-stream download; v0.2.243 directory-index shell → 404). Only the root / reliably serves index.html as text/html. FIX (no backend): the canonical zone route is now the URL FRAGMENT /#/zone/<slug> — the fragment is never sent to the server, so the request path is always / and the root shell ALWAYS renders on hard refresh; the client parser reads the fragment. zoneRouteFor + handoffRouteFor build /#/zone/<slug>; the portal allowlists are /#/zone/; main._applyZoneRoute reads the URL hash fragment (+ a hashchange listener) and falls back to the path for a LEGACY /zone/<slug> link, which the parser still resolves client-side (NON-CANONICAL: a cold /zone/* deep-link 404s before the bundle loads, so it is never generated/shared). No per-slug static shell is generated any more (the build step + tools/zoneShells.mjs + tools/generate-zone-shells.mjs were removed); the dist ships NO /zone/* file. Preserves the v0.2.240 service-worker fail-soft precache (HTML is network-first; the root / is always the cache key), the v0.2.238 fail-closed loop, and the v0.2.236 NIP-07 login decoupling; root entry flow + ENTER ARENA + ESC pause unchanged. Prior — v0.2.243 zone renderable trailing-slash shell (404d live, superseded); v0.2.242 zone exact-path extensionless shell (downloaded as octet-stream, superseded); v0.2.241 zone hard-refresh shell; v0.2.240 travel-gateway entry repair. HARD CONSTRAINTS held: godMode false; no new timers (loop uses rAF only); no new hot-path Vector3/Matrix4; nostrich comments; Chiefmonkey exact; debug tools ship unconditionally; non-religious ethics guard + useful-job invariant intact; no Nostr writes/signing beyond the existing login/read; no deploy/publish/push (parent handles those).
Contributors SEED · not live1 human · 3 clankers
Docs-derived DERIVED · build-time
  • 0 completed task markers (torii-quest-todo.md)
  • 12 next-12
  • 7 archive clusters
12tasks ahead
3active
4done (24h)
7archive clusters
6tracks
0 / 5milestones
47% estimate
PoC / vision progress
74% tracks
Build progress
0% 0/5
Milestones achieved

Engineering health

8
The efficiency loop in numbers — each card chipped GENERATED or LAST-KNOWN.
Build version GENERATEDv0.2.497-alpha
Test files / profiles GENERATED
  • fast 5
  • foundation 25
  • full —
Total tests LAST-KNOWN2637 passing / 196 files
Profile timings LAST-KNOWN
  • fast ~1s
  • foundation ~6s
  • full suite ~44s
Bundle baseline LAST-KNOWN2.9 MB raw / ~1022 KB gzip (rapier chunk >700 KB, expected)
Parser gaps GENERATED
  • 5
  • curated fallback used
Release gate LAST-KNOWN
  • 21 / 21 regression checks GREEN
  • last green v0.2.497-alpha
Source-of-truth docs GENERATEDdoc/version drift — check the continuity docs
100% last green
Tests passing
100% 21 / 21
Regression checks
0% profiles
Foundation coverage
Engineering health — the efficiency/oversight loop: measure · profile · standardise · automate · modularise · document. GENERATED at build time where deterministic (profile sizes, parser gaps, version, doc-sync); LAST-KNOWN where captured from the most recent green release-gate run (total tests, timings, bundle).

Deployment readiness

NOT READY DEPLOY READINESS · STATIC HOST · READ-ONLY
Static-host posture for the gateway /zone/* travel feature — repo-side prerequisites are checked locally; configuring the host + deploying stay manual.
CheckStateNote
SPA /zone/* fallback documentedgateda required doc is missing the index.html SPA fallback — run npm run zones:check
Built dist route shapedeferredno dist/ this build — run npm run build then npm run zones:check
Host SPA fallback configuredmanualserve index.html for unmatched paths on torii.quest — manual maintainer step, outside this repo
Auto-updatemanualnone — the update-check is read-only and actionable:false; deploys stay a manual maintainer action
Blocking:
  • missing or unreadable doc: VPS_INSTALL.md (must document the /zone/* SPA fallback)
  • missing or unreadable doc: torii-quest-handoff.md (must document the /zone/* SPA fallback)
Static-host deployment readiness for the gateway /zone/* travel feature. The repo-side prerequisites (docs describe the index.html SPA fallback; a built dist/ has index.html with no /zone/* file shadowing it) are verified LOCALLY by npm run zones:check / regression-check [15]. Configuring the real host fallback and deploying stay MANUAL maintainer steps — this surface only INFORMS.

Nostr read-path health

READ-ONLY OK NOSTR READ-PATH · READ-ONLY
Static, local proof that every Nostr path is read-only at the MVP stage and the live-write tier stays consent-gated — derived from the pure read helpers, no relay call.
SignalStateDetail
relay read model presentokread-only adapter exposes read() only; no publish/sign/send/connect/close
no EVENT publish verb in relay read pathokread verbs are [REQ, CLOSE] — no EVENT publish frame
profile read path presentokkind:0 READ→sanitise proven (1 profile); signed:false published:false
leaderboard read path presentokkind-30000 READ→rank proven (1 row); signed:false published:false
write paths disabled / consent gatedok3 read action(s) allowed; 5 write action(s) blocked without explicit consent
SEC-1 / SEC-2 / SEC-3 still future-gatedokSEC-1 signer/publish write path deferred; 3 signed write action(s) gated
Read-only invariants: signed:false · published:false · readOnly:true — 6/6 signals ok.
Nostr surface is read-only at the MVP stage; the live-write path (NIP-07 signer + relay publish, SEC-1) stays consent-gated and deferred.

Track overview

6
Directional per-track completion — momentum, not archaeology.
Foundation / ARS71% · 5 / 7
ARS-4 (FSM fold) + ARS-6 (CODE_INDEX upkeep) open
Combat / Game-feel100% · 30 / 30
1 open edge (travel-time lead on moving targets)
Rapier / Physics100% · 5 / ~5 seams
ARS-3 raycast migration complete
SDK / API86% · 18 / ~21
player boundary lift + BotAgent runtime remain
Nostr / Open-world15% · 0 / 5+
read-paths + consent gate + travel chain + read-path health model proven; relays/signing deferred
Deployment / VPSn/a · —
source clean; live behind (manual deploy)

15-hour proof-of-concept route

5
The active milestone's slices (LEAN-1..5) and what each still needs to ACT.
#SliceStatus
LEAN-1Torii.quest live (publish green source)pending (manual smoke first)
LEAN-2Gateway / NAP-to-NAP travelin-world PORTAL TRIGGER (181) + pure SPA /zone/<slug> ROUTE PARSER (182): proximity arms the injected boundary + prompt (inert), an explicit KeyF interact performs the confirmed same-origin hop, and the resulting /zone/ URL has a safe client-side read (home/zone/invalid → inert HUD notice). The static-host SPA fallback for hard-refresh deep links is now docs-explicit + locally checkable (v0.2.185 zones:check / regression [15]) and pinned end-to-end by the v0.2.197 host-route smoke (unknown /zone/<slug> → index.html, no built file shadows the fallback, slug kept safe); still needs a dedicated portal MESH and the host fallback configured on torii.quest itself
LEAN-3Plebeian/Nostr product panelshells + visible preview; needs in-world mesh + real listing
LEAN-4Leaderboard (Nostr signed events)unsigned helpers + publisher adapter + view + relay-read proof; needs real signer (SEC-1) + relay read
LEAN-5torii.quest GitHub update-checkhelper + view-model + release source/status + static release-metadata template/spec (v0.2.192, npm run release:meta) + local install dry-run checklist (v0.2.193, npm run vps:dry-run) + update-flow smoke harness pinning the read-only/no-auto-update/confirmation-gated contracts (v0.2.196, ToriiDebug.shells.updateFlowSmoke); needs read-only releases fetch + prompt mesh

Now · Next · Later

Active work, the archive of landed clusters, and what shipped in the last day.

NOW · Active 3

  • v0.2.207 — GITHUB MVP RELEASE DRY-RUN (docs/tooling only, no runtime change): a local, read-only dry-run (tools/githubReleaseDryRun.mjs + CLI tools/github-release-dry-run.mjs, npm run release:dry-run) that validates the prerequisites for a FUTURE GitHub MVP-proof release WITHOUT creating one. It folds version stamped + synced, clean working tree, HEAD pushed, release-notes draft present, release-package index present, the tests/RC gate green, a public live URL, and non-actionable (no autoUpdate) release metadata into one READY/NEAR/BLOCKED verdict with the missing list and the suggested FUTURE manual commands (git tag / git push / gh release) as INERT TEXT — each carrying an explicit do-not-run-without-user-approval note — plus the standing manual-approval gate. The CLI reads local files + runs read-only git (rev-parse/status) only and emits text / --json / --markdown, plus an opt-in bounded in-repo --write (default GITHUB_RELEASE_DRY_RUN.md, confined via the shared resolveHandoffWritePath boundary). DRY-RUN ONLY: no git tag, no GitHub release, no push, no announcement, no network, no deploy, no publish. +16 unit tests. NON-GOALS held: read-only except the explicit --write output; no gameplay/physics/shooter/Rapier change; no Nostr signing/publishing/live network write; godMode stays false.
  • v0.2.206 — MVP RELEASE PACKAGE INDEX (docs/tooling only, no runtime change): a single discoverability INDEX for the MVP proof-of-concept candidate (tools/releasePackage.mjs + CLI tools/release-package.mjs, npm run release:package) so humans and future agents can find every relevant file fast. The curated, frozen index points at the release notes draft, playtest checklist + results template, generated + hand-maintained handoff briefs, the progress/todo source-of-truth docs, and the update/VPS/zone-fallback readiness notes — grouped by category — and folds in the current version/commit, the curated test-count, the live URL, the known non-blocking advisories, and the recommended next safe action. The CLI stat-s each indexed file for a present/missing flag and emits text / --json / --markdown, plus an opt-in bounded in-repo --write (default MVP_RELEASE_PACKAGE.md, confined via the shared resolveHandoffWritePath boundary). INDEX ONLY: no GitHub release, no git tag, no announcement, no network, no deploy, no publish. +12 unit tests. NON-GOALS held: read-only except the explicit --write output; no gameplay/physics/shooter/Rapier change; no Nostr signing/publishing/live network write; godMode stays false.
  • ARS-4 — finish folding reload/pointer-lock into the guarded FSM.

LATER · Archive 7

  • v0.2.164–167 — gateway travel chain foundation: relay-read proof → travel confirm/intent → consent UX view-model → dry-run handoff plan (all PURE & INERT).
  • v0.2.159–163 — read-only Nostr foundation: relay-read + leaderboard/profile reads + consent-gate foundation + leaderboard submit intent.
  • v0.2.147–158 — proof-surface pipeline + update-check source/panel: spec layer → cross-check → anchor→transform contract → first in-world mesh pass → promotion/regression gate; GitHub release-check source + update-status panel.
  • v0.2.138–146 — MVP loop made visible + docs symmetry: pivot to the 15-hour PoC route; four inert title-screen preview cards; self-hosting guide + debug index + diff checklist.
  • v0.2.134–137 — lean-MVP foundation: Gateway Protocol draft + travelIntent; product display; leaderboard helpers; registry; view shells; hardening + shellReport.
  • v0.2.120–133 — SDK + components + test harness: Vitest; event bus + FSM slices; ToriiDebug; pure physics/raycast/combat seams; SDK entrypoint + stability tiers; component contract; first reference component; real GAMEOVER edge.
  • v0.2.100–119 — reconciliation & game-feel + decoupling: source reconciled by concern; physics SDK seams; regression batches; CSP + avatar-URL hardening; globals moved onto the event bus / module registries.

DONE · Last 24h 4

  • v0.2.206 — MVP RELEASE PACKAGE INDEX (docs/tooling only, no runtime change): a single discoverability INDEX for the MVP proof-of-concept candidate (tools/releasePackage.mjs + CLI tools/release-package.mjs, npm run release:package) so humans and future agents can find every relevant file fast. The curated, frozen index points at the release notes draft, playtest checklist + results template, handoff briefs, the progress/todo source-of-truth docs, and the update/VPS/zone-fallback readiness notes — grouped by category — and folds in the current version/commit, the curated test-count, the live URL, the known non-blocking advisories, and the recommended next safe action. The CLI stat-s each indexed file for a present/missing flag and emits text / --json / --markdown, plus an opt-in bounded in-repo --write (default MVP_RELEASE_PACKAGE.md, confined via the shared resolveHandoffWritePath boundary). INDEX ONLY: no GitHub release, no git tag, no announcement, no network, no deploy, no publish. +12 unit tests. NON-GOALS held: read-only except the explicit --write output; no gameplay/physics/shooter/Rapier change; no Nostr signing/publishing/live network write; godMode stays false.
  • v0.2.205 — PLAYTEST CHECKLIST DOC WARNING CLEANUP (docs-only, no runtime change): cleared the non-blocking WARN from the v0.2.204 security review where two illustrative v0.2.349-alpha example strings (plus a historical authorship stamp) lingered in tools/playtestChecklist.mjs comments/examples. The LAUNCH-1 expected-result version-label example and the buildPlaytestChecklistModel version-input comment are now version-neutral (a vX.Y.Z-alpha marker) so future security reviews no longer re-flag stale examples, and the file header drops its dated (v0.2.203) authorship stamp. No behavior change and no new test file. NON-GOALS held: docs/comment cleanup only; no gameplay/physics/shooter/Rapier change; no Nostr signing/publishing/live network write; godMode stays false.
  • v0.2.204 — MVP MANUAL PLAYTEST RESULTS INTAKE TEMPLATE (docs/tooling only, no runtime change): a pure/local way to RECORD manual playtest results from the v0.2.203 checklist and feed failures back into todo/progress/handoff without ambiguity (tools/playtestResults.mjs + CLI tools/playtest-results.mjs, npm run playtest:results). The blank results template DERIVES its 17 items / 13 sections from PLAYTEST_CHECKLIST_SECTIONS so it stays in lock-step with the checklist as single source of truth, carrying build/version, commit, live URL, tester, date, environment + overall fields plus per-item PASS/FAIL/N/A, severity, repro notes, screenshot/video refs, and recommended next action. A tolerant pure parser/summary folds a completed results markdown into counts (pass/fail/na/blank/other) + failing ids + an EMPTY/INCOMPLETE/ATTENTION/COMPLETE verdict, tolerating blanks. Emits text / --json / --markdown, plus an opt-in bounded in-repo --write (default MVP_PLAYTEST_RESULTS_TEMPLATE.md, confined via the shared resolveHandoffWritePath boundary) and a read-only --summarize. RESULTS INTAKE ONLY: no browser automation, no network, no deploy/publish. +16 unit tests. NON-GOALS held: read-only except the explicit --write output; no gameplay/physics/shooter/Rapier change; no Nostr signing/publishing/live network write; godMode stays false.
  • v0.2.203 — MVP MANUAL PLAYTEST CHECKLIST (docs/tooling only, no runtime change): a pure/local manual QA acceptance checklist (tools/playtestChecklist.mjs + CLI tools/playtest-checklist.mjs, npm run playtest:checklist) a human — or a future AI handoff — runs by hand against the LIVE build. 17 curated items across 13 areas (launch/title, shooter loop, movement/footsteps, aim + hit-feedback + headshots/body-shots, reload feel, gun/reflection, mirror, crates/physics-nudge, NAP monkey, Continuum dashboard, release-metadata/update-prompt, Nostr read surfaces, gateway portal/travel-confirm shell) — each carrying reproduction steps, an expected result, a severity (blocker/major/minor), an "if it fails" action, and Result/Notes fields to fill in. Emits text / --json / --markdown, plus an opt-in bounded in-repo --write (default MVP_PLAYTEST_CHECKLIST.md, confined via the shared resolveHandoffWritePath boundary). MANUAL CHECKLIST ONLY: no browser automation, no network, no deploy/publish. +15 unit tests. NON-GOALS held: read-only; no gameplay/physics/shooter/Rapier change; no Nostr signing/publishing/live network write; godMode stays false.

Next 12 tasks

12
The ordered queue — top of the list is the next thing to pick up.
  1. 1Drive gatewayActivation (v0.2.178) from a real host router: inject the app/browser window or host transport at the gateway boundary + a same-origin route allowlist wired to CSP, so a confirmed in-world hop performs the live same-origin navigation.
  2. 2Gateway portal mesh — actually move the player in-world on a confirmed hop (front-end trigger for the live-wired activation seam).
  3. 3SEC-2 handoff verification gate — cryptographic checks before acting on live relay travel intents.
  4. 4Real leaderboard signer/publisher + relay read (SEC-1 explicit NIP-07 consent first).
  5. 5In-world product panel mesh over productPanelShell + a real Plebeian.Market listing.
  6. 6SEC-3 product URL validation — URL-object parsing (scheme+host), not regex-only.
  7. 7Read-only GitHub releases fetch (CSP-scoped) + in-world update-prompt mesh.
  8. 8LEAN-1 / TQ-MANUAL-113 — manual smoke on real hardware, then publish source-built artifact.
  9. 9ARS-4 FSM fold close-out.
  10. 10Player boundary full extraction (movement tick, combat, lifecycle, body-state behind the seam).
  11. 11BotAgent runtime migration — wire decideActions, migrate stateful tick/shoot/blowback.
  12. 12Formalise NAP zone registry for the gateway/NAP-to-NAP travel preview.

Risk / blocked / no-blocker

6
What can move freely vs. what is gated, manual, or a tracked open edge.
ItemStateNote
Foundation / docs / tooling slicesno-blockerPure node-safe, no deploy needed — the current cadence.
Gateway-travel chain (read→execute)no-blockerAll PURE & INERT; never navigates/signs/publishes/writes network.
Live relay I/O · signing · world hopgatedSEC-1/2/3 must clear before any wire write or live navigation.
Live deploymentmanualTrails source; needs maintainer smoke + publish (LEAN-1).
Travel-time lead on fast targetsopen-edgeHitscan-aimed but projectile-flown; long shots on strafing bots can trail.
ESBUILD-1 dev-server advisorydeferrednpm audit fix pulls a risky rolldown/vite chain; tracked WARN.