# ACT_RUNNER.md

ACT Runner is CI for Local LLC: build, test, validation (`COMPANY.md`). It is deployed and
reachable today, with runners registered for both Linux and macOS. This document is DevOps
Engineer policy, owned per `ORGANIZATION.md`.

## Runners

| Runner | Label placeholder | Used for |
|---|---|---|
| Linux | `<RUNNER_LABEL_LINUX>` | Default for backend/ML/general builds and tests |
| macOS | `<RUNNER_LABEL_MACOS>` | Anything requiring macOS-specific toolchains (e.g. iOS builds) |

Replace the placeholders with the actual registered runner labels once confirmed; workflow
files should target a label, never assume "whichever runner picks it up first" for
platform-specific work.

## When CI runs

- On every push to a PR branch (per branch naming in `GITEA.md`).
- On merge to `main`.
- Not on pushes to `main` directly, because pushes to `main` directly shouldn't happen
  (`GITEA.md`) — if CI catches one, that's itself a signal worth flagging to DevOps.

## What a passing run means

A passing ACT Runner run means the build succeeded and the automated test suite passed. It does
**not** mean QA sign-off — those are separate gates in `WORKFLOW.md`. CI passing is necessary
for a PR to merge; it is not sufficient for a Task to close. Don't let "CI is green" be
mistaken for "verified" — see `EMPLOYEE_HANDBOOK.md` on the fabrication rule; reporting a task
done because CI passed, without QA verification, is exactly the kind of shortcut that rule
exists to prevent.

## Failure policy

- A failed run blocks merge, full stop — no manual override by the PR author.
- The engineer who owns the PR is responsible for the fix, not DevOps, unless the failure is
  infrastructure-level (runner offline, environment misconfiguration) rather than code-level.
- DevOps triages ambiguous failures (is this the code or the pipeline?) when the PR author can't
  tell — that's a legitimate escalation, not a stall.

## Retry policy

- A CI failure is retried once automatically if the failure signature matches a known-flaky
  pattern the DevOps Engineer has documented (record these in `memory/lessons-learned.md` as
  they're identified, so the list doesn't live only in someone's head).
- Anything else is not auto-retried — a red run is investigated, not re-rolled until it happens
  to go green. Re-running a failing job hoping for a different answer is the CI equivalent of
  the fabrication rule violation in `EMPLOYEE_HANDBOOK.md`.

## Deployment policy

- ACT Runner's scope here is build/test validation, not production deployment automation —
  deployment pipelines beyond CI are a DevOps Engineer responsibility to design and document
  per project in that project's `PROJECT.md`, referencing this file for the CI contract they
  build on top of.
- Any workflow that deploys to a real environment (not just runs tests) requires a Security
  Engineer review of the workflow file itself, since CI credentials and deploy targets are a
  supply-chain surface (`SECURITY.md`).

## Ownership

DevOps Engineer owns `.gitea/workflows` (or equivalent) configuration across project
repositories. Changes to shared CI configuration that affect multiple projects should be
documented as an ADR (`DECISIONS.md`) if they change how *all* projects validate code, not just
one.