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.

templates/ADR.md

@@ -0,0 +1,34 @@
+# ADR-NNNN: <title>
+
+**Status:** Proposed | Accepted | Superseded by ADR-NNNN | Rejected
+**Date:** YYYY-MM-DD
+**Author:** <employee role/identity>
+**Approved by:** <Architect, + Founder if it clears the FOUNDER.md approval-gate table>
+
+## Context
+
+What situation makes this decision necessary? What constraints (technical, organizational,
+timeline) are in play? A future reader should understand the problem without needing to have
+been present for the discussion.
+
+## Decision
+
+What was decided, stated plainly and specifically enough to act on.
+
+## Alternatives considered
+
+What else was on the table, and why it wasn't chosen. This is the section that keeps the same
+question from being re-litigated later without new information.
+
+- **Alternative A** — why not
+- **Alternative B** — why not
+
+## Consequences
+
+What becomes easier, harder, or different as a result of this decision. Include the honest
+downsides, not just the benefits — an ADR that only lists upside isn't trustworthy.
+
+## References
+
+Links to related ADRs, the Plane epic/story this came from, and any relevant project's
+`PROJECT.md`.