compliance
Post-QA hardening — detects task type (code, docs, research, legal, content, infra) and applies the matching verification checklist before archiving.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Post-QA hardening — detects task type (code, docs, research, legal, content, infra) and applies the matching verification checklist before archiving.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Schema and migration semantics for /dr-doctor — thin one-liner contract, 6-pass migration, data-loss safety, conflict resolution. Loaded by self-heal.
Core Datarim rules. Load this entry first, then only the fragment needed for paths, storage, numbering, backlog, routing, or archive behavior.
Testing pyramid, frameworks, mocking. Load first; then the fragment for the active gate (live smoke, silent failure, bats, legacy triage).
Preserve Datarim task continuity while orchestrated Claude Code or Codex sessions compact or clear context at deterministic pressure thresholds.
Immutability contract for all pipeline stages: artefact freeze, V-AC parity, non-code parity, anti-tautological rule, and return-to-source transition.
Init-task artefact: verbatim operator brief + append-log, mandatory read by every pipeline command. Source of truth for operator intent.
| name | compliance |
| description | Post-QA hardening — detects task type (code, docs, research, legal, content, infra) and applies the matching verification checklist before archiving. |
| model | inherit |
| current_aal | 2 |
| target_aal | 3 |
Compliance is the final quality gate before archiving. It verifies that the work meets all stated requirements and standards. The checklist adapts to the task type.
When a finding (Low / Medium severity) surfaces during compliance and a clean deferral target exists (a successor task that already owns the same surface), the default reflex is Path A: «document as caller-side contract, hand off to successor». This is the safe choice for high-blast-radius findings or those without a clean inline reduction.
But Path A carries a hidden cost: caller-side contract is invisible closure debt. The successor task carries the obligation, but the obligation is no longer linked to the original finding's context — the operator has to re-derive why the caller-side handoff exists when the successor task starts. If the successor expands into a multi-finding scope, the original handoff item silently grows in importance.
Rule of thumb — prefer Path B (inline-ship) when ALL of the following hold:
When any condition fails, Path A is correct. When all four hold, Path B is the lower-friction path — the operator gets one fewer cross-task handoff to track, and the successor task's scope is provably narrower at archive time.
Operator override is the canonical escape hatch. If compliance default-routes to Path A but the operator wants Path B (or vice versa), the override carries via --focus-items invocation of /dr-do — see Layer 3b FAIL-Routing CTA. Each override round MUST land in the init-task append-log (FB-2 / FB-5 traceability).
Source: ARAS-0006 archive — F-2 (ReadlinePrompt deferral) and F-3 (caller-side canonicalize) initially Path A at compliance v1/v2; both operator-overridden to Path B in subsequent /dr-do rounds, closing ARAS-0024 obligations #1 and #2. Net effect: successor task's scope reduced from 3 items to 1. Second source: TUNE-0264 archive — PASS_WITH_NOTES (two functions slightly over 50-line cap) closed inline at /dr-compliance under Path B; accepted-risk register stayed empty by design.
Read datarim/tasks.md and datarim/activeContext.md to determine task type:
| Type | Indicators | Checklist |
|---|---|---|
| Code | Modified source code files (.js, .ts, .py, etc.) | Software Checklist (7 steps) |
| Documentation | Modified .md files in docs, guides, README | Documentation Checklist |
| Research | PRD mentions research, analysis, literature | Research Checklist |
| Legal | PRD mentions legal, compliance, terms, policy | Legal Checklist |
| Content | Modified posts, articles, blog content | Content Checklist |
| Infrastructure | Modified Docker, CI/CD, IaC, deploy configs | Infrastructure Checklist |
| Mixed | Multiple types | Apply relevant checklists from each type |
/dr-do. When the AC genuinely cannot be measured yet (blocked on an external dependency, e.g. tooling not yet installed on the target host), defer it explicitly using the four-field waiver shape in ${DATARIM_RUNTIME:-$HOME/.claude}/templates/coverage-deferral-clause.md (status, gating dependency, follow-up condition, timestamp + owner) rather than carrying it forward as unstructured prose. Source: prior incident — AC-7 (≥80% line coverage) was carried as «presumed met» through /dr-qa PASS_WITH_NOTES; Compliance had to install the coverage tool and measure (actual 91.5%) to close the gap.claude -p, gh, aws, …) and act on its output, Compliance MUST NOT pass it on a mock-only suite. Verify per $HOME/.claude/skills/testing/live-smoke-gates.md § Gate 7: (a) the real entrypoint (__main__/systemd ExecStart/cron) actually reaches the declared function — call-graph grep + runtime probe, an orchestrator/lane reachable only from tests is dead-code-in-prod ⇒ NON-COMPLIANT → /dr-do; (b) one live run of the agent against the real tool was performed, with the captured real output + observed side-effect recorded in the report. A kill-switch-OFF exit-0 probe proves the agent does nothing and does NOT satisfy this gate; an evidence_type: empirical wish marked met on mocks alone is a hard finding. Source: prior incident — orchestrator + repair lanes fully unit-tested but never wired to cli.main; claude -p never ran in prod; QA passed on mocks and proposed archive; operator caught the unwired entrypoint.$HOME/.claude/skills/testing/live-smoke-gates.md § Gate 9. An unrelated setup error must be classified HARNESS_INVALID, not caught. Missing attribution evidence is NON-COMPLIANT and cannot be carried as notes.23505, P2002, or another unique-error family to a domain result, require an exact named constraint or exact normalized column signature plus runtime-shaped unit, real boundary, intended-positive, and unrelated-negative evidence per $HOME/.claude/skills/testing/SKILL.md § Unique-Violation Domain Normalization. Unknown explicit names fail loud without column fallback. Require real-database evidence when driver/schema metadata determines the classification. A mock-only or broad-family mapping is NON-COMPLIANT, never PASS_WITH_NOTES.$HOME/.claude/skills/testing/SKILL.md § Ambient-Reaper Masking in Timing-Sensitive Mutation Gates: the test must disable the reaper, assert on a guard-unique signal, or prove the effect preceded the reaper's fire window. Source: prior incident — a shutdown-guard mutation gate passed because a background reaper produced the same termination regardless of whether the guard fired.ruff check src/ scripts/ but not tests/), and compliance finds the unscoped directories dirty, recommend widening the CI scope to the full tree (ruff check . or explicit src/ tests/ scripts/) as part of the cleanup. Compliance is the wrong place to discover a narrowly-scoped linter — a narrow CI scope produces avoidable cosmetic notes in every QA cycle. Fix the scope at the source, not just the dirty files.git log --oneline <base>..HEAD -- <failing-test-file>. If the violation predates the task (none of the task's commits touched the failing file), document it as "pre-existing branch issue, not introduced by task commit" and do NOT treat it as a task-scope blocking verdict. The task's own diff must be clean — failures from unrelated branch history or parallel-session dirty files are advisory, not verdicts.skills/ scope is English-only", "agents/ scope has no private IDs"). When such a test fails, do not hand-write a discrimination note each time. Run the deterministic git-based classifier with the failing test's scope directory:
bash "${DATARIM_RUNTIME:-$HOME/.claude}/dev-tools/classify-bats-failure-scope.sh" \
--repo <framework-repo> --base <base-ref> --scope <scope-dir> [--scope <scope-dir> ...]
The classifier runs git log <merge-base>..HEAD -- <scope-dir> per scope. A scope with zero task commits in the range is labelled pre-existing (exit 0) — the failure is foreign / parallel-session noise; record the classifier's verdict verbatim and do NOT treat it as a task-scope block. A scope that did receive task commits is labelled regression (exit 1) — it stays a real, blocking regression and a real regression is never masked. The helper fails closed (exit 2) when a scope's git range cannot be evaluated, so an undeterminable scope is never auto-classified as foreign. This replaces the per-archive manual discrimination note for regression-invariant failures; the per-file manual check above still applies to failures that are not scope-shaped.Prior incident: two test failures traced to pre-task commits and foreign dirty hunks — neither introduced by the task under compliance review. Recurrence: the same hand-written discrimination note for a regression-invariant test whose scope had no task commits surfaced repeatedly across tasks until it was made deterministic via the classifier above.
git cat-file -t <sha>; if the object is absent locally, run git ls-remote origin and git fetch origin <branch> read-only, then verify the diff against FETCH_HEAD. A SHA absent both locally and on the remote is a genuine fabrication finding — NON-COMPLIANT. A SHA absent locally but present on the remote branch is the expected stale-clone case in a remote-first project (the work was pushed from another machine and the local clone never fetched): fetch read-only and verify the actual diff — never block, never reject. Verify against FETCH_HEAD, do not check out, so a shared clone parked on another task's branch stays undisturbed.Prior incident: a QA report cited two commit SHAs invalid on the local clone (git cat-file reported them as unknown objects); both resolved on the remote feature branch and the implemented work was real — the local clone was simply stale in a remote-first workflow. Compliance fetched the branches read-only and verified the diffs against FETCH_HEAD.
scripts/lib/*.sh) or skill (skills/*/SKILL.md), the change is live only where it was committed. Run the shared detector and surface its output verbatim so multi-machine consumers are reminded to update each install: bash "${DATARIM_RUNTIME:-$HOME/.claude}/dev-tools/check-stale-runtime.sh" --repo <framework-repo> --range <base>..HEAD. Single source of truth (same script as /dr-archive Step 0.48); advisory only — it never gates the compliance verdict.git-only). Before reporting any apparent change in PR diff vs origin/<base> as a "regression", check whether the diff is a side-effect of origin/<base> advancing past the branch's merge-base rather than a branch-side edit. If git diff <merge-base>..HEAD -- <file> is empty for a file that nonetheless appears in git diff origin/<base>..HEAD -- <file>, simulate the actual 3-way merge: git merge-tree $(git merge-base HEAD origin/<base>) HEAD origin/<base>. If the simulated tree preserves the upstream change in question, the apparent diff is a no-op on merge — record this in the report and do NOT block the archive on a rebase requirement. Source: prior incident — a feature PR appeared to revert an upstream baseline-hardening fix that landed mid-flight; merge-tree simulation confirmed the fix was preserved by 3-way merge, deflating a needless rebase cycle.base-SHA reconciled <old>→<new> after rebase on <date>), leaving the originally-authored value intact for provenance. Rewriting the header destroys the record of what the plan was actually written against; an inline annotation preserves it while making the current base explicit. Source: prior incident — a rebased task's stale plan-header base-SHA was raised as a defect when it was benign drift; the correct move was a non-destructive inline reconciliation note, not a history rewrite.cta-format § Loop guard escalates after 3 same-layer fails. The default automatic re-run between attempts 1 and 2 is appropriate only when the verdict could plausibly change without external action — for example, when a flaky test was re-run, when an upstream timing dependency might have caught up, or when the operator may have acted between attempts.
When a probe set is deterministic (gh pr view PR states, git rev-parse origin/main HEAD, live /health endpoints, validator stdout) AND state delta vs the previous attempt is empty across all probes, attempt 2 carries zero information. The verdict cannot change without operator action.
In that case Compliance MUST, on attempt 2:
Anti-pattern caught by this rule: identical NON-COMPLIANT verdicts at v1 + v2 produced by re-running the same gh pr view / curl /health set 23 minutes apart with no merge in between. The runtime probes are cheap, but the compliance turn (context, narration, validator append-log) is not — and the operator gets a noisy «attempt 2 of 3» banner that obscures the actual blocker.
Source: prior incident — a multi-repo task ran compliance v1+v2 within 23 minutes; both returned identical Layer-4 NON-COMPLIANT verdicts with state delta ∅ on all 5 runtime probes (PR states, main HEAD, live /health, expectations validator). Attempt 3 resolved only when the operator explicitly delegated the blocking mechanical action under FB-1..FB-5 + autonomous-ops authorization, not via further probe re-runs. Provenance: see documentation/how-to/evolution-log.md for the archive entry that motivated this rule.
When the task ran the /dr-auto L1 doc-only fast-path and produced a qa-stub artefact (datarim/qa/qa-stub-{TASK-ID}.md), that stub satisfies the QA-presence requirement for this compliance run. Compliance MUST NOT emit the "QA report absent" advisory for this class. Verify only that the stub file exists and records at least the style/banlist check and the cross-reference grep outcomes. Any other task class (code, infra, research, content, legal, or a doc task that did not go through the fast-path) still requires a full /dr-qa report; absence of that report remains an advisory as before.
/dr-prd, NOT at /dr-do. Inventory mismatches caught late cost creative/planning effort. Example: .meta planned 13 repos when only 7 existed in the GitHub org.name field, asset set, deploy-script target path, directory structure) across ALL org repos — not only the same-named one. A same-name repo that exists but does not reproduce the live build is a false source; the real source is often a differently-named repo. A do-stage candidate build from the wrong repo yields a false "source-lost" verdict that a content-based hunt later has to correct — pay the content-hunt cost at plan-time instead. Cross-check: a byte-identical bundle filename (content-hashed asset such as main.<hash>.js) shared between the candidate build and the live target is the strongest single parity signal for hash-named single-page-app output./dr-prd before writing the solution section. Structural assumptions that look like subdomains may be separate zones (each needing its own rule), and a rule-expression function available on one plan tier may be absent on another — both invalidate a written plan in one API call's worth of discovery. Also probe the API token's permission scopes against the exact endpoints the plan intends to call; a token valid for reads may lack the edit scope for the rule phase, forcing an architecture change mid-execution.docker inspect <writer> --format '{{.Config.Env}}', then resolve any service-alias to its container) at /dr-plan time — NOT inferred from indirect evidence (query-log timestamps, last-seen INSERT patterns, prior-session recon notes, or inventory-file comments). Indirect evidence names a hypothesis; the live env probe names the fact. A writer pointed at a Docker-network alias (e.g. clickhouse:8123) may resolve to a co-located local container rather than the remote host the inventory implies.blocked_by, a backlog note like "after X closes", or "earliest: "), the task's DoD was authored before the blocking task ran — and the blocking task may have changed the very state the DoD assumes. At /dr-do start, probe whether the DoD's precondition still holds: if the DoD names a live resource (a running service to back up, an instance to repoint, a port to bind) that the parent task may have stopped, moved, or retired, verify that resource's current state with a live probe before implementing. When the parent invalidated the precondition (e.g. the DoD says "back up the live DB nightly" but the parent stopped the DB and froze its data), surface the divergence and reconcile the DoD with the operator (or autonomously under FB-1..FB-5 when the correct reading is unambiguous) before executing the stale DoD. Mechanically running an outdated DoD wastes a cycle and ships the wrong outcome. This is distinct from the root-cause check in Software Step 1 (which validates a stated cause) and from the hypothetical-trigger probe (which validates a named symptom): here the DoD was correct when written and drifted over time.find . -maxdepth 6 -name .git -type d -exec dirname {} \;
git status --porcelain + git rev-list --count @{u}..HEAD (uncommitted + unpushed)./dr-archive clean-git check).$HOME/.claude/skills/file-sync-config/SKILL.md.find per the skill's checklist BEFORE confirming compliant.systemd-analyze verify <unit>, crontab -T, plutil -lint). Non-zero exit → block compliant.grep -E "^Requires=" *.timer MUST be empty per host where recurring units are deployed.When an expectation's success criterion or an acceptance criterion names two or more distinct filesystem roots that must all satisfy the same property (e.g. a code repository AND a separate registry/docs tree, or a service tree AND its sibling configuration tree), the verification MUST grep every named root independently. A repo-local helper script proves only the repo it scans; it is not evidence for the other roots.
grep/ls active datarim/.auto-mode-active* markers across sessions, and note any other in-flight task on the same resource (backlog/PRD cross-reference).Render the compliance report via the canonical structure declared in ${DATARIM_RUNTIME:-$HOME/.claude}/templates/compliance-report-template.md. The report carries:
task_id, date, verdict (COMPLIANT / COMPLIANT_WITH_NOTES / NON-COMPLIANT), optional scope.--- horizontal rule carrying ### Step-by-step verdicts (the 7-step per-step table), ### Remaining risks, ### Related.The four top sections answer «что просил оператор» and «что подтвердили / что осталось» in plain Russian — apply the banlist from skills/human-summary/banlist.txt. The audit addendum carries the technical surface (status table, risk list, cross-links) and MAY wrap ASCII-heavy lines in <!-- gate:literal --> fence.
Save to datarim/reports/compliance-report-{task_id}.md if the directory exists, otherwise present in chat. Filename suffix on re-runs: -v2, -v3, … (one new file per /dr-compliance invocation).