# unified-develop-workspace

**Repository Path**: thrulife2gether/unified-develop-workspace

## Basic Information

- **Project Name**: unified-develop-workspace
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-04-20
- **Last Updated**: 2026-08-27

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# unified-develop-workspace

这是 `general-office-system` 的父级工程，用于让业务相关的仓库、工程地图、阶段文档、项目 Skills、Harness、generated 导航和独立演示工程处于同一套可访问上下文中。

父级工程不承载业务代码历史。业务代码、业务验证和业务 Git 操作仍在 [`general-office-system`](general-office-system/) 子仓完成；父级只读取和索引子仓规则，不改写子仓的 Agent 工作流。

## 核心入口

- [AGENTS.md](AGENTS.md)：项目边界、上下文地图、阶段路由和硬规则。
- [ARCHITECTURE.md](ARCHITECTURE.md)：子仓架构地图、关键业务域、实现路径和架构不变量。
- [docs/workflow-artifacts.md](docs/workflow-artifacts.md)：Draft、Design、Product Spec、Exec Plan、Validation 与 generated 的职责。
- [docs/FRONTEND.md](docs/FRONTEND.md)：后台页面体验、设计确认和用户可见文案约束。
- [docs/design-docs/core-beliefs.md](docs/design-docs/core-beliefs.md)：长期设计信念与原型原则。
- [docs/generated/index.md](docs/generated/index.md)：静态扫描加复核后的工程导航。
- [presentations‌/](presentations‌/)：独立 React 演示工程，和子仓业务开发流程相互隔离。

## 为什么使用父级工程

前后端、SQL、运行脚本和业务规则相互关联时，只打开其中一个子仓会让工程上下文割裂。父级工程把这些入口放在同一个可访问范围内，同时保持子仓独立 Git 历史。

```text
unified-develop-workspace/
├── AGENTS.md
├── ARCHITECTURE.md
├── docs/
├── .agents/skills/
├── .harness/
├── presentations‌/
└── general-office-system/   # 独立业务子仓
```

父仓 generated 会读取但不修改：

- `general-office-system/AGENTS.md`
- `general-office-system/README.md`
- 子仓现有工程参考文档
- 子仓现有项目 Skills
- `general-office-system/docs/tasks/active/`
- 三个客户端目录的 README

子仓文档入口索引见 [docs/generated/subrepo-doc-index.md](docs/generated/subrepo-doc-index.md)。

## Harness 工作流

可以先写一份很简单的需求草案，再通过多轮对话补充目标、边界、规则和决策。

常用自然语言入口：

- `这个 draft 需要优化。你看我还需要交代什么上下文？还有什么决策点需要确认？`
- `我补充一下：…… 你继续帮我更新 draft，并告诉我还缺什么。`
- `我们先讨论页面设计方向。先只更新 draft，不生成设计稿。`
- `这个 draft 可以进入下一步。`
- `基于这个 draft 生成设计稿，先不要生成 spec/plan。`
- `设计稿确认，可以基于 draft 和设计生成 Product Spec 和 Active Exec Plan，先不要实施。`
- `按这个 Active Exec Plan 开始实施。`

不需要设计确认：

```text
Draft 多轮收敛
  -> Draft 确认
  -> Product Spec
  -> Active Exec Plan
  -> 授权 Run
  -> 实现、测试、修复
  -> Validation 与归档
```

需要设计确认：

```text
Draft 多轮收敛
  -> Draft 确认
  -> Design 与原型
  -> 设计确认
  -> Product Spec
  -> Active Exec Plan
  -> 授权 Run
  -> 实现、测试、修复
  -> Validation 与归档
```

内部 UI 影响等级和原型模式由当前模型结合需求与工程上下文维护，不要求用户填写。图像视觉探索只要求宿主具备可用图像生成能力，不绑定某个模型或版本；进入实现前仍需形成可执行的 HTML/hybrid 原型与 Handoff。

## 项目 Skills

`.agents/skills` 是项目 Skill 的唯一物理目录。核心阶段 Skill：

- `lumine-harness-navigate`：判断父仓、子仓和模块入口。
- `lumine-harness-draft`：整理轻量 Draft。
- `lumine-harness-generated`：刷新并复核 generated 导航。
- `lumine-harness-design`：处理页面设计、原型和 Handoff。
- `lumine-harness-plan`：生成或更新 Product Spec 与 Active Plan。
- `lumine-harness-run`：按 Active Plan 实施、验证和收口。
- `lumine-harness-check`：运行 Harness 检查。
- `unified-startup`：管理后端与 PC 端启停。

人通常重点审核 Draft、Design、Product Spec、Plan 摘要、Validation 摘要和高风险代码；完整源码、详细日志、测试输出和 generated 导航主要由 Agent 与工具消费。

## 检查当前 Agent 是否已接入

普通使用者不需要先记 Adapter 命令。可以直接对 Agent 说：

```text
检查当前 Agent 的 Lumine Harness 是否已经生效。
```

这项检查是只读的，不会创建探针。结果只需要告诉你：现在能不能开始、是否还有一次性设置，以及当前产品有没有会影响使用的关键限制。无法识别宿主时必须如实说明，不能猜测产品身份。

如需查看当前工程选择的全部 Adapter，可以运行：

```bash
./.harness/cli adapter status selected
```

## 常用命令

```bash
./.harness/cli check all
./.harness/cli check stale-docs
./.harness/cli check draft <slug>
./.harness/cli check design <slug>
./.harness/cli check plan <slug>

./.harness/cli generated refresh all
./.harness/cli generated refresh workspace-index

./.harness/cli skills list
./.harness/cli skills search <query>
./.harness/cli skills inspect <name>

./.harness/cli adapter list
./.harness/cli adapter check current
./.harness/cli adapter status current
./.harness/cli adapter status selected
```

`check` 是普通使用入口；`status` 只汇总已有状态。只有维护 Adapter 或排查协议时，才需要使用 `doctor` 检查配置、使用 `verify` 记录真实会话证据。

## Parallel Workers

Parallel worker 是按任务复杂度选择的辅助方式，不绑定某个 Agent 产品：

- 边界不清楚时先做只读映射。
- generated 刷新后可做只读抽样复核。
- 可写 worker 必须拥有互斥 write set 和明确验收命令。
- Integration 串行收口，runtime verifier 最后执行。

## Git 边界

- 父级 Git 只管理父级工程文件。
- `general-office-system/` 保留独立 Git 历史、远端、分支和提交流程。
- 不在父级提交子仓业务代码。
- 进入子仓真实开发且用户未指定分支时，再读取 `personal-git-rules`。

## 打开工程

优先打开 [workspace.code-workspace](workspace.code-workspace)，这样可以同时访问父级工程和业务子仓，同时保持两套 Git 边界清晰。