Orchestra ecosystem Guidelines

When operating within this repository or when this plugin is active, adhere to the following routing and execution guidelines:

1. Governance Layer: The Steward (business alignment, scope, SDLC) and The Governor (legal, compliance, privacy, IP, licensing) sit above the Conductor. Governance review is dynamic, need-based, and adapts to the active operating mode (Ideation, Prototype, Implementation, Audit, Release). The Conductor cannot override governance decisions.
2. Routing Layer: Conductor is the exclusive router and workflow orchestrator. Do not invent custom subagent chains or bypass the Conductor for complex tasks.
3. Implementation Layer: Ponytail handles focused implementation, strictly keeping code minimal, reversible, and free of over-engineering.
4. Communication Layer: Caveman controls output compression to preserve context limits during long multi-file operations.
5. Domain Specialists: Specialists (Clockwork, Cloak, Cipher, Chronicler, Weaver, Scribe, Overseer, Dagger) exclusively own their respective domains.
6. Source of Truth: Do not guess specialist logic or rules. The authoritative source of truth for any skill's behavior is always located in its corresponding skills/*/SKILL.md file. Always defer to the explicit instructions in those files.
7. Local Sync Preflight Rule: Before starting a new local development phase or repository-editing session, run python scripts/preflight_sync_check.py against origin/main. Do not begin edits if the local branch is behind, diverged, dirty, or unverifiable. Ahead-only state may proceed, but the unpublished commits must be reported.
8. Delegated Phase Progression Rule: In delegated phase mode (DELEGATED), Conductor consumes Arbiter transition decision records (AUTO_CONTINUE, AUTO_REMEDIATE_AND_REVALIDATE, WAIT_FOR_EVIDENCE, WAIT_FOR_CAPACITY, ESCALATE_HUMAN, STOP) inside human-authorized execution envelopes. No transition outside delegated authority is permitted. External actions remain default-deny.
9. Cross-Specialist Coordination Layer: The Tuner is a coordination specialist invoked only by Conductor for material multi-domain work. It assembles specialist-owned contract references, detects missing ownership, contradictions, stale revisions, and required re-entry. It does not route, implement, validate itself, approve continuation, or create authority. Obvious single-owner work bypasses The Tuner. The canonical protocol is docs/routing/CROSS_SPECIALIST_COORDINATION_PROTOCOL.md.
10. Evidence-Bound Governed Transition Rule: Platform capability never equals governance readiness: PLATFORM_CAN_EXECUTE != GOVERNANCE_READY_TO_TRANSITION, GITHUB_CAN_MERGE != GOVERNANCE_READY_TO_MERGE, API_SUCCESS != VERIFIED_STATE, and NO_EVIDENCE != APPROVAL. Missing, pending, stale, skipped, cancelled, timed-out, contradictory, or failed required evidence is never permission. Evidence is bound to the exact current state and is invalidated when that state changes. A red canonical baseline blocks ordinary progression except for explicitly authorized bounded remediation. A state-changing action is not complete until an independent canonical read verifies the result. This rule constrains already-granted authority and never creates new authority. Autonomous or delegated merges must additionally follow docs/governance/AUTONOMOUS_MERGE_READINESS_PROTOCOL.md, including exact-head validation, immediate pre-merge head re-read, expected-head protection when supported, and independent post-merge verification.
11. Governed Autonomy Profile Rule: Risk mode, progression mode, and Governance Profile are separate. HUMAN_GOVERNED is the safe default; SEMI_AUTONOMOUS may progress through granted PR/CI work but stops before merge and major phase progression; FULL_AUTONOMOUS may continue only through explicitly granted transitions while exact-state evidence and repository policy remain green. Profiles reduce authority and never create it. Increasing autonomy requires explicit human authorization; children cannot exceed parents; release, deployment, policy activation, destructive action, force push, history rewrite, and authority expansion remain separately controlled.
12. Runtime Architecture Placement Rule: New or migrated orchestra_runtime code must be placed under the bounded architecture defined by machine/governance/runtime-architecture-boundaries.v1.json and must pass python scripts/validation/validate_architecture_boundaries.py. Do not add new flat runtime implementation modules, unrecognized runtime package roots, DTOs/DPOs outside their declared zones, repository abstractions outside port/persistence zones, domain dependencies on infrastructure/entrypoints, or production runtime dependencies on repository internal/. If ownership is ambiguous, stop at Clockwork architecture review before implementation; validation success never grants implementation or release authority.
13. Covenant System-Coherence Rule: The Covenant synthesizes separate Steward system-intent and Governor protected-obligation judgments with specialist and PRAI evidence. It does not vote, authorize, or override the Prime Directive, either owning governance decision, exact candidate binding, or Arbiter transition ownership. A green PRAI or specialist result cannot suppress a cross-layer contradiction; unresolved conflict, missing durable evidence, unknown state, or invalid reconciliation fails closed.

Repo Source vs Runtime Rule

Apply persistent project updates only to Git-tracked repo source paths. Do not treat .agents/, generated runtime copies, installed adapter copies, cache folders, or local execution mirrors as the source of truth. Before editing, verify the target file path is inside the tracked repo source and not inside .agents/. If a task touches skill files, update skills/<skill>/... in the repository source, not .agents/skills/<skill>/.... Runtime copies may be inspected for comparison, but persistent fixes must be applied to the Git-tracked source.