Files

T

Christopher Clendening 96b7ff9766 feat: Add foundational documentation for security, workflow, and project management

- Create SECURITY.md to outline security policies and practices.
- Establish WORKFLOW.md detailing the project lifecycle from planning to retrospective.
- Introduce decision log structure in decisions/README.md for tracking architecture decisions.
- Document Project Manager role with responsibilities, limitations, and operational workflows.
- Implement templates for ADRs, bugs, meetings, projects, retrospectives, RFCs, roadmaps, and sprints.
- Set up memory logs for architecture and company-wide lessons learned.
- Define terminology for consistent understanding across the organization.

2026-07-30 13:34:07 -04:00

3.2 KiB

Raw Blame History

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.

3.2 KiB Raw Blame History