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

# Status and traceability output

> Understand the JSON fields from status and traceability for developers, Agents, and scripts.

## `status`

```bash theme={null}
npx @caesarlo/sdlc-harness status
```

[View the `status` command →](/sdlc-harness-docs/reference/command-repository#status)

| Field | Meaning |
| - | - |
| `project` | Project name |
| `counts` | Counts for the four feature statuses |
| `activeFeatures` | Current `in_progress` features. Each entry contains `id`, `behavior`, and `owner`, plus `title` only when the feature defines one. |
| `readyFeatures` | Features whose dependencies pass and can be started, sorted by priority; summaries also include `dependencies` and `sourceRefs` |
| `blockedFeatures` | Blocked features and their blockers; summaries also include `dependencies` and `sourceRefs` |
| `artifactApprovals` | Project artifact approvals and their current validity |
| `traceability` | Whether traceability applies, is deferred, is complete, and each category of gap |
| `nextActions` | Recommended actions generated from current state |
| `milestoneCount` | Number of milestones |

`activeFeatures` entries always contain `id`, `behavior`, and `owner`; they contain `title` only when the feature defines one. `readyFeatures` and `blockedFeatures` summaries additionally contain `dependencies` and `sourceRefs`. This helps an Agent choose the next step without traversing the entire JSON itself.

```json theme={null}
{
  "counts": {
    "not_started": 2,
    "in_progress": 1,
    "blocked": 0,
    "passing": 4
  },
  "nextActions": [
    "Continue M1-AUTH-001; run verify, record review, then feature complete."
  ]
}
```

## `traceability`

```bash theme={null}
npx @caesarlo/sdlc-harness traceability
```

[View the `traceability` command →](/sdlc-harness-docs/reference/command-repository#traceability)

The complete matrix contains parsed requirements, stories, acceptance criteria, features, and verification mappings, plus these diagnostics:

* `applicable`: whether the current repository is in scope for real traceability checks.
* `deferred`: whether checks are still deferred because of a scope placeholder.
* `ok`: whether the matrix has no gaps.
* `uncoveredRequirements`, `orphanStories`, and `orphanFeatures`.
* `uncoveredAcceptanceCriteria` and `unverifiedAcceptanceCriteria`.
* `unknownReferences`: unknown requirement, story, or acceptance criterion IDs, plus verification references to acceptance criteria that the feature itself does not declare. Path existence is checked separately by `validate` under `[stage-gate]`.

On a normal read, `status` does not fail because of governance gaps and provides an observational view. Loading or parsing errors can still make it exit nonzero. `traceability` exits nonzero when it applies and has actual gaps, so it can serve as a CI gate.

<Tip>
  When scripts consume these commands, parse the JSON. Do not depend on field order or natural-language `nextActions`, which primarily guide developers and Agents.
</Tip>


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