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

# Feature lifecycle

> Create, start, block, reopen, and complete features safely.

Features have only four states: `not_started`, `in_progress`, `blocked`, and `passing`. Prefer lifecycle commands for updates instead of editing states and claims directly.

## Create

```bash theme={null}
npx @caesarlo/sdlc-harness new-feature
npx @caesarlo/sdlc-harness new-feature --input planning/feature.json
```

[See the `new-feature` options →](/sdlc-harness-docs/reference/command-planning#new-feature)

The input file must be inside the repository and cannot preset a claim, evidence, workspace, or completed state. Before creation, the command validates the ID, milestone, dependencies, verification, and source references. A failure does not modify the state file.

## Start

```bash theme={null}
npx @caesarlo/sdlc-harness feature start M1-AUTH-001 --owner alice --actor codex-1 --ttl 120
```

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

Before starting, the command checks that the feature is ready based on its status and dependencies, then checks the `owner` WIP limit. On success, it atomically creates the claim and lease and transitions the feature to `in_progress`; it does not require a claim in advance.

## Verify and review

```bash theme={null}
npx @caesarlo/sdlc-harness verify M1-AUTH-001
npx @caesarlo/sdlc-harness review record M1-AUTH-001 \
  --reviewer bob --summary "Acceptance behavior and regression tests passed"
```

Options: [Run automated verification](/sdlc-harness-docs/reference/command-evidence#verify) · [Record a review](/sdlc-harness-docs/reference/command-evidence#review-record)

`verify` executes automated verifications; use `evidence manual` for manual verifications. The review must pass, occur after the latest verification, and be recorded by a reviewer other than the claim `owner`.

## Complete

```bash theme={null}
npx @caesarlo/sdlc-harness feature complete M1-AUTH-001 --owner alice
```

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

The command requires a valid claim, passing dependencies, passing results for every verification at the current commit, and a later independent review. Only then does it atomically transition the feature to `passing`.

## Block and reopen

```bash theme={null}
npx @caesarlo/sdlc-harness feature block M1-AUTH-001 --reason "Waiting for an identity-provider test account"
npx @caesarlo/sdlc-harness feature reopen M1-AUTH-001
```

Options: [Block a feature](/sdlc-harness-docs/reference/command-feature#block) · [Reopen a feature](/sdlc-harness-docs/reference/command-feature#reopen)

`block` writes a blocker, releases the claim, and transitions the feature to `blocked`. `reopen` clears the blocker and returns it to `not_started`, after which it must be started again.

## Release

```bash theme={null}
npx @caesarlo/sdlc-harness release M1-AUTH-001 --owner alice
```

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

Use `release` to abandon work that is still in progress. It clears the claim and returns `in_progress` to `not_started`. It is not a feature-completion step.

<Important>
  By default, `passing` is monotonic. When you need to change a completed feature, create a new feature to track the change instead of moving the old feature back to an incomplete state.
</Important>


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