woostack-bootstrap

woostack-bootstrap

概述

Bootstrap 是面向全新项目、以项目为先的入口。它收集需求，实时确认当前技术栈和版本，呈现完整的架构与范围，并在任何目标目录写入操作之前等待明确的设计审批。通过目标冲突检查后，只有这项审批（而非服务提供方的确认回执）才能解除写入屏障。本地脚手架无需 GitHub 仓库、账户、远程 URL 或 Project。

技术栈保持动态，而不是从模板中选择。根据项目需求验证用户提供的技术栈，然后为每个获批应用搭建脚手架，并使用该应用本地的代码。只有多个应用需要相同代码时，才将其提取为软件包。明确选择的 GitHub Project 可以保留获批设计和请求的交付说明，但它是可选的，绝不会授权写入。

核心原则： 根据项目需求实时确认技术和版本，绝不凭记忆判断；并在写入新代码库之前，验证获批设计以及通过冲突检查的目标目录。

调用方式

使用 /woostack-bootstrap <goal> 调用，其中 goal 是对新代码库的通俗描述：

/woostack-bootstrap create a new mobile app for cataloging recipes
/woostack-bootstrap a SaaS dashboard with a marketing site and a billing API

goal 用于启动需求收集和建议阶段；它不代表审批，也不会成为已保存的开发记录。

路由

仅当不存在其惯例或历史记录可作为工作依据的现有代码库时，才使用 bootstrap。空的远程仓库可以是预期目标，但涉及现有仓库的请求应在需求收集、MCP 预检或创建项目之前进行路由：

• 未解决的 Bug、回归、事故和根因排查 → 使用 woostack-debug 进行诊断；已证实的缺陷需要问题计划时 → 使用 woostack-plan；
• 适合纳入一个可审查 PR 的有限范围增强、重构或测试任务（包括单文件请求），或已获授权且有因果证据、适合纳入一个可审查 PR 的缺陷修复 → woostack-execute；
• 涉及多个 PR 的功能或架构计划 → woostack-plan。

流程

1. 分类并了解意图。 首先判断是绿地项目还是棕地项目。可以按照 文件系统流程进行有限的只读 目标检查，以确认目标是否存在或是否存在冲突；但这不授予任何写入权限。
2. 收集需求。 针对产品目标、必需的使用界面、规模、部署限制、合规性与安全性、集成以及预算提出有针对性的问题。
3. 开展实时行业调研。 使用网络搜索和实时注册表查询（例如 npm view <pkg> version），找出满足需求的当前框架、库、数据库和服务。
4. 呈现设计。 调研并验证所提供的可行技术栈，然后呈现一套完整的拟议架构和范围，包括使用界面、初始功能、技术决策、生产就绪情况及成本影响。仅针对尚未解决的重要权衡比较其他方案。设计仅保留在对话／运行上下文中：不得创建远程项目／议题、本地规格说明或计划、目标目录、分支、提交或 PR。

等待对完整呈现的设计给予明确批准。沉默、最初提出的目标、对技术栈的偏好、部分同意，或 Agent 推断出的批准，均不能通过此关卡。批准前，不得对官方 MCP 进行任何开发变更，也不得创建任何开发产物。

5. 通过文件系统写入屏障。 设计获批后，按照规范的 冲突检查流程执行。已批准的范围和实际选定的目标须保留在对话上下文中；不得创建运行记录、哈希或清单来代替它们。早期检查不能取代写入前重新进行的检查。
6. 可选：发布已批准的设计。 仅在设计获批且目标冲突检查通过后，并且仅当调用方选定了确切的 GitHub Project 时，应用通用的 产物契约，加载 Project 内容契约，并遵循引导发布流程。设计获批且冲突／文件系统准入完成前，不得执行任何 GitHub 操作。根据实际范围、身份、能力和回读规则，解析确切选定的 Project，并追加／回读 designApproved。GitHub 操作结果缺失、不完整、含糊或未知时，仅阻止本次请求的发布，除非该发布明确属于交付内容。产物文本永远不能解除文件系统屏障。
7. 搭建脚手架并验证。 遵循 references/bootstrap.md，包括其中引用的所有架构、框架、基础设施和实现契约。仅在本地 Git 初始化完成后，才可按照存储库初始化流程设置明确要求的远程仓库。仅当用户在已批准范围内选择采用 Woostack 或项目指南，或明确需要本地支持时，才调用 woostack-init。对于文档编写，传入已批准的产品／设计决策和观察到的脚手架命令；复用这些信息，不要再次访谈需求或扩大脚手架范围。仅需支持的交接场景，直接选择 Init 的本地支持路径。交接前，运行所选技术栈规定的构建、测试、代码检查、格式化和启动检查。

参考资料（按需加载）

文件	定义内容
references/decisions.md	问卷指南和明确的设计确认流程
references/bootstrap.md	防冲突初始化和可选的 GitHub 发布
references/architecture.md	应用内代码放置、可选共享包和命名
references/frameworks.md	版本解析规则、应用级依赖项和注意事项
references/infrastructure.md	生产就绪模式：托管、CI/CD、环境变量、迁移、可观测性
references/patterns.md	标准实现模式；规范测试指南见 Execute
references/development.md	仓库权威来源、保留数据、路由和分支模型

硬性约束

以下要求不可妥协。违反要求会导致项目缺少归属信息、无法正常运行或容易偏离预期。

• 棕地项目路由。 仅为诊断而提出的请求应路由至只读 Debug；问题规划应路由至 Plan；经授权的、有明确范围的增强、重构、测试和修正应路由至 Execute。Execute 会在修复前查明缺陷原因；证据充分时，可在同一流程中完成。
• 明确批准前不生成任何产物。 需求、研究、选项和设计均保留在运行上下文中。设计审批关卡通过前，不得创建远程项目、更新、问题、文档、本地规范/计划、目标目录、分支、提交或 PR。
• 写入前先批准。 遵循文件系统屏障；早期只读检查和 GitHub 回执均不构成进行修改的授权。
• 远程操作须主动选择。 仅本地脚手架不会调用 GitHub，也不需要账户、Project、远程 URL、推送或 PR；不得推测仓库名称或创建远程资源来满足本地交付要求。用户要求进行远程设置或发布时，只能使用已获授权的原生 GitHub 能力或经过主机身份验证的 gh，并使用精确身份、稳定的修改 ID、完整分页和独立回读。不得使用文档、自定义传输、仓库凭据、环境令牌回退或其他权威来源。
• 发布失败的影响范围有限。 缺少访问权限或结果未知/不完整时，应阻止用户要求的发布，但不应阻止其他已批准且不含产物的脚手架工作，除非发布明确属于交付内容。未直接回读确认时，绝不可声称已发布。已弃用的旧配置/数据仍以不透明的用户数据形式保留在磁盘上，从活动配置中排除，并在其边界处提供弃用说明；绝不导入此类数据。
• 始终在线解析最新版本。 绝不可使用记忆中硬编码的版本。在研究和精确解析期间，应实时查询注册表。
• 代码保持在应用内，直至需要共享。 遵循 references/architecture.md：新代码应放在所属应用中，只有多个应用需要相同实现或契约时，才提取为包。
• 未经验证不得交付。 在声明脚手架已完成前，所选技术栈的构建、lint、测试、格式化和启动检查必须全部通过。
• 记录决策。 交接时，将最终技术栈选择、已解析版本、理由和开发说明写入项目根目录的 README.md；仅当可选产物链接已明确选定并验证后，才将其列入其中。

SPEC_VERSION

6.0.0 — 本地优先的全新项目脚手架：经审批后生成脚手架，不强制要求远程服务，可选择直接发布到 GitHub Project。