@tea-agent/loop-agent 0.24.4-beta.0 → 0.24.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +13 -5
- package/CHANGELOG.md +52 -0
- package/README.md +5 -2
- package/dist/commands/init.js +16 -2
- package/dist/worker/cli.js +59 -14
- package/dist/worker/console/operator-actions.js +135 -24
- package/dist/worker/console/static/assets/index-CSRIhuzh.js +29 -0
- package/dist/worker/console/static/assets/index-Yyn3ynVv.css +1 -0
- package/dist/worker/console/static/index.html +2 -2
- package/dist/worker/console/static-src/prd-file-import.js +218 -0
- package/dist/workflows/dag/backend-test-markdown-workflow.js +77 -11
- package/dist/workflows/dag/init-hybrid.js +15 -15
- package/dist/workflows/dag/l5-report-metrics.js +0 -3
- package/docs/architecture/evolution.md +1 -1
- package/docs/architecture/system-overview.md +1 -1
- package/docs/operations/local-development-environment.md +19 -0
- package/docs/templates/backend-test-dag.generate-pytest.prompt.md +3 -2
- package/docs/templates/backend-test-dag.json +7 -7
- package/docs/templates/backend-test-dag.retrospect.prompt.md +0 -3
- package/docs/templates/backend-test-dag.review-cases.prompt.md +1 -1
- package/docs/templates/evaluation/agents-map-slim-v1.md +1 -1
- package/docs/templates/evaluation/agents-map-verbose-v0.md +2 -2
- package/harness.json +2 -2
- package/package.json +1 -1
- package/skills/agent-worker/SKILL.md +1 -1
- package/skills/loop-agent/SKILL.md +1 -1
- package/skills/loop-agent/references/command-reference.md +1 -0
- package/dist/worker/console/static/assets/index-Cv68Ge5n.js +0 -27
- package/dist/worker/console/static/assets/index-Dp_2sKGk.css +0 -1
|
@@ -19,9 +19,6 @@ export function computeL5ReportMetrics(input) {
|
|
|
19
19
|
automationCoverage: input.manifest.coverageSummary
|
|
20
20
|
? ratioMetric(input.manifest.coverageSummary.generatedCount, input.manifest.coverageSummary.caseCount, 0.9, "automation-coverage")
|
|
21
21
|
: unavailable("case-manifest-coverage-missing", null, null, 0.9),
|
|
22
|
-
stability: input.stability?.status === "available" && input.stability.ratio !== null
|
|
23
|
-
? { numerator: input.stability.successfulRuns, denominator: input.stability.recordedRuns, ratio: input.stability.ratio, threshold: 0.95, status: input.stability.ratio >= 0.95 ? "pass" : "fail", reason: input.stability.ratio >= 0.95 ? null : "stability-below-threshold" }
|
|
24
|
-
: unavailable(input.stability?.reason ?? "stability-evidence-missing", input.stability?.successfulRuns ?? null, input.stability?.recordedRuns ?? null, 0.95),
|
|
25
22
|
lineCoverage: input.coverage?.metrics.line.status === "available" && input.coverage.metrics.line.ratio !== null
|
|
26
23
|
? { numerator: input.coverage.metrics.line.covered, denominator: input.coverage.metrics.line.total, ratio: input.coverage.metrics.line.ratio, threshold: 0.8, status: input.coverage.metrics.line.ratio >= 0.8 ? "pass" : "fail", reason: input.coverage.metrics.line.ratio >= 0.8 ? null : "line-coverage-below-threshold" }
|
|
27
24
|
: unavailable(input.coverage?.metrics.line.reason ?? "line-coverage-missing", input.coverage?.metrics.line.covered ?? null, input.coverage?.metrics.line.total ?? null, 0.8),
|
|
@@ -48,7 +48,7 @@
|
|
|
48
48
|
| 云 Task Pool / SQL / Orchestrator | 规划 / 未实现 | 同上(第 2 月原始设计已调整为本地 Feature 闭环) |
|
|
49
49
|
| 多仓库平台 | 规划 / 未实现 | 同上 |
|
|
50
50
|
| 组织级服务 | 规划 / 未实现 | 同上 |
|
|
51
|
-
| Web Console(远端多用户) | 规划 / 未实现;**不等于**已发布的本地 loopback Operator Console | 同上;对照 `docs/design/
|
|
51
|
+
| Web Console(远端多用户) | 规划 / 未实现;**不等于**已发布的本地 loopback Operator Console | 同上;对照 `docs/design/archive/2026-07-21-local-operator-console-from-pi-web.md` |
|
|
52
52
|
| fullstack Delivery / Final Verification live 闭环 | 进行中(active train) | `docs/exec-plans/active/2026-07-19-fullstack-dogfood-016x-release-train.md` |
|
|
53
53
|
| Dynamic Workflow runtime limits 强执法、更广 profile | 设计输入 | `docs/design/active/dynamic-workflow-dag-engine-roadmap.md` |
|
|
54
54
|
| Loop 与 Dynamic Workflow 更深双向集成 / 自动恢复 | 设计输入 | 同上;当前已有基础 `workflow` action |
|
|
@@ -64,7 +64,7 @@ workflow runtime(调度 Pi / shell / static 节点)
|
|
|
64
64
|
- `agent-worker console serve|doctor` 提供 loopback Operator Console(默认 `127.0.0.1:8790`);Happy Path / Interview 策略面、Task Contract 落地与 recovery CTA 已随 **0.17.0–0.17.2** 发布。
|
|
65
65
|
- canonical mutation 只经 sibling 已发布 `loop-agent`(`LoopAgentClient`),不 in-process 跑 DAG kernel。
|
|
66
66
|
- Observe 保持**独立**只读进程(默认 `8787`);Console 通过 versioned Observe `/api/health`(`schemaVersion`、`repoFingerprint`、route capabilities)做深链 fail-closed,**不** mount / proxy。
|
|
67
|
-
- openCode 等主会话仍是 Compatibility / Operator Assist,与 Official Console **不等同**。设计锚点:ADR 0005、`docs/design/
|
|
67
|
+
- openCode 等主会话仍是 Compatibility / Operator Assist,与 Official Console **不等同**。设计锚点:ADR 0005、`docs/design/archive/2026-07-21-local-operator-console-from-pi-web.md`;handoff `docs/reports/feature/2026-07-22-console-mvp-handoff.md`。
|
|
68
68
|
|
|
69
69
|
## 外部边界
|
|
70
70
|
|
|
@@ -2,6 +2,25 @@
|
|
|
2
2
|
|
|
3
3
|
本文记录仅与特定开发环境有关、但可能反复影响验证结果的问题。它不是通用工程规则;标准验证命令仍以 [`verification-matrix.md`](../governance/verification-matrix.md) 为准。
|
|
4
4
|
|
|
5
|
+
## Git hooks(本仓库)
|
|
6
|
+
|
|
7
|
+
每个 clone 安装一次:
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
bash scripts/install-git-hooks.sh
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
| Hook | 行为 |
|
|
14
|
+
| --- | --- |
|
|
15
|
+
| `pre-commit` | `bash scripts/check-repo.sh`(快,不含 `npm test`) |
|
|
16
|
+
| `pre-push` | `bash scripts/ci.sh`(check-repo + typecheck + 全量 `npm test`) |
|
|
17
|
+
|
|
18
|
+
编辑与实现阶段只跑 verification-matrix 的「最低验证」;全量测试由 push 前 hook 承担。紧急跳过一次:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
LOOP_AGENT_SKIP_PRE_PUSH_TESTS=1 git push
|
|
22
|
+
```
|
|
23
|
+
|
|
5
24
|
## Cursor Cloud
|
|
6
25
|
|
|
7
26
|
Cursor Cloud VM 当前有两个需要特别注意的环境问题。
|
|
@@ -22,11 +22,12 @@ class TestOrderApi:
|
|
|
22
22
|
- 断言只来自 `### 预期结果` / `### Expected Results`;setup 只来自必选 `### 前置条件`,以及存在时的 `### 测试数据`、`### 自动化映射` 或对应历史英文分节。
|
|
23
23
|
- 每条可自动化 Case 应在 `自动化映射` / `Automation Notes` 明确写出目标 pytest 脚本;第 6 节点只扫描这些脚本,不递归扫描无关历史 `test_*.py`。
|
|
24
24
|
- 每次接口请求必须通过统一日志 helper 或等价 client wrapper 打印请求与响应诊断信息:请求日志至少包含 HTTP method、URL/path、query 与 JSON/body/payload 参数摘要;响应日志至少包含 status code 与 JSON/text/body 结果摘要。日志必须能出现在 pytest stdout/stderr,不能改变断言或把失败伪装成通过。
|
|
25
|
-
- 日志输出前必须递归脱敏 `authorization`、`proxy-authorization`、`cookie`、`set-cookie`、`token`、`password`、`secret`、`api key`、`credential` 等 key/header;禁止打印完整 Authorization/Cookie。序列化后的 request/response body 必须有明确长度上限和截断标识,避免大对象淹没 pytest/
|
|
25
|
+
- 日志输出前必须递归脱敏 `authorization`、`proxy-authorization`、`cookie`、`set-cookie`、`token`、`password`、`secret`、`api key`、`credential` 等 key/header;禁止打印完整 Authorization/Cookie。序列化后的 request/response body 必须有明确长度上限和截断标识,避免大对象淹没 pytest/pytest-html/报告证据。
|
|
26
26
|
- 禁止 `skip` / `xfail`、吞断言、宽异常静默通过、mock 替代真实目标、删除用例或弱化断言。
|
|
27
27
|
- best-effort 清理只能捕获所选 HTTP client 实际抛出的窄 transport exception,例如 `requests.RequestException` 或 `urllib.error.URLError`;禁止 `except:`、`except Exception`、`except BaseException` 后 `pass`。
|
|
28
28
|
- 同一 Case ID 可以由多个 pytest 函数覆盖;额外映射会进入 traceability 报告,但不能伪造未在 Markdown 中定义的业务场景。
|
|
29
|
-
-
|
|
29
|
+
- 生成 pytest 文件名必须与 Markdown 模块一一对应:`testcase/md/<module>.md` → `testcase/test_<module>.py`(`<module>` 为文件名去 `.md` 后小写、非字母数字转 `_`)。即使 Markdown `自动化映射` 写了别的路径,也必须写模块 stem 路径,不得额外发明 `test_be_*` 前缀。
|
|
30
|
+
- 测试失败必须诚实保留,后续节点只执行一次 pytest,并从同一 pytest-html 报告生成 HTML/facts。
|
|
30
31
|
|
|
31
32
|
## 推荐输出
|
|
32
33
|
|
|
@@ -30,7 +30,7 @@
|
|
|
30
30
|
"Replace REPLACE/WITH/NARROW/IMPLEMENT/PATHS/** with concrete paths before executing the implementation writer",
|
|
31
31
|
"backend-test-dag uses exactly 8 real top-level tasks and executes pytest exactly once over only the safe scripts explicitly mapped by final Markdown cases.",
|
|
32
32
|
"Model nodes produce Markdown and pytest assets, never backend-test business JSON envelopes.",
|
|
33
|
-
"Environment, advisory Markdown validation, advisory traceability,
|
|
33
|
+
"Environment, advisory Markdown validation, advisory traceability, pytest-html, HTML and execution facts are deterministic evidence. Nodes 4 and 6 record findings without blocking nodes 5, 7 or 8.",
|
|
34
34
|
"Only Markdown case generation/review may read source facts; pytest generation must not read source/**.",
|
|
35
35
|
"Functional case IDs use BE-<MODULE>-<NNN>; production code/config, skip/xfail, repair and rerun are forbidden."
|
|
36
36
|
],
|
|
@@ -125,7 +125,7 @@
|
|
|
125
125
|
"artifacts/**"
|
|
126
126
|
],
|
|
127
127
|
"outputContract": "Write a Chinese, human-readable testcase/md/README.md plus module Markdown case cards using BE-<MODULE>-<NNN>; keep machine IDs/literals exact and do not execute pytest or modify production code/config.",
|
|
128
|
-
"subtask_prompt": "Read the upstream environment report. Generate a Markdown-first backend test strategy and cases under testcase/md/**.\n\nWrite human-readable content in Simplified Chinese by default. Keep English only for machine-readable IDs and technical literals such as Case/AC/REQ/BR IDs, HTTP methods, paths, field names, enum values, commands, filenames, code symbols and exact source citations.\n\nCreate testcase/md/README.md as the concise entry page: test objective, target/environment, isolation/cleanup, module summary and a linked case index table with Case ID, Chinese case name, scenario type, endpoint and expected status/result. Avoid repeating every case body in README.\n\nWrite each module as readable case cards. Every case starts with `## BE-<MODULE>-<NNN>|<中文用例名称>`. The only sections required by the deterministic validator are `### 前置条件`, `### 操作步骤`, and `### 预期结果` (legacy English aliases remain accepted). Add `测试目的`, `验收标准`, `需求依据`, `测试数据`, and `自动化映射` when useful for human readability; every automatable case should explicitly name its target pytest script under `自动化映射` so traceability can scan only that script.\n\nPlace steps and their expected results in a compact readable table when that improves clarity; otherwise keep numbered executable steps and numbered/bulleted independently assertable results. Every result must name the observable HTTP status, response field/value, state transition or membership condition, never vague wording such as ‘符合预期’.\n\nIn `自动化映射`, record the planned script path and pytest function name when known. Put implementation-only restrictions in a concise `<details>` block rather than dominating the main case flow. Use only environment-supported fixtures/targets/isolation, record evidence gaps in Chinese, and do not emit JSON, pytest, or execute commands.\n\n## Derived task contract: 需求.md\n\n# Backend test\n- AC-001 proof\n\n## Authoritative reference index\n\n[]\n\nFor each index entry, use `readPath` for Pi read-tool calls and copy `path` exactly into Markdown Source References. Bound files under .harness/tasks/<taskId>/source/** are read-only inputs: reading them is allowed even though writing .harness/** is forbidden. Never resolve `path` relative to the repository root, search for substitutes, or fall back to docs/** when a bound read fails.\n\nRead only precise indexed references needed for AC/API/field/rule evidence; references remain authoritative over derived text."
|
|
128
|
+
"subtask_prompt": "Read the upstream environment report. Generate a Markdown-first backend test strategy and cases under testcase/md/**.\n\nWrite human-readable content in Simplified Chinese by default. Keep English only for machine-readable IDs and technical literals such as Case/AC/REQ/BR IDs, HTTP methods, paths, field names, enum values, commands, filenames, code symbols and exact source citations.\n\nCreate testcase/md/README.md as the concise entry page: test objective, target/environment, isolation/cleanup, module summary and a linked case index table with Case ID, Chinese case name, scenario type, endpoint and expected status/result. Avoid repeating every case body in README.\n\nWrite each module as readable case cards. Every case starts with `## BE-<MODULE>-<NNN>|<中文用例名称>`. The only sections required by the deterministic validator are `### 前置条件`, `### 操作步骤`, and `### 预期结果` (legacy English aliases remain accepted). Add `测试目的`, `验收标准`, `需求依据`, `测试数据`, and `自动化映射` when useful for human readability; every automatable case should explicitly name its target pytest script under `自动化映射` so traceability can scan only that script.\n\nName each module file with a stable lowercase business stem such as `testcase/md/health.md` or `testcase/md/resource_notes.md`. Do not use Case-ID-like module filenames such as `BE-HEALTH.md` or `BE-NOTES.md`. For every automatable case, `自动化映射` must name exactly `testcase/test_<module>.py`, where <module> is that Markdown filename without `.md`, lowercased, with non-alphanumeric characters replaced by underscores. Example: `testcase/md/health.md` → `testcase/test_health.py`; `testcase/md/resource_notes.md` → `testcase/test_resource_notes.py`. Never invent a different pytest path in Markdown than the module stem implies.\n\nPlace steps and their expected results in a compact readable table when that improves clarity; otherwise keep numbered executable steps and numbered/bulleted independently assertable results. Every result must name the observable HTTP status, response field/value, state transition or membership condition, never vague wording such as ‘符合预期’.\n\nIn `自动化映射`, record the planned script path and pytest function name when known, and keep the script path identical to the module one-to-one path above. Put implementation-only restrictions in a concise `<details>` block rather than dominating the main case flow. Use only environment-supported fixtures/targets/isolation, record evidence gaps in Chinese, and do not emit JSON, pytest, or execute commands.\n\n## Derived task contract: 需求.md\n\n# Backend test\n- AC-001 proof\n\n## Authoritative reference index\n\n[]\n\nFor each index entry, use `readPath` for Pi read-tool calls and copy `path` exactly into Markdown Source References. Bound files under .harness/tasks/<taskId>/source/** are read-only inputs: reading them is allowed even though writing .harness/** is forbidden. Never resolve `path` relative to the repository root, search for substitutes, or fall back to docs/** when a bound read fails.\n\nRead only precise indexed references needed for AC/API/field/rule evidence; references remain authoritative over derived text."
|
|
129
129
|
},
|
|
130
130
|
{
|
|
131
131
|
"id": "review-and-revise-backend-md-cases-pi",
|
|
@@ -149,7 +149,7 @@
|
|
|
149
149
|
"artifacts/**"
|
|
150
150
|
],
|
|
151
151
|
"outputContract": "Review source fidelity and directly revise only testcase/md/**; return concise Markdown, never JSON.",
|
|
152
|
-
"subtask_prompt": "Independently review generated Markdown cases against the task requirements and environment evidence. Treat the files as human-facing test documentation: require clear preconditions, executable steps and assertable expected results; improve names, purpose, metadata and automation mapping where useful while preserving exact machine IDs and technical literals.\n\nCheck AC completeness/meaning, endpoint, fields/shape, status/error codes, rules, states, documented boundaries/auth, positive/negative coverage, executable steps and assertable results. Reject avoidable English prose, duplicated bilingual wording, repeated boilerplate, oversized unstructured sections, vague results such as ‘符合预期’, and missing script/function mapping where it can be derived.\n\nCorrect testcase/md/** directly: add documented omissions, remove unsupported cases, fix mappings/
|
|
152
|
+
"subtask_prompt": "Independently review generated Markdown cases against the task requirements and environment evidence. Treat the files as human-facing test documentation: require clear preconditions, executable steps and assertable expected results; improve names, purpose, metadata and automation mapping where useful while preserving exact machine IDs and technical literals.\n\nCheck AC completeness/meaning, endpoint, fields/shape, status/error codes, rules, states, documented boundaries/auth, positive/negative coverage, executable steps and assertable results. Reject avoidable English prose, duplicated bilingual wording, repeated boilerplate, oversized unstructured sections, vague results such as ‘符合预期’, Case-ID-like module filenames (for example `BE-HEALTH.md`), and missing or drifted script/function mapping where it can be derived.\n\nCorrect testcase/md/** directly: add documented omissions, remove unsupported cases, rename module files to stable lowercase stems when needed, fix automation mappings so each case points at `testcase/test_<module>.py` derived from that module filename, merge duplicates, improve navigation/tables/Chinese wording, or record gaps in Chinese. Keep Case IDs, AC/REQ/BR IDs, HTTP methods, paths, fields, enum values, filenames, code symbols and source citations exact. The validator accepts Chinese and legacy English section aliases; retain or converge to the Chinese human-readable headings without losing structure.\n\nRead only precise referenced source paths plus requirement sections needed for uncovered ACs. Do not scan the repository, modify source/**, generate pytest, execute tests, or emit JSON.\n\n## Derived task contract: 需求.md\n\n# Backend test\n- AC-001 proof\n\n## Authoritative reference index\n\n[]\n\nFor each index entry, use `readPath` for Pi read-tool calls and keep `path` as the exact Markdown Source References citation. Bound files under .harness/tasks/<taskId>/source/** are read-only inputs: reading them is allowed even though writing .harness/** is forbidden. Never resolve `path` relative to the repository root, search for substitutes, or fall back to docs/** when a bound read fails."
|
|
153
153
|
},
|
|
154
154
|
{
|
|
155
155
|
"id": "validate-backend-md-cases-shell",
|
|
@@ -203,7 +203,7 @@
|
|
|
203
203
|
"artifacts/**"
|
|
204
204
|
],
|
|
205
205
|
"outputContract": "Convert every final automatable Markdown case into pytest assets whose actual test function region contains the exact Case ID, preferably in the function name or docstring. Each testcase/md/<module>.md (excluding README.md) maps one-to-one to testcase/test_<module>.py; never merge or split modules. No JSON and no pytest execution.",
|
|
206
|
-
"subtask_prompt": "Convert testcase/md/** to pytest using upstream environment and advisory validation evidence plus only bounded pytest config/conftest. A FAIL advisory report does not authorize inventing missing behavior; use the final Markdown facts that are present.\n\nEnsure every final Markdown Case ID appears in at least one real pytest test function or pytest test class method region, preferably as `test_BE_<MODULE>_<NNN>_<description>` and in that function/method docstring. Module-level functions and class-based pytest methods are both supported. Multiple test functions may cover one Case ID; assertions come only from 预期结果/Expected Results and setup comes only from 前置条件 plus any optional 测试数据/自动化映射 or their legacy English aliases.\n\nName each generated pytest file so it corresponds one-to-one with its source Markdown module file: for each `testcase/md/<module>.md` (excluding README.md), emit exactly one `testcase/test_<module>.py`. The <module> stem is the Markdown filename without the `.md` extension, lowercased and with non-alphanumeric characters replaced by underscores. For example, `testcase/md/resource_notes.md` maps to `testcase/test_resource_notes.py`, and `testcase/md/order-api.md` maps to `testcase/test_order_api.py`. Never merge multiple Markdown modules into one pytest file, never split one module across several files, and never invent pytest filenames unrelated to the Markdown modules.\n\nGenerate a reusable HTTP logging helper (or equivalent client wrapper) and call it for every interface request. The request log must include method, URL/path, and request parameters (query plus JSON/body/payload summary). The response log must include status code and response result (JSON/text/body summary), and both records must be visible in pytest stdout/stderr without changing assertions.\n\nCompare timestamps and other semantically equivalent protocol values by parsed meaning, not byte-for-byte serialization. In particular, normalize valid ISO-8601 instants before equality/order assertions so differences such as omitted trailing fractional seconds do not create TestBug failures; preserve exact-string assertions only when the Markdown explicitly requires representation equality.\n\nBefore logging, recursively redact sensitive keys and header values including authorization, proxy-authorization, cookie, set-cookie, token, password, secret, api key and credentials. Never print full Authorization/Cookie values. Apply bounded truncation to serialized request and response bodies (with an explicit truncation marker) so large payloads cannot flood pytest or report artifacts.\n\nDo not read source/**, add cases, reassign ACs, modify conftest/config/production code, use skip/xfail, swallow assertions, execute pytest, or emit JSON. For best-effort cleanup, catch only the narrow transport exception actually raised by the selected HTTP client (for example `requests.RequestException` or `urllib.error.URLError`); never use bare `except`, `Exception`, or `BaseException` with `pass`."
|
|
206
|
+
"subtask_prompt": "Convert testcase/md/** to pytest using upstream environment and advisory validation evidence plus only bounded pytest config/conftest. A FAIL advisory report does not authorize inventing missing behavior; use the final Markdown facts that are present.\n\nEnsure every final Markdown Case ID appears in at least one real pytest test function or pytest test class method region, preferably as `test_BE_<MODULE>_<NNN>_<description>` and in that function/method docstring. Module-level functions and class-based pytest methods are both supported. Multiple test functions may cover one Case ID; assertions come only from 预期结果/Expected Results and setup comes only from 前置条件 plus any optional 测试数据/自动化映射 or their legacy English aliases.\n\nName each generated pytest file so it corresponds one-to-one with its source Markdown module file: for each `testcase/md/<module>.md` (excluding README.md), emit exactly one `testcase/test_<module>.py`. The <module> stem is the Markdown filename without the `.md` extension, lowercased and with non-alphanumeric characters replaced by underscores. For example, `testcase/md/resource_notes.md` maps to `testcase/test_resource_notes.py`, `testcase/md/health.md` maps to `testcase/test_health.py`, `testcase/md/BE-HEALTH.md` maps to `testcase/test_be_health.py`, and `testcase/md/order-api.md` maps to `testcase/test_order_api.py`. If Markdown automation mapping names a different path than this module stem path, still write the module stem path and do not invent prefixes such as `test_be_*` unless the module filename itself normalizes to that stem. Never merge multiple Markdown modules into one pytest file, never split one module across several files, and never invent pytest filenames unrelated to the Markdown modules.\n\nGenerate a reusable HTTP logging helper (or equivalent client wrapper) and call it for every interface request. The request log must include method, URL/path, and request parameters (query plus JSON/body/payload summary). The response log must include status code and response result (JSON/text/body summary), and both records must be visible in pytest stdout/stderr without changing assertions.\n\nCompare timestamps and other semantically equivalent protocol values by parsed meaning, not byte-for-byte serialization. In particular, normalize valid ISO-8601 instants before equality/order assertions so differences such as omitted trailing fractional seconds do not create TestBug failures; preserve exact-string assertions only when the Markdown explicitly requires representation equality.\n\nBefore logging, recursively redact sensitive keys and header values including authorization, proxy-authorization, cookie, set-cookie, token, password, secret, api key and credentials. Never print full Authorization/Cookie values. Apply bounded truncation to serialized request and response bodies (with an explicit truncation marker) so large payloads cannot flood pytest or report artifacts.\n\nDo not read source/**, add cases, reassign ACs, modify conftest/config/production code, use skip/xfail, swallow assertions, execute pytest, or emit JSON. For best-effort cleanup, catch only the narrow transport exception actually raised by the selected HTTP client (for example `requests.RequestException` or `urllib.error.URLError`); never use bare `except`, `Exception`, or `BaseException` with `pass`."
|
|
207
207
|
},
|
|
208
208
|
{
|
|
209
209
|
"id": "backend-test-traceability-gate-shell",
|
|
@@ -250,8 +250,8 @@
|
|
|
250
250
|
".harness/dag-runs/**",
|
|
251
251
|
"artifacts/**"
|
|
252
252
|
],
|
|
253
|
-
"outputContract": "One scoped pytest execution over Markdown-mapped scripts producing valid
|
|
254
|
-
"subtask_prompt": "Resolve the final Markdown Automation Notes/自动化映射 to a unique, safe set of testcase/**/test_*.py targets and execute only those scripts exactly once.
|
|
253
|
+
"outputContract": "One scoped pytest execution over Markdown-mapped scripts producing a valid pytest-html report with per-case captured output, self-contained reports/backend-test.html and reports/backend-test.md, plus internal reports/backend-test-facts.md evidence; exit 0/1 with valid evidence continues.",
|
|
254
|
+
"subtask_prompt": "Resolve the final Markdown Automation Notes/自动化映射 to a unique, safe set of testcase/**/test_*.py targets and execute only those scripts exactly once. Prefer the deterministic module one-to-one path when a mapped script is missing but the module stem file exists. Generate a native pytest-html self-contained report, then render the primary self-contained Chinese HTML report from the same pytest-html plus final Markdown case metadata without rerun. Keep 测试结论, quality status, failure overview, and a polished per-case result card with concise scenario, automation test name, result, duration, and redacted bounded HTTP request parameters/response results for both passed and failed cases. Do not render a technical/execution evidence section in HTML; retain auditable paths and hashes in facts.",
|
|
255
255
|
"shell": {
|
|
256
256
|
"commands": [
|
|
257
257
|
"mkdir -p \"${HARNESS_DAG_RUN_DIR}/reports\"; echo \"pytest targets are resolved at runtime from final Markdown 自动化映射\""
|
|
@@ -284,7 +284,7 @@
|
|
|
284
284
|
"artifacts/**"
|
|
285
285
|
],
|
|
286
286
|
"outputContract": "Final Markdown report and L-5 conclusion under docs/test-reports/**; no JSON.",
|
|
287
|
-
"subtask_prompt": "Generate the final Markdown report from upstream facts and run-owned environment, advisory case-validation, advisory traceability,
|
|
287
|
+
"subtask_prompt": "Generate the final Markdown report from upstream facts and run-owned environment, advisory case-validation, advisory traceability, pytest-html and HTML evidence. Do not emit JSON.\n\nUse this exact human-facing section order: 测试结论 → 执行概览 → 质量校验 → 失败分析 → 风险与建议 → 证据与 L-5. Put the decision and key numbers first, use compact tables/bullets, and keep headings concise. Do not paste entire upstream reports, duplicate per-case tables already present in facts, or repeat the same evidence in multiple sections; link to paths/hashes and quote only the findings needed for the conclusion.\n\nAlways state the exact PASS/FAIL status and findings from nodes 4 and 6. Their FAIL status does not block pytest, but it must remain visible as a quality/traceability risk and must never be rewritten as PASS.\n\nInclude environment, case quality/review, automation mapping, exact pytest facts, failure classification/analysis, risks, regression recommendations, evidence paths/hashes, coverage availability, and L-5 READY/NOT READY.\n\nNever override Shell/pytest-html facts. L-5 requires pass=100%, AC=100%, automation>=90%, line>=80%, branch>=70%, skipped=0 and no blocking Critical risk.\n\nWrite only under docs/test-reports/**."
|
|
288
288
|
}
|
|
289
289
|
],
|
|
290
290
|
"sourceBinding": {
|
|
@@ -47,7 +47,6 @@ This node runs on **both pass and assertion-fail** paths after canonical context
|
|
|
47
47
|
3. **Classification** — `classify-backend-test-result-pi` JSON (`category`, `confidence`, `evidence`). Interpretive only; does not override outcome.
|
|
48
48
|
4. **Review report** — `review-backend-cases-pi` output (VERDICT, findings, coverage assessment).
|
|
49
49
|
5. **Code Coverage v1** — optional validated `contracts/code-coverage-v1.json`, generated by coverage.py/pytest-cov or JaCoCo. Never infer it from Result v1.
|
|
50
|
-
6. **Stability Evidence** — optional independent contract for repeated runs of the same suite and version.
|
|
51
50
|
7. Optional secondary: execute stdout markers / JUnit path (do not re-parse logs for counts when Result v1 exists).
|
|
52
51
|
|
|
53
52
|
Do NOT re-read source documents. Use upstream outputs only.
|
|
@@ -58,7 +57,6 @@ Do NOT re-read source documents. Use upstream outputs only.
|
|
|
58
57
|
- AC coverage = `coverageSummary.acCoverageRatio` from Case Manifest v1 only (do **not** recompute or invent percentages).
|
|
59
58
|
- Automation coverage = `coverageSummary.generatedCount / coverageSummary.caseCount`; if either field is missing, output `unavailable`.
|
|
60
59
|
- Code coverage = Code Coverage v1 only. Display line (gate ≥80%), branch (gate ≥70%), and function/method (display only), each with covered, total, ratio, status, reason, source scope, requirement IDs, tool/version, commit and artifact SHA-256. Missing artifacts or line/branch metrics are `unavailable` and block L-5.
|
|
61
|
-
- Stability = Stability Evidence `successfulRuns / recordedRuns`, same suite and version, minimum `n≥5`; one run is `unavailable` and cannot prove `FlakyTest`.
|
|
62
60
|
- Failed case table rows must match `failures[]` from Result v1.
|
|
63
61
|
- If Result v1 `outcome` is not `passed`, the retrospective **must not** claim overall success.
|
|
64
62
|
|
|
@@ -105,7 +103,6 @@ Write the report as a Markdown file named `backend-test-retrospect-<date>.md` un
|
|
|
105
103
|
| Code line coverage | N / N (X%), threshold ≥80%, status |
|
|
106
104
|
| Code branch coverage | N / N (X%), threshold ≥70%, status |
|
|
107
105
|
| Code function/method coverage | N / N (X%) or unavailable |
|
|
108
|
-
| Stability | successfulRuns / recordedRuns (X%), n, or unavailable |
|
|
109
106
|
|
|
110
107
|
Code coverage must include language, tool/version, requirement IDs, source scope, commit and artifact SHA-256.
|
|
111
108
|
|
|
@@ -22,7 +22,7 @@
|
|
|
22
22
|
- 对照每条 `需求依据` 和环境报告检查 AC、接口、字段/响应形状、状态码、错误语义、状态转换、正向/异常/边界场景。
|
|
23
23
|
- 删除无依据场景、合并重复用例、补齐有依据的遗漏;无法确认的内容写入中文证据缺口,不猜测行为或凭据。
|
|
24
24
|
- 拒绝“符合预期”“正常工作”等模糊结果,以及无意义的中英双写和大段重复 boilerplate。
|
|
25
|
-
- 若能确定脚本与函数命名,在 `自动化映射` 中写明计划脚本路径与 pytest
|
|
25
|
+
- 若能确定脚本与函数命名,在 `自动化映射` 中写明计划脚本路径与 pytest 函数/方法名;脚本路径必须等于模块 one-to-one 路径 `testcase/test_<module>.py`,`<module>` 来自当前 Markdown 文件名 stem,不得使用 Case-ID 式模块名(如 `BE-HEALTH.md`)或与模块 stem 不一致的映射。
|
|
26
26
|
|
|
27
27
|
## 推荐输出
|
|
28
28
|
|
|
@@ -37,7 +37,7 @@
|
|
|
37
37
|
4. 涉及测试纪律/验证声明/调试时继续读:`docs/harness-methodology-*.md`。
|
|
38
38
|
5. 查看最近提交、相关 plan/progress/report;`git status --short --branch`;跑最小基线验证。
|
|
39
39
|
6. 后端/接口/pytest → `taskKind: "backend-test"`(不是 `--profile`);知识回写 `knowledge-sync`;图谱开荒 `knowledge-graph-bootstrap`。`--profile` 仅 `auto|minimal|standard|reviewed|supervised`。
|
|
40
|
-
7. 看板/observe → `agent-worker console serve --repo . --port 8790
|
|
40
|
+
7. 看板/observe → `agent-worker console`(默认 repo=当前目录、port=8790;兼容 `agent-worker console serve --repo . --port 8790`)(`/inspect/` 只读);`observe serve` 仅为兼容入口。
|
|
41
41
|
8. 分支合并 → 先读 `docs/operations/branch-merge-guideline.md`。
|
|
42
42
|
|
|
43
43
|
## 会话协议
|
|
@@ -54,7 +54,7 @@
|
|
|
54
54
|
10. 检查 `git status --short --branch`。
|
|
55
55
|
11. 运行本次任务相关的最小基线验证。
|
|
56
56
|
12. 如果用户提到"后端测试"、"接口测试"、"pytest"、"自动化测试",在任务 `task.json` 中设置 `taskKind: "backend-test"` 再 `dag run-task`;不要用 `--profile backend-test`(CLI 不接受该值,专用模板只走 taskKind)。知识回写用 `taskKind: "knowledge-sync"`(须 `featureId`),图谱开荒用 `taskKind: "knowledge-graph-bootstrap"`。`--profile` 仅表示治理强度:`auto|minimal|standard|reviewed|supervised`。
|
|
57
|
-
13. 如果用户提到"看板"、"observe"、"监控面板"、"启动看板",使用 `agent-worker console serve --repo . --port 8790
|
|
57
|
+
13. 如果用户提到"看板"、"observe"、"监控面板"、"启动看板",使用 `agent-worker console` 启动统一 Operator Console(默认 repo=当前目录、port=8790;兼容入口 `agent-worker console serve --repo . --port 8790`);`/inspect/` 提供只读检视。`agent-worker observe serve --repo . --port 8787` 仅为兼容入口。
|
|
58
58
|
14. 如果用户要求“合并 `<source>` 到 `<target>`”或“合并 origin/main 到当前分支”,先阅读 `docs/operations/branch-merge-guideline.md`,按影响自动选择快速、标准或深度模式;始终冻结 source SHA、审查双方功能、运行 merge-tree、生成 source-SHA 合并报告,并在提交前再次 fetch 防止主干前进。
|
|
59
59
|
|
|
60
60
|
## 会话协议
|
|
@@ -89,7 +89,7 @@
|
|
|
89
89
|
- 长期决策写入 `docs/`,不要只留在聊天里。
|
|
90
90
|
- 分支合并遵循 `docs/operations/branch-merge-guideline.md`;快速模式只用于可证明的低风险/no-op 合并,涉及冲突、init/package/runtime/release/public API 时必须升级为标准或深度模式。
|
|
91
91
|
- 后端测试、接口/API 测试、pytest 或明确的后端自动化测试,必须把 `.harness/tasks/<task-id>/task.json` 的 `taskKind` 设置为 `"backend-test"`,不得保留默认 `standard`。`backend-test` 是 `taskKind`,不是 `--profile` 的可选值;`dag run-task` 继续使用 `--profile auto` 选择治理等级。仅说“自动化测试”且前后端不明时,先根据任务源和项目技术栈判断,禁止无条件路由。
|
|
92
|
-
- 本地 Operator Console:`agent-worker console serve --repo . --port 8790
|
|
92
|
+
- 本地 Operator Console:`agent-worker console`(默认 repo=当前目录、port=8790;兼容 `agent-worker console serve --repo . --port 8790`),访问 `http://127.0.0.1:8790/`;其中 `/inspect/` 为只读运行检视。默认绑定本机 `127.0.0.1`;可用 `--host 0.0.0.0` / `--debug`,不要直接暴露到公开网络。端口被占用时不会自动更换,请用 `--port <port>` 显式指定。
|
|
93
93
|
- 面向使用者的新增、修改、删除或修复,应同步更新根目录 `CHANGELOG.md`;保持版本级摘要即可,不写过细技术细节。
|
|
94
94
|
- 面向用户的中文更新日志、README 和说明文档应使用自然、结果导向的表达:先说明用户能获得什么或问题如何改善,保留必要的命令和产品术语,避免逐字翻译、内部实现细节和无意义的中英混杂。
|
|
95
95
|
- 涉及 `loop-agent init` 或目标项目投影的改动,必须同步考虑目标项目生成物:`AGENTS.md`、`README.md`、`harness.json`、`ai_workspace/loop-agent/`、`scripts/`、`.agents/skills/`、`.harness/prompts`、`.gitignore`(loop-agent runtime managed block)和 npm 包内置 assets;目标项目根 `docs/` 和根 `skills/` 的旧投影需要由 `init update --apply-safe` 安全迁移或退役。
|
package/harness.json
CHANGED
|
@@ -58,8 +58,8 @@
|
|
|
58
58
|
"executors": {
|
|
59
59
|
"pi": {
|
|
60
60
|
"description": "Pi planning, review, diagnosis, and bounded writing when DAG toolProfile=write",
|
|
61
|
-
"LOW": "
|
|
62
|
-
"MED": "
|
|
61
|
+
"LOW": "grok-4.5",
|
|
62
|
+
"MED": "grok-4.5",
|
|
63
63
|
"HIGH": "gpt-5.6-sol"
|
|
64
64
|
}
|
|
65
65
|
}
|
package/package.json
CHANGED
|
@@ -16,7 +16,7 @@ references:
|
|
|
16
16
|
- **允许**:`agent-worker` / `loop-agent` CLI;只读 `pool doctor`、`observe`、status/report;冻结 controller identity;选择 Ready 工作与 recovery 命令。
|
|
17
17
|
- **禁止**:绕过 CLI 直接 Edit 业务实现;Worker/DAG 失败后主会话「救火改文件」。
|
|
18
18
|
- **失败时只允许**:保留 evidence → `task retry` / `task reconcile` / `pool mark-failed` / human gate → 再经 CLI 重跑;实现写入仍只经 published `loop-agent` DAG。
|
|
19
|
-
- **Official vs Compatibility**:`agent-worker console
|
|
19
|
+
- **Official vs Compatibility**:`agent-worker console` 是 Official 本地控制面(裸入口直接启动;默认 repo=当前目录、port=8790;兼容入口 `agent-worker console serve --repo . --port 8790` 等价)。同进程提供 Operate + Inspect,Inspect 路径 `/inspect/#/...`;openCode 等主会话仍是 Compatibility Assist,二者**不是**同等保证。原 `observe serve` 为兼容期只读入口(启动时输出 `OBSERVE_SERVE_DEPRECATED`,stdout 仍只输出 URL),功能等价于 Console 的 Inspect 面。
|
|
20
20
|
|
|
21
21
|
## Route the Work
|
|
22
22
|
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: loop-agent
|
|
3
3
|
description: >-
|
|
4
|
-
Use when implementing features, processing PRDs or requirements, running structured loop-agent workflows, creating harness tasks, using Agent DAG, run-dag, pi-prompt planning/review, cursor-prompt one-shot sidecar intervention, initializing a target project with loop-agent, checking init update status, applying a safe init update, or converging website/governance docs after user-visible changes in loop-agent. Triggers: loop-agent, workflow, structured development, harness task, Agent DAG, docs converge, Converge Docs, 文档收敛, 结构化开发, 工作流, 需求实现, PRD 实现, 初始化 loop-agent, loop agent 初始化, loop agent初始化, loop-agent 初始化, 初始化更新校验, loop agent初始化更新校验, 检查初始化更新, 初始化安全更新, loop agent初始化安全更新, 应用初始化更新.
|
|
4
|
+
Use when implementing features, processing PRDs or requirements, running structured loop-agent workflows, creating harness tasks, using Agent DAG, run-dag, pi-prompt planning/review, cursor-prompt one-shot sidecar intervention, initializing a target project with loop-agent, checking init update status, applying a safe init update, or converging website/governance docs after user-visible changes in loop-agent. Triggers: loop-agent, workflow, structured development, harness task, Agent DAG, docs converge, Converge Docs, 文档收敛, 结构化开发, 工作流, 需求实现, PRD 实现, 初始化 loop-agent, loop agent 初始化, loop agent初始化, loop-agent 初始化, 初始化更新校验, loop agent初始化更新校验, 检查初始化更新, 初始化安全更新, loop agent初始化安全更新, 应用初始化更新. 强路由:loop-agent 帮我完成需求, 帮我实现, 帮我修复, 帮我开发, 使用 loop-agent 完成, 按 loop-agent 流程处理, 通用需求实现;这些表达确定性地进入 Agent DAG/CLI(new-task, dag run-task, dag validate, run-dag),主会话编排而不直接写业务实现.
|
|
5
5
|
references:
|
|
6
6
|
- path: references/harness-policy.md
|
|
7
7
|
required: true
|
|
@@ -117,6 +117,7 @@ SDK 回归或 SDK 可选依赖不可用时用 `cli-only` 诊断。CLI fallback
|
|
|
117
117
|
| 初始化更新校验 / loop agent初始化更新校验 / 检查初始化更新 | `loop-agent init check-update --repo-root . --markdown`(只读,不得隐含 `apply-safe`) |
|
|
118
118
|
| 初始化安全更新 / loop agent初始化安全更新 / 应用初始化更新 | 先 `loop-agent init check-update --repo-root . --markdown`,再 `loop-agent init update --repo-root . --apply-safe`(surface 缺失时先 `--bootstrap-surface`;human decisions 存在时停下等用户) |
|
|
119
119
|
| 初始化对齐 / 升级后对齐 / init reconcile / 控制器升级后对齐目标项目 | `loop-agent init reconcile --repo-root .`(统一入口:surface 缺失返回 `needs-baseline` 零写入;human decisions 返回 `needs-human-decision` 零写入;活跃 DAG/Worker 或 Worker 状态无法确认时返回 `blocked-active-runtime` 零写入;其余执行 safe actions 后复查) |
|
|
120
|
+
| loop-agent 帮我完成 / 帮我实现 / 帮我修复 / 帮我开发 <需求>;使用 loop-agent 完成 <X>;按 loop-agent 流程处理 <X> | 先 `loop-agent new-task <task-id> "任务标题"`,写 `source/需求.md` 与 `source/执行约束.md`,同步 `task.json.allowedPaths` / `forbiddenPaths`,再 `loop-agent dag run-task <task-id> --profile auto --strict-models`、`dag validate`、`run-dag`;主会话编排而不直接写业务实现 |
|
|
120
121
|
|
|
121
122
|
```bash
|
|
122
123
|
loop-agent init instructions --repo-root <target-repo>
|