aep-workflow-feedback

工作流反馈

一种可复用的模式，用于在下游项目中记录工作流观察，并将其反馈到上游，以改进 AEP 技能和文档。

两种模式：

• 记录 — 在构建完成后，于下游项目中运行，以标准化观察结果。
• 审查 — 在 AEP 仓库中运行，从下游项目收集并分流上游候选项。

DOWNSTREAM PROJECT                           AEP REPO
━━━━━━━━━━━━━━━━━━                           ━━━━━━━━
/aep-build → lessons.md                          /aep-workflow-feedback review
/aep-wrap  → lessons-learned/                      ↓
/aep-workflow-feedback capture                   Read .aep/config.yaml
  ↓                                            ↓
.dev-workflow/feedback.md  ──────────────→   Route to docs/
  (standardized + classified)                  ↓
                                             Human approves
                                               ↓
                                             tag release → re-pin downstreams ──→ updated skills flow back

**会话：**主会话，与用户交互。

**严格护栏 — 此技能绝不编辑 AEP 技能文件。**在任一模式中，都应在反馈/经验文件中提出修订建议；由人工通过有意执行重新固定来应用这些修订。

---

模式 1：记录

在完成一个层、一批故事或一次自动驾驶运行后，于下游项目中运行。目标是将原始观察整理为 AEP 可审查的格式。

步骤 1 — 收集来源

从所有可用来源收集观察结果，包括 AEP 技能/流程的表现，不仅限于产品 Bug（产品特定的 Bug 应转到 /aep-reflect → 创建故事，不在此处处理）：

1. 已归档经验：lessons-learned/*.md（由 /aep-wrap 编写）
2. 流程经验：lessons-learned/process/*.md（来自 /aep-reflect）
3. 尚未归档的工作区经验：.feature-workspaces/*/dev-workflow/lessons.md（如果工作区尚未完成归档）
4. **用户观察：**询问用户在本次运行中注意到了什么，且上述来源尚未记录。

后置条件：每条用户观察都已记录在反馈文件中（步骤 3），或者用户明确确认没有观察结果。

步骤 2 — 对每条观察进行分类

为每条观察指定分类：

分类	描述	是否上游？
process	AEP 工作流改进 — 应更改技能、阶段或关卡	是
tech-stack	特定于技术栈的注意事项 — 适用于任何使用该技术的项目	是
discovery	对产品领域或架构的新认识	可能
project-local	仅适用于此项目的代码库，无法泛化	否

仅当某条内容能让其他使用 AEP 的项目受益时，才将其标记为 upstream_candidate: yes。后置条件：每条观察都带有分类。

步骤 3 — 编写标准化反馈

写入 .dev-workflow/feedback.md：

# Workflow Feedback: <project> <layer/context>

Date: YYYY-MM-DD
Project: <name>
Layer: <layer>
Stories: <count>

## Observations

### <title>

- **Classification:** process | tech-stack | discovery | project-local
- **Skill affected:** /aep-calibrate, /aep-build, /aep-autopilot, etc. (if applicable)
- **Technology:** Rust, Cloudflare, etc. (if tech-stack)
- **Observation:** <what happened>
- **Recommendation:** <proposed change>
- **Upstream candidate:** yes | no

后置条件：.dev-workflow/feedback.md 存在，且每条收集到的观察都有一个 Observations 条目。

步骤 4 — 提交

将 .dev-workflow/feedback.md 提交到下游项目，以便 AEP 审查模式使用。后置条件：git status 显示 .dev-workflow/feedback.md 已提交。

---

模式 2：审查

在 AEP 仓库中运行，从下游项目收集反馈，并将其分流至 AEP 文档。

步骤 1 — 扫描下游项目

读取 .aep/config.yaml，查找已注册的下游项目路径。对每个项目：

1. 检查是否存在 .dev-workflow/feedback.md（来自记录模式的标准化反馈）。
2. 如果不存在 feedback.md，检查 lessons-learned/**/*.md（构建产生的原始经验）——反馈可能不完整，因此如存在这些文件，应直接读取。

如果下游项目没有反馈文件，记录这一情况并继续。后置条件：每个已注册的下游项目都已扫描，或已注明没有反馈。

步骤 2 — 筛选上游候选项

提取符合以下条件的观察：

• 标记为 upstream_candidate: yes，或
• 分类为 process 或 tech-stack（几乎总是与上游相关），或
• 仅当 discovery 揭示了适用于多个项目的模式时，才提取此类观察。

只有在人工明确要求时，才提取 project-local 条目。

Step 3 — 路由条目

对于每个上游候选项，确定其目标位置，并注明 process 观察会影响哪些 AEP 技能：

分类	目标位置	格式
process	docs/lessons/YYYY-MM-DD-<project>-<context>.md	带日期前缀的经验总结，附技能修订说明
tech-stack	docs/tech-stack/<technology>-<topic>.md	独立的技术注意事项文档
discovery	提交人工决策	可存入 docs/decisions/ 或 docs/workflow/

Step 4 — 提交摘要

向人工展示包含所有上游候选项（包括次要项）及建议路由方式的表格：

| # | Source | Classification | Title | Proposed destination |
|---|--------|---------------|-------|---------------------|
| 1 | <project> | process | /aep-calibrate should modify real components | docs/lessons/... |
| 2 | <project> | tech-stack | Rust keyring needs platform features | docs/tech-stack/... |

人工批准、修改或拒绝每个条目。

Step 5 — 写入已批准的条目

对于每个已批准的条目，按照 docs/README.md 中的约定创建目标文件。根据上述硬性防护规则，在经验总结/决策文件中记录建议的技能修订，供人工应用。

写入后，提醒人工：已批准的技能改进只有通过有意重新固定版本，才能传递到下游项目：创建新的 AEP 发布标签，然后按照 README 中的“升级到新版本”流程，重新固定 .aep/config.yaml 中注册的每个下游项目。后置条件：每个已批准的条目都已作为文件存放在 docs/ 下。

---

何时使用此技能

情况	模式
刚完成下游项目中的一个层	捕获
Autopilot 运行已完成，想要记录经验教训	捕获
/aep-reflect 识别出流程观察	捕获
需要审查下游项目的学习成果	审查
准备发布包含累积改进的 AEP 版本	审查

与相邻技能的关系：/aep-reflect 对_产品_反馈（错误、改进、发现、润色）进行分类；此技能处理它发现但未向上游路由的_流程_和_技术栈_观察。/aep-wrap 将工作区经验归档到 lessons-learned/，而 /aep-build 将原始观察写入 .dev-workflow/lessons.md——捕获模式会读取这两个文件。/aep-autopilot 的 orchestration-learning.md 会记录跨工作区的元模式，供审查模式向上游提取。