Case study: owner-scoped tickets
User problem
An operator needs a durable queue that humans and agents can share. Items need ownership, status transitions, comments, assignment, and an audit trail.
Application shape
The application stores a typed ticket record and exposes narrow operations for create, list, view, comment, claim, release, and close. Authentication supplies the owner boundary. An eligible ticket can also become bounded work for an agent without changing the ticket API used by humans.
| Artifact | Role |
|---|---|
| Checked-in Rust serde schema + CBOR | Stable record and lifecycle fields |
| Pipeline manifests | One reviewed route contract per operation |
| Ticket handler | Validation and allowed transitions |
| Engine dataset | Owner-scoped durable records |
| Agent dispatch | Optional execution attached to the ticket identity |
Request path
authenticated request
-> ticket route
-> transition validation
-> typed engine write
-> owner-scoped read model
The write and subsequent read use the same ticket identity. Claim and close operations validate the current state, so clients receive a conflict instead of silently overwriting a competing transition.
Representative result
{
"ticket": {
"id": "ticket-id",
"title": "Verify the public API examples",
"status": "open"
}
}
The exact response and all supported operations are shown in the Tickets API walkthrough.
Current status and limitation
The owner-scoped ticket application is a managed preview. Its /v1/tickets/*
routes are absent from the generated public allowlist in the V1 route
reference, so they remain outside the self-service public
API contract. Onboarded accounts can use the routes while the contract is
reviewed. Agent execution depends on workspace capacity and authorization.
Ticket transitions remain useful when no agent is assigned, and clients should
treat dispatch as asynchronous work.