--- name: aif-qa-check description: Executes QA test cases created by /aif-qa in human-guided or automated-agent mode. Use when you need to walk through QA one case at a time, record pass/fail results, or have an agent verify cases through browser, CLI, API, automated tests, or file/document checks. argument-hint: "[human | agent] []" allowed-tools: Read Write Grep Glob Bash AskUserQuestion Browser mcp__playwright__* disable-model-invocation: true --- # QA Check — Execute Test Cases Runs the `test-cases.md` artifact produced by `/aif-qa` and records execution status in `qa-check.md`. In agent mode, it also maintains reusable cross-QA execution memory under the QA root: - `agent-context.md` — curated, current, reusable non-sensitive setup facts for future automated QA runs - `agent-history.md` — append-only reusable learnings extracted from prior runs, not a per-run audit log The skill is stack-free and agent-free: it does not assume a framework, package manager, browser tool name, or agent runtime. In agent mode, it uses the appropriate available execution surface for each case: live browser automation, CLI commands, project test runners, HTTP/API calls, database-safe read checks, file/document inspection, or other non-destructive automated verification. ## Modes | Argument | Mode | What you do | |----------|------|-------------| | `human` | Human-guided QA | Show exactly one test case, ask the user whether it works, and record their answer | | `agent` | Automated-agent QA | Execute test cases through the most appropriate available capability and record observed results | If no mode is provided, ask the user which mode to run. --- ## Workflow ### Step 0: Load Config **FIRST:** Read `.ai-factory/config.yaml` if it exists to resolve: - **Paths:** `paths.description`, `paths.architecture`, `paths.qa` (default: `.ai-factory/qa`) - **Language:** - `language.ui` for AskUserQuestion prompts, progress messages, summaries, and next-step guidance - `language.artifacts` for the persisted `qa-check.md` artifact - `language.technical_terms` for human-readable technical terminology style in the artifact - If `language.artifacts` is missing, use `language.ui` - If both are missing, use `en` - **Git:** `git.enabled` for branch resolution If config.yaml does not exist, use defaults: - DESCRIPTION.md: `.ai-factory/DESCRIPTION.md` - ARCHITECTURE.md: `.ai-factory/ARCHITECTURE.md` - QA artifacts: `.ai-factory/qa/` - `ui_language`: `en` - `artifact_language`: `en` - `technical_terms_policy`: `keep` - Git enabled: `true` Store: - `ui_language = language.ui || "en"` - `artifact_language = language.artifacts || language.ui || "en"` - `technical_terms_policy = language.technical_terms || "keep"` - `git_enabled = git.enabled` when present, otherwise `true` - `qa_root = resolved paths.qa || ".ai-factory/qa/"` - `qa_agent_context_path = /agent-context.md` - `qa_agent_history_path = /agent-history.md` All AskUserQuestion prompts, user-visible explanations, per-case summaries, and final summaries MUST be written in `ui_language`. The persisted `qa-check.md` artifact MUST be written in `artifact_language`. Templates define structure, not language. Use the canonical English template in `templates/QA-CHECK.md`. If `artifact_language` is not `en`, translate headings, labels, status text, comments you author, and explanatory text to `artifact_language` before saving. Preserve checkbox syntax, test case IDs (`TC-001`), commands, paths, config keys, URLs, selectors, package names, API names, branch names, and raw error messages. For `artifact_language = ru`, write human-readable prose, headings, statuses, summaries, and agent-authored comments in Russian. Preserve user wording except mandatory redaction of sensitive values before writing. Apply `technical_terms_policy` while writing artifacts: - `keep` — keep common technical terms such as `browser`, `selector`, `viewport`, `endpoint`, `payload`, `regression`, and `fixture` when clearer - `translate` — translate human-readable technical terms where a natural target-language term exists - `mixed` — translate ordinary prose terms while keeping code, infrastructure, and ecosystem terms unchanged ### Step 0.1: Load Project Context Read the resolved description path if it exists. Read the resolved architecture path if it exists. Read `.ai-factory/skill-context/aif-qa-check/SKILL.md` — MANDATORY if the file exists. Treat it as project-level overrides for this skill. Read `/agent-context.md` if it exists. Treat it as reusable, user-approved QA execution context for future automated runs: stable environment classes, canonical local/staging URLs, login route, test account role, allowed non-sensitive usernames, required seed data patterns, stable selectors, field identifiers, known redirects, startup prerequisites, safe command patterns, reusable test-filter conventions, environment notes, and service startup instructions. Read `/agent-history.md` if it exists. Treat it as append-only cross-QA memory from prior `/aif-qa-check` runs. Before asking the user or attempting automated execution, search it for reusable prior answers to the same blocker so the skill does not repeat avoidable mistakes. `agent-context.md` and `agent-history.md` are global to all QA sets under `paths.qa`. They MUST NOT become logs for a specific QA plan. Do not write branch names, branch slugs, QA target paths, current `artifact_dir`, `TC-*` mappings, per-run summary counts, exhaustive command transcripts, assertion counts from a single run, one-off file checks, or plan-specific labels such as a numbered QA folder name. Write those details only to `//qa-check.md`. Only promote information into `agent-context.md` or `agent-history.md` when it is likely to help future unrelated QA runs. Prefer stable patterns over concrete one-off run facts. Example: `Laravel backend checks use php artisan test --filter=` is reusable; `05-profile-formula-recommendations ran ProfileReaderTest with 4 tests / 13 assertions` is run-specific and belongs only in `qa-check.md`. Never write global negative capability or scope claims unless they are true for the whole project. Do not write statements like `browser automation is not required`, `browser URL is not used`, `all QA is backend/CLI`, or `these cases are backend-test/cli/file-docs` to `agent-context.md` or `agent-history.md` when that conclusion came from one QA plan. Instead, keep it branch-specific in `qa-check.md`, or phrase a reusable conditional rule such as `For backend-only QA cases, browser automation is not required; browser/UI cases still require Browser or Playwright MCP`. Never treat either file as a source of secrets. If either file contains an apparent password, token, cookie, authorization header, one-time code, or other secret, ignore that value for execution and redact it the next time the file is rewritten or appended to. ### Step 0.2: Parse Arguments and Resolve Branch Parse `$ARGUMENTS`: 1. Detect mode: first word matching `human` or `agent`; remove it from arguments. 2. Detect branch: remaining text, if any, is the branch label. 3. If no mode was provided, ask in `ui_language` which mode to run: - Human-guided QA - Automated-agent QA Resolve the working branch: ```text If git_enabled = false or the repository is not a git work tree: If branch was provided in arguments → use it as the resolved branch label Otherwise → set resolved_branch = "manual" If git_enabled = true and the repository is a git work tree: If branch was provided in arguments → use it as the resolved branch Otherwise → run: git branch --show-current ``` Store: - `resolved_branch` - `artifact_dir = /` - `test_cases_path = /test-cases.md` - `qa_check_path = /qa-check.md` Compute `branch-slug` with the exact same algorithm as `/aif-qa`: 1. Replace every character not in `[A-Za-z0-9._-]` with `-`, collapse consecutive `-`, trim leading/trailing `-`, and use `branch` if empty. Then MUST truncate `safe_slug` to the first 40 ASCII characters. Because the normalized `safe_slug` alphabet is `[A-Za-z0-9._-]`, byte length and character length are identical. 2. Run `git hash-object --stdin <<< ""` and take the first 8 hex characters as `hash8`. 3. Combine: `branch-slug = "-"`. ### Step 1: Verify QA Inputs Check for `/test-cases.md`. If it is missing, STOP and ask in `ui_language` whether to: 1. Run `/aif-qa test-cases ` first 2. Cancel Read `test-cases.md`. Extract test cases by IDs (`TC-001`, `TC-002`, etc.), titles, priority, type, execution surface when present, preconditions, steps, expected results, and test data. Preserve their order. Compute source binding metadata before creating or modifying `qa-check.md`: - `source_digest` — deterministic digest of the full `test-cases.md` content using `git hash-object --no-filters ` when available, or `git hash-object --stdin` over the exact file content. - `case_digests` — deterministic per-case digest for each extracted `TC-NNN`, computed from that case's canonical block including title, priority, type, preconditions, steps, expected result, and test data. - `tested_revision` — when `git_enabled = true` and the repository is a git work tree, run `git rev-parse HEAD` and record the resolved commit SHA. - `worktree_digest` — when `git_enabled = true` and the repository is a git work tree, record a deterministic digest of the current working tree state so dirty-tree QA cannot be reused after local changes without a commit. - `manual_build_id` — when `git_enabled = false` or the repository is not a git work tree, ask the user for an explicit build/version identifier before creating or resuming results. Do not accept an empty identifier. Canonicalize each per-case digest input exactly: 1. Extract the raw Markdown block from the line containing the case's `TC-NNN` identifier through the line before the next `TC-NNN` block or end of file. 2. Normalize line endings from CRLF or CR to LF. 3. Remove trailing spaces and tabs from each line. 4. Trim leading and trailing blank lines from the extracted block. 5. Preserve the original field order, bullet markers, indentation, internal blank lines, Markdown punctuation, and all remaining whitespace. Do not sort fields, collapse whitespace, or rewrite bullets. 6. Wrap the normalized block with raw block boundaries before hashing: `BEGIN TC-NNN\n\nEND TC-NNN\n`. 7. Hash the wrapped block with `git hash-object --stdin` when available, or another stable SHA-1/SHA-256 digest if git is unavailable. Compute `worktree_digest` exactly when git is enabled and a git work tree exists: 1. Capture `git status --porcelain=v1 --untracked-files=all`. 2. Capture `git diff --binary HEAD --`. 3. Exclude `qa_check_path` from the status, diff, and untracked-file digest inputs so saving `qa-check.md` does not stale its own results. Do not exclude `test_cases_path`; source changes are also tracked by `source_digest`. 4. For each untracked file listed by porcelain status except `qa_check_path`, append `UNTRACKED

` where `` is `git hash-object --no-filters ` when the file is readable. 5. Normalize line endings in the combined input to LF and hash it with `git hash-object --stdin`. 6. If the filtered work tree input is clean, record the digest of the canonical string `clean\n`. If `mode = agent`, perform Step 1.1 before creating or modifying `qa-check.md`. Existing `qa-check.md` may be inspected read-only during this gate. If `qa-check.md` exists, read it and resume from existing statuses only after comparing stored binding metadata to the current binding metadata: - If `tested_revision` changed, mark every prior result as `Stale` and unchecked, preserve prior comments/evidence as historical context, and require retest. Do not count stale pass/fail/block statuses as current. - If `worktree_digest` changed, mark every prior result as `Stale` and unchecked, preserve prior comments/evidence as historical context, and require retest. Do not count stale pass/fail/block statuses as current. - If `manual_build_id` changed, treat it the same as a tested revision change. - If `source_digest` changed, compare `case_digests`. Preserve current status only for cases whose per-case digest is unchanged and whose tested revision/manual build id and worktree digest are unchanged. - If an existing case's digest changed, mark that case `Stale`, unchecked, and require retest. - If a new case appears, add it as unchecked `Pending`. - If a prior case no longer exists in `test-cases.md`, keep its historical entry marked `Stale` or move it to an artifact-language "Stale / Removed Cases" section; never count it as current. - Do not overwrite prior pass/fail comments unless the user explicitly chooses to retest that case. If `qa-check.md` does not exist, create it from `templates/QA-CHECK.md` using the extracted test cases and source binding metadata. Every case starts unchecked and `Pending`. ### Step 1.1: Agent Mode Capability and Safety Preflight Agent mode is user-only (`disable-model-invocation: true`) because it can perform live browser actions, shell commands, local service calls, and other checks with meaningful side effects. Before executing any case or writing `qa-check.md` in agent mode: 1. Detect available execution capabilities from the current runtime tools: - shell/CLI command execution - project test runners and build tools available through shell - live browser automation through in-app Browser or Playwright MCP - HTTP/API checks available through existing project tooling or safe shell commands - file, document, and repository inspection through Read/Grep/Glob 2. Classify each test case by the evidence surface it requires: `browser-ui`, `cli`, `backend-test`, `api`, `file-docs`, `database-read`, `hybrid`, `human`, or `unknown`. If the case has an explicit `Execution surface:` field, use it unless the case text clearly contradicts it; record any override in `agent-history.md`. 3. Choose the least invasive capability that can produce concrete evidence for that case. Browser automation is REQUIRED for browser/UI-observable cases and hybrid cases whose expected result depends on rendered web behavior. Do not substitute CLI commands, unit tests, static inspection, or backend checks for a browser/UI case; those may be recorded only as supporting evidence. 4. If a case requires browser automation, prefer the in-app Browser capability if available. If in-app Browser is not available, use Playwright MCP if available. 5. If a browser/UI case requires live browser automation and neither in-app Browser nor Playwright MCP is available, keep only that case unchecked, set status to `Blocked`, ask the user in `ui_language` to enable a live browser capability, and append this blocker to `/agent-history.md`. Continue with other cases that can be verified through CLI, tests, API, or file/document checks. 6. Use `/agent-context.md`, `/agent-history.md`, `test-cases.md`, `change-summary.md`, project docs, current browser state, and repository scripts to determine the target URL, service startup commands, test commands, and environment. 7. For browser/UI cases that require authentication or specific user state, resolve a browser test identity before marking the case blocked: - First search `agent-context.md`, `agent-history.md`, test data, seeders/factories/fixtures, docs, local database-safe reads, and existing test users for a matching non-sensitive test identity. - If the environment is clearly `local`, `test`, or disposable `development`, and repository tooling provides a safe way to create or seed a synthetic test user/state, create the minimal disposable fixture needed for the case. Record the fixture identifier and setup command/evidence in `qa-check.md`. - If creating a fixture requires a password, role, tenant, workspace, feature flag, seed command, or any unclear setup decision, ask the user before blocking. Ask whether to provide an existing test account or authorize creating a disposable fixture. - If the user provides or authorizes disposable test credentials for a `local` or `test` environment, use them for this run. Store credentials in `agent-context.md` only if the user explicitly says they are reusable test-only credentials and safe to persist. Otherwise store only the username/role and where to retrieve the secret. - Never store production credentials, personal credentials, cookies, session tokens, one-time codes, or shared secrets in `agent-context.md` or `agent-history.md`. 8. If a user-suppliable prerequisite is missing, ask the user before blocking: - application URL or login URL - test account role or non-sensitive username - where to find credentials without exposing them in artifacts - authorization to create a disposable local/test browser fixture and the desired initial state - required startup state, seed data, feature flag, tenant, organization, or workspace - ambiguous login mechanism or authentication provider - stable selector, field identifier, or page route needed to continue - exact project command, test filter, service startup command, or safe API endpoint needed to continue 9. Save reusable non-sensitive answers to `/agent-context.md` immediately only when the answer is general enough to help future QA sets. Append the redacted answer summary to `/agent-history.md` only when it captures a reusable lesson; otherwise keep it in the branch-specific `qa-check.md` evidence/comment. 10. Determine and display the target environment, including URL when applicable and inferred environment class: `local`, `development`, `staging`, `test`, `production`, or `unknown`. 11. Do not execute browser actions, API writes, CLI commands with side effects, database writes, destructive commands, payment, permission, email, notification, data export, or other external-side-effect steps against `production` or `unknown` targets without explicit user authorization immediately before execution. Record the authorization decision and target class in `qa-check.md`. Append it to `agent-history.md` only when it creates a reusable cross-QA policy or recurring authorization lesson; do not persist broad production authorization for future runs. 12. Inspect each case and proposed command for destructive, irreversible, payment, permission, email, notification, data export, database mutation, service restart, deployment, filesystem deletion, or other external-side-effect risk. Require explicit per-case authorization before executing any such case. 13. Prefer read-only and test-scoped commands. Do not run destructive shell commands such as `rm`, `git reset`, `git checkout --`, database resets, migrations against shared environments, deploy commands, or cleanup commands that delete user data unless the user explicitly authorizes the exact action. 14. If authorization is denied or unclear, leave the case unchecked, set status to `Blocked`, and write the blocker to `qa-check.md` without executing the risky action. Append the decision to `agent-history.md` only when it is a reusable cross-QA lesson, not merely a case-specific denial. Redaction is mandatory for agent comments/evidence and all human-entered comments/evidence: - Redact credentials, cookies, authorization values, session tokens, API keys, bearer tokens, basic auth values, one-time codes, and personal secrets. - Redact sensitive URL parameters such as `token`, `access_token`, `refresh_token`, `id_token`, `code`, `secret`, `password`, `passwd`, `pwd`, `auth`, `key`, `api_key`, `session`, `sid`, and `jwt`. - Replace redacted values with `[REDACTED]` before writing comments or evidence to `qa-check.md`. - Do not paste raw browser storage, cookies, request headers, authorization headers, or token-bearing URLs into the artifact. ### Step 2: Human Mode Run exactly one pending or selected test case at a time. For each case: 1. Show only that test case's title, priority, preconditions, steps, test data, and expected result. 2. Include a short per-case summary in `ui_language`. 3. The summary question MUST mean: "Test this and answer whether it works." For `ui_language = ru`, use exactly: `Протестируйте и ответьте работает или нет`. 4. Ask the user for the result: - Works / completed - Does not work / failed - Stop for now 5. If the user says it works, mark the case as checked (`[x]`) in `qa-check.md`, set status to `Passed`, and add the current mode as `human`. 6. If the user says it failed, keep the checkbox unchecked (`[ ]`), set status to `Failed`, ask for the reason, and write the user's explanation as the comment while preserving user wording except mandatory redaction of sensitive values. 7. Save `qa-check.md` after every case so progress survives context resets. Do not show the next test case until the current one has a result or the user stops. ### Step 3: Agent Mode Agent mode MUST produce concrete, case-appropriate evidence. Browser execution, CLI output, automated test output, API responses, backend command results, database-safe read results, or file/document inspection can each be enough to mark a case passed when that evidence directly covers the case steps and expected result. Internal deterministic invariants MUST be treated as automated checks, not manual QA. Cases involving service-method calls, cache state, materialized rows, exact arrays, raw database values, formula outputs, CLI internals, or similar non-human-observable behavior should be classified as `backend-test`, `cli`, `api`, or `database-read` as appropriate. First look for existing tests or commands that already cover the invariant. If existing tests are found and pass, mark the corresponding `TC-*` case `Passed` with the test class/name, command/filter, exit status, and assertion/result summary as evidence. If one test run covers multiple `TC-*` cases, reuse that evidence on every covered case and optionally summarize the shared run under "Supporting Automated Checks". If no suitable automated coverage exists, keep the case `Blocked` with a blocker such as `Missing automated test coverage for backend invariant`; do not ask the user to manually verify internal arrays or raw database values. Determine the test target: - If `agent-context.md`, `agent-history.md`, `test-cases.md`, `change-summary.md`, project docs, or current browser state clearly identify a URL, use it. - If repository scripts, test files, package manifests, Makefiles, framework commands, or docs clearly identify a safe command or test filter for a CLI/backend/API/docs case, use it. - If no URL, command, startup state, credentials location, test filter, or required fixture is clear, ask the user for the missing detail, then persist only the non-sensitive reusable facts to `agent-context.md`. - Do not invent credentials, URLs, commands, fixtures, or environment assumptions. - Use the target environment and authorizations collected in Step 1.1. Reconfirm if navigation redirects to a different host or a more sensitive environment. For each pending or selected case: 1. Select the execution surface from the case classification: - `browser-ui`: navigate with Browser or Playwright MCP and execute UI steps. - `cli`: run the relevant project command and inspect exit code/output. - `backend-test`: find and run the narrowest existing relevant test command or test filter first; broaden only when needed for confidence. Passing automated coverage is valid pass evidence for the case. - `api`: call the endpoint through existing project tooling, safe local commands, or browser/network capability as appropriate. - `file-docs`: inspect generated files, docs, config, or repository contents with Read/Grep/Glob and, when useful, project validation commands. - `database-read`: use only safe read-only checks unless the user explicitly authorizes mutation in a test-scoped environment. - `hybrid`: combine the necessary surfaces and record each evidence type. 2. Execute the test steps as written, adapting only mechanics that are obvious from the selected surface. 3. If execution stalls because of missing credentials, missing browser fixture, unavailable services, unclear setup, blocked navigation, missing selector knowledge, ambiguous field mapping, unknown route, unknown command, missing fixture, or unclear test filter, search `agent-context.md` and `agent-history.md` first. For browser/UI auth or user-state gaps, try safe local/test fixture discovery or creation as described in Step 1.1 before blocking. If the answer or fixture is not already available, ask the user exactly for the missing information or authorization before marking the case blocked. 4. When the user provides usable non-sensitive information, continue the case in the same run. Update `agent-context.md` with durable cross-QA facts and append the resolved friction to `agent-history.md` only if it is likely to recur in future QA sets. Keep case-specific details in `qa-check.md`. 5. If the user cannot provide the missing information, the service remains unavailable, authorization is denied, the required capability is unavailable, or a side-effect risk remains unresolved, keep the checkbox unchecked (`[ ]`), set status to `Blocked`, and write the blocker. 6. Compare the observed result to the expected result. 7. If observed behavior matches, mark the case checked (`[x]`), set status to `Passed`, and add concise redacted evidence. Evidence may be a browser observation, command and exit status, test name and result, API response summary, file path and matched condition, or other concrete observation. 8. If observed behavior does not match, keep the checkbox unchecked (`[ ]`), set status to `Failed`, and write a concrete redacted problem comment with observed vs expected behavior. 9. Save `qa-check.md` after every case. Before the final summary, write detailed per-run evidence to `qa-check.md`, not to root-level memory. This includes the current branch/QA target, commands executed, exit codes, assertion counts, supporting file checks, case mappings, summary counts, and one-off blockers. After writing `qa-check.md`, extract only reusable cross-QA learnings: - Update `/agent-context.md` when a discovered fact is durable and likely useful for future QA sets. - Append to `/agent-history.md` only when a blocker, selector, command pattern, test-filter convention, API endpoint pattern, route, setup note, or authorization decision is likely to recur beyond the current QA set. - It is valid to append nothing to `agent-history.md` for a successful run that produced no new reusable learning. - Never append a full run transcript, branch/QA target, per-run summary counts, exact assertion totals, or current QA-plan label to `agent-history.md`. Keep `/agent-context.md` concise and current; prefer stable facts over one-off observations. Do not write raw passwords, tokens, cookies, authorization headers, one-time codes, private personal data, token-bearing URLs, branch names, QA target paths, or run summaries. Use screenshots or browser state observations when the active runtime makes them available, but do not require screenshots to pass a test. ### Step 4: Final Summary After stopping or finishing, report in `ui_language`: - total test cases - passed - failed - blocked - pending - path to `qa-check.md` - path to `agent-context.md` and `agent-history.md` when agent mode ran or requested missing execution context - next recommended action If `mode = agent` and one or more current cases are `Blocked`, split them into human-verifiable blocked cases and automation-only blocked cases before ending. - Offer human-guided continuation only for blocked cases whose execution surface is `human`, `browser-ui`, `hybrid` with human-observable steps, or `unknown`. - Do NOT offer human-guided continuation for blocked `backend-test`, `cli`, `api`, `file-docs`, or `database-read` cases when the blocker is missing automated coverage, missing command/test filter, unavailable service, or another technical automation prerequisite. For those cases, recommend adding/running the appropriate automated check or providing the missing command/fixture/context. - If at least one human-verifiable blocked case exists, ask the user in `ui_language` whether to run those eligible blocked cases now in human-guided mode. - If the user agrees, continue in the same invocation using Step 2, but only for eligible blocked cases. Preserve existing agent blocker comments as context and append the human result/comment under the same case. - If the user declines or stops, keep those cases unchecked and `Blocked`. - Write the handoff decision and any resolved blocked cases to `qa-check.md`. Append to `agent-history.md` only when the handoff revealed a reusable cross-QA lesson. If any case failed, the next recommended action should be to fix the issue and rerun `/aif-qa-check `. If human-verifiable cases remain blocked after an agent-mode run and the user did not continue them in human mode, the next recommended action should be to run `/aif-qa-check human ` for those cases or provide the missing execution context. If automation-only cases remain blocked, recommend adding/running the required automated test, command, fixture, service, or context instead. Do not imply that a blocked case is a product defect unless there is concrete observed evidence. ## Artifact Ownership and Config Policy - Primary ownership: `//qa-check.md`, `/agent-context.md`, and `/agent-history.md`. - Read policy: may read `//change-summary.md`, `test-plan.md`, `test-cases.md`, `/agent-context.md`, and `/agent-history.md` as QA context. - Write policy: persistent writes are limited to `qa-check.md`, `agent-context.md`, and `agent-history.md`; do not rewrite `test-cases.md`, `test-plan.md`, `change-summary.md`, or `config.yaml`. - Config policy: config-aware, read-only. Reads `paths.description`, `paths.architecture`, `paths.qa`, `language.ui`, `language.artifacts`, `language.technical_terms`, and `git.enabled`; never writes `config.yaml`. ## Critical Rules 1. MUST NOT run without `test-cases.md`. 2. MUST show only one case at a time in human mode. 3. MUST ask the user whether the case works in human mode. 4. MUST preserve failed-user comment wording except mandatory redaction of sensitive values before writing. 5. MUST NOT mark a case passed in agent mode without concrete evidence from an appropriate execution surface for that case. 6. MUST NOT block non-browser cases merely because live browser automation is unavailable. 7. MUST classify deterministic internal/backend/CLI/API/database invariant cases as automated checks and MUST NOT route them to human manual QA as a substitute for missing automated coverage. 8. MUST bind current results to (`tested_revision` and `worktree_digest`) or `manual_build_id`, plus `source_digest` and `case_digests`. 9. MUST mark stale results stale when the tested revision, worktree digest, manual build id, full source digest, or per-case digest changes. 10. MUST require explicit authorization for production/unknown targets and destructive or external-side-effect cases. 11. MUST redact credentials, cookies, authorization values, tokens, and sensitive URL parameters before writing comments or evidence. 12. MUST save progress after every case. 13. MUST read `agent-context.md` and `agent-history.md` before automated execution and before asking the user for setup facts, so prior answers are reused. 14. MUST ask the user for missing user-suppliable execution context before blocking an agent-mode case for missing URL, credentials, login route, field identifiers, setup state, selectors, commands, test filters, fixtures, or similar recoverable information. 15. MUST NOT block a browser/UI case for missing login credentials or user state until it has searched reusable context, existing fixtures, seeders/factories, docs, and safe local/test data; attempted safe disposable fixture creation when the environment is local/test and tooling is available; or asked the user for credentials, fixture setup, or authorization to create a disposable fixture. 16. MUST persist reusable test-only credentials in `agent-context.md` only after explicit user permission, and MUST never persist production credentials, personal credentials, cookies, session tokens, one-time codes, or shared secrets. 17. MUST write only reusable non-sensitive cross-QA answers and discovered stable execution facts to `agent-context.md`, and MUST append to `agent-history.md` only when a recurring reusable learning or blocker pattern was discovered. 18. MUST ask whether to continue eligible blocked agent-mode cases in human mode before ending an agent run with any current human-verifiable `Blocked` cases.