orchestration-bundle-candidate

# Orchestration Bundle Candidate Use this skill once per immaculate orchestrator activation. Consume only the controller-supplied task packet, execution contract, detail artifacts, effective-capacity snapshot, and expected bundle revision. ## Reply Contract 1. Return exactly one route decision: `direct_execution`, `needs_detail`, `macro_adjustment_request`, `blocked`, or `partial_completion`. 2. Return compact `orchestration_notes` citing the supplied task and contract refs. 3. For Config V3 `direct_execution` or `partial_completion`, always include exactly one `orchestration_bundle:` heading immediately followed by a code fence whose language tag is literally `json`. Put the schema identifier `ccb.loop.orchestration_bundle_candidate.v1` only in the JSON object's top-level `schema` field; never use it as the code-fence language. Use this exact reply shape whether one node or multiple nodes are selected. 4. Config V2 may omit the candidate only for deterministic one-node compatibility. A decomposed Config V2 route must include it. Candidate root fields are exactly `schema`, `task_id`, `bundle_revision`, `selection`, `nodes`, `integration`, and `policy`. Selection fields are exactly `workgroup_count`, `complexity`, `cutability`, `execution_shape`, and `rationale`. `workgroup_count` must equal the node count. `rationale` must be one non-empty line of at most 500 characters; target 300 characters or fewer and do not repeat node work packets in it. `...