[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RG8Z9XTW5D11SH2EKH8F2":3,"skill-same:01M71RG8Z9XTW5D11SH2EKH8F2":149},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71RG8Z9XTW5D11SH2EKH8F2","autospec-qa",null,"Use when the user wants to revalidate a running app against a spec, regenerate missing or weak tests, audit UI controls\u002Fforms\u002Fvalidation\u002Fdropdowns\u002FAPI behavior\u002Faccessibility, or prove implemented features actually work after autospec-run.","berlinguyinca\u002Fautospec","berlinguyinca","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16364?v=4","01M71R7C0SWBG05FNHQE4XQ7Y3","Gert Wohlgemuth","01M71R7C1VY5K3Q715RNDDBVGQ",3,"MIT","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"autospec","autospec qa","qa","running","features","audit","work","api","when","user","validation","behavior","use","prove","controls","tests","ui","forms","run","app","2026-11-10 13:02:02",false,"---\nname: autospec-qa\ndescription: Use when the user wants to revalidate a running app against a spec, regenerate missing or weak tests, audit UI controls\u002Fforms\u002Fvalidation\u002Fdropdowns\u002FAPI behavior\u002Faccessibility, or prove implemented features actually work after autospec-run.\n---\n\n# autospec-qa workflow\n\nRun a spec-to-running-app QA audit, then regenerate missing or weak tests until\nthe application behavior is covered by executable evidence. This skill is the\nexplicit revalidation companion to `autospec-test`: `autospec-test` gates PRs\nwith deterministic coverage and E2E checks; `autospec-qa` performs a broad\nhuman-style audit from the spec and turns gaps into stronger tests or follow-up\nissues.\n\n## Cluster dispatch\n\nThe per-area prose for this skill is also available as 8 cluster files under\n`skills\u002Fautospec-qa\u002Fclusters\u002F\u003Cname>.md`, dispatched by\n`qa-cluster-dispatch.sh` (issue #730). The 8 canonical clusters are:\n\n1. `spec-traceability` — extract spec requirements + traceability matrix.\n2. `functional-coverage` — UI controls, forms, validation, dropdowns, buttons.\n3. `backend-integration` — API contracts + no-mock smoke + live backend triage.\n4. `reliability-contract` — proof matrix, control ledger, mutation, canary,\n no-mock coverage, observability, data lifecycle.\n5. `legacy-and-cleanup` — legacy removal gate + spec\u002Fdocs cleanup +\n deprecated-surface scan.\n6. `benchmark-and-outsourcing` — benchmark-overfit gate + outsourced-\n implementation gate.\n7. `accessibility-and-responsive` — a11y + viewport + browser variance.\n8. `production-incidents` — incident registry regression check (PR #661).\n\nEach cluster carries only its area's prose plus the spec under audit. The\norchestrator (`qa-cluster-dispatch.sh`) is harness-aware (via\n`lib\u002Fautospec-harness-detect.sh`, PR #725), honors\n`qa-cluster-coverage.sh` for cross-cluster dedup, and honors\n`qa-verify-finding.sh` for verify-first filtering. Aggregated findings\nland in `.autospec\u002Fqa-verdict.json`, which the existing heal loop\n(PR #666\u002F#713) consumes unchanged.\n\nThe full per-area prose in the sections below remains canonical for now;\ncluster files reference it and will be backfilled as the dispatch model\nmatures. Operators can opt out individual clusters via\n`qa-cluster-dispatch.sh --skip-cluster \u003Cname>`.\n\n## Deployment contract\n\n`\u002Fautospec-qa` assumes the app under audit is already running at the URL the\noperator supplies. For repos that need a fresh deploy plus a scoped test-data\nclone before each QA cycle, the optional declarative contract\n`.autospec\u002Fqa-deploy.yml` stands the app up **first** and records what\u002Fwhen\u002Fwhere\ninto the verdict — so a failed deploy surfaces as a single\n`code_health:qa_deploy_*` finding instead of a downstream `502` triage trail.\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-deploy-runner.sh\" \\\n --repo-dir . --verdict .autospec\u002Fqa-verdict.json\n```\n\nis invoked at the **very start** of the orchestration — **before any cluster\nfan-out** — and its exit code gates the audit. The Live backend blocker triage\nprompt above stays as-is: it covers the deploy-succeeds-but-app-unhealthy-mid-\naudit case; the deploy runner covers the never-deployed case.\n\n**Contract file `.autospec\u002Fqa-deploy.yml`** mirrors the declarative style of\n`.autospec\u002Ftest.yml`, parsed with `yq -o=json` and validated against\n`schemas\u002Fautospec-qa-deploy.schema.json` with `ajv` (the same yq → jq → ajv\ntoolchain `skills\u002Fautospec-test\u002Fscripts\u002Fload-contract.sh` uses). Its presence\nmakes deploy mandatory. Key fields:\n\n- `stages[]` (required) — ordered deploy stages run sequentially under each\n stage's `timeout` (default 300s); first failure aborts the rest. Each stage\n has a `name`, a `command` run via `bash -c`, optional `env`, and an optional\n `health_check` (`url`, `expect_status` default 200, `retry` default 30,\n `retry_interval` default 10s) polled after the command.\n- `stages[].safety.max_records` — **required** for any data-clone stage (name or\n command matching `clone|copy|replicate|sync`).\n- `teardown[]` — post-verdict cleanup entries (`name`, `command`, `on_failure`\n `warn`|`fail`).\n- `target_envs.forbidden` (required, ≥1) — the absolute safety floor.\n- `target_envs.allowed` \u002F `safety.notes` — advisory, recorded.\n\n**Safety floor (non-negotiable, enforced regardless of operator config),** each\nviolation aborts immediately, runs no further stages, and exits **3**:\n\n1. **Forbidden-target match** — each `target_envs.forbidden` token (literal,\n case-insensitive substring) matched against each stage `command`,\n `health_check.url`, and captured stdout → `qa_deploy_forbidden_target`.\n2. **Production-pattern rejection** — each deploy\u002Fteardown `command` matched\n word-boundary case-insensitively against `--prod`, `--production`, ` prod `,\n ` production `, `production-only`, `live-prod` → `qa_deploy_prod_pattern`.\n3. **`max_records` required for data-clone stages** — a `clone|copy|replicate|\n sync` stage without `safety.max_records` → `qa_deploy_missing_records_cap`.\n\n**Exit-code gating:**\n\n| Exit | Meaning | Verdict category |\n| --- | --- | --- |\n| 0 | No `.autospec\u002Fqa-deploy.yml` (no-op), or all stages + probes succeeded | — \u002F `deploy` block |\n| 1 | A stage failed\u002Ftimed out, or a `health_check` exhausted retries | `code_health:qa_deploy_failed` |\n| 2 | Usage \u002F contract invalid (ajv fail, malformed YAML, missing required) | `code_health:qa_deploy_invalid_contract` |\n| 3 | Safety-floor violation | `qa_deploy_forbidden_target` \\| `qa_deploy_prod_pattern` \\| `qa_deploy_missing_records_cap` |\n\nA failed deploy (exit 1\u002F2\u002F3) never reaches the cluster fan-out: the operator\nsees a single `code_health:qa_deploy_*` finding naming the failing stage and a\nstdout tail, not a `502`.\n\n**`deploy:` verdict block.** On success the runner writes a `deploy:` block into\n`.autospec\u002Fqa-verdict.json` (atomically via the sibling `.tmp` + `mv` pattern\nfrom `qa-finding-filter.sh`; a minimal `{\"deploy\": {...}}` is created\nwhen no verdict exists yet, which the later audit merges into):\n\n```json\n{\n \"deploy\": {\n \"stages_run\": [\"deploy-to-test-family\", \"clone-production-data\"],\n \"stage_durations_ms\": {\"deploy-to-test-family\": 145000},\n \"target_env\": \"https:\u002F\u002Ftest.tidyboard.org\",\n \"head_sha_deployed\": \"abc1234\",\n \"data_clone\": {\"source\": \"prod-readonly\", \"records_copied\": 8500, \"max_records\": 10000},\n \"teardown_run\": true,\n \"teardown_failures\": []\n }\n}\n```\n\n`head_sha_deployed` = `git rev-parse --short HEAD` at deploy time.\n`data_clone.records_copied` is parsed from a `records_copied=\u003Cint>` stdout line\nwhen present, else omitted. The block is **additive** — every existing verdict\nconsumer (heal loop, `\u002Fautospec-release`, `\u002Fautospec-sweep`) is unaffected.\n\n**Teardown.** `teardown[]` entries run after the verdict is final, unless\n`--skip-teardown` is passed (which sets `deploy.teardown_run: false` and leaves\nthe env intact for repeated manual re-QA). `on_failure: warn` logs only;\n`on_failure: fail` downgrades a `PASS` verdict to `PARTIAL` (never touches\n`FAIL`) and appends the entry to `deploy.teardown_failures`.\n\n**Graceful absent-file behavior.** When `.autospec\u002Fqa-deploy.yml` is absent the\nrunner exits `0` immediately, writes nothing, and QA proceeds exactly as today —\nthe verdict is byte-identical with no `deploy:` key. This compatibility contract\nis the most important one: behavior is byte-for-byte today's behavior when the\nfile is not present. Secret env **values** are never logged or recorded (only\nkey names). The runner uses `set -u` (not `set -e`) around stage execution so\nfailures are caught explicitly and recorded in the verdict.\n\n\u003C!-- autospec-block:startup-self-update SKILL_NAME=autospec-qa -->\n\n## Self-update mode\n\nIf the feature-request argument matches `update` after trimming and lowercasing,\nre-install the full autospec suite from `main`, show the before\u002Fafter diff if the\nharness exposes it, then stop. Do not run the QA audit.\n\n## Required capabilities & harness adapter\n\n| Capability | Claude Code | OpenCode | Codex CLI | Fallback if missing |\n| --- | --- | --- | --- | --- |\n| Subagent model tier | Tier A: `opus` + ultrathink | Tier A: top-tier `task` + max reasoning | Tier A: current top GPT + `reasoning_effort=high` | Run inline, but keep the same report contract |\n\u003C!-- autospec-block:harness-adapter-core -->\n| Browser\u002FE2E execution | Playwright\u002Fbrowser tool or shell | Playwright\u002Fbrowser task | shell + browser when available | Use `browser-verified` \u002F `fallback-smoke-only` \u002F `not-run`; mark UI-only gaps with blocker |\n| Shell execution | Bash tool | shell tool | shell\u002Fapply_patch | Required for regeneration |\n\n**Model tier:** TIER_A for the spec audit and test-regeneration plan because\nfalse PASS results are more expensive than extra review tokens.\n\n## Harness detection\n\nDetect the harness once at skill start:\n\n1. Claude Code: `Agent` with `subagent_type` is available.\n - `TIER_A` = `opus` + ultrathink.\n - `TIER_B` = `sonnet`.\n2. OpenCode: `task` tool is available.\n - `TIER_A` = top-tier task model + high reasoning.\n - `TIER_B` = smaller-tier task model + medium reasoning.\n3. Codex CLI: `apply_patch` is the primary edit tool.\n - `TIER_A` = current top GPT + `reasoning_effort=high`.\n - `TIER_B` = current cost-optimized Codex model + `reasoning_effort=medium`.\n\nPrefer a Tier A reviewer\u002FQA subagent for the first traceability audit when the\nharness supports it. If `TIER_A` is unavailable, silently fall back to the next\navailable top-tier model. If delegation is unavailable, run the audit inline.\n\n## When to use\n\n- After `\u002Fautospec-run` finishes and the operator wants proof that the app\n actually satisfies the source spec.\n- When a UI-heavy feature needs text boxes, validation, selects, dropdowns,\n buttons, navigation, modals, keyboard behavior, accessibility, and API effects\n verified from multiple directions.\n- When existing tests pass but the spec may still be under-tested.\n- When the user asks to regenerate tests from a spec or strengthen weak tests.\n\n## When not to use\n\n- Do not use against production unless the target repo's `autospec-test`\n contract explicitly allows scoped production and backup\u002Frestore is verified.\n- Do not mark a feature PASS from code inspection alone.\n- Do not loosen assertions to make regenerated tests pass.\n- Do not treat mocked API tests as proof that a deployed workflow works.\n\n## No-mock deployed smoke rule\n\nFor every user workflow button or dropdown-backed action, QA must cover both the\ncontract and the deployed user-visible result:\n\n1. Verify the control is enabled and changing it changes the actual request\n payload, query, route, or command parameters.\n2. Run a mocked happy-path test for deterministic UI state coverage.\n3. Run a no-mock smoke test against the configured deployed\u002Fdev URL using a\n representative input from the spec or domain fixtures.\n4. Assert that no generic live-failure banner appears.\n5. Assert that the result panel contains a real domain result, not only that a\n request was sent.\n6. Include regression coverage for known fragile backend responses, such as\n `502` bridge\u002Fproxy failures, and require either a working fallback route or a\n clear actionable user state.\n7. Re-check the endpoint mental model against the app and production behavior:\n if a mocked route differs from the route that actually supports the workflow,\n tests must follow the user-visible workflow and document the stable backend\n contract they prove.\n\n## No-mock deployed smoke blocker handling\n\nIf a required no-mock deployed\u002Fdev smoke path is `NOT TESTED`, the final verdict\nmust be `PARTIAL` unless the target repo's explicit test contract says that\nworkflow intentionally has no deployed smoke requirement.\n\nDo not leave a no-mock smoke gap as a prose-only \"remaining risk.\" For every\n`NOT TESTED` no-mock smoke row, create or draft one of:\n\n1. An environment setup issue\u002Ftask that names the missing dev URL or env var,\n representative seed\u002Flive data, credential requirements, backup\u002Frestore\n constraints, and exact smoke workflow command or Playwright scenario.\n2. A test contract update in `.autospec\u002Ftest.yml`, `docs\u002F**`, or the repo's\n equivalent QA contract explaining why deployed smoke is intentionally\n unavailable for that workflow.\n3. An operator-blocker line with the exact missing configuration and the next\n command to rerun once it exists.\n\nIf a dev URL and representative data are supplied, run the no-mock smoke test\ninstead of drafting setup work. If credentials or data are missing, keep the\ntraceability row `NOT TESTED`, keep the overall result `PARTIAL`, and make the\nsetup artifact the required next action.\n\n## Presentational control classification\n\nExample chips, demo shortcuts, taxonomy tokens, conversion presets, and similar\ncontrols must be classified before the report is finalized:\n\n- `decorative\u002Fpresentational`: assert that the element has no action contract,\n no request side effect, and is either documented or clearly inert.\n- `workflow control`: verify request contract, mocked happy path, no-mock smoke\n path, success-state result, failure-banner absence, and known-fragile-backend\n fallback behavior.\n\nDo not report presentational chips as a vague risk. Either prove they are\nintentionally decorative or file\u002Fdraft the issue that wires and tests them as\nreal controls.\n\n## User input element intent prompt\n\nUse this prompt every time the app creates, changes, tests, or audits any\nuser-input element, including text boxes, textareas, selects, dropdowns,\ncomboboxes, checkboxes, radio buttons, switches, date\u002Ftime inputs, file inputs,\nsearch boxes, filters, sliders, segmented controls, editable tables, chips, or\nother controls that accept or change user intent:\n\n```text\nFor this user input element, answer before accepting the implementation or test:\n\n1. What is this control for?\n2. Which user goal or spec requirement does it serve?\n3. How should a real user discover and use it?\n4. What valid, invalid, empty, boundary, and recovery inputs must work?\n5. What request payload, query, route, command, state change, persistence effect,\n or visible result should change when the user changes this input?\n6. What should happen when the backend rejects, times out, or partially accepts\n this input?\n7. Is this control intentionally read-only, disabled, decorative, or\n presentational? If yes, where is that contract documented?\n8. Did I implement and test this correctly, with evidence from the running app\n rather than only DOM presence or mocked request dispatch?\n\nRequired outcome:\n- If the control is functional, tests must cover discoverability, enabled\u002Fdisabled\n state, valid input, invalid input, boundary input, request\u002Foutput effect,\n success state, error state, and recovery.\n- If the control is decorative or read-only, the QA report must classify it that\n way and cite the spec, UI copy, or test contract that makes this intentional.\n- If the answers are unclear, mark the traceability row AMBIGUOUS or PARTIAL and\n draft the smallest spec\u002Ftest\u002Fimplementation follow-up needed to settle it.\n```\n\n## Live backend blocker triage prompt\n\nWhen a no-mock deployed\u002Fdev smoke path is blocked by missing config, unknown\ncredentials, `502`, `504`, timeout, bridge, queue, worker, proxy, or backend\nhealth errors, do not stop at \"credentials unavailable\" or \"live backend not\ntested\" until you have made a bounded, non-secret-leaking config search.\n\n```text\nFor this live backend blocker, answer before finalizing the QA report:\n\n1. Where does the app define its deployed\u002Fdev base URL, API endpoint, worker\n endpoint, queue\u002Fbridge URL, and environment-specific service names?\n2. Are these values available through safe config surfaces such as Terraform\n outputs, deployment manifests, CI variables, documented env vars, cloud\n resource names, or local `.env.example` files?\n3. If credentials are required, which secret names or credential sources are\n referenced, and can the smoke test use them without printing secret values?\n4. If temporary credential files or tokens are created for probing, were they\n stored outside the repo, restricted, and removed after the probe?\n5. Is the failure caused by missing credentials, stopped infrastructure,\n unhealthy bridge\u002Fproxy, missing worker, wrong route mental model, or a live\n handler\u002Findex path that times out?\n6. Can a direct health\u002Fstatus\u002Ffleet\u002Fping probe distinguish infrastructure\n outage from a route-specific worker failure?\n7. Which no-mock smoke paths now pass with real domain data, and which exact\n route\u002Fsubject still fails?\n8. What operator action, infrastructure fix, worker fix, or fallback behavior is\n required next?\n\nRequired outcome:\n- Never print secret values in the QA report, logs, issue body, or test output.\n- If credentials\u002Fconfig are discoverable, run the no-mock smoke instead of\n leaving it `NOT TESTED`.\n- If infrastructure was stopped or unhealthy and can be safely started by the\n target repo's documented dev procedure, record the action and rerun the smoke.\n- If broad health probes pass but one route\u002Fsubject times out, classify the\n blocker as a route-specific live worker\u002Fhandler failure, not missing\n credentials.\n- Report passed live paths and the remaining failing path separately.\n```\n\n## Proof artifact requirements\n\nThe QA pass should produce machine-readable proof artifacts whenever the target\nrepo permits writing under `.autospec\u002F`. If the repo is read-only, draft the\nartifact contents in the report.\n\nRequired artifacts:\n\n- `.autospec\u002Fproof-matrix.json`: one row per spec requirement with fields for\n `requirement_id`, `spec_reference`, `expected_behavior`,\n `implementation_files`, `automated_tests`, `live_evidence`, `status`,\n `blocker`, and `follow_up`.\n- `.autospec\u002Freliability.yml`: the generated app reliability contract,\n including required live smoke workflows, representative inputs, seed\u002Flive data\n sources, allowed mocks, required no-mock paths, health probes, expected\n fallback behavior, forbidden production URLs, and forbidden false-green\n conditions such as \"PASS from DOM presence only.\"\n- `.autospec\u002Fcontrol-intent-ledger.json`: every discovered user input, button,\n link, chip, dropdown, form, modal trigger, table action, and workflow control\n classified as `functional`, `read_only`, `decorative`, or `unclassified`, with\n intent, owning spec reference, selector\u002Flocator, expected effect, tests, and\n evidence.\n- `.autospec\u002Fmutation-proof.json`: critical workflow assertions that were\n intentionally broken or simulated and proved that the test suite fails when\n the implementation regresses.\n- `.autospec\u002Fcanary-results.json`: post-merge or deployed\u002Fdev no-mock canary\n results for representative workflows when a deployed\u002Fdev environment exists.\n\nValidate written artifacts against the matching repository schemas when tooling\nis available:\n\n- `schemas\u002Fautospec-proof-matrix.schema.json`\n- `schemas\u002Fautospec-reliability.schema.json`\n- `schemas\u002Fautospec-control-intent-ledger.schema.json`\n- `schemas\u002Fautospec-mutation-proof.schema.json`\n- `schemas\u002Fautospec-canary-results.schema.json`\n\nUse `validate-qa-artifacts.sh --repo \u003Ctarget-repo>` when the autospec\nrepository helper is available. It validates present `.autospec\u002F*` proof files\nand fails malformed artifacts while warning about missing draft-only artifacts.\n\nHard gate: a QA result cannot be `PASS` if `.autospec\u002Fproof-matrix.json` has a\n`FAIL`, `PARTIAL`, `NOT_TESTED`, `AMBIGUOUS`, or unblocked `unclassified` row.\n\n## Artifact freshness gate\n\nEvery proof artifact must carry freshness metadata:\n\n- repository commit SHA,\n- spec file path,\n- spec hash,\n- app URL or environment,\n- test command hash when practical,\n- generation timestamp.\n\nBefore accepting an artifact, compare its freshness metadata to the current\ncheckout and tested environment. If the spec, implementation, app URL, or test\ncommand changed after the artifact was generated, mark the artifact stale and\nthe affected rows `PARTIAL` until regenerated.\n\n## Documentation gate\n\nEvery QA run invokes `\u002Fautospec-doc --full` (via\n`skills\u002Fautospec-doc\u002Fscripts\u002Fdoc-orchestrator.mjs --full`), then runs\n`verify-examples.mjs` across the regenerated pages, then runs\n`check-doc-drift.sh --working-tree` expecting a clean working tree.\n\n`documentation.auto_regenerate` is NOT consulted here. QA is the guaranteed\nsync point for documentation correctness, independent of the operator-controlled\nauto-regeneration switch.\n\nEach of the following failure classes is a **QA finding** in the standard QA\nreport format, subject to the same severity discipline as the no-mock smoke rule\n(never silently skipped):\n\n- **Generation error** — `doc-orchestrator.mjs --full` exits non-zero or\n produces no output pages.\n- **Failing example** — `verify-examples.mjs` reports one or more example\n failures across the regenerated audience pages.\n- **Residual drift** — `check-doc-drift.sh --working-tree` exits non-zero,\n indicating that generated pages differ from what is committed.\n- **Missing audience page** — a required audience page is absent from the\n output after generation.\n\nFailures are reported as findings with `release_blocking: true` and `category:\ndocumentation_gate`, mirroring the no-mock smoke handling.\n\n**Graceful skip** (logged as INFO, not a finding): when the target repo has no\n`documentation:` config (orchestrator exits 2), the gate records an INFO log\nline — `docs: no documentation config found (exit 2), gate skipped` — and\ncontinues without emitting a finding. No other skip condition is permitted.\n\n## Repo quality audit\n\nAfter QA proof artifacts are written, run the shared read-only quality audit so\nthe QA report carries repo-wide code-quality, verification, dependency, route,\nsecurity, and maintainability gaps discovered during revalidation:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frepo-quality-audit.sh\" \\\n --repo . \\\n --json \".autospec\u002Frepo-quality-audit.json\" \\\n --markdown \".autospec\u002Frepo-quality-audit.md\" \\\n ${AUTOSPEC_QUALITY_AUDIT_FILE_ISSUES:+--file-issues}\n```\n\nInclude the audit `status`, filed issue links, suppressed findings, and unfiled\nresidual risks in the final QA verdict. The helper is read-only with respect to\nsource files; it only writes audit artifacts and optional deduplicated GitHub\nissues when operator policy permits issue creation.\n\n## Evidence provenance gate\n\nEvery `PASS` must cite provenance that another reviewer can inspect:\n\n- test file and test name,\n- command and result,\n- screenshot, video, trace, or log path when relevant,\n- network request\u002Fresponse summary,\n- deployed\u002Fdev URL and representative input for no-mock smoke,\n- backend health\u002Fprobe result when backend behavior is claimed.\n\nNo provenance means no `PASS`. Request dispatch alone, DOM presence alone, a\ngeneric result panel change, or a mocked-only response is not sufficient\nprovenance for backend-backed behavior.\n\n## Console and network error gate\n\nFor each browser or deployed\u002Fdev workflow, inspect console and network signals.\nThe workflow fails unless the error is the explicit negative path under test:\n\n- uncaught frontend exceptions,\n- failed network calls,\n- hydration\u002Fruntime warnings that affect the route,\n- generic live-failure banners,\n- unexpected retries, timeouts, or aborted requests,\n- swallowed errors that leave stale UI.\n\nRecord expected negative-path failures separately from unexpected errors.\n\n## Spec contradiction detector\n\nBefore implementation, test generation, or final QA, scan the spec and current\nUI\u002FAPI behavior for contradictions:\n\n- two requirements conflict,\n- an acceptance criterion is not testable,\n- UI copy implies behavior the spec does not mention,\n- backend\u002FAPI contract contradicts product wording,\n- error\u002Ffallback behavior is unspecified for a required workflow,\n- required seed\u002Flive data is missing for a no-mock path.\n\nContradictions become `AMBIGUOUS` rows with a proposed resolution and a\nspec\u002Fconfig follow-up before implementation is called complete.\n\n## Spec supersession (recency)\n\nWhen two specs in `docs\u002Fspecs\u002F` overlap on a behavior, the spec whose\nlast-modifying commit on the current branch is most recent wins (issue #635:\nimplicit-by-recency supersession; untracked specs fall back to filesystem\nmtime). Operators do NOT write `Supersedes:` frontmatter — recency alone\ndecides.\n\nQA validation MUST resolve each behavior to its authoritative spec before\nclassifying a row as `FAIL`. Behavior present only in an older, superseded\nspec is not a QA failure — it has been replaced by the newer spec. Use the\nshared helper to look up the authoritative spec for each behavior key:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fresolve-spec-supersession.sh\" \"\u003Cbehavior-key>\"\n```\n\nFor each proof-matrix row whose expected behavior overlaps multiple specs:\n\n1. Run the resolver against the behavior key (e.g. heading text or\n acceptance-criterion fragment).\n2. If the resolver returns a spec path different from the row's\n `spec_reference`, the row is being validated against a superseded\n behavior. Re-derive the expected behavior from the resolver's winning\n spec and update the row's `spec_reference` accordingly.\n3. If the row's expected behavior no longer appears in the winning spec,\n mark the row `superseded` with a note pointing at the winning spec; do\n NOT classify it `FAIL`.\n\nThis rule applies symmetrically to control-intent ledger entries and\nlive-evidence checks: a control whose intent is only described by a\nsuperseded spec is not a regression.\n\n## Data lifecycle proof\n\nFor CRUD, stateful, or workflow apps, prove the data lifecycle:\n\n- create persists after refresh,\n- edit propagates to list\u002Fdetail\u002Fsearch\u002Fexport views,\n- delete\u002Fremove is reflected everywhere without ghost UI state,\n- failed writes roll back optimistic UI,\n- retries are idempotent or visibly safe,\n- browser back\u002Fforward and deep links preserve expected state,\n- concurrent or rapid repeated actions do not corrupt state.\n\nIf the app has persistence but lacks lifecycle evidence, keep the affected\nfeature `PARTIAL`.\n\n## Observability contract\n\nGenerated apps must expose enough safe diagnostics to debug failed QA and\ncanaries:\n\n- request correlation IDs across frontend\u002Fbackend where practical,\n- frontend error boundary logging,\n- backend route\u002Fworker timing,\n- health\u002Fstatus endpoints or probes,\n- user-safe actionable error messages,\n- logs that identify route\u002Fworker\u002Fcache\u002Fdatabase class without exposing\n secrets or PII.\n\nMissing observability does not automatically fail a pure UI feature, but it is a\nblocking gap for backend-backed workflows whose failures cannot otherwise be\ntriaged.\n\n## Flake quarantine rule\n\nDo not accept \"green after retry\" as reliable without classification. If a test\nuses retries, sleeps, widened timeouts, or repeated reruns to pass, classify the\nflake as one of:\n\n- product race,\n- selector fragility,\n- backend instability,\n- environment issue,\n- test oracle weakness.\n\nThen either fix it, quarantine it with a follow-up issue and owner, or keep the\naffected proof row `PARTIAL`.\n\n## Additional reliability surfaces\n\nKeep looking for reliability gaps beyond the obvious UI happy path:\n\n- route\u002Fscreen inventory: every spec screen and reachable route has coverage or\n a documented exclusion,\n- API contract replay: frontend requests match OpenAPI\u002Fschema\u002Fserver contracts\n when available,\n- auth and permission matrix: each role can and cannot perform the expected\n actions,\n- timezone, locale, browser, viewport, and device variance for date\u002Fformat\u002FUI\n sensitive features,\n- performance budgets for primary workflows,\n- destructive action safety: confirmation, undo\u002Frestore, scoped production\n protections, and backup\u002Frestore where relevant,\n- dead-code and generated-artifact cleanup after implementation,\n- dependency\u002Fsecurity scan for newly added packages or SDK use,\n- migration\u002Fbackward-compatibility proof for schema or persisted-data changes,\n- test oracle specificity: assertions name the domain result, not generic text\n or \"something changed.\"\n\n## Reliability exhaustion loop\n\nBefore finalizing, ask: \"What else could make this generated app unreliable,\nduplicated, or falsely green against the spec?\"\n\nRepeat until the next answer is only:\n\n- already covered by a proof artifact, test, canary, or follow-up issue,\n- impossible to verify from available safe environments and recorded as an\n operator blocker,\n- outside the accepted scope and filed as a separate spec issue,\n- lower value than the documented risk tolerance in `.autospec\u002Freliability.yml`.\n\nEach actionable answer must become a strengthened test, implementation fix,\nproof-artifact update, reliability-contract update, or follow-up issue.\n\n## Generated app reliability contract prompt\n\nBefore declaring a generated app reliable, create or validate\n`.autospec\u002Freliability.yml`:\n\n```text\nFor this app, define the reliability contract:\n\n1. Which user workflows are required live smokes?\n2. Which representative inputs and seed\u002Flive data prove each workflow?\n3. Which tests may mock APIs, and which workflows require no-mock deployed\u002Fdev\n execution?\n4. Which health probes distinguish app, API, queue, bridge, worker, cache,\n database, and external-service failures?\n5. Which backend failures require fallback behavior, and what visible state\n proves the fallback worked?\n6. Which production or unsafe URLs are forbidden during tests?\n7. Which false-green patterns are forbidden, such as DOM-only PASS, request-only\n PASS, mocked-only PASS, or screenshot-only PASS?\n\nRequired outcome:\n- If the contract is missing, draft it.\n- If the contract conflicts with the spec, mark the affected rows PARTIAL and\n file a spec\u002Fconfig follow-up.\n- If no deployed\u002Fdev environment exists, require an explicit contract entry\n explaining the blocker and exact setup action.\n```\n\n## Control intent ledger prompt\n\nThe UI audit must not rely on a vague list of \"controls covered.\" Build a\ncontrol intent ledger:\n\n```text\nFor every reachable control, record:\n\n- selector or stable locator\n- visible label and accessible name\n- control type\n- classification: functional, read_only, decorative, or unclassified\n- spec requirement served\n- expected request\u002Fstate\u002Fpersistence\u002Fresult effect\n- validation and error behavior\n- tests proving the effect\n- live no-mock evidence when required\n- follow-up issue or blocker if not fully proven\n\nRequired outcome:\n- Functional controls need request\u002Foutput\u002Fresult\u002Ffailure coverage.\n- Read-only and decorative controls need an explicit documented reason.\n- Any unclassified control makes the QA result PARTIAL or FAIL.\n```\n\n## Duplicate-code guardian prompt\n\nBefore accepting generated code or regenerated tests, challenge duplication:\n\n```text\nFor each new component, function, module, API client, validator, form helper,\nerror handler, backend wrapper, fixture, or test utility:\n\n1. Search the repo for existing helpers or patterns that already solve this.\n2. If a duplicate exists, reuse it or explain why it is insufficient.\n3. If the new code remains, identify its owning spec requirement and public\n contract.\n4. Block duplicate API clients, duplicate validators, duplicate form state\n logic, duplicate error banners, duplicate request wrappers, and duplicated\n test fixtures unless the issue\u002Fspec explicitly requires a fork.\n\nRequired outcome:\n- Duplication findings become implementation fixes or `DUPLICATE_CODE`\n follow-up issues with file references.\n```\n\n## Mutation and breakage proof prompt\n\nFor every critical user workflow, prove that the test would fail if the product\nwere broken:\n\n```text\nFor this workflow test, simulate or reason through one minimal break:\n\n1. Break request payload\u002Fquery propagation.\n2. Break the visible result rendering.\n3. Return a known backend failure such as `502`, `504`, timeout, empty data, or\n validation rejection.\n4. Disable the fallback route or error banner.\n5. Remove persistence or state update.\n\nRequired outcome:\n- At least one critical workflow per feature has mutation\u002Fbreakage evidence.\n- If a test still passes after the behavior is broken, strengthen the assertion\n before accepting the QA result.\n- Record the result in `.autospec\u002Fmutation-proof.json` or the QA report.\n```\n\n## Benchmark leak and overfit gate\n\nFor every test that consumes a public dataset, benchmark, leaderboard, or\nexternally-curated answer key (e.g., ClassyFire, ChEMBL, MassBank, MNIST,\nGLUE, SuperGLUE, ImageNet, BIG-bench, HELM, GSM8K, MMLU, fixtures derived\nfrom a named corpus), audit for benchmark leak and overfit-shaped assertions:\n\n```text\nFor each test fixture and assertion derived from a public benchmark or\nexternally-curated dataset:\n\n1. Identifier hard-coding — does the test pin specific benchmark IDs\n (InChIKeys, accession numbers, row hashes, sample indices, image filenames,\n prompt IDs) and assert exact downstream values?\n2. First-N slice — is the fixture the first N rows \u002F top-N records \u002F a fixed\n prefix of a known benchmark, rather than a randomized or rotated sample?\n3. Answer-key shape — do the assertions match the benchmark's published\n answer key (labels, class names, expected outputs) such that the system\n under test could pass by memorizing those rows?\n4. Distributional sibling — is there a randomized or property-based test\n covering the same code path on a fresh draw from the source distribution?\n5. Refresh path — can the fixture be regenerated on demand from the upstream\n source (API, query, seeded sampler), or is it frozen indefinitely?\n6. Training-on-test — is the same fixture also used to train, tune, select,\n or prompt-engineer the code under test? If yes, the fixture is leaked.\n\nRequired outcome:\n- Replace fixed slices with a seeded random sample drawn from the upstream\n source per run (or per release), and rotate the seed at a defined cadence.\n- Replace exact-value assertions on benchmark identifiers with property-based\n or invariant assertions that hold for any valid draw from the distribution.\n- Keep at most one tiny \"shape smoke\" test with hard-coded IDs, clearly named\n as a smoke test, never as the primary correctness signal.\n- A test that asserts exact benchmark answers without a randomized sibling is\n a PARTIAL finding. If the same fixture is also used as the training or\n selection signal for the code under test, it is FAIL (training-on-test\n leak).\n- Record each finding in the QA report under \"Benchmark Overfit and Test\n Leak\" with the test path, the leaked dataset, the failure mode (1-6\n above), and the required remediation.\n```\n\n## Outsourced implementation gate\n\nWhen the spec uses an implementation verb (classify, resolve, score, parse,\ntransform, extract, generate, rank, detect, segment, embed, …) and the diff\nor repo adds a runtime call to a third-party API\u002FSDK that performs that same\nverb, the LLM has outsourced the product to an external service instead of\nimplementing it. Audit every new or expanded external-service binding:\n\n```text\nFor each new HTTP client, SDK call, or service binding introduced to satisfy\na spec acceptance criterion:\n\n1. Verb alignment — does the spec's verb describe an action the product is\n supposed to PERFORM (build, classify, resolve, score, parse, transform,\n extract, generate, detect, segment, embed) or merely INTEGRATE WITH\n (fetch from, sync, import, mirror, publish to)? Implementation verbs\n satisfied by remote-call shortcuts are outsourced implementations.\n2. Benchmark \u002F comparator collision — does the third-party service's name\n appear elsewhere in `docs\u002Fspecs\u002F**`, README, or QA reports as a\n \"benchmark\", \"comparator\", \"ground truth\", or \"baseline\"? Using the\n benchmark at runtime contaminates evaluation and frequently violates\n ToS.\n3. Missing local algorithm — does the spec or referenced paper describe an\n algorithm (rules, features, model, scoring formula) that the repo does\n NOT implement, while a remote call answers the same question?\n4. Cached external payloads — is there a `cache\u002F`, `fixtures\u002F`, or\n `generated\u002F` directory holding downloaded service responses that the\n runtime depends on, with no in-repo computation able to reproduce them?\n (Does NOT apply when the spec's verb is itself an integration verb\n from signal 1's integration list — e.g., a project whose stated job is\n to mirror\u002Fimport\u002Fsync that external dataset.)\n5. License and provenance — is there a provenance record (URL, fetch\n timestamp, ToS link, redistribution scope) for every cached external\n payload? Missing provenance on cached third-party data is a release\n blocker even when the runtime call is itself legitimate.\n6. Reimplementation directive — does the spec or product mission state\n that the project is supposed to REPLACE or REIMPLEMENT the named\n service? If yes, runtime use of that service is a definitional bug.\n\nRequired outcome:\n- For each finding, name the spec acceptance criterion, the offending\n client\u002FURL\u002FSDK call, and the signals (1-6) that matched.\n- Remediation: replace the remote call with an in-repo implementation that\n matches the spec's described algorithm. The external service MUST be\n either (a) removed entirely, or (b) gated behind an off-by-default\n feature flag scoped to evaluation\u002Fbenchmark comparison only, with cached\n payloads carrying explicit redistribution permission. No other\n configuration is acceptable for release PASS.\n- A finding matching signal 1 (implementation verb satisfied by remote\n call), signal 2 (benchmark\u002Fcomparator collision), or signal 6\n (reimplementation directive) is FAIL — these are product-identity\n violations and cannot be release-deferred.\n- Signals 3, 4, or 5 alone default to PARTIAL until the in-repo\n implementation lands. Signal 3 paired with signal 1 escalates to FAIL.\n- Record each finding in the QA report under \"Outsourced Implementation\"\n and in `.autospec\u002Fqa-verdict.json` with category\n `outsourced_implementation`, the matched signal numbers in the summary,\n and the remediation status.\n```\n\n## Exhaustiveness flags\n\nThe orchestrator soft-discipline sections above (the reliability exhaustion\nloop, the 20-question Critical self-questioning checkpoint, \"no-mock minimum\ncoverage\", etc.) drive depth of coverage by prose. When clusters skip a step\nthe report can still say PASS while a production bug ships. The operator MAY\ninvoke `\u002Fautospec-qa` with one or more explicit machine-checkable flags that\nconvert that prose into a hard gate. With no flag, behavior is unchanged.\n\n- `--every-spec-row` — fail the run with `code_health:incomplete_traceability`\n if any spec acceptance criterion lacks a non-`NOT_TESTED` row in\n `.autospec\u002Fproof-matrix.json`. Forces the orchestrator to extract every\n AC, not just the ones it judged \"important\".\n- `--mutation-each` — require a mutation\u002Fbreakage entry in\n `.autospec\u002Fmutation-proof.json` for every workflow listed in the spec,\n not just \"critical\" ones. Missing entries emit\n `code_health:incomplete_mutation_proof`.\n- `--no-mock-each` — require a no-mock deployed\u002Fdev smoke path in\n `.autospec\u002Fcanary-results.json` for every backend-backed feature.\n Exceptions must be declared explicitly under `no_mock_exempt` in\n `.autospec\u002Freliability.yml`. Missing entries emit\n `code_health:incomplete_no_mock_coverage`.\n- `--exhaustive` — turns the three above on.\n\nEnforcement runs after the existing verdict computation but BEFORE writing\n`.autospec\u002Fqa-verdict.json` as final. The helper appends one\n`release_blocking: true` finding per gap and demotes the verdict from\nPASS to PARTIAL (FAIL is preserved). The list of flags actually requested\nis recorded under `requested_flags` on the verdict so downstream skills\n(notably `\u002Fautospec-release`) can see what was enforced. Both the\norchestrator prompt and the regeneration loop call this helper:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-exhaustiveness-check.sh\" \\\n --exhaustive \\\n --verdict .autospec\u002Fqa-verdict.json \\\n --proof-matrix .autospec\u002Fproof-matrix.json \\\n --mutation-proof .autospec\u002Fmutation-proof.json \\\n --canary .autospec\u002Fcanary-results.json \\\n --reliability .autospec\u002Freliability.yml \\\n --spec docs\u002Fspecs\u002F\u003Cfeature>.md\n```\n\nExit 0 means every requested gate passed. Exit 1 means at least one gate\nfailed and the verdict + findings have been updated atomically. Backwards-\ncompatible: invoking with no flag is a no-op.\n\n## Self-healing loop\n\n`\u002Fautospec-qa` is self-healing by default. After discovery, the orchestrator\nenters a discover → file → fix → re-QA loop and runs until convergence or a\nguardrail trips. The loop is driven by `qa-heal-loop.sh`, which calls\n`qa-finding-to-issue.sh` once per release-blocking finding to file an\n`auto-implement,autospec:v2-flow` GitHub issue, then dispatches `\u002Fautospec-run`\nto drain the queue before re-running QA.\n\nBuilds on the verify-first filter (#647 \u002F PR #650): the heal loop relies on\nthe filter to reject unverified findings before they become issues, otherwise\nround 1 would file noise. Builds on the production-incident registry\n(#659 \u002F PR #661): findings tagged\n`code_health:production_incident_regression_missing` follow the same heal\npath. Companion to autonomous mode (#662): when\n`~\u002F.autospec\u002Fautonomous.flag` is set, heal mode is implicit.\n\nLoop semantics:\n\n1. Round N: run `\u002Fautospec-qa`, write `.autospec\u002Fqa-verdict.json` as today.\n2. For each finding with `release_blocking: true` and\n `status ∈ {FAIL, PARTIAL, NOT_TESTED}`:\n - Translate via `qa-finding-to-issue.sh` into a structured issue\n body (category + summary + evidence + reproduction + remediation\n directive verbatim from the relevant `code_health:*` directive map).\n - File one `auto-implement,autospec:v2-flow` issue. Existing dedup:\n skip if an open issue with the same `(category, file, summary_hash)`\n already exists.\n3. Launch `\u002Fautospec-run` (single-agent Phase 4) to drain the new + existing\n queue. One PR per issue per existing pipeline semantics.\n4. After the run drains (`batch-done.json: ALL_DONE`), re-enter step 1.\n\nTermination — loop exits when ANY of:\n\n- **Convergence** — round N produces zero findings with\n `release_blocking: true`. (Non-blocking findings are filed once but do\n NOT keep the loop alive.) This is the canonical success state.\n- **Oscillation detected** — round N+1's release-blocking finding set,\n hashed by `(category, file, summary)`, equals round N's. The auto-fix\n is going nowhere; the loop exits with `oscillation_detected` and\n surfaces the persistent findings for operator review.\n- **Round cap** — `AUTOSPEC_HEAL_MAX_ROUNDS` reached (default 5).\n- **Budget cap** — tokens used > `AUTOSPEC_HEAL_TOKEN_CAP` (default\n 1.5M) or wall time > `AUTOSPEC_HEAL_TIME_CAP` (default 4h).\n- **Verify-first violation persists** — if the post-cluster verify-first\n filter keeps dropping the same findings as `verified_dropped` round\n after round, those findings are likely flaky probes; the loop exits\n and asks the operator to triage.\n\nAt loop end, the orchestrator prints a Markdown table to the operator and\nwrites `.autospec\u002Fheal-summary.md` for the audit trail and for\n`\u002Fautospec-release` to consume as a release-readiness signal:\n\n```\n## \u002Fautospec-qa heal loop summary\n\n| Round | Findings | Issues filed | PRs merged | Time | Status |\n|-------|---------:|-------------:|-----------:|------|-------------------------|\n| 1 | 7 | 7 | 6 | 12m | 1 finding persisted |\n| 2 | 1 | 0 | 0 | 4m | oscillation_detected |\n\nFinal verdict: PARTIAL (1 persistent finding)\n```\n\nInvocation:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-heal-loop.sh\" \\\n --verdict .autospec\u002Fqa-verdict.json \\\n --summary .autospec\u002Fheal-summary.md\n```\n\nSafety guardrails (NOT bypassed by heal mode) — inherit all existing\nautonomy\u002Frelease guardrails:\n\n- Destructive remote actions surface for confirmation (handled by\n `autospec-autonomy-gate.sh`).\n- Per-PR merge still goes through the rebase-and-retest gate.\n- `~\u002F.autospec\u002Fno-heal.flag` exists → heal globally disabled (operator\n escape hatch for runaway loops).\n- `~\u002F.autospec\u002Fstop.flag` (graceful \u002F immediate) terminates the loop at\n the next round boundary.\n\n## --no-heal opt-out\n\nThe heal loop runs by default (issue #711 locks the default-on contract;\nissue #666 introduced it). Four opt-outs revert to discovery-only\nbehavior; all four are equivalent and only post-discovery behavior\ndiffers:\n\n1. `--no-heal` flag.\n2. `--single-pass` flag (alias).\n3. `~\u002F.autospec\u002Fqa-no-heal.flag` operator preference.\n4. `~\u002F.autospec\u002Fno-heal.flag` legacy operator preference (still honored).\n\nWhen any of the four is present, `\u002Fautospec-qa` writes\n`.autospec\u002Fqa-verdict.json` and exits without filing issues or\ndispatching `\u002Fautospec-run`. Triggers are identical for both modes.\nBackwards compatibility: any caller that relied on `\u002Fautospec-qa`\nexiting after discovery must pass `--no-heal`. The\n`.autospec\u002Fqa-verdict.json` schema is unchanged. Existing\n`\u002Fautospec-release` and `\u002Fautospec-sweep` integrations see the post-heal\nverdict, not the pre-heal one — this is the intended improvement.\n\n## Shared loop driver (issue #711)\n\n`qa-heal-loop.sh` adopts the shared loop driver\n`lib\u002Fautospec-loop.sh` (issue #708 \u002F PR #712) for unified\ntermination naming. The four loop-enabled skills — `\u002Fautospec --loop`,\n`\u002Fautospec-refine --continue`, `\u002Fautospec-continue --loop`, and\n`\u002Fautospec-qa` (heal default-on) — share these termination conditions:\n\n- `convergence_clean` — zero release-blocking findings (heal alias:\n `convergence`).\n- `oscillation_detected` — finding-set hash repeats round-over-round.\n- `round_cap_reached` — `AUTOSPEC_HEAL_MAX_ROUNDS` reached.\n- `evidence_based_stop` — `stop_marker` \u002F `STOP:` field in the QA\n verdict.\n- `operator_stop` — `~\u002F.autospec\u002Fstop.flag` or\n `~\u002F.autospec\u002Fqa-heal-stop.flag` (heal alias: `stopped`).\n- `budget_cap_reached` — token or wall-time cap exceeded.\n\nLoop end produces `.autospec\u002Fqa-heal-summary.md` (mirrored from the\nlegacy `.autospec\u002Fheal-summary.md` path) with the same Markdown table\nshape as `.autospec\u002Floop-summary.md` (refine\u002Fcontinue\u002Fautospec --loop)\nso `\u002Fautospec-release` and downstream consumers see structurally\nidentical summaries across all four loop-enabled skills.\n\n## Production incident regression check\n\nWhen QA passes but production breaks, the same bug class tends to leak again the\nnext cycle because nothing in the QA pipeline learns from the incident. The\nregistry `.autospec\u002Fproduction-incidents.json` records every production incident\nand the regression test that proves it cannot reoccur silently. `\u002Fautospec-qa`\nreads this registry on every run and asserts, for each `active` incident:\n\n1. A named `regression_test` file exists.\n2. That test actually runs.\n3. The test is non-trivially assertive (no `expect(true).toBe(true)` or empty\n stub).\n4. The test FAILS when the incident's recorded `mutation` is applied to the\n implementation — proving the test would catch a regression rather than\n passing for unrelated reasons.\n\nMissing any of these four checks emits a finding under category\n`code_health:production_incident_regression_missing` with\n`release_blocking: true` in `.autospec\u002Fqa-verdict.json`.\n\nRegistry schema (one JSON array, one entry per incident):\n\n```json\n[\n {\n \"id\": \"INC-2026-05-28-checkout-double-charge\",\n \"occurred_at\": \"2026-05-28T03:14:00Z\",\n \"failure_mode\": \"concurrent submit creates duplicate Stripe charge\",\n \"feature\": \"checkout\u002Fpayment\",\n \"spec_anchor\": \"docs\u002Fspecs\u002Fcheckout.md#payment\",\n \"regression_test\": \"tests\u002Fregression\u002Fincident-2026-05-28-double-charge.test.ts\",\n \"mutation\": \"remove the `submitting` guard on the Pay button; test must FAIL\",\n \"added_by\": \"\u003Coperator handle>\",\n \"status\": \"active\"\n }\n]\n```\n\n`status` ∈ `active | superseded | wont_test`. Only `active` is enforced.\n`superseded` means the underlying behavior was redesigned out of existence and\nmust cite the replacement spec section. `wont_test` requires explicit\njustification (e.g., \"infra-level only, no test can reach it\") and emits a\nwarning, never a release blocker.\n\nNever silently delete an incident entry. Operators move incidents to\n`superseded` or `wont_test` with a citation\u002Fjustification so the historical\nrecord of why a regression test was added stays auditable. The orchestrator\nruns the helper after the existing verdict computation, similar to other\npost-verdict gates:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-incident-check.sh\" \\\n --registry .autospec\u002Fproduction-incidents.json \\\n --verdict .autospec\u002Fqa-verdict.json\n```\n\nExit 0 means every `active` incident is covered. Exit 1 means at least one\nactive incident is missing coverage and a release-blocking finding has been\nappended to the verdict. The helper validates the registry against\n`schemas\u002Fautospec-production-incidents.schema.json` and writes findings\natomically.\n\n## Post-merge deployed canary prompt\n\nWhen a deployed\u002Fdev URL exists, define the post-merge canary before release:\n\n```text\nFor this feature, list the smallest deployed\u002Fdev workflow set that must run\nafter merge or deploy:\n\n- route or screen\n- representative input\n- expected live API\u002Fbackend path\n- expected visible domain result\n- failure banners that must not appear\n- health probes to run if the canary fails\n- issue label or escalation path for a failed canary\n\nRequired outcome:\n- A missing canary for a backend-backed feature is PARTIAL unless the reliability\n contract explicitly exempts it.\n- A failed canary creates a regression issue with logs, route classification,\n and live evidence.\n```\n\n## No-mock minimum coverage prompt\n\nMocked tests are not enough for backend-backed features:\n\n```text\nFor every spec feature that depends on backend behavior, identify the minimum\nno-mock path that proves real integration:\n\n- one representative happy path,\n- one known fragile backend path or fallback path,\n- one visible success result,\n- one absence-of-generic-failure assertion.\n\nRequired outcome:\n- If no no-mock path exists, update `.autospec\u002Freliability.yml` with the blocker\n and setup action.\n- If the app has only mocked coverage, do not mark the backend-backed feature\n PASS.\n```\n\n## New code intent gate\n\nEvery new component, module, function, endpoint, worker, hook, or test helper\nmust answer why it exists:\n\n```text\nFor this new code unit:\n\n1. Which spec requirement or issue acceptance criterion owns it?\n2. Why is an existing helper, component, service, or test utility not enough?\n3. What is the smallest public contract this unit exposes?\n4. What automated test and, when applicable, live workflow proves it?\n5. What would break if this unit were wrong?\n\nRequired outcome:\n- If there is no spec-linked reason, remove the code or file a scope\u002Fspec issue.\n- If there is an existing helper, prefer reuse over a new abstraction.\n```\n\n## Legacy removal and spec cleanup gate\n\nWhen the current spec, operator direction, or accepted architecture deprecates a\nroute, cache, bucket, storage backend, worker, feature flag, config key, UI path,\nor data source, autospec must remove the legacy surface and its spec\u002Fdocs\nreferences instead of making the deprecated path work again.\n\n```text\nFor each legacy or deprecated surface:\n\n1. What replaced it, and where is that replacement specified?\n2. Which code paths, feature flags, env vars, infrastructure resources, docs,\n tests, fixtures, runbooks, and specs still reference the legacy surface?\n3. Did any smoke\u002Ftest\u002Frepair step try to make the app pass by repopulating,\n restarting, or relying on the deprecated surface?\n4. What data migration, cleanup, or compatibility window is required before\n removal?\n5. Which tests prove the replacement path works and the legacy path is no longer\n used?\n6. Which specs or docs were updated to remove or mark the legacy behavior as\n intentionally unsupported?\n\nRequired outcome:\n- Do not populate deprecated caches, buckets, queues, indexes, or fallback stores\n just to make a live smoke pass.\n- If a deployed environment still depends on a deprecated surface, mark the row\n PARTIAL\u002FFAIL and file an implementation\u002Finfrastructure cleanup issue.\n- Remove stale spec\u002Fdocs references in the same change when implementation\n removes legacy behavior.\n- If compatibility must remain temporarily, document the sunset condition,\n owner, and follow-up issue; tests must still prove the new canonical path.\n```\n\n## Brute-force string heuristics sweep\n\nSweep already-merged code for the LLM-tier RULE_IDs `STRING_MATCH_DOMAIN_LOGIC`\nand `REPEATED_STRUCTURE_AS_CODE` (AGENTS.md `## Implementation-quality contract`).\nThis catches rot that pre-dates the PR-time guardian — substring-on-name\nclassifiers and ≥5-branch ladders that ship as a wall of `if`\u002F`elif`\u002F`switch`\ninstead of a table + dispatcher.\n\nSupported languages: Python, JavaScript\u002FTypeScript, Go, Java, Scala, Rust.\n\n```bash\n# Run from repo root. Emits findings into .autospec\u002Fqa-verdict.json under\n# the category `code_health:brute_force_string_heuristics` and files one\n# auto-implement issue per offender.\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-brute-force-sweep.sh\"\n```\n\nThe sweep:\n\n1. Walks every `*.py`, `*.js`, `*.ts`, `*.jsx`, `*.tsx`, `*.go`, `*.java`,\n `*.scala`, `*.rs` file outside `node_modules`, `.git`, and `dist`.\n2. For `STRING_MATCH_DOMAIN_LOGIC`: counts substring-style checks\n (`.contains(...)`, `.includes(...)`, `in name`, `strings.Contains`,\n etc.) and confirms the file imports a proper-representation library for\n its language — Python `rdkit`\u002F`ast`\u002F`urllib.parse`\u002F`datetime`\u002F\n `ipaddress`\u002F`lxml`\u002F`jsonschema`; JS\u002FTS `URL`\u002F`Date`\u002F`@babel\u002Fparser`\u002F\n `acorn`\u002F`ts-morph`\u002F`zod`\u002F`ajv`\u002F`joi`; Go `net\u002Furl`\u002F`time`\u002F`go\u002Fast`\u002F\n `net.ParseIP`\u002F`encoding\u002Fjson`; Java `java.net.URI`\u002F`java.time`\u002F\n `JavaParser`\u002F`com.github.javaparser`\u002F`javax.validation`; Scala\n `java.net.URI`\u002F`java.time`\u002F`scalameta`\u002Frefined\u002Fcirce; Rust `url::Url`\u002F\n `chrono`\u002F`time`\u002F`syn`\u002F`std::net::IpAddr`\u002F`serde`.\n3. For `REPEATED_STRUCTURE_AS_CODE`: counts repeated branch-shaped lines\n (`if`\u002F`elif`\u002F`case`\u002F`match` arms) and flags any file with ≥5.\n4. Writes one finding line per offender to `.autospec\u002Fqa-verdict.json`\n under category `code_health:brute_force_string_heuristics`, carrying\n `rule_id`, `language`, `file`, `function`, `line`.\n5. Files one `auto-implement,autospec:v2-flow` GitHub issue per offender\n via `gh issue create`. Issue body cites the file, function\u002Fmethod, line,\n and the verbatim RULE_ID directive from AGENTS.md so the implementer\n retry loop has the corrective instruction. Where the offending file has\n no proper-representation library imported, the issue notes\n \"no proper-rep library imported — investigate first\" so the implementer\n does not blindly add a dependency.\n\nErrors in the sweep MUST NOT block the QA verdict; emit findings and\ncontinue. End-to-end regression: after the QA-filed rewrite issues run\nthrough `\u002Fautospec-run`, the offending files no longer trip either\nRULE_ID in the PR-time guardian.\n\n## Bug-class sibling sweep (issue #737)\n\nWhen `.autospec\u002Fqa-verdict.json` carries a `release_blocking: true`\nfinding whose `category` ends in `:bug` (or otherwise matches a\nfingerprintable shape), run `qa-bug-class-sweep.sh` to fan out\nacross the repo for sibling instances of the same pattern class. Goal:\nconsistency by construction — the implementer fixes every matching\ninstance in **one PR**, not N PRs.\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-bug-class-sweep.sh\" \\\n --verdict .autospec\u002Fqa-verdict.json --repo-dir .\n```\n\nThe sweep:\n\n1. Computes a deterministic **pattern fingerprint** over the offending\n line + ±5 context lines (literal-stripped: strings → `\"\"`, numbers →\n `N`). The fingerprint and its sha256 (`pattern_fingerprint`,\n `fingerprint_hash`) are stored on the PARENT finding **at\n finding-time**, not recomputed — this gives pattern drift safety so\n siblings remain resolvable even after the parent line is rewritten.\n2. Runs `git grep -nE \u003Cfingerprint>` over the repo, excluding\n `node_modules\u002F`, `.git\u002F`, and `vendor\u002F`, plus the parent's own\n `file:line`.\n3. For each match, computes a **confidence** score\n `(presence + density_bonus) * specificity` where specificity scales\n with fingerprint length (longer anchors → higher confidence). Matches\n with `confidence >= AUTOSPEC_QA_BUG_CLASS_MIN_CONFIDENCE` (default\n `0.7`) are appended to `findings[]` with\n `category: code_health:bug_class_sibling`, `parent_fingerprint`,\n `confidence`, `file`, `line`. Below-threshold matches land in\n `.autospec\u002Fqa-bug-class-flagged.json` (operator review surface, NOT\n filed as issues).\n4. Applies the verify-first filter\n (`qa-verify-finding.sh --category missing_function`) to every\n candidate sibling. If the bug is already fixed at HEAD for an\n instance, that sibling is dropped silently.\n5. All verdict mutations are atomic (`.tmp` + `mv`) so partial runs\n cannot corrupt the verdict.\n\nPer-class issue filing: `qa-heal-loop.sh` groups findings by\n`parent_fingerprint` when present and files **one `auto-implement` issue\nper pattern class** carrying every instance's `file:line`. Findings\nwithout a fingerprint stay per-finding as before. This is the key\ncontract that turns bug-class detection into a single coordinated fix.\n\n## Verify-first discipline\n\nBefore any cluster emits a finding to `.autospec\u002Fqa-verdict.json`, the cluster\nMUST verify that the symptom still reproduces at current HEAD. This eliminates\nthe dominant false-positive class observed in production: clusters re-flagging\ngaps that landed in a recent PR. Run the shared probe per candidate finding:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-verify-finding.sh\" \\\n --category \u003Cmissing_function|missing_import|failing_test|spec_mismatch|regression> \\\n [--symbol \u003Cname>] [--file \u003Cpath>] [--test-cmd \u003Ccmd>] \\\n [--spec \u003Cpath>] [--impl \u003Cpath>] [--claim \u003Ctext>] [--commit \u003Csha>]\n```\n\nExit 0 means the finding still reproduces (KEEP and emit). Exit 1 means the\nsymptom no longer reproduces (DROP and append to `verified_dropped[]` in the\nQA report). When ingesting prior-cycle findings from a previous\n`.autospec\u002Fqa-verdict.json`, run the same probe; drops go into\n`stale_dropped[]` rather than `verified_dropped[]`.\n\nCluster cross-talk dedup: the QA orchestrator maintains\n`.autospec\u002Fqa-cluster-coverage.json` via the shared coverage helper. Each\ncluster MUST attempt to claim the `(file, spec_section, rule_id)` tuple it is\nabout to scan; a second cluster racing on the same tuple receives exit 1\n(\"already claimed\") and logs the skip as `cluster_skip_dedup`:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-cluster-coverage.sh\" \\\n claim --cluster \u003Cid> --file \u003Cpath> --section \u003Csection> --rule \u003Crule_id>\n```\n\nThe final QA report MUST surface four explicit count fields so the operator\ncan see what the discipline filtered: `findings_emitted`, `verified_dropped`,\n`stale_dropped`, `cluster_skip_dedup`.\n\nAfter cluster fan-out completes, the QA orchestrator MUST run\n`qa-finding-filter.sh` against the merged\n`.autospec\u002Fqa-verdict.json` before any release-skill (e.g.,\n`\u002Fautospec-release`) consumes it. The filter partitions findings into\nverified, stale (re-probed and either refreshed or dropped to\n`verified_dropped[]`), and unverified. Under `AUTOSPEC_QA_STRICT=1`\n(the CI default), any finding lacking `verified_at` causes the QA run\nto FAIL with status `code_health:verify_first_violation`; under\n`AUTOSPEC_QA_STRICT=0` unverified findings are routed to\n`unverified_warnings[]` for operator triage. Cluster agents MUST emit\nfindings via `qa-verify-finding.sh --emit-record \u003Cpath>` so the\nrequired `verified_at`, `verified_by`, and `verify_category` fields are\npopulated by the probe rather than hand-constructed.\n\n## Cluster sizing\n\nThe QA orchestrator's cluster fan-out is a knob, not a constant. When the\nprior QA run dropped ≥30% of candidate findings on verification, prefer **3\nverify-first clusters** over **7 blind clusters** for the next run. A drop\nrate >50% means clusters are re-litigating the same closed gaps rather than\nexploring new surface; shrink the fan-out and let each cluster do deeper\nverification work. This is prose guidance to the orchestrator — no enforcement\nscript — but the rule is non-negotiable for runs whose prior-cycle drop rate\nexceeded the threshold.\n\n## Dogfood detectors driver\n\nWhen QA runs against the autospec repo itself, use `dogfood-detectors.sh` as the authoritative aggregated sweep rather than invoking individual `scripts\u002Fqa-*-sweep.sh` directly. The driver enforces an allowlist of intentional findings and fails on regression.\n\n## Critical self-questioning checkpoint\n\nBefore finalizing the QA report or accepting regenerated tests, stop and answer\nthese questions in the working notes:\n\n1. What could still pass in the current mocked tests while failing for a real\n user on the deployed\u002Fdev environment?\n2. Which user-visible outcome proves the feature worked, independent of DOM\n wiring or request dispatch?\n3. Which backend route, service, queue, bridge, cache, or external dependency am\n I assuming is healthy?\n4. If that dependency fails, is there a tested fallback route or a clear\n actionable user state?\n5. Which button, dropdown, select, text box, validation rule, or error state did\n I not touch because it was inconvenient, slow, or required setup?\n6. Does the test prove the intended domain result, or only that a generic panel\n changed?\n7. What is the single highest-risk missing test I can add now?\n8. Did I search safe deployment\u002Fconfig surfaces deeply enough to distinguish\n missing credentials from stopped infrastructure or a route-specific worker\n failure?\n9. Did I emit proof artifacts that connect the spec, implementation, tests,\n live evidence, and remaining blockers?\n10. Did I challenge duplicated code and require a spec-linked reason for every\n new code unit?\n11. Did I prove at least one critical workflow test fails when the workflow is\n intentionally broken?\n12. Are the proof artifacts fresh for the current commit, spec hash, app URL,\n environment, and test command?\n13. Does every PASS have evidence provenance a reviewer can inspect?\n14. Did browser console and network inspection reveal any unexpected errors?\n15. Did I resolve or file spec contradictions before treating behavior as done?\n16. For stateful features, did I prove the data lifecycle across create, refresh,\n edit, delete, rollback, and navigation?\n17. Is there enough observability to debug a failed canary without exposing\n secrets or PII?\n18. Did I classify every retry, sleep, timeout increase, or flaky rerun instead\n of accepting green-after-retry?\n19. What else could make this generated app unreliable, duplicated, or falsely\n green against the spec?\n20. Did I remove deprecated code paths and stale spec\u002Fdocs references instead of\n reviving a legacy cache, bucket, route, worker, or fallback to make QA pass?\n\nIf any answer identifies a material gap, add the narrowest test for it or file a\nfollow-up issue with reproduction steps. Do not silently leave it as an\nunstated risk.\n\n## Inputs\n\nCollect or infer:\n\n- Spec path or URL.\n- App URL or local run command.\n- Repository path.\n- Test credentials and seed data, if needed.\n- Relevant PR\u002Fissue numbers.\n\nIf the app cannot be run and no URL is available, continue with static\u002Ftest\naudit only, but mark all runtime UI checks `NOT TESTED` with the exact blocker.\n\n## QA prompt\n\nUse this prompt as the audit driver:\n\n```text\nYou are a senior QA engineer, product tester, and spec-compliance auditor.\n\nYour job is to test this application completely from every meaningful scope and\ndirection, and to verify that every feature specified in the spec actually works\nin the running app.\n\nInputs:\n- Spec: \u003Cpaste or link the product\u002Fspec document>\n- App URL or local run command: \u003CURL or command>\n- Repository path, if available: \u003Cpath>\n- Test credentials\u002Fdata, if available: \u003Ccredentials\u002Fdata>\n\nMission:\nCreate and execute a complete verification pass that proves whether the\nimplemented app matches the spec. Do not only inspect code. Run the app and\ninteract with it like a real user. Treat the spec as the source of truth.\n\nRequired testing scope:\n\n1. Spec Traceability\n- Extract every feature, requirement, acceptance criterion, user flow,\n validation rule, permission rule, and edge case from the spec.\n- Build a traceability matrix with requirement, expected behavior, test\n performed, PASS\u002FFAIL\u002FPARTIAL\u002FNOT TESTED result, evidence, and notes.\n\n2. Functional Testing\nTest every user-facing feature end to end: buttons, links, text inputs,\ntextareas, checkboxes, radio buttons, selects, dropdowns, multi-selects, search\nfields, filters, sorting, pagination, tabs, modals, forms, uploads\u002Fdownloads,\nnavigation, save\u002Fedit\u002Fdelete flows, auth\u002Flogin\u002Flogout, and empty\u002Floading\u002F\nsuccess\u002Ferror\u002Fdisabled states.\n\nFor every workflow button or dropdown-backed action, do not stop at clickability\nor request dispatch. Verify the selected values change the real request\npayload\u002Fquery, run a mocked happy path, run a no-mock deployed\u002Fdev smoke path\nwith representative input, assert no live-failure banner appears, and assert a\nreal domain result is visible.\n\nFor every user input element, run the User Input Intent Prompt: identify what\nthe control is for, why it exists, how it should be used, what request\u002Fstate\u002F\nvisible result it should affect, how invalid or rejected input behaves, whether\nit is intentionally decorative\u002Fread-only, and whether running-app evidence proves\nit was implemented and tested correctly.\n\nWhen live backend smoke is blocked by config, credentials, bridge\u002Fqueue errors,\ntimeouts, or stopped services, run the Live Backend Blocker Triage Prompt before\ndeclaring `NOT TESTED`. Search safe config surfaces, do not print secret values,\nclean up temporary credential material, separate passed live paths from failing\nroutes, and classify whether the blocker is credentials, infrastructure health,\nroute mental model, or a route-specific worker\u002Fhandler failure.\n\nCreate or draft the proof artifacts: `.autospec\u002Fproof-matrix.json`,\n`.autospec\u002Freliability.yml`, `.autospec\u002Fcontrol-intent-ledger.json`,\n`.autospec\u002Fmutation-proof.json`, and `.autospec\u002Fcanary-results.json` when a\ndeployed\u002Fdev canary exists. Use them to prevent false PASS results: unclassified\ncontrols, missing backend no-mock coverage, missing mutation proof, duplicated\ncode, or missing code intent keep the result PARTIAL or FAIL until resolved.\nValidate artifacts against their schemas when possible, reject stale artifacts,\nrequire evidence provenance for every PASS, fail unexpected console\u002Fnetwork\nerrors, detect spec contradictions, prove data lifecycle for stateful features,\nrequire observability for backend-backed workflows, classify flakes, and run the\nReliability Exhaustion Loop until all actionable reliability ideas are handled\nor explicitly filed. Run the Legacy Removal and Spec Cleanup Gate whenever a\nworkflow touches a deprecated route, cache, bucket, storage backend, worker,\nfeature flag, config key, UI path, or data source.\n\n3. Form and Validation Testing\nFor every form\u002Finput test valid input, empty input, invalid input, boundary\nvalues, very long text, special characters, whitespace-only values, duplicates,\nrequired-field behavior, error-message clarity, recovery after correction,\nkeyboard submission, disabled submit behavior, and server-side validation.\n\n4. UI and UX Behavior\nVerify text readability, labels, discoverability, visible state changes,\nloading\u002Ferror\u002Fsuccess states, desktop\u002Ftablet\u002Fmobile layouts, and absence of\noverlapping or clipped content.\n\n5. Accessibility\nCheck keyboard-only navigation, focus order, visible focus indicators, input\nlabels, ARIA where needed, screen-reader names for icon buttons, color contrast,\nEscape behavior, and Enter\u002FSpace behavior.\n\n6. Data and State Testing\nVerify persistence after refresh, unsaved-change handling, optimistic update\nreconciliation, delete\u002Fedit propagation, filter\u002Fsearch\u002Fsort state, browser\nback\u002Fforward behavior, and deep links.\n\n7. Negative and Edge Cases\nTest API failure, slow responses, empty datasets, large datasets, unauthorized\naccess, expired sessions, invalid routes, concurrent edits, repeated rapid\nclicks, and refresh during in-progress actions.\n\n8. Backend\u002FAPI Integration\nWhen a backend exists, verify frontend requests match API contracts, API errors\nare handled correctly, storage reflects create\u002Fupdate\u002Fdelete behavior, and\npermissions\u002Fvalidation are enforced server-side.\n\nInclude regression coverage for deployed backend failures such as `502` bridge,\nproxy, queue, or cache misses. If a backend route is known fragile, the UI must\neither recover through a documented fallback route or show a clear actionable\nstate. Mocked endpoint success is not sufficient evidence.\n\n9. Regression and Cross-Feature Testing\nCombine flows: create then search\u002Ffilter\u002Fsort, edit then verify list\u002Fdetail\nviews, delete then verify navigation\u002Fempty states, change settings then verify\ndependent screens, and complete full user journeys.\n\n10. Automated Test Recommendations\nIdentify missing unit, integration, component, E2E, accessibility, and API\ncontract tests. For each missing test, state exactly what it should assert.\n\n11. Reliability and Maintainability Proof\nValidate the reliability contract, proof matrix, control intent ledger,\nduplicate-code guardian findings, mutation\u002Fbreakage proof, post-merge canary,\nno-mock minimum coverage, and new-code intent gate. Treat these as required\nspec-compliance evidence, not optional cleanup.\n\n12. Freshness, Provenance, and Runtime Error Testing\nValidate artifact freshness against the current commit\u002Fspec\u002Fenvironment, require\nreviewable evidence provenance for every PASS, fail unexpected console\u002Fnetwork\nerrors, classify retries\u002Fflakes, and record stale or unverifiable artifacts as\nPARTIAL.\n\n13. Spec, Data, Observability, and Exhaustion Testing\nDetect spec contradictions, prove create\u002Fedit\u002Fdelete\u002Frefresh\u002Frollback\u002Fnavigation\nlifecycles for stateful features, verify observability for backend-backed\nworkflows, and run the Reliability Exhaustion Loop until no new actionable\nquality ideas remain.\n\n14. Legacy Removal and Spec Cleanup\nIdentify deprecated routes, caches, buckets, fallback stores, workers, config\nkeys, UI paths, and data sources. Verify the canonical replacement works, the\nlegacy path is not repopulated or relied on, stale specs\u002Fdocs\u002Ftests are removed\nor marked unsupported, and any temporary compatibility has a sunset issue.\n\nExecution rules:\n- Do not assume a feature works because code appears to exist.\n- Do not mark PASS without concrete evidence.\n- Mark untestable items NOT TESTED and explain the blocker.\n- Mark spec mismatches FAIL even if the implementation seems reasonable.\n- Mark ambiguous spec items AMBIGUOUS and propose expected behavior.\n- Capture screenshots, logs, console errors, network failures, or command output\n where useful.\n- Continue until every spec item has a status.\n\nFinal report:\n# QA Verification Report\n## Summary\n- Overall result: PASS \u002F FAIL \u002F PARTIAL\n- App\u002Fversion\u002Fcommit tested:\n- Environment:\n- Main risks:\n## Spec Traceability Matrix\n| Requirement | Expected Behavior | Test Performed | Result | Evidence | Notes |\n|---|---|---|---|---|---|\n## Proof Artifacts\nList `.autospec\u002Fproof-matrix.json`, `.autospec\u002Freliability.yml`,\n`.autospec\u002Fcontrol-intent-ledger.json`, `.autospec\u002Fmutation-proof.json`, and\n`.autospec\u002Fcanary-results.json`, or state why each artifact was drafted inline\ninstead of written.\n## Artifact Freshness and Evidence Provenance\nList commit\u002Fspec\u002Fenvironment\u002Ftest-command freshness checks and the exact\nevidence cited for each PASS row.\n## Runtime Error and Flake Classification\nList console errors, network failures, runtime warnings, retries, sleeps,\ntimeouts, flake classification, and fixes or quarantines.\n## Spec Contradictions\nList contradictory or untestable requirements, UI\u002FAPI\u002Fspec mismatches, proposed\nresolution, and follow-up issue or spec edit.\n## Data Lifecycle Proof\nList create, refresh, edit, delete, rollback, idempotency, navigation, and\nconcurrency evidence for stateful workflows.\n## Observability Contract\nList correlation IDs, health probes, error boundary behavior, backend timing,\nlogs, user-safe messages, and any missing diagnostic hooks.\n## Reliability Exhaustion Loop\nList each \"what else could make this unreliable, duplicated, or falsely green?\"\nanswer and how it was handled.\n## Legacy Removal and Spec Cleanup\nList deprecated surfaces found, replacement path, code\u002Fconfig\u002Fdocs\u002Fspec\u002Ftests\nremoved or updated, data cleanup or migration action, compatibility window if\nany, and evidence that QA did not revive the legacy path.\n## Bugs and Gaps\nFor each issue include severity, area, spec reference, steps to reproduce,\nexpected, actual, evidence, and suggested fix.\n## UI Control Coverage\nList every tested text input, select\u002Fdropdown, button, form, navigation element,\nmodal, table\u002Flist, and other control.\n## Validation Coverage\nList every validation rule tested, including valid, invalid, boundary, and\nrecovery behavior.\n## User Input Intent Review\nList every input-like control and answer: what it is for, why it exists, how a\nuser should use it, expected request\u002Fstate\u002Fresult effect, invalid\u002Frejected-input\nbehavior, decorative\u002Fread-only status if applicable, and evidence that it was\nimplemented and tested correctly.\n## No-Mock Deployed Smoke Coverage\nList every deployed\u002Fdev smoke workflow, live URL\u002Fconfig used, representative\ninput\u002Fdata, result, and blocker. Any required `NOT TESTED` no-mock smoke row\nforces Overall result: PARTIAL unless the QA contract explicitly exempts it.\n## Live Backend Blocker Triage\nFor each blocked live path, list safe config sources checked, secret names or\ncredential sources referenced without values, temporary credential cleanup,\nhealth\u002Fstatus\u002Ffleet probes, passed real-data endpoints, remaining failing route\nor subject, root-cause classification, and next operator or implementation\naction.\n## Presentational Control Classification\nList each example chip, shortcut, preset, or token-like control as\ndecorative\u002Fpresentational or workflow control, with the evidence or follow-up\nissue\u002Ftask.\n## Duplicate-Code Guardian\nList duplicated or near-duplicated components, helpers, validators, API clients,\nrequest wrappers, error banners, fixtures, and test utilities, with reused\nalternatives or follow-up fixes.\n## Mutation and Breakage Proof\nList critical workflow tests, the simulated break or mutation, expected failing\nassertion, observed result, and strengthening performed if the test stayed green.\n## Benchmark Overfit and Test Leak\nList tests whose fixtures hard-code public benchmark identifiers, use a fixed\nfirst-N slice, assert exact benchmark answer-key values, lack a randomized or\nproperty-based sibling, or reuse the same fixture as training\u002Fselection signal.\nFor each: test path, leaked dataset, failure mode (1-6 from the gate), and\nrequired remediation.\n## Outsourced Implementation\nList third-party API\u002FSDK calls or cached external payloads where the spec\nrequired the product to implement the action locally. For each: spec\nacceptance criterion, offending client\u002FURL, matched signal(s) from the gate\n(1-6), and remediation (replace remote call with in-repo algorithm; keep\nexternal service only as optional comparator behind a flag).\n## Post-Merge Deployed Canary\nList required canary workflows, representative input, deployed\u002Fdev URL, expected\ndomain result, result, and regression issue\u002Faction for failures.\n## New Code Intent Gate\nList new code units reviewed, owning spec\u002FAC, reason existing helpers were not\nenough, public contract, proof test, and what would break if wrong.\n## Accessibility Findings\nInclude keyboard, focus, labels, contrast, ARIA, and screen-reader concerns.\n## Cross-Browser \u002F Responsive Findings\nInclude desktop, tablet, and mobile behavior if applicable.\n## Automated Test Gaps\nList exact tests to add before the app is fully protected.\n## Final Verdict\nState whether the app satisfies the spec and the minimum fixes required before\nrelease.\n```\n\n## Regeneration loop\n\nAfter the audit:\n\n1. Convert every `FAIL`, `PARTIAL`, `NOT TESTED`, and high-risk `AMBIGUOUS`\n traceability row into one of:\n - a product bug fix,\n - a regenerated\u002Fstrengthened automated test,\n - a follow-up GitHub issue when implementation scope is too large.\n A required no-mock deployed smoke row that remains `NOT TESTED` must produce\n an environment setup issue\u002Ftask, a QA contract update, or an operator-blocker\n line with exact rerun instructions.\n Any input-like control with an unanswered User Input Intent Prompt must\n produce a strengthened test, implementation fix, spec clarification, or\n follow-up issue.\n A blocked live-backend row must run the Live Backend Blocker Triage Prompt\n first and then produce either real no-mock smoke evidence or a classified\n credentials\u002Finfrastructure\u002Froute\u002Fworker blocker.\n Missing proof artifacts, unclassified controls, duplicated generated code,\n missing mutation\u002Fbreakage proof, missing canary, missing no-mock minimum\n coverage, and unanswered new-code intent gates must each produce a\n strengthened test, implementation fix, reliability contract update, or\n follow-up issue.\n Stale artifacts, missing evidence provenance, unexpected console\u002Fnetwork\n errors, unresolved spec contradictions, missing data lifecycle proof, missing\n observability for backend-backed failures, unclassified flakes, and any\n actionable Reliability Exhaustion Loop answer must also produce a fix,\n stronger test, proof update, contract update, or follow-up issue.\n Any deprecated surface still referenced by code, config, specs, docs, tests,\n fixtures, infrastructure, or live-smoke repair steps must produce removal,\n spec cleanup, migration work, or a sunset follow-up before PASS.\n2. Regenerate tests in the narrowest existing harness:\n - unit tests for pure functions and validation rules,\n - integration\u002FAPI tests for server-side validation and persistence,\n - component tests for isolated UI states,\n - E2E\u002FPlaywright tests for user journeys, controls, accessibility, and\n cross-feature behavior.\n3. Preserve or strengthen assertions. Never replace a specific assertion with a\n weaker smoke assertion.\n4. Run the relevant test commands and the repo's validation command.\n5. Repeat until the traceability matrix has no unexplained gaps or the remaining\n gaps are filed as issues with reproduction steps and evidence.\n\n## QA verdict artifact\n\nAt the end of every audit run (including aborted runs), write\n`.autospec\u002Fqa-verdict.json` as the machine-readable result. Downstream\nskills — notably `\u002Fautospec-release` — read this file as the authoritative\ngate signal instead of re-parsing the prose report.\n\nSchema:\n\n```json\n{\n \"verdict\": \"PASS|PARTIAL|FAIL\",\n \"head_sha\": \"\u003Cgit rev-parse HEAD at run start>\",\n \"generated_at\": \"\u003CISO-8601 UTC>\",\n \"live_app_proof\": true,\n \"artifacts\": [\"path\u002Fto\u002Fscreenshot.png\", \"path\u002Fto\u002Fnetwork-trace.har\"],\n \"findings\": [\n {\n \"category\": \"benchmark_overfit|outsourced_implementation|no_mock_smoke|live_backend_blocker|mutation_proof_missing|spec_contradiction|duplicate_code|presentational_misclassified|legacy_residue|new_code_intent|accessibility|cross_browser|visual_fidelity|automated_test_gap|other\",\n \"release_blocking\": true,\n \"status\": \"PASS|PARTIAL|FAIL|NOT_TESTED\",\n \"summary\": \"\u003Cone-line description>\",\n \"evidence\": \"\u003Cpath or pointer to artifact, report section, or issue>\"\n }\n ]\n}\n```\n\nRules:\n\n- `live_app_proof` is `true` ONLY if at least one interaction artifact\n (screenshot, DOM snapshot, network trace, recorded session) was captured\n against a booted app whose commit matches `head_sha`. Otherwise `false`.\n- `release_blocking` defaults TRUE for:\n - `benchmark_overfit` with failure mode 6 (training-on-test leak),\n - `outsourced_implementation` matching signal 1 (implementation verb\n satisfied by remote call), signal 2 (benchmark\u002Fcomparator collision),\n or signal 6 (reimplementation directive),\n - `no_mock_smoke` on a required path with any non-PASS status,\n - `live_backend_blocker` unresolved,\n - `mutation_proof_missing` on a critical workflow,\n - `spec_contradiction` unresolved,\n - `legacy_residue` referenced by current user-facing docs.\n Other categories default FALSE; promote to TRUE only when the finding\n documents a user-visible regression, data loss, security exposure, or\n violated spec requirement.\n- Write atomically: `.autospec\u002Fqa-verdict.json.tmp` then `mv` to the final\n path. Chmod 644. Always overwrite — staleness is checked by `head_sha`,\n not mtime.\n- If the audit aborts before completion, still write the file with\n `verdict: \"FAIL\"` and one finding describing the abort reason. Never\n leave a stale prior verdict in place to be misread as the current run.\n\n## Output contract\n\nReturn:\n\n- QA report path or inline report.\n- Tests added\u002Fchanged.\n- Product bugs fixed, if any.\n- Follow-up issues filed or drafted.\n- Proof artifacts written or drafted.\n- Reliability contract, control ledger, mutation proof, canary, duplicate-code,\n and new-code intent status.\n- Commands run and results.\n- Remaining risks.\n\n## Stop mode\n\nIf the request is exactly `stop` or `stop` plus `--\u003Cword>` flags after\nnormalization, dispatch to:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-stop.sh\" \u003Cargs>\n```\n\nPrint the helper output and stop. Do not run the QA audit.\n\n## Harness-aware handoff\n\nLoop dispatch uses `lib\u002Fautospec-harness-detect.sh` (issue #723) to\nresolve the active AI harness and pick the canonical `\u002Fautospec --autonomous`\ninvocation form:\n\n- Claude Code → `claude \"\u002Fautospec\" \"--autonomous\" \"$PROMPT\"`.\n- Codex CLI → `codex exec --skip-git-repo-check \"\u002Fautospec --autonomous $PROMPT\" \u003C\u002Fdev\u002Fnull` (the \u003C\u002Fdev\u002Fnull closes stdin — without it codex exec hangs on an open stdin, issue #3380).\n- OpenCode → `opencode \"\u002Fautospec\" \"--autonomous\" \"$PROMPT\"` (best-effort).\n\nDetection order: `AUTOSPEC_HANDOFF_DISPATCHER_KIND` env override → skill-mount\nprobe (`~\u002F.claude\u002Fskills` \u002F `~\u002F.codex\u002Fprompts` \u002F `~\u002F.config\u002Fopencode\u002Fagent`) →\nPATH probe. Missing dispatcher exits 3 with\n`code_health:loop_handoff_no_dispatcher_for_harness`.\n","# autospec-qa workflow\n\nRun a spec-to-running-app QA audit, then regenerate missing or weak tests until\nthe application behavior is covered by executable evidence. This skill is the\nexplicit revalidation companion to `autospec-test`: `autospec-test` gates PRs\nwith deterministic coverage and E2E checks; `autospec-qa` performs a broad\nhuman-style audit from the spec and turns gaps into stronger tests or follow-up\nissues.\n\n## Cluster dispatch\n\nThe per-area prose for this skill is also available as 8 cluster files under\n`skills\u002Fautospec-qa\u002Fclusters\u002F\u003Cname>.md`, dispatched by\n`qa-cluster-dispatch.sh` (issue #730). The 8 canonical clusters are:\n\n1. `spec-traceability` — extract spec requirements + traceability matrix.\n2. `functional-coverage` — UI controls, forms, validation, dropdowns, buttons.\n3. `backend-integration` — API contracts + no-mock smoke + live backend triage.\n4. `reliability-contract` — proof matrix, control ledger, mutation, canary,\n no-mock coverage, observability, data lifecycle.\n5. `legacy-and-cleanup` — legacy removal gate + spec\u002Fdocs cleanup +\n deprecated-surface scan.\n6. `benchmark-and-outsourcing` — benchmark-overfit gate + outsourced-\n implementation gate.\n7. `accessibility-and-responsive` — a11y + viewport + browser variance.\n8. `production-incidents` — incident registry regression check (PR #661).\n\nEach cluster carries only its area's prose plus the spec under audit. The\norchestrator (`qa-cluster-dispatch.sh`) is harness-aware (via\n`lib\u002Fautospec-harness-detect.sh`, PR #725), honors\n`qa-cluster-coverage.sh` for cross-cluster dedup, and honors\n`qa-verify-finding.sh` for verify-first filtering. Aggregated findings\nland in `.autospec\u002Fqa-verdict.json`, which the existing heal loop\n(PR #666\u002F#713) consumes unchanged.\n\nThe full per-area prose in the sections below remains canonical for now;\ncluster files reference it and will be backfilled as the dispatch model\nmatures. Operators can opt out individual clusters via\n`qa-cluster-dispatch.sh --skip-cluster \u003Cname>`.\n\n## Deployment contract\n\n`\u002Fautospec-qa` assumes the app under audit is already running at the URL the\noperator supplies. For repos that need a fresh deploy plus a scoped test-data\nclone before each QA cycle, the optional declarative contract\n`.autospec\u002Fqa-deploy.yml` stands the app up **first** and records what\u002Fwhen\u002Fwhere\ninto the verdict — so a failed deploy surfaces as a single\n`code_health:qa_deploy_*` finding instead of a downstream `502` triage trail.\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-deploy-runner.sh\" \\\n --repo-dir . --verdict .autospec\u002Fqa-verdict.json\n```\n\nis invoked at the **very start** of the orchestration — **before any cluster\nfan-out** — and its exit code gates the audit. The Live backend blocker triage\nprompt above stays as-is: it covers the deploy-succeeds-but-app-unhealthy-mid-\naudit case; the deploy runner covers the never-deployed case.\n\n**Contract file `.autospec\u002Fqa-deploy.yml`** mirrors the declarative style of\n`.autospec\u002Ftest.yml`, parsed with `yq -o=json` and validated against\n`schemas\u002Fautospec-qa-deploy.schema.json` with `ajv` (the same yq → jq → ajv\ntoolchain `skills\u002Fautospec-test\u002Fscripts\u002Fload-contract.sh` uses). Its presence\nmakes deploy mandatory. Key fields:\n\n- `stages[]` (required) — ordered deploy stages run sequentially under each\n stage's `timeout` (default 300s); first failure aborts the rest. Each stage\n has a `name`, a `command` run via `bash -c`, optional `env`, and an optional\n `health_check` (`url`, `expect_status` default 200, `retry` default 30,\n `retry_interval` default 10s) polled after the command.\n- `stages[].safety.max_records` — **required** for any data-clone stage (name or\n command matching `clone|copy|replicate|sync`).\n- `teardown[]` — post-verdict cleanup entries (`name`, `command`, `on_failure`\n `warn`|`fail`).\n- `target_envs.forbidden` (required, ≥1) — the absolute safety floor.\n- `target_envs.allowed` \u002F `safety.notes` — advisory, recorded.\n\n**Safety floor (non-negotiable, enforced regardless of operator config),** each\nviolation aborts immediately, runs no further stages, and exits **3**:\n\n1. **Forbidden-target match** — each `target_envs.forbidden` token (literal,\n case-insensitive substring) matched against each stage `command`,\n `health_check.url`, and captured stdout → `qa_deploy_forbidden_target`.\n2. **Production-pattern rejection** — each deploy\u002Fteardown `command` matched\n word-boundary case-insensitively against `--prod`, `--production`, ` prod `,\n ` production `, `production-only`, `live-prod` → `qa_deploy_prod_pattern`.\n3. **`max_records` required for data-clone stages** — a `clone|copy|replicate|\n sync` stage without `safety.max_records` → `qa_deploy_missing_records_cap`.\n\n**Exit-code gating:**\n\n| Exit | Meaning | Verdict category |\n| --- | --- | --- |\n| 0 | No `.autospec\u002Fqa-deploy.yml` (no-op), or all stages + probes succeeded | — \u002F `deploy` block |\n| 1 | A stage failed\u002Ftimed out, or a `health_check` exhausted retries | `code_health:qa_deploy_failed` |\n| 2 | Usage \u002F contract invalid (ajv fail, malformed YAML, missing required) | `code_health:qa_deploy_invalid_contract` |\n| 3 | Safety-floor violation | `qa_deploy_forbidden_target` \\| `qa_deploy_prod_pattern` \\| `qa_deploy_missing_records_cap` |\n\nA failed deploy (exit 1\u002F2\u002F3) never reaches the cluster fan-out: the operator\nsees a single `code_health:qa_deploy_*` finding naming the failing stage and a\nstdout tail, not a `502`.\n\n**`deploy:` verdict block.** On success the runner writes a `deploy:` block into\n`.autospec\u002Fqa-verdict.json` (atomically via the sibling `.tmp` + `mv` pattern\nfrom `qa-finding-filter.sh`; a minimal `{\"deploy\": {...}}` is created\nwhen no verdict exists yet, which the later audit merges into):\n\n```json\n{\n \"deploy\": {\n \"stages_run\": [\"deploy-to-test-family\", \"clone-production-data\"],\n \"stage_durations_ms\": {\"deploy-to-test-family\": 145000},\n \"target_env\": \"https:\u002F\u002Ftest.tidyboard.org\",\n \"head_sha_deployed\": \"abc1234\",\n \"data_clone\": {\"source\": \"prod-readonly\", \"records_copied\": 8500, \"max_records\": 10000},\n \"teardown_run\": true,\n \"teardown_failures\": []\n }\n}\n```\n\n`head_sha_deployed` = `git rev-parse --short HEAD` at deploy time.\n`data_clone.records_copied` is parsed from a `records_copied=\u003Cint>` stdout line\nwhen present, else omitted. The block is **additive** — every existing verdict\nconsumer (heal loop, `\u002Fautospec-release`, `\u002Fautospec-sweep`) is unaffected.\n\n**Teardown.** `teardown[]` entries run after the verdict is final, unless\n`--skip-teardown` is passed (which sets `deploy.teardown_run: false` and leaves\nthe env intact for repeated manual re-QA). `on_failure: warn` logs only;\n`on_failure: fail` downgrades a `PASS` verdict to `PARTIAL` (never touches\n`FAIL`) and appends the entry to `deploy.teardown_failures`.\n\n**Graceful absent-file behavior.** When `.autospec\u002Fqa-deploy.yml` is absent the\nrunner exits `0` immediately, writes nothing, and QA proceeds exactly as today —\nthe verdict is byte-identical with no `deploy:` key. This compatibility contract\nis the most important one: behavior is byte-for-byte today's behavior when the\nfile is not present. Secret env **values** are never logged or recorded (only\nkey names). The runner uses `set -u` (not `set -e`) around stage execution so\nfailures are caught explicitly and recorded in the verdict.\n\n\u003C!-- autospec-block:startup-self-update SKILL_NAME=autospec-qa -->\n\n## Self-update mode\n\nIf the feature-request argument matches `update` after trimming and lowercasing,\nre-install the full autospec suite from `main`, show the before\u002Fafter diff if the\nharness exposes it, then stop. Do not run the QA audit.\n\n## Required capabilities & harness adapter\n\n| Capability | Claude Code | OpenCode | Codex CLI | Fallback if missing |\n| --- | --- | --- | --- | --- |\n| Subagent model tier | Tier A: `opus` + ultrathink | Tier A: top-tier `task` + max reasoning | Tier A: current top GPT + `reasoning_effort=high` | Run inline, but keep the same report contract |\n\u003C!-- autospec-block:harness-adapter-core -->\n| Browser\u002FE2E execution | Playwright\u002Fbrowser tool or shell | Playwright\u002Fbrowser task | shell + browser when available | Use `browser-verified` \u002F `fallback-smoke-only` \u002F `not-run`; mark UI-only gaps with blocker |\n| Shell execution | Bash tool | shell tool | shell\u002Fapply_patch | Required for regeneration |\n\n**Model tier:** TIER_A for the spec audit and test-regeneration plan because\nfalse PASS results are more expensive than extra review tokens.\n\n## Harness detection\n\nDetect the harness once at skill start:\n\n1. Claude Code: `Agent` with `subagent_type` is available.\n - `TIER_A` = `opus` + ultrathink.\n - `TIER_B` = `sonnet`.\n2. OpenCode: `task` tool is available.\n - `TIER_A` = top-tier task model + high reasoning.\n - `TIER_B` = smaller-tier task model + medium reasoning.\n3. Codex CLI: `apply_patch` is the primary edit tool.\n - `TIER_A` = current top GPT + `reasoning_effort=high`.\n - `TIER_B` = current cost-optimized Codex model + `reasoning_effort=medium`.\n\nPrefer a Tier A reviewer\u002FQA subagent for the first traceability audit when the\nharness supports it. If `TIER_A` is unavailable, silently fall back to the next\navailable top-tier model. If delegation is unavailable, run the audit inline.\n\n## When to use\n\n- After `\u002Fautospec-run` finishes and the operator wants proof that the app\n actually satisfies the source spec.\n- When a UI-heavy feature needs text boxes, validation, selects, dropdowns,\n buttons, navigation, modals, keyboard behavior, accessibility, and API effects\n verified from multiple directions.\n- When existing tests pass but the spec may still be under-tested.\n- When the user asks to regenerate tests from a spec or strengthen weak tests.\n\n## When not to use\n\n- Do not use against production unless the target repo's `autospec-test`\n contract explicitly allows scoped production and backup\u002Frestore is verified.\n- Do not mark a feature PASS from code inspection alone.\n- Do not loosen assertions to make regenerated tests pass.\n- Do not treat mocked API tests as proof that a deployed workflow works.\n\n## No-mock deployed smoke rule\n\nFor every user workflow button or dropdown-backed action, QA must cover both the\ncontract and the deployed user-visible result:\n\n1. Verify the control is enabled and changing it changes the actual request\n payload, query, route, or command parameters.\n2. Run a mocked happy-path test for deterministic UI state coverage.\n3. Run a no-mock smoke test against the configured deployed\u002Fdev URL using a\n representative input from the spec or domain fixtures.\n4. Assert that no generic live-failure banner appears.\n5. Assert that the result panel contains a real domain result, not only that a\n request was sent.\n6. Include regression coverage for known fragile backend responses, such as\n `502` bridge\u002Fproxy failures, and require either a working fallback route or a\n clear actionable user state.\n7. Re-check the endpoint mental model against the app and production behavior:\n if a mocked route differs from the route that actually supports the workflow,\n tests must follow the user-visible workflow and document the stable backend\n contract they prove.\n\n## No-mock deployed smoke blocker handling\n\nIf a required no-mock deployed\u002Fdev smoke path is `NOT TESTED`, the final verdict\nmust be `PARTIAL` unless the target repo's explicit test contract says that\nworkflow intentionally has no deployed smoke requirement.\n\nDo not leave a no-mock smoke gap as a prose-only \"remaining risk.\" For every\n`NOT TESTED` no-mock smoke row, create or draft one of:\n\n1. An environment setup issue\u002Ftask that names the missing dev URL or env var,\n representative seed\u002Flive data, credential requirements, backup\u002Frestore\n constraints, and exact smoke workflow command or Playwright scenario.\n2. A test contract update in `.autospec\u002Ftest.yml`, `docs\u002F**`, or the repo's\n equivalent QA contract explaining why deployed smoke is intentionally\n unavailable for that workflow.\n3. An operator-blocker line with the exact missing configuration and the next\n command to rerun once it exists.\n\nIf a dev URL and representative data are supplied, run the no-mock smoke test\ninstead of drafting setup work. If credentials or data are missing, keep the\ntraceability row `NOT TESTED`, keep the overall result `PARTIAL`, and make the\nsetup artifact the required next action.\n\n## Presentational control classification\n\nExample chips, demo shortcuts, taxonomy tokens, conversion presets, and similar\ncontrols must be classified before the report is finalized:\n\n- `decorative\u002Fpresentational`: assert that the element has no action contract,\n no request side effect, and is either documented or clearly inert.\n- `workflow control`: verify request contract, mocked happy path, no-mock smoke\n path, success-state result, failure-banner absence, and known-fragile-backend\n fallback behavior.\n\nDo not report presentational chips as a vague risk. Either prove they are\nintentionally decorative or file\u002Fdraft the issue that wires and tests them as\nreal controls.\n\n## User input element intent prompt\n\nUse this prompt every time the app creates, changes, tests, or audits any\nuser-input element, including text boxes, textareas, selects, dropdowns,\ncomboboxes, checkboxes, radio buttons, switches, date\u002Ftime inputs, file inputs,\nsearch boxes, filters, sliders, segmented controls, editable tables, chips, or\nother controls that accept or change user intent:\n\n```text\nFor this user input element, answer before accepting the implementation or test:\n\n1. What is this control for?\n2. Which user goal or spec requirement does it serve?\n3. How should a real user discover and use it?\n4. What valid, invalid, empty, boundary, and recovery inputs must work?\n5. What request payload, query, route, command, state change, persistence effect,\n or visible result should change when the user changes this input?\n6. What should happen when the backend rejects, times out, or partially accepts\n this input?\n7. Is this control intentionally read-only, disabled, decorative, or\n presentational? If yes, where is that contract documented?\n8. Did I implement and test this correctly, with evidence from the running app\n rather than only DOM presence or mocked request dispatch?\n\nRequired outcome:\n- If the control is functional, tests must cover discoverability, enabled\u002Fdisabled\n state, valid input, invalid input, boundary input, request\u002Foutput effect,\n success state, error state, and recovery.\n- If the control is decorative or read-only, the QA report must classify it that\n way and cite the spec, UI copy, or test contract that makes this intentional.\n- If the answers are unclear, mark the traceability row AMBIGUOUS or PARTIAL and\n draft the smallest spec\u002Ftest\u002Fimplementation follow-up needed to settle it.\n```\n\n## Live backend blocker triage prompt\n\nWhen a no-mock deployed\u002Fdev smoke path is blocked by missing config, unknown\ncredentials, `502`, `504`, timeout, bridge, queue, worker, proxy, or backend\nhealth errors, do not stop at \"credentials unavailable\" or \"live backend not\ntested\" until you have made a bounded, non-secret-leaking config search.\n\n```text\nFor this live backend blocker, answer before finalizing the QA report:\n\n1. Where does the app define its deployed\u002Fdev base URL, API endpoint, worker\n endpoint, queue\u002Fbridge URL, and environment-specific service names?\n2. Are these values available through safe config surfaces such as Terraform\n outputs, deployment manifests, CI variables, documented env vars, cloud\n resource names, or local `.env.example` files?\n3. If credentials are required, which secret names or credential sources are\n referenced, and can the smoke test use them without printing secret values?\n4. If temporary credential files or tokens are created for probing, were they\n stored outside the repo, restricted, and removed after the probe?\n5. Is the failure caused by missing credentials, stopped infrastructure,\n unhealthy bridge\u002Fproxy, missing worker, wrong route mental model, or a live\n handler\u002Findex path that times out?\n6. Can a direct health\u002Fstatus\u002Ffleet\u002Fping probe distinguish infrastructure\n outage from a route-specific worker failure?\n7. Which no-mock smoke paths now pass with real domain data, and which exact\n route\u002Fsubject still fails?\n8. What operator action, infrastructure fix, worker fix, or fallback behavior is\n required next?\n\nRequired outcome:\n- Never print secret values in the QA report, logs, issue body, or test output.\n- If credentials\u002Fconfig are discoverable, run the no-mock smoke instead of\n leaving it `NOT TESTED`.\n- If infrastructure was stopped or unhealthy and can be safely started by the\n target repo's documented dev procedure, record the action and rerun the smoke.\n- If broad health probes pass but one route\u002Fsubject times out, classify the\n blocker as a route-specific live worker\u002Fhandler failure, not missing\n credentials.\n- Report passed live paths and the remaining failing path separately.\n```\n\n## Proof artifact requirements\n\nThe QA pass should produce machine-readable proof artifacts whenever the target\nrepo permits writing under `.autospec\u002F`. If the repo is read-only, draft the\nartifact contents in the report.\n\nRequired artifacts:\n\n- `.autospec\u002Fproof-matrix.json`: one row per spec requirement with fields for\n `requirement_id`, `spec_reference`, `expected_behavior`,\n `implementation_files`, `automated_tests`, `live_evidence`, `status`,\n `blocker`, and `follow_up`.\n- `.autospec\u002Freliability.yml`: the generated app reliability contract,\n including required live smoke workflows, representative inputs, seed\u002Flive data\n sources, allowed mocks, required no-mock paths, health probes, expected\n fallback behavior, forbidden production URLs, and forbidden false-green\n conditions such as \"PASS from DOM presence only.\"\n- `.autospec\u002Fcontrol-intent-ledger.json`: every discovered user input, button,\n link, chip, dropdown, form, modal trigger, table action, and workflow control\n classified as `functional`, `read_only`, `decorative`, or `unclassified`, with\n intent, owning spec reference, selector\u002Flocator, expected effect, tests, and\n evidence.\n- `.autospec\u002Fmutation-proof.json`: critical workflow assertions that were\n intentionally broken or simulated and proved that the test suite fails when\n the implementation regresses.\n- `.autospec\u002Fcanary-results.json`: post-merge or deployed\u002Fdev no-mock canary\n results for representative workflows when a deployed\u002Fdev environment exists.\n\nValidate written artifacts against the matching repository schemas when tooling\nis available:\n\n- `schemas\u002Fautospec-proof-matrix.schema.json`\n- `schemas\u002Fautospec-reliability.schema.json`\n- `schemas\u002Fautospec-control-intent-ledger.schema.json`\n- `schemas\u002Fautospec-mutation-proof.schema.json`\n- `schemas\u002Fautospec-canary-results.schema.json`\n\nUse `validate-qa-artifacts.sh --repo \u003Ctarget-repo>` when the autospec\nrepository helper is available. It validates present `.autospec\u002F*` proof files\nand fails malformed artifacts while warning about missing draft-only artifacts.\n\nHard gate: a QA result cannot be `PASS` if `.autospec\u002Fproof-matrix.json` has a\n`FAIL`, `PARTIAL`, `NOT_TESTED`, `AMBIGUOUS`, or unblocked `unclassified` row.\n\n## Artifact freshness gate\n\nEvery proof artifact must carry freshness metadata:\n\n- repository commit SHA,\n- spec file path,\n- spec hash,\n- app URL or environment,\n- test command hash when practical,\n- generation timestamp.\n\nBefore accepting an artifact, compare its freshness metadata to the current\ncheckout and tested environment. If the spec, implementation, app URL, or test\ncommand changed after the artifact was generated, mark the artifact stale and\nthe affected rows `PARTIAL` until regenerated.\n\n## Documentation gate\n\nEvery QA run invokes `\u002Fautospec-doc --full` (via\n`skills\u002Fautospec-doc\u002Fscripts\u002Fdoc-orchestrator.mjs --full`), then runs\n`verify-examples.mjs` across the regenerated pages, then runs\n`check-doc-drift.sh --working-tree` expecting a clean working tree.\n\n`documentation.auto_regenerate` is NOT consulted here. QA is the guaranteed\nsync point for documentation correctness, independent of the operator-controlled\nauto-regeneration switch.\n\nEach of the following failure classes is a **QA finding** in the standard QA\nreport format, subject to the same severity discipline as the no-mock smoke rule\n(never silently skipped):\n\n- **Generation error** — `doc-orchestrator.mjs --full` exits non-zero or\n produces no output pages.\n- **Failing example** — `verify-examples.mjs` reports one or more example\n failures across the regenerated audience pages.\n- **Residual drift** — `check-doc-drift.sh --working-tree` exits non-zero,\n indicating that generated pages differ from what is committed.\n- **Missing audience page** — a required audience page is absent from the\n output after generation.\n\nFailures are reported as findings with `release_blocking: true` and `category:\ndocumentation_gate`, mirroring the no-mock smoke handling.\n\n**Graceful skip** (logged as INFO, not a finding): when the target repo has no\n`documentation:` config (orchestrator exits 2), the gate records an INFO log\nline — `docs: no documentation config found (exit 2), gate skipped` — and\ncontinues without emitting a finding. No other skip condition is permitted.\n\n## Repo quality audit\n\nAfter QA proof artifacts are written, run the shared read-only quality audit so\nthe QA report carries repo-wide code-quality, verification, dependency, route,\nsecurity, and maintainability gaps discovered during revalidation:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Frepo-quality-audit.sh\" \\\n --repo . \\\n --json \".autospec\u002Frepo-quality-audit.json\" \\\n --markdown \".autospec\u002Frepo-quality-audit.md\" \\\n ${AUTOSPEC_QUALITY_AUDIT_FILE_ISSUES:+--file-issues}\n```\n\nInclude the audit `status`, filed issue links, suppressed findings, and unfiled\nresidual risks in the final QA verdict. The helper is read-only with respect to\nsource files; it only writes audit artifacts and optional deduplicated GitHub\nissues when operator policy permits issue creation.\n\n## Evidence provenance gate\n\nEvery `PASS` must cite provenance that another reviewer can inspect:\n\n- test file and test name,\n- command and result,\n- screenshot, video, trace, or log path when relevant,\n- network request\u002Fresponse summary,\n- deployed\u002Fdev URL and representative input for no-mock smoke,\n- backend health\u002Fprobe result when backend behavior is claimed.\n\nNo provenance means no `PASS`. Request dispatch alone, DOM presence alone, a\ngeneric result panel change, or a mocked-only response is not sufficient\nprovenance for backend-backed behavior.\n\n## Console and network error gate\n\nFor each browser or deployed\u002Fdev workflow, inspect console and network signals.\nThe workflow fails unless the error is the explicit negative path under test:\n\n- uncaught frontend exceptions,\n- failed network calls,\n- hydration\u002Fruntime warnings that affect the route,\n- generic live-failure banners,\n- unexpected retries, timeouts, or aborted requests,\n- swallowed errors that leave stale UI.\n\nRecord expected negative-path failures separately from unexpected errors.\n\n## Spec contradiction detector\n\nBefore implementation, test generation, or final QA, scan the spec and current\nUI\u002FAPI behavior for contradictions:\n\n- two requirements conflict,\n- an acceptance criterion is not testable,\n- UI copy implies behavior the spec does not mention,\n- backend\u002FAPI contract contradicts product wording,\n- error\u002Ffallback behavior is unspecified for a required workflow,\n- required seed\u002Flive data is missing for a no-mock path.\n\nContradictions become `AMBIGUOUS` rows with a proposed resolution and a\nspec\u002Fconfig follow-up before implementation is called complete.\n\n## Spec supersession (recency)\n\nWhen two specs in `docs\u002Fspecs\u002F` overlap on a behavior, the spec whose\nlast-modifying commit on the current branch is most recent wins (issue #635:\nimplicit-by-recency supersession; untracked specs fall back to filesystem\nmtime). Operators do NOT write `Supersedes:` frontmatter — recency alone\ndecides.\n\nQA validation MUST resolve each behavior to its authoritative spec before\nclassifying a row as `FAIL`. Behavior present only in an older, superseded\nspec is not a QA failure — it has been replaced by the newer spec. Use the\nshared helper to look up the authoritative spec for each behavior key:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fresolve-spec-supersession.sh\" \"\u003Cbehavior-key>\"\n```\n\nFor each proof-matrix row whose expected behavior overlaps multiple specs:\n\n1. Run the resolver against the behavior key (e.g. heading text or\n acceptance-criterion fragment).\n2. If the resolver returns a spec path different from the row's\n `spec_reference`, the row is being validated against a superseded\n behavior. Re-derive the expected behavior from the resolver's winning\n spec and update the row's `spec_reference` accordingly.\n3. If the row's expected behavior no longer appears in the winning spec,\n mark the row `superseded` with a note pointing at the winning spec; do\n NOT classify it `FAIL`.\n\nThis rule applies symmetrically to control-intent ledger entries and\nlive-evidence checks: a control whose intent is only described by a\nsuperseded spec is not a regression.\n\n## Data lifecycle proof\n\nFor CRUD, stateful, or workflow apps, prove the data lifecycle:\n\n- create persists after refresh,\n- edit propagates to list\u002Fdetail\u002Fsearch\u002Fexport views,\n- delete\u002Fremove is reflected everywhere without ghost UI state,\n- failed writes roll back optimistic UI,\n- retries are idempotent or visibly safe,\n- browser back\u002Fforward and deep links preserve expected state,\n- concurrent or rapid repeated actions do not corrupt state.\n\nIf the app has persistence but lacks lifecycle evidence, keep the affected\nfeature `PARTIAL`.\n\n## Observability contract\n\nGenerated apps must expose enough safe diagnostics to debug failed QA and\ncanaries:\n\n- request correlation IDs across frontend\u002Fbackend where practical,\n- frontend error boundary logging,\n- backend route\u002Fworker timing,\n- health\u002Fstatus endpoints or probes,\n- user-safe actionable error messages,\n- logs that identify route\u002Fworker\u002Fcache\u002Fdatabase class without exposing\n secrets or PII.\n\nMissing observability does not automatically fail a pure UI feature, but it is a\nblocking gap for backend-backed workflows whose failures cannot otherwise be\ntriaged.\n\n## Flake quarantine rule\n\nDo not accept \"green after retry\" as reliable without classification. If a test\nuses retries, sleeps, widened timeouts, or repeated reruns to pass, classify the\nflake as one of:\n\n- product race,\n- selector fragility,\n- backend instability,\n- environment issue,\n- test oracle weakness.\n\nThen either fix it, quarantine it with a follow-up issue and owner, or keep the\naffected proof row `PARTIAL`.\n\n## Additional reliability surfaces\n\nKeep looking for reliability gaps beyond the obvious UI happy path:\n\n- route\u002Fscreen inventory: every spec screen and reachable route has coverage or\n a documented exclusion,\n- API contract replay: frontend requests match OpenAPI\u002Fschema\u002Fserver contracts\n when available,\n- auth and permission matrix: each role can and cannot perform the expected\n actions,\n- timezone, locale, browser, viewport, and device variance for date\u002Fformat\u002FUI\n sensitive features,\n- performance budgets for primary workflows,\n- destructive action safety: confirmation, undo\u002Frestore, scoped production\n protections, and backup\u002Frestore where relevant,\n- dead-code and generated-artifact cleanup after implementation,\n- dependency\u002Fsecurity scan for newly added packages or SDK use,\n- migration\u002Fbackward-compatibility proof for schema or persisted-data changes,\n- test oracle specificity: assertions name the domain result, not generic text\n or \"something changed.\"\n\n## Reliability exhaustion loop\n\nBefore finalizing, ask: \"What else could make this generated app unreliable,\nduplicated, or falsely green against the spec?\"\n\nRepeat until the next answer is only:\n\n- already covered by a proof artifact, test, canary, or follow-up issue,\n- impossible to verify from available safe environments and recorded as an\n operator blocker,\n- outside the accepted scope and filed as a separate spec issue,\n- lower value than the documented risk tolerance in `.autospec\u002Freliability.yml`.\n\nEach actionable answer must become a strengthened test, implementation fix,\nproof-artifact update, reliability-contract update, or follow-up issue.\n\n## Generated app reliability contract prompt\n\nBefore declaring a generated app reliable, create or validate\n`.autospec\u002Freliability.yml`:\n\n```text\nFor this app, define the reliability contract:\n\n1. Which user workflows are required live smokes?\n2. Which representative inputs and seed\u002Flive data prove each workflow?\n3. Which tests may mock APIs, and which workflows require no-mock deployed\u002Fdev\n execution?\n4. Which health probes distinguish app, API, queue, bridge, worker, cache,\n database, and external-service failures?\n5. Which backend failures require fallback behavior, and what visible state\n proves the fallback worked?\n6. Which production or unsafe URLs are forbidden during tests?\n7. Which false-green patterns are forbidden, such as DOM-only PASS, request-only\n PASS, mocked-only PASS, or screenshot-only PASS?\n\nRequired outcome:\n- If the contract is missing, draft it.\n- If the contract conflicts with the spec, mark the affected rows PARTIAL and\n file a spec\u002Fconfig follow-up.\n- If no deployed\u002Fdev environment exists, require an explicit contract entry\n explaining the blocker and exact setup action.\n```\n\n## Control intent ledger prompt\n\nThe UI audit must not rely on a vague list of \"controls covered.\" Build a\ncontrol intent ledger:\n\n```text\nFor every reachable control, record:\n\n- selector or stable locator\n- visible label and accessible name\n- control type\n- classification: functional, read_only, decorative, or unclassified\n- spec requirement served\n- expected request\u002Fstate\u002Fpersistence\u002Fresult effect\n- validation and error behavior\n- tests proving the effect\n- live no-mock evidence when required\n- follow-up issue or blocker if not fully proven\n\nRequired outcome:\n- Functional controls need request\u002Foutput\u002Fresult\u002Ffailure coverage.\n- Read-only and decorative controls need an explicit documented reason.\n- Any unclassified control makes the QA result PARTIAL or FAIL.\n```\n\n## Duplicate-code guardian prompt\n\nBefore accepting generated code or regenerated tests, challenge duplication:\n\n```text\nFor each new component, function, module, API client, validator, form helper,\nerror handler, backend wrapper, fixture, or test utility:\n\n1. Search the repo for existing helpers or patterns that already solve this.\n2. If a duplicate exists, reuse it or explain why it is insufficient.\n3. If the new code remains, identify its owning spec requirement and public\n contract.\n4. Block duplicate API clients, duplicate validators, duplicate form state\n logic, duplicate error banners, duplicate request wrappers, and duplicated\n test fixtures unless the issue\u002Fspec explicitly requires a fork.\n\nRequired outcome:\n- Duplication findings become implementation fixes or `DUPLICATE_CODE`\n follow-up issues with file references.\n```\n\n## Mutation and breakage proof prompt\n\nFor every critical user workflow, prove that the test would fail if the product\nwere broken:\n\n```text\nFor this workflow test, simulate or reason through one minimal break:\n\n1. Break request payload\u002Fquery propagation.\n2. Break the visible result rendering.\n3. Return a known backend failure such as `502`, `504`, timeout, empty data, or\n validation rejection.\n4. Disable the fallback route or error banner.\n5. Remove persistence or state update.\n\nRequired outcome:\n- At least one critical workflow per feature has mutation\u002Fbreakage evidence.\n- If a test still passes after the behavior is broken, strengthen the assertion\n before accepting the QA result.\n- Record the result in `.autospec\u002Fmutation-proof.json` or the QA report.\n```\n\n## Benchmark leak and overfit gate\n\nFor every test that consumes a public dataset, benchmark, leaderboard, or\nexternally-curated answer key (e.g., ClassyFire, ChEMBL, MassBank, MNIST,\nGLUE, SuperGLUE, ImageNet, BIG-bench, HELM, GSM8K, MMLU, fixtures derived\nfrom a named corpus), audit for benchmark leak and overfit-shaped assertions:\n\n```text\nFor each test fixture and assertion derived from a public benchmark or\nexternally-curated dataset:\n\n1. Identifier hard-coding — does the test pin specific benchmark IDs\n (InChIKeys, accession numbers, row hashes, sample indices, image filenames,\n prompt IDs) and assert exact downstream values?\n2. First-N slice — is the fixture the first N rows \u002F top-N records \u002F a fixed\n prefix of a known benchmark, rather than a randomized or rotated sample?\n3. Answer-key shape — do the assertions match the benchmark's published\n answer key (labels, class names, expected outputs) such that the system\n under test could pass by memorizing those rows?\n4. Distributional sibling — is there a randomized or property-based test\n covering the same code path on a fresh draw from the source distribution?\n5. Refresh path — can the fixture be regenerated on demand from the upstream\n source (API, query, seeded sampler), or is it frozen indefinitely?\n6. Training-on-test — is the same fixture also used to train, tune, select,\n or prompt-engineer the code under test? If yes, the fixture is leaked.\n\nRequired outcome:\n- Replace fixed slices with a seeded random sample drawn from the upstream\n source per run (or per release), and rotate the seed at a defined cadence.\n- Replace exact-value assertions on benchmark identifiers with property-based\n or invariant assertions that hold for any valid draw from the distribution.\n- Keep at most one tiny \"shape smoke\" test with hard-coded IDs, clearly named\n as a smoke test, never as the primary correctness signal.\n- A test that asserts exact benchmark answers without a randomized sibling is\n a PARTIAL finding. If the same fixture is also used as the training or\n selection signal for the code under test, it is FAIL (training-on-test\n leak).\n- Record each finding in the QA report under \"Benchmark Overfit and Test\n Leak\" with the test path, the leaked dataset, the failure mode (1-6\n above), and the required remediation.\n```\n\n## Outsourced implementation gate\n\nWhen the spec uses an implementation verb (classify, resolve, score, parse,\ntransform, extract, generate, rank, detect, segment, embed, …) and the diff\nor repo adds a runtime call to a third-party API\u002FSDK that performs that same\nverb, the LLM has outsourced the product to an external service instead of\nimplementing it. Audit every new or expanded external-service binding:\n\n```text\nFor each new HTTP client, SDK call, or service binding introduced to satisfy\na spec acceptance criterion:\n\n1. Verb alignment — does the spec's verb describe an action the product is\n supposed to PERFORM (build, classify, resolve, score, parse, transform,\n extract, generate, detect, segment, embed) or merely INTEGRATE WITH\n (fetch from, sync, import, mirror, publish to)? Implementation verbs\n satisfied by remote-call shortcuts are outsourced implementations.\n2. Benchmark \u002F comparator collision — does the third-party service's name\n appear elsewhere in `docs\u002Fspecs\u002F**`, README, or QA reports as a\n \"benchmark\", \"comparator\", \"ground truth\", or \"baseline\"? Using the\n benchmark at runtime contaminates evaluation and frequently violates\n ToS.\n3. Missing local algorithm — does the spec or referenced paper describe an\n algorithm (rules, features, model, scoring formula) that the repo does\n NOT implement, while a remote call answers the same question?\n4. Cached external payloads — is there a `cache\u002F`, `fixtures\u002F`, or\n `generated\u002F` directory holding downloaded service responses that the\n runtime depends on, with no in-repo computation able to reproduce them?\n (Does NOT apply when the spec's verb is itself an integration verb\n from signal 1's integration list — e.g., a project whose stated job is\n to mirror\u002Fimport\u002Fsync that external dataset.)\n5. License and provenance — is there a provenance record (URL, fetch\n timestamp, ToS link, redistribution scope) for every cached external\n payload? Missing provenance on cached third-party data is a release\n blocker even when the runtime call is itself legitimate.\n6. Reimplementation directive — does the spec or product mission state\n that the project is supposed to REPLACE or REIMPLEMENT the named\n service? If yes, runtime use of that service is a definitional bug.\n\nRequired outcome:\n- For each finding, name the spec acceptance criterion, the offending\n client\u002FURL\u002FSDK call, and the signals (1-6) that matched.\n- Remediation: replace the remote call with an in-repo implementation that\n matches the spec's described algorithm. The external service MUST be\n either (a) removed entirely, or (b) gated behind an off-by-default\n feature flag scoped to evaluation\u002Fbenchmark comparison only, with cached\n payloads carrying explicit redistribution permission. No other\n configuration is acceptable for release PASS.\n- A finding matching signal 1 (implementation verb satisfied by remote\n call), signal 2 (benchmark\u002Fcomparator collision), or signal 6\n (reimplementation directive) is FAIL — these are product-identity\n violations and cannot be release-deferred.\n- Signals 3, 4, or 5 alone default to PARTIAL until the in-repo\n implementation lands. Signal 3 paired with signal 1 escalates to FAIL.\n- Record each finding in the QA report under \"Outsourced Implementation\"\n and in `.autospec\u002Fqa-verdict.json` with category\n `outsourced_implementation`, the matched signal numbers in the summary,\n and the remediation status.\n```\n\n## Exhaustiveness flags\n\nThe orchestrator soft-discipline sections above (the reliability exhaustion\nloop, the 20-question Critical self-questioning checkpoint, \"no-mock minimum\ncoverage\", etc.) drive depth of coverage by prose. When clusters skip a step\nthe report can still say PASS while a production bug ships. The operator MAY\ninvoke `\u002Fautospec-qa` with one or more explicit machine-checkable flags that\nconvert that prose into a hard gate. With no flag, behavior is unchanged.\n\n- `--every-spec-row` — fail the run with `code_health:incomplete_traceability`\n if any spec acceptance criterion lacks a non-`NOT_TESTED` row in\n `.autospec\u002Fproof-matrix.json`. Forces the orchestrator to extract every\n AC, not just the ones it judged \"important\".\n- `--mutation-each` — require a mutation\u002Fbreakage entry in\n `.autospec\u002Fmutation-proof.json` for every workflow listed in the spec,\n not just \"critical\" ones. Missing entries emit\n `code_health:incomplete_mutation_proof`.\n- `--no-mock-each` — require a no-mock deployed\u002Fdev smoke path in\n `.autospec\u002Fcanary-results.json` for every backend-backed feature.\n Exceptions must be declared explicitly under `no_mock_exempt` in\n `.autospec\u002Freliability.yml`. Missing entries emit\n `code_health:incomplete_no_mock_coverage`.\n- `--exhaustive` — turns the three above on.\n\nEnforcement runs after the existing verdict computation but BEFORE writing\n`.autospec\u002Fqa-verdict.json` as final. The helper appends one\n`release_blocking: true` finding per gap and demotes the verdict from\nPASS to PARTIAL (FAIL is preserved). The list of flags actually requested\nis recorded under `requested_flags` on the verdict so downstream skills\n(notably `\u002Fautospec-release`) can see what was enforced. Both the\norchestrator prompt and the regeneration loop call this helper:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-exhaustiveness-check.sh\" \\\n --exhaustive \\\n --verdict .autospec\u002Fqa-verdict.json \\\n --proof-matrix .autospec\u002Fproof-matrix.json \\\n --mutation-proof .autospec\u002Fmutation-proof.json \\\n --canary .autospec\u002Fcanary-results.json \\\n --reliability .autospec\u002Freliability.yml \\\n --spec docs\u002Fspecs\u002F\u003Cfeature>.md\n```\n\nExit 0 means every requested gate passed. Exit 1 means at least one gate\nfailed and the verdict + findings have been updated atomically. Backwards-\ncompatible: invoking with no flag is a no-op.\n\n## Self-healing loop\n\n`\u002Fautospec-qa` is self-healing by default. After discovery, the orchestrator\nenters a discover → file → fix → re-QA loop and runs until convergence or a\nguardrail trips. The loop is driven by `qa-heal-loop.sh`, which calls\n`qa-finding-to-issue.sh` once per release-blocking finding to file an\n`auto-implement,autospec:v2-flow` GitHub issue, then dispatches `\u002Fautospec-run`\nto drain the queue before re-running QA.\n\nBuilds on the verify-first filter (#647 \u002F PR #650): the heal loop relies on\nthe filter to reject unverified findings before they become issues, otherwise\nround 1 would file noise. Builds on the production-incident registry\n(#659 \u002F PR #661): findings tagged\n`code_health:production_incident_regression_missing` follow the same heal\npath. Companion to autonomous mode (#662): when\n`~\u002F.autospec\u002Fautonomous.flag` is set, heal mode is implicit.\n\nLoop semantics:\n\n1. Round N: run `\u002Fautospec-qa`, write `.autospec\u002Fqa-verdict.json` as today.\n2. For each finding with `release_blocking: true` and\n `status ∈ {FAIL, PARTIAL, NOT_TESTED}`:\n - Translate via `qa-finding-to-issue.sh` into a structured issue\n body (category + summary + evidence + reproduction + remediation\n directive verbatim from the relevant `code_health:*` directive map).\n - File one `auto-implement,autospec:v2-flow` issue. Existing dedup:\n skip if an open issue with the same `(category, file, summary_hash)`\n already exists.\n3. Launch `\u002Fautospec-run` (single-agent Phase 4) to drain the new + existing\n queue. One PR per issue per existing pipeline semantics.\n4. After the run drains (`batch-done.json: ALL_DONE`), re-enter step 1.\n\nTermination — loop exits when ANY of:\n\n- **Convergence** — round N produces zero findings with\n `release_blocking: true`. (Non-blocking findings are filed once but do\n NOT keep the loop alive.) This is the canonical success state.\n- **Oscillation detected** — round N+1's release-blocking finding set,\n hashed by `(category, file, summary)`, equals round N's. The auto-fix\n is going nowhere; the loop exits with `oscillation_detected` and\n surfaces the persistent findings for operator review.\n- **Round cap** — `AUTOSPEC_HEAL_MAX_ROUNDS` reached (default 5).\n- **Budget cap** — tokens used > `AUTOSPEC_HEAL_TOKEN_CAP` (default\n 1.5M) or wall time > `AUTOSPEC_HEAL_TIME_CAP` (default 4h).\n- **Verify-first violation persists** — if the post-cluster verify-first\n filter keeps dropping the same findings as `verified_dropped` round\n after round, those findings are likely flaky probes; the loop exits\n and asks the operator to triage.\n\nAt loop end, the orchestrator prints a Markdown table to the operator and\nwrites `.autospec\u002Fheal-summary.md` for the audit trail and for\n`\u002Fautospec-release` to consume as a release-readiness signal:\n\n```\n## \u002Fautospec-qa heal loop summary\n\n| Round | Findings | Issues filed | PRs merged | Time | Status |\n|-------|---------:|-------------:|-----------:|------|-------------------------|\n| 1 | 7 | 7 | 6 | 12m | 1 finding persisted |\n| 2 | 1 | 0 | 0 | 4m | oscillation_detected |\n\nFinal verdict: PARTIAL (1 persistent finding)\n```\n\nInvocation:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-heal-loop.sh\" \\\n --verdict .autospec\u002Fqa-verdict.json \\\n --summary .autospec\u002Fheal-summary.md\n```\n\nSafety guardrails (NOT bypassed by heal mode) — inherit all existing\nautonomy\u002Frelease guardrails:\n\n- Destructive remote actions surface for confirmation (handled by\n `autospec-autonomy-gate.sh`).\n- Per-PR merge still goes through the rebase-and-retest gate.\n- `~\u002F.autospec\u002Fno-heal.flag` exists → heal globally disabled (operator\n escape hatch for runaway loops).\n- `~\u002F.autospec\u002Fstop.flag` (graceful \u002F immediate) terminates the loop at\n the next round boundary.\n\n## --no-heal opt-out\n\nThe heal loop runs by default (issue #711 locks the default-on contract;\nissue #666 introduced it). Four opt-outs revert to discovery-only\nbehavior; all four are equivalent and only post-discovery behavior\ndiffers:\n\n1. `--no-heal` flag.\n2. `--single-pass` flag (alias).\n3. `~\u002F.autospec\u002Fqa-no-heal.flag` operator preference.\n4. `~\u002F.autospec\u002Fno-heal.flag` legacy operator preference (still honored).\n\nWhen any of the four is present, `\u002Fautospec-qa` writes\n`.autospec\u002Fqa-verdict.json` and exits without filing issues or\ndispatching `\u002Fautospec-run`. Triggers are identical for both modes.\nBackwards compatibility: any caller that relied on `\u002Fautospec-qa`\nexiting after discovery must pass `--no-heal`. The\n`.autospec\u002Fqa-verdict.json` schema is unchanged. Existing\n`\u002Fautospec-release` and `\u002Fautospec-sweep` integrations see the post-heal\nverdict, not the pre-heal one — this is the intended improvement.\n\n## Shared loop driver (issue #711)\n\n`qa-heal-loop.sh` adopts the shared loop driver\n`lib\u002Fautospec-loop.sh` (issue #708 \u002F PR #712) for unified\ntermination naming. The four loop-enabled skills — `\u002Fautospec --loop`,\n`\u002Fautospec-refine --continue`, `\u002Fautospec-continue --loop`, and\n`\u002Fautospec-qa` (heal default-on) — share these termination conditions:\n\n- `convergence_clean` — zero release-blocking findings (heal alias:\n `convergence`).\n- `oscillation_detected` — finding-set hash repeats round-over-round.\n- `round_cap_reached` — `AUTOSPEC_HEAL_MAX_ROUNDS` reached.\n- `evidence_based_stop` — `stop_marker` \u002F `STOP:` field in the QA\n verdict.\n- `operator_stop` — `~\u002F.autospec\u002Fstop.flag` or\n `~\u002F.autospec\u002Fqa-heal-stop.flag` (heal alias: `stopped`).\n- `budget_cap_reached` — token or wall-time cap exceeded.\n\nLoop end produces `.autospec\u002Fqa-heal-summary.md` (mirrored from the\nlegacy `.autospec\u002Fheal-summary.md` path) with the same Markdown table\nshape as `.autospec\u002Floop-summary.md` (refine\u002Fcontinue\u002Fautospec --loop)\nso `\u002Fautospec-release` and downstream consumers see structurally\nidentical summaries across all four loop-enabled skills.\n\n## Production incident regression check\n\nWhen QA passes but production breaks, the same bug class tends to leak again the\nnext cycle because nothing in the QA pipeline learns from the incident. The\nregistry `.autospec\u002Fproduction-incidents.json` records every production incident\nand the regression test that proves it cannot reoccur silently. `\u002Fautospec-qa`\nreads this registry on every run and asserts, for each `active` incident:\n\n1. A named `regression_test` file exists.\n2. That test actually runs.\n3. The test is non-trivially assertive (no `expect(true).toBe(true)` or empty\n stub).\n4. The test FAILS when the incident's recorded `mutation` is applied to the\n implementation — proving the test would catch a regression rather than\n passing for unrelated reasons.\n\nMissing any of these four checks emits a finding under category\n`code_health:production_incident_regression_missing` with\n`release_blocking: true` in `.autospec\u002Fqa-verdict.json`.\n\nRegistry schema (one JSON array, one entry per incident):\n\n```json\n[\n {\n \"id\": \"INC-2026-05-28-checkout-double-charge\",\n \"occurred_at\": \"2026-05-28T03:14:00Z\",\n \"failure_mode\": \"concurrent submit creates duplicate Stripe charge\",\n \"feature\": \"checkout\u002Fpayment\",\n \"spec_anchor\": \"docs\u002Fspecs\u002Fcheckout.md#payment\",\n \"regression_test\": \"tests\u002Fregression\u002Fincident-2026-05-28-double-charge.test.ts\",\n \"mutation\": \"remove the `submitting` guard on the Pay button; test must FAIL\",\n \"added_by\": \"\u003Coperator handle>\",\n \"status\": \"active\"\n }\n]\n```\n\n`status` ∈ `active | superseded | wont_test`. Only `active` is enforced.\n`superseded` means the underlying behavior was redesigned out of existence and\nmust cite the replacement spec section. `wont_test` requires explicit\njustification (e.g., \"infra-level only, no test can reach it\") and emits a\nwarning, never a release blocker.\n\nNever silently delete an incident entry. Operators move incidents to\n`superseded` or `wont_test` with a citation\u002Fjustification so the historical\nrecord of why a regression test was added stays auditable. The orchestrator\nruns the helper after the existing verdict computation, similar to other\npost-verdict gates:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-incident-check.sh\" \\\n --registry .autospec\u002Fproduction-incidents.json \\\n --verdict .autospec\u002Fqa-verdict.json\n```\n\nExit 0 means every `active` incident is covered. Exit 1 means at least one\nactive incident is missing coverage and a release-blocking finding has been\nappended to the verdict. The helper validates the registry against\n`schemas\u002Fautospec-production-incidents.schema.json` and writes findings\natomically.\n\n## Post-merge deployed canary prompt\n\nWhen a deployed\u002Fdev URL exists, define the post-merge canary before release:\n\n```text\nFor this feature, list the smallest deployed\u002Fdev workflow set that must run\nafter merge or deploy:\n\n- route or screen\n- representative input\n- expected live API\u002Fbackend path\n- expected visible domain result\n- failure banners that must not appear\n- health probes to run if the canary fails\n- issue label or escalation path for a failed canary\n\nRequired outcome:\n- A missing canary for a backend-backed feature is PARTIAL unless the reliability\n contract explicitly exempts it.\n- A failed canary creates a regression issue with logs, route classification,\n and live evidence.\n```\n\n## No-mock minimum coverage prompt\n\nMocked tests are not enough for backend-backed features:\n\n```text\nFor every spec feature that depends on backend behavior, identify the minimum\nno-mock path that proves real integration:\n\n- one representative happy path,\n- one known fragile backend path or fallback path,\n- one visible success result,\n- one absence-of-generic-failure assertion.\n\nRequired outcome:\n- If no no-mock path exists, update `.autospec\u002Freliability.yml` with the blocker\n and setup action.\n- If the app has only mocked coverage, do not mark the backend-backed feature\n PASS.\n```\n\n## New code intent gate\n\nEvery new component, module, function, endpoint, worker, hook, or test helper\nmust answer why it exists:\n\n```text\nFor this new code unit:\n\n1. Which spec requirement or issue acceptance criterion owns it?\n2. Why is an existing helper, component, service, or test utility not enough?\n3. What is the smallest public contract this unit exposes?\n4. What automated test and, when applicable, live workflow proves it?\n5. What would break if this unit were wrong?\n\nRequired outcome:\n- If there is no spec-linked reason, remove the code or file a scope\u002Fspec issue.\n- If there is an existing helper, prefer reuse over a new abstraction.\n```\n\n## Legacy removal and spec cleanup gate\n\nWhen the current spec, operator direction, or accepted architecture deprecates a\nroute, cache, bucket, storage backend, worker, feature flag, config key, UI path,\nor data source, autospec must remove the legacy surface and its spec\u002Fdocs\nreferences instead of making the deprecated path work again.\n\n```text\nFor each legacy or deprecated surface:\n\n1. What replaced it, and where is that replacement specified?\n2. Which code paths, feature flags, env vars, infrastructure resources, docs,\n tests, fixtures, runbooks, and specs still reference the legacy surface?\n3. Did any smoke\u002Ftest\u002Frepair step try to make the app pass by repopulating,\n restarting, or relying on the deprecated surface?\n4. What data migration, cleanup, or compatibility window is required before\n removal?\n5. Which tests prove the replacement path works and the legacy path is no longer\n used?\n6. Which specs or docs were updated to remove or mark the legacy behavior as\n intentionally unsupported?\n\nRequired outcome:\n- Do not populate deprecated caches, buckets, queues, indexes, or fallback stores\n just to make a live smoke pass.\n- If a deployed environment still depends on a deprecated surface, mark the row\n PARTIAL\u002FFAIL and file an implementation\u002Finfrastructure cleanup issue.\n- Remove stale spec\u002Fdocs references in the same change when implementation\n removes legacy behavior.\n- If compatibility must remain temporarily, document the sunset condition,\n owner, and follow-up issue; tests must still prove the new canonical path.\n```\n\n## Brute-force string heuristics sweep\n\nSweep already-merged code for the LLM-tier RULE_IDs `STRING_MATCH_DOMAIN_LOGIC`\nand `REPEATED_STRUCTURE_AS_CODE` (AGENTS.md `## Implementation-quality contract`).\nThis catches rot that pre-dates the PR-time guardian — substring-on-name\nclassifiers and ≥5-branch ladders that ship as a wall of `if`\u002F`elif`\u002F`switch`\ninstead of a table + dispatcher.\n\nSupported languages: Python, JavaScript\u002FTypeScript, Go, Java, Scala, Rust.\n\n```bash\n# Run from repo root. Emits findings into .autospec\u002Fqa-verdict.json under\n# the category `code_health:brute_force_string_heuristics` and files one\n# auto-implement issue per offender.\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-brute-force-sweep.sh\"\n```\n\nThe sweep:\n\n1. Walks every `*.py`, `*.js`, `*.ts`, `*.jsx`, `*.tsx`, `*.go`, `*.java`,\n `*.scala`, `*.rs` file outside `node_modules`, `.git`, and `dist`.\n2. For `STRING_MATCH_DOMAIN_LOGIC`: counts substring-style checks\n (`.contains(...)`, `.includes(...)`, `in name`, `strings.Contains`,\n etc.) and confirms the file imports a proper-representation library for\n its language — Python `rdkit`\u002F`ast`\u002F`urllib.parse`\u002F`datetime`\u002F\n `ipaddress`\u002F`lxml`\u002F`jsonschema`; JS\u002FTS `URL`\u002F`Date`\u002F`@babel\u002Fparser`\u002F\n `acorn`\u002F`ts-morph`\u002F`zod`\u002F`ajv`\u002F`joi`; Go `net\u002Furl`\u002F`time`\u002F`go\u002Fast`\u002F\n `net.ParseIP`\u002F`encoding\u002Fjson`; Java `java.net.URI`\u002F`java.time`\u002F\n `JavaParser`\u002F`com.github.javaparser`\u002F`javax.validation`; Scala\n `java.net.URI`\u002F`java.time`\u002F`scalameta`\u002Frefined\u002Fcirce; Rust `url::Url`\u002F\n `chrono`\u002F`time`\u002F`syn`\u002F`std::net::IpAddr`\u002F`serde`.\n3. For `REPEATED_STRUCTURE_AS_CODE`: counts repeated branch-shaped lines\n (`if`\u002F`elif`\u002F`case`\u002F`match` arms) and flags any file with ≥5.\n4. Writes one finding line per offender to `.autospec\u002Fqa-verdict.json`\n under category `code_health:brute_force_string_heuristics`, carrying\n `rule_id`, `language`, `file`, `function`, `line`.\n5. Files one `auto-implement,autospec:v2-flow` GitHub issue per offender\n via `gh issue create`. Issue body cites the file, function\u002Fmethod, line,\n and the verbatim RULE_ID directive from AGENTS.md so the implementer\n retry loop has the corrective instruction. Where the offending file has\n no proper-representation library imported, the issue notes\n \"no proper-rep library imported — investigate first\" so the implementer\n does not blindly add a dependency.\n\nErrors in the sweep MUST NOT block the QA verdict; emit findings and\ncontinue. End-to-end regression: after the QA-filed rewrite issues run\nthrough `\u002Fautospec-run`, the offending files no longer trip either\nRULE_ID in the PR-time guardian.\n\n## Bug-class sibling sweep (issue #737)\n\nWhen `.autospec\u002Fqa-verdict.json` carries a `release_blocking: true`\nfinding whose `category` ends in `:bug` (or otherwise matches a\nfingerprintable shape), run `qa-bug-class-sweep.sh` to fan out\nacross the repo for sibling instances of the same pattern class. Goal:\nconsistency by construction — the implementer fixes every matching\ninstance in **one PR**, not N PRs.\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-bug-class-sweep.sh\" \\\n --verdict .autospec\u002Fqa-verdict.json --repo-dir .\n```\n\nThe sweep:\n\n1. Computes a deterministic **pattern fingerprint** over the offending\n line + ±5 context lines (literal-stripped: strings → `\"\"`, numbers →\n `N`). The fingerprint and its sha256 (`pattern_fingerprint`,\n `fingerprint_hash`) are stored on the PARENT finding **at\n finding-time**, not recomputed — this gives pattern drift safety so\n siblings remain resolvable even after the parent line is rewritten.\n2. Runs `git grep -nE \u003Cfingerprint>` over the repo, excluding\n `node_modules\u002F`, `.git\u002F`, and `vendor\u002F`, plus the parent's own\n `file:line`.\n3. For each match, computes a **confidence** score\n `(presence + density_bonus) * specificity` where specificity scales\n with fingerprint length (longer anchors → higher confidence). Matches\n with `confidence >= AUTOSPEC_QA_BUG_CLASS_MIN_CONFIDENCE` (default\n `0.7`) are appended to `findings[]` with\n `category: code_health:bug_class_sibling`, `parent_fingerprint`,\n `confidence`, `file`, `line`. Below-threshold matches land in\n `.autospec\u002Fqa-bug-class-flagged.json` (operator review surface, NOT\n filed as issues).\n4. Applies the verify-first filter\n (`qa-verify-finding.sh --category missing_function`) to every\n candidate sibling. If the bug is already fixed at HEAD for an\n instance, that sibling is dropped silently.\n5. All verdict mutations are atomic (`.tmp` + `mv`) so partial runs\n cannot corrupt the verdict.\n\nPer-class issue filing: `qa-heal-loop.sh` groups findings by\n`parent_fingerprint` when present and files **one `auto-implement` issue\nper pattern class** carrying every instance's `file:line`. Findings\nwithout a fingerprint stay per-finding as before. This is the key\ncontract that turns bug-class detection into a single coordinated fix.\n\n## Verify-first discipline\n\nBefore any cluster emits a finding to `.autospec\u002Fqa-verdict.json`, the cluster\nMUST verify that the symptom still reproduces at current HEAD. This eliminates\nthe dominant false-positive class observed in production: clusters re-flagging\ngaps that landed in a recent PR. Run the shared probe per candidate finding:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-verify-finding.sh\" \\\n --category \u003Cmissing_function|missing_import|failing_test|spec_mismatch|regression> \\\n [--symbol \u003Cname>] [--file \u003Cpath>] [--test-cmd \u003Ccmd>] \\\n [--spec \u003Cpath>] [--impl \u003Cpath>] [--claim \u003Ctext>] [--commit \u003Csha>]\n```\n\nExit 0 means the finding still reproduces (KEEP and emit). Exit 1 means the\nsymptom no longer reproduces (DROP and append to `verified_dropped[]` in the\nQA report). When ingesting prior-cycle findings from a previous\n`.autospec\u002Fqa-verdict.json`, run the same probe; drops go into\n`stale_dropped[]` rather than `verified_dropped[]`.\n\nCluster cross-talk dedup: the QA orchestrator maintains\n`.autospec\u002Fqa-cluster-coverage.json` via the shared coverage helper. Each\ncluster MUST attempt to claim the `(file, spec_section, rule_id)` tuple it is\nabout to scan; a second cluster racing on the same tuple receives exit 1\n(\"already claimed\") and logs the skip as `cluster_skip_dedup`:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fqa-cluster-coverage.sh\" \\\n claim --cluster \u003Cid> --file \u003Cpath> --section \u003Csection> --rule \u003Crule_id>\n```\n\nThe final QA report MUST surface four explicit count fields so the operator\ncan see what the discipline filtered: `findings_emitted`, `verified_dropped`,\n`stale_dropped`, `cluster_skip_dedup`.\n\nAfter cluster fan-out completes, the QA orchestrator MUST run\n`qa-finding-filter.sh` against the merged\n`.autospec\u002Fqa-verdict.json` before any release-skill (e.g.,\n`\u002Fautospec-release`) consumes it. The filter partitions findings into\nverified, stale (re-probed and either refreshed or dropped to\n`verified_dropped[]`), and unverified. Under `AUTOSPEC_QA_STRICT=1`\n(the CI default), any finding lacking `verified_at` causes the QA run\nto FAIL with status `code_health:verify_first_violation`; under\n`AUTOSPEC_QA_STRICT=0` unverified findings are routed to\n`unverified_warnings[]` for operator triage. Cluster agents MUST emit\nfindings via `qa-verify-finding.sh --emit-record \u003Cpath>` so the\nrequired `verified_at`, `verified_by`, and `verify_category` fields are\npopulated by the probe rather than hand-constructed.\n\n## Cluster sizing\n\nThe QA orchestrator's cluster fan-out is a knob, not a constant. When the\nprior QA run dropped ≥30% of candidate findings on verification, prefer **3\nverify-first clusters** over **7 blind clusters** for the next run. A drop\nrate >50% means clusters are re-litigating the same closed gaps rather than\nexploring new surface; shrink the fan-out and let each cluster do deeper\nverification work. This is prose guidance to the orchestrator — no enforcement\nscript — but the rule is non-negotiable for runs whose prior-cycle drop rate\nexceeded the threshold.\n\n## Dogfood detectors driver\n\nWhen QA runs against the autospec repo itself, use `dogfood-detectors.sh` as the authoritative aggregated sweep rather than invoking individual `scripts\u002Fqa-*-sweep.sh` directly. The driver enforces an allowlist of intentional findings and fails on regression.\n\n## Critical self-questioning checkpoint\n\nBefore finalizing the QA report or accepting regenerated tests, stop and answer\nthese questions in the working notes:\n\n1. What could still pass in the current mocked tests while failing for a real\n user on the deployed\u002Fdev environment?\n2. Which user-visible outcome proves the feature worked, independent of DOM\n wiring or request dispatch?\n3. Which backend route, service, queue, bridge, cache, or external dependency am\n I assuming is healthy?\n4. If that dependency fails, is there a tested fallback route or a clear\n actionable user state?\n5. Which button, dropdown, select, text box, validation rule, or error state did\n I not touch because it was inconvenient, slow, or required setup?\n6. Does the test prove the intended domain result, or only that a generic panel\n changed?\n7. What is the single highest-risk missing test I can add now?\n8. Did I search safe deployment\u002Fconfig surfaces deeply enough to distinguish\n missing credentials from stopped infrastructure or a route-specific worker\n failure?\n9. Did I emit proof artifacts that connect the spec, implementation, tests,\n live evidence, and remaining blockers?\n10. Did I challenge duplicated code and require a spec-linked reason for every\n new code unit?\n11. Did I prove at least one critical workflow test fails when the workflow is\n intentionally broken?\n12. Are the proof artifacts fresh for the current commit, spec hash, app URL,\n environment, and test command?\n13. Does every PASS have evidence provenance a reviewer can inspect?\n14. Did browser console and network inspection reveal any unexpected errors?\n15. Did I resolve or file spec contradictions before treating behavior as done?\n16. For stateful features, did I prove the data lifecycle across create, refresh,\n edit, delete, rollback, and navigation?\n17. Is there enough observability to debug a failed canary without exposing\n secrets or PII?\n18. Did I classify every retry, sleep, timeout increase, or flaky rerun instead\n of accepting green-after-retry?\n19. What else could make this generated app unreliable, duplicated, or falsely\n green against the spec?\n20. Did I remove deprecated code paths and stale spec\u002Fdocs references instead of\n reviving a legacy cache, bucket, route, worker, or fallback to make QA pass?\n\nIf any answer identifies a material gap, add the narrowest test for it or file a\nfollow-up issue with reproduction steps. Do not silently leave it as an\nunstated risk.\n\n## Inputs\n\nCollect or infer:\n\n- Spec path or URL.\n- App URL or local run command.\n- Repository path.\n- Test credentials and seed data, if needed.\n- Relevant PR\u002Fissue numbers.\n\nIf the app cannot be run and no URL is available, continue with static\u002Ftest\naudit only, but mark all runtime UI checks `NOT TESTED` with the exact blocker.\n\n## QA prompt\n\nUse this prompt as the audit driver:\n\n```text\nYou are a senior QA engineer, product tester, and spec-compliance auditor.\n\nYour job is to test this application completely from every meaningful scope and\ndirection, and to verify that every feature specified in the spec actually works\nin the running app.\n\nInputs:\n- Spec: \u003Cpaste or link the product\u002Fspec document>\n- App URL or local run command: \u003CURL or command>\n- Repository path, if available: \u003Cpath>\n- Test credentials\u002Fdata, if available: \u003Ccredentials\u002Fdata>\n\nMission:\nCreate and execute a complete verification pass that proves whether the\nimplemented app matches the spec. Do not only inspect code. Run the app and\ninteract with it like a real user. Treat the spec as the source of truth.\n\nRequired testing scope:\n\n1. Spec Traceability\n- Extract every feature, requirement, acceptance criterion, user flow,\n validation rule, permission rule, and edge case from the spec.\n- Build a traceability matrix with requirement, expected behavior, test\n performed, PASS\u002FFAIL\u002FPARTIAL\u002FNOT TESTED result, evidence, and notes.\n\n2. Functional Testing\nTest every user-facing feature end to end: buttons, links, text inputs,\ntextareas, checkboxes, radio buttons, selects, dropdowns, multi-selects, search\nfields, filters, sorting, pagination, tabs, modals, forms, uploads\u002Fdownloads,\nnavigation, save\u002Fedit\u002Fdelete flows, auth\u002Flogin\u002Flogout, and empty\u002Floading\u002F\nsuccess\u002Ferror\u002Fdisabled states.\n\nFor every workflow button or dropdown-backed action, do not stop at clickability\nor request dispatch. Verify the selected values change the real request\npayload\u002Fquery, run a mocked happy path, run a no-mock deployed\u002Fdev smoke path\nwith representative input, assert no live-failure banner appears, and assert a\nreal domain result is visible.\n\nFor every user input element, run the User Input Intent Prompt: identify what\nthe control is for, why it exists, how it should be used, what request\u002Fstate\u002F\nvisible result it should affect, how invalid or rejected input behaves, whether\nit is intentionally decorative\u002Fread-only, and whether running-app evidence proves\nit was implemented and tested correctly.\n\nWhen live backend smoke is blocked by config, credentials, bridge\u002Fqueue errors,\ntimeouts, or stopped services, run the Live Backend Blocker Triage Prompt before\ndeclaring `NOT TESTED`. Search safe config surfaces, do not print secret values,\nclean up temporary credential material, separate passed live paths from failing\nroutes, and classify whether the blocker is credentials, infrastructure health,\nroute mental model, or a route-specific worker\u002Fhandler failure.\n\nCreate or draft the proof artifacts: `.autospec\u002Fproof-matrix.json`,\n`.autospec\u002Freliability.yml`, `.autospec\u002Fcontrol-intent-ledger.json`,\n`.autospec\u002Fmutation-proof.json`, and `.autospec\u002Fcanary-results.json` when a\ndeployed\u002Fdev canary exists. Use them to prevent false PASS results: unclassified\ncontrols, missing backend no-mock coverage, missing mutation proof, duplicated\ncode, or missing code intent keep the result PARTIAL or FAIL until resolved.\nValidate artifacts against their schemas when possible, reject stale artifacts,\nrequire evidence provenance for every PASS, fail unexpected console\u002Fnetwork\nerrors, detect spec contradictions, prove data lifecycle for stateful features,\nrequire observability for backend-backed workflows, classify flakes, and run the\nReliability Exhaustion Loop until all actionable reliability ideas are handled\nor explicitly filed. Run the Legacy Removal and Spec Cleanup Gate whenever a\nworkflow touches a deprecated route, cache, bucket, storage backend, worker,\nfeature flag, config key, UI path, or data source.\n\n3. Form and Validation Testing\nFor every form\u002Finput test valid input, empty input, invalid input, boundary\nvalues, very long text, special characters, whitespace-only values, duplicates,\nrequired-field behavior, error-message clarity, recovery after correction,\nkeyboard submission, disabled submit behavior, and server-side validation.\n\n4. UI and UX Behavior\nVerify text readability, labels, discoverability, visible state changes,\nloading\u002Ferror\u002Fsuccess states, desktop\u002Ftablet\u002Fmobile layouts, and absence of\noverlapping or clipped content.\n\n5. Accessibility\nCheck keyboard-only navigation, focus order, visible focus indicators, input\nlabels, ARIA where needed, screen-reader names for icon buttons, color contrast,\nEscape behavior, and Enter\u002FSpace behavior.\n\n6. Data and State Testing\nVerify persistence after refresh, unsaved-change handling, optimistic update\nreconciliation, delete\u002Fedit propagation, filter\u002Fsearch\u002Fsort state, browser\nback\u002Fforward behavior, and deep links.\n\n7. Negative and Edge Cases\nTest API failure, slow responses, empty datasets, large datasets, unauthorized\naccess, expired sessions, invalid routes, concurrent edits, repeated rapid\nclicks, and refresh during in-progress actions.\n\n8. Backend\u002FAPI Integration\nWhen a backend exists, verify frontend requests match API contracts, API errors\nare handled correctly, storage reflects create\u002Fupdate\u002Fdelete behavior, and\npermissions\u002Fvalidation are enforced server-side.\n\nInclude regression coverage for deployed backend failures such as `502` bridge,\nproxy, queue, or cache misses. If a backend route is known fragile, the UI must\neither recover through a documented fallback route or show a clear actionable\nstate. Mocked endpoint success is not sufficient evidence.\n\n9. Regression and Cross-Feature Testing\nCombine flows: create then search\u002Ffilter\u002Fsort, edit then verify list\u002Fdetail\nviews, delete then verify navigation\u002Fempty states, change settings then verify\ndependent screens, and complete full user journeys.\n\n10. Automated Test Recommendations\nIdentify missing unit, integration, component, E2E, accessibility, and API\ncontract tests. For each missing test, state exactly what it should assert.\n\n11. Reliability and Maintainability Proof\nValidate the reliability contract, proof matrix, control intent ledger,\nduplicate-code guardian findings, mutation\u002Fbreakage proof, post-merge canary,\nno-mock minimum coverage, and new-code intent gate. Treat these as required\nspec-compliance evidence, not optional cleanup.\n\n12. Freshness, Provenance, and Runtime Error Testing\nValidate artifact freshness against the current commit\u002Fspec\u002Fenvironment, require\nreviewable evidence provenance for every PASS, fail unexpected console\u002Fnetwork\nerrors, classify retries\u002Fflakes, and record stale or unverifiable artifacts as\nPARTIAL.\n\n13. Spec, Data, Observability, and Exhaustion Testing\nDetect spec contradictions, prove create\u002Fedit\u002Fdelete\u002Frefresh\u002Frollback\u002Fnavigation\nlifecycles for stateful features, verify observability for backend-backed\nworkflows, and run the Reliability Exhaustion Loop until no new actionable\nquality ideas remain.\n\n14. Legacy Removal and Spec Cleanup\nIdentify deprecated routes, caches, buckets, fallback stores, workers, config\nkeys, UI paths, and data sources. Verify the canonical replacement works, the\nlegacy path is not repopulated or relied on, stale specs\u002Fdocs\u002Ftests are removed\nor marked unsupported, and any temporary compatibility has a sunset issue.\n\nExecution rules:\n- Do not assume a feature works because code appears to exist.\n- Do not mark PASS without concrete evidence.\n- Mark untestable items NOT TESTED and explain the blocker.\n- Mark spec mismatches FAIL even if the implementation seems reasonable.\n- Mark ambiguous spec items AMBIGUOUS and propose expected behavior.\n- Capture screenshots, logs, console errors, network failures, or command output\n where useful.\n- Continue until every spec item has a status.\n\nFinal report:\n# QA Verification Report\n## Summary\n- Overall result: PASS \u002F FAIL \u002F PARTIAL\n- App\u002Fversion\u002Fcommit tested:\n- Environment:\n- Main risks:\n## Spec Traceability Matrix\n| Requirement | Expected Behavior | Test Performed | Result | Evidence | Notes |\n|---|---|---|---|---|---|\n## Proof Artifacts\nList `.autospec\u002Fproof-matrix.json`, `.autospec\u002Freliability.yml`,\n`.autospec\u002Fcontrol-intent-ledger.json`, `.autospec\u002Fmutation-proof.json`, and\n`.autospec\u002Fcanary-results.json`, or state why each artifact was drafted inline\ninstead of written.\n## Artifact Freshness and Evidence Provenance\nList commit\u002Fspec\u002Fenvironment\u002Ftest-command freshness checks and the exact\nevidence cited for each PASS row.\n## Runtime Error and Flake Classification\nList console errors, network failures, runtime warnings, retries, sleeps,\ntimeouts, flake classification, and fixes or quarantines.\n## Spec Contradictions\nList contradictory or untestable requirements, UI\u002FAPI\u002Fspec mismatches, proposed\nresolution, and follow-up issue or spec edit.\n## Data Lifecycle Proof\nList create, refresh, edit, delete, rollback, idempotency, navigation, and\nconcurrency evidence for stateful workflows.\n## Observability Contract\nList correlation IDs, health probes, error boundary behavior, backend timing,\nlogs, user-safe messages, and any missing diagnostic hooks.\n## Reliability Exhaustion Loop\nList each \"what else could make this unreliable, duplicated, or falsely green?\"\nanswer and how it was handled.\n## Legacy Removal and Spec Cleanup\nList deprecated surfaces found, replacement path, code\u002Fconfig\u002Fdocs\u002Fspec\u002Ftests\nremoved or updated, data cleanup or migration action, compatibility window if\nany, and evidence that QA did not revive the legacy path.\n## Bugs and Gaps\nFor each issue include severity, area, spec reference, steps to reproduce,\nexpected, actual, evidence, and suggested fix.\n## UI Control Coverage\nList every tested text input, select\u002Fdropdown, button, form, navigation element,\nmodal, table\u002Flist, and other control.\n## Validation Coverage\nList every validation rule tested, including valid, invalid, boundary, and\nrecovery behavior.\n## User Input Intent Review\nList every input-like control and answer: what it is for, why it exists, how a\nuser should use it, expected request\u002Fstate\u002Fresult effect, invalid\u002Frejected-input\nbehavior, decorative\u002Fread-only status if applicable, and evidence that it was\nimplemented and tested correctly.\n## No-Mock Deployed Smoke Coverage\nList every deployed\u002Fdev smoke workflow, live URL\u002Fconfig used, representative\ninput\u002Fdata, result, and blocker. Any required `NOT TESTED` no-mock smoke row\nforces Overall result: PARTIAL unless the QA contract explicitly exempts it.\n## Live Backend Blocker Triage\nFor each blocked live path, list safe config sources checked, secret names or\ncredential sources referenced without values, temporary credential cleanup,\nhealth\u002Fstatus\u002Ffleet probes, passed real-data endpoints, remaining failing route\nor subject, root-cause classification, and next operator or implementation\naction.\n## Presentational Control Classification\nList each example chip, shortcut, preset, or token-like control as\ndecorative\u002Fpresentational or workflow control, with the evidence or follow-up\nissue\u002Ftask.\n## Duplicate-Code Guardian\nList duplicated or near-duplicated components, helpers, validators, API clients,\nrequest wrappers, error banners, fixtures, and test utilities, with reused\nalternatives or follow-up fixes.\n## Mutation and Breakage Proof\nList critical workflow tests, the simulated break or mutation, expected failing\nassertion, observed result, and strengthening performed if the test stayed green.\n## Benchmark Overfit and Test Leak\nList tests whose fixtures hard-code public benchmark identifiers, use a fixed\nfirst-N slice, assert exact benchmark answer-key values, lack a randomized or\nproperty-based sibling, or reuse the same fixture as training\u002Fselection signal.\nFor each: test path, leaked dataset, failure mode (1-6 from the gate), and\nrequired remediation.\n## Outsourced Implementation\nList third-party API\u002FSDK calls or cached external payloads where the spec\nrequired the product to implement the action locally. For each: spec\nacceptance criterion, offending client\u002FURL, matched signal(s) from the gate\n(1-6), and remediation (replace remote call with in-repo algorithm; keep\nexternal service only as optional comparator behind a flag).\n## Post-Merge Deployed Canary\nList required canary workflows, representative input, deployed\u002Fdev URL, expected\ndomain result, result, and regression issue\u002Faction for failures.\n## New Code Intent Gate\nList new code units reviewed, owning spec\u002FAC, reason existing helpers were not\nenough, public contract, proof test, and what would break if wrong.\n## Accessibility Findings\nInclude keyboard, focus, labels, contrast, ARIA, and screen-reader concerns.\n## Cross-Browser \u002F Responsive Findings\nInclude desktop, tablet, and mobile behavior if applicable.\n## Automated Test Gaps\nList exact tests to add before the app is fully protected.\n## Final Verdict\nState whether the app satisfies the spec and the minimum fixes required before\nrelease.\n```\n\n## Regeneration loop\n\nAfter the audit:\n\n1. Convert every `FAIL`, `PARTIAL`, `NOT TESTED`, and high-risk `AMBIGUOUS`\n traceability row into one of:\n - a product bug fix,\n - a regenerated\u002Fstrengthened automated test,\n - a follow-up GitHub issue when implementation scope is too large.\n A required no-mock deployed smoke row that remains `NOT TESTED` must produce\n an environment setup issue\u002Ftask, a QA contract update, or an operator-blocker\n line with exact rerun instructions.\n Any input-like control with an unanswered User Input Intent Prompt must\n produce a strengthened test, implementation fix, spec clarification, or\n follow-up issue.\n A blocked live-backend row must run the Live Backend Blocker Triage Prompt\n first and then produce either real no-mock smoke evidence or a classified\n credentials\u002Finfrastructure\u002Froute\u002Fworker blocker.\n Missing proof artifacts, unclassified controls, duplicated generated code,\n missing mutation\u002Fbreakage proof, missing canary, missing no-mock minimum\n coverage, and unanswered new-code intent gates must each produce a\n strengthened test, implementation fix, reliability contract update, or\n follow-up issue.\n Stale artifacts, missing evidence provenance, unexpected console\u002Fnetwork\n errors, unresolved spec contradictions, missing data lifecycle proof, missing\n observability for backend-backed failures, unclassified flakes, and any\n actionable Reliability Exhaustion Loop answer must also produce a fix,\n stronger test, proof update, contract update, or follow-up issue.\n Any deprecated surface still referenced by code, config, specs, docs, tests,\n fixtures, infrastructure, or live-smoke repair steps must produce removal,\n spec cleanup, migration work, or a sunset follow-up before PASS.\n2. Regenerate tests in the narrowest existing harness:\n - unit tests for pure functions and validation rules,\n - integration\u002FAPI tests for server-side validation and persistence,\n - component tests for isolated UI states,\n - E2E\u002FPlaywright tests for user journeys, controls, accessibility, and\n cross-feature behavior.\n3. Preserve or strengthen assertions. Never replace a specific assertion with a\n weaker smoke assertion.\n4. Run the relevant test commands and the repo's validation command.\n5. Repeat until the traceability matrix has no unexplained gaps or the remaining\n gaps are filed as issues with reproduction steps and evidence.\n\n## QA verdict artifact\n\nAt the end of every audit run (including aborted runs), write\n`.autospec\u002Fqa-verdict.json` as the machine-readable result. Downstream\nskills — notably `\u002Fautospec-release` — read this file as the authoritative\ngate signal instead of re-parsing the prose report.\n\nSchema:\n\n```json\n{\n \"verdict\": \"PASS|PARTIAL|FAIL\",\n \"head_sha\": \"\u003Cgit rev-parse HEAD at run start>\",\n \"generated_at\": \"\u003CISO-8601 UTC>\",\n \"live_app_proof\": true,\n \"artifacts\": [\"path\u002Fto\u002Fscreenshot.png\", \"path\u002Fto\u002Fnetwork-trace.har\"],\n \"findings\": [\n {\n \"category\": \"benchmark_overfit|outsourced_implementation|no_mock_smoke|live_backend_blocker|mutation_proof_missing|spec_contradiction|duplicate_code|presentational_misclassified|legacy_residue|new_code_intent|accessibility|cross_browser|visual_fidelity|automated_test_gap|other\",\n \"release_blocking\": true,\n \"status\": \"PASS|PARTIAL|FAIL|NOT_TESTED\",\n \"summary\": \"\u003Cone-line description>\",\n \"evidence\": \"\u003Cpath or pointer to artifact, report section, or issue>\"\n }\n ]\n}\n```\n\nRules:\n\n- `live_app_proof` is `true` ONLY if at least one interaction artifact\n (screenshot, DOM snapshot, network trace, recorded session) was captured\n against a booted app whose commit matches `head_sha`. Otherwise `false`.\n- `release_blocking` defaults TRUE for:\n - `benchmark_overfit` with failure mode 6 (training-on-test leak),\n - `outsourced_implementation` matching signal 1 (implementation verb\n satisfied by remote call), signal 2 (benchmark\u002Fcomparator collision),\n or signal 6 (reimplementation directive),\n - `no_mock_smoke` on a required path with any non-PASS status,\n - `live_backend_blocker` unresolved,\n - `mutation_proof_missing` on a critical workflow,\n - `spec_contradiction` unresolved,\n - `legacy_residue` referenced by current user-facing docs.\n Other categories default FALSE; promote to TRUE only when the finding\n documents a user-visible regression, data loss, security exposure, or\n violated spec requirement.\n- Write atomically: `.autospec\u002Fqa-verdict.json.tmp` then `mv` to the final\n path. Chmod 644. Always overwrite — staleness is checked by `head_sha`,\n not mtime.\n- If the audit aborts before completion, still write the file with\n `verdict: \"FAIL\"` and one finding describing the abort reason. Never\n leave a stale prior verdict in place to be misread as the current run.\n\n## Output contract\n\nReturn:\n\n- QA report path or inline report.\n- Tests added\u002Fchanged.\n- Product bugs fixed, if any.\n- Follow-up issues filed or drafted.\n- Proof artifacts written or drafted.\n- Reliability contract, control ledger, mutation proof, canary, duplicate-code,\n and new-code intent status.\n- Commands run and results.\n- Remaining risks.\n\n## Stop mode\n\nIf the request is exactly `stop` or `stop` plus `--\u003Cword>` flags after\nnormalization, dispatch to:\n\n```bash\nbash \"${AUTOSPEC_SCRIPTS_DIR:-$HOME\u002F.autospec\u002Fscripts}\u002Fautospec-stop.sh\" \u003Cargs>\n```\n\nPrint the helper output and stop. Do not run the QA audit.\n\n## Harness-aware handoff\n\nLoop dispatch uses `lib\u002Fautospec-harness-detect.sh` (issue #723) to\nresolve the active AI harness and pick the canonical `\u002Fautospec --autonomous`\ninvocation form:\n\n- Claude Code → `claude \"\u002Fautospec\" \"--autonomous\" \"$PROMPT\"`.\n- Codex CLI → `codex exec --skip-git-repo-check \"\u002Fautospec --autonomous $PROMPT\" \u003C\u002Fdev\u002Fnull` (the \u003C\u002Fdev\u002Fnull closes stdin — without it codex exec hangs on an open stdin, issue #3380).\n- OpenCode → `opencode \"\u002Fautospec\" \"--autonomous\" \"$PROMPT\"` (best-effort).\n\nDetection order: `AUTOSPEC_HANDOFF_DISPATCHER_KIND` env override → skill-mount\nprobe (`~\u002F.claude\u002Fskills` \u002F `~\u002F.codex\u002Fprompts` \u002F `~\u002F.config\u002Fopencode\u002Fagent`) →\nPATH probe. Missing dispatcher exits 3 with\n`code_health:loop_handoff_no_dispatcher_for_harness`.\n",{"name":5,"description":7},"main","9e7f04357ff46ab731d4f56a4ac5ca5449c13bb0","skills\u002Fautospec-qa",1,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec","https:\u002F\u002Fgithub.com\u002Fberlinguyinca","Love to lead, code, cook and contribute to open source and believe that you can learn anything you set your mind too.\r\n","2026-11-11 07:09:35",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add berlinguyinca\u002Fautospec --skill autospec-qa",{"tool":63,"command":64},"bunx","bunx skills add berlinguyinca\u002Fautospec --skill autospec-qa",{"tool":66,"command":67},"pnpm","pnpm dlx skills add berlinguyinca\u002Fautospec --skill autospec-qa","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002FSKILL.md",true,[71,77,81,85,89,93,97,101,105,109,115,119,123,127,131,135,141,145],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"clusters\u002Faccessibility-and-responsive.md","REFERENCE","参考文档",17382,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Faccessibility-and-responsive.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"clusters\u002Fbackend-integration.md",1177,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Fbackend-integration.md",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"clusters\u002Fbenchmark-and-outsourcing.md",1027,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Fbenchmark-and-outsourcing.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"clusters\u002Ffunctional-coverage.md",1257,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Ffunctional-coverage.md",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"clusters\u002Flegacy-and-cleanup.md",1092,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Flegacy-and-cleanup.md",{"path":94,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":95,"sourceHtmlUrl":96},"clusters\u002Fproduction-incidents.md",998,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Fproduction-incidents.md",{"path":98,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":99,"sourceHtmlUrl":100},"clusters\u002Freliability-contract.md",1397,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Freliability-contract.md",{"path":102,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":103,"sourceHtmlUrl":104},"clusters\u002Fspec-traceability.md",1147,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fclusters\u002Fspec-traceability.md",{"path":106,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":107,"sourceHtmlUrl":108},"codex\u002Fprompt.md",82563,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fcodex\u002Fprompt.md",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":114},"install.sh","SCRIPT","脚本",7207,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Finstall.sh",{"path":116,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":117,"sourceHtmlUrl":118},"opencode\u002Fagent.md",82855,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fopencode\u002Fagent.md",{"path":120,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":121,"sourceHtmlUrl":122},"README.md",1334,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002FREADME.md",{"path":124,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":125,"sourceHtmlUrl":126},"scripts\u002Fgen-layout-guardrails.mjs",2788,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fscripts\u002Fgen-layout-guardrails.mjs",{"path":128,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":129,"sourceHtmlUrl":130},"scripts\u002Fqa-visual-findings.sh",2945,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Fscripts\u002Fqa-visual-findings.sh",{"path":132,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":133,"sourceHtmlUrl":134},"tests\u002Ffixtures\u002Fscreenshot-audit.json",300,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Ftests\u002Ffixtures\u002Fscreenshot-audit.json",{"path":136,"resourceType":137,"resourceTypeDesc":138,"sizeBytes":139,"sourceHtmlUrl":140},"tests\u002Fgen-layout-guardrails.bats","OTHER","其他",1011,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Ftests\u002Fgen-layout-guardrails.bats",{"path":142,"resourceType":137,"resourceTypeDesc":138,"sizeBytes":143,"sourceHtmlUrl":144},"tests\u002Fqa-visual-findings.bats",3074,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Ftests\u002Fqa-visual-findings.bats",{"path":146,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":147,"sourceHtmlUrl":148},"uninstall.sh",2079,"https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-qa\u002Funinstall.sh",[150,161,170,179,205,228],{"skillNo":151,"name":152,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":158,"publishedAt":44},"01M71RJHYMKPTC9AAPXWQ6F4RT","trio-pass-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-trio-pass\u002FSKILL.md",[155],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[159,160],"trio","trio pass skill",{"skillNo":162,"name":163,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":44},"01M71RJFBQ1KAF9XM3T3Y4VMSK","duo-pass-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-duo-pass\u002FSKILL.md",[166],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},[168,169],"duo pass skill","duo",{"skillNo":171,"name":172,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":44},"01M71RJDT1TB3P9TRWR6A534FB","duo-divergence-skill","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Flockstep-duo-divergence\u002FSKILL.md",[175],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},[177,169,178],"duo divergence skill","divergence",{"skillNo":180,"name":24,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":187,"publishedAt":44},"01M71RJAC4NNEQSYBDSY3NZS73","Use when the user wants to ship a feature end-to-end across multiple commits — bootstraps repo if missing, brainstorms a design spec, decomposes into linked GitHub issues, or splits an existing spec into issues, then runs an autonomous implementation loop with auto-merge.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec\u002FSKILL.md",[184],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[24,188,189,190,191,192,193,194,32,195,196,197,198,199,200,201,202,203,204,36],"ship a feature","end","issues","design","autonomous","auto","loop","across","design spec","merge","ship","implementation loop","github issues","feature","commits","repo","missing",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":44},"01M71RJ4F9HT8PT26CKNM9XE1M","autospec-upgrade","Use when the user wants to upgrade an Angular, Next.js, or React project to the latest official versions safely — by locking observable behavior before touching versions, upgrading one major at a time with official codemods, and gating completion on mutation score rather than coverage theater.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-upgrade\u002FSKILL.md",[],[212,24,213,214,215,216,217,218,219,32,220,221,222,223,36,224,225,226,35,227],"autospec upgrade","upgrade","mutation","coverage","official","project","time","gating","angular","react","next","at","Next.js","one","with","latest",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":239,"publishedAt":44},"01M71RJ28FJ4PM6DXHB7T5CF8H","autospec-ui-audit","Use when a React Router application needs a deterministic whole-site route inventory before UI, UX, navigation, or evidence auditing begins.","https:\u002F\u002Fgithub.com\u002Fberlinguyinca\u002Fautospec\u002Fblob\u002Fmain\u002Fskills\u002Fautospec-ui-audit\u002FSKILL.md",[234],{"categoryNo":235,"categoryName":236,"taxonomyType":237,"taxonomyTypeDesc":238},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[240,24,29,241,40,36,242,243,244,245,246,247,248,249,250,221,251,32,252],"ui audit","autospec ui audit","inventory","evidence","deterministic","route","ux","site","react router","navigation","application","needs","router"]