Outcome Checklist

Last reviewed: 2026-03-10

Purpose

• Product requirements live in Vision.
• High-level delivery tracking lives in Execution Tracker.
• This page is the outcome-by-outcome checklist used to close the gap from a demoable prototype to full V1 outcome coverage.

Rule For Marking An Outcome Complete

• Mark an item [x] only when the current checkout fully matches the requirement as written in Vision.
• Mark an item [x] only when its listed validation gates are passing.
• Mark an item [x] only when there is no known blocker that would break the user-facing outcome in normal use.

Current Snapshot

• Short-term outcomes at full-spec coverage: 5 / 13
• Short-term outcomes still partial: 8 / 13
• App quality gate blocker: resolved (npm --prefix packages/app run build is now passing)
• Automated validation on 2026-03-10:
  • npm --prefix packages/app run lint passed
  • npm --prefix packages/app run test passed
  • npm --prefix packages/app run tsc passed
  • npm --prefix packages/app run build passed (includes PWA generateSW)
  • npm --prefix packages/app run test:e2e passed with 8 passed / 2 skipped
  • npm --prefix packages/contracts test passed with 1 stub contract test
  • npm --prefix packages/app run test:coverage passed with 33.10% statement coverage
  • Offline smoke validation passed against preview build (serviceWorker.ready=true, offline reload renders login shell)

V1 Proof Loop

• Onboarding -> add plant -> record care -> earn energy -> nurture/evolve creature -> play a game Current state: Demoable and exercised by packages/app/e2e/core-loop.spec.cjs. Needed for 100%:
  • remove remaining skipped realtime E2E cases
  • confirm the loop works in both same-device and true two-device play without manual caveats Validation gate:
  • npm --prefix packages/app run build
  • npm --prefix packages/app run test:e2e with zero skips

Short-Term Outcomes

• 1. Player can login with either passkey or Ethereum wallet Current state: Partial. Passkey is real WebAuthn and Pimlico-aware. Wallet login exists, but wallet restore only succeeds when the wallet is still connected and the automated suite does not prove the full wallet success path. Needed for 100%:

  • make wallet return-after-refresh behavior satisfy the definition of done
  • add automated wallet login coverage, not just passkey coverage
  • decide whether offline return is required for wallet mode or only for local profile access after prior auth Validation gate:
  • wallet login and restore covered in E2E
  • no webdriver-only auth fallback required for the default suite Evidence:
  • packages/app/src/views/Login.tsx
  • packages/app/src/providers/AuthProvider.tsx
  • packages/app/src/modules/auth/passkey.ts

• 2. Player can onboard after first login and select their element, location details, and user info Current state: Partial. Element, biome, location label, optional geolocation, and resume-friendly XState flow are present. Separate user info beyond the login name is not collected, and geolocation is not used downstream. Needed for 100%:

  • define the minimum user info fields required by v1 and add them explicitly
  • either use geolocation in creature/environment logic or narrow the requirement
  • keep the onboarding resume behavior intact Validation gate:
  • onboarding state-machine tests remain green
  • E2E covers interruption + resume Evidence:
  • packages/app/src/views/Onboard.tsx
  • packages/app/src/machines/onboardingMachine.ts

• 3. Player can generate creature based on selected element and local environment Current state: Partial. Creature generation is implemented, but the generator currently varies by element only; biome is stored on the creature but does not meaningfully change output. Needed for 100%:

  • make biome/environment influence generation output in a visible way
  • document which inputs are real in v1 and which remain stubs
  • add tests that prove environment changes the output Validation gate:
  • generator tests cover element + biome variation
  • onboarding E2E verifies environment-driven output differences or labeled fallback behavior Evidence:
  • packages/app/src/views/Onboard.tsx
  • packages/app/src/modules/creature-generator/seed-pack.ts

• 4. Player can nurture creature with resources earned from plant care Current state: Implemented. Plant care awards energy, nurture spends energy to raise XP and stats, and gameplay reads creature state for initiative and reward bonuses. Keep watching:

  • maintain gameplay stat integration as rules change Validation gate:
  • machine and gameplay tests stay green Evidence:
  • packages/app/src/hooks/plants/usePlantCare.ts
  • packages/app/src/hooks/creatures/useNurture.ts
  • packages/app/src/machines/gameSessionMachine.ts

• 5. Players can evolve creature once they have enough XP and unlock new capabilities and more developed visuals Current state: Partial. Explicit evolution works and changes stage/stats, but it does not currently change signature move text or evolve the visual asset in a clear v1-complete way. Needed for 100%:

  • update signature move on evolve
  • update the creature visual or frame in a way the player can clearly see
  • add regression tests for evolved move/visual metadata Validation gate:
  • evolution tests cover metadata changes
  • UI test verifies the updated stage and evolved presentation Evidence:
  • packages/app/src/hooks/creatures/useEvolve.ts
  • packages/app/src/views/Deck.tsx

• 6. Player can select a plant in their local environment to care for and add it to inventory with details and initial health Current state: Implemented with stubbed health/species logic. Photo, nickname, biome, location tag, notes, first photo timestamp, and health score are stored locally. Keep watching:

  • if species verification becomes mandatory for v1, wire the verifier into the add flow Validation gate:
  • add-plant flow remains covered in E2E Evidence:
  • packages/app/src/views/Deck.tsx
  • packages/app/src/hooks/plants/useAddPlant.ts

• 7. Player can nurture plants with daily photos to earn resources for their creature Current state: Implemented. Daily photo is required, checklist actions are recorded, streak decay is soft, energy is granted, and care events are queued locally for later reporting/proof work. Keep watching:

  • maintain queueing behavior for offline-first care submission Validation gate:
  • plant care machine tests stay green
  • core loop E2E keeps the daily photo requirement Evidence:
  • packages/app/src/views/Deck.tsx
  • packages/app/src/hooks/plants/usePlantCare.ts
  • packages/app/src/modules/job-queue/handlers.ts

• 8. Player can start a game in the play tab in AR, choose Tic-Tac-Toe, Ludo, or Mancala, and play with a local peer using creatures as game assets Current state: Partial. Garden is the play hub, all three games are present, AR rendering exists, and device/local/world modes exist. Realtime setup sync now includes seat ownership, creature selection profiles, and match start signaling, but two-device realtime reliability remains environment-sensitive in automation. Needed for 100%:

  • remove environment-dependent realtime skips by stabilizing transport for two-context automation
  • prove AR works on supported devices beyond capability detection
  • add deterministic two-device coverage for Local and World paths Validation gate:
  • zero-skipped realtime E2E
  • AR smoke validation on supported hardware Evidence:
  • packages/app/src/views/Garden.tsx
  • packages/app/src/components/game/GameCanvas.tsx
  • packages/app/src/modules/yjs.ts

• 9. Player can join game started by another player and select the creature to use Current state: Partial. Join codes, seat ownership, and per-player creature selection sync are implemented; each peer now selects only their own seat creature in network modes, and setup readiness is enforced before start. Remaining gap is deterministic two-context proof in environments where realtime transport is unavailable. Needed for 100%:

  • keep the seat-owned selection flow green in two-context E2E without skip conditions Validation gate:
  • separate-browser-context E2E proves host and guest each choose their own creature Evidence:
  • packages/app/src/views/Garden.tsx
  • packages/app/src/hooks/games/useGameSession.ts
  • packages/app/src/modules/yjs.ts

• 10. Player in an active game can make a game move when it is their turn Current state: Implemented. Turn enforcement and move validation are handled in the state machine and pure game rules. Keep watching:

  • preserve parity across Tic-Tac-Toe, Ludo, and Mancala Validation gate:
  • rules and session tests remain green Evidence:
  • packages/app/src/machines/gameSessionMachine.ts
  • packages/app/src/modules/games/*.test.ts

• 11. Player who completes game can claim their game reward based on the result Current state: Partial. Reward attribution is now seat-aware (p0/p1) and persisted with multiplayer context; local energy/badge updates and event payloads now use the local player’s actual seat result. Remaining gap is deterministic two-context E2E proof in runs where realtime transport is available. Needed for 100%:

  • keep multiplayer reward attribution assertions green in non-skipped two-context E2E Validation gate:
  • separate-context E2E confirms correct host and guest reward attribution Evidence:
  • packages/app/src/views/Garden.tsx

• 12. Player can publish and remix UGC with clear ownership metadata Current state: Implemented as a local-first foundation. Publish/remix/flag/canonize flows exist in the Profile view, and items receive content hashes, lineage, moderation state, and proof references. Keep watching:

  • clarify whether simulated AT publishing is acceptable for v1 or must be made real Validation gate:
  • UGC service tests remain green Evidence:
  • packages/app/src/views/Profile.tsx
  • packages/app/src/modules/ugc/service.ts

• 13. Community can promote UGC into canonized world content through transparent proof-based rules Current state: Partial. Local canonization and reproducibility checks exist, but onchain verification is read-only and depends on an external registry already being configured and populated. Needed for 100%:

  • define whether v1 requires write-path integration or only reproducible verification
  • if write-path is required, add registry publish/update support
  • add tests that cover configured onchain registry behavior Validation gate:
  • canon reproducibility passes with configured registry
  • integration test covers registry-backed verification Evidence:
  • packages/app/src/views/Profile.tsx
  • packages/app/src/modules/autonomous-world/registry.ts
  • packages/app/src/modules/autonomous-world/onchain.ts

Output Coverage

• Fully functional and usable PWA able to be deployed Current state: Implemented for v1 deployability. Build is green, service worker generation succeeds, and offline smoke was validated by loading preview, waiting for serviceWorker.ready, forcing offline mode, and reloading successfully. Keep watching:

  • reduce large bundle chunks to improve install/update performance Validation gate:
  • npm --prefix packages/app run build
  • offline smoke validation

• Semi-integrated with Green Goods protocol for reporting plant care Current state: Partial. A report interface and local queue are present, but it falls back to a stub when config is absent and there is no direct test coverage. Needed for 100%:

  • decide whether a stubbed interface is sufficient for v1
  • if not, add live endpoint integration and tests Validation gate:
  • direct tests for report success and failure paths Evidence:
  • packages/app/src/modules/green-goods/reporting.ts

• README documentation outlining core aspects Current state: Present in root and app README files. Keep watching:

  • keep docs aligned when behavior changes Evidence:
  • README.md
  • packages/app/README.md

• UGC and autonomous world framework documented Current state: Partial. The structure is documented, but story/canon content in the app code is still explicitly marked TODO. Needed for 100%:

  • finish the v1 canon/story content and onboarding copy
  • ensure youth-safety/moderation/promotion rules are fully documented in one place Validation gate:
  • docs and app copy match the intended v1 canon Evidence:
  • Protocol Stack
  • packages/app/src/data/story.ts

Path To 100% Outcome Coverage

• 1. Restore the green deployment path Steps:

  • fixed npm --prefix packages/app run build (type errors + PWA runtime/deploy config)
  • reran lint, tests, typecheck, coverage, E2E, contracts, and build
  • added and executed an explicit offline smoke validation pass

• 2. Close the multiplayer correctness gaps Steps:

  • [done] synchronize host/guest setup state, including creature ownership and readiness
  • [done] fix reward attribution for true two-device play
  • [remaining] replace skipped realtime coverage with deterministic passing coverage

• 3. Finish the “real vs stubbed” decisions for identity and proofs Steps:

  • decide whether AT Protocol remains a local v1 stub or becomes a real provider flow
  • decide whether EAS remains offchain for v1 or must reach live registry/timestamping
  • decide whether Green Goods stub reporting satisfies the outcome or must hit a real endpoint

• 4. Complete the creature growth spec Steps:

  • make environment affect creature generation in a visible way
  • make evolution update signature move and visual presentation
  • add regression tests for both behaviors

• 5. Complete the story/canon layer Steps:

  • replace placeholder story content in packages/app/src/data/story.ts
  • align onboarding copy, lore, and creature metadata with the v1 narrative
  • verify the story constraints in Vision are actually represented in the app

• 6. Strengthen validation to match the claims Steps:

  • raise statement coverage in the highest-risk runtime code: views, hooks, auth, sync, AR, Green Goods
  • add offline/PWA runtime verification
  • add AR smoke validation on supported hardware
  • expand contract coverage beyond the current stub test

Immediate Next Actions

• Remove realtime transport-dependent E2E skips for two-context multiplayer
• Convert two-context multiplayer reward assertions from conditional-skip to always-on
• Decide the required v1 bar for AT Protocol, EAS, and Green Goods integrations
• Replace placeholder story/canon content
• Validate AR gameplay path on supported hardware and capture smoke evidence