Skip to content
Use Cases
CompozyOS RuntimeUse Cases

Release Readiness Sweep

Use Compozy tasks and sessions to run release checks with durable ownership and completion evidence.

Audience
Operators running durable agent work
Focus
Use Cases guidance shaped for scanability, day-two clarity, and operator context.

A release sweep is a set of checks that should not disappear into chat: docs, build health, integration status, migration notes, and operator risk. Compozy models that work as tasks, task runs, and attached sessions.

The model is simple:

Runtime objectMeaning in this use caseTypical owner
TaskThe release concern, such as "Verify release documentation".Operator creates and reviews it.
Task runOne attempt to perform that task, with queue, claim, and close state.Operator or agent claims and closes it.
SessionThe durable agent process that reads files, runs commands, and reports evidence.Agent produces the work evidence.

Setup

Start with a registered workspace:

compozy workspace add /Users/you/project --name project

Create one task per release concern. Keep the title concrete enough that an agent can claim it without extra context.

compozy task create \
  --scope workspace \
  --workspace project \
  --title "Verify release documentation" \
  --description "Check docs, CLI examples, and known release claims for drift." \
  -o json

Flow

Rendering diagram…

A release readiness sweep moves from task creation through an exact session-bound claim, agent evidence, and an auditable completion decision.

The operator creates the work and starts the intended agent session. That session claims the exact queued run, renews its lease while working, and closes it; the operator reviews the durable evidence.

compozy task run enqueue task_123 -o json
compozy session new --workspace project --agent reviewer --name release-docs -o json
export COMPOZY_SESSION_ID=sess_1234
export COMPOZY_AGENT=reviewer
compozy task next --run-id run_123 -o json
compozy session prompt sess_1234 "Verify release documentation. Report mismatches, missing examples, and commands used."

When the evidence is clear, close the run:

compozy task complete run_123 \
  --result '{"status":"ready","evidence":["compozy session history sess_1234"]}' \
  -o json

If the check finds a blocker, fail the run instead:

compozy task fail run_123 \
  --error "CLI examples do not match generated reference" \
  --metadata '{"session":"sess_1234"}' \
  -o json

Evidence to keep

EvidenceCommandWhy it matters
Task definitioncompozy task get task_123 -o jsonShows scope, workspace, owner, channel, and metadata.
Run statecompozy task run list task_123 -o jsonShows whether work is queued, claimed, running, or closed.
Claiming sessioncompozy task run list task_123 --session sess_1234 -o jsonConnects the session-bound lease to the task run.
Session historycompozy session history sess_1234Preserves the reasoning and commands behind the result.

Useful release sweep tasks

Task titleWhat the agent should prove
Verify CLI examplesEvery command in edited docs exists in generated CLI reference.
Check OpenAPI route claimsDocs distinguish generated schema coverage from implemented routes.
Review provider and agent supportPublic copy lists only implemented provider IDs and agent adapters.
Exercise first-run docsA new operator can install, start the daemon, create a workspace, and start a session.
Collect unresolved release risksAny gap has a task id, owner, and visible next action.

Failure path

SymptomFirst checkLikely fix
No one can claim the runcompozy task run list task_123 -o jsonConfirm the run was enqueued and is not closed.
Session is doing unrelated workcompozy task run list task_123 --session sess_1234 -o jsonClaim the exact run from the intended session.
Result JSON is too vaguecompozy session history sess_1234Re-prompt for concrete evidence before closing.
Release concern keeps recurringTask history and run metadataSplit the concern into smaller tasks.

On this page