> ## Documentation Index
> Fetch the complete documentation index at: https://gump.top/sdlc-harness-docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Evidence and review

> Understand automated verification, manual verification, reviews, artifact approvals, and CI evidence.

Evidence answers two questions: what conclusion holds, and which code or document that conclusion is bound to. Different evidence types cannot replace one another.

## Automated verification evidence

```bash theme={null}
npx @caesarlo/sdlc-harness verify <feature-id>
```

[See the `verify` options →](/sdlc-harness-docs/reference/command-evidence#verify)

This is the only supported entry point for writing local `kind: "test"` evidence. It actually executes each automated verification and records the command, exit code, result, time, and current commit SHA. Failures are recorded too.

Solo mode creates a temporary claim when needed and releases it afterward. Team mode requires a valid claim in advance. If a feature mixes automated and manual verification items, `verify` skips the manual ones (it never executes a manual item's description as a shell command) and still records evidence for the automated ones — record the manual part separately with `evidence manual`. A feature that is fully manual has nothing for `verify` to do; it's a no-op, not a failure.

## Manual verification evidence

```bash theme={null}
npx @caesarlo/sdlc-harness evidence manual <feature-id> \
  --verification 1 --result passed \
  --notes "Completed the login flow with a screen reader" --actor alice
```

[See the `evidence manual` options →](/sdlc-harness-docs/reference/command-evidence#manual)

`--verification` is one-based and must point to a `manual` verification. The notes should record the environment, steps, and observed result.

## Independent review evidence

```bash theme={null}
npx @caesarlo/sdlc-harness review record <feature-id> \
  --reviewer bob --result passed \
  --summary "Checked behavior, failure paths, security boundaries, and regression tests"
```

[See the `review record` options →](/sdlc-harness-docs/reference/command-evidence#review-record)

The reviewer cannot be the claim `owner`, and the review must occur after the latest passing verification. After further changes and verification, record another review.

## Artifact approval

```bash theme={null}
npx @caesarlo/sdlc-harness evidence approval docs/product/requirements.md \
  --actor product-owner --summary "M1 scope approved"
```

[See the `evidence approval` options →](/sdlc-harness-docs/reference/command-evidence#approval)

An approval is bound to the artifact path, SHA-256 content hash, and current commit. When the file content changes, the previous approval becomes stale and `validate` requires a new approval.

## GitHub Actions evidence

```bash theme={null}
npx @caesarlo/sdlc-harness evidence import <feature-id> --ci-run <run-id>
```

[See the `evidence import` options →](/sdlc-harness-docs/reference/command-evidence#import)

The tool uses the GitHub CLI to confirm that the run exists, has completed, and has a successful conclusion. It does not import a failed, in-progress, or nonexistent run.

## Recommended order

```text theme={null}
implement → verify / evidence manual → review record → feature complete → validate
```

<Warning>
  Do not hand-write test or review records that appear to pass. The CLI validates inputs, binds evidence to a commit, and uses atomic writes to avoid overwriting concurrent changes.
</Warning>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.