bootstrap-brownfield

存量项目引导

在进行 SDD 规划前，对现有产品进行架构探索。

Harness 探索

参见 ../nextstage-harness/references/harness-discovery.md。从 {harness_root}/rules/*.md 加载规则。先阅读 architecture-rules.md。旧版：仅当 {harness_root} 不存在时，才读取 .cursor/rules/*.mdc。当存在规范规则时，将发现结果与之对照；缺少规则时，检查仅供参考。

适用场景

• “分析现有项目” / “存量项目引导”
• 在包含代码但没有 requirements.md 的仓库中首次进行 SDD 规划
• 在旧版代码上运行 requirements-generator 之前

工作流

步骤 1 — 结构检测

检查 {product_root}（以及旧版布局中的仓库根目录，并记录不一致之处）：

后端信号： composer.json、artisan、模块化的 app/Modules/、docker-compose.yml、.env.example

前端信号： package.json、tsconfig.json、src/modules/、cypress/、打包工具配置

布局： backend/ + frontend/ 单体仓库，还是单一应用

步骤 2 — 模块映射

列出各领域：

• 后端：每个模块的模块、控制器、模型、迁移
• 前端：每个模块的页面、状态仓库、服务

步骤 3 — 规则遵循情况（可选）

当存在 Harness 规则时，与之对照检查后端模块布局、多租户、前端模式和测试。为每行标记 ✅ / ⚠️ / ❌。

没有 Harness 规则时，使用与技术栈无关的检查项。

步骤 4 — 报告

创建或更新 {product_root}/docs/context/brownfield-map.md：

# Architectural map — brownfield bootstrap

**Date:** {date}

## Identified stack

- Backend: ...
- Frontend: ...
- Database, cache, queues, E2E tooling

## Backend modules

| Module | Controllers | Models | Migrations | Tests |

## Frontend modules

| Module | Pages | Stores | E2E |

## Rule adherence

{tables when rules exist}

## Gaps (priority)

1. Critical ...
2. Medium ...

## Recommendations for next planning

- ...

步骤 5 — 呈现结果

用 3–5 条要点进行总结，突出关键差距，并询问是否开始版本规划或审查差距。

重要规则

• 只读 — 不修改代码
• 仅在 {product_root}/docs/context/ 下生成报告
• 将 brownfield-map.md 作为上下文传递给 requirements-generator
• 更新现有映射，而不是创建重复文件

相关技能

• codebase-reverse-spec — 提取业务行为（比引导更深入）
• requirements-generator — 引导后的下一步
• clarify-requirements — 范围仍不明确时使用