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.

ACT_RUNNER.md

@@ -0,0 +1,66 @@
+# 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.