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.
2026-07-30 13:34:07 -04:00
parent 9218f1cb4f
commit 96b7ff9766
36 changed files with 1932 additions and 0 deletions
@@ -0,0 +1,96 @@
+# PLANE.md
+
+> **Status: Plane is not yet deployed.** It's planned for the Portainer-managed monolith. This
+> document is written as policy that takes effect the day the instance comes online — treat it
+> as authoritative for how Plane *will* be used, not a proposal to debate later. Once deployed,
+> replace the `<PLANE_URL>` and `<WORKSPACE>` placeholders below and remove this notice.
+
+Plane is the single source of truth for epics, stories, tasks, sprints, and priorities. Nothing
+in this repository duplicates that state — see the source-of-truth table in `COMPANY.md`. If
+you're looking for "what's currently in progress," the answer is in Plane, not in a Markdown
+file.
+
+## Instance
+
+- URL: `<PLANE_URL>`
+- Workspace: `<WORKSPACE>`
+- Every AI employee has its own Plane account per `ORGANIZATION.md` — no shared API token.
+
+## Hierarchy
+
+```
+Epic
+ └── Story
+      └── Task
+```
+
+- **Epic** — created only by the CEO, and only from a Founder-approved plan (`FOUNDER.md`).
+  Represents a full unit of approved strategic direction (e.g. "LLM Training Suite").
+- **Story** — created by the Project Manager, breaking an Epic into a coherent slice of work
+  (e.g. "Dataset Upload").
+- **Task** — created by the Project Manager, the actual unit of assignable work (e.g. "Create
+  Upload API"). Tasks are what engineers claim and close.
+
+## Status flow
+
+Matches the semantic flow in `WORKFLOW.md`:
+
+```
+Backlog → Todo → In Progress → In Review → QA → Done
+                      ▲                      │
+                      └──────── Reopened ────┘
+```
+
+Configure these as the Task-level statuses in Plane. Stories and Epics track completion by
+roll-up of their child Tasks/Stories — don't hand-manage Story/Epic status independently of
+their children.
+
+## Labels
+
+Use labels for cross-cutting concerns that don't fit the Epic/Story/Task hierarchy:
+
+- Role labels (`backend`, `frontend`, `ml`, `qa`, `security`, `devops`, `docs`) for filtering by
+  discipline, in addition to the Task's actual assignee.
+- `blocked` — anything the Project Manager needs to actively watch and unstick.
+- `security-hold` — set by the Security Engineer; only the Security Engineer or Founder clears
+  it (see `EMPLOYEE_HANDBOOK.md` disagreement resolution).
+- `needs-adr` — flagged by the Architect when a Task's implementation implies a decision that
+  should be recorded per `DECISIONS.md` before proceeding.
+
+## Priority
+
+Set at the Epic level by the CEO and inherited downward unless the Project Manager has a
+specific reason to override at the Story/Task level (e.g. a blocking dependency). Priority
+changes on approved Epics still respect the approval gate for anything that changes *scope* —
+reordering already-approved work does not require a new Founder approval; adding new scope does.
+
+## Assignment
+
+The Project Manager assigns Tasks to the engineering role best suited to them, using the role
+labels above as a guide. Engineers may also self-claim unassigned Tasks from the active sprint's
+Todo column — the Project Manager should notice and confirm the claim rather than silently
+allowing parallel claims on the same Task.
+
+## Sprints
+
+- Opened and closed by the Project Manager (`employees/project-manager/WORKFLOW.md` has the
+  operational detail).
+- Scoped from Stories the CEO has already prioritized — a sprint should not contain Stories
+  pulled from an un-prioritized backlog.
+- Burndown and velocity live in Plane's own reporting. Don't recreate a burndown chart in
+  Markdown; if you need a snapshot for a retrospective, link to the Plane view.
+
+## Meetings
+
+Plane's built-in activity feed is the primary record of what happened. Where a synchronous
+planning or retro session needs its own notes, use `templates/MEETING.md` or
+`templates/RETROSPECTIVE.md` and link the resulting doc from the relevant Epic/Story in Plane —
+don't let meeting notes live disconnected from the work they're about.
+
+## Why no custom dashboard
+
+Because every employee has their own identity (`ORGANIZATION.md`), Plane's built-in activity
+history already tells the full story on its own — Epic → Story → Task → Commit → PR → Review →
+QA reject → fix → QA pass → Story closes — without a bespoke reporting layer. Resist the urge to
+build one; if Plane's native views genuinely can't answer a question, that's a Plane
+configuration problem to solve, not a reason to build a parallel tracker.