R — the source PRD recommends the smallest sufficient stack, not three compulsory releases. The inventory answers what exists; this decision guide answers what is necessary. Each scope can be the final product.
Decision order
- If simultaneous participation creates the essential value, choose scope-3-play-together.
- Otherwise, if meaningful shared/cross-device records must survive return visits, choose scope-2-keep-what-matters.
- Otherwise start with scope-1-play-now.
A same-browser, non-sensitive preference does not justify a database. S3 does not automatically inherit S2 persistence. Runtime AI is an independent opt-in in all three scopes, not a service automatically inherited with a larger number. Actual platform access requirements still need checking.
| Scope | Minimum required by the recommendation | Add only for an explicit reason | Stop condition |
|---|---|---|---|
| S1 — Play now | Browser UI, local interaction state, repeat/reset | Non-sensitive preferences; runtime AI essential to the outcome | One visitor completes the loop without unnecessary setup |
| S2 — Keep what matters | S1 interaction principles, named durable records, enforceable access policy | Identity for ownership; roles for genuinely different powers; an independent AI branch | An allowed person recovers the correct work and an unauthorized person cannot |
| S3 — Play together | Browser interaction, shared-state rules, access policy, synchronization | Required history, moderation proportional to exposure, independently justified AI | Two visitors complete a safe shared loop through disconnect and rejoin |
Capability admission
Every enabled capability needs a necessity argument and a future observable check. The proof column below is a requirement, not a result.
| Capability | Admission question | Required evidence before shipping an experience |
|---|---|---|
| Local storage | Does remembering this non-sensitive preference help on this browser? | Storage denial does not break the loop; reset and clearing behavior are honest |
| Database | Which exact record must persist, and why is local state insufficient? | Minimal fields; correct refresh/return behavior; enforced read/write/delete rules |
| Identity | Which operation needs ownership or a distinguishable actor? | Trusted identity rather than display-name equality; denied access stays denied after UI/ID tampering |
| Runtime AI | Would deterministic behavior fail the intended outcome? | Current payer and limits understood; malformed/empty/failure responses handled; no duplicate costly calls; input preserved; generated output labeled |
| Multiplayer | Does being together at the same time create the actual value? | Declared authoritative outcomes and conflict resolution; two clients, late join, reconnect, and duplicate input exercised |
| Moderation | Can a participant harm someone or publish unwanted content? | Proportionate restriction/removal path, explicit operator powers, and understood destructive bans |
| Extra roles, a feed, or group build | Is there a distinct approved user task? | That task and its permissions work; otherwise leave the capability out |
Managed capabilities are preferable to invented replacements only when they meet the needed contract. If a critical trust or recovery guarantee cannot be established, narrow the outcome or use another platform; hiding a button does not make the scope safe.
Product promise and non-goals
The source package promises a decision aid: a reader should identify the default, explain why a capability is admitted or excluded, find its acceptance case, and distinguish documented availability from untested implementation. Success for a future experience is a visitor completing the named loop and receiving truthful state, not a high feature count or volume of AI output.
The PRD excludes app implementation, subscription purchase, provider connection, production/security certification, Funday deployment, mandatory React/Svelte/daisyUI, a bespoke backend, feeds, growth mechanics, streaks, billing, competitive-score trust, telemetry infrastructure, and an exhaustive proprietary technology inventory.
Its brainstorm explicitly declines an interactive scope wizard, a separate responsive explainer product, generated SDK reference, analytics dashboard, animation/video, full design system, downloadable backend, custom authentication, and another technology survey unless a named task cannot be served by the images and text. Preserving that historical boundary does not turn this foundation wiki into one of those applications.
What these pages do not decide
No project-specific audience, game, record schema, server, SDK signature, database engine, transport guarantee, or capacity figure is supplied. The workflow > Scope before implementation inputs would be needed for an actual experience; they are not evidence that implementation has started.
For state placement see state-and-trust. For observable behavior see experience-and-acceptance. For the prior poster rationale and source-reported review limits see evidence-and-limits.
Source basis: PRD.md sections 1, 3, 4, and 8; scoped-posters.json global rules and three decision records. The three scope pages provide the images’ text equivalents and declared edge semantics.
Apply the same discipline to an independent stack
The September 10 corpus changes the available recommendations, not the principle. First choose the product lane on index > First distinguish the product, then the needed state/shared scope, then an engine only if the interaction earns it. An independent S1 can remain HTML or a small Svelte app; a graph editor need not become an execution platform; a 3D scene need not acquire physics, accounts, or multiplayer.
Its dependency admission question is: which current user action becomes substantially easier, safer, or more reliable because this package exists? Future flexibility alone is insufficient, but reinventing an accessible combobox, database wrapper, or physics engine solely to reduce package count is not the goal. Optimize total maintenance.
The source recommends beginning its conceptual collection with one base and one working 3D example, adding templates only after a real project yields something worth copying. That is source advice, not a selected Simp approach. A representative interaction, owned state/reset, applicable loading/error behavior, an explicit deployment choice, and an exercised smoke scenario would be required of a real starter. No installed starter collection is supplied.