Product increment delivery

# Product increment delivery

## Goal

Implement the single bounded product increment authorized by an accepted contract and implementation plan, verify it locally, and leave an auditable record of what was and was not delivered.

Delivery is not permission to redesign the product, clean up the codebase broadly, or make deployment decisions. The contract governs behavior; the plan governs the intended path; repository evidence governs safe execution.

This prompt may modify product code, tests, local documentation, and other repository files only where the accepted increment requires them. Never deploy, change production, use production secrets, access real user data, or perform external side effects.

Complete the work autonomously while safe progress remains. Do not ask for routine implementation choices. Stop honestly with `BLOCKED` or `CONTRACT CONFLICT` when authority, evidence, access, or the accepted boundary is insufficient.

## Prerequisites

Read, in order:

* every applicable `AGENTS.md` and repository instruction file, including nested instructions for each file you may touch
* `docs/product/increment-contract.md`, `docs/product/increment-contract.yaml`, and their changelog
* `docs/product/implementation-plan.md`, `docs/product/implementation-plan.yaml`, and their changelog
* the exact current source, tests, interfaces, schemas, configuration, dependency files, and operational docs named by the plan
* the current working-tree status and relevant recent history
* any existing `docs/product/increment-delivery.md`, `docs/product/increment-delivery.yaml`, and `docs/product/increment-delivery-changelog.md`

Proceed only when the latest contract decision is `CONTRACT` or `CONTRACT NARROWLY` and the latest plan decision is `PLAN` or `PLAN NARROWLY`. The increment ID and inherited versions must agree.

If either artifact changed after the other, the planned paths no longer match the repository, or the working tree contains overlapping changes whose ownership cannot be resolved safely, stop before modifying those paths.

## Evidence standard

Label every material delivery claim with exactly one:

* `OBSERVED`: directly shown by the current diff, test output, inspection, or repository artifact
* `DERIVED`: concluded from cited observed results; show the derivation
* `ASSUMED`: necessary but unverified; do not use it to claim acceptance
* `UNKNOWN`: unresolved; state the blocker and what evidence would resolve it

Code that looks correct is not delivered behavior. A passing focused test is not a passing full regression suite. A skipped test is not a pass. Record commands, exit status, and the relevant result without fabricating output.

## Step 1: Run the delivery preflight

Before editing:

* record increment ID, contract version, plan version, and permitted scope
* inspect working-tree changes and identify pre-existing or unrelated work
* confirm every intended path is governed by applicable instructions
* confirm local verification commands from repository evidence
* identify destructive, irreversible, privileged, networked, or production-facing steps and exclude them
* confirm no step requires secrets, live accounts, real personal data, or production access

Build a protected-work ledger: path, existing change, likely owner if known, overlap risk, and handling. Preserve all unrelated work. Never overwrite, reset, revert, delete, reformat, or stage another person’s changes to make delivery easier.

If safe isolation is impossible, return `BLOCKED` without destructive cleanup.

## Step 2: Reconcile plan with current reality

Trace each planned task to the current repository before executing it.

Minor path or symbol drift may be handled when behavior and risk are unchanged; record the deviation. Stop with `CONTRACT CONFLICT` when implementation requires:

* removing or weakening an acceptance criterion
* changing a business rule, permission, success measure, or quality bar
* changing a protected invariant or public contract
* a new irreversible migration or breaking interface
* materially broader data access, permissions, dependency, or security exposure
* product behavior outside the accepted scope
* an architecture change that invalidates the plan’s risk or rollback analysis

Do not reinterpret the contract to keep coding.

## Step 3: Implement in bounded slices

Follow the ordered tasks. For each slice:

1. make the smallest coherent change that advances named contract requirement IDs
2. add or update the lowest-level reliable tests with the behavior
3. run the focused verification named by the plan
4. inspect the diff for scope, accidental generated output, secrets, debug code, and unrelated formatting
5. record result and deviation before moving on

Follow existing patterns where they satisfy the contract. Avoid speculative abstractions, drive-by refactors, dependency upgrades, broad formatting, and generated-file churn.

Handle error, empty, loading, permission, and recovery paths required by the contract. Preserve compatibility and data integrity. Treat accessibility semantics, security boundaries, privacy, performance, and reliability as implementation requirements where the contract or affected surface makes them relevant.

Do not weaken tests, validation, authentication, authorization, typing, lint rules, or safety checks merely to obtain a pass.

## Step 4: Implement proportional operability

Add or update only the local code and documentation required by the accepted observability and rollback plan:

* events, logs, metrics, or traces that can be verified without production access
* non-sensitive diagnostic context
* feature-flag or compatibility behavior authorized by the plan
* reversible schema or data transitions using synthetic fixtures only
* user, support, or operator documentation required to understand the increment

Do not emit secrets, personal data, raw content, or sensitive identifiers. Do not configure live dashboards, vendors, alerts, flags, infrastructure, or production migrations.

If the accepted outcome cannot be observed or rolled back as planned, record the gap and stop when it makes release unsafe.

## Step 5: Verify from narrow to broad

Run, in this order where available and relevant:

* tests focused on changed behavior
* integration or contract tests for affected boundaries
* static analysis, type checking, linting, or formatting checks
* accessibility, security, privacy, and performance checks named by the plan
* relevant regression suites
* build or packaging verification when it does not start a server, deploy, or contact production

Use only repository-supported commands. Do not start a local development server unless explicitly authorized by the user or repository instructions.

For every acceptance criterion, business rule, permission, protected invariant, and quality bar, record `PASS`, `FAIL`, `NOT RUN`, or `NOT VERIFIABLE`, the command or inspection, and the evidence. For success measures, record whether later observation is supported without claiming the outcome occurred. `NOT RUN` and `NOT VERIFIABLE` cannot support `DELIVERED` unless the plan explicitly established a safe, proportionate alternative.

When a command fails, determine whether the cause is the increment, pre-existing repository state, environment, or unknown. Do not repair unrelated failures. Include the smallest useful failure excerpt and preserve the full command.

## Step 6: Review the final change set

Inspect the complete diff and changed-file list:

* map every change to a task and contract requirement ID
* identify deviations from the plan
* confirm no unrelated work was altered
* confirm no secrets, credentials, personal data, debug hooks, production endpoints, or accidental artifacts were introduced
* confirm migrations, dependencies, interfaces, observability, accessibility, and rollback behavior match the accepted plan
* list remaining risks and known unverified behavior

Do not commit, push, open a pull request, merge, release, deploy, execute migrations against shared systems, or change external services as part of this prompt.

## Decision

Conclude with exactly one:

* `DELIVERED`: all in-scope criteria are implemented and verified at the planned level, with no material unresolved risk
* `PARTIAL`: a clearly named subset is implemented safely, but one or more criteria remain incomplete or unverified
* `BLOCKED`: environment, access, evidence, tooling, or overlapping work prevents safe progress
* `CONTRACT CONFLICT`: current implementation reality requires changing the accepted behavior, boundary, invariant, or material risk

Lead with:

“As of [date], increment [increment_id] against contract [version] and plan [version] has [N/N] in-scope criteria implemented and [N/N] verified, with [N] changed files and [N] unresolved risks; decision [DELIVERED / PARTIAL / BLOCKED / CONTRACT CONFLICT].”

## Deliverables

In addition to the bounded implementation changes, create or update:

### 1. `docs/product/increment-delivery.md`

Lead sentence, inherited scope, protected-work ledger, task log, changed-file map, criterion, business-rule, permission, success-measure, invariant, and quality-bar results, commands and outcomes, plan deviations, operability and rollback notes, unresolved risks, and decision.

### 2. `docs/product/increment-delivery.yaml`

Include `version`, `status`, `as_of_date`, `decision`, `increment_id`, `contract_version`, `plan_version`, `working_tree_baseline`, `protected_work`, `tasks`, `changed_files`, `criterion_results`, `business_rule_results`, `permission_results`, `success_measure_results`, `invariant_results`, `quality_bar_results`, `verification_runs`, `observability`, `rollback`, `deviations`, `risks`, `assumptions`, `unknowns`, and `sources`.

Use stable task and criterion IDs. Record failed and skipped verification honestly. Unknown values are `null` with an explanation.

### 3. `docs/product/increment-delivery-changelog.md`

Append only. Record version, date, inherited contract and plan versions, decision, delivered scope, and why any work or verification remains incomplete.

Parse the YAML and confirm the delivery artifacts agree with the actual diff and command results.

## Boundaries

* Implement only the single accepted increment and its required tests and documentation.
* Read and obey all applicable `AGENTS.md` files before touching a path.
* Preserve unrelated and pre-existing work; never use destructive cleanup or broad rewrites.
* Never deploy, release, merge, push, contact production, use secrets, access real user data, or change external systems.
* Do not run destructive migrations or irreversible data transformations.
* Do not weaken quality or safety controls to make checks pass.
* Do not hide partial delivery, failed tests, skipped checks, plan deviations, or contract conflicts.

## Done when

* Every changed file maps to the accepted increment and applicable instructions were followed.
* Every in-scope criterion, business rule, permission, success measure, protected invariant, and quality bar has an honest implementation, verification, or observation-readiness status.
* Relevant tests and proportional accessibility, security, privacy, performance, reliability, and compatibility checks were run.
* Observability and rollback requirements are implemented locally or their gaps force a non-delivered decision.
* Unrelated work, production systems, secrets, and user data were untouched.
* The Markdown, YAML, append-only changelog, actual diff, and command results agree.