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.
This commit is contained in:
Christopher Clendening
+104
@@ -0,0 +1,104 @@
|
||||
# WORKFLOW.md
|
||||
|
||||
This document defines how work actually moves through Local LLC, from an idea in a planning
|
||||
session to merged, verified code. If `ORGANIZATION.md` is the org chart, this is the machine
|
||||
that chart runs.
|
||||
|
||||
## The full lifecycle
|
||||
|
||||
```
|
||||
1. PLANNING Founder + Executive Office brainstorm, research, draft a proposal
|
||||
│
|
||||
2. APPROVAL GATE Executive Office asks "approve this plan?" — Founder says yes
|
||||
│
|
||||
3. EPIC CREATION CEO creates the Epic in Plane, sets milestones, sets priority
|
||||
│
|
||||
4. BREAKDOWN Project Manager splits the Epic into Stories, Stories into Tasks
|
||||
│
|
||||
5. SPRINT START Project Manager opens a sprint, assigns Tasks to engineering roles
|
||||
│
|
||||
6. EXECUTION Engineer claims Task → writes code → commits → opens PR
|
||||
│
|
||||
7. REVIEW Architect (and/or peer engineer) reviews the PR
|
||||
│
|
||||
8. CI ACT Runner builds and tests the PR automatically
|
||||
│
|
||||
9. QA QA Engineer verifies against acceptance criteria
|
||||
│
|
||||
┌─────────────────────────┴─────────────────────────┐
|
||||
▼ QA rejects ▼ QA passes
|
||||
Task reopens, moves back to "In Progress" Story/Task closes
|
||||
Bug filed if needed, Engineer fixes Sprint burndown updates
|
||||
→ back to step 6 │
|
||||
▼
|
||||
10. SPRINT CLOSE Project Manager closes the sprint, reports velocity
|
||||
│
|
||||
11. RETROSPECTIVE What worked, what didn't — recorded in memory/lessons-learned.md
|
||||
```
|
||||
|
||||
Steps 1–2 happen entirely outside the company (see `FOUNDER.md`). Steps 3 onward happen inside
|
||||
Plane and Gitea, and are where AI employees actually operate.
|
||||
|
||||
## Where the line sits: approval vs. autonomy
|
||||
|
||||
Once an Epic clears the approval gate, the company does not go back to the Founder for routine
|
||||
decisions inside it. Concretely:
|
||||
|
||||
- **Needs to go back through the gate:** new scope not implied by the approved Epic, a
|
||||
direction change, anything in an employee's `LIMITATIONS.md` "escalate to Founder" list.
|
||||
- **Company handles it:** how an Epic splits into Stories/Tasks, which engineer gets what,
|
||||
sprint length and pacing, how a bug gets triaged, code review outcomes, QA verdicts.
|
||||
|
||||
If a Task's scope grows enough that it stops looking like what was approved, the Architect (for
|
||||
technical scope) or Project Manager (for schedule/priority scope) escalates — see
|
||||
`EMPLOYEE_HANDBOOK.md` for how escalation is supposed to feel from the inside.
|
||||
|
||||
## Task lifecycle, in Plane terms
|
||||
|
||||
A single Task moves through these Plane states. Exact label/status names are defined in
|
||||
`PLANE.md`; this is the semantic flow every role needs to agree on:
|
||||
|
||||
```
|
||||
Backlog → Todo → In Progress → In Review → QA → Done
|
||||
▲ │
|
||||
└──────── Reopened ────┘
|
||||
```
|
||||
|
||||
- **Backlog → Todo**: Project Manager prioritizes it into the active sprint.
|
||||
- **Todo → In Progress**: an engineer claims it.
|
||||
- **In Progress → In Review**: a PR is opened and linked to the Task.
|
||||
- **In Review → QA**: the PR is approved and CI passes.
|
||||
- **QA → Done**: QA Engineer verifies against acceptance criteria and signs off.
|
||||
- **QA → Reopened**: QA rejects; a bug may be filed (`templates/BUG.md`); Task returns to
|
||||
"In Progress" for the original or a reassigned engineer.
|
||||
|
||||
## Sprint cadence
|
||||
|
||||
- Sprints are opened and closed by the Project Manager, scoped from Stories the CEO has
|
||||
prioritized.
|
||||
- Sprint length is a Project Manager judgment call, not fixed by policy in this document —
|
||||
record the reasoning for unusual lengths in `memory/lessons-learned.md` so future sprints
|
||||
benefit from it.
|
||||
- Burndown and velocity are tracked in Plane directly (see `PLANE.md`) — not duplicated in a
|
||||
Markdown file. This repository records *policy*, Plane records *state*.
|
||||
|
||||
## Retrospectives
|
||||
|
||||
Every sprint close is followed by a retrospective using `templates/RETROSPECTIVE.md`. The
|
||||
output that matters is not the ceremony — it's what gets written into
|
||||
`memory/lessons-learned.md`. A retrospective that produces no memory update didn't accomplish
|
||||
its job.
|
||||
|
||||
## Escalation paths during execution
|
||||
|
||||
```
|
||||
Engineer ──technical question──▶ Architect
|
||||
Engineer ──priority/assignment question──▶ Project Manager
|
||||
Architect/Project Manager ──unresolved/scope change──▶ CEO
|
||||
CEO ──strategic/direction question──▶ Founder
|
||||
Security Engineer ──standing block on any merge, overridable only by Founder──▶ (halts merge)
|
||||
QA Engineer ──standing reject authority on any task──▶ (returns task to In Progress)
|
||||
```
|
||||
|
||||
See `EMPLOYEE_HANDBOOK.md` for the behavioral expectations behind each of these arrows —
|
||||
this document defines the paths; that one defines how to walk them.
|
||||
Reference in New Issue
Block a user