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

# Planning commands

> Inputs, constraints, and examples for new-feature, new-milestone, and milestone archiving.

Planning commands add milestones or features to `feature_list.json`. They use compare-and-swap writes and reject duplicate IDs. Interactive commands perform their documented input checks; the full schema and structural preflight applies specifically to `new-feature --input`.

<h2 id="new-feature">
  `new-feature`
</h2>

Create a feature interactively or import one from a JSON file in the repository.

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

| Argument | Type | Required | Default | Description |
| - | - | - | - | - |
| `--input` | path string | No | — | Relative path to an existing JSON file in the repository. When specified, the command runs non-interactively. |

The input can be a feature object directly or `{ "feature": { ... } }`. `id`, `milestone`, `behavior`, and a non-empty `verification` array are required. The `milestone` must already exist. A new feature can only have the `not_started` status and cannot include a preconfigured `claim`, `workspace`, or `evidence`. Before writing, this mode runs `[schema]`, `[structural]`, `[dependency-cycles]`, `[milestone-order]`, and `[stage-gate]` checks against the candidate feature list. See the [`feature_list.json` reference](/sdlc-harness-docs/reference/feature-list) for the full field definitions.

Without `--input`, the command prompts for the ID, milestone, title, observable behavior, owner, verification commands, dependencies, source references, and priority. Priority must be an integer. Lower values are selected first by `claim --next`.

<h2 id="new-milestone">
  `new-milestone`
</h2>

Create a milestone interactively.

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

This command has no CLI arguments. It prompts for the milestone ID, title, and objective. The ID must be unique. On success, it appends the milestone to `feature_list.json`.

<h2 id="milestone-archive">
  `milestone archive`
</h2>

Move a completed milestone, and every feature in it, out of `feature_list.json` into `.harness/archive/<milestone-id>.json`.

```bash theme={null}
npx @caesarlo/sdlc-harness milestone archive M1 --actor alice
```

| Argument | Type | Required | Default | Description |
| - | - | - | - | - |
| `--actor` | string | No | `harness.config.json.defaultOwner` | Identity recorded as `archived_by` in the archive file and the `milestone.archived` audit event. |

Every feature in the milestone must already be `passing`; the command refuses and lists the blocking features otherwise, without changing anything. The archive file is written before the milestone is removed from `feature_list.json`, so an interrupted run can leave a duplicate archive record but never loses the milestone's data.

Archived features are not deleted from the project's history — they still satisfy dependencies for new features (`claim`, `feature start`, `dependency-cycles`), and `traceability` still counts them as covering their requirements, stories, and acceptance criteria. Archiving only relocates completed work so a new milestone starts from a lean `feature_list.json`; it never invalidates what already shipped. See [Archiving milestones](/sdlc-harness-docs/reference/feature-list#archiving-milestones) for the archive file's shape.

<h2 id="milestone-list-archived">
  `milestone list-archived`
</h2>

List archived milestones.

```bash theme={null}
npx @caesarlo/sdlc-harness milestone list-archived
```

This command has no arguments and does not modify the repository. It prints a JSON array with each archived milestone's `id`, `title`, feature count, and `archived_at`/`archived_by`.


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