bounded-orchestration-contract

Bounded Orchestration Contract

Use this skill only when separate planning, review, or independent execution slices materially improve a non-trivial task. Small or tightly coupled work stays with the root.

This is an opt-in coordination discipline, not a scheduler, model router, provider bridge, permission grant, or persistent configuration layer.

Authority

The root owns intent, canonical plan state, delegation decisions, integration, safety, verification, and the final answer. Planner and Reviewer are read-only. Executors receive only their bounded slice. Explicit no subagents or equivalent instructions disable delegation.

Plan protocol

Version every canonical plan. Use exactly these first-line states:

• PLAN_DRAFT: first complete candidate plan.
• PLAN_REVISE: the current version has material findings.
• PLAN_APPROVED: the exact reviewed version may release executor work.

The Reviewer returns PLAN_APPROVED or PLAN_REVISE. Stop immediately on approval. Never exceed five total review rounds. If round five still returns PLAN_REVISE, halt before executor release and report unresolved findings.

Findings ledger

Assign stable IDs in discovery order: F-001, F-002, and so on. Never renumber or silently drop a finding.

Each entry contains:

ID: F-001
Status: OPEN | INCORPORATED | REJECTED
Summary:
Reason:
Plan version introduced:
Plan version disposed:

Every latest finding must be INCORPORATED or REJECTED with a concrete reason before approval. OPEN, missing, duplicated, stale-version, or empty-reason entries block PLAN_APPROVED. Rejection means the root or Planner has supplied an evidence-based reason; it does not mean the finding disappeared.

Review loop

1. Root prepares the task constraints, acceptance criteria, repo facts, risks, proposed slices, and verification.
2. Planner or root emits PLAN_DRAFT version 1.
3. Reviewer checks only the canonical current version and returns a state plus findings.
4. Planner or root revises the complete plan and updates every finding disposition.
5. Root validates version and ledger integrity before another review.
6. Repeat only while material findings remain, up to five reviews.