Govern one GitHub issue

What you will prove

This quickstart uses one small GitHub issue to prove the minimum Midfleet operating loop: repository context, explicit ownership, a reviewable handoff path, a claim before edits, visible blocker handling, and durable completion evidence.

Before you begin

• A Midfleet Cloud account and selected workspace.
• A project connected to the intended GitHub repository and default branch.
• A team assigned to that project with analysis, implementation, and review responsibility.
• One online or project-assigned agent with the required repository access.
• A GitHub issue small enough to implement, test, and review in one bounded run.

1. Write a bounded GitHub issue

State the outcome, in-scope files or systems, exclusions, acceptance criteria, risk, and required evidence. Avoid broad requests such as improve the backend. The first run should have one observable result and a clear reviewer.

Outcome: <one observable result>
In scope: <files, package, or service>
Out of scope: <explicit exclusions>
Acceptance criteria:
- <testable condition>
- <testable condition>
Required evidence:
- pull request
- passing CI check
- reviewer decision

2. Refine the issue into governed work

Start refinement with a signed-in participant session. Review the returned status before accepting it; Hub remains authoritative for the current issue revision, artifact, and acceptance checks.

midfleet epic refinement start <owner>/<repo>#<issue-number>
midfleet epic refinement status <owner>/<repo>#<issue-number> --json
midfleet epic refinement accept <owner>/<repo>#<issue-number>

3. Check readiness before launch

Inspect project readiness, roster coverage, runtime routes, open blockers, evidence requirements, and allowed actions. Fix the typed blocker at its owning layer instead of spawning around it.

• route_ready must be true before invocation.
• can_launch must be true before launch.
• The intended launch action must appear in the current allowed actions.
• Repository readiness, agent heartbeat, and console reachability are separate signals.

midfleet workflow status --project <project-code> --json

4. Launch and follow the owned path

Open Control, select the same project and drafted invocation, review the compiled stages and evidence requirements, then launch only when the current allowed action permits it. The assigned agent should accept its handoff and claim the narrowest useful scope before editing.

• Use Workflow Manager for the live run and ordered stage path.
• Use Handoffs for current ownership, acceptance context, and completion state.
• Use Claims for leased file, branch, task, or runtime scope.
• Use Blockers and Approvals for missing decisions or risk gates.
• Use Workflow Runs for durable diagnosis and evidence history, not for mutation.

5. Verify evidence-backed completion

Completion is valid only when the run and handoff have the required evidence, blockers are resolved, the reviewer decision is recorded, and Hub accepts the supported completion transition.