> ## 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.

# Audits and conclusions

> Distinguish feature verification, repository audits, and GitHub checks, and fix each class of validate error.

## Do not confuse these three conclusions

| Command | Question answered | Executes feature tests |
| - | - | - |
| `verify <feature-id>` | Did the commands declared by this feature actually pass? | Yes |
| `validate` | Do the current repository state, evidence, and traceability comply with the contract? | No |
| `provider github check` | Does the target GitHub branch's governance configuration meet the requirements? | No |

Completing a feature also requires `review record` and `feature complete`; none of these conclusions is sufficient on its own.

## `verify` output

```text theme={null}
[PASS] npm test -- auth (exit 0)
All verification commands passed for M1-AUTH-001.
```

If any command fails, `verify` exits nonzero and records failed evidence. Use `evidence manual` for manual verification.

## `validate` output

```text theme={null}
All checks passed.
```

Example failure:

```text theme={null}
FAILED with 1 error(s):
  - [pass-gate] Feature M1-AUTH-001 is passing but has no passing review evidence
```

The name in brackets identifies the auditor responsible for the check.

## Auditor categories

### `[schema]`

Checks JSON Schema, including field types, required fields, status enums, and manual/automated types. Fix the structure first so other auditors have reliable input.

### `[structural]`

Checks top-level fields, a non-empty feature list, unique IDs, known milestones, and at least one verification item. Do not use duplicate IDs or empty verification arrays as temporary placeholders.

### `[dependency-cycles]`

Checks unknown dependencies and dependency cycles. An error shows the cycle, such as `A -> B -> A`. Split the work differently or reverse the dependency direction.

### `[dependency-readiness]`

Every dependency of an `in_progress` feature must already be `passing`. Complete the dependency first, or block and reschedule the current feature.

### `[milestone-order]`

An earlier milestone cannot depend on a feature in a later milestone. Adjust milestone order or dependency ownership.

### `[stage-gate]`

Real features must have `source_refs` that resolve to files in the repository. Use stable paths and IDs for requirements, acceptance criteria, or ADRs.

### `[pass-gate]`

Checks the per-owner WIP limit, prevents placeholders from becoming passing, and checks passing evidence for every verification item, independent review, and monotonic passing status. Prefer lifecycle commands for repairs; do not edit status manually.

### `[adr-coverage]`

Every topic in `requiredAdrTopics` must be covered by matching frontmatter `topic` in `docs/adr/`.

### `[agents-onboarding]`

When a repository already has `AGENTS.md` and adopt creates a sidecar, the root protocol must explicitly reference `AGENTS.sdlc-harness.md`.

### `[feedback-log]`

When observability is not `none`, checks feedback entry dates, sources, observations, S1-S4 severity, and dispositions. Deferred and Declined entries also require a reason.

### `[artifact-approval]`

An artifact approval becomes invalid when the artifact is missing or its content hash differs from the approved version. After confirming the new content, run `evidence approval` again.

### `[traceability]`

Checks uncovered requirements, orphan stories and features, and uncovered or unverified acceptance criteria. Use `traceability` to view the complete matrix.

## Git baseline

Passing monotonicity prefers comparison against the Git history at `HARNESS_BASE_REF`, `GITHUB_BASE_REF`, `origin/main`, or `main`. Without available history, it falls back to the last successful local audit snapshot. CI should use full history or an explicit baseline.

## GitHub conclusions

`provider github check` outputs `PASS`, `FAIL`, or `UNKNOWN`. `UNKNOWN` means the current token cannot read an administrative setting. It is a degraded warning and must not be represented as “the check passed.”

## Recommended troubleshooting order

1. `[schema]` and `[structural]`.
2. Dependency cycles, milestone order, and readiness.
3. `source_refs`, ADRs, and traceability.
4. WIP, verification, review, and approval.
5. Run `validate` again. Do not delete erroneous state to hide a problem.


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