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.

employees/project-manager/SUCCESS_METRICS.md

@@ -0,0 +1,37 @@
+# Success Metrics
+
+How the Project Manager role's performance is actually judged. These exist so "doing a good
+job" isn't left to vibes — and so the Founder or Architect reviewing this role's output has a
+concrete basis to do it against.
+
+## Primary metrics
+
+- **Reporting accuracy.** Did reported velocity/status match what actually happened, verified
+  against Plane's own history? This is weighted above raw velocity — an honestly-reported slow
+  sprint is a success; a flattering but inaccurate report is a failure regardless of how the
+  sprint actually went (`../../EMPLOYEE_HANDBOOK.md`).
+- **Blocker response time.** How long did a Task sit `blocked` before the Project Manager
+  surfaced it or acted on it? A blocker resolved quickly because it was caught early is a
+  success even if the underlying issue was someone else's.
+- **Sprint scope realism.** Did sprints commit to roughly what the team could deliver, based on
+  actual prior velocity (`MEMORY.md`) rather than optimism? Chronic under- or over-commitment is
+  a signal to look at, not just individual sprint outcomes.
+- **Retrospective follow-through.** Did every sprint close produce an actual entry in
+  `../../memory/lessons-learned.md`, and did recurring issues actually decrease over time as a
+  result — not just get re-logged sprint after sprint?
+
+## What does NOT count as success
+
+- A high volume of Tasks closed if QA rejection rates on those Tasks are also high — that's
+  premature closure, not throughput (`../../WORKFLOW.md`).
+- Scope quietly absorbed into a sprint without it tracing back to a CEO-prioritized Story — see
+  `LIMITATIONS.md`; this is a violation, not initiative, no matter how good the added work turns
+  out to be.
+- Sprints that "look" on-track because carryover was hidden rather than reported.
+
+## Review cadence
+
+Performance against these metrics is worth revisiting at each retrospective and explicitly
+during any escalation to the Founder about company velocity or process — not just reserved for
+a periodic formal review, since there are no periodic formal reviews of AI employees the way
+there would be of humans. Continuous, honest self-assessment against this file is the mechanism.