> ## 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. # Daily workflow > Start a session, select a feature, implement and verify it, review and complete it, then close the session. Daily work follows one principle: advance one independently verifiable feature at a time, and always leave repository state that the next developer or Agent can take over. ## 1. Start the session: read instead of guessing ```bash theme={null} npx @caesarlo/sdlc-harness status npx @caesarlo/sdlc-harness validate ``` Options: [Read status](/sdlc-harness-docs/reference/command-repository#status) · [Validate the repository](/sdlc-harness-docs/reference/command-repository#validate) Also read `AGENTS.md`, `feature_list.json`, the relevant `source_refs`, and `progress.md`. Resolve existing validation errors before starting new work. `status` lists active, ready, and blocked features, approval status, traceability gaps, and recommended next steps. See [Status and traceability output](/sdlc-harness-docs/reference/status-and-traceability-output) for field definitions. ## 2. Plan: create only when needed ```bash theme={null} npx @caesarlo/sdlc-harness new-milestone npx @caesarlo/sdlc-harness new-feature ``` Options: [Create a milestone](/sdlc-harness-docs/reference/command-planning#new-milestone) · [Create a feature](/sdlc-harness-docs/reference/command-planning#new-feature) When an Agent creates a feature automatically, use a JSON input file inside the repository: ```bash theme={null} npx @caesarlo/sdlc-harness new-feature --input .harness-input/feature.json ``` [See the `--input` option →](/sdlc-harness-docs/reference/command-planning#new-feature) Input cannot inject a claim, workspace, evidence, or completed state. A feature should describe observable behavior, contain at least one verification, and connect to requirements, user stories, acceptance criteria, or ADRs through `source_refs`. Before planning the next milestone, archive the previous one once every feature in it is `passing`, so `feature_list.json` starts the new requirement cycle lean instead of accumulating every milestone the repository has ever had: ```bash theme={null} npx @caesarlo/sdlc-harness milestone archive M1 --actor alice ``` [See the `milestone archive` options →](/sdlc-harness-docs/reference/command-planning#milestone-archive) Archived features keep satisfying dependencies and traceability coverage for the milestones that follow, so archiving never blocks or invalidates new work — see [Archiving milestones](/sdlc-harness-docs/reference/feature-list#archiving-milestones). ## 3. Start: select ready work The unified lifecycle command is recommended: ```bash theme={null} npx @caesarlo/sdlc-harness feature start ``` [See the `feature start` options →](/sdlc-harness-docs/reference/command-feature#start) Teams can also explicitly claim a specific feature or the highest-priority ready feature: ```bash theme={null} npx @caesarlo/sdlc-harness claim --owner alice npx @caesarlo/sdlc-harness claim --next --owner alice ``` Options: [Claim a specific feature](/sdlc-harness-docs/reference/command-claim#claim) · [Select a feature automatically](/sdlc-harness-docs/reference/command-claim#next) Lower `priority` values take precedence. Features without a `priority` follow those with one and retain their list order. ## 4. Isolate: create a workspace when needed ```bash theme={null} npx @caesarlo/sdlc-harness workspace create --base main ``` [See the `workspace create` options →](/sdlc-harness-docs/reference/command-workspace#create) This command creates `.worktrees/` and a `feature/` branch for a claimed feature. A small solo change may not need one; separate workspaces are recommended for parallel Agents or changes that are likely to conflict. ## 5. Implement: follow the project's test strategy Read `testStrategy` in `harness.config.json` and `docs/workflow/06-agile-tdd.md`. During implementation, modify only what the current feature requires. If you discover additional work, create a new feature instead of silently expanding scope. Automated verification: ```bash theme={null} npx @caesarlo/sdlc-harness verify ``` [See the `verify` options →](/sdlc-harness-docs/reference/command-evidence#verify) A manual verification cannot run as a shell command. Record it with: ```bash theme={null} npx @caesarlo/sdlc-harness evidence manual \ --verification 1 --result passed \ --notes "Completed the keyboard interaction check on Windows 11" --actor alice ``` [See the `evidence manual` options →](/sdlc-harness-docs/reference/command-evidence#manual) ## 6. Review: after the latest verification ```bash theme={null} npx @caesarlo/sdlc-harness review record \ --reviewer bob --result passed \ --summary "Acceptance behavior, failure paths, and regression tests meet the requirements" ``` [See the `review record` options →](/sdlc-harness-docs/reference/command-evidence#review-record) The reviewer must be independent of the claim `owner`. After any code change that affects a verification conclusion, run `verify` and record the review again. ## 7. Complete: let the CLI check the gates atomically ```bash theme={null} npx @caesarlo/sdlc-harness feature complete --owner alice npx @caesarlo/sdlc-harness validate ``` Options: [Complete a feature](/sdlc-harness-docs/reference/command-feature#complete) · [Validate the repository](/sdlc-harness-docs/reference/command-repository#validate) If completion fails, do not edit the state directly. Follow the error to restore a valid claim, resolve dependency failures, rerun verification for the current commit, or record a later passing review. When an external dependency blocks work: ```bash theme={null} npx @caesarlo/sdlc-harness feature block --reason "Waiting for a test account" npx @caesarlo/sdlc-harness feature reopen ``` Options: [Block a feature](/sdlc-harness-docs/reference/command-feature#block) · [Reopen a feature](/sdlc-harness-docs/reference/command-feature#reopen) `block` records the reason and releases the claim. `reopen` clears the blocker and returns the feature to `not_started`. ## 8. Close the session: leave a state others can take over ```bash theme={null} npx @caesarlo/sdlc-harness session close ``` [See the `session close` command →](/sdlc-harness-docs/reference/command-environment#session-close) It runs `validate` and the configured environment checks, then summarizes Git state, feature counts, and next steps. Uncommitted changes are reported but do not cause failure by themselves; validation or environment-check failures return a nonzero exit code. Remove the workspace only when you no longer need it: ```bash theme={null} npx @caesarlo/sdlc-harness workspace remove ``` [See the `workspace remove` options →](/sdlc-harness-docs/reference/command-workspace#remove) The tool refuses to remove a workspace that contains uncommitted or unpushed work. Use `--force` only when you explicitly accept losing that content. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.