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/architecture-memory.md

@@ -0,0 +1,30 @@
+# Architecture Memory
+
+Technical context that spans projects: shared-infrastructure quirks, integration details
+between Gitea, Plane, and ACT Runner discovered in practice, and patterns worth reusing across
+projects rather than rediscovering each time. Primarily maintained by the Architect role, but
+open to any engineer who learns something worth keeping. See [../MEMORY.md](../MEMORY.md).
+
+## Log
+
+*No entries yet.*
+
+Known gaps to fill once true, not written speculatively:
+
+- Plane is not yet deployed (`../PLANE.md`) — once it is, record actual workspace conventions
+  discovered during setup here if they differ from what `PLANE.md` assumed.
+- `../GITEA.md` and `../ACT_RUNNER.md` currently use placeholders for instance URLs and runner
+  labels — once replaced with real values, note here anything about the actual instances (quirks,
+  constraints, capacity) that future engineers should know but that doesn't belong in the policy
+  docs themselves.
+
+Format for new entries:
+
+```
+### YYYY-MM-DD — <short title>
+
+<the technical fact or pattern>
+
+**Why:** <how it was discovered / why it matters>
+**How to apply:** <what future work should do differently because of this>
+```