/orbit — Complete Orbit

CRITICAL: Run HARNESS_DIR=$(epic path) first. NEVER use .harness/ in the project directory.

You are entering Orbit mode — the full autonomous pipeline from spec to PR in one shot.

Phase Recovery Protocol

At the start of every response during an active orbit:

1. Run ls $HARNESS_DIR/orbit/PIPELINE-*.json 2>/dev/null
2. Find the file with "status": "running"
3. Read it. Verify phase matches where you left off
4. If phase is ahead of where you think you are, trust the file — you may have compacted
5. Conflict resolution (crash-mid-update): If phase_history contains an entry for the current phase with a completed timestamp, treat that phase as done and advance to the next phase — phase_history wins over the phase field when they disagree.
6. Resume from the resolved phase. Do NOT re-ask mode selection, re-run spec, or re-discover
7. Worktree recovery: If worktree_name is set in pipeline state:
   • Check if worktree still exists: git worktree list | grep "{worktree_name}"
   • If exists: cd into the worktree path to continue work
   • If not found: worktree was cleaned up externally — abort orbit with warning, set "status": "aborted"

If no file with "status": "running" exists, orbit was not started or has completed. Do not invent one.

Crash recovery: If updated_at is older than 45 minutes and the pipeline is in status: running, assume a crash occurred. Read the state, determine the last completed phase from phase_history (rule 5 above applies), and resume from there. Report the recovery to the user.

Step 0: Preflight

Concurrent-orbit guard — before starting, run:

epic orbit lock   # exit 1 + "another orbit is running" if one is active → STOP

On success you own the guard; run epic orbit unlock when the pipeline reaches a terminal state (complete/aborted). If a crashed orbit left the lock behind, lock reclaims it automatically once no PIPELINE-*.json is running.

Initialize pipeline state at $HARNESS_DIR/orbit/PIPELINE-{timestamp}.json:

{
  "id": "{timestamp}",
  "mode": null,
  "phase": "auto_detect",
  "status": "running",
  "spec_file": null,
  "goal_slug": null,
  "branch": null,
  "worktree_name": null,
  "original_cwd": null,
  "audit_fail_count": 0,
  "max_retries": 3,
  "audit_report": null,
  "pr_url": null,
  "deadline": "{ISO-8601, now + 30 minutes}",
  "started_at": "{ISO-8601}",
  "updated_at": "{ISO-8601}",
  "phase_history": []
}

Step 1: Auto-Detect Mode

DO NOT ask the user for mode selection. Auto-detect the best path:

Detection Logic

Detection Process

1. Check for PRD/requirements docs: ls {project}/PRD*.md {project}/docs/PRD*.md {project}/requirements*.md 2>/dev/null
2. Evaluate user request clarity:
   • Specific: contains concrete feature descriptions, acceptance criteria, or technical constraints → direct
   • Vague: "build X", "improve Y", "add Z" without details → council
3. Record detected mode in pipeline state ("mode": "direct|council|interactive")
4. Report mode choice to user as a notification, not a question: "Orbit mode: {mode} (auto-detected)"
5. Proceed immediately to the matching step below — do not wait for confirmation

Step 2A: Direct Mode (clear request → auto-spec)

Use when: Request is specific and actionable.

1. Read the user's request + any existing docs (PRD, README, AGENTS.md)
2. Generate spec directly at $HARNESS_DIR/specs/SPEC-{timestamp}.md, run the Readiness gate from skills/spec/SKILL.md (step 3) on it, settle every GAP: from the request and codebase yourself, record each as GAP: … → settled: … (assumption) under the spec's ## Readiness Gate, then write status: approved. If a gap cannot be settled without the user, downgrade to council mode instead of guessing.
3. Record via epic mem add --title "Orbit: {mode} mode decision" --type decision --importance 0.9 --body "CONTEXT"
4. Proceed immediately to Step 3 — no approval gate

Step 2B: Council Auto-Spec (complex/vague request → council)

Use when: PRD exists or request needs framing.

1. Gather the user's request from conversation context
2. Launch 4 parallel sub-agents (Architect, Skeptic, Pragmatist, Critic) — each receives ONLY the request + codebase context, NOT the full conversation (anti-anchoring)
3. Synthesize: list agreement/disagreement, produce recommended approach
4. Generate spec at $HARNESS_DIR/specs/SPEC-{timestamp}.md, run the Readiness gate (spec skill step 3), settle every GAP: from the council output and record each under ## Readiness Gate, then write status: approved
5. Record via epic mem add --title "Orbit: council decision" --type decision --importance 0.9 --body "CONTEXT"
6. Proceed immediately to Step 3 — no approval gate, no "orbit go"

Step 2C: Interactive Mode (explicit user choice only)

Use when: User explicitly requested interactive mode.

1. Tell user to run /discover → /spec, then say "orbit go". STOP and wait.
2. On resume: load latest SPEC-*.md with status: approved. Proceed to Step 3.

This mode is never auto-selected. It requires explicit user opt-in.

Step 3: Build (Go)

1. Load spec, extract goal_slug
2. Git preflight: verify clean working tree and not on detached HEAD:

   [ -z "$(git status --porcelain)" ] || (echo "ERROR: Dirty working tree or untracked files. Commit or stash first." && exit 1)
   git symbolic-ref -q HEAD || (echo "ERROR: Detached HEAD. Checkout a branch first." && exit 1)

3. Worktree isolation: Create an isolated git worktree:

   git worktree add .harness/worktrees/orbit-{goal_slug} -b orbit-{goal_slug} origin/{default-branch}
   cd .harness/worktrees/orbit-{goal_slug}

   • .harness/worktrees/ is host-neutral. Do NOT use .claude/worktrees/ — it is meaningless on Codex and Antigravity.
   • Record worktree_name and original_cwd in pipeline state
4. Plan tasks from Requirements (R1, R2...)
5. Execute with sub-agents — TDD, debug on failure, verify before done
6. Handle states: DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED
7. Integrate: full test suite, verify ACs

Step 4: Audit

1. Gather scope via git diff --stat
2. Classify changed files (API, Frontend, DB, Backend, Tests, Infra)
3. Launch parallel sub-agents: Reviewer, Auditor, Test runner (+ scope-specific)
4. Synthesize Audit Report: Quality/Security/Performance PASS/WARN/FAIL + Spec Coverage
5. PRESERVE audit report in pipeline state audit_report field

Step 5: Verdict

• All PASS + all AC verified → proceed to Eval (if eval.yaml exists) or Ship
• WARN → log, auto-proceed
• FAIL → increment audit_fail_count:
  • < 3: plan fixes from action items, execute, return to Step 4
  • ≥ 3: PAUSE — ask user "continue or abort?"

Step 5.5: Eval (optional — only if eval.yaml or benchmarks exist)

1. Check for eval config — eval is active if ANY of these exist:
   • $HARNESS_DIR/eval/eval.yaml
   • benchmarks/baselines/latest.json in CWD (in-repo baseline)
   • benchmarks/eval_runner.py in CWD (auto-detected benchmark)
2. If eval is active, run epic eval --json via the eval skill
3. Eval PASS → proceed to Ship
4. Eval FAIL (regression detected) → increment audit_fail_count:
   • < 3: plan fixes, execute, return to Step 4
   • ≥ 3: PAUSE — ask user "continue or abort?"
5. If no eval config and no benchmarks detected, skip this step entirely

Step 6: Ship

1. Gate: verify PASS audit report exists
2. Integration verification — run directly in worktree:
   • Clean build artifacts first: cargo clean / npm run clean / equivalent
   • Full build from scratch · complete test suite · linter + formatter
   • Fail → STOP. Do NOT create PR.
3. Git hygiene: conventional commits, rebase, squash fixups
4. Create PR via gh pr create with spec + audit report in body
   • Record the URL in pipeline state as pr_url. epic orbit unlock warns when a pipeline reaches complete without it.
5. CI watch — probe first, then watch:

   gh pr checks <PR_NUMBER> --json name,state

   • Checks exist → run gh pr checks <PR_NUMBER> --watch, auto-fix failures.
   • Empty result (no CI configured on the repo) → skip the watch. Log "No CI configured, skipping CI watch", append a phase_history entry recording "ci_watch": "skipped", and proceed to Step 7 (evolve runs regardless of CI outcome, so the pipeline must never wait on checks that will never appear).
6. Exit worktree: Return to original directory and keep the worktree

Step 7: Evolve

Run the evolution engine to analyze this session and generate/improve skills.

1. Always run — regardless of CI outcome:

   epic-harness reflect

   This triggers the Ring 3 loop: observe → analyze → seed evolved skills → update metrics.

   If $HARNESS_DIR/projects/{slug}/pending_synth.jsonl has records with status: "pending", synthesize each — launch one subagent per manifest (use your host's subagent mechanism; do NOT name a model or CLI), then apply the body it produced:

   epic-harness evolve accept-synth --skill <name> --file <body.md>

   Unconsumed manifests leave the template skill body in place.

2. If CI green (all checks passed): additionally run

   epic-harness reflect --context --days 1

   and record the successful orbit pattern into memory:

   epic mem add --title "Orbit: {goal_slug} succeeded" \
     --type pattern --importance 0.7 \
     --body "Orbit completed. Mode: {mode}. AC: all verified. PR: {url}. Stack: {stack}."

3. Report the evolution outcome in the final summary (evolved skills generated, score trend).
4. Update pipeline state: "phase": "evolve", "status": "complete", then run epic orbit unlock.

Step 8: Report

## Orbit Complete
- Pipeline: PIPELINE-{id}
- Mode: {direct|council|interactive} (auto-detected)
- Spec: SPEC-{timestamp} ({goal_slug})
- Branch: orbit-{goal_slug}
- Worktree: orbit-{goal_slug} (preserved for PR)
- PR: {URL}
- Audit retries: {count}

### Phase Summary
| Phase | Status | Retries |
|-------|--------|---------|
| Spec | approved | 0 |
| Go | complete | 0 |
| Audit | PASS | {count} |
| Eval | {PASS|SKIPPED} | 0 |
| Ship | complete | 0 |
| Evolve | complete | 0 |

### Evolution
- Skills evolved: {count}
- Score trend: {improving|stable|declining}

Red Flags

• Interactive mode proceeding without spec approval (direct and council modes auto-approve)
• Continuing after 3 audit failures without user consent
• Skipping isolated integration test
• Shipping with FAIL in security audits
• Losing audit report between phases
• Creating branch with dirty working tree
• Losing worktree reference between phases
• Skipping evolve step after ship (evolve must always run, even if CI fails)