orca-fleet

Drain a maintainer's inbound pull-request queue: every open contribution is absorbed with the contributor's authorship preserved and a RED-on-base / GREEN-on-head regression receipt, refuted with a reproduction attempt on current main, closed as superseded or duplicate citing the winning SHA, or parked with a named ask to the contributor. The unit is one inbound PR — someone else's diff, not your finding. Use when "review and merge the open PRs", "drain the PR queue", "absorb these community contributions", "we have 40 stale inbound PRs", "close out the contributor backlog". Not for opening PRs on a repo you cannot merge (oss-contribute), a read-only verdict on one diff (review-it), or fixing findings you wrote yourself (clean-sweep) — the diff, the authorship, and the contributor round-trip are what make this its own mission.

Drive a FROZEN page/flow/component set to WCAG 2.2 AA conformance (the engineering target that satisfies EAA / ADA / Section 508, which formally reference WCAG 2.1/2.0): a deterministic axe-core oracle clean on the surface plus a mandatory negative control (revert the fix, the violation returns), with the hard ~30-40% automation ceiling forcing screen-reader and cognitive criteria into a first-class human-AT park. The unit is one success-criterion violation instance on the frozen surface. Use when "accessibility", "a11y", "WCAG conformance", "screen reader", "keyboard-only operability", "ARIA", "axe-core", "Section 508 accessibility", "color contrast". Not for building a keyboard feature or shortcut (ship-it), a security exploit loop (harden-it), a PR merge verdict or a per-diff accessibility lens (review-it), a discovered backlog (clean-sweep), or standards attestation (attest-it).

Prove a codebase or change-set conforms to a standard — EU AI Act Art-12/50, SOC 2, NIST SSDF — with auditor-grade, independently re-derived evidence, or name the gaps. The unit is one obligation from a FROZEN standard catalog (standard@version), not a discovered finding: enumerate the obligations, gather evidence bound to authoritative state for each, have an independent session re-derive it, and mark each control VERIFIED or GAP. Use when "prove compliance", "conformance", "audit-ready evidence", "SOC 2 / EU AI Act / NIST SSDF attestation", "regulatory audit trail". Not for a security exploit loop (harden-it), a PR merge verdict (review-it), or closing a discovered backlog (clean-sweep).

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 the backlog is yours to merge: "clean sweep", "close every open issue", "drain the backlog", "our docs are out of date with the code", "the API contract drifted from the docs", "fix everything in this audit", "the README lies — verify and fix it", "fix this broken test" when it fails deterministically (N/N, same assertion, cause findable — deflake-it and prove-it both route 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).

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).

Cover a public surface with documentation that is true: extract the surface with a script at the base head, map coverage per Diataxis quadrant by grep-able evidence, freeze the gap list, write one cell per unit reference-first from code archaeology, and bind every factual claim to a file:symbol or a pasted run — with the negative control that renaming the anchored fact turns the claim check RED. The unit is one (public-surface entity x quadrant) cell. Use when "document this project", "our docs have huge gaps", "write the reference docs", "the API is undocumented", "new hires cannot find anything", "docs coverage". Not for docs that already exist and have gone stale or out of date: false claims in docs are clean-sweep (source=doc-claims), syncing docs to one wave's diff is ship-it's doc-sync unit, and stale runtime doctrine is pin-it.

Verify an app on a real device or emulator and fix what only hardware shows: pair a device session through Orca's emulator/device skills, capture a pre-change regression baseline, reproduce the defect on-device with captured artifacts, fix it, and re-verify the same flow on- device at the head SHA — with the negative control that reverting the fix reintroduces the on- device failure. The unit is one device-observed defect (or one device QA pass over a flow). Use when "test on a real device", "works on desktop, breaks on mobile", "emulator QA", "on-device bug", "verify on hardware", "a regression no desktop run reproduces", "physical device testing". Not for web perf budgets (speed-it), WCAG conformance (access-it), test-coverage gaps (prove- it), or a PR verdict (review-it).

Install a written, numbered, tool-enforced quality bar for a repo: detect the constraint dimensions (coverage, security scanning, perf budgets, a11y, architecture boundaries) with measured current values, freeze them with thresholds into a committed CONSTRAINTS.md at a human gate, wire one machine check per dimension, and prove every gate FIRES — on an injected violation in a throwaway worktree before CI, and on a canary PR that must fail CI after — then guard the bar itself against quiet lowering. The unit is one constraint dimension. Use when "set the quality bar", "define our standards", "make CI enforce", "stop shipping junk", "quality gates", "enforce the budget", "constraint-driven", "bar keeps slipping". Not for closing test debt (prove-it), journey-level perf optimization (speed-it), a WCAG surface sweep (access-it), external-framework conformance (attest-it), or a threat-model loop (harden-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 the ask is the whole adversarial loop: "harden this", "red team", "close the security loop", "harden this service against SQL injection and auth bypass", "audit then exploit then re-attack", or an unattended audit-fix-verify run. The full adversarial loop — for a bounded per-diff security check use review-it's risk lens. Not for shipping one authorized fix (ship-it), general backlog drain (clean-sweep), a single PR verdict (review-it), or routine dependency-advisory currency with no exploit proof (modernize-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).

Land a stateful schema or data change across deploys with old and new code valid at every step: expand → dual-write → backfill → switch reads → zero-readers → retire-writes → zero-writers → contract, each phase its own deployed and baked change, each with a down path that was written AND run, dual-validity proven both directions, and a parity probe GREEN after backfill and archived before the old shape is dropped. The unit is one migration PHASE of one table or shape. Use when "migrate the database", "rename this column safely", "expand/contract migration", "backfill this table", "split this table without downtime", "we cannot take downtime for this schema change", or a stateful dependency upgrade. Not for ordinary feature delivery through one release (ship-it), code-only dependency or framework currency (modernize-it), restructuring code behind unchanged behaviour (reshape-it), or a backlog of findings (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", "move from Postgres 12 to 16", or an unattended dependency-currency run. Not for stateful DB schema/data migration across deploys (hand that to migrate-it), ordinary feature delivery (ship-it), or advisory exploit proof (harden-it).

Make a surface operable: every path in a frozen set answers its on-call questions from telemetry alone, every alert is symptom-based with two severities and a justified threshold, every alert has a linked runbook and has been test-fired, and an induced staging failure is located by a fresh worker with NO source access — the oracle a narrator cannot fake. The unit is one path times its 2-4 on-call questions. Use when "make this operable", "we were blind during the incident", "add observability", "instrument this service", "we cannot tell what happened at 3am", "set up alerts and runbooks". Not for diagnosing a live failure (root-cause), a post-deploy canary on a change you just shipped (ship-it's release states), a latency budget (speed-it), an exploit (harden-it), closing a findings backlog (clean-sweep), or a blanket "make this production-ready" ask — that is a mission chain, not one mission.

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 the target is upstream and unmergeable by you: "contribute to this project", "open PRs upstream", "send fixes upstream", "we only have a fork", "help out this OSS repo". 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).

Re-witness and re-pin the fleet's runtime-mechanics doctrine against the installed control-plane binary after an upgrade or a drift signal: enumerate every mechanics claim in runtime policies, scripts, and mission dispatch preambles, load the version-matched guides the binary serves, replay each claim live, and patch what lags — kept claims carry receipts, removed claims carry archived refutations. The unit is one mechanics claim. Use when "Orca updated", "re-pin the runtime contract", "policy lags practice", "the guides say otherwise", "our control-plane dispatch docs are stale", "a receipt shape appeared that the runtime guides don't describe". Not for docs that drifted from your own code or API contract (clean-sweep), dependency/framework upgrades (modernize-it), or a PR verdict (review-it).

Give every critical path a test that dies under a behavior-changing 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", "pin a characterization net", "test debt", "add tests before we refactor", characterization/mutation testing, missing coverage. Not for broken tests, nor flake eradication (deflake-it), a deterministically failing test (clean-sweep), building features with tests from the start (ship-it), or restructuring a module's interface once the net exists (reshape-it — its DEEPEN units consume this mission's characterization net).

Deepen a lived-in codebase's confirmed hot modules without changing behaviour: a churn-weighted shallowness inventory finds the modules whose interfaces are too wide for what they hide, a human confirms the target surface, a mutation-audited characterization net (prove-it's, consumed here) is pinned BEFORE any restructure, and each module is deepened one seam at a time with build-blind review. The unit is one module-deepening (one interface shrink at one seam). Use when "this module is a god file", "the interface is wider than the implementation", "too many imports to change anything", "architecture erosion", "refactor the hot path safely", "shallow modules", "deep modules". Not for dependency/framework upgrades (modernize-it), a findings backlog (clean-sweep), missing tests (prove-it — though reshape-it borrows its net), or perf (speed-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 this diff", "is this diff ready to merge", "review this PR for accessibility", "check this component in the diff", "review queue", a pre-merge quality/permission gate; an attached request to fix what you find does not move the verdict — it routes out. Report-only — it never edits code (fixing is ship-it / clean- sweep). Not the full security loop (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", "why does this fail only in CI", "find the root cause", "debug this hard bug", diagnosis. Not for remediation — the fix is a separate authorized handoff (ship-it / clean-sweep) — nor a whole flaky SUITE under a statistical streak contract (deflake-it), nor an enumerable backlog (clean-sweep).

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", "ship this fix", "land this change", "build me this feature", or an autonomous build-to-release run. Not for closing an existing backlog (clean-sweep), diagnosing why a build or test fails (root-cause), or a foggy goal that needs charting first (map-it).

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", "LCP regression on mobile", "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).