.gitmodules

@@ -1,6 +0,0 @@
-[submodule "sources/sysmgr-nest"]
-	path = sources/sysmgr-nest
-	url = ssh://git@git.dianyunshouhu.com:2222/touyun_liuyun/sysmgr-nest.git
-[submodule "sources/sysmgr-admin"]
-	path = sources/sysmgr-admin
-	url = ssh://git@git.dianyunshouhu.com:2222/touyun_liuyun/sysmgr-admin.git

CLAUDE.md

@@ -1,28 +1,28 @@
 # 通用系统管理脚手架 (sysmgr)
 
-通用系统管理脚手架：用户/角色/资源/组织/审计/字典/日志等后台基础能力的统一管理。
+通用系统管理脚手架：用户/角色/权限/组织/审计等后台基础能力的统一管理。需求与规格权威见 `docs/requirements/`（产品方案 + PRD）。
-**单一事实源 = `openspec/specs/`**；spec 约定见 `docs/spec-conventions.md`，三支柱架构见 `docs/architecture.md`。
 
 ## 技术栈
 
-- 后端：NestJS 12（`sources/sysmgr-nest`）
+待定（TODO：待技术选型后补充）
-- 管理后台前端：Vue 3（`sources/sysmgr-admin`）
-- 运行时 Node 22.23.1 · 包管理 pnpm 12.10.1
 
 ## 开发工作流（三支柱编排）
 
+本项目用三件工具协作，请按此顺序理解其分工：
+
 | 支柱 | 定位 | 载体 |
 |---|---|---|
 | harness (Claude Code) | 执行环境：规范、权限 | 本文件、`.claude/settings.json` |
-| openspec | 需求与变更单一事实源 | `openspec/`（spec-driven） |
+| openspec | 需求与变更单一事实源 | `openspec/`（spec-driven schema） |
 | superpowers | 过程方法论驱动 | 全局插件 + `.claude/skills/` |
 
-架构图与协作分工详见 `docs/architecture.md`。
-
 **任何功能/变更请求，按以下流程推进：**
 
 1. 用 `superpowers:brainstorming` 将请求分类为 spike / bounded / architectural。
-2. architectural 工作 → 走 `/opsx:propose`（proposal → specs → design → tasks）。
+2. architectural 工作 → 走 `/opsx:propose`（proposal → specs → design → tasks），
+   配合 `.claude/skills/openspec-*` 技能；入口由
+   `.claude/skills/openspec-superpowers-bridge/` 将 openspec 各阶段映射到
+   superpowers 过程技能。
 3. 用 `superpowers:writing-plans` 生成实施计划（存 `docs/superpowers/plans/`）。
 4. 执行期遵循 superpowers 过程技能：TDD、systematic-debugging、
    requesting-code-review、verification-before-completion，并按 `/opsx:apply` 落地任务。
@@ -33,8 +33,21 @@ harness 管「环境怎么配合」。
 
 ## Spec 约定（新会话必须遵守）
 
-spec 的**组织 / 粒度 / 编号 / 铁律 / 模块清单 / 设计决策**唯一权威见
+规范详情见 `docs/spec-conventions.md`，此处为必守要点。
-`docs/spec-conventions.md`，新会话与每个 change 必须遵守，此处不重复。
+
+### 三层结构（前后端分离，独立验收）
+- `specs/shared/`：跨前后端公共契约——`platform`(全局规范) / `data-model`(数据模型) / `api-contract`(API 契约)
+- `specs/frontend/`：前端 spec，按「页面 → 功能块」拆分，用 Mock 独立验收
+- `specs/backend/`：后端 spec，按「实体/域」拆分，用 API 测试独立验收
+
+### 编号
+格式 `<层>-<端/域>-<页面/实体>[.<功能块>]`，顺序即构建顺序（SH→FE→BE）；详见 `docs/spec-conventions.md`。
+
+### 铁律
+- **需求文档（PRD）是约束/规范的唯一权威，原型仅作视觉参考**
+- **数据库 schema 是字段一致性的唯一锚点**：`data-model` spec（字段字典）先行，前后端引用同一字段名，禁止各自命名
+- **前端先行 + Mock**：前端对 Mock 验收，后端对 api-contract 实现
+- **字段/接口变更先改 `shared/`，再改对应 spec**
 
 ## 约定
 
@@ -43,9 +56,11 @@ spec 的**组织 / 粒度 / 编号 / 铁律 / 模块清单 / 设计决策**唯
 
 ## 当前进度
 
-| 项 | 状态 |
+<!-- 进度表：随开发更新，示例格式见下 -->
+<!--
+| 层/端 | 状态 |
 |---|---|
-| 前后端工程脚手架 + Git submodule | ✅ 完成 |
 | SH 三层 spec（platform / data-model / api-contract） | ⏳ 待启动 |
-| FE 管理后台 | ⏳ 待启动 |
+| FE 前端 | ⏳ 待启动 |
 | BE 后端 | ⏳ 待启动 |
+-->

README.md

@@ -1,24 +1,16 @@
 # 通用系统管理脚手架 (sysmgr)
 
-通用系统管理脚手架：用户/角色/资源/组织/审计/字典/日志等后台基础能力的统一管理。
+通用系统管理脚手架：用户/角色/权限/组织/审计等后台基础能力的统一管理。需求规格见 `docs/requirements/`，spec 约定见 `docs/spec-conventions.md`。
-单一事实源为 `openspec/specs/`；spec 约定见 `docs/spec-conventions.md`，架构见 `docs/architecture.md`。
 
 ## 技术栈
 
-| 端 | 工程 | 栈 |
+待定（TODO：待技术选型后补充）
-|---|---|---|
-| 后端 | `sources/sysmgr-nest` | NestJS 12 · TypeScript · Vitest |
-| 管理后台前端 | `sources/sysmgr-admin` | Vue 3 · Vite · TypeScript · Pinia · UnoCSS |
 
-运行时 Node 22.23.1 · 包管理 pnpm 12.10.1。
+AI Coding 项目，融合三件工具：
-
-## 三支柱
 
 - **harness** — Claude Code（规范见 `CLAUDE.md`）
-- **openspec** — 需求/变更单一事实源（`openspec/`，spec-driven）
+- **openspec** — 需求/变更单一事实源（`openspec/`，spec-driven 工作流）
-- **superpowers** — 过程方法论（全局插件 + `.claude/skills/`）
+- **superpowers** — 过程方法论（全局插件，项目级桥接见 `.claude/skills/`）
-
-架构详图见 `docs/architecture.md`。
 
 ## 快速开始
 
@@ -29,19 +21,14 @@ openspec list                # 列变更
 openspec view                # 交互式看板
 ```
 
-克隆（含子模块）：
-
-```bash
-git clone --recurse-submodules git@git.dianyunshouhu.com:touyun_liuyun/System_Management.git
-```
-
 ## 目录
 
 - `CLAUDE.md` / `AGENTS.md` — 项目规范与工作流
 - `openspec/` — 规范与变更
-- `docs/requirements/` — 功能文档（边实现边补）
+- `docs/requirements/` — 产品方案 + PRD + 原型
-- `docs/spec-conventions.md` — spec 约定（组织/粒度/编号/模块清单）
+- `docs/spec-conventions.md` — spec 约定（组织/粒度/编号）
-- `docs/architecture.md` — 三支柱架构图
+- `docs/architecture.md` — 三支柱架构图（职责 / 协作 / 技术分层 / 变更生命周期）
-- `docs/superpowers/` — 设计文档 / 实施计划
+- `docs/superpowers/specs/` — 设计文档
+- `docs/superpowers/plans/` — 实施计划
 - `.claude/skills/` — 项目级技能
-- `sources/` — 源码（前后端 Git submodule，前缀 `sysmgr-`）
+- `sources/` — 源码（各端独立项目，前缀 `sysmgr-`）

docs/spec-conventions.md

@@ -1,28 +1,18 @@
 # Spec 约定（Spec Conventions）
 
-通用系统管理脚手架 openspec spec 的**组织、粒度、编号、模块划分**唯一权威。
+通用系统管理脚手架 openspec spec 的**组织、粒度、编号**唯一权威约定。
-**新会话、新 change 必须遵守，违反即返工。**
+**新会话、新 change 必须严格遵守，违反即返工。**
 
-> 本文是 spec 相关约定的**唯一事实源**；`CLAUDE.md` / `AGENTS.md` / `openspec/config.yaml`
+## 1. 需求权威
-> 只引用本文、不重复本文内容。改 spec 约定只改这里。
 
-## 1. 事实源
+- **需求文档（PRD）是约束/规范的唯一权威**，位于 `docs/requirements/`：
-
+  - docs/requirements/*.md
-- 本项目是**脚手架**，无外部 PRD；**单一事实源 = `openspec/specs/`**，其中
+- **原型仅作视觉参考**，约束/规范一律以 PRD 为准。
-  `shared/data-model`（字段字典）是字段一致性唯一锚点，`shared/api-contract`（接口契约）
+- **PRD 内部冲突时，以全局规范文档（PRD-00 全局规范）为准**。
-  是前后端联调唯一锚点。
-- **功能文档**边实现边补，存 `docs/requirements/`（模块说明/产品方案），仅作说明，不凌驾于 spec。
-- 原型仅作视觉参考。
 
 ## 2. 技术栈
 
-| 端 | 工程 | 栈 |
+待定（TODO：待技术选型后补充）
-|---|---|---|
-| 后端 | `sources/sysmgr-nest` | NestJS 12 · TypeScript · Vitest |
-| 管理后台前端 | `sources/sysmgr-admin` | Vue 3 · Vite · TypeScript · Pinia · UnoCSS |
-
-- 运行时 Node 22.23.1，包管理 pnpm 12.10.1（以 `engines` / `packageManager` / `.nvmrc` 为准）。
-- 前后端工程以 **Git submodule** 形式纳入主仓管理。
 
 ## 3. spec 三层结构
 
@@ -33,18 +23,19 @@ specs/
 │   ├── data-model/            数据模型（实体 + 枚举 + 状态机 = 字段字典）
 │   └── api-contract/          API 契约（endpoint + 请求/响应 shape）
 ├── frontend/                  ← 前端 spec（Mock 独立验收）
-│   └── AD/                    管理后台（当前唯一前端端）
+│   └── <各端目录>            ← `BE` 后端 / `FE` 前端 / `AD` 管理后台（待定）
 └── backend/                   ← 后端 spec（API 独立验收）
-    └── <域>/                  按 §9 域码清单
+    └── <各实体/域目录>        ← `USER` 用户 / `ROLE` 角色 / `PERM` 权限 / `ORG` 组织（待定）
 ```
 
 ## 4. 粒度规则
 
-- **前端**：细到「功能块」级。一个 spec = 一个可独立验收的功能单元。每页保留一个薄
+- **前端**：细到「功能块」级。一个 spec = 一个可独立验收的功能单元，锚定 PRD 的
-  「页面级 spec」作容器（定位/导航/布局/流转）。
+  「元素定义表」（1 个元素或一组强相关元素）。每页保留一个薄「页面级 spec」作容器
+  （定位/导航/布局/流转）。
   - 判断标准：这个块能不能**独立验收、独立打勾**。能就拆，不能就合；简单页不强拆。
   - 同一页面 PC 与移动可合并为同一 spec（布局差异写在 spec 内部）。
-- **后端**：按实体/域（见 §9 域码清单）。
+- **后端**：按实体/域（`USER` 用户 / `ROLE` 角色 / `PERM` 权限 / `ORG` 组织（待定））。
 - **共享**：platform / data-model / api-contract 三个。
 
 ## 5. 编号规则
@@ -54,35 +45,32 @@ specs/
 | 段 | 取值 |
 |---|---|
 | 层 | `SH` shared / `FE` frontend / `BE` backend |
-| 端(FE) | `AD` 管理后台（当前唯一；将来用户端为 `FE`） |
+| 端(FE) | `BE` 后端 / `FE` 前端 / `AD` 管理后台（待定） |
-| 域(BE) | 见 §9 域码清单 |
+| 域(BE) | `USER` 用户 / `ROLE` 角色 / `PERM` 权限 / `ORG` 组织（待定） |
 | 域(SH) | `PLT` platform / `DM` data-model / `AC` api-contract |
-| 页面(FE) | 功能页英文 kebab-case（如 `user`、`role`、`resource`） |
+| 页面(FE) | 沿用 PRD 编号去 `P-` 前缀 |
 | 功能块 | `.01` `.02` …（页面级 spec 无后缀） |
 
 **顺序（读取即构建顺序）**：
 1. 层序：`SH` → `FE` → `BE`
-2. FE 内端序：`AD`（将来加 `FE` 用户端时排 `AD` 之后）
+2. FE 内端序：`FE` → `AD`
-3. 域序按 §9 核心域顺序；块序 `.01` → `.02` …
+3. 页序按 PRD 编号；块序 `.01` → `.02` …
 
-**目录命名**：功能块目录带序号，如 `specs/frontend/AD/<页面>/03-<功能块>/`。
+**目录命名**：功能块目录带序号，如 `specs/frontend/<端>/<页面>/03-<功能块>/`。
 
-**例子**：`SH-DM`（数据模型，最前）· `FE-AD-<页面>.<块>`（前端功能块）· `BE-<域码>`（后端域）
+**例子**：`SH-DM`（数据模型，最前）· `FE-<端码>-<页面>.<块>`（前端功能块）· `BE-<实体码>`（后端域）
 
 ## 6. 铁律
 
-1. **单一事实源 = `openspec/specs/`**（无 PRD 权威）；冲突以 `shared/data-model` / `shared/api-contract` 为准。
+1. **需求文档（PRD）是约束/规范的唯一权威，原型仅作视觉参考**；PRD 冲突以全局规范为准。
-2. **数据库 schema 是字段一致性的唯一锚点**：`data-model` 字段字典先行，前后端引用同一字段名，禁止各自命名。
+2. **数据库 schema 是字段一致性的唯一锚点**：`SH-DM` 字段字典先行，前后端 spec 引用同一字段名，禁止各自命名。
 3. **前端先行 + Mock**：前端对 Mock 验收，后端对 `SH-AC` 契约实现。
-4. **字段/接口变更先改 `shared/`，再改对应 spec。**
+4. **字段/接口变更先改 `shared/`，再改对应 spec**。
-5. **多租户**：业务实体一律带 `tenant_id`，查询统一按租户过滤（见 §9.2-1）。
-6. **资源表统一授权**：菜单/按钮/接口统一为「资源」表，RBAC 授权锚点（见 §9.2-2）。
-7. **数据权限**：行级可见性由 `ROLE.data_scope` 控制（见 §9.2-3）。
 
 ## 7. 构建顺序（Phase）
 
 - **Phase 0 地基**：`sources/` 脚手架 + `shared/` 三层 spec（含 DB 设计）+ Mock
-- **Phase 1 前端**：管理后台按 Mock 驱动实现
+- **Phase 1 前端**：各端按 Mock 驱动实现
 - **Phase 2 后端**：按 `SH-AC` 契约实现
 - **Phase 3 联调与上线**：切真实 API → 端到端验证 → 上线
 
@@ -109,38 +97,4 @@ specs/
 
 ### ④ 验收标准（Acceptance）
 - **ACCEPTANCE Checklist，可勾选**（`- [ ]` 形式）
-- 每条对应一个可验证行为，锚定 `SH-AC` 契约或功能点编号
+- 每条对应一个可验证行为，锚定 PRD 的 `AC-xx` 验收编号
-
-## 9. 模块清单与设计决策
-
-### 9.1 域码清单（后端 spec 按此拆分）
-
-| 层 | 域码 | 模块 | 说明 |
-|---|---|---|---|
-| 核心 | `TENANT` | 租户 | 仅 `tenant_id` 隔离，不做计费/SaaS 复杂化 |
-| 核心 | `AUTH` | 认证 | 登录/登出、token、验证码、密码策略（横切：落 `SH-AC` + 守卫） |
-| 核心 | `USER` | 用户 | CRUD、启停/锁定、密码重置、头像、关联角色/部门 |
-| 核心 | `ROLE` | 角色 | 授权（资源）+ 数据权限范围 |
-| 核心 | `RES` | 资源 | 菜单/按钮/接口统一资源表，RBAC 授权锚点 |
-| 核心 | `ORG` | 组织 | 部门树、层级、负责人 |
-| 核心 | `DICT` | 字典 | 类型 + 项，运行时 lookup |
-| 建议 | `CONFIG` | 参数配置 | 系统键值参数 |
-| 建议 | `AUDIT` | 操作日志 | 审计：谁/何时/对什么/做了什么 |
-| 建议 | `LOGIN` | 登录日志 | 登录成功/失败、IP、UA |
-| 建议 | `SESSION` | 在线会话 | 活跃会话、强退 |
-| 扩展 | `POST` | 岗位 | 比「角色」更细的职位维度 |
-| 扩展 | `NOTICE` | 通知公告 | 站内公告 |
-| 扩展 | `JOB` | 定时任务 | 任务调度 |
-| 扩展 | `FILE` | 文件存储 | 附件/OSS |
-| 扩展 | `MSG` | 消息通知 | 邮件/短信/推送 |
-
-### 9.2 三大设计决策
-
-1. **多租户**：单租户式简单实现——所有业务实体带 `tenant_id`，后端统一租户过滤切面；
-   登录时按账号/租户域识别当前租户。**不做**按量付费、套餐、租户配额。
-2. **资源表（RES）**：菜单与权限合一为「资源」表，`type ∈ {菜单 MENU, 按钮 BUTTON, 接口 API}`；
-   「目录」不设独立类型，由「菜单节点是否拥有菜单子节点」推导。
-   - 后端鉴权三级：公开接口无需 token → 未登记接口仅校验登录 → 登记为「接口」资源的接口校验 token + 权限标识。
-   - **约定**：写操作/敏感查询一律登记为「接口」资源，仅真正公开的留白。
-3. **数据权限**：`ROLE.data_scope ∈ {全部 / 本部门 / 本部门及以下 / 本人 / 自定义}`；
-   自定义时经 `role_org`（角色-部门）关联表；后端列表查询统一按可见部门过滤。

openspec/config.yaml

@@ -2,16 +2,16 @@ schema: spec-driven
 
 context: |
   项目：通用系统管理脚手架 (sysmgr)
-  领域：用户/角色/资源/组织/审计/字典/日志等后台基础能力的统一管理（多租户 tenant_id 隔离）
+  领域：通用系统管理脚手架：用户/角色/权限/组织/审计等后台基础能力的统一管理
-  技术栈：后端 NestJS 12，前端 Vue 3；Node 22.23.1 · pnpm 12.10.1
+  技术栈：待定（TODO：待技术选型后补充）
-  事实源：openspec/specs/ 为单一事实源（无 PRD 权威）
+  工作流：spec-driven（proposal → specs → design → tasks）
-  工作流：spec-driven（proposal → specs → design → tasks）；superpowers 过程技能驱动
+  协作：superpowers 过程技能驱动（brainstorming → writing-plans → TDD → review）
-  spec 约定：三层 shared/frontend/backend + 功能块级粒度 + 编号 <层>-<端/域>-<页面>.<块>；
+  spec 约定：三层 shared/frontend/backend + 前端功能块级粒度 + 编号 <层>-<端/域>-<页面>.<块>（SH→FE→BE）；详见 docs/spec-conventions.md
-  唯一权威见 docs/spec-conventions.md
 
 rules:
   specs:
-    - 遵循 docs/spec-conventions.md（三层结构/粒度/编号/铁律/模块清单），此处不重复
+    - 前后端 spec 分离；前端按页面→功能块拆分（锚定 PRD 元素定义表）
+    - 编号遵循 <层>-<端/域>-<页面/实体>[.<功能块>] 格式，层序 SH→FE→BE
     - 字段名引用 shared/data-model 字段字典，禁止各自命名
   design:
     - 数据库 schema（ERD/DDL/字段字典）放 design，字段以 shared/data-model 为源

sources/sysmgr-admin

@@ -1 +0,0 @@
-Subproject commit 9730b9fd5e0bf75e53bfb24b4822c9ea68985165

sources/sysmgr-nest

@@ -1 +0,0 @@
-Subproject commit dc40ca3343dc84aa2de96c1025e01db88668a399