@guanlin4924/devflow-pi 0.1.94 → 0.1.96

package/plugins/devflow-quality/runtime/playwright/runtime-manifest.json

@@ -0,0 +1,11 @@
+{
+  "schema_version": 1,
+  "runtime_version": "0.1.0",
+  "playwright_version": "1.63.0",
+  "files": {
+    "runner.spec.mjs": "5612cde9ddef5a203829d86ab45788d65cbe83891ff7dbb73c308aa9345ead83",
+    "playwright.config.mjs": "301c0b97e229f83e6934994718b11b93a1da5d46ec606cfd11a8292e9d622b02",
+    "reporter.mjs": "5c91d68c50a93603f583cf82345d427bcd9ce9a7cfb78fd6d0989abddbd55275",
+    "devflow-test-dsl-v1.schema.json": "21ce608adcaf60ac138b532b7731f3b74c3e2749cba26dfeb12fc12ce0b6e5f3"
+  }
+}

package/plugins/devflow-quality/skills/workflow-acceptance-test-design/SKILL.md

@@ -43,6 +43,7 @@ description: "Use after integration verification and before change planning to d
   "acceptance_refs": ["AC-0001"],
   "requirement_refs": ["REQ-0001", "BR-0001"],
   "test_type": "api|page|permission|boundary|resilience|migration|performance",
+  "execution_surface": "http|ui|api_flow|project_test",
   "target": "外部可观察的 API、页面或运行边界",
   "preconditions": ["身份、数据和环境前置条件"],
   "steps": ["测试操作"],
@@ -52,6 +53,8 @@ description: "Use after integration verification and before change planning to d
 }
 ```
 
+- `execution_surface` 必须显式填写：单个 Core HTTP 请求且断言来自 `execution` 用 `http`；真实页面交互用 `ui`；受限 DSL 中的多步骤 API 或 UI/API 组合用 `api_flow`；项目自有测试命令、权限、边界、韧性、迁移和性能专项用 `project_test`。`page` 必须对应 `ui`，带 `execution.protocol: http` 的 Core API TC 必须对应 `http`；新冻结 TC 缺失或冲突会被 CP-3 拒绝。
+- `automated` 的 `ui` / `api_flow` TC 在 `run-acceptance-tests` 绑定阶段必须有 v1 DSL（`workflow-generate-mainflow-cases` 生成，`covers` 逐条映射 `preconditions[i]`、`steps[i]` 和 `oracle`）并经用户批准 `execution_plan`，否则只会 blocked。因此每个前置条件和步骤要写成可单独映射的原子条目，oracle 要写成确定性的可观察结果（具体文案、URL、响应字段）；需要纯视觉判断、缺少稳定 locator 或无法准备/隔离数据的场景，现在就标 `manual` 或 `blocked`，不要标 `automated`。
 - `manual` 额外写 `manual_reason` 和 `owner`；`blocked` 额外写 `blocked_by` 和 `owner`。
 - `replay`：可用稳定步骤再次触发，必须写 `replay_scope`（`component|page|api|integration`）。页面优先拆到组件、页面、接口或集成边界，不要求 AI 在真实环境盲目重试。
 - `causal`：用于已由 HAR、控制台、DOM 快照、服务日志或请求链路证明首个偏差、但暂不能稳定重放的缺陷。必须写 `causal_evidence_refs`（已有 `SRC-*` / `CODE-*`）和 `first_divergence`；后续执行绑定还必须提供实际证据文件，Core 会哈希留档。没有这些证据不能称为“已证实”。

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/SKILL.md

@@ -1,55 +1,59 @@
 ---
 name: workflow-generate-mainflow-cases
-description: "Use after workflow-execute-phase to bind frozen API/page TC acceptance intent to importable positive mainflow automation cases."
+description: "Use after code review, as the binding-phase prerequisite of run-acceptance-tests, to compile one deterministic devflow-test-dsl/v1 file per frozen automated ui/api_flow TC, validate the whole generated-cases directory, get an independent AI review, and propose execution_plan approvals for the user."
 ---
 
-# 主流程自动化用例生成
+# 主流程自动化用例生成（Playwright DSL）
 
-在 `execute` 完成后运行本 skill，生成当前测试聚合平台可导入的正向主流程自动化用例。只生成 `api-mainflow` 和 `ui-mainflow` 用例，不生成异常、边界、权限、安全、性能专项。
+为冻结套件中 `automation_mode: automated` 且 `execution_surface` 为 `ui` 或 `api_flow` 的正向主流程 TC 生成确定性的 `devflow-test-dsl/v1`，每个 TC 一个文件，交给 Devflow Playwright Runtime 执行。**这是 `run-acceptance-tests` 的真实前置条件**：没有 DSL 并经用户批准 `execution_plan` 的自动化 ui/api_flow TC 只会 `blocked(dsl_not_approved)`，不能进入收口。不生成异常、边界、权限、安全、性能专项；这些 TC 按 `run-acceptance-tests` 的降级规则处理。
 
 ## Hard Rules
 
 - MUST NOT hardcode `platform-backend` or `platform-frontend`.
 - MUST derive code roots from `.devflow/planning/navigation` and `.devflow/context/spec`.
 - MUST use `.devflow/planning/code-index/` for fine-grained entrypoint, route, component, API, call, import, and data-flow evidence when present.
-- MUST only generate `api-mainflow` and `ui-mainflow` cases.
-- MUST read the frozen `.devflow/planning/requirements/{feature}/tests.json` before selecting case scope. Only frozen positive `TC-*` with `test_type: api` or `page` may produce mainflow cases. Core-generated API TC carrying `execution.expect.error_code` is a negative/exception case and is excluded here; it is executed by `run-acceptance-tests`.
-- MUST NOT read `SUMMARY.md`, delivery self-reports, or diffs to decide what to test. Current code is allowed only to bind an already frozen TC to an entrypoint, selector, request, or runner adapter.
-- MUST run `scripts/compile_dsl.py` before final output.
-- MUST run `scripts/validate_case_payloads.py` before reporting success.
+- MUST read the frozen `.devflow/planning/requirements/{feature}/tests.json` before selecting scope. Only frozen, `confirmed`, `automation_mode: automated` TCs whose `execution_surface` is `ui` or `api_flow` get a DSL (legacy `page` TCs derive to `ui`). `http` TCs (including Core-generated API TCs with `execution.expect.error_code`) and `project_test` TCs are executed by their own adapters, not here.
+- MUST NOT read `SUMMARY.md`, delivery self-reports, or diffs to decide what to test. Current code is allowed only to bind an already frozen TC to an entrypoint, `data-testid`/locator, request path, or test data; it must never change the TC's steps or oracle.
+- MUST NOT hand-write or hand-edit `TC-xxxx.json`. Write `case-descriptions.json` and run `compile_dsl.py`; the compiler owns `tc_sha256`, target/driver generation, and hard rejections (`ai_only`, Midscene, xpath, scripts, token injection, fixed waits).
+- MUST run `compile_dsl.py`, then `validate_case_payloads.py` on the whole `generated-cases/{feature}` directory, before reporting success. Block if either exits non-zero.
 - MUST block if codebase discovery fails.
-- MUST block if generated DSL fails validation.
+- MUST get an independent AI review of every DSL against its TC oracle (advisory) before proposing approvals. The reviewer must not be the agent that wrote the descriptions.
+- MUST propose one `execution_plan` approval per automated TC with `devflow_approval`; only the user can approve it, in `/devflow` → “待审批”. The agent cannot confirm, must not write approval records, and must not treat an unapproved DSL as accepted.
+- MUST NOT create `case-import-payloads.json`. That name belongs only to the explicit legacy TestAgent export and is never a Runtime DSL artifact (see Legacy export).
 
 ## Workflow Position
 
-This step sits between code execution and frozen acceptance execution. It runs after `execute` alongside `code-review`; `run-acceptance-tests` consumes both gates:
+This skill is not a workflow step and must not appear in `pending_steps` or participate in main-chain ordering. It runs inside the binding phase of `run-acceptance-tests`:
 
-`execute -> code-review + generate-mainflow-cases -> run-acceptance-tests -> release-closeout`
+`execute -> code-review -> [human acceptance] -> generate DSL (this skill) -> bind + user approves execution plans -> run-acceptance-tests -> release closeout`
 
-The workflow step id is `generate-mainflow-cases`, order `86`, and it depends on `execute`.
+Before running, verify that the current feature's `code-review` is completed and the frozen TC suite is fresh (`devflow_acceptance_tests(feature)`). A generation, validation, or approval failure means the affected TCs cannot run as `devflow_playwright`; report it and either fix it or downgrade the TC (`manual` with a `mode_override` approval, or `blocked` with owner/reason). It never mutates workflow state itself.
 
 ## Required Outputs
 
-Always create or update:
+Always create or update, under `.devflow/planning/generated-cases/{feature}/`:
 
-- `.devflow/planning/generated-cases/{feature}/source-map.md`
-- `.devflow/planning/generated-cases/{feature}/mainflow-analysis.md`
-- `.devflow/planning/generated-cases/{feature}/case-descriptions.json`
-- `.devflow/planning/generated-cases/{feature}/case-import-payloads.json`
-- `.devflow/planning/generated-cases/{feature}/validation-report.md`
-- `.devflow/planning/phases/{phase}/MAINFLOW-CASES.md`
+- `source-map.md` — frozen TC ID, planning evidence, code-index evidence, source files, and the source of every non-testid locator.
+- `mainflow-analysis.md` — included/excluded TCs with reasons (including TCs that need downgrade), assumptions, traceability.
+- `case-descriptions.json` — the AI-written input (`references/intermediate-format.md`).
+- `TC-xxxx.json` — one v1 DSL per automated ui/api_flow TC, written by `compile_dsl.py` only.
+- `validation-report.md` — output of the directory validation.
+- `ai-review.md` — the independent review findings per TC (advisory).
 
-The discovery script also writes support artifact `.devflow/planning/generated-cases/{feature}/codebase-discovery.json`.
+Also `.devflow/planning/phases/{phase}/MAINFLOW-CASES.md` (summary) and support artifact `codebase-discovery.json` (written by the discovery script).
+
+`case-import-payloads.json` is **not** an output of this skill.
 
 ## Resource Loading
 
 Read these references before generating cases:
 
 - `references/codebase-discovery.md` before scanning any source file.
-- `references/mainflow-selection.md` before deciding which flows become cases.
-- `references/intermediate-format.md` before writing `case-descriptions.json`.
-- `references/api-mainflow-rules.md` before generating API cases.
-- `references/ui-mainflow-rules.md` before generating UI cases.
+- `references/mainflow-selection.md` before deciding which TCs become DSL.
+- `references/intermediate-format.md` before writing `case-descriptions.json` (the exact accepted format).
+- `references/project-dsl-contract.md` for the v1 DSL shape, `covers`, and the approval/hash rules.
+- `references/api-mainflow-rules.md` before generating `api_flow` cases.
+- `references/ui-mainflow-rules.md` before generating `ui` cases.
 
 ## Process
 
@@ -62,7 +66,7 @@ Read these references before generating cases:
 
    Stop if it exits non-zero.
 
-3. Read the frozen TC suite first. Record the source `TC-*` for every selected mainflow case; a missing or stale source TC is a blocker. Then read planning inputs when present:
+3. Read the frozen TC suite first and list every `automated` TC whose surface is `ui` or `api_flow`. Record the source `TC-*` for each; a missing or stale TC is a blocker. Then read planning inputs when present:
    - `.devflow/planning/requirements/baseline.md`
    - `.devflow/planning/features/{feature}/功能点梳理.md`
    - `.devflow/planning/features/{feature}/UI-SPEC.md`
@@ -71,57 +75,66 @@ Read these references before generating cases:
    - `.devflow/planning/features/{feature}/变更清单.md`
    - `.devflow/planning/features/{feature}/PROGRESS.md`
 
-4. Read discovery output, then read each discovered codebase's navigation and spec files. Select scan targets by codebase type:
+4. Read discovery output, then each discovered codebase's navigation and spec files. Select scan targets by codebase type:
    - Backend: router/controller, service/usecase, schema/dto/request/response, model/entity, API entry.
    - Frontend: router, pages/views, api/client, types/contracts, stores/hooks/components related to the feature.
 
-5. If `.devflow/planning/code-index/` exists, query symbols and relations for candidate entrypoints and mainflow paths:
+5. If `.devflow/planning/code-index/` exists, query symbols and relations for candidate entrypoints and flows:
    - Backend/API: `routes_to`, `calls`, `reads`, `writes`, `config_uses`, `tested_by`.
    - Frontend/UI: route/page/component symbols, `routes_to`, `imports`, `calls` into API clients, store/hook relations.
-   Read `evidence_path:evidence_line` before using an edge in case selection.
-6. Inspect actual code paths that are both relevant to `{feature}` and reachable from navigation/spec/code-index. Do not scan excluded historical modules.
-7. Write `source-map.md` with the frozen TC ID, planning evidence, code-index evidence when used, source evidence, and selected source files for each candidate case.
-8. Write `mainflow-analysis.md` with included API/UI positive mainflows, excluded non-mainflows, assumptions, and traceability to frozen TC plus source evidence.
-9. Write `case-descriptions.json` using the simplified format in `references/intermediate-format.md`. **Do NOT write raw DSL** — use locator strings like `"text:编辑"`, `"placeholder:请输入名称"`, `"css:.el-dialog__footer .el-button--primary"`.
-10. Compile descriptions into strict DSL:
+   Read `evidence_path:evidence_line` before using an edge.
+6. Inspect actual code paths that are both relevant to `{feature}` and reachable from navigation/spec/code-index. Prefer `data-testid` for locators. Do not scan excluded historical modules.
+7. Write `source-map.md`, then `mainflow-analysis.md`.
+8. Write `case-descriptions.json` using `references/intermediate-format.md`: one case per TC, locator strings such as `"testid:save-btn"`, `"role:button:确定"`, `"label:用户名"`, and a `covers` mapping that covers every precondition, every step, and the oracle of the TC. Do NOT write raw DSL.
+9. Compile (writes one `TC-xxxx.json` per TC into `.devflow/planning/generated-cases/{feature}/`; all-or-nothing):
 
    ```text
-   devflow_mainflow(action="compile", args=[".devflow/planning/generated-cases/{feature}/case-descriptions.json", "--output", ".devflow/planning/generated-cases/{feature}/case-import-payloads.json"])
+   devflow_mainflow(action="compile", args=[".devflow/planning/generated-cases/{feature}/case-descriptions.json", "--feature", "{feature}"])
    ```
 
-   Stop if it exits non-zero. The compiler owns all target key selection, strategy decisions, and assertion formatting.
+   Stop and fix the descriptions if it exits non-zero. Do not pass `--output`: it no longer exists (only `--output-dir`, whose default is already the directory above) and the compiler rejects it. Compiler warnings (non-testid locators, high-risk texts) go into `source-map.md`/the handoff; prefer replacing them by a `data-testid`.
 
-11. Validate compiled payloads:
+10. Validate the whole directory (pure data, never loads project code):
 
     ```text
-    devflow_mainflow(action="validate", args=[".devflow/planning/generated-cases/{feature}/case-import-payloads.json", "--discovery", ".devflow/planning/generated-cases/{feature}/codebase-discovery.json", "--output", ".devflow/planning/generated-cases/{feature}/validation-report.md"])
+    devflow_mainflow(action="validate", args=[".devflow/planning/generated-cases/{feature}", "--suite", ".devflow/planning/requirements/{feature}/tests.json", "--output", ".devflow/planning/generated-cases/{feature}/validation-report.md"])
     ```
 
-    Stop if it exits non-zero.
+    Stop if it exits non-zero. Read the warnings: an automated ui/api_flow TC listed as having no DSL will be blocked as `dsl_not_approved`.
+
+11. Independent AI review (advisory). Have a different agent than the author review each DSL against its frozen TC: read only the TC (`preconditions`, `steps`, `oracle`) and the DSL, and list omissions, weak assertions, assertions on the wrong object, ambiguous or unstable locators, missing data isolation, and any step that does not follow from the TC. Write the findings per TC to `ai-review.md`. Serious findings should be fixed by editing `case-descriptions.json` and repeating steps 9–11; any DSL byte change invalidates approval for that TC. The review never counts as a pass.
+
+12. Propose an execution plan per automated TC (one item per TC; `dsl_file` defaults to `.devflow/planning/generated-cases/{feature}/{tc_id}.json`):
+
+    ```text
+    devflow_approval(action="propose", feature="{feature}", kind="execution_plan",
+      items=[{"subject":"TC-0001","dsl_file":".devflow/planning/generated-cases/{feature}/TC-0001.json","review_issues":["<advisory issue from ai-review.md>"],"note":"<optional context>"}])
+    ```
 
-11. Write `.devflow/planning/phases/{phase}/MAINFLOW-CASES.md` summarizing:
-    - Generated case count by tag.
-    - Import payload path.
-    - Validation status.
-    - Source evidence index.
-    - Any environment data needed before execution.
+    Core pins `suite_graph_revision`, `suite_fingerprint`, `tc_sha256` and `dsl_sha256` and re-runs structural validation; the proposal is all-or-nothing. It requires database authority. Then ask the user to review each TC (oracle text, covering assertions, review issues) and decide in `/devflow` → “待审批”. Re-running `devflow_approval(action="list", feature="{feature}")` shows proposal status; do not wait on, simulate, or write approvals.
 
-12. Report success only after compilation and validation pass.
+13. Write `.devflow/planning/phases/{phase}/MAINFLOW-CASES.md` summarizing: TC IDs and DSL paths, validation status, review issues, approval proposal status, downgrade candidates, environment data/profile needed.
+14. Report success only after compile, validate, and propose succeeded. Return a handoff containing the source TC IDs, DSL directory, `validation-report.md` and `ai-review.md` paths, proposal IDs/status, required environment/test data, TCs without DSL, and any gaps. Do not advance workflow state.
+
+If a TC's DSL needs to change after it was approved (TC refrozen, code changed, review findings), recompile, revalidate, re-review, and propose again. Recompiling an unchanged description yields byte-identical output, so existing approvals stay valid.
 
 ## AI Scope
 
 AI is responsible for semantic judgment only:
 
-- Determine API/page test scope from frozen `TC-*`, not from implementation delivery prose.
-- Confirm implemented behavior from actual code.
-- Identify positive API mainflows.
-- Identify positive UI mainflows.
-- Generate `case-descriptions.json` in simplified intermediate format.
-- Record source evidence for each case.
-
-AI is NOT responsible for DSL formatting. The `compile_dsl.py` script owns:
-- Target key selection (`label`, `css`, `placeholder`, etc.)
-- Strategy decisions (`structured_first` vs `ai_only`)
-- Assertion type selection and formatting
-- Auth step generation
-- Step ID assignment and dependency wiring
+- Decide which frozen TCs are eligible and which need downgrade.
+- Confirm implemented behavior from actual code and bind entrypoints, locators, request paths, and data.
+- Write `case-descriptions.json` faithful to each TC and its `covers`.
+- Record source evidence in `source-map.md`.
+- Review (as a different agent) each DSL against the oracle.
+
+AI is NOT responsible for, and cannot override:
+
+- DSL formatting, `tc_sha256`, target key selection, and step ID assignment (`compile_dsl.py`).
+- Schema, semantic, secret-literal, and structural coverage checks (Core `dsl_v1`/`dsl_coverage` via `validate_case_payloads.py`).
+- The approval of an execution plan or environment profile (only the user, in `/devflow`).
+- Any pass/fail verdict (only Core's `run-acceptance-tests`).
+
+## Legacy export
+
+Only when a developer explicitly asks for a TestAgent import file, run `scripts/export_legacy_testagent.py` directly with a separate legacy-format input and an explicit `--output` (for example `.devflow/planning/generated-cases/{feature}/legacy-testagent-import.json`). It is not exposed by `devflow_mainflow`, is not part of the gate, and its output cannot be bound to `devflow_playwright`, approved as an execution plan, or counted as an acceptance result. Never write its output as `TC-xxxx.json` and never describe it as a Runtime DSL artifact.

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/references/api-mainflow-rules.md

@@ -1,27 +1,32 @@
 # API Mainflow Rules
 
-API cases validate successful backend behavior through importable DSL.
+这里的 API 用例指冻结的、自动化的 `execution_surface: api_flow` TC：需要多步骤链式请求（变量提取、前后依赖）或 UI/API 组合，用 v1 DSL 表达。单个 Core HTTP 请求且断言来自冻结 TC 的 `execution` 的 API TC 是 `execution_surface: http`，由 Core 的 `http` adapter 直接执行，**不**生成 DSL；带 `execution.expect.error_code` 的异常码 TC 同理，本 Skill 不处理。
+
+AI 写 `case-descriptions.json`（`intermediate-format.md`），`compile_dsl.py` 生成 `TC-xxxx.json`（`project-dsl-contract.md`）。
 
 ## Step Rules
 
-- Use `driver: "api"`.
-- Use HTTP method as `action`: `get`, `post`, `put`, `patch`, `delete`, `head`, or `options`.
-- Set `params.url` for every API step.
-- Put query values under `params.params`.
-- Put JSON request payloads under `params.json` or `params.body`.
-- Add success assertions for status code and key response fields where code/planning provide them.
-- Extract ids or tokens only into variables, never literal secrets.
-- Use `depends_on` to model required execution order.
+- 每个请求是一个 API 步骤：`action` 写 `request` 并给 `method`，或直接写 `get`/`post`/`put`/`patch`/`delete`（`head`/`options` 不支持）。
+- `url` 必填：以 `/` 开头相对已批准 profile 的 `api_base_url`（缺省 `base_url`）；绝对 URL 的 origin 必须在 profile `api_origins` 中。不要把环境相关主机写死，也不要写变量 `${base_url}`（不是内置变量）。
+- 查询参数写 `query`（标量），请求体写 `json`，请求头写 `headers`。
+- 成功断言：`expect_status`，以及响应体断言 `assertions: [{ "pointer": "/data/status", "op": "equals", "value": "created" }]`（`op`：`equals`/`not_equals`/`contains`/`exists`/`not_exists`，JSON Pointer）。只写 `expect_status: 200` 且没有响应体断言，覆盖 oracle 时会被判为弱断言。没有 `status_code`/`json_path_*`/`regex` 之类旧断言类型。
+- 用 `extract: { "order_id": "/data/id" }` 把 id 提取成变量，后续步骤用 `${order_id}`。只支持 JSON Pointer；提取到的令牌等敏感值写 `{ "pointer": "...", "sensitive": true }`。
+- 步骤按写入顺序执行，没有 `depends_on`；失败即停止。
+- 默认不重试；只有传输失败才可声明 `retry`，POST/PATCH 还需 `idempotent: true`。
+- 凭据用 `variables` 的 `{ "secret": "ENV_KEY" }`，请求头写 `"Authorization": "Bearer ${auth_token}"`；不得出现 token/密码/cookie 字面量。
+- 需要前置数据用 `data.setup`，清理用 `data.cleanup`（都只能是 API 步骤）。
 
-## Source Evidence
+## covers 与 TC 忠实性
 
-Cite at least one planning artifact and one code artifact per case:
+- TC 的每个前置条件（对应 `data.setup` 或步骤的 `covers.preconditions`）、每个步骤都要被某个 DSL 步骤覆盖，oracle 要被带 `assertions`/`expect_status` 的主流程 API 步骤覆盖：`covers: ["oracle"]`。
+- DSL 不得增删或改写 TC 的步骤与 oracle；源码只补充路径、字段名和请求体。
+
+## Source Evidence
 
-- Planning: backend tech spec, change list, feature breakdown, or requirement baseline.
-- Code: router/controller and service/usecase, plus schema/model when they define the contract.
+每个 case 在 `source-map.md` 里至少引用一份规划产物（后端技术方案、变更清单、功能点梳理或需求基线）和一份代码产物（路由/控制器、service/usecase，以及定义契约的 schema/model）。证据不写入 DSL。
 
 ## Positive Mainflow Boundary
 
-Allowed: create/list/detail/update/execute success flow for the current feature.
+生成范围：当前功能的创建/查询/详情/更新/执行成功链路。
 
-Not allowed: invalid request, unauthorized access, missing resource, validation error, conflict, retry, timeout, or performance scenario.
+不生成：非法请求、未授权、资源缺失、校验错误、冲突、重试/超时场景、性能场景。这些 TC 走 Core HTTP adapter、项目自有 command 或降级为 `manual`/`blocked`。

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/references/codebase-discovery.md

@@ -2,6 +2,8 @@
 
 Use discovery before reading feature source files. The goal is to make the skill portable across projects that have valid `.devflow/planning` and `.devflow/context/spec` initialization artifacts.
 
+Discovery only locates code roots so that entrypoints, `data-testid`s, routes, and request shapes can be read for the frozen TCs. It is **not** an input to compilation or validation: `validate_case_payloads.py` is pure data and never loads project code (`--discovery` is deprecated and ignored).
+
 ## Required Sources
 
 Read and cross-check:
@@ -43,7 +45,7 @@ Use `codebase-discovery.json` fields:
 - `codebases[].stack_key`
 - `codebases[].scan_profile`
 
-Current project discovery should resolve `BACKEND` and `FRONTEND`, but this is an output fact, not a skill rule.
+Current project discovery should resolve `BACKEND` and `FRONTEND`, but this is an output fact, not a skill rule. Reading a codebase only supplies binding facts (entry URL, locator, request path); it never changes a frozen TC's steps or oracle.
 
 ## Scan Range By Type