arsdlc-verify

Verification is the moment the process either earns trust or destroys it. The output of this skill is evidence files, not sentences.

Iron law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you have not run the command in this session and recorded it, you cannot say it passes. Violating the letter of this rule is violating the spirit of it.

The gate function (before any status claim, every time)

1. IDENTIFY the command that would prove the claim.
2. RUN it, fresh and complete, through npx arsdlc evidence so the run is recorded.
3. READ the entire output: exit code, failure count, skipped count, warnings that are really errors.
4. VERIFY the output supports the claim. If not, state the actual status with the evidence file. If yes, state the claim with the evidence file.
5. Only then make the claim.

claim	requires	not sufficient
tests pass	full-suite run, exit 0, 0 failures, recorded	a previous run, "should pass", the subset you wrote
build succeeds	build command exit 0, recorded	linter passing, logs "look fine"
bug fixed	the red test now green + full suite green	code changed, assumed fixed
a11y ok	axe/pa11y report with 0 serious violations, recorded	"used semantic HTML"
migration safe	applied to a copy and rolled back, recorded	"it's just an add column"
subagent finished	diff on disk + its evidence files	the subagent said "done"

What G3 checks (npx arsdlc gate G3 <slug>)

1. Secrets scan clean across tracked and non-ignored files (9 detector families; placeholders ignored).
2. A run was recorded: at least one evidence/*.json with a real command and an exit code.
3. Full suite recorded and green: the latest full evidence has exitCode: 0, unless the repo declares a test policy (below).
4. Current evidence integrity: recorded checksums and source fingerprints match; legacy records must be re-run.
5. All tasks checked off.

Test policy (arsdlc.json → test.gate)

Three states, because "this repo has no runner" and "nobody set one up" are different facts and only one of them is a choice:

state	G3 requires	when it is true
configured (default)	a recorded full run, green	the repo has a test command in plan.md Verification strategy
none-by-design	latest full run green, or latest recorded run green if no full run exists; waiver printed	docs site, IaC glue, a spike - a repo that deliberately ships no runner, with the reason in docs/taste.md
none-yet	the recorded full run, same as configured	the honest state when tests simply were not written. It is not an escape hatch; write them

Set it in arsdlc.json; none-by-design also requires a non-placeholder test.reason. Check with npx arsdlc doctor. Never reach for none-by-design to make a gate go green: G4's human sign-off is what carries the risk, so say out loud that you are handing the trade-off to a person.

Procedure

1. Run the whole suite, not just the tests you wrote: npx arsdlc evidence <slug> --label full -- <full test command from plan.md Verification strategy>

2. Run the plan's smoke path end to end — the exact commands a stranger would run — and record it as --label smoke. Unit tests green with a broken entrypoint is the classic fake-green, and the smoke path is what catches it.

3. Run kind-specific verification and record each as evidence with a descriptive label:

   kind	required extra evidence
   frontend	component tests, visual diff (or screenshots), a11y audit (axe/pa11y), keyboard-only pass
   backend	integration tests, preview/local smoke (curl against a running instance), one negative-auth request
   mobile	emulator run, store checklist
   data	invariant tests, backfill parity check, row counts before/after
   ml	eval suite against thresholds; evals are tests; adversarial cases
   infra	plan/dry-run, policy check, expand/contract order, destroy plan reviewed
   docs	lint, link check, code samples executed
   lib	API contract tests, semver check, back-compat test against the previous version

4. Static checks the repo already has (typecheck, lint, build): run and record them too; a green suite on code that does not compile is not green.

5. npx arsdlc scan. Findings block; fix and re-run.

6. npx arsdlc gate G3 <slug>. Paste the output verbatim.

7. Scenario sweep: for every #### Scenario: in the spec, name the evidence file that exercises it. Missing one? That is a missing test: go back to BUILD via a new task, do not proceed.

8. Write acceptance.md rows for each spec scenario, linking the evidence file names (see arsdlc-review).

Worked example (what a real claim looks like)

claim:  "the export flow works"
wrong:  "I ran the tests earlier and they were green."
right:  IDENTIFY → npm test -- export
        RUN      → npx arsdlc evidence demo --label full -- npm test
        READ     → exit 0, 84 passed, 0 failed, 0 skipped
        CLAIM    → "Full suite green: 84 passed (evidence/2026-09-27T10-12-03-full.json).
                    Smoke path ran: curl -s localhost:3000/export returns 200 CSV
                    (evidence/...-smoke.json). Re-run: npm test."

The difference is not politeness; the second message can be checked by a stranger and the first cannot.

Honesty protocol

• If a command cannot run (missing runtime, network, credentials), record it anyway with --label blocked; the exit code and stderr are the evidence. Report IMPLEMENTED-NOT-VERIFIED and list exactly what a human must provide (names, never values).
• Never edit an evidence file. They are append-only and hashed.
• Never delete, skip, or loosen a failing test to get green. Fix the code, or open a delta if the spec was wrong.
• Flaky test? Record three runs. Three greens are evidence; two out of three is a bug report → arsdlc-debug.
• Words that mean you have not verified: "should", "probably", "seems to", "I believe", "looks good", "Done!" before the command ran. Delete them and run the command.

Final security verification

Before acceptance or a completion claim, classify the change's security surfaces. For web/API/auth/data/infra changes or an explicit security audit, read references/security-verification.md and follow it: all 21 controls, architecture-backed applicability, recorded negative tests, OWASP/provider comparison, fixes and retests. Other changes still need secrets/dependency checks and an evidenced reason for excluded surfaces.

Write docs/features/<slug>/security-review.md; report VERIFIED, FAILED, NOT_APPLICABLE or NOT_VERIFIED with evidence. Failed or applicable unverified controls block a security-ready claim. CLI gate success is separate; the CLI does not automatically assess this report. End the handoff with security results and residual risks.

Hand off

When G3 is green, run npx arsdlc next <slug>; the state moves to ACCEPT. Load arsdlc-review. Prefer a fresh session for the review (segregation of duties); if you must continue, say so.