orca-fleet

Turn a bounded set of issues on a repo you do NOT control into landed open-source contributions. Each actionable issue is skeptic-triaged (including a search of the upstream repo's OPEN PRs, not just its code), built on a fork with a failing-first test, reviewed build-blind, and opened as an etiquette-correct PR against the upstream default branch — or, where a maintainer PR already exists, shared as a quoted review-assist comment (an alternative PR only if maintainers invite one). The loop re-enumerates until the actionable set is dry. Merge is the maintainer's; the fleet never merges. Use when "contribute to this project", "open PRs for these upstream issues", "help out this OSS repo", "send fixes upstream", "we only have a fork". Not for a repo you own and can merge (that is clean-sweep — merged-SHA closure) and not for building a net-new project (ship-it).

Exhaust a finite backlog of findings to zero, PR-per-finding, on Orca. Sources: an audit/adversarial-review document, the issue tracker, or verified false documentation claims. Each finding is skeptic-triaged (reproduced or refuted with evidence), fixed on an integration branch with a failing-first test, build-blind reviewed, merge-verified, and closed with a linked SHA; the loop re-enumerates until dry. Use when "clean sweep", "close every issue", "drain the backlog", "fix everything in this audit", "the README lies — verify and fix it", or a broken test that fails deterministically (N/N, cause findable — deflake-it routes those here). Not for security/perf/deps/coverage-gaps/flakes (those are harden-it / speed-it / modernize-it / prove-it / deflake-it — different convergence proofs) and not for building new work (ship-it).

Turn intent or a frozen spec into a released, verified outcome on Orca. Entry is either a frozen spec (validate → decompose) or raw intent (grill → freeze → decompose); after freeze both enter one canonical pipeline: decompose → build (tested slices) → acceptance review → runtime-prove → land → release → observe, stopping at the highest release state you're authorized to reach (BUILT / PROMOTION_READY / RELEASED / DEPLOYED_AND_VERIFIED). Use when "build and ship this", "spec to shipped product", "ship this feature", or an autonomous build-to-release run. Not for closing an existing backlog (that's clean-sweep) or a foggy goal that needs charting first (that's map-it).

Give every critical path a test that dies under a semantics-preserving mutation. Map the untested critical surface (coverage × call-graph of the money/auth/data paths), write characterization tests that assert real behavior, prove each earns its keep by failing at its assertion under a mutation (harness still runnable — a compile break is not proof), and route surfaced bugs to a fix or backlog, looping until every confirmed critical path is mutation-audited. Use when "close the test gap", "cover the critical paths", "test debt", characterization/mutation testing — it owns missing coverage, not broken tests. Not for flake eradication (deflake-it), a deterministically failing test (clean-sweep), or building features with tests from the start (ship-it).

Establish a threat model and close it: audit → prove exploits → fix → RE-ATTACK the fix and audit the whole vulnerability class → re-audit, looping until a fresh full audit finds zero unrefuted P0/P1. STRIDE + OWASP Top 10 + OWASP LLM Top 10 + supply-chain. Use when "harden this", "security sweep", "red team", "close the security loop", or an unattended audit-fix-verify security run. The full adversarial loop — for a bounded per-diff security check use review-it's risk lens. Not for general backlog drain (clean-sweep) or a single PR verdict (review-it).

Resolve a foggy, multi-session goal into a frozen execution map that ship-it can consume — decisions, not deliverables. Chart a fog-of-war map of decision-tickets (only ticket what you can phrase sharply now), clear the research/decision frontier in parallel with HITL at each decision, and produce a frozen plan + a prepared DAG. Use when the goal is too big/foggy for one session, "chart this", "plan this epic", "I don't know the shape yet", or you can't yet authorize implementation. Its outcome is a decided plan; building is ship-it. Not for a foggy BUG (root-cause) or ready-to-build intent (ship-it).

Eliminate intermittent test failures to a declared confidence contract. Detect flakes by repeat-run + CI retry history, diagnose each with a loop that RAISES the failure rate (never a theory), fix the root cause and ratchet it red-by-revert, then re-run the whole suite for a consecutive green streak — local AND in CI — looping until the streak holds. Retry-wrappers as fixes are banned and grep-checked. Use when "kill the flaky tests", "deflake the CI", "flake zero", a flaky/intermittent suite. Not for a single hard bug with no suite-rate contract (root-cause) or deterministic failures (clean-sweep).

Bring a dependency / framework / platform surface current, safely — CI green at every merge. Inventory outdated + advisories with reachability triage → order by a compatibility graph → upgrade one dep or coherent group per PR, adapting call sites (code-level expand/migrate/contract) to get off old majors while keeping CI green → re-inventory until every major is current or pinned-with-a-reason. Use when "update the dependencies", "upgrade everything", "framework migration", "get off the old major", or an unattended dependency-currency run. Not for stateful DB schema/data migration across deploys (hand that to ship-it) or advisory exploit proof (harden-it).

Find the demonstrated root cause of a hard bug that has neither a frozen spec nor an enumerable backlog — a flaky failure, an intermittent production symptom, a concurrency bug, an unexplained regression. Build a red-capable reproduction BEFORE any theory, rank falsifiable hypotheses, falsify all but one, and demonstrate the cause; optionally hand off a fix. Use when "diagnose this", "why is this happening", "find the root cause", "debug this hard bug". Diagnosis, not remediation — the fix is a separate authorized handoff (ship-it / clean-sweep). Not for a whole flaky SUITE under a statistical streak contract (deflake-it) or an enumerable backlog (clean-sweep).

Bring declared user journeys within pre-declared performance budgets, proven by measurement. Controlled baseline (measure to a metric contract, not once) → profile the real bottleneck → fix PR-per-hotspot with a mandatory before/after → re-benchmark to the metric's statistical contract → add CI regression guards, looping until every journey is within budget or parked. Use when "the app is slow", "perf sweep", "Core Web Vitals", "get under budget", or an unattended perf-hardening run. Not for a per-diff perf opinion (review-it) or post-deploy watch alone (observe via ship-it).

Produce a trusted, read-only, SHA-bound verdict on a PR or branch — no fixing authority. Acceptance review (standards, frozen-spec compliance, test-adequacy) always; scope-triggered risk lenses (security, performance, accessibility, data-migration) when the change surface warrants. Findings quote their motivating line, carry severity, and are bound to the reviewed SHA. Use when "review this PR", "review queue", "is this ready to merge", a pre-merge quality/permission gate. Report-only — it never edits code (fixing is ship-it / clean-sweep). Not the full security loop (harden-it).