feat(demo): 从登录页进入全站只读演示账户

[tiankaima]

目标

在登录页提供“进入演示”入口。演示账户进入后像普通已登录用户一样浏览现有页面，看到一套相互一致的 demo 数据；所有普通用户业务操作均为只读。演示模式不另建独立工作台。

范围

覆盖普通用户能看到的功能，包括工作台、目录、课程与作业、待办、订阅、社区及账户资料。管理员、OAuth 授权、上传和对外订阅等有外部副作用的入口不在演示范围，演示身份下应隐藏或禁用。

验收

• 登录入口、导航和账户状态清楚标明“演示 / 只读”。
• 演示身份不能伪装成真实用户，也不能读取真实用户的私有数据。
• demo 数据在页面及其使用的 API 中一致，能浏览普通用户功能的主要状态。
• 演示身份的写入请求在服务端被拒绝；界面同步禁用相关操作并说明原因。
• 正常登录用户的功能与权限保持不变。

交付顺序

先打通登录页入口、一个完整的普通用户浏览路径和服务端只读边界；每完成一组页面，就补齐相应 demo 数据及端到端验证。

[tiankaima]

2026-07-22 complete demo boundary (draft-only, production disabled)

The requested web login and API authorization can coexist with the original non-persistent requirement if demo identity is a separate authentication realm, not a Better Auth database user.

Identity and entry

• /demo is a real, explicit sign-in page available only when DEMO_MODE_ENABLED=true; the default and production configuration remain false and expose no navigation/login entry.
• Successful bootstrap mints a server-signed, short-lived demo session cookie. It contains an opaque session ID, issued/expiry times and kind=demo, never a real userId.
• API clients exchange that active demo session for a short-lived bearer token with a distinct audience/token kind and a strict demo scope allowlist. It must never be accepted as an OAuth/Better Auth access token. GraphQL and MCP use the same principal/scope representation after verification.

Data model

• No User, Session, Account, enrollment, todo, OAuth grant/token or other business row is created. Reads come from versioned deterministic fixtures.
• Optional temporary interaction state is a signed-cookie overlay with a small size/action cap in the first slice; if multi-device/state volume is later required, move only that ephemeral overlay to TTL KV. Do not use PostgreSQL business tables.
• The fixture version is embedded in the demo token/session so deployments can invalidate old state deterministically.

Mutation contract

• A central command gate runs after authentication/scope checks and before Prisma, R2, OAuth, webhooks or external adapters.
• Only explicitly allowlisted demo commands are simulated. Responses always include machine-readable simulated: true; REST uses a response field/header, GraphQL uses payload metadata/extensions, and MCP structured content carries the same marker.
• Non-allowlisted actions fail closed with a stable demo_operation_forbidden error. V1 excludes admin, user/OAuth management, uploads, public collaborative writes, account operations, calendar feed tokens and webhooks.
• “Immutable” means zero durable business/external effects, not silently returning normal success.

Audit and abuse controls

• The only durable effect is a privacy-safe audit event: allowlisted operation, result, request ID, timestamp, fixture version and keyed hash of the demo session. No request body, token, cookie, email, IP or fixture content.
• Add bootstrap/token rate limits, short TTL, audience separation, key rotation, per-session action caps and a global kill switch.

Draft PR acceptance

The first draft vertical slice should cover /demo, cookie principal, one fixture-backed read, one simulated Todo mutation, one demo API token, and negative tests proving zero Prisma/R2/OAuth/external calls. It stays draft and disabled in every checked-in production environment until the threat model and UX are accepted.

[tiankaima]

Alignment: keep scoped to draft PR #595. Recommend ephemeral session-only demo principal with read-only catalog access, no persistence, explicit env gate — document matrix before implementation.