Christopher Clendening
96b7ff9766
- 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.
105 lines
5.3 KiB
Markdown
105 lines
5.3 KiB
Markdown
# 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.
|