Tickets & Software Delivery

Orkestia's largest workflow family after the cloud ports is ticket.* — a ticket ledger plus a governed software delivery lifecycle built on top of it. The premise: if AI agents are going to write software for you, the unit of work needs to be as governed as everything else on the platform. A ticket is that unit — it carries the problem, the plan, the evidence, and the exact git objects that came out the other end.

The ticket ledger

Tickets are org-scoped records with a typed lifecycle, and they arrive from three directions:

Because the ledger is a workflow surface, everything that happens to a ticket — claim, plan, acknowledgement, delivery — is a recorded, auditable run.

The delivery lifecycle: ticket → verified pull request

Before the first delivery on a new repository, complete Wire a repository for coding agents.

The ticket.software-delivery.*, ticket.git-work.*, and ticket.git-delivery.* families implement an end-to-end coding lifecycle for AI agents:

1. Claim — an agent takes the ticket and resolves every reference it carries (error groups, repos, prior artifacts).
2. Workspace lease — the agent gets a leased, disposable workspace on runner capacity (runner.workspace-lease.*). Repository access is defined by a repository profile, not by handing the agent a credential.
3. Investigate → plan → acknowledgement — the agent reproduces the problem and proposes a plan; a human acknowledges it before implementation. This is the same approval-gate pattern as everywhere else: AI proposes, the gate decides.
4. Implement and validate — the agent codes against the plan and runs the checks the repository's policy demands.
5. Trusted delivery — the agent publishes the exact git objects it produced; a trusted delivery step opens the pull request. The coding agent never holds a git provider credential and never pushes directly — what lands is byte-for-byte what was verified.
6. Evidence — the full chain (plan, runs, checks, objects, PR) is recorded back on the ticket.

Repository policies and delivery SLOs

Two supporting surfaces make the lifecycle operable at fleet scale:

• ticket.repository-policy.* — per-repository rules for what delivered work must satisfy (checks, review requirements) before delivery proposes it.
• audit.software-delivery-slo.scan — the audit view of how delivery is actually performing: it evaluates active deliveries and reconciles deduplicated, auto-clearing findings for the humans accountable for the fleet's output.

Where to go next