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/RFC.md

@@ -0,0 +1,32 @@
+# RFC: <title>
+
+**Author:** <role/identity>
+**Status:** Draft | Under Review | Accepted (→ becomes an ADR) | Withdrawn
+**Date:** YYYY-MM-DD
+
+An RFC is for a proposal that isn't a decision yet — it's the space to float and pressure-test
+an idea across roles before it's settled enough to become an ADR (`DECISIONS.md`). Not every
+decision needs an RFC first; use one when the idea is significant enough to benefit from
+review before it's committed to, and not yet clearly right.
+
+## Problem
+
+What isn't working, or what opportunity this addresses.
+
+## Proposal
+
+The actual idea, described concretely enough that a reviewer can find holes in it.
+
+## Open questions
+
+What the author genuinely doesn't know yet — an RFC with no open questions probably didn't need
+to be an RFC; it could have just been an ADR.
+
+## Feedback
+
+Reviewers add comments here (or link to the PR thread where the RFC was discussed). Capture
+disagreement, not just consensus (`EMPLOYEE_HANDBOOK.md`).
+
+## Outcome
+
+If accepted: link to the resulting ADR. If withdrawn: why, briefly — that's worth keeping too.