Operating Flow

Ledger Execution Path

The current operating-system canon expects governed work to move through a bounded sequence.

flowchart LR
    A["Startup"] --> B["GitHub sync"]
    B --> C["Task routing"]
    C --> D["Authority check"]
    D --> E["Preflight"]
    E --> F["Execution"]
    F --> G["Review and closeout"]
    G --> H["Evidence and memory reconciliation"]

Meaning Of Each Stage

Stage	Purpose
Startup	load agent startup contract and role context
GitHub sync	use the governing issue as the execution anchor
Task routing	resolve task type, repo scope, change level, and obligations
Authority check	confirm lane ownership and escalation boundaries
Preflight	lock the expected route before real work starts
Execution	do the bounded task without silent scope drift
Review and closeout	validate against route-aware acceptance requirements
Evidence and memory reconciliation	preserve closure proof and handoff truth

Canon Sources Behind This Flow

• docs/agents/AGENT_STARTUP_PROTOCOL.md
• docs/operating-system/models/TASK_ROUTING_AND_LIFECYCLE_MODEL.md
• docs/operating-system/models/ORBITRA_GOVERNED_TASK_PREFLIGHT_MODEL.md
• docs/operating-system/playbooks/REVIEW_AND_CLOSEOUT_PLAYBOOK.md
• meta/task-routing.yaml

Why This Flow Matters

The repo is large. Without a stable execution path, contributors start reading surfaces in the wrong order and mixing draft truth with canon truth.