[Page] Fix: Align prototype frontend with spx-gui

.gitignore

@@ -18,5 +18,10 @@
 # Go workspace file
 go.work
 
+# Agent workflow artifacts
+docs/superpowers/
+*/docs/superpowers/
+.playwright-mcp/
+
 .idea/
 *.wasm

ui/README.md

@@ -48,7 +48,7 @@ The same requirement should use one issue to connect the Design PR and Code PR.
 
 `ui/prototype` is a runnable product prototype, not an isolated demo.
 
-It is used during Design PR to express product behavior, page structure, visual design, and basic interactions. See [Prototype Maintenance](skills/prototype-maintenance/SKILL.md) for detailed maintenance rules.
+It is used during Design PR to express product behavior, page structure, visual design, and basic interactions. See [`prototype/AGENTS.md`](prototype/AGENTS.md) for detailed maintenance rules.
 
 ## Quick Start
 
@@ -79,12 +79,6 @@ It is used during Design PR to express product behavior, page structure, visual
 | [Design to Code Mapping (Legacy)](docs/design-to-code-mapping-legacy.md) | Legacy `.pen` to `spx-gui` mapping rules |
 | [Component Docs Naming](docs/component-docs-naming.md) | Component documentation naming conventions |
 
-## Skills
-
-| Skill | Description |
-| ----- | ----------- |
-| [Prototype Maintenance](skills/prototype-maintenance/SKILL.md) | Use when maintaining `ui/prototype` and keeping it aligned with the real frontend structure, routes, and interactions |
-
 ## Tests and Validation
 
 `ui/tests/pen/` contains design asset validation tests for protecting the component library and page-level Pencil files. See [Design Asset Validation](docs/design-asset-validation.md) for details.

ui/README.zh.md

@@ -48,7 +48,7 @@ PR（Code 发布）
 
 `ui/prototype` 是可运行的功能原型，不是孤立 demo。
 
-它用于在 Design PR 阶段表达产品功能、页面结构、设计样式和基础交互。具体维护规则见 [Prototype Maintenance](skills/prototype-maintenance/SKILL.md)。
+它用于在 Design PR 阶段表达产品功能、页面结构、设计样式和基础交互。具体维护规则见 [`prototype/AGENTS.md`](prototype/AGENTS.md)。
 
 ## 快速开始
 
@@ -79,12 +79,6 @@ PR（Code 发布）
 | [设计到代码映射（旧版）](docs/design-to-code-mapping-legacy.md) | 旧版 `.pen` 到 `spx-gui` 的映射规则，历史参考 |
 | [组件文档命名](docs/component-docs-naming.md) | 组件文档命名约定 |
 
-## Skills
-
-| Skill | 说明 |
-| ----- | ---- |
-| [Prototype Maintenance](skills/prototype-maintenance/SKILL.md) | 维护 `ui/prototype` 时使用，确保 prototype 与真实前端结构、路由和交互保持一致 |
-
 ## 测试与校验
 
 `ui/tests/pen/` 存放设计资产校验测试，用于保护组件库和页面级 Pencil 文件。详细说明见 [设计资产校验](docs/design-asset-validation.md)。

ui/docs/design-to-code-mapping-legacy.md

@@ -1,7 +1,7 @@
 # Design to Code Mapping Guide (Legacy)
 
 > 本文是旧版 `.pen` 到 `spx-gui` 的映射与规范化文档，主要服务旧版设计同步流程。
-> 当前 prototype 维护规则请优先查看 [`ui/skills/prototype-maintenance/SKILL.md`](../skills/prototype-maintenance/SKILL.md)。
+> 当前 prototype 维护规则请优先查看 [`ui/prototype/AGENTS.md`](../prototype/AGENTS.md)。
 
 本文记录整个仓库里 `.pen` 设计资产与 `spx-gui` 前端实现之间的对应关系，供后续开发者同步设计稿到代码时使用。
 

ui/docs/team-workflow.md

@@ -108,11 +108,11 @@ Code PR 不应只从静态设计稿重新推导实现方案，而应把 Design P
 
 ## Prototype 维护
 
-Prototype 的维护规则已经单独整理为 skill：
+Prototype 的维护规则已经合并到原型目录：
 
-- [`ui/skills/prototype-maintenance/SKILL.md`](../skills/prototype-maintenance/SKILL.md)
+- [`ui/prototype/AGENTS.md`](../prototype/AGENTS.md)
 
-当任务涉及 `ui/prototype`、Pencil 页面改动同步、prototype 预览环境或 prototype 与真实前端代码对齐时，应优先使用该 skill。
+当任务涉及 `ui/prototype`、Pencil 页面改动同步、prototype 预览环境或 prototype 与真实前端代码对齐时，应优先遵循该文件。
 
 ## 责任边界
 
@@ -142,5 +142,5 @@ Code PR 不应绕开 issue 和 Design PR 单独解释需求。
 
 - Issue 编写规则：[Issue 模板](./issue-template.md)
 - Design PR 编写规则：[PR 模板](./pr-template.md)
-- Prototype 维护规则：[`ui/skills/prototype-maintenance/SKILL.md`](../skills/prototype-maintenance/SKILL.md)
+- Prototype 维护规则：[`ui/prototype/AGENTS.md`](../prototype/AGENTS.md)
 - 旧版协作流程：[团队工作流程（旧版）](./team-workflow-legacy.md)

ui/prototype/AGENTS.md

@@ -4,31 +4,60 @@ This file guides AI agents working under `ui/prototype/`.
 
 ## Purpose
 
-`ui/prototype/` is a standalone, design-driven UI preview workspace, usually generated from `.pen` files in `ui/pages/` and assets in `ui/images/`.
+`ui/prototype/` is a standalone, runnable XBuilder frontend prototype. It exists for Design PR work: product behavior, page structure, visual design, and basic interactions should be experienced here before production logic is implemented in `spx-gui/`.
 
-It should stay close to the real frontend in stack and presentation style, but it is not the real frontend.
+The prototype must look and behave like the current Builder frontend, but it must be disconnected from the server. Data shown in the prototype is local fake data.
 
 ## Core Contract
 
-- `spx-gui/` is the real product frontend.
-- `ui/prototype/` is a local preview sandbox.
-- The prototype should resemble the real frontend in structure, theme shape, typography, and implementation style.
-- The prototype must not depend on the real frontend at runtime, build time, or type-check time.
+- `spx-gui/` is the real product frontend and the reference implementation.
+- `ui/prototype/` is an independent frontend app with its own install, dev, build, and preview flow.
+- Prototype code must follow the real frontend's stack and organization where practical: Vite, Vue 3, Vue Router, Tailwind CSS v4, page/component/API-style boundaries, local theme tokens, and local app styles.
+- Runtime, build, and typecheck must not depend on `spx-gui/`.
+- The prototype must not call real backend services.
 
 Stable rule:
 
-- You may copy or adapt presentation-layer patterns from the real frontend.
-- You must not import code, config, styles, fonts, routes, tokens, utilities, or components directly from `spx-gui/`.
+- Inspect the current real frontend implementation before changing the corresponding prototype surface.
+- Recreate the needed structure locally under `ui/prototype/`.
+- Use local mock APIs and fake data instead of real network calls.
+- Do not import code, config, styles, fonts, routes, tokens, utilities, or components directly from `spx-gui/`.
 
-If something is needed from the real frontend, copy the minimum local version into `ui/prototype/` and remove production-only concerns.
+If something is needed from the real frontend, copy or adapt the minimum local presentation-layer subset into `ui/prototype/` and remove production-only concerns.
 
 ## Source Priority
 
 When changing the prototype, use this order:
 
-1. Design files and design assets decide what should be rendered.
-2. Existing prototype files decide local conventions.
-3. The real frontend is only a reference for structure, theme, naming, and visual implementation patterns.
+1. The changed Pencil design file or design asset decides the intended UI.
+2. The current real frontend decides the page structure, route shape, component boundaries, styling approach, and interaction model.
+3. Existing prototype files decide local conventions.
+
+Do not invent an unrelated demo architecture when a matching real frontend surface exists.
+
+## Required Workflow
+
+1. Start from the real frontend.
+   - Inspect the corresponding implementation in the current Builder frontend before editing prototype code.
+   - Reuse the same route model, page/component split, style approach, and interaction logic where practical.
+
+2. Ensure the target prototype surface exists.
+   - If `ui/prototype` does not have the changed page or UI, initialize it from the current real frontend structure.
+   - If it exists but has drifted from the real frontend organization, align the structure first, then apply the design change.
+
+3. Apply only the current design change.
+   - Sync the latest relevant Pencil page change into `ui/prototype`.
+   - If only one page changed, only override that page or component surface.
+   - Other pages, routes, and features must remain accessible and usable through local mock behavior.
+
+4. Keep the prototype offline.
+   - Replace server APIs with local `src/apis/*` mock modules.
+   - Replace auth, persistence, permission, and backend state with deterministic local state.
+   - Keep interactions local and preview-oriented.
+
+5. Keep edits scoped.
+   - Write prototype-related changes under `ui/` unless the user explicitly authorizes broader scope.
+   - Do not modify `spx-gui/` by default.
 
 ## Boundaries
 
@@ -38,83 +67,74 @@ Agents must preserve all of the following:
 - Runtime and build dependencies stay inside `ui/prototype/`, except shared static assets under `ui/images/`.
 - Do not import from `../../spx-gui` or any other real frontend directory.
 - Do not extend, merge, or proxy real frontend config.
-- Do not add business logic, network requests, auth flow, persistence, or real app state.
-- Keep interactions local, minimal, and preview-oriented.
+- Do not add real network requests, real auth flow, real persistence, or real app state.
 - Keep mock data local.
 
 Forbidden shortcuts include:
 
 - importing the real frontend's Vite config, router, token files, or components
 - reading fonts from the real frontend instead of copying them locally
 - using aliases that resolve into the real frontend project
+- adding `fetch`, `axios`, or backend client calls for prototype data
+- replacing the app with a single isolated static demo page
 
 ## Alignment And Simplification
 
 Keep these areas aligned with the real frontend when practical:
 
 - Vite + Vue 3 + Vue Router + Tailwind CSS v4
-- page/component/data/style directory split
+- route names and URL shape for community, search, tutorials, project, and editor surfaces
+- page/component/API-style directory split
 - semantic token naming and UI-facing class style
 - typography, spacing, radius, shadow, and color conventions
 - `src/styles/app.css`, especially the `@theme inline` bridge and base presentation rules
 
 At the same time, keep the prototype simpler than the real frontend:
 
 - replace business state with static data or minimal local state
-- replace real flows with a small local router
-- replace product actions with no-op handlers or local feedback
+- replace real APIs with local functions returning mock data
+- replace product actions with local feedback
+- replace game/project runtime surfaces with static placeholder previews; do not copy SPX engine assets or parse XBP files
+- do not recreate `/docs/*` pages or `src/widgets/*` entry surfaces because they are not end-user prototype UI
 - omit infrastructure and edge-case handling unless it changes the visual result
 
 ## Editing Rules
 
 When iterating on the prototype:
 
 1. Start from the design artifact that changed.
-2. Reuse existing prototype components before adding abstractions.
-3. Prefer pure presentational Vue components.
-4. Prefer Tailwind utility classes.
-5. Keep `src/styles/app.css` structurally aligned with the real frontend's `app.css`.
-6. If new token families are needed, add local `--ui-*` variables first, then expose them through local `@theme inline` mapping.
-7. If copying from the real frontend, copy the minimum presentational subset and strip production logic.
-
-## Long-Term Stability
-
-These rules are more important than reducing duplication:
-
-- Never reintroduce a direct dependency on the real frontend.
-- Prefer local copies over shared imports for theme, style, asset, and config surfaces.
-- Keep the prototype's public shape similar to the real frontend so later migration stays easy.
-- Keep the prototype's implementation simpler so preview work stays cheap.
-- If the prototype deliberately diverges from the real frontend, document that near the affected file or in `README.md`.
-
-Sync direction:
-
-1. Copy semantic token names and theme structure.
-2. Copy base presentation rules.
-3. Copy static assets locally when needed.
-4. Recreate markup and styling locally.
-5. Drop production-only logic.
-
-Do not treat prototype code as the source of truth for production code.
+2. Inspect the matching real frontend files.
+3. Reuse existing prototype components before adding abstractions.
+4. Prefer pure presentational Vue components.
+5. Prefer Tailwind utility classes.
+6. Keep `src/styles/app.css` structurally aligned with the real frontend's `app.css`.
+7. If new token families are needed, add local `--ui-*` variables first, then expose them through local `@theme inline` mapping.
+8. If copying from the real frontend, copy the minimum presentational subset and strip production logic.
 
 ## Validation
 
-After substantive changes:
+After substantive changes, run from `ui/prototype/`:
 
-- run `npm run build` inside `ui/prototype/`
+```bash
+npm run test:prototype
+npm run build
+```
 
-When UI structure or styling changes, also do the following when possible:
+When UI structure or styling changes, also:
 
 - run the dev server from `ui/prototype/`
 - open the preview in a browser
 - verify the main route renders
-- verify any local preview interaction still works
+- verify changed pages are accessible
+- verify important unchanged pages still load
+- verify navigation, search, course-card navigation, project pages, and editor preview flows when relevant
 
 Before finishing, confirm:
 
 - no import points into `spx-gui/`
 - no config references the real frontend
-- the prototype still behaves as a standalone app
+- no real backend calls exist
+- the prototype still behaves as a standalone offline app
 
 ## Keep This File Updated
 
@@ -125,6 +145,7 @@ Update this file when any of the following changes:
 - the allowed relationship with the real frontend
 - the validation flow
 - the local prototype architecture
+- the mock API/data strategy
 - the sync strategy for theme, asset, or config surfaces
 
-If a change creates pressure to depend on the real frontend directly, document the local alternative here instead.
+If a change creates pressure to depend on the real frontend directly, document the local alternative here instead.

ui/prototype/README.md

@@ -1,8 +1,8 @@
 # XBuilder Prototype Preview
 
-这是一个独立的 UI 原型工程，用来预览 `ui/pages/spx/tutorial.pen` 对应的设计实现。
+这是一个独立的 XBuilder 前端原型工程，用来在 Design PR 阶段预览页面结构、视觉样式和基础交互。
 它保持与真实前端相近的组织方式和技术栈：基于 Vite、Vue 3、Vue Router、Tailwind CSS v4，按页面、
-组件、数据和样式拆分；主题 token、基础排版和字体资源尽量与真实前端保持一致，但不包含业务逻辑，也不直接依赖真实前端项目。
+组件、mock API、数据和样式拆分；主题 token、基础排版和字体资源尽量与真实前端保持一致，但不直接依赖真实前端项目，也不调用服务端。
 
 ## Run
 
@@ -19,14 +19,24 @@ http://127.0.0.1:5174/
 
 ## Scope
 
-- `/` 重定向到 `/tutorials`
-- `/tutorials` 使用 prototype 页面，并直接引用 `ui/images` 中的设计资源
+- `/`、`/explore`、`/search`、`/user/:nameInput` 以及 `/user/:nameInput/projects|likes|followers|following` 复刻社区和用户主页结构
+- `/project/:ownerInput/:nameInput` 复刻项目详情、运行预览、owner、说明、remix、release history 和相关项目区域
+- `/tutorials`、`/course-series/:courseSeriesIdInput`、`/course/:courseSeriesIdInput/:courseIdInput/start` 复刻教程主流程
+- `/editor/:ownerNameInput/:projectNameInput/:inEditorPath*` 提供离线编辑器预览，并包含 sprite editor 局部 prototype surface
+- `/sign-in/callback`、`/sign-in/token` 提供本地模拟登录页面，不触发真实鉴权
 - 样式通过 Tailwind v4 utility class 实现，并在 `src/styles/app.css` 中维护与真实前端接近的 `@theme inline` token 映射
-- 本地 mock 教程数据与卡片点击反馈
-- 导航、banner、列表和页脚都保留为纯展示层实现
+- 数据由 `src/apis/*` 和 `src/data/mock.ts` 提供，全部为本地假数据；导航、搜索、课程卡片跳转、项目页、编辑器局部交互均为本地状态
 
 ## Constraints
 
 - 这个目录应始终可单独安装、单独启动、单独构建
 - 可以复用 `ui/images` 这类设计资源，但不要直接 import 真实前端项目中的代码或配置
-- 如需模拟交互，只保留用于预览 UI 的最小本地状态
+- 不要加入真实 `fetch`、`axios`、鉴权、持久化、OpenAPI 服务加载或服务端状态
+- 不复刻 `/docs/*` 页面、`src/widgets/*` entry surface、SPX engine runtime 或 XBP 解析逻辑；项目运行区域使用静态占位预览
+
+## Validate
+
+```bash
+npm run test:prototype
+npm run build
+```

ui/prototype/package.json

@@ -6,7 +6,8 @@
   "scripts": {
     "dev": "vite",
     "build": "vue-tsc --noEmit && vite build",
-    "preview": "vite preview"
+    "preview": "vite preview",
+    "test:prototype": "node scripts/check-prototype.mjs"
   },
   "dependencies": {
     "@tailwindcss/vite": "4.2.2",