Harness Lifecycle¶

这张图把一轮受规格约束的软件工程工作放进 HG。产品定义、风险判断、批准、spec、plan、tasks、worker 报告、评估与评审都成为带 Revision 的工件。

真实路径会使用现有 Codex 与 OpenCode 凭据句柄。凭据不会进入 Slot、Receipt 或最终 Git 工件。

完整图定义¶

下面的配置完整展示了两个 Human Rule、一次角色越界拒绝、一轮 Supervisor 与 worker 协作，以及最终 Git 提交。你也可以下载原始 YAML。

version: 1
project:
  name: real-world-harness-lifecycle
  default_targets: [final_repo]
slots:
  project_fixture: { kind: dir, path: fixtures/project }
  human_responses: { kind: file, path: fixtures/human-responses.json }
  product_brief: { kind: file, path: product-brief.md }
  questions: { kind: file, path: lifecycle/questions.md }
  product_definition: { kind: file, path: lifecycle/product.json }
  feasibility: { kind: file, path: lifecycle/feasibility.json }
  core_approval: { kind: file, path: lifecycle/core-approval.json }
  spec: { kind: file, path: lifecycle/spec.md }
  plan: { kind: file, path: lifecycle/plan.md }
  tasks: { kind: file, path: lifecycle/tasks.md }
  role_check: { kind: file, path: lifecycle/role-check.json }
  next_task: { kind: file, path: lifecycle/next-task.md }
  worker_report: { kind: file, path: lifecycle/worker-report.md }
  evaluation: { kind: file, path: lifecycle/eval.md }
  report: { kind: file, path: lifecycle/report.md }
  review: { kind: file, path: lifecycle/acceptance-review.md }
  final_repo: { kind: git, path: lifecycle-repo }
rules:
  - id: grill_product
    in: [project_fixture, product_brief]
    out: [questions]
    run:
      using: codex
      model: gpt-5.6-luna
      reasoning_effort: none
      command: >-
        Use shell commands only, never apply_patch. You must execute exactly this command and do nothing else:
        printf '# Product Grill\n\n1. What is the smallest deterministic behavior?\n2. Which acceptance evidence proves it?\n' > out/questions
  - id: define_product
    in: [questions, human_responses]
    out: [product_definition]
    run: { using: human, command: "Provide the exact product definition JSON" }
  - id: assess_feasibility
    in: [project_fixture, product_definition]
    out: [feasibility]
    run: >-
      jq -n --arg product "$(jq -r '.mvp' in/product_definition)" '{feasible:true,risk:"core",product:$product,reason:"lifecycle kernel boundary"}' > out/feasibility
  - id: approve_core
    in: [feasibility, human_responses]
    out: [core_approval]
    run: { using: human, command: "Approve or reject the core-risk fixture implementation" }
  - id: write_spec
    in: [product_definition, core_approval]
    out: [spec]
    when: "test \"$(jq -r '.decision' core_approval)\" = approve"
    run: "printf '# Spec\n\nGiven 1, increment returns 2.\n' > out/spec"
  - id: write_plan
    in: [feasibility, core_approval]
    out: [plan]
    when: "test \"$(jq -r '.decision' core_approval)\" = approve"
    run: "printf '# Plan\n\nRED test, GREEN implementation, evaluation, report, review.\n' > out/plan"
  - id: write_tasks
    in: [product_definition, feasibility, core_approval]
    out: [tasks]
    when: "test \"$(jq -r '.decision' core_approval)\" = approve"
    run: "printf '# Tasks\n\n1. RED acceptance.\n2. GREEN implementation.\n3. Verify and report.\n' > out/tasks"
  - id: enforce_role_boundary
    in: [human_responses, core_approval]
    out: [role_check]
    when: "test \"$(jq -r '.decision' core_approval)\" = approve"
    run: >-
      role=$(jq -r '.role_violation.role' in/human_responses); path=$(jq -r '.role_violation.path' in/human_responses); if test "$role" = TDD-RED && case "$path" in src/*) true;; *) false;; esac; then jq -n --arg role "$role" --arg path "$path" '{decision:"reject",reason:"role_boundary",role:$role,path:$path}' > out/role_check; else exit 1; fi
  - id: supervisor_iteration
    in: [spec, plan, tasks, role_check]
    out: [next_task]
    when: "test \"$(jq -r '.decision' role_check)\" = reject"
    run:
      using: codex
      model: gpt-5.6-luna
      reasoning_effort: none
      command: >-
        Use shell commands only, never apply_patch. You must execute exactly this command and do nothing else:
        printf '# Next Task\n\nObjective: implement increment.\nAllowed: src/lib.rs.\nForbidden: tests and product scope.\nAcceptance: increment(1) == 2.\nRequired Harness process: TDD-GREEN then report.\nVerification: cargo test.\nOutput: .pm/runtime/worker-report.md.\n' > out/next_task
  - id: opencode_worker
    in: [project_fixture, next_task, role_check]
    out: [worker_report]
    when: "test \"$(jq -r '.decision' role_check)\" = reject"
    run: >-
      OPENCODE_PERMISSION='{"bash":"allow","edit":"allow","write":"allow"}' opencode run -m zhipuai-coding-plan/glm-5.1 'Use shell commands only. Execute exactly: printf "# Worker Report\n\n## Changed files\n- src/lib.rs\n\n## Commands run\n- cargo test\n\n## Test results\n- 1 passed\n\n## Acceptance criteria\n- [x] increment(1) == 2\n\n## Problems encountered\n- none\n\n## Deviations\n- none\n" > out/worker_report' >/dev/null
  - id: evaluate_iteration
    in: [spec, worker_report]
    out: [evaluation]
    run: "grep -q '1 passed' in/worker_report && printf '# Eval\n\nAcceptance behavior and worker evidence pass.\n' > out/evaluation"
  - id: report_iteration
    in: [plan, tasks, worker_report, evaluation]
    out: [report]
    run: "printf '# Implementation Report\n\nOne bounded Supervisor/worker iteration completed with role isolation.\n' > out/report"
  - id: review_iteration
    in: [spec, role_check, worker_report, evaluation, report]
    out: [review]
    run: >-
      test "$(jq -r '.decision' in/role_check)" = reject; grep -q 'Acceptance criteria' in/worker_report; printf '# Acceptance Review\n\nVerdict: accepted\nEvidence: role violation rejected; worker report complete; evaluation passed.\nNext action: stage exit.\n' > out/review
  - id: commit_lifecycle
    in: [project_fixture, product_definition, feasibility, core_approval, spec, plan, tasks, role_check, next_task, worker_report, evaluation, report, review]
    out: [final_repo]
    run: |
      git init -q out/final_repo
      git -C out/final_repo config user.email hg@example.invalid
      git -C out/final_repo config user.name HG
      cp -R in/project_fixture/. out/final_repo/
      mkdir -p out/final_repo/specs/001-counter out/final_repo/.pm/runtime
      cp in/product_definition out/final_repo/.pm/runtime/product.json
      cp in/feasibility out/final_repo/.pm/runtime/feasibility.json
      cp in/core_approval out/final_repo/.pm/runtime/core-approval.json
      cp in/spec out/final_repo/specs/001-counter/spec.md
      cp in/plan out/final_repo/specs/001-counter/plan.md
      cp in/tasks out/final_repo/specs/001-counter/tasks.md
      cp in/role_check out/final_repo/.pm/runtime/role-check.json
      cp in/next_task out/final_repo/.pm/runtime/next-task.md
      cp in/worker_report out/final_repo/.pm/runtime/worker-report.md
      cp in/evaluation out/final_repo/specs/001-counter/eval.md
      cp in/report out/final_repo/specs/001-counter/report.md
      cp in/review out/final_repo/.pm/runtime/acceptance-review.md
      printf 'schema: harness-lifecycle/v1\niteration: 1\nloop_control: STAGE_EXIT_REACHED\n' > out/final_repo/.pm/runtime/state.yaml
      git -C out/final_repo add .
      git -C out/final_repo commit -qm 'complete Harness lifecycle fixture'

Slot 怎样分工¶

Slot	阶段	在图里的作用
`project_fixture`	输入	worker 最终要修改的固定项目目录。
`human_responses`	输入	测试中使用的人工答案与角色越界样本。
`product_brief`	输入	最初的产品要求。
`questions`	产品	Grill 生成的澄清问题。
`product_definition`	产品	用户确认后的确切 MVP 定义。
`feasibility`	风险	可行性、风险级别与原因。
`core_approval`	风险	对 core 风险变更的独立人工决定。
`spec`	规格	获批后生成的行为规格。
`plan`	规格	RED、GREEN、评估、报告和评审计划。
`tasks`	规格	worker 可以执行的任务清单。
`role_check`	治理	对角色越界的结构化拒绝证据。
`next_task`	调度	Supervisor 交给 worker 的单个有边界任务。
`worker_report`	实现	worker 记录的改动、命令、测试和验收结果。
`evaluation`	验收	对行为和 worker 证据的评估。
`report`	验收	本轮实现报告。
`review`	验收	最终 acceptance review。
`final_repo`	输出	汇总代码与全部过程证据的 Git 工件。

Rule 逐条看¶

Rule	读取	写入	作用
`grill_product`	project_fixture、product_brief	questions	生成两个最小产品问题。
`define_product`	questions、human_responses	product_definition	Human Rule 提交确切产品定义。
`assess_feasibility`	project_fixture、product_definition	feasibility	写出 core 风险判断。
`approve_core`	feasibility、human_responses	core_approval	第二个 Human Rule 单独批准核心风险。
`write_spec`	product_definition、core_approval	spec	approve 后写入行为规格。
`write_plan`	feasibility、core_approval	plan	approve 后写入实现计划。
`write_tasks`	product_definition、feasibility、core_approval	tasks	approve 后写入任务清单。
`enforce_role_boundary`	human_responses、core_approval	role_check	捕获 TDD-RED 写实现文件的越界，并写出 reject。
`supervisor_iteration`	spec、plan、tasks、role_check	next_task	越界被拒绝后生成一个受限 GREEN 任务。
`opencode_worker`	project_fixture、next_task、role_check	worker_report	调用 OpenCode 完成一次实现并记录报告。
`evaluate_iteration`	spec、worker_report	evaluation	检查测试证据并写评估。
`report_iteration`	plan、tasks、worker_report、evaluation	report	汇总本轮实现情况。
`review_iteration`	spec、role_check、worker_report、evaluation、report	review	检查越界拒绝、验收项和报告完整性。
`commit_lifecycle`	项目与全部生命周期证据	final_repo	初始化 Git 仓库，复制代码和证据并创建提交。

产品定义与核心风险批准是两个不同决定，各自绑定到自己的输入前沿。角色检查写出 reject 后，reject 本身成为下游的输入事实。Supervisor 和 worker 因此无需隐藏的控制状态。

运行并观察¶

scripts/test-real-world-cases.sh harness-lifecycle contract

合约路径检查过期人工回答隔离、第二次风险决定、角色越界拒绝，以及最终 Git 工件中的 spec、eval 与 report。

准备好 Codex 和 OpenCode 后运行真实边界。

scripts/test-real-world-cases.sh harness-lifecycle live

完成后检查 lifecycle-repo/.pm/runtime 与 specs/001-counter。这些文件来自声明 Slot，可以追溯到本轮输入和 Receipt。