Weekly operations brief capstone.
This worked sample shows how an Operator capstone should expose the business task, source rules, verification path, shipped surface, and known limitation.
Capstone scenario
A project lead spends Friday collecting status notes from a tracker, meeting notes, and deployment log. The agent builds a weekly brief with shipped work, blocked decisions, owners, and source links. It cannot invent progress or mark a blocker resolved.
Decision rules
- The project tracker is authoritative for owner and status.
- Every shipped item must include a deploy, commit, or release-note source.
- Conflicting statuses render as “needs review,” never as a merged guess.
- Private notes may inform a draft but cannot be copied into the public brief.
- A human approves the final brief before distribution.
Evidence checklist
- Versioned instructions and source hierarchy.
- Test fixtures for missing owners, conflicting status, and stale updates.
- Runnable command or interface another owner can trigger.
- Output diff against a human-prepared reference brief.
- Failure receipt plus manual preparation fallback.
Known limitation
The agent can report only what exists in approved sources. It flags stale or absent updates; it does not infer work from chat activity or rewrite uncertainty as progress.
Review standard
Operator review looks for a real recurring task, durable instructions, safe source handling, reproducible tests, an owner-run workflow, and evidence that failure remains visible.