Delivery projects: hours, costs, change requests and sign-off

What it models

Handover is a plan-then-create pair: the read-only plan says who delivers what and why, and the create action commits the handover run, the delivery project, one work package per obligation, the ordered milestone plan, an optional partner engagement and the obligations marked handed over — all in one transaction across a package boundary. Who delivers a work package is a policy decision from the identity the obligation already carries, never an inference from a label, and a policy that cannot say returns ambiguous and blocks the handover until a human decides with a reason.

Execution is eight actions over an explicit transition table: a project moves pending kickoff to in progress to completed, a work package moves planned to in progress and in and out of blocked, a milestone moves planned to in progress to completed. Every declared state is reachable by a shipped action and every declared edge is walked by one, checked from the shipped action list rather than asserted in prose. Blocking requires a stated reason and records who and when; resuming clears those fields and the block stays in the audit log; completed is terminal and there is no reopen.

Economics adds immutable time and expense entries, a versioned cost policy, an immutable economic plan per publish, and a reproducible grouped snapshot. Change and acceptance adds governed change requests, immutable plan revisions, deliverables gated on server-authoritative execution state, and acceptance requests whose scope is frozen with a SHA-256 fingerprint the evidence binds to.

Where the money stops being a margin

The server computes cost: a caller supplies minutes, the versioned cost policy supplies the rate, and the action multiplies and rounds in integers throughout, checking the product before the division so an absurd input is refused rather than rounded into something plausible. A client-supplied cost, rate or currency is not authoritative — it is not even an input, and a test proves a forged one is ignored.

Currencies are never mixed, because there is no FX: every total is grouped by currency and a group is a complete answer for that currency alone. Periods are never mixed either, and this is the sharp edge. A recurring obligation prices one period; recorded cost is a spend to date; there is no term over which the two are comparable. So a contribution estimate exists only where every commercial input in that currency is one-time, and a mixed project returns no estimate at all with a named reason — recurring commercial input, unknown commercial shape or no commercial input — rather than one computed against a one-time subtotal that would understate the number in a way no label can rescue.

The vocabulary is fixed on purpose. Commercial delivery input, not recognized revenue. Planned and actual delivery cost, not budget or cost of goods sold. Delivery contribution estimate, never gross margin, accounting margin or profit. One-time commercial value, never ARR, MRR, TCV or an annualized figure — and a test asserts none of those strings appears anywhere in the serialized output.

The commercial boundary, which is the whole risk

A change that costs money must never reach the signed commercial record, so it does not. Approving a change flagged as commercially significant raises an immutable candidate and moves the request to a visible pending-commercial-followup state rather than an implicit hop. The end-to-end suite fingerprints every quote, order, contract and subscription row before and after and asserts the bytes are identical.

That handoff has an end, which matters more than it sounds: a raised candidate blocks acceptance over the scope it touches, so a candidate nobody could close would block that scope forever. A human records what the commercial follow-up concluded elsewhere — resolved externally, or withdrawn — once, with a stated reason, and recording it amends nothing. The result literally says amended false, the way a completed deliverable says accepted false.

Requesting acceptance is refused while an unresolved candidate touches the scope being submitted, and a change that names nothing is read as project-wide and counts too: the safe reading of we have not decided what this project includes is that it covers this milestone as well.

Acceptance is evidence, not authentication

An acceptance request stores the exact scope it submitted — the milestone, every deliverable with its completion evidence, and the customer reference as it read then — plus a fingerprint covering the body of work alone. Rebuilding that scope later from the current deliverable set would silently re-point old testimony at new work, so it is never rebuilt and the Admin says so on screen.

The fingerprint deliberately excludes the customer label, which is an unverified operator string: folding it in would let a rejected scope be re-asked as Acme instead of ACME over identical work. The label is still frozen and stored because it is part of the testimony; it just cannot buy a second answer. A pending request freezes its milestone, a settled scope cannot be re-asked, and evidence binds to the fingerprint rather than the request id.

A rejection preserves execution history. Completed work packages and deliverables are never destructively reopened, because rewriting execution evidence would stop an economics snapshot taken on Tuesday reproducing on Wednesday. Replanning goes through a new change request, which changes the deliverables and therefore the fingerprint — which is exactly how a genuinely new question becomes askable and an unchanged one does not.

How a coding agent builds it

Delivery is the second domain package and the first that depends on another. It reaches the contracts package only through declared capabilities and never imports its source or reads its tables; a package that did not declare the requirement is refused even though the capability exists. The capability methods are created with the caller's runtime handles, so the obligation update commits inside the delivery transaction — inject a failure after any write, including that one, and no delivery record survives while every obligation stays pending.

Every economics, change and acceptance record is managed storage: no public create, update or delete through the service, HTTP, the SDK, the Admin or MCP. A correction is a new record. An entry key promises that the same call records once — it is not an edit handle, so a retry whose values differ is refused, naming the fields that diverged, rather than answering 200 to an operator correcting 60 minutes to 480 while the money is still derived from 60.

Where it stops

Recording time, expenses, plans, snapshots, changes, deliverables and acceptance each require a user actor; an agent may call only the read-only preview and plan operations. That is a human-actor boundary rather than a Delivery Manager role, and it is the same boundary everywhere in this framework: the actor is asserted, not authenticated.