Delivery
How the firm turns a committed plan into a shipped, observed product increment. Delivery is the structure, guidance, and guardrails around that move — so what reaches users is what the firm decided to build, nothing more.
Delivery is the only place in the firm that touches reality. Tactics produces a typed Delivery Plan — ordered tasks, acceptance criteria, the value the increment is meant to make reachable. The Delivery Engine resolves that plan against a customer's Delivery Profile (the firm's "how we build, ship, and observe") and runs it through a deterministic lifecycle.
The lifecycle is explicit and persisted: pending → provisioning → implementing → testing → shipping → observing → completed | failed | abandoned. Testing can loop back to implementing when a structural check rejects a run. Each step is a recorded event you can open later, not an inferred state.
Strategy decides which bet matters. Tactics decides what to build. Only Delivery proves it. Without a real shipping path, a firm of agents is a debate club — eloquent and untested.
Delivery is also where the firm's bets become measurable. A shipped increment emits telemetry; the telemetry feeds reflection; reflection updates the causal model. No delivery, no learning.
Every tenant has a Delivery Profile that names which adapters apply: how things build, how they deploy, and how they send back telemetry. Tactics reads the profile and produces a plan that is shippable against it — no inventing a deploy target the firm cannot actually reach.
Planned Available external services. Today, Tactics guesses at what third-party services exist for a tenant — a CRM, a payment provider, an analytics platform — and the Delivery Plan can promise things the firm cannot actually call. A richer Delivery Profile section will name what is reachable, so plans respect the firm's real surface area.
The build adapter compiles, packages, or assembles whatever the Delivery Plan says should ship. Today: a node static-site build — npm/vite-style toolchain that outputs a static bundle. Knobs the firm tunes: build command, environment variables, output directory, dependency cache.
The deploy adapter lands a built artefact on the target the tenant actually serves from. Today: ssh+rsync — pushes the bundle to a remote host's web root. Knobs: SSH host alias, remote path, post-deploy command. GitOps, FTP, and platform-native deploys are on the list, not in the box.
The observation adapter feeds reality back into the firm. Today: a webhook — "poor man's telemetry", a small script injected into the sandbox that posts events to a firmd endpoint. Useful when the tenant has no dedicated telemetry stack. Knobs: webhook URL, which events to forward.
Planned Tenant-grade observability. The webhook is fine for the pilot, thin for tenants that already run a real observability stack. A fuller path will integrate with the tenant's own telemetry rather than handing it back through a script.
Each plan runs in its own Development Sandbox — a k3d
pod with explicit egress controls and just the
credentials a build needs, nothing more.
A Quality Engineer participant checks whether the shipped increment actually meets the acceptance criteria from the committed plan — including that the planned telemetry signals show up. If they don't, Delivery does not declare success.
