Back to Details

manifest-generator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

ManifestGenerator

ManifestGenerator

Given a project description, produce two files in the current directory:
  1. PROJECT_MANIFEST.md
    — structured project context every factory agent reads
  2. SOFTWARE_FACTORY_MANIFEST.md
    — the 6-agent SDLC pipeline blueprint
Execute each phase in order. Do not skip phases. Do not proceed past a STOP until you have the required input.
给定项目描述后，在当前目录生成两个文件：
  1. PROJECT_MANIFEST.md
    — 所有工厂Agent都会读取的结构化项目上下文
  2. SOFTWARE_FACTORY_MANIFEST.md
    — 6-Agent软件开发生命周期（SDLC）流水线蓝图
按顺序执行每个阶段，不可跳过阶段。在获得所需输入前，不得越过STOP步骤。

FILE_WRITE_GUARD

FILE_WRITE_GUARD

Call this procedure before writing either output file. Substitute the actual filename.
FILE_WRITE_GUARD(filename):
  Check if filename exists in the current directory (use Read tool).
  If it exists:
    Ask the user: "filename already exists. Overwrite, rename to filename.bak, or abort?"
    Overwrite → proceed.
    Rename → rename the existing file to filename.bak, then proceed.
    Abort → stop execution entirely.
  If it does not exist → proceed to write.
在写入任一输出文件前调用此流程，替换为实际文件名。
FILE_WRITE_GUARD(filename):
  检查当前目录中是否存在filename（使用Read工具）。
  如果已存在：
    询问用户："filename已存在。是否覆盖、重命名为filename.bak，还是终止操作？"
    覆盖 → 继续执行。
    重命名 → 将现有文件重命名为filename.bak，然后继续执行。
    终止 → 完全停止执行。
  如果不存在 → 继续写入。

Phase 0: Resume Detection

Phase 0：恢复检测

Before anything else, check for existing output files (use Read tool — expect a "file not found" error if they don't exist, which is the normal case):
  1. Does 
    PROJECT_MANIFEST.md
    exist in the current directory?
  2. Does 
    SOFTWARE_FACTORY_MANIFEST.md
    exist in the current directory?
Both missing: Proceed to Phase 1.
PROJECT_MANIFEST.md exists, SOFTWARE_FACTORY_MANIFEST.md does NOT: Read 
PROJECT_MANIFEST.md
into context. Skip Phases 1–5. Tell the user: "Found existing PROJECT_MANIFEST.md — skipping to factory manifest generation." Jump to Phase 6.
Both exist: Ask the user: "Both output files already exist. Regenerate from scratch, or abort?" Regenerate → proceed to Phase 1 (FILE_WRITE_GUARD will handle overwrites). Abort → stop.
在执行任何操作前，检查是否存在输出文件（使用Read工具——如果不存在会返回"文件未找到"错误，这是正常情况）：
  1. 当前目录中是否存在
    PROJECT_MANIFEST.md
    ？
  2. 当前目录中是否存在
    SOFTWARE_FACTORY_MANIFEST.md
    ？
两者均缺失： 进入Phase 1。
PROJECT_MANIFEST.md存在，SOFTWARE_FACTORY_MANIFEST.md不存在： 读取
PROJECT_MANIFEST.md
到上下文，跳过Phase 1–5。 告知用户："检测到已存在的PROJECT_MANIFEST.md —— 跳过至工厂清单生成阶段。" 跳转至Phase 6。
两者均存在： 询问用户："两个输出文件均已存在。是否从头重新生成，还是终止操作？" 重新生成 → 进入Phase 1（FILE_WRITE_GUARD将处理覆盖逻辑）。 终止 → 停止操作。

Phase 1: Accept Input

Phase 1：接收输入

Runtime detection probe: Attempt to call AskUserQuestion with the question below. If it succeeds → interactive mode: use AskUserQuestion one-at-a-time for all remaining phases. If it fails (tool not found) → text mode: for all remaining phases, print pending questions as a numbered list, wait for the user to answer, then continue.
Input check (first question / probe):
Check the user's current message or invocation arguments:
  • Contains a file path (e.g., 
    PROJECT_OVERVIEW.md
    ): use the Read tool to read it.
    • File not found → tell the user, ask them to paste the description directly. STOP.
    • File found but appears non-text (JSON, binary, package.json, etc.) → tell the user "That file doesn't look like a project description." Ask for inline text. STOP.
    • File found and text → use it as the description.
  • Contains a project description (multiple sentences about what's being built): use it.
  • Neither → ask: "Paste your project description, or describe what you're building. Include what it does, who uses it, the tech stack if chosen, and any constraints."
STOP. Do not proceed until a description is in context.
运行时检测探针： 尝试调用AskUserQuestion工具提出以下问题。 如果调用成功 → 交互模式：对所有后续阶段逐个使用AskUserQuestion。如果调用失败（未找到工具） → 文本模式：将所有待解决问题打印为编号列表，等待用户回答后再继续。
输入检查（第一个问题/探针）：
检查用户当前消息或调用参数：
  • 包含文件路径（例如：
    PROJECT_OVERVIEW.md
    ）：使用Read工具读取该文件。
    • 文件未找到 → 告知用户，要求直接粘贴项目描述。STOP。
    • 文件存在但非文本格式（JSON、二进制、package.json等） → 告知用户"该文件看起来不是项目描述"，要求提供内联文本。STOP。
    • 文件存在且为文本格式 → 将其作为项目描述。
  • 包含项目描述（关于构建内容的多段语句）：直接使用。
  • 两者都不满足 → 询问："请粘贴您的项目描述，或描述您要构建的内容。包括功能用途、目标用户、选定的技术栈以及任何约束条件。"
STOP。在获取到项目描述前，不得继续执行。

Phase 2: Extraction

Phase 2：信息提取

Map the description against the 11 PROJECT_MANIFEST sections. For each, assign:
  • EXTRACTED — specific, project-named content present (real technology names, actual user roles, concrete constraints, named entities)
  • PARTIAL — some content present but incomplete or vague
  • MISSING — no relevant content found
Use the WORKED EXAMPLE (at the bottom of this file, between the HTML comment markers) to calibrate what "EXTRACTED" looks like per section. Do not use example content as output.
Always-ask sections — ask if PARTIAL or MISSING, never default:
Section 1: Overview
Section 2: Tech Stack
Section 4: Domain Model  ← most important; never generate a default
Section 6: Constraints
Section 9: Success Criteria
Defaultable sections — generate from context if MISSING, with label:
Section 3: Project Structure
  → infer from tech stack
  → label: (proposed — update when scaffolded)

Section 5: Conventions
  → infer from tech stack (e.g. Node.js → kebab-case files, *.test.ts,
    conventional commits; Python → snake_case, test_*.py, etc.)
  → label: (default — update when scaffolded)

Section 7: Task Inputs
  → derive from Domain Model + fixed pipeline sequence
  → label: (pipeline-critical — verify before running factory)
  → note: weak Domain Model = weak Task Inputs; this breaks pipeline sequencing

Section 8: Services to Connect
  → empty table if not mentioned

Section 10: Review Standards
  → generic rules appropriate to the detected tech stack
  → label: (default — customize for this project)

Section 11: Release Criteria
  → generic checklist appropriate to the project type
  → label: (default — customize for this project)
After mapping, identify which always-ask sections are PARTIAL or MISSING. Proceed to Phase 3.
将项目描述与PROJECT_MANIFEST的11个部分进行匹配，为每个部分标记：
  • EXTRACTED（已提取） —— 存在特定的、与项目相关的内容（真实技术名称、实际用户角色、具体约束条件、命名实体）
  • PARTIAL（部分提取） —— 存在部分内容但不完整或模糊
  • MISSING（缺失） —— 未找到相关内容
使用本文件底部HTML注释标记内的WORKED EXAMPLE（示例），校准每个部分的"EXTRACTED"标准。不得将示例内容作为输出使用。
必须询问的部分 —— 如果标记为PARTIAL或MISSING，必须询问用户，不得默认填充：
Section 1: Overview（概述）
Section 2: Tech Stack（技术栈）
Section 4: Domain Model（领域模型） ← 最重要；绝不自动生成默认内容
Section 6: Constraints（约束条件）
Section 9: Success Criteria（成功标准）
可默认填充的部分 —— 如果标记为MISSING，可根据上下文生成内容并添加标签：
Section 3: Project Structure（项目结构）
  → 根据技术栈推断
  → 标签：(proposed — update when scaffolded)（建议方案 —— 脚手架搭建后更新）

Section 5: Conventions（约定规范）
  → 根据技术栈推断（例如：Node.js → 短横线命名文件、*.test.ts、规范式提交；Python → 下划线命名、test_*.py等）
  → 标签：(default — update when scaffolded)（默认方案 —— 脚手架搭建后更新）

Section 7: Task Inputs（任务输入）
  → 从领域模型+固定流水线序列推导
  → 标签：(pipeline-critical — verify before running factory)（流水线核心 —— 运行工厂前请验证）
  → 注意：领域模型薄弱会导致任务输入质量低下，进而破坏流水线顺序

Section 8: Services to Connect（待集成服务）
  → 如果未提及则为空表格

Section 10: Review Standards（评审标准）
  → 适用于检测到的技术栈的通用规则
  → 标签：(default — customize for this project)（默认方案 —— 针对本项目定制）

Section 11: Release Criteria（发布标准）
  → 适用于项目类型的通用检查清单
  → 标签：(default — customize for this project)（默认方案 —— 针对本项目定制）
匹配完成后，识别出所有标记为PARTIAL或MISSING的必须询问部分，进入Phase 3。

Phase 3: Gap-Fill

Phase 3：填补信息缺口

For each always-ask section that is PARTIAL or MISSING, ask one targeted question. Ask in this order: Overview → Tech Stack → Domain Model → Constraints → Success Criteria.
Interactive mode: AskUserQuestion, one question per call. Wait for answer before asking the next.
Text mode: Print all pending questions as a numbered list. Wait for the user to answer all before continuing.
Never ask about a section that is already EXTRACTED.
Domain Model special rule: If the Domain Model answer contains no entity names (a single vague sentence like "it manages data" or "it has users"), ask one follow-up: "Can you name the core data entities? For example: Order, Customer, Staff — the main 'things' your system tracks and stores." Accept the second answer regardless. If still no entity names, mark FILLED but add label 
(weak — strengthen Section 4 before running factory)
.
STOP. Do not proceed until all always-ask sections are FILLED.
对每个标记为PARTIAL或MISSING的必须询问部分，提出一个针对性问题。按以下顺序询问：Overview（概述）→ Tech Stack（技术栈）→ Domain Model（领域模型）→ Constraints（约束条件）→ Success Criteria（成功标准）。
交互模式： 使用AskUserQuestion，每次提问一个问题，等待回答后再提出下一个。
文本模式： 将所有待解决问题打印为编号列表，等待用户全部回答后再继续。
绝不询问已标记为EXTRACTED的部分。
领域模型特殊规则： 如果领域模型的回答中没有实体名称（例如"它管理数据"或"它有用户"这类模糊语句），追加一个跟进问题："能否列出核心数据实体？例如：Order（订单）、Customer（客户）、Staff（员工）—— 系统跟踪和存储的主要对象。" 无论第二个回答如何都接受。如果仍然没有实体名称，标记为FILLED（已填充）并添加标签
(weak — strengthen Section 4 before running factory)
（薄弱 —— 运行工厂前请完善Section 4）。
STOP。在所有必须询问部分都完成填充前，不得继续执行。

Phase 4: Validate

Phase 4：验证

Check all 11 sections. A section is still a placeholder if it:
  • Is empty
  • Contains unedited template text (e.g., 
    [Core entities, their fields...]
    )
  • Contains only generic content applicable to any project
For any defaultable section still a placeholder: generate a reasonable default and label it 
(generated — verify before use)
.
For any always-ask section still a placeholder: this should not happen (Phase 3 should have caught it). If it somehow did, ask one targeted question now.
Proceed to Phase 5.
检查所有11个部分。如果某部分满足以下任一条件，则视为占位符：
  • 内容为空
  • 包含未编辑的模板文本（例如：
    [Core entities, their fields...]
    ）
  • 仅包含适用于任何项目的通用内容
对于仍为占位符的可默认填充部分：生成合理的默认内容并添加标签
(generated — verify before use)
（自动生成 —— 使用前请验证）。
对于仍为占位符的必须询问部分：这种情况不应发生（Phase 3应已处理）。如果确实发生，立即提出一个针对性问题。
进入Phase 5。

Phase 5: Write PROJECT_MANIFEST.md

Phase 5：写入PROJECT_MANIFEST.md

Call FILE_WRITE_GUARD("PROJECT_MANIFEST.md").
Write 
PROJECT_MANIFEST.md
to the current directory using the Write tool. Use the PROJECT_MANIFEST template defined in the Schema section below. Fill every section. No section may remain empty or contain template placeholder text.
Report: "PROJECT_MANIFEST.md written. N/11 sections extracted from description, M filled via Q&A, K generated as defaults."
调用FILE_WRITE_GUARD("PROJECT_MANIFEST.md")。
使用Write工具将
PROJECT_MANIFEST.md
写入当前目录，采用下方Schema部分定义的PROJECT_MANIFEST模板。 填充所有部分，不得有空白部分或模板占位文本。
反馈："PROJECT_MANIFEST.md已写入。11个部分中有N个从描述中提取，M个通过问答填充，K个为自动生成的默认内容。"

Phase 6: Generate SOFTWARE_FACTORY_MANIFEST

Phase 6：生成SOFTWARE_FACTORY_MANIFEST

Use the PROJECT_MANIFEST content already in context (generated in Phase 5, or read in Phase 0 resume). Do not re-read from disk.
Fill the 7 SOFTWARE_FACTORY_MANIFEST sections:
Section 1 — Factory Overview One paragraph: project name + "This factory runs a 6-agent sequential pipeline..." + tech stack summary drawn from the project manifest.
Section 2 — Pipeline Sequence Fixed 6-agent sequence. Use the project name (lowercased, hyphenated) as <slug>:
1. Planner
   Reads:  feature request + PROJECT_MANIFEST.md
   Writes: work-packages/<slug>.md

2. Architect
   Reads:  Planner work package + Tech Stack section of PROJECT_MANIFEST.md
   Writes: docs/adr/NNNN-<slug>.md

3. Designer
   Reads:  Architect ADR + Domain Model section of PROJECT_MANIFEST.md
   Writes: design/<slug>-spec.md

4. Coder
   Reads:  Designer spec + Conventions section of PROJECT_MANIFEST.md
   Writes: src/ on feature branch <slug>-<feature>

5. Reviewer
   Reads:  code diff + Review Standards section of PROJECT_MANIFEST.md
   Writes: review-reports/<slug>-review.md

6. Deployer
   Reads:  Reviewer report + Release Criteria section of PROJECT_MANIFEST.md
   Writes: release-gates/<slug>-gate.md
Section 3 — Human Gates
Gate 1: After Architect — human approves ADR before Designer runs.
Gate 2: After Reviewer — human approves review report before Deployer runs.
Section 4 — Per-Agent System Prompt Seeds Use this template for each of the 6 agents:
"You are the {Agent} for {ProjectName}. You {role description} using
{relevant manifest sections} in PROJECT_MANIFEST.md."
Fill in:
  • {ProjectName}: from Section 1 (Overview) of the project manifest
  • {Agent}: Planner / Architect / Designer / Coder / Reviewer / Deployer
  • {role description}: appropriate to the agent's function
  • {relevant manifest sections}: the sections that agent reads
Each seed MUST contain the project name AND at least one domain entity name from Section 4 (Domain Model) of the project manifest. If the domain model is weak (labeled "weak"), add to each seed: 
(update with domain entities once Section 4 is strengthened)
.
Example seeds for "Fired Up Pizza":
Planner:   "You are the Planner for Fired Up Pizza. You decompose feature
           requests into work packages using the Domain Model and Tech Stack
           in PROJECT_MANIFEST.md."

Architect: "You are the Architect for Fired Up Pizza. You write architectural
           decision records using the Tech Stack and Constraints in
           PROJECT_MANIFEST.md."

Designer:  "You are the Designer for Fired Up Pizza. You write UX specs and
           interaction designs using the Domain Model and Conventions in
           PROJECT_MANIFEST.md."

Coder:     "You are the Coder for Fired Up Pizza. You implement features
           following the Conventions and Task Inputs in PROJECT_MANIFEST.md."

Reviewer:  "You are the Reviewer for Fired Up Pizza. You enforce the Review
           Standards in PROJECT_MANIFEST.md against every code diff."

Deployer:  "You are the Deployer for Fired Up Pizza. You gate releases against
           the Release Criteria in PROJECT_MANIFEST.md."
Section 5 — Quality Gates Copy the Review Standards and Release Criteria sections from the project manifest. Organize as: "Stage N passes when: [criteria]" for each of the 6 stages.
Section 6 — Orchestrator Configuration
Coordination pattern: sequential pipeline with handoffs
Failure handling: stop pipeline at failing agent, surface error to human
Retry policy: no automatic retries (human decides whether to re-run)
Branch strategy: feature branch per work item, merge after Deployer gate passes
Section 7 — Conventions Reference Copy verbatim from Section 5 (Conventions) of the project manifest.
使用已在上下文中的PROJECT_MANIFEST内容（Phase 5生成，或Phase 0恢复时读取），不得重新从磁盘读取。
填充SOFTWARE_FACTORY_MANIFEST的7个部分：
Section 1 — Factory Overview（工厂概述） 一段文字：项目名称 + "此工厂运行6-Agent顺序流水线..." + 从项目清单中提取的技术栈摘要。
Section 2 — Pipeline Sequence（流水线序列） 固定的6-Agent序列，使用项目名称（小写、短横线分隔）作为<slug>：
1. Planner（规划Agent）
   读取：需求请求 + PROJECT_MANIFEST.md
   写入：work-packages/<slug>.md

2. Architect（架构Agent）
   读取：Planner工作包 + PROJECT_MANIFEST.md的Tech Stack部分
   写入：docs/adr/NNNN-<slug>.md

3. Designer（设计Agent）
   读取：Architect架构决策记录（ADR） + PROJECT_MANIFEST.md的Domain Model部分
   写入：design/<slug>-spec.md

4. Coder（编码Agent）
   读取：Designer设计规范 + PROJECT_MANIFEST.md的Conventions部分
   写入：特性分支<slug>-<feature>下的src/

5. Reviewer（评审Agent）
   读取：代码差异 + PROJECT_MANIFEST.md的Review Standards部分
   写入：review-reports/<slug>-review.md

6. Deployer（部署Agent）
   读取：Reviewer评审报告 + PROJECT_MANIFEST.md的Release Criteria部分
   写入：release-gates/<slug>-gate.md
Section 3 — Human Gates（人工审核节点）
Gate 1：Architect之后 —— 人工批准ADR后，Designer才可运行。
Gate 2：Reviewer之后 —— 人工批准评审报告后，Deployer才可运行。
Section 4 — Per-Agent System Prompt Seeds（Agent系统提示词模板） 为6个Agent分别使用以下模板：
"您是{ProjectName}的{Agent}。您将使用PROJECT_MANIFEST.md中的{relevant manifest sections}来{role description}。"
填充内容：
  • {ProjectName}：来自项目清单的Section 1（Overview）
  • {Agent}：Planner / Architect / Designer / Coder / Reviewer / Deployer
  • {role description}：与Agent职能匹配的描述
  • {relevant manifest sections}：该Agent需要读取的清单部分
每个模板必须包含项目名称以及项目清单Section 4（Domain Model）中的至少一个领域实体名称。如果领域模型薄弱（标记为"weak"），在每个模板中添加：
(update with domain entities once Section 4 is strengthened)
（Section 4完善后，请更新领域实体）。
"Fired Up Pizza"项目的模板示例：
Planner:   "您是Fired Up Pizza的Planner。您将使用PROJECT_MANIFEST.md中的Domain Model和Tech Stack将需求请求分解为工作包。"

Architect: "您是Fired Up Pizza的Architect。您将使用PROJECT_MANIFEST.md中的Tech Stack和Constraints编写架构决策记录。"

Designer:  "您是Fired Up Pizza的Designer。您将使用PROJECT_MANIFEST.md中的Domain Model和Conventions编写UX规范和交互设计。"

Coder:     "您是Fired Up Pizza的Coder。您将遵循PROJECT_MANIFEST.md中的Conventions和Task Inputs实现功能。"

Reviewer:  "您是Fired Up Pizza的Reviewer。您将针对每个代码差异执行PROJECT_MANIFEST.md中的Review Standards。"

Deployer:  "您是Fired Up Pizza的Deployer。您将根据PROJECT_MANIFEST.md中的Release Criteria管控发布流程。"
Section 5 — Quality Gates（质量管控节点） 复制项目清单中的Review Standards和Release Criteria部分，整理为："Stage N通过条件：[标准]"，对应6个阶段。
Section 6 — Orchestrator Configuration（编排器配置）
协调模式：带交接的顺序流水线
故障处理：在失败的Agent处停止流水线，向人工反馈错误
重试策略：无自动重试（由人工决定是否重新运行）
分支策略：每个工作项对应一个特性分支，通过Deployer节点后合并
Section 7 — Conventions Reference（约定规范参考） 直接复制项目清单Section 5（Conventions）的内容。

Phase 7: Validate and Write

Phase 7：验证并写入

Validation checks before writing. Fix any failure by regenerating the section using in-context project manifest content.
  1. All 6 agents in Pipeline Sequence have non-empty Reads and Writes — PASS or fix.
  2. Gate 1 is after Architect, Gate 2 is after Reviewer (not Deployer) — PASS or fix.
  3. All 6 seeds contain the project name AND at least one domain entity — PASS or fix.
  4. Quality Gates section is non-empty and non-generic — PASS or fix.
Call FILE_WRITE_GUARD("SOFTWARE_FACTORY_MANIFEST.md").
Write 
SOFTWARE_FACTORY_MANIFEST.md
to the current directory.
Report: "SOFTWARE_FACTORY_MANIFEST.md written and validated. Both manifests ready — your 6-agent factory has context."
写入前执行验证检查，若验证失败则使用上下文项目清单内容重新生成对应部分。
  1. 流水线序列中的6个Agent均有非空的读取和写入内容 —— 通过或修复。
  2. Gate 1在Architect之后，Gate 2在Reviewer之后（而非Deployer） —— 通过或修复。
  3. 6个模板均包含项目名称以及至少一个领域实体 —— 通过或修复。
  4. Quality Gates部分非空且非通用内容 —— 通过或修复。
调用FILE_WRITE_GUARD("SOFTWARE_FACTORY_MANIFEST.md")。
将
SOFTWARE_FACTORY_MANIFEST.md
写入当前目录。
反馈："SOFTWARE_FACTORY_MANIFEST.md已写入并验证完成。两个清单均已就绪 —— 您的6-Agent工厂已具备运行上下文。"

PROJECT_MANIFEST Schema

PROJECT_MANIFEST Schema

Write the output file with exactly this structure. Fill every section.
# Project Manifest: [Project Name]

## Overview

[One paragraph: what the software does and who uses it.]

## Tech Stack

| Layer    | Technology | Notes |
|----------|-----------|-------|
| Frontend |           |       |
| Styling  |           |       |
| State    |           |       |
| Routing  |           |       |
| Backend  |           |       |
| Database |           |       |
| Testing  |           |       |
| Linting  |           |       |

## Project Structure

[Top-level directory tree, annotated. Label (proposed) if pre-code.]

## Domain Model

[Core entities, their fields, and their relationships.]

## Conventions

- File naming:
- Test files:
- API routes:
- Commits:
- Branches:

## Constraints

- [Explicit out-of-scope items or disallowed approaches.]

---

## Task Inputs

| Agent     | Receives                  | From                     |
|-----------|--------------------------|--------------------------|
| Planner   |                          |                          |
| Architect |                          |                          |
| Designer  |                          |                          |
| Coder     |                          |                          |
| Reviewer  |                          |                          |
| Deployer  |                          |                          |

## Services to Connect

| Service | Purpose | Config |
|---------|---------|--------|
|         |         |        |

## Success Criteria

### Per-Feature Success

- [ ]
- [ ]

### Factory-Level Success

- [ ]
- [ ]

---

## Review Standards

### Spec Compliance

- [Rules the Reviewer enforces against the Designer's spec.]

### Style

- [Project-specific style rules.]

### Security

- [Project-specific security rules.]

### Severity Scale

- **Low**: cosmetic issues, minor inconsistencies
- **Medium**: functional gaps, missing edge cases
- **High**: data loss, security vulnerability, spec violation

---

## Release Criteria

### Required (all must PASS)

1. [ ]
2. [ ]

### Informational (reported but non-blocking)

- [metric 1]
严格按照此结构写入输出文件，填充所有部分。
# Project Manifest: [项目名称]

## Overview（概述）

[一段文字：软件功能及目标用户。]

## Tech Stack（技术栈）

| Layer（层级）    | Technology（技术） | Notes（说明） |
|----------|-----------|-------|
| Frontend（前端） |           |       |
| Styling（样式）  |           |       |
| State（状态管理）    |           |       |
| Routing（路由）  |           |       |
| Backend（后端）  |           |       |
| Database（数据库） |           |       |
| Testing（测试）  |           |       |
| Linting（代码检查）  |           |       |

## Project Structure（项目结构）

[顶级目录树及注释。若未编码则标记(proposed)。]

## Domain Model（领域模型）

[核心实体、字段及关系。]

## Conventions（约定规范）

- 文件命名：
- 测试文件：
- API路由：
- 提交规范：
- 分支策略：

## Constraints（约束条件）

- [明确的范围外内容或禁用方案。]

---

## Task Inputs（任务输入）

| Agent（Agent）     | Receives（接收内容）                  | From（来源）                     |
|-----------|--------------------------|--------------------------|
| Planner   |                          |                          |
| Architect |                          |                          |
| Designer  |                          |                          |
| Coder     |                          |                          |
| Reviewer  |                          |                          |
| Deployer  |                          |                          |

## Services to Connect（待集成服务）

| Service（服务） | Purpose（用途） | Config（配置） |
|---------|---------|--------|
|         |         |        |

## Success Criteria（成功标准）

### Per-Feature Success（单功能成功标准）

- [ ]
- [ ]

### Factory-Level Success（工厂级成功标准）

- [ ]
- [ ]

---

## Review Standards（评审标准）

### Spec Compliance（规范符合性）

- [评审Agent针对Designer规范执行的规则。]

### Style（代码风格）

- [项目特定的风格规则。]

### Security（安全）

- [项目特定的安全规则。]

### Severity Scale（严重程度分级）

- **Low（低）**： cosmetic issues, minor inconsistencies（外观问题、轻微不一致）
- **Medium（中）**： functional gaps, missing edge cases（功能缺口、缺失边缘场景）
- **High（高）**： data loss, security vulnerability, spec violation（数据丢失、安全漏洞、违反规范）

---

## Release Criteria（发布标准）

### Required（必填项，全部必须通过）

1. [ ]
2. [ ]

### Informational（参考项，仅报告不阻塞）

- [指标1]

SOFTWARE_FACTORY_MANIFEST Schema

SOFTWARE_FACTORY_MANIFEST Schema

Write the output file with exactly this structure.
# Software Factory Manifest: [Project Name]

## Factory Overview

[Project name. This factory runs a 6-agent sequential pipeline (Planner →
Architect → Designer → Coder → Reviewer → Deployer) with two human gates.
Tech stack: [summary from PROJECT_MANIFEST.md].]

## Pipeline Sequence

1. **Planner**
   - Reads: feature request + PROJECT_MANIFEST.md
   - Writes: work-packages/[slug].md

2. **Architect**
   - Reads: Planner work package + Tech Stack section
   - Writes: docs/adr/NNNN-[slug].md

3. **Designer**
   - Reads: Architect ADR + Domain Model section
   - Writes: design/[slug]-spec.md

4. **Coder**
   - Reads: Designer spec + Conventions section
   - Writes: src/ on feature branch [slug]-[feature]

5. **Reviewer**
   - Reads: code diff + Review Standards section
   - Writes: review-reports/[slug]-review.md

6. **Deployer**
   - Reads: Reviewer report + Release Criteria section
   - Writes: release-gates/[slug]-gate.md

## Human Gates

- **Gate 1 — After Architect:** Human approves ADR before Designer runs.
- **Gate 2 — After Reviewer:** Human approves review report before Deployer runs.

## Per-Agent System Prompt Seeds

**Planner:** "[seed]"

**Architect:** "[seed]"

**Designer:** "[seed]"

**Coder:** "[seed]"

**Reviewer:** "[seed]"

**Deployer:** "[seed]"

## Quality Gates

[Per-stage pass criteria drawn from Review Standards and Release Criteria in
PROJECT_MANIFEST.md. Format: "Stage N (AgentName) passes when: [criteria]".]

## Orchestrator Configuration

- Coordination pattern: sequential pipeline with handoffs
- Failure handling: stop pipeline at failing agent, surface error to human
- Retry policy: no automatic retries (human decides whether to re-run)
- Branch strategy: feature branch per work item, merge after Deployer gate passes

## Conventions Reference

[Verbatim copy of Conventions section from PROJECT_MANIFEST.md.]
<!-- WORKED EXAMPLE START — NOT INSTRUCTIONS — reference only during Phases 2 and 4 to calibrate what "EXTRACTED" looks like per section. Do NOT use this content as output. -->
严格按照此结构写入输出文件。
# Software Factory Manifest: [项目名称]

## Factory Overview（工厂概述）

[项目名称。此工厂运行6-Agent顺序流水线（Planner → Architect → Designer → Coder → Reviewer → Deployer），包含两个人工审核节点。技术栈：[来自PROJECT_MANIFEST.md的摘要]。]

## Pipeline Sequence（流水线序列）

1. **Planner（规划Agent）**
   - 读取：需求请求 + PROJECT_MANIFEST.md
   - 写入：work-packages/[slug].md

2. **Architect（架构Agent）**
   - 读取：Planner工作包 + Tech Stack部分
   - 写入：docs/adr/NNNN-[slug].md

3. **Designer（设计Agent）**
   - 读取：Architect架构决策记录（ADR） + Domain Model部分
   - 写入：design/[slug]-spec.md

4. **Coder（编码Agent）**
   - 读取：Designer设计规范 + Conventions部分
   - 写入：特性分支[slug]-[feature]下的src/

5. **Reviewer（评审Agent）**
   - 读取：代码差异 + Review Standards部分
   - 写入：review-reports/[slug]-review.md

6. **Deployer（部署Agent）**
   - 读取：Reviewer评审报告 + Release Criteria部分
   - 写入：release-gates/[slug]-gate.md

## Human Gates（人工审核节点）

- **Gate 1 — Architect之后**：人工批准ADR后，Designer才可运行。
- **Gate 2 — Reviewer之后**：人工批准评审报告后，Deployer才可运行。

## Per-Agent System Prompt Seeds（Agent系统提示词模板）

**Planner:** "[模板内容]"

**Architect:** "[模板内容]"

**Designer:** "[模板内容]"

**Coder:** "[模板内容]"

**Reviewer:** "[模板内容]"

**Deployer:** "[模板内容]"

## Quality Gates（质量管控节点）

[来自PROJECT_MANIFEST.md中Review Standards和Release Criteria的阶段通过条件。格式："Stage N（AgentName）通过条件：[标准]"。]

## Orchestrator Configuration（编排器配置）

- 协调模式：带交接的顺序流水线
- 故障处理：在失败的Agent处停止流水线，向人工反馈错误
- 重试策略：无自动重试（由人工决定是否重新运行）
- 分支策略：每个工作项对应一个特性分支，通过Deployer节点后合并

## Conventions Reference（约定规范参考）

[直接复制PROJECT_MANIFEST.md中Conventions部分的内容。]
<!-- WORKED EXAMPLE START — 非指令内容 — 仅在Phase 2和4期间参考，校准"EXTRACTED"标准。不得将此内容作为输出使用。 -->

Worked Example: Fired Up Pizza

Worked Example: Fired Up Pizza

Input description

输入描述

Fired Up Pizza is a web app for a small neighborhood pizza restaurant. Customers browse the menu, customize pizzas (size, crust, toppings), place an order against their phone number, and track it through "placed → preparing → ready → delivered." Staff use the same app to manage menu items and advance order status as pizzas move through the kitchen. It replaces a phone-only workflow that loses orders and leaves customers in the dark.
Goals: customers can place and track an order without a phone call; staff can see every live order in one view and update status in one click; runs on a single machine with 
npm install && npm run dev
— no cloud setup.
Stack: React 18 + TypeScript + Vite; Tailwind; Node.js + Express REST API; SQLite via better-sqlite3; Vitest + React Testing Library.
Out of scope: online payments (pay at counter), SMS/push notifications, multi-location support, loyalty accounts.
Constraints: no external auth (phone-number identity), no external DB server, no real-time infra — polling is acceptable.
Users: Customer (places and tracks orders, identified by phone number); Staff (views live order queue, advances order status, edits menu items).
Fired Up Pizza是一款面向小型社区披萨店的Web应用。顾客可浏览菜单、定制披萨（尺寸、饼底、配料）、通过手机号下单，并跟踪订单状态（已下单 → 制作中 → 已就绪 → 已配送）。员工使用同一应用管理菜单菜品，并在披萨制作过程中更新订单状态。它取代了仅靠电话接单的工作流程，该流程容易丢失订单且无法让顾客了解进度。
目标：顾客无需打电话即可下单并跟踪订单；员工可在一个视图中查看所有实时订单并一键更新状态；只需
npm install && npm run dev
即可在单台机器上运行 —— 无需云配置。
技术栈：React 18 + TypeScript + Vite；Tailwind；Node.js + Express REST API；通过better-sqlite3操作SQLite；Vitest + React Testing Library。
范围外：在线支付（仅柜台支付）、短信/推送通知、多门店支持、会员账户。
约束条件：无外部认证（手机号作为身份标识）、无外部数据库服务器、无实时基础设施 —— 轮询方式可接受。
用户：Customer（顾客，下单并跟踪订单，通过手机号识别）；Staff（员工，查看实时订单队列、更新订单状态、编辑菜单菜品）。

What "EXTRACTED" looks like (annotated excerpts)

"EXTRACTED"标准示例（带注释节选）

Section 1 — Overview (EXTRACTED): Fired Up Pizza is a web app for a small neighborhood restaurant that lets customers browse the menu, customize and place orders by phone number, and track status through placed → preparing → ready → delivered. Staff view the live order queue and advance status. Replaces a phone-only workflow. [Good: project-named, specific actors, specific workflow described.]
Section 2 — Tech Stack (EXTRACTED): Frontend: React 18 + TypeScript + Vite | Styling: Tailwind CSS | Backend: Node.js + Express (REST) | Database: SQLite via better-sqlite3 (single-machine, no external server) | Testing: Vitest + React Testing Library [Good: named technologies with versions where available, notes on constraints.]
Section 4 — Domain Model (EXTRACTED): MenuItem: id, name, description, base_price, available (boolean) Order: id, phone_number, status (placed|preparing|ready|delivered), created_at OrderItem: id, order_id, menu_item_id, size, crust, toppings[], unit_price Customer: identified by phone_number (no account entity) Staff: role only, no separate entity needed [Good: named entities, key fields, relationships implied. This is what "EXTRACTED" looks like.]
Section 4 — Domain Model (PARTIAL): "The app manages orders and menu items for customers and staff." [Bad: entity names present (orders, menu items, customers, staff) but no fields, no relationships, no statuses. Would trigger a follow-up question.]
Section 6 — Constraints (EXTRACTED):
  • No online payments (pay at counter only)
  • No SMS or push notifications
  • No multi-location support
  • No external auth — identity is phone number only
  • No external DB server — SQLite, single machine
  • Polling acceptable (no real-time infra needed) [Good: explicit, enumerated, actionable.]
Section 9 — Success Criteria (EXTRACTED): Per-Feature: customer places order without phone call; customer tracks through 4 status stages; staff sees all live orders in one view; staff advances status in one click; staff edits menu items. Factory-Level: app starts with npm install && npm run dev; all tests pass on clean checkout. [Good: specific, testable, includes factory-level criteria.]
<!-- WORKED EXAMPLE END -->
Section 1 — Overview（概述）（EXTRACTED）： Fired Up Pizza是一款面向小型社区披萨店的Web应用，顾客可浏览菜单、定制并通过手机号下单，跟踪订单状态从已下单到已配送的全流程。员工可查看实时订单队列并更新状态。它取代了仅靠电话接单的工作流程。 [优秀：包含项目名称、具体角色、具体工作流程描述。]
Section 2 — Tech Stack（技术栈）（EXTRACTED）： Frontend：React 18 + TypeScript + Vite | Styling：Tailwind CSS | Backend：Node.js + Express（REST） | Database：SQLite via better-sqlite3（单台机器，无外部服务器） | Testing：Vitest + React Testing Library [优秀：包含具体技术名称及版本（如有），并标注约束条件。]
Section 4 — Domain Model（领域模型）（EXTRACTED）： MenuItem: id, name, description, base_price, available（布尔值） Order: id, phone_number, status（placed|preparing|ready|delivered）, created_at OrderItem: id, order_id, menu_item_id, size, crust, toppings[], unit_price Customer: 通过phone_number识别（无账户实体） Staff: 仅角色，无需单独实体 [优秀：包含命名实体、关键字段、隐含关系。这就是"EXTRACTED"的标准。]
Section 4 — Domain Model（领域模型）（PARTIAL）： "该应用为顾客和员工管理订单和菜单菜品。" [不合格：存在实体名称（订单、菜单菜品、顾客、员工）但无字段、无关系、无状态。会触发跟进问题。]
Section 6 — Constraints（约束条件）（EXTRACTED）：
  • 无在线支付（仅柜台支付）
  • 无短信或推送通知
  • 无多门店支持
  • 无外部认证 —— 仅以手机号作为身份标识
  • 无外部数据库服务器 —— 使用SQLite，单台机器
  • 可接受轮询方式（无需实时基础设施） [优秀：明确、可枚举、可执行。]
Section 9 — Success Criteria（成功标准）（EXTRACTED）： 单功能：顾客无需打电话即可下单；顾客可跟踪4个状态阶段；员工可在一个视图中查看所有实时订单；员工可一键更新状态；员工可编辑菜单菜品。 工厂级：应用可通过npm install && npm run dev启动；全新检出代码后所有测试通过。 [优秀：具体、可测试、包含工厂级标准。]
<!-- WORKED EXAMPLE END -->