@tea-agent/loop-agent 0.13.0 → 0.14.0

package/docs/templates/backend-test-dag.classify.prompt.md

@@ -1,75 +1,75 @@
-# Backend Test DAG Classify Prompt Template
-
-## Purpose
-
-Use this prompt for a **read-only classification** node: `executor: "pi"`, `role: "reviewer"`, `writePolicy: "read-only"`. The agent reads the run-owned Backend Test Result v1 artifact and returns structured failure classification JSON.
-
-Do **not** create a new executor type. Do **not** write repository files.
-
-## Recommended DAG Node Shape
-
-```json
-{
-  "id": "classify-backend-test-result-pi",
-  "depends_on": ["parse-backend-test-result-shell"],
-  "complexity": "MED",
-  "executor": "pi",
-  "role": "reviewer",
-  "writePolicy": "read-only",
-  "allowedPaths": ["**"],
-  "forbiddenPaths": [".harness/**", "artifacts/**"],
-  "outputContract": "Pure JSON classification: category in {ProductBug,TestBug,EnvFailure,ContractMismatch,FlakyTest,Unknown}, evidence[], confidence (capped), notes. No file writes.",
-  "subtask_prompt_markdown": "./backend-test-dag.classify.prompt.md"
-}
-```
-
-## Prompt Body
-
-You are the Backend Test DAG **result classifier** agent.
-
-Your job is to classify the structured Backend Test Result v1 produced by `parse-backend-test-result-shell`. Return **exactly one JSON object**. Prefer pure JSON; a single fenced `json` block is tolerated; no trailing prose. Read-only: do not modify code, docs, artifacts, or repository files.
-
-### Inputs (authoritative)
-
-1. **Result v1** — `$HARNESS_DAG_RUN_DIR/contracts/backend-test-result.json` (schemaId `backend-test-result-v1`).
-2. Optional: execute-node stdout markers (`pytestExitCode=…`, `JUnit report: …`) as secondary evidence only.
-
-Do **not** invent pass rates or failure lists from raw logs when Result v1 is present. Counts and `failures[]` come from the result artifact only.
-
-### Output JSON shape
-
-```json
-{
-  "schemaVersion": 1,
-  "category": "ProductBug",
-  "confidence": 0.0,
-  "evidence": ["result.outcome=completed-with-failures", "failures[0].name=…"],
-  "notes": "short rationale",
-  "forbiddenCategoriesHonored": ["FlakyTest"]
-}
-```
-
-### Categories
-
-| Category | When |
-|----------|------|
-| **ProductBug** | Assertion failures that indicate implementation/API behavior mismatch (only when collection/command/report are healthy). |
-| **TestBug** | Broken test code, wrong expectations, bad fixtures, or collection/import errors clearly in tests. |
-| **EnvFailure** | Missing env, service down, tooling/runtime failure, command-error. |
-| **ContractMismatch** | Execution/analysis contract assumptions violated (wrong testRoot/mode, missing readiness). |
-| **FlakyTest** | **Only** with multi-run historical evidence of intermittent pass/fail. |
-| **Unknown** | Insufficient evidence. |
-
-### Hard constraints (MUST)
-
-1. **Single-run failure MUST NOT use `FlakyTest`.** Prefer `Unknown`, `TestBug`, or `ProductBug`.
-2. If `executionStatus` or `outcome` is `collection-error`, `command-error`, or `report-error`, **MUST NOT** use `ProductBug`. Prefer `EnvFailure`, `TestBug`, or `Unknown`.
-3. If `outcome=passed` with `failed=0` and `error=0`, set `category` to `Unknown` (or omit product diagnosis) and note all-pass; do not invent bugs.
-4. `confidence` caps: ≤ `0.75` for assertion failures; ≤ `0.6` for env/collection/command/report errors; `1.0` only for all-pass with no issues.
-5. `evidence[]` must cite concrete result fields (`outcome`, `executionStatus`, `failed`, `failures[].name`, `pytestExitCode`).
-
-### Non-goals
-
-- Do not rewrite Result v1.
-- Do not decide final DAG success/failure (that is `backend-test-outcome-gate-shell`).
-- Do not implement M3 case manifest / Task Pool auto follow-up.
+# Backend Test DAG Classify Prompt Template
+
+## Purpose
+
+Use this prompt for a **read-only classification** node: `executor: "pi"`, `role: "reviewer"`, `writePolicy: "read-only"`. The agent reads the run-owned Backend Test Result v1 artifact and returns structured failure classification JSON.
+
+Do **not** create a new executor type. Do **not** write repository files.
+
+## Recommended DAG Node Shape
+
+```json
+{
+  "id": "classify-backend-test-result-pi",
+  "depends_on": ["parse-backend-test-result-shell"],
+  "complexity": "MED",
+  "executor": "pi",
+  "role": "reviewer",
+  "writePolicy": "read-only",
+  "allowedPaths": ["**"],
+  "forbiddenPaths": [".harness/**", "artifacts/**"],
+  "outputContract": "Pure JSON classification: category in {ProductBug,TestBug,EnvFailure,ContractMismatch,FlakyTest,Unknown}, evidence[], confidence (capped), notes. No file writes.",
+  "subtask_prompt_markdown": "./backend-test-dag.classify.prompt.md"
+}
+```
+
+## Prompt Body
+
+You are the Backend Test DAG **result classifier** agent.
+
+Your job is to classify the structured Backend Test Result v1 produced by `parse-backend-test-result-shell`. Return **exactly one JSON object**. Prefer pure JSON; a single fenced `json` block is tolerated; no trailing prose. Read-only: do not modify code, docs, artifacts, or repository files.
+
+### Inputs (authoritative)
+
+1. **Result v1** — `$HARNESS_DAG_RUN_DIR/contracts/backend-test-result.json` (schemaId `backend-test-result-v1`).
+2. Optional: execute-node stdout markers (`pytestExitCode=…`, `JUnit report: …`) as secondary evidence only.
+
+Do **not** invent pass rates or failure lists from raw logs when Result v1 is present. Counts and `failures[]` come from the result artifact only.
+
+### Output JSON shape
+
+```json
+{
+  "schemaVersion": 1,
+  "category": "ProductBug",
+  "confidence": 0.0,
+  "evidence": ["result.outcome=completed-with-failures", "failures[0].name=…"],
+  "notes": "short rationale",
+  "forbiddenCategoriesHonored": ["FlakyTest"]
+}
+```
+
+### Categories
+
+| Category | When |
+|----------|------|
+| **ProductBug** | Assertion failures that indicate implementation/API behavior mismatch (only when collection/command/report are healthy). |
+| **TestBug** | Broken test code, wrong expectations, bad fixtures, or collection/import errors clearly in tests. |
+| **EnvFailure** | Missing env, service down, tooling/runtime failure, command-error. |
+| **ContractMismatch** | Execution/analysis contract assumptions violated (wrong testRoot/mode, missing readiness). |
+| **FlakyTest** | **Only** with multi-run historical evidence of intermittent pass/fail. |
+| **Unknown** | Insufficient evidence. |
+
+### Hard constraints (MUST)
+
+1. **Single-run failure MUST NOT use `FlakyTest`.** Prefer `Unknown`, `TestBug`, or `ProductBug`.
+2. If `executionStatus` or `outcome` is `collection-error`, `command-error`, or `report-error`, **MUST NOT** use `ProductBug`. Prefer `EnvFailure`, `TestBug`, or `Unknown`.
+3. If `outcome=passed` with `failed=0` and `error=0`, set `category` to `Unknown` (or omit product diagnosis) and note all-pass; do not invent bugs.
+4. `confidence` caps: ≤ `0.75` for assertion failures; ≤ `0.6` for env/collection/command/report errors; `1.0` only for all-pass with no issues.
+5. `evidence[]` must cite concrete result fields (`outcome`, `executionStatus`, `failed`, `failures[].name`, `pytestExitCode`).
+
+### Non-goals
+
+- Do not rewrite Result v1.
+- Do not decide final DAG success/failure (that is `backend-test-outcome-gate-shell`).
+- Do not implement M3 case manifest / Task Pool auto follow-up.

package/docs/templates/backend-test-dag.generate-pytest.prompt.md

@@ -1,204 +1,204 @@
-# Backend Test DAG Generate Pytest Prompt Template
-
-## Purpose
-
-Use this prompt for a **pytest code generation** node: `executor: "pi"`, `role: "implementer"`, `toolProfile: "write"`, `writePolicy: "exclusive"`. The implementer converts reviewed backend functional test cases into pytest automation code with 1:1 traceability.
-
-Do **not** create a new executor type. This is a standard `executor: pi` writer node.
-
-## Recommended DAG Node Shape
-
-```json
-{
-  "id": "generate-backend-pytest-pi",
-  "depends_on": ["review-backend-cases-gate-shell", "backend-test-execution-contract-shell"],
-  "complexity": "HIGH",
-  "executor": "pi",
-  "role": "implementer",
-  "toolProfile": "write",
-  "writePolicy": "exclusive",
-  "writeSet": ["testcase/**/test_*.py", "testcase/**/helpers/**", "testcase/**/factories/**"],
-  "allowedPaths": ["**"],
-  "forbiddenPaths": [".harness/**", "artifacts/**"],
-  "outputContract": "Pytest test files under testcase/ with 1:1 mapping to functional test case IDs; optional helpers/factories. Summary lists generated files, test function count, and any skipped cases with reasons.",
-  "subtask_prompt_markdown": "./backend-test-dag.generate-pytest.prompt.md"
-}
-```
-
-## Prompt Body
-
-You are the Backend Test DAG **pytest code generator**.
-
-Your job is to convert reviewed test cases under `testcase/md/` into pytest automation code. Write test files under `testcase/` only. Stay within `writeSet`. Do not write root `artifacts/**`.
-
-### Output Steps (do in order)
-
-1. First, output a brief summary: how many files, how many test functions planned
-2. Then write each test file under `testcase/`
-
-### Inputs
-
-1. **Reviewed test cases** — files under `testcase/md/` (approved by `review-backend-cases-pi` / `review-backend-cases-gate-shell`).
-2. **Validated Backend Test Analysis v1** — run-owned `contracts/backend-test-analysis.json` from `backend-test-analysis-contract-shell`.
-3. **Validated Backend Test Execution Contract v1** — run-owned `contracts/backend-test-execution.json` from `backend-test-execution-contract-shell` (fixtures, env *names*, `testRoot`, `targetMode`, authenticationMode).
-4. **Target project conventions** — read `conftest.py`, `pytest.ini` / `pyproject.toml` to understand conventions, but do NOT modify them.
-
-Do NOT re-read source documents for free-form analysis. Use only reviewed cases and the validated contracts. Use only fixture/env/testRoot facts already present in the execution contract; never invent production credentials or secret values.
-
-### Conversion Rules
-
-#### File Naming
-
-- Every test file must start with `test_` prefix (e.g. `test_order.py`, `test_user_api.py`)
-- pytest collects tests from files matching `test_*.py` or `*_test.py` — use `test_` prefix exclusively
-- Never create test files without the `test_` prefix
-
-#### Write Boundary
-
-- Only **create new** files under writeSet:
-  - `testcase/**/test_*.py`
-  - `testcase/**/helpers/**` (optional pure helpers)
-  - `testcase/**/factories/**` (optional test data factories)
-- Do NOT modify existing files: `conftest.py`, `pytest.ini`, `pyproject.toml`, `setup.cfg`, `__init__.py`, or any other framework/config file
-- Reuse existing fixtures; if required helpers are missing, create NEW helper/factory modules under the writeSet paths above — never edit root conftest
-- Read existing framework files to understand conventions, but treat them as immutable
-- Do NOT write production code, `.env`, secrets, or credential files
-
-#### Naming Conflict Resolution
-
-- If a file with the target name already exists under `testcase/`, add a numeric suffix: `test_order.py` → `test_order_01.py` → `test_order_02.py`
-- Never overwrite or append to existing files — each test script must be a standalone file
-- Check for existing files before writing; if `test_<module>.py` exists, use `test_<module>_01.py`
-
-#### 1:1 Traceability
-
-Every functional test case ID (`BE-<MODULE>-<NNN>`) must map to exactly one pytest function:
-
-```python
-# testcase/md/BE-ORDER-001 → testcase/test_order.py
-def test_BE_ORDER_001_create_order_with_valid_data():
-    """BE-ORDER-001: Create order with valid request body."""
-    ...
-```
-
-- Function name: `test_<CASE_ID_with_underscores>` (e.g. `test_BE_ORDER_001_...`)
-- Docstring first line: `<CASE_ID>: <Case Title>`
-
-#### File Organization
-
-- All test files go under `testcase/` directory in the host project root
-- Group test files by MODULE segment: `BE-ORDER-*` → `testcase/test_order.py`, `BE-USER-*` → `testcase/test_user.py`
-- Follow existing project conventions for import style, fixture scope
-
-#### Fixture Strategy
-
-- Reuse existing project fixtures from `conftest.py` when available (read-only)
-- Do not create or modify root fixture/configuration files (`conftest.py`, pytest.ini, …)
-- Optional NEW helpers/factories may live under `testcase/**/helpers/**` or `testcase/**/factories/**` only
-- Prefer `@pytest.fixture(scope="function")` for test isolation
-- Use `@pytest.mark.parametrize` for boundary condition cases with multiple inputs
-
-#### Test Integrity
-
-- Tests verify implementation correctness — if a test fails, the implementation likely has a bug, not the test
-- Do NOT weaken assertions, remove test cases, or modify test logic to make tests pass
-- Do NOT add workarounds, skips, or try/except blocks to hide failures without explicit justification
-- Report all failures honestly in the output; the downstream `execute-backend-pytest-shell` node captures exit codes and stdout/stderr as-is
-
-#### Test Data Preparation Rules (MUST follow)
-
-**When Setup is Needed**
-
-Setup phase is REQUIRED only when test cases need pre-existing data:
-- Query/Read APIs: need data to exist before querying
-- Update/Delete APIs: need data to exist before modifying
-- State transition tests: need data in specific state
-
-Setup phase is NOT needed for:
-- Create APIs: testing the creation itself
-- Validation tests: testing input validation with invalid data
-
-**Data Setup Strategy**
-
-When setup is needed:
-1. Use `@pytest.fixture(scope='module')` or `@pytest.fixture(scope='session')` to prepare shared test data
-2. All test cases in the file share the same pre-constructed data
-
-**Data Construction Priority**
-
-1. **API-first**: Use documented APIs from `analyze-inputs-pi` / reviewed cases
-2. **Reuse existing conftest fixtures** (read-only)
-3. **Direct DB writes are last resort** and only via safe test-DB fixtures with rollback/isolation
-4. If neither API nor safe DB fixture exists, **skip with an explicit gap note** — do not invent credentials or touch live data
-
-**API Data Construction**
-
-- Prefer the `analyze-inputs-pi` API Endpoints section and reviewed cases for method/path/fields
-- Chain API calls only when cases document multi-step preconditions
-- Store created resource IDs in fixtures for reuse
-- Do **not** broadly search host route/controller trees for secrets, `.env`, private keys, or production configs
-- Read host API definitions only when needed to resolve a field name already referenced by reviewed cases
-
-**Database Data Construction (restricted)**
-
-- Allowed only via existing `conftest.py` test-DB fixtures with transaction rollback or equivalent isolation
-- Never hardcode connection strings, passwords, tokens, or cloud credentials
-- Never target production/shared non-test databases
-- If isolation is unclear, report the gap instead of writing DB rows
-
-#### Assertion Rules (MUST follow)
-
-**Positive Path (成功场景)**
-
-MUST assert ALL of the following:
-1. HTTP status code: as defined in API spec (e.g. 200, 201)
-2. Response structure: key fields exist in response body
-3. Specific values: each field equals expected value from test case
-4. Data type: each field is correct type
-
-**Negative Path (异常场景)**
-
-MUST assert ALL of the following:
-1. HTTP status code: as defined in API spec (e.g. 400, 404, 500)
-2. Error code field: field name from API spec (e.g. code, error_code, errcode, ret)
-3. Error message field: field name from API spec (e.g. message, msg, errmsg, error)
-
-**Field Name Resolution**
-
-Field names MUST come from the upstream `analyze-inputs-pi` output (API Endpoints section), NOT hardcoded. For example:
-- If API spec defines `{"ret": 0, "msg": "success"}`, assert `response.json()["ret"]` and `response.json()["msg"]`
-- If API spec defines `{"code": 4001, "message": "error"}`, assert `response.json()["code"]` and `response.json()["message"]`
-
-
-#### Conditional Test Implementation (include ONLY if test cases exist)
-
-- **Authentication tests**: implement ONLY if `testcase/md/` contains auth-related cases
-  - Use `@pytest.mark.auth` marker
-  - Test no token, expired token, invalid token, insufficient permissions, cross-user access
-- **Timeout tests**: implement ONLY if `testcase/md/` contains timeout-related cases
-  - Use `@pytest.mark.timeout` marker
-  - Use `unittest.mock.patch` or `pytest-mock` to simulate slow responses
-- If no such cases exist in the reviewed test cases, do NOT add these tests
-
-#### Markers
-
-- `@pytest.mark.positive` — happy path cases
-- `@pytest.mark.negative` — error/exception cases
-- `@pytest.mark.boundary` — edge cases
-- `@pytest.mark.<MODULE>` — module-specific marker (e.g. `@pytest.mark.order`)
-
-#### Skip Policy
-
-If a test case cannot be automated (requires external service not mockable, requires manual verification), add it with `@pytest.mark.skip(reason="...")` and document the reason. Do not omit the function — traceability requires it exists.
-
-### Output Shape (after summary line)
-
-After the mandatory summary line, provide:
-
-1. **Generated Files** — list of files written under `tests/backend/`.
-2. **Function Mapping Table** — `| Test Case ID | Pytest Function | File | Marker |`.
-3. **Skipped Cases** — if any, list with reason.
-4. **Conventions Observed** — note project fixtures/config discovered and followed.
-5. **Residual Risks** — cases that may need manual verification or environment setup.
-
-Do not include chain-of-thought. Do not write root `artifacts/**`.
+# Backend Test DAG Generate Pytest Prompt Template
+
+## Purpose
+
+Use this prompt for a **pytest code generation** node: `executor: "pi"`, `role: "implementer"`, `toolProfile: "write"`, `writePolicy: "exclusive"`. The implementer converts reviewed backend functional test cases into pytest automation code with 1:1 traceability.
+
+Do **not** create a new executor type. This is a standard `executor: pi` writer node.
+
+## Recommended DAG Node Shape
+
+```json
+{
+  "id": "generate-backend-pytest-pi",
+  "depends_on": ["review-backend-cases-gate-shell", "backend-test-execution-contract-shell"],
+  "complexity": "HIGH",
+  "executor": "pi",
+  "role": "implementer",
+  "toolProfile": "write",
+  "writePolicy": "exclusive",
+  "writeSet": ["testcase/**/test_*.py", "testcase/**/helpers/**", "testcase/**/factories/**"],
+  "allowedPaths": ["**"],
+  "forbiddenPaths": [".harness/**", "artifacts/**"],
+  "outputContract": "Pytest test files under testcase/ with 1:1 mapping to functional test case IDs; optional helpers/factories. Summary lists generated files, test function count, and any skipped cases with reasons.",
+  "subtask_prompt_markdown": "./backend-test-dag.generate-pytest.prompt.md"
+}
+```
+
+## Prompt Body
+
+You are the Backend Test DAG **pytest code generator**.
+
+Your job is to convert reviewed test cases under `testcase/md/` into pytest automation code. Write test files under `testcase/` only. Stay within `writeSet`. Do not write root `artifacts/**`.
+
+### Output Steps (do in order)
+
+1. First, output a brief summary: how many files, how many test functions planned
+2. Then write each test file under `testcase/`
+
+### Inputs
+
+1. **Reviewed test cases** — files under `testcase/md/` (approved by `review-backend-cases-pi` / `review-backend-cases-gate-shell`).
+2. **Validated Backend Test Analysis v1** — run-owned `contracts/backend-test-analysis.json` from `backend-test-analysis-contract-shell`.
+3. **Validated Backend Test Execution Contract v1** — run-owned `contracts/backend-test-execution.json` from `backend-test-execution-contract-shell` (fixtures, env *names*, `testRoot`, `targetMode`, authenticationMode).
+4. **Target project conventions** — read `conftest.py`, `pytest.ini` / `pyproject.toml` to understand conventions, but do NOT modify them.
+
+Do NOT re-read source documents for free-form analysis. Use only reviewed cases and the validated contracts. Use only fixture/env/testRoot facts already present in the execution contract; never invent production credentials or secret values.
+
+### Conversion Rules
+
+#### File Naming
+
+- Every test file must start with `test_` prefix (e.g. `test_order.py`, `test_user_api.py`)
+- pytest collects tests from files matching `test_*.py` or `*_test.py` — use `test_` prefix exclusively
+- Never create test files without the `test_` prefix
+
+#### Write Boundary
+
+- Only **create new** files under writeSet:
+  - `testcase/**/test_*.py`
+  - `testcase/**/helpers/**` (optional pure helpers)
+  - `testcase/**/factories/**` (optional test data factories)
+- Do NOT modify existing files: `conftest.py`, `pytest.ini`, `pyproject.toml`, `setup.cfg`, `__init__.py`, or any other framework/config file
+- Reuse existing fixtures; if required helpers are missing, create NEW helper/factory modules under the writeSet paths above — never edit root conftest
+- Read existing framework files to understand conventions, but treat them as immutable
+- Do NOT write production code, `.env`, secrets, or credential files
+
+#### Naming Conflict Resolution
+
+- If a file with the target name already exists under `testcase/`, add a numeric suffix: `test_order.py` → `test_order_01.py` → `test_order_02.py`
+- Never overwrite or append to existing files — each test script must be a standalone file
+- Check for existing files before writing; if `test_<module>.py` exists, use `test_<module>_01.py`
+
+#### 1:1 Traceability
+
+Every functional test case ID (`BE-<MODULE>-<NNN>`) must map to exactly one pytest function:
+
+```python
+# testcase/md/BE-ORDER-001 → testcase/test_order.py
+def test_BE_ORDER_001_create_order_with_valid_data():
+    """BE-ORDER-001: Create order with valid request body."""
+    ...
+```
+
+- Function name: `test_<CASE_ID_with_underscores>` (e.g. `test_BE_ORDER_001_...`)
+- Docstring first line: `<CASE_ID>: <Case Title>`
+
+#### File Organization
+
+- All test files go under `testcase/` directory in the host project root
+- Group test files by MODULE segment: `BE-ORDER-*` → `testcase/test_order.py`, `BE-USER-*` → `testcase/test_user.py`
+- Follow existing project conventions for import style, fixture scope
+
+#### Fixture Strategy
+
+- Reuse existing project fixtures from `conftest.py` when available (read-only)
+- Do not create or modify root fixture/configuration files (`conftest.py`, pytest.ini, …)
+- Optional NEW helpers/factories may live under `testcase/**/helpers/**` or `testcase/**/factories/**` only
+- Prefer `@pytest.fixture(scope="function")` for test isolation
+- Use `@pytest.mark.parametrize` for boundary condition cases with multiple inputs
+
+#### Test Integrity
+
+- Tests verify implementation correctness — if a test fails, the implementation likely has a bug, not the test
+- Do NOT weaken assertions, remove test cases, or modify test logic to make tests pass
+- Do NOT add workarounds, skips, or try/except blocks to hide failures without explicit justification
+- Report all failures honestly in the output; the downstream `execute-backend-pytest-shell` node captures exit codes and stdout/stderr as-is
+
+#### Test Data Preparation Rules (MUST follow)
+
+**When Setup is Needed**
+
+Setup phase is REQUIRED only when test cases need pre-existing data:
+- Query/Read APIs: need data to exist before querying
+- Update/Delete APIs: need data to exist before modifying
+- State transition tests: need data in specific state
+
+Setup phase is NOT needed for:
+- Create APIs: testing the creation itself
+- Validation tests: testing input validation with invalid data
+
+**Data Setup Strategy**
+
+When setup is needed:
+1. Use `@pytest.fixture(scope='module')` or `@pytest.fixture(scope='session')` to prepare shared test data
+2. All test cases in the file share the same pre-constructed data
+
+**Data Construction Priority**
+
+1. **API-first**: Use documented APIs from `analyze-inputs-pi` / reviewed cases
+2. **Reuse existing conftest fixtures** (read-only)
+3. **Direct DB writes are last resort** and only via safe test-DB fixtures with rollback/isolation
+4. If neither API nor safe DB fixture exists, **skip with an explicit gap note** — do not invent credentials or touch live data
+
+**API Data Construction**
+
+- Prefer the `analyze-inputs-pi` API Endpoints section and reviewed cases for method/path/fields
+- Chain API calls only when cases document multi-step preconditions
+- Store created resource IDs in fixtures for reuse
+- Do **not** broadly search host route/controller trees for secrets, `.env`, private keys, or production configs
+- Read host API definitions only when needed to resolve a field name already referenced by reviewed cases
+
+**Database Data Construction (restricted)**
+
+- Allowed only via existing `conftest.py` test-DB fixtures with transaction rollback or equivalent isolation
+- Never hardcode connection strings, passwords, tokens, or cloud credentials
+- Never target production/shared non-test databases
+- If isolation is unclear, report the gap instead of writing DB rows
+
+#### Assertion Rules (MUST follow)
+
+**Positive Path (成功场景)**
+
+MUST assert ALL of the following:
+1. HTTP status code: as defined in API spec (e.g. 200, 201)
+2. Response structure: key fields exist in response body
+3. Specific values: each field equals expected value from test case
+4. Data type: each field is correct type
+
+**Negative Path (异常场景)**
+
+MUST assert ALL of the following:
+1. HTTP status code: as defined in API spec (e.g. 400, 404, 500)
+2. Error code field: field name from API spec (e.g. code, error_code, errcode, ret)
+3. Error message field: field name from API spec (e.g. message, msg, errmsg, error)
+
+**Field Name Resolution**
+
+Field names MUST come from the upstream `analyze-inputs-pi` output (API Endpoints section), NOT hardcoded. For example:
+- If API spec defines `{"ret": 0, "msg": "success"}`, assert `response.json()["ret"]` and `response.json()["msg"]`
+- If API spec defines `{"code": 4001, "message": "error"}`, assert `response.json()["code"]` and `response.json()["message"]`
+
+
+#### Conditional Test Implementation (include ONLY if test cases exist)
+
+- **Authentication tests**: implement ONLY if `testcase/md/` contains auth-related cases
+  - Use `@pytest.mark.auth` marker
+  - Test no token, expired token, invalid token, insufficient permissions, cross-user access
+- **Timeout tests**: implement ONLY if `testcase/md/` contains timeout-related cases
+  - Use `@pytest.mark.timeout` marker
+  - Use `unittest.mock.patch` or `pytest-mock` to simulate slow responses
+- If no such cases exist in the reviewed test cases, do NOT add these tests
+
+#### Markers
+
+- `@pytest.mark.positive` — happy path cases
+- `@pytest.mark.negative` — error/exception cases
+- `@pytest.mark.boundary` — edge cases
+- `@pytest.mark.<MODULE>` — module-specific marker (e.g. `@pytest.mark.order`)
+
+#### Skip Policy
+
+If a test case cannot be automated (requires external service not mockable, requires manual verification), add it with `@pytest.mark.skip(reason="...")` and document the reason. Do not omit the function — traceability requires it exists.
+
+### Output Shape (after summary line)
+
+After the mandatory summary line, provide:
+
+1. **Generated Files** — list of files written under `tests/backend/`.
+2. **Function Mapping Table** — `| Test Case ID | Pytest Function | File | Marker |`.
+3. **Skipped Cases** — if any, list with reason.
+4. **Conventions Observed** — note project fixtures/config discovered and followed.
+5. **Residual Risks** — cases that may need manual verification or environment setup.
+
+Do not include chain-of-thought. Do not write root `artifacts/**`.