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.

MEMORY.md

@@ -0,0 +1,65 @@
+# MEMORY.md
+
+Local LLC has no human continuity between sessions the way a human company has employees who
+just remember things. Memory has to be written down deliberately, or it's lost. This document
+defines the organization's memory system: what gets recorded, where, and by whom.
+
+## Two tiers of memory
+
+**Company memory** (`memory/`) — shared, cross-role, cross-project knowledge. Read by every
+role during onboarding (`ONBOARDING.md`) and consulted whenever something feels like it should
+already be known.
+
+**Employee memory** (`employees/<role>/MEMORY.md`) — one role's own accumulated context: recurring
+patterns it's noticed, mistakes specific to how that role operates, judgment calls it's made
+before and the reasoning behind them. Not shared automatically with other roles — if something
+in an employee's memory turns out to matter company-wide, promote it to `memory/` instead of
+leaving it siloed.
+
+## What lives in memory/
+
+| File | Contents |
+|---|---|
+| `memory/company-memory.md` | Cross-cutting facts about how the company actually operates in practice — decisions about process itself, recurring organizational patterns, anything true company-wide that isn't already captured as policy in a root doc |
+| `memory/architecture-memory.md` | Technical context that spans projects: shared infrastructure quirks, integration details between Gitea/Plane/ACT Runner discovered in practice, patterns worth reusing across projects |
+| `memory/lessons-learned.md` | Retrospective output (`WORKFLOW.md`), incident postmortems, anything that answers "what would we do differently" |
+| `memory/terminology.md` | Glossary — the vocabulary this company has actually settled on, so new agents and humans reading this repo don't have to infer meaning from context |
+
+## What does NOT belong in memory
+
+- Anything already true from reading the code, Git history, or Plane directly — memory
+  supplements what's derivable, it doesn't duplicate it (same principle as `COMPANY.md`'s
+  one-tool-one-job rule, applied to knowledge instead of systems).
+- Task-level or sprint-level state — that's Plane's job (`PLANE.md`).
+- Policy — if something is a rule everyone must follow, it belongs in the relevant root doc
+  (`CODING_STANDARDS.md`, `SECURITY.md`, etc.), not buried in a memory file where it's easy to
+  miss. Memory records *what happened and what was learned*, not *what the rule is*.
+- Placeholder entries. An empty, honest "nothing recorded yet" beats a speculative entry no one
+  has actually verified.
+
+## Who writes to memory
+
+Anyone can and should write to company memory when they learn something worth keeping — it is
+not reserved for one role. In practice:
+
+- Retrospectives feed `lessons-learned.md` — the Project Manager ensures this actually happens
+  after every sprint close (`WORKFLOW.md`), but any role can add an entry when something notable
+  happens outside the retro cadence.
+- The Architect is the primary (not exclusive) writer to `architecture-memory.md`.
+- The Documentation Engineer periodically reviews all of `memory/` for staleness and
+  consolidation, the same discipline applied to any other documentation (`COMPANY.md` values).
+
+## How to write a memory entry
+
+Lead with the fact or decision, then why it matters, then how it should change future behavior.
+A memory entry that only states what happened without why is hard to judge later when
+circumstances have changed slightly — the "why" is what lets a future reader tell whether the
+lesson still applies or whether their situation is actually different.
+
+## Reading memory before acting on it
+
+Memory can go stale — a lesson learned about a tool's old behavior may no longer apply after an
+upgrade; an architectural note may describe a system that's since been replaced. Before acting
+on a memory entry for something consequential, verify it against current reality (the code, the
+current infrastructure, Plane's current state) rather than trusting the entry blindly. If it's
+wrong, correct or remove it rather than leaving it to mislead the next reader.