Local-LLC/PLANE.md

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.