Pular para conteúdo

AUR-014: Versionar standard de code review

Documento histórico do board. Pode descrever componentes removidos; para uso atual, consulte o guia do produto.

This is a research and policy-data card. It does not ship a scanner, review engine, approval service, or publication adapter. It fixes a versioned catalog that later review cards can consume. The observable behavior is the bounded, offline acceptance lint in tests/acceptance/AUR-014.sh.

Behavior

tests/acceptance/AUR-014.sh with selector AC-001 reads the existing research baseline and standards/code-review/cases.yaml. It checks, without a network request, that each of the nine declared controls resolves exactly once to:

  1. an official source with an allowlisted HTTPS host, version, ISO date, and current status;
  2. one positive case whose expected verdict is pass;
  3. one negative case whose expected verdict is fail; and
  4. a local, non-empty fixture that names the matching control and is distinct from every other case fixture.

The acceptance program runs its own bounded synthetic self-tests before checking the repository catalog. Those tests prove that missing sources, withdrawn sources, non-allowlisted URLs, inverted verdicts, reused fixtures, identical fixtures, missing research, and missing controls are detected.

Contract

  • standards/code-review/cases.yaml is the sole machine-readable catalog.
  • The catalog contains exactly one row for each AUR-014 control: CR-EVD-001 through CR-EVD-003, CR-REV-001 through CR-REV-005, and CR-GATE-001.
  • A fixture path must remain below standards/code-review/, must be a regular local file, must contain its rule ID, and must not be reused by another case.
  • positive means expect: pass; negative means expect: fail.
  • Source URLs are checked as text against the allowlist embedded in the sealed acceptance program. No URL is fetched, and a citation is not evidence of external certification or conformity.
  • The crosswalk in standards/code-review/README.md records the card, AC, and mutation for every row. The card remains data-only; consumers implement behavior in dependent cards.

Limits and compatibility

The catalog is bounded to 256 KiB by the acceptance program and uses only local fixtures. It does not run arbitrary fixture content, execute source code, or grant network, credential, write, or publication capabilities. Changes outside the AUR-014 paths are not part of this contract.

The delivery of this card follows the current lightweight process: one human-authored commit, the card acceptance command, and an independent validation by the coordinator. The retired multi-reviewer and candidate identity ceremony is not a behavior delivered by this card.

Example (no secret)

With no network access or secret material:

$ tests/acceptance/AUR-014.sh AC-001
{"card":"AUR-014","scenario":"AC-001","result":"pass","controls":9,"rules":9,"cases":18}

The card's containerized command is:

$ ./.board/bin/oci-run --profile bootstrap-readonly-v1 --card AUR-014

Diagnosis

  • AUR-014/AC-001/missing-standard-dir or missing-catalog means the versioned catalog is absent from standards/code-review.
  • AUR-014/AC-001/missing-rule-case means a declared control has no catalog row, or the catalog could not be read as the bounded YAML subset.
  • duplicate-rule, missing-source, missing-version, missing-source-url, missing-source-date, or withdrawn-source identifies a source metadata defect in a catalog row.
  • source-url-not-allowlisted means the citation is not an HTTPS URL on an allowlisted primary-source host.
  • missing-positive-case, missing-negative-case, bad-case-kind, verdict-mismatch, missing-assert, missing-fixture, fixture-not-bound-to-rule, fixture-reused, or fixture-not-distinct identifies a case or fixture defect.
  • AUR-014/AC-001/infrastructure: ... is reserved for missing host tools, unreadable inputs, or an unavailable execution environment. It is never a behavioral pass or RED result.