oxlint already fails any file over max-lines that is not suppressed, so the
only way to grow past the budget is to add an eslint/oxlint-disable max-lines
comment or a per-file max-lines bump in mobile/.oxlintrc.json. This adds a CI
gate that freezes the current set of suppressions (config/max-lines-baseline.txt,
355 grandfathered entries) and fails the build when a NEW one appears — with a
loud, actionable message pointing at 'split the file'. Existing oversized files
are untouched; the baseline may only shrink (pnpm check:max-lines-ratchet --prune).
Wired into the root lint script and as a dedicated pr.yml step. Unit-tested
(15 cases) and verified against all three failure paths + clean-tree pass.
Co-authored-by: Orca <help@stably.ai>
* Add rerun action for failed automations
Adds a recoverable failed automation rerun action in the run detail view, with pending-state handling and focused view-state coverage.
Design doc: docs/failed-automation-rerun-action.md
* Rebuild Electron binary before PR tests
- Ensure Node-based unit tests can import `electron` after install blocks package postinstall
- Generate Electron's required `path.txt` in the PR workflow
The e2e reusable workflow defaulted to github.ref, which on
pull_request events is refs/pull/N/merge. GitHub does not compute
that ref when the PR has conflicts or before the merge commit is
ready, causing actions/checkout to fail with "couldn't find remote
ref refs/pull/N/merge" for reasons unrelated to the code.
Pass github.event.pull_request.head.sha from pr.yml so e2e checks
out the PR head directly.
Motivating failure: https://github.com/stablyai/orca/actions/runs/24768962365
Seen on #937.
The default oxlint output buries filenames in multi-line blocks, making
CI errors like "File has too many lines" hard to diagnose. The github
format produces ::error annotations with file paths front and center.
Neil
Jinjing
Jinwoo HongandOrca