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.

SECURITY.md

@@ -0,0 +1,67 @@
+# SECURITY.md
+
+Security policy for Local LLC, owned by the Security Engineer role (`ORGANIZATION.md`) with
+standing authority to block any merge on a finding — a block only the Security Engineer or the
+Founder can lift (`WORKFLOW.md`, `EMPLOYEE_HANDBOOK.md`).
+
+## Secrets
+
+- No secret, credential, API key, or token is ever committed to a Gitea repository — including
+  in test fixtures, example configs, or commit history that gets later "cleaned up." Once
+  committed, treat it as compromised: rotate it, don't just remove it from the latest commit.
+- Secrets live in the deployment environment's secret store (Portainer-managed secrets, or the
+  runner's secret configuration for ACT Runner jobs — see `ACT_RUNNER.md`), never in a
+  repository, project doc, or Plane task description.
+- `.env.example` style files document *which* variables are needed, never real values.
+
+## Authentication
+
+- Every AI employee authenticates as itself (its own Gitea/Plane identity per
+  `ORGANIZATION.md`/`GITEA.md`) — never through a shared credential shared across roles.
+- Any project that adds its own authentication (user-facing login, service-to-service auth) gets
+  a Security Engineer review of the auth design before implementation begins, not just at PR
+  review — auth design mistakes are expensive to unwind after the fact.
+
+## Containers
+
+- Base images are pinned to a specific version/digest, not a floating `latest` tag.
+- Containers run as a non-root user unless there's a specific, documented reason they can't.
+- New container images or significant Dockerfile changes get a Security Engineer review before
+  merge, the same as auth changes.
+
+## Dependencies
+
+- Adding a new dependency is a deliberate choice, not a default — prefer what's already in the
+  project's dependency set over adding an equivalent new one.
+- New dependencies are checked for known vulnerabilities and reasonably active maintenance
+  before being added, not after a scan flags them post-merge.
+- Dependency version bumps that aren't purely patch-level get a changelog check, not a blind
+  bump — especially for anything touching auth, crypto, or serialization.
+
+## Supply chain
+
+- CI workflow files (`.gitea/workflows` or equivalent) that touch deployment credentials or
+  publish artifacts require Security Engineer review, per `ACT_RUNNER.md`'s deployment policy.
+- Third-party GitHub Actions / Gitea Actions used in workflows are pinned to a commit SHA, not a
+  mutable tag, wherever the action supports it.
+- Any script that downloads and executes code from an external source at build or runtime is
+  treated as a supply-chain risk requiring explicit Security Engineer sign-off — this mirrors
+  the Founder-level prohibition on downloading/executing untrusted files, applied to CI/build
+  pipelines.
+
+## Reporting and handling findings
+
+- A Security Engineer finding attaches a `security-hold` label in Plane (`PLANE.md`) and blocks
+  merge until resolved or explicitly overridden by the Founder.
+- Findings are documented with enough detail for the responsible engineer to actually fix the
+  issue, not just "this is insecure" — see `EMPLOYEE_HANDBOOK.md` on what a real review looks
+  like; the same standard applies to security findings.
+- A pattern of findings in the same area (e.g. repeated secret-handling mistakes in one project)
+  gets recorded in `memory/lessons-learned.md` so it's caught earlier next time, not just
+  fixed reactively each time it recurs.
+
+## What Security does not do
+
+Security reviews and can block merges; it does not write the fix. The responsible engineer
+implements the fix and resubmits for review, the same as any other rejected PR
+(`WORKFLOW.md`).