refactor(change-author): 收紧按 schema 模板的详细文档编写

Author: sincerely90

README.en.md

@@ -69,7 +69,7 @@ Aisee makes that context explicit:
 
 - clarify business requirements or establish an existing-system baseline before implementation;
 - separate setup, baseline migration, change planning, and detailed change authoring;
-- create and complete OpenSpec changes while working from the current project schema or official `spec-driven`;
+- create and complete OpenSpec changes while working from the schema bound to the current change;
 - keep OpenSpec as the only persistent specification source of truth;
 - expose durable project memory and team knowledge guardrails without replacing OpenSpec facts;
 - constrain document-local numbering through skills/templates to reduce invented or duplicated labels;
@@ -146,7 +146,7 @@ Legacy / transitional:
 - **Existing-project baseline migration**: `aisee:spec-migrate` derives current system behavior into OpenSpec baseline specs before brownfield enhancement work starts.
 - **Structured requirement clarification**: `aisee:srs` clarifies business needs through dialogue and produces the inputs needed for change planning.
 - **OpenSpec change planning**: `aisee:change-plan` maps confirmed inputs into independently deliverable OpenSpec changes.
-- **Detailed change authoring**: `aisee:change-author` strengthens OpenSpec change content so proposal, specs, design, and tasks are more actionable.
+- **Detailed change authoring**: `aisee:change-author` fills out a single OpenSpec change document set in detail from the current schema templates, then strengthens the result with clearer boundaries, risks, verification, and implementation sequencing.
 - **Project memory**: `aisee memory` retrieves and writes current-repository long-lived guidance without replacing OpenSpec facts.
 - **Team knowledge guardrails**: `aisee knowledge` retrieves a small number of reviewed engineering lessons through pack/card protocols without turning the knowledge repository into a second specification source.
 - **Controlled memory and knowledge retrieval**: `aisee memory` and `aisee knowledge` provide direct retrieval entrypoints without becoming workflow authority.
@@ -339,7 +339,7 @@ For existing projects or brownfield enhancement work, use `aisee:spec-migrate` t
 | `aisee:spec-migrate` | Build OpenSpec baseline specs for existing projects or brownfield enhancement work. |
 | `aisee:srs` | Clarify software requirements and produce the inputs needed for change planning. |
 | `aisee:change-plan` | Plan independent OpenSpec changes and prepare `/opsx:new` inputs. |
-| `aisee:change-author` | Strengthen the current OpenSpec change so proposal/specs/design/tasks are more actionable. |
+| `aisee:change-author` | Generate and refine a single change's documents from the current schema templates, then strengthen them with clearer boundaries, risks, verification, and implementation sequencing. |
 | `aisee:memory` | Guide project memory CLI inspect/search/add/update-index usage. |
 | `aisee:knowledge` | Guide team knowledge CLI initialization, configuration, sync, retrieval, and promote workflows. |
 | `aisee:knowledge-curate` | Batch-review project-local reusable knowledge candidates and produce card drafts for human submission to team knowledge. |

README.md

@@ -69,7 +69,7 @@ Aisee 的目标是让这些上下文显式化：
 
 - 在实现前澄清业务需求或补齐已有系统 baseline；
 - 把已有项目接入、baseline 迁移、change planning 和 change authoring 明确分层；
-- 创建和补齐 OpenSpec changes，并优先围绕项目当前 schema 或官方 `spec-driven` 工作；
+- 创建和补齐 OpenSpec changes，并按当前 change 绑定的 schema 工作；
 - 保持 OpenSpec 作为唯一持久规范事实源；
 - 用 skill/template 约束文档内编号，减少临时发明和重复命名；
 - 检查 artifacts、tasks、source-map、测试和 review evidence 是否闭环。
@@ -145,7 +145,7 @@ legacy / transitional：
 - **已有项目 baseline 迁移**：`aisee:spec-migrate` 反向整理现有系统当前行为，帮助已有项目先建立 OpenSpec baseline specs。
 - **结构化需求澄清**：`aisee:srs` 通过对话澄清业务需求，并生成 change planning 所需需求输入。
 - **OpenSpec change planning**：`aisee:change-plan` 将已确认输入映射为可独立交付的 OpenSpec changes。
-- **Detailed change authoring**：`aisee:change-author` 细化 OpenSpec change 内容，强化 proposal、specs、design、tasks 的可实现性。
+- **Detailed change authoring**：`aisee:change-author` 按当前 schema 的模板详细补齐单个 OpenSpec change 文档，并在模板基础上补强边界、风险、验证和实施顺序。
 - **项目记忆**：`aisee memory` 受控检索和写入当前仓库长期 guidance，不替代 OpenSpec 事实源。
 - **团队知识 Guardrails**：`aisee knowledge` 基于 pack/card 协议按需检索少量已审查工程经验，不把知识库变成第二份规范事实源。
 - **受控记忆与知识检索**：`aisee memory` 与 `aisee knowledge` 直接提供项目记忆和团队 guardrails 查询，不升级为 workflow authority。
@@ -338,7 +338,7 @@ quick-fix / quick-research / 其它轻量 schema
 | `aisee:spec-migrate` | 为已有项目或二开场景整理 OpenSpec baseline specs。 |
 | `aisee:srs` | 澄清软件需求并生成 change planning 所需需求输入。 |
 | `aisee:change-plan` | 规划独立 OpenSpec changes，并为 `/opsx:new` 提供范围和 schema 建议。 |
-| `aisee:change-author` | 细化当前 OpenSpec change 内容，强化 proposal/specs/design/tasks 的可实现性。 |
+| `aisee:change-author` | 按当前 schema 的模板详细生成和补全单个 change 文档，并在模板基础上补强边界、风险、验证和实施顺序。 |
 | `aisee:memory` | 引导项目记忆 CLI 的 inspect/search/add/update-index 使用。 |
 | `aisee:knowledge` | 引导团队知识 CLI 的初始化、配置、同步、检索和 promote 流程。 |
 | `aisee:knowledge-curate` | 批量审查项目内 reusable knowledge candidates，产出可人工提交到 team knowledge 的 card drafts。 |

docs/architecture/aisee-harness-design.md

@@ -109,6 +109,15 @@ Skill eval 文件应使用下面的结构，同时保留 `prompt` 和 `expected_
       "fact_source_constraints": [
         "避免平行事实源或不受支持来源的规则。"
       ],
+      "template_checks": [
+        "输出必须遵循当前 schema 模板和 instruction，而不是自创文档结构。"
+      ],
+      "strengthening_checks": [
+        "在模板骨架基础上补强必要的边界、风险、验证或实施细节。"
+      ],
+      "consistency_checks": [
+        "多个文档或多个章节之间的术语、范围和验证口径必须一致。"
+      ],
       "files": []
     }
   ]
@@ -124,6 +133,9 @@ Skill eval 文件应使用下面的结构，同时保留 `prompt` 和 `expected_
 - 当场景包含范围、业务规则、架构、平台、证据或迁移决策缺口时，必须填写 `must_ask`。
 - `must_not` 必须覆盖该 skill 最容易越界的 artifact 或行为。
 - `fact_source_constraints` 应在相关场景中说明 OpenSpec、Aisee docs、ID registry、source-map 或 CLI JSON 的边界。
+- `template_checks` 是可选字段，用于检查输出是否真正以 schema 模板 / instruction 为基础，而不是绕开模板重新组织。
+- `strengthening_checks` 是可选字段，用于检查 skill 是否在模板基础上补强了必要信息，而不是机械填空。
+- `consistency_checks` 是可选字段，用于检查多文档或多章节之间是否保持一致。
 
 ## Runner 策略
 
@@ -138,7 +150,7 @@ Skill eval 文件应使用下面的结构，同时保留 `prompt` 和 `expected_
 后续可选：
 
 1. 增加小型 eval linter，检查必填字段和稳定 ID。
-2. 可选增加模型评分，检查 `expected_outputs`、`must_include` 和 `must_not`。
+2. 可选增加模型评分，检查 `expected_outputs`、`must_include`、`must_not`，以及存在时的 `template_checks`、`strengthening_checks`、`consistency_checks`。
 3. 模型评分只作为审查建议，不能写项目事实，也不能批准 archive。
 
 ## 归属
@@ -147,4 +159,3 @@ Skill eval 文件应使用下面的结构，同时保留 `prompt` 和 `expected_
 - Skill eval harness：`skills/<skill>/evals/`。
 - Workflow scenario harness：未来的 `tests/fixtures/projects/`。
 - Harness 设计：本文档。
-

docs/workflow.en.md

@@ -68,7 +68,7 @@ Artifact roles:
 | --- | --- | --- |
 | SRS | Clarifies business goals, scope, functional requirements, non-functional requirements, and acceptance criteria | Does not write implementation tasks |
 | Change Plan | Maps confirmed inputs into one or more OpenSpec changes | Does not write change artifact bodies directly |
-| Change Author | Strengthens the current change's `proposal`, `specs`, `design`, and `tasks` | Does not write implementation code |
+| Change Author | Fills out the current change's schema-defined documents in detail and strengthens them with clearer boundaries, risks, verification, and implementation sequencing | Does not write implementation code |
 
 These documents are planning docs for the current version or iteration. They are planning inputs, not OpenSpec baseline facts.
 
@@ -95,24 +95,27 @@ Splitting rules:
 
 ## 3. Change Creation And Authoring
 
-After creating a change, use `aisee:change-author` to complete artifacts according to the schema artifact DAG.
+After creating a change, use `aisee:change-author` to fill out the current schema's documents in detail. Preserve the template structure first, then strengthen the parts most likely to cause implementation, review, or verification mistakes.
 
 Typical commands:
 
 ```bash
 /opsx:new "<change>" --schema <project-schema-or-spec-driven>
 openspec validate <change>
 ```
-service-contract.md      # as needed
-data-model.md            # as needed
-```
 
-`source-map.md` decides whether as-needed artifacts are required:
+Common as-needed document examples:
+
+- `service-contract.md`
+- `data-model.md`
+
+Current rules:
 
-- Required=yes: expand the artifact.
-- Required=no: provide a concrete N/A reason.
-- Do not generate unrelated contracts for completeness.
-- Use `Ref` / `Refs` for source references in upstream tables; use document-local numbers for new objects created inside the current change.
+- Only write documents declared by the current schema; do not invent undeclared files.
+- Templates are the starting skeleton, not the completion condition; each document should strengthen the needed boundaries, exceptions, risks, verification details, or implementation handoff.
+- Required=yes documents must be expanded; Required=no documents must provide a concrete N/A reason.
+- Do not generate unrelated contracts or helper docs for completeness.
+- If a schema still declares `source-map.md`, treat it as an ordinary schema document and fill it according to its template; do not make it the center of the whole authoring phase.
 
 ## 4. Implementation Handoff
 
@@ -156,8 +159,8 @@ Read-only Aisee reviewer lens timing:
 | Reviewer | When to trigger | Purpose |
 | --- | --- | --- |
 | `aisee-change-architect` | After `aisee:change-plan` and before `aisee:change-author` when the change has complex boundaries, cross-module or cross-schema impact, unclear dependencies, or uncertain granularity | Review change boundaries, dependencies, granularity, and independent deliverability |
-| `aisee-spec-reviewer` | After `aisee:change-author` and before implementation | Review whether artifacts, contracts, source-map, and tasks are complete, consistent, and verifiable |
-| `aisee-implementation-reviewer` | After `ce-work` | Compare implementation, tasks, specs/source-map, and evidence for drift |
+| `aisee-spec-reviewer` | After `aisee:change-author` and before implementation | Review whether the current schema documents, N/A reasons, tasks, and verification posture are complete, consistent, and verifiable |
+| `aisee-implementation-reviewer` | After `ce-work` | Compare implementation, the current schema documents, tasks, and evidence for drift |
 
 These reviewers only return structured review conclusions. They do not edit code, run tests, submit PRs, or replace `ce-doc-review`, `ce-code-review`, `ce-test-*`, or `ce-work`. Interface, UI, hardware, firmware, security, and verification differences should remain schema-aware check lenses rather than new all-purpose agents.
 

docs/workflow.md

@@ -67,7 +67,7 @@ aisee:srs
 | --- | --- | --- |
 | SRS | 澄清业务目标、范围、功能需求、非功能需求和验收标准 | 不写实现任务 |
 | Change Plan | 把已确认输入映射为一个或多个 OpenSpec changes | 不直接写 change artifact 正文 |
-| Change Author | 细化当前 change 的 `proposal`、`specs`、`design`、`tasks` 等内容 | 不写实现代码 |
+| Change Author | 按当前 schema 模板详细补齐当前 change 的各项文档，并在模板基础上补强边界、风险、验证和实施顺序 | 不写实现代码 |
 
 这些前置文档是当前版本 / 迭代的 planning docs，是 change planning 的输入，不是 OpenSpec baseline。
 
@@ -94,24 +94,27 @@ aisee:change-plan
 
 ## 3. Change 创建与 Authoring
 
-创建 change 后，用 `aisee:change-author` 按 schema artifact DAG 补齐文档。
+创建 change 后，用 `aisee:change-author` 按当前 schema 模板详细补齐文档。先保留模板结构，再补强当前 change 最容易导致实现、评审或验证出错的信息。
 
 典型命令：
 
 ```bash
 /opsx:new "<change>" --schema <project-schema-or-spec-driven>
 openspec validate <change>
 ```
-service-contract.md      # 按需
-data-model.md            # 按需
-```
 
-`source-map.md` 决定按需 artifacts 是否 Required：
+常见的按需文档示例：
+
+- `service-contract.md`
+- `data-model.md`
+
+当前规则：
 
-- Required=yes：必须展开对应 artifact。
-- Required=no：必须写清楚 N/A 原因。
-- 不要为了“完整”强行生成与当前 change 无关的 contract。
-- Upstream Sources / Trace 表记录来源 `Ref` / `Refs`；当前 change 内新对象使用文档内编号。
+- 只写当前 schema 声明的文档，不补未声明文件。
+- 模板是基础骨架，不是完成条件；每个文档都应补强边界、例外、风险、验证或实施衔接中的必要内容。
+- Required=yes 的文档必须展开；Required=no 的文档必须写清楚 N/A 原因。
+- 不要为了“完整”强行生成与当前 change 无关的 contract 或辅助文档。
+- 如果某个 schema 仍声明 `source-map.md`，把它当成该 schema 的普通文档按模板补齐，不把它当成整个 authoring 阶段的中心。
 
 ## 4. 实现交接
 
@@ -155,8 +158,8 @@ Knowledge matches 只作为提醒，不改变当前 change 的规范事实源，
 | Reviewer | 触发时机 | 用途 |
 | --- | --- | --- |
 | `aisee-change-architect` | `aisee:change-plan` 后、`aisee:change-author` 前按需触发；仅用于边界复杂、跨模块、跨 schema、依赖不清或粒度不确定的 change | 审查 change 边界、依赖、粒度和可独立交付性 |
-| `aisee-spec-reviewer` | `aisee:change-author` 后、进入实现前建议触发 | 审查 artifacts、contracts、source-map、tasks 是否完整、一致、可验证 |
-| `aisee-implementation-reviewer` | `ce-work` 完成后建议触发 | 比对实现、tasks、spec/source-map 和 evidence 是否一致 |
+| `aisee-spec-reviewer` | `aisee:change-author` 后、进入实现前建议触发 | 审查当前 schema 文档、N/A 理由、tasks 和验证口径是否完整、一致、可验证 |
+| `aisee-implementation-reviewer` | `ce-work` 完成后建议触发 | 比对实现、当前 schema 文档、tasks 和 evidence 是否一致 |
 
 这些 reviewer 只输出结构化审查结论，不改代码、不跑测试、不提交 PR，也不替代 `ce-doc-review`、`ce-code-review`、`ce-test-*` 或 `ce-work`。接口、UI、硬件、固件、安全和验证差异应作为 schema-aware check lenses，而不是新增独立全能 agent。