# NADILI: Delivery
Source: https://manaienko.com/projects/nadili/delivery/
Author: Artem Manaienko

# Delivery
_and acceptance._

I build the delivery workflow: specifications, agent context, independent review and release checks. I integrate changes and trace failures.

**Scope:** Specifications, context and exclusions

**Review:** Independent review and findings

**Release:** Final-commit checks and owner UAT

Explore the delivery process

01 Agent work contract **Give implementation a bounded problem** **Scope**02 Independent verification **Implementation and review are separate steps** **Review**03 Release acceptance **Release evidence belongs to the final commit** **Release**

Recorded plans, reviews and release gates.

Agent work contract

## Give implementation a bounded problem

I turn product and architecture decisions into scoped specifications, repository context and a verification plan. I use coding agents for bounded changes, then integrate and verify the result.

### What a work item carries

**Behavior:** The concrete trigger, expected result and failure cases.

**Context:** Affected product rules, architecture, contracts and code.

**Limits:** Explicit exclusions and dependencies.

**Acceptance:** Relevant automated checks and owner-verifiable behavior.

### A search change with a precise boundary

The search specification names the multilingual queries to improve, preserves exact-match behavior and excludes index migration. Acceptance checks the intended Answer and old false positives.

Why the proposed search fallback was rejected

The ticket suggested returning all merged candidates when reranking failed. The plan rejected this because the product contract suppresses unvalidated broad-term and vector-only candidates.

The plan records the model, deadline, affected services and owner checks. The disagreement is visible before implementation.

Independent verification

## Implementation and review are separate steps

The repository defines review outside implementation. Review checks behavior, architecture, tenancy, contracts and failure handling. Findings and limits stay in the release record.

### What a review records

**Target:** The plan and exact affected implementation.

**Evidence:** Relevant checks plus the reviewer findings.

**Feedback:** Blocking findings return to implementation and review.

**Record:** A versioned review with a verdict and declared omissions.

### Example: Answer publication across locales

One reviewed change lets publication use a current verified private Claim rendering in any locale. Validation and immutable snapshot creation use the same deterministic resolver. The review identifies the backend and Web tests covering the change.

What the recorded approval does and does not cover

The locale-publication review lists the implementation, plan, checked boundaries and verdict. It records no open findings for that change.

Blocking findings require fixes and renewed review. Lower-severity findings may remain recorded. Later code, test or configuration changes can require another review.

Release acceptance

## Release evidence belongs to the final commit

The release procedure runs its full gate against the final delivery commit. Amending or rebasing invalidates the earlier result. User-facing work also has an owner UAT path.

### What the full gate exercises

**Static:** The full local code and boundary checks.

**Database:** Integration against disposable PostgreSQL.

**Runtime:** Web E2E and runtime liveness in isolated stacks.

**Public web:** The standalone bundle shipped by the image.

### Test the artifact that will actually ship

The public visual harness tests the traced standalone bundle rather than relying only on the dev server. Each worktree has isolated test infrastructure. Wrapper ownership prevents the same suite from being scheduled twice on an unchanged tree.

Inspect the release gate and its evidence boundary

The gate runs code and boundary checks, PostgreSQL integration, web E2E, runtime liveness and public visual checks in sequence. A failed stage stops the release.

The gate runs again after an amended commit or rebase. UI and UX changes go to owner UAT; backend-only work can finish through agent verification. Public cutover needs more operational evidence.

[Back to all six areas](https://manaienko.com/projects/#scope-overview-title)[Next: Security ↗](https://manaienko.com/projects/nadili/security/)I design and integrate the product, with coding agents supporting implementation.