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.
97 lines
4.4 KiB
Markdown
97 lines
4.4 KiB
Markdown
# 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.
|