# 通用系统管理脚手架 (sysmgr)

通用系统管理脚手架：用户/角色/权限/组织/审计等后台基础能力的统一管理。需求与规格权威见 `docs/requirements/`（产品方案 + PRD）。

## 技术栈

待定（TODO：待技术选型后补充）

## 开发工作流（三支柱编排）

本项目用三件工具协作，请按此顺序理解其分工：

| 支柱 | 定位 | 载体 |
|---|---|---|
| harness (Claude Code) | 执行环境：规范、权限 | 本文件、`.claude/settings.json` |
| openspec | 需求与变更单一事实源 | `openspec/`（spec-driven schema） |
| superpowers | 过程方法论驱动 | 全局插件 + `.claude/skills/` |

**任何功能/变更请求，按以下流程推进：**

1. 用 `superpowers:brainstorming` 将请求分类为 spike / bounded / architectural。
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` 落地任务。
5. 完成并归档：`/opsx:archive` 更新主 spec。

**分工口诀**：openspec 管「要做什么」，superpowers 管「怎么一步步做对」，
harness 管「环境怎么配合」。

## Spec 约定（新会话必须遵守）

规范详情见 `docs/spec-conventions.md`，此处为必守要点。

### 三层结构（前后端分离，独立验收）
- `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**

## 约定

- 提交信息遵循 Conventional Commits（feat/fix/chore/docs/refactor）。
- 不直接手改 `openspec/` 下手动生成的文件，优先用 `openspec` CLI。

## 当前进度

<!-- 进度表：随开发更新，示例格式见下 -->
<!--
| 层/端 | 状态 |
|---|---|
| SH 三层 spec（platform / data-model / api-contract） | ⏳ 待启动 |
| FE 前端 | ⏳ 待启动 |
| BE 后端 | ⏳ 待启动 |
-->