Hermes Kanban 多 Agent 对接飞书生产实践指南
适用目录：/home/fd/.hermes
当前版本：2026-05-19
适用场景：用 Hermes Kanban 编排 prod-main、prod-prd、prod-architect、prod-coder、prod-tester，通过飞书作为用户入口、当前负责 agent 交互层和状态展示层，完成从需求输入、PRD、设计、实现、验收、交付完成通知到用户决策返工的生产链路。
安全原则：任何 API Key、App Secret、Token、Cookie、访问票据、真实密钥都不能写入 Kanban 任务、评论、结果、metadata、日志、飞书消息或本文档。
1. 核心结论
Hermes 生产链路不是让多个机器人在飞书里互相 @ 来猜下一步，而是把 Kanban DB 作为唯一事实源和状态机。
当前生产链路采用轻量 Manual SDD / Spec Lite：PRD、设计、数据库 DDL、API 设计、实现 handoff、测试报告是人和 Agent 的共同协议。OpenSpec / GitHub Spec Kit 只作为思想参考，不作为默认运行依赖。
当前生产链路：
用户 / 飞书群
-> prod-main 接收需求、原型图、文件路径、业务输入
-> prod-main 在 prod board 创建 prod-prd PRD 任务
-> prod-prd 写可执行 PRD，并创建 prod-architect child task
-> prod-architect 写技术设计，必要时通过 Architecture Approval Gate 确认技术栈/架构/数据库/API，再创建 prod-coder child task
-> prod-coder 通过 Windows Codex CLI 完成主要代码实现，自测后 review-required block
-> monitor 识别 review-required，创建独立 prod-tester implementation-review task
-> prod-tester 使用 Windows Chrome MCP 做真实用户路径验收
-> prod-tester pass 则 comment source coder 并 unblock；fail 则 block tester 写缺陷
-> prod-coder 被 unblock 后 complete
-> monitor 发送交付完成通知，不创建 prod-main review task
-> 用户自行验收；如需返工或恢复，可直接 @ 当前负责 agent 或 @prod-main 手动路由
一句话分层：
Feishu = 用户与当前负责 agent 的交互层 + 状态展示
Kanban = 调度事实源 + 状态机
Agent = 分角色执行
Monitor = 事件通知 + PRD/设计审批通知 + tester review 创建器
Codex = prod-coder 的代码实现工具
Chrome MCP = prod-tester 的浏览器验收工具
2. 控制面目录
关键目录和文件：
/home/fd/.hermes
├── AGENTS.md
├── MULTI_AGENT_ROUTER.md
├── MULTI_AGENT_WORKFLOW.md
├── HERMES_KANBAN_MULTI_AGENT_FEISHU_ULTIMATE_GUIDE.md
├── kanban_feishu_monitor_prod.yaml
├── kanban/boards/prod/kanban.db
├── scripts/
│ ├── restart_prod_stack.sh
│ ├── kanban_feishu_monitor.py
│ └── codex_windows_exec.sh
├── team/
│ ├── workflows/prod-dev.yaml
│ └── handoffs/*.md
└── profiles/
├── prod-main/
├── prod-prd/
├── prod-architect/
├── prod-coder/
└── prod-tester/
职责边界：
AGENTS.md：全局生产规则。
MULTI_AGENT_ROUTER.md：跨 Agent 路由、正常路径、异常路径。
team/workflows/prod-dev.yaml：机器可读工作流合同。
team/handoffs/*.md：上下游任务 body / summary 模板。
profiles/prod-*/AGENTS.md：每个生产角色的硬规则。
profiles/prod-*/SOUL.md：角色身份、语气、沟通风格，不负责调度行为。
kanban_feishu_monitor_prod.yaml：monitor 监听、飞书通知、review task 创建配置。
scripts/restart_prod_stack.sh：生产栈统一重启入口。
scripts/codex_windows_exec.sh：prod-coder 调 Windows Codex CLI 的唯一生产 wrapper。
当 SOUL.md 与 AGENTS.md / MULTI_AGENT_ROUTER.md / prod-dev.yaml 冲突时，以后者为准。
2.1 Manual SDD / Spec Lite
Hermes 不默认引入 OpenSpec / GitHub Spec Kit，也不要求每个项目初始化外部 SDD 目录。默认方案是把 SDD 思想嵌入现有五角色链路：
prod-main 锁定意图、范围、授权、技术偏好和成功标准
prod-prd 输出 Requirement Spec / docs/PRD.md
prod-architect 输出 Implementation Spec / docs/DESIGN.md + 条件设计文件
prod-coder 按规格实现，提交 Spec Trace / Acceptance Trace
prod-tester 按验收矩阵和设计契约验收，失败输出 defect contract
硬原则：
Spec as Source of Truth：PRD、Design、DDL、API Design、Test Plan、handoff、TEST_REPORT 是共同事实源。
Gate Before Handoff：每个角色满足门禁后才能交给下游。
Spec Trace：每个验收项必须能追踪到设计、实现、自测和测试报告。
No Guessing：需求、代码现状、PRD、设计冲突时必须 block 或请求澄清。
Record Decisions：技术栈、数据库、架构、API、风险取舍、人工确认必须留痕。
2.2 Architecture Approval Gate
架构确认点放在 prod-architect -> prod-coder 之间。太早确认技术细节信息不足，太晚到 coder 再确认返工成本高。
必须确认：
可跳过确认：
已有项目内的小 bugfix、样式小改、文案调整、局部修复。
不改变技术栈、架构、API、数据库、schema、部署。
prod-architect 在设计中写明 approval_required: false 和原因。
需要确认时，prod-architect 先写设计草案，再 block：
error_type: design-approval
summary:
attempted:
recommended_next_action:
用户确认后，prod-architect 才能创建 exactly one prod-coder child task。
2.3 数据库设计标准
涉及持久化、结构化后端数据、schema、seed/demo 数据时，必须先确定数据库引擎和 SQL 规范来源：
docs/DATABASE_DESIGN.md
docs/DATABASE_DDL.sql
优先级：
existing project convention > explicit user requirement > approved architecture decision > documented default profile
docs/DATABASE_DDL.sql 必须按已确认的数据库 profile 生成。MySQL 8.x 只是可选 profile，不是全局默认；Oracle、PostgreSQL 或项目自定义 SQL 规范必须在设计中显式记录。
数据库设计必须包含表关系、表清单、字段、主键、唯一约束、索引、外键或逻辑关系、状态枚举、时间字段、软删除策略、初始化数据、迁移/兼容说明。已有项目如果明确使用某种数据库，prod-architect 不得静默切换，必须走 design-approval。
3. 生产角色
生产 assignee 只允许：
prod-main
prod-prd
prod-architect
prod-coder
prod-tester
角色职责：
| Profile | 职责 | 允许创建下游任务 | 关键产物 |
| — | — | — | — |
| prod-main | 飞书入口、需求澄清、PRD task 创建、用户主动请求时的手动路由 | 正常路径只创建 prod-prd | PRD task、手动路由结论 |
| prod-prd | 写可执行 PRD、页面清单、验收矩阵 | 必须创建 exactly one prod-architect child | docs/PRD.md |
| prod-architect | 写技术设计、确认技术栈/架构/数据库/API、接口/数据/视觉/测试策略 | 通过必要确认后创建 exactly one prod-coder child | docs/DESIGN.md 及条件设计文件 |
| prod-coder | 调 Windows Codex CLI 实现、自测、review-required handoff | 不创建 tester | 代码变更、自测证据、handoff comment |
| prod-tester | 实现验收、真实浏览器测试、缺陷报告 | 不创建修复或 review task | docs/TEST_REPORT.md |
4. Board 和命令硬规则
所有生产 Kanban 命令必须显式使用：
hermes kanban --board prod ...
不要在生产链路里使用 default board。
生产任务 body 应以 Workflow Header frontmatter 开头：
---
workflow_id: prod-dev
workflow_version: 2
stage: prd
root_task_id:
source_task_id:
workspace: dir:/home/fd/projects/example
contract: /home/fd/.hermes/team/workflows/prod-dev.yaml
---
常用 stage：
prd
architect
coder
implementation-review
manual-routing
5. 正常路径
5.1 prod-main
prod-main 是生产入口。
必须做：
禁止做：
PRD task 需要包含：
user_request
workspace
authorization
expected_result
prototype_inventory
unresolved_images
prototype_reference_pack
acceptance_criteria
visual_acceptance_criteria
required_workspace_artifacts
router
5.2 prod-prd
prod-prd 必须写：
docs/PRD.md
PRD 应覆盖：
背景
目标
功能范围
非目标范围
页面原型映射
用户故事
页面清单
可执行验收矩阵
验收标准
视觉验收标准
测试要求
安全边界
完成 PRD 后，prod-prd 必须创建 exactly one prod-architect child task：
hermes kanban --board prod create \
--assignee prod-architect \
--parent <prd_task_id> \
--workspace <workspace> \
--title "设计：<title>" \
--body-file <architect_task_body.md>
PRD 缺少可执行验收矩阵时，后续 coder/tester 会变成靠猜，生产链路会变慢。
5.3 prod-architect
prod-architect 必须写：
docs/DESIGN.md
按需写：
docs/DATABASE_DESIGN.md
docs/API_DESIGN.md
docs/VISUAL_SPEC.md
docs/TEST_PLAN.md
触发条件：
持久化/表/seed/demo 数据变化：写 DATABASE_DESIGN.md。
HTTP/API 合同新增或变化：写 API_DESIGN.md。
UI、原型、视觉验收、响应式、浏览器行为：写 VISUAL_SPEC.md。
复杂验证路径或关键风险：写 TEST_PLAN.md。
设计输出应覆盖：
技术方案
模块边界
数据与接口设计
路由/API/数据契约
原型引用
视觉规格
文件组织
实现计划
Required Codex Implementation
测试策略
页面驱动验收计划
风险和取舍
完成设计后，prod-architect 必须创建 exactly one prod-coder child task：
hermes kanban --board prod create \
--assignee prod-coder \
--parent <architect_task_id> \
--workspace <workspace> \
--title "实现：<title>" \
--body-file <coder_task_body.md>
5.4 prod-coder
prod-coder 是实现 worker，但不是任意手工写代码的 worker。
当前生产规则：
Windows Codex CLI 是 prod-coder 代码变更任务的默认实现引擎。
唯一生产入口是 /home/fd/.hermes/scripts/codex_windows_exec.sh。
Codex 只做代码实现，不创建、完成、block、review Kanban 任务。
Kanban 生命周期仍由 prod-coder 负责。
执行顺序：
读 task body、父 PRD、父设计、comments、Router、workflow contract。
进入 task workspace。
读取 docs/PRD.md 和 docs/DESIGN.md。
按需读取 DATABASE_DESIGN.md、API_DESIGN.md、VISUAL_SPEC.md、TEST_PLAN.md。
如果 docs/PRD.md 或 docs/DESIGN.md 缺失，block handoff-incomplete，不实现。
准备 Codex prompt。
调用 Windows Codex wrapper。
审查 Codex 输出和 workspace 变更。
只做小范围 follow-up edits。
跑自测。
写 review-required handoff comment。
block review-required: <summary>。
推荐 Codex 调用：
/home/fd/.hermes/scripts/codex_windows_exec.sh "<workspace_path>" "<implementation prompt>"
原型图任务：
/home/fd/.hermes/scripts/codex_windows_exec.sh "<workspace_path>" \
--image "<prototype_image_1>" \
--image "<prototype_image_2>" \
"<implementation prompt>"
必须使用 Windows Codex CLI 的条件：
如果 wrapper、Windows cmd.exe、Windows Codex CLI 启动失败，或者 Codex 在实现前退出：
error_type: env-missing
summary: Windows Codex CLI is required for this implementation task but the wrapper could not start it.
attempted: include the wrapper command and error.
recommended_next_action: fix WSL/Windows interop or Codex CLI availability, restart prod-coder if needed, then retry/unblock.
如果 Codex 已启动，但模型、网络、工具短暂失败：
error_type: retryable
两种情况都不能 fallback 到 Hermes 大范围手工实现。
prod-coder 自测应覆盖：
success_path:
- core action succeeds
- data is persisted or reflected
- list/detail/readback confirms the result
failure_path:
- required fields empty
- min/max length or format invalid
- API 400/401/403/404/422/500 handled
- network/upload failure handled when relevant
user_feedback:
- no [object Object]
- no raw JSON object exposed
- no raw framework/Pydantic text exposed
- visible field/global error
- loading/disabled state during mutation
- failure leaves input recoverable
page_driven:
- route/page shell reachable
- primary content/control present
- API-backed data renders non-empty when API returns non-empty
- mutation readback exists
真实浏览器交互、截图、DOM snapshot、console 检查、响应式视觉验收属于 prod-tester，不属于 prod-coder。
review-required handoff comment 模板：
review-required handoff:
changed_files:
docs_read:
codex_invocation:
verification:
interfaces_verified:
page_driven_self_checks:
functional_paths_verified:
failure_paths_verified:
mutation_readback_verified:
error_feedback_verified:
visual_spec_coverage:
prototype_reference_images:
test_instructions:
residual_risk:
workspace:
然后：
hermes kanban --board prod block <coder_task_id> "review-required: <implementation summary and review need>"
5.5 monitor 创建 implementation-review
prod-coder 不创建 prod-tester task。
monitor 识别：
assignee = prod-coder
block reason prefix = review-required:
然后创建：
assignee: prod-tester
review_type: implementation-review
title_prefix: implementation-review：
source_task_id: <coder_task_id>
这个 tester task 是独立任务，不对 blocked coder 使用硬 parent link。
5.6 prod-tester
prod-tester 是实现 reviewer，不是全站无限探索 QA。
必须做：
读取 source coder handoff、PRD、DESIGN、TEST_PLAN、VISUAL_SPEC。
写 docs/TEST_REPORT.md。
UI/browser 验收使用已批准的生产浏览器验证适配器；当前 Windows 环境通常是 Windows Chrome chrome-devtools-win MCP。
通过后 comment source coder 并 unblock source coder。
失败时 block tester task，写清楚缺陷、证据、复现步骤、建议下一步。
推荐 tester 策略：
信任 prod-coder 已明确记录且证据充分的 pytest/build/API smoke。
只做必要轻量复核和关键浏览器/视觉/user-path 验收。
如果证据缺失、过期、高风险，才重跑更广验证。
命中阻塞缺陷后，快速收敛：截图/DOM/Network/Console/最小复现，然后 block。
不要在发现一个明确阻塞缺陷后继续做无边界全站探索。
浏览器环境不可用时：
error_type: env-missing
summary: chrome-devtools-win or Windows Chrome 9222 is unavailable.
attempted: include bounded connection attempts and exact missing prerequisite.
recommended_next_action: start Windows Chrome with remote debugging or fix MCP config, then retry.
通过时：
hermes kanban --board prod comment <source_coder_task_id> "<tester pass summary>"
hermes kanban --board prod unblock <source_coder_task_id>
hermes kanban --board prod complete <tester_task_id> "<tester summary>"
失败时：
hermes kanban --board prod block <tester_task_id> "error_type: test-failed
summary: ...
attempted: ...
recommended_next_action: ..."
prod-tester 不创建修复任务、不创建 review task。
5.7 prod-coder 完成
tester pass 并 unblock source coder 后，prod-coder 才 complete。
完成 summary 应包含：
实现内容：
修改文件：
文档读取确认：
Codex 调用：
验证：
接口自测：
页面驱动自测：
功能和失败路径自测：
变更读回自测：
错误提示自测：
tester approval evidence：
风险/备注：
5.8 交付完成通知
tester pass 并 unblock source coder 后，prod-coder complete。monitor 发送 [交付完成] 飞书通知，不创建 prod-main review task。
通知和 coder summary 应包含：
实现内容
修改文件
验证结果
tester approval evidence
运行方式
风险/备注
后续建议
6. Artifact Contract
工作流合同：
/home/fd/.hermes/team/workflows/prod-dev.yaml
必需落盘文件：
prod-prd:
docs/PRD.md
prod-architect:
docs/DESIGN.md
prod-tester:
docs/TEST_REPORT.md
条件文件：
docs/DATABASE_DESIGN.md
docs/API_DESIGN.md
docs/VISUAL_SPEC.md
docs/TEST_PLAN.md
硬规则：
Kanban comments、summary、metadata 不能替代 workspace artifact。
metadata 推荐写，但不是链路推进前置条件。
稳定 handoff 依赖 task body、comments、summary、result、parent/child links。
如果 metadata 为 null，后续 agent 必须从稳定记录恢复上下文。
7. 原型图处理
原型图是输入材料，不是最终实现合同。
prod-main 是默认识图入口：
稳定字段：
prototype_inventory
prototype_reference_pack
unresolved_images
page_structure
visual_spec
visual_acceptance_criteria
高保真 UI 任务必须明确：
page_identity:
- 页面名称
- route
- active nav
- first viewport content
layout:
- 信息层级
- 栅格/列表/卡片
- 响应式断点
visual:
- color
- typography
- spacing
- states
acceptance:
- desktop
- mobile
- interaction
- data rendering
- error states
下游注意：
如果 prototype 是首页，不要默默实现成案例页。
如果 prototype active nav 是 案例广场，除非任务明确改动，否则保持页面身份。
视觉验收应根据 visual_spec 和 visual_acceptance_criteria，不是凭印象自由发挥。
8. Feishu 设计
推荐生产模式：
一个用户入口：prod-main
多个生产 profile：prod-prd / prod-architect / prod-coder / prod-tester
一个 monitor：监听 Kanban 并向飞书群通知
飞书用途：
飞书不做：
bot-to-bot 调度协议。
Agent 间可靠状态机。
secret 存储。
每个 profile 可有独立 .env：
profiles/prod-main/.env
profiles/prod-prd/.env
profiles/prod-architect/.env
profiles/prod-coder/.env
profiles/prod-tester/.env
不要把真实 .env 内容复制到任务或文档。
9. Monitor 配置
生产配置：
/home/fd/.hermes/kanban_feishu_monitor_prod.yaml
关键配置：
home: /home/fd/.hermes
board: prod
db_path: /home/fd/.hermes/kanban/boards/prod/kanban.db
poll_interval_seconds: 15
implementation_review:
enabled: true
source_assignee: prod-coder
reviewer_assignee: prod-tester
reason_prefix: "review-required:"
title_prefix: "implementation-review："
review:
enabled: true
create_tasks: false
create_for_kinds: []
create_for_leaf_completed: false
implementation_review:
enabled: true
approval_notice:
enabled: true
monitor 负责：
监听 Kanban 事件并推送飞书。
将 prod-coder 的 review-required: block 转成独立 prod-tester implementation-review。
PRD/设计进入审批 gate 时发送审批通知和产物预览。
将 blocked/crashed/timed_out/gave_up/spawn_failed 发送为 [任务异常，需要用户决策]，不自动创建 prod-main task。
将 prod-coder complete 发送为 [交付完成]，不自动创建 final review。
10. 异常路径
异常事件：
blocked
spawn_failed
gave_up
crashed
timed_out
例外：
prod-coder block reason prefix = review-required:
这个不是异常，而是正常 implementation-review gate。
其他异常只进入飞书通知，等待用户决策。
异常处理原则：
必须获得用户明确决策后才能 retry/unblock、provide-input、repair、accept-risk、terminate。
用户可以直接 @ 当前负责 agent 继续、修改或补充信息。
如果需要重新路由或创建返工任务，用户可以 @ prod-main 手动处理。
允许恢复动作：
retry -> unblock source task
provide-input -> comment user input on source task, then unblock
repair -> create focused remediation task
accept-risk -> continue/finalize with stated risk
terminate -> stop chain and explain
11. Windows Codex CLI
prod-coder 调用 Windows Codex CLI 的唯一生产入口：
/home/fd/.hermes/scripts/codex_windows_exec.sh
wrapper 职责：
从 WSL 调 Windows Codex CLI。
固定 Hermes prod-coder policy。
允许 approved workspace/image roots。
使用 --skip-git-repo-check 支持非 git workspace。
支持 --image <wsl_image_path>。
用 /mnt/c/Windows/System32/cmd.exe 降低 PATH 敏感度。
强制规则：
For prod-coder, Windows Codex CLI is mandatory for the primary implementation step of code-changing tasks. If no Codex-produced implementation exists in the current run, direct prod-coder edits must not satisfy a code-changing task.
Codex prompt 应包含：
workspace
scope
files allowed / files forbidden
docs read
implementation requirements
visual_spec / acceptance criteria
verification commands
Kanban prohibition: do not create/complete/block/review tasks
UI/UX 任务应要求 Codex 使用 Windows 侧 UI skill：
C:\Users\18196\.codex\skills\ui-ux-pro-max\SKILL.md
Codex 不能做：
12. Windows Chrome MCP
prod-tester 的浏览器验收工具：
chrome-devtools-win
推荐配置：
mcp_servers:
chrome-devtools-win:
command: /mnt/c/Windows/System32/cmd.exe
args:
- /c
- cd /d C:\Windows && npx -y chrome-devtools-mcp@latest --browserUrl http://127.0.0.1:9222 --no-usage-statistics --no-performance-crux
enabled: true
Windows Chrome 需要以 remote debugging 方式运行：
Start-Process "chrome.exe" "--remote-debugging-port=9222 --user-data-dir=C:\tmp\chrome-devtools-hermes"
WSL 内检查：
curl -sS --max-time 5 http://127.0.0.1:9222/json/version
curl -sS --max-time 5 http://127.0.0.1:9222/json/list
如果出现：
MCP server 'chrome-devtools-win' keepalive failed, triggering reconnect
这通常是连接抖动。判断是否致命，应看后续 MCP tool 是否还能成功执行 list_pages、navigate_page、take_snapshot、click、list_console_messages。
如果 Chrome 9222 不通，tester 必须快速 block env-missing，不要改用 WSL Chromium、Playwright Chromium、Hermes built-in browser fallback。
13. 启动和检查
一键重启生产栈：
cd /home/fd/.hermes
bash scripts/restart_prod_stack.sh
脚本会启动：
prod-main gateway + dashboard
prod-prd gateway + dashboard
prod-architect gateway + dashboard
prod-coder gateway + dashboard
prod-tester gateway + dashboard
kanban_feishu_monitor.py --daemon --config kanban_feishu_monitor_prod.yaml
Dashboard：
prod-main http://127.0.0.1:9130
prod-prd http://127.0.0.1:9131
prod-architect http://127.0.0.1:9132
prod-coder http://127.0.0.1:9133
prod-tester http://127.0.0.1:9134
进程检查：
ps -eo pid,etime,cmd | grep -E "hermes -p prod-|kanban_feishu_monitor.py" | grep -v grep
Dashboard HTTP 检查：
python3 - <<'PY'
import urllib.request
for port in [9130, 9131, 9132, 9133, 9134]:
try:
r = urllib.request.urlopen(f"http://127.0.0.1:{port}/", timeout=5)
print(port, r.status)
except Exception as exc:
print(port, "ERR", repr(exc))
PY
Kanban 检查：
hermes kanban boards list
hermes kanban --board prod list
hermes kanban --board prod assignees
日志位置：
profiles/prod-main/logs/gateway.supervisor.log
profiles/prod-prd/logs/gateway.supervisor.log
profiles/prod-architect/logs/gateway.supervisor.log
profiles/prod-coder/logs/gateway.supervisor.log
profiles/prod-tester/logs/gateway.supervisor.log
profiles/prod-tester/logs/mcp-stderr.log
kanban/feishu_monitor_prod.log
kanban/feishu_monitor_prod.out
14. systemd
systemd unit 位于：
/home/fd/.hermes/systemd/
包括：
hermes-prod-main-gateway.service
hermes-prod-prd-gateway.service
hermes-prod-architect-gateway.service
hermes-prod-coder-gateway.service
hermes-prod-tester-gateway.service
hermes-prod-main-dashboard.service
hermes-prod-prd-dashboard.service
hermes-prod-architect-dashboard.service
hermes-prod-coder-dashboard.service
hermes-prod-tester-dashboard.service
hermes-kanban-feishu-monitor-prod.service
当前日常推荐仍是：
bash /home/fd/.hermes/scripts/restart_prod_stack.sh
systemd 可作为长期守护部署选项，但启停前要确认 WSL/systemd 状态和 PATH 是否包含 Windows interop 路径。
15. WSL + Windows 注意事项
需要 Windows interop 的组件：
PATH 至少需要包含：
/mnt/c/Windows/system32
/mnt/c/Windows
/mnt/c/Windows/System32/WindowsPowerShell/v1.0
/mnt/d/nodejs
/mnt/c/Users/18196/AppData/Roaming/npm
Windows cmd.exe 不支持 UNC 当前目录。MCP 配置里用：
cd /d C:\Windows && npx ...
这是为了避免 \\wsl.localhost\... 被 cmd.exe 当成无效 cwd。
16. 安全规范
禁止写入以下内容到任务、评论、summary、metadata、飞书、日志、文档：
API Key
App Secret
Access Token
Refresh Token
Cookie
Session
Private Key
OAuth ticket
Webhook secret
真实数据库密码
生产代码修改边界：
17. 常见问题
17.1 Coder 没调用 Codex
判断：
处理：
17.2 Tester 跑很久
先分清：
blocked task 没有 completed_at，看起来会像“跑了几小时/几天”，但实际测试可能只跑了几分钟。
建议：
17.3 Chrome MCP 抖动
看到：
keepalive failed, triggering reconnect
不一定是失败。检查：
curl http://127.0.0.1:9222/json/version
并查看 tester session 是否后续成功调用 MCP tools。
17.4 Coder 90 轮耗尽
prod-coder 必须保留 Kanban closure budget：
17.5 Child missing
如果：
monitor 可以发送 [下游任务缺失] 通知，但不自动创建 prod-main review task。
prod-coder completion 是正常交付完成，应触发 [交付完成] 通知。
18. 最小验证任务
飞书里给 prod-main 的最小请求建议包含：
workspace:
authorization:
goal:
acceptance:
constraints:
示例：
@prod-main
在 /home/fd/projects/demo-app 中实现一个最小 Todo 页面。
允许创建和修改该 workspace 内文件。
验收标准：可以新增 todo、切换完成状态、刷新后数据仍在本地存储中。
要求走 prod 多 Agent 链路，不跳过 PRD、设计、coder review-required、tester 验收。
预期链路：
prod-main creates prod-prd
prod-prd creates prod-architect
prod-architect creates prod-coder
prod-coder calls codex_windows_exec.sh and blocks review-required
monitor creates prod-tester implementation-review
prod-tester pass/unblock or block defects
prod-coder complete after unblock
monitor sends delivery-complete notice
user accepts or asks the responsible agent / prod-main for follow-up
19. 最佳实践
入口统一：用户只找 prod-main。
调度统一：所有生产任务只走 prod board。
角色纯粹：main 不写代码，prd 不设计实现，architect 不编码，coder 不建 tester，tester 不建修复任务。
产物落盘：PRD、DESIGN、TEST_REPORT 是硬产物。
原型转文字：图片先变成 prototype_inventory、visual_spec、visual_acceptance_criteria。
Codex 强制：prod-coder 的主要实现走 Windows Codex wrapper。
验收聚焦：prod-tester 做关键用户路径和视觉验收，不重复无限全量测试。
异常要用户决策：retry/repair/accept-risk 等动作不能自动冒进。
metadata 推荐但不强依赖：body/comments/summary/result/links 才是稳定交接底座。
永不泄密：任务、评论、日志、飞书、文档都不能出现真实 secret。
20. 当前权威文件索引
日常排查以这些文件为准：
/home/fd/.hermes/AGENTS.md
/home/fd/.hermes/MULTI_AGENT_ROUTER.md
/home/fd/.hermes/MULTI_AGENT_WORKFLOW.md
/home/fd/.hermes/team/workflows/prod-dev.yaml
/home/fd/.hermes/team/handoffs/*.md
/home/fd/.hermes/kanban_feishu_monitor_prod.yaml
/home/fd/.hermes/profiles/prod-main/AGENTS.md
/home/fd/.hermes/profiles/prod-prd/AGENTS.md
/home/fd/.hermes/profiles/prod-architect/AGENTS.md
/home/fd/.hermes/profiles/prod-coder/AGENTS.md
/home/fd/.hermes/profiles/prod-tester/AGENTS.md
如果本文与上述规则文件冲突，以 AGENTS.md、MULTI_AGENT_ROUTER.md、team/workflows/prod-dev.yaml 和 profile-specific AGENTS.md 为准，并更新本文。
littlerookie 05-28 10:592楼
无花僧 05-28 11:314楼
青玉白露 05-28 12:407楼
卡农 05-28 13:018楼
superloki7 05-28 16:1910楼
宫野しほ 05-28 16:3616楼
mumong 05-29 14:5518楼
可惜就是你 05-29 15:1819楼