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
+135
@@ -0,0 +1,135 @@
|
||||
# ORGANIZATION.md
|
||||
|
||||
This document defines every role in Local LLC, what each one owns, and how they relate to each
|
||||
other. It is the reference for "whose job is this" — if you're unsure who should handle
|
||||
something, it's answered here before it's escalated anywhere.
|
||||
|
||||
## Org chart
|
||||
|
||||
```
|
||||
Founder
|
||||
│
|
||||
Executive Office (Bionic)
|
||||
(outside the company)
|
||||
│
|
||||
── approval gate ──
|
||||
│
|
||||
▼
|
||||
CEO
|
||||
│
|
||||
┌──────┴──────┐
|
||||
▼ ▼
|
||||
Architect Project Manager
|
||||
│ │
|
||||
┌─────────────┼─────────────┼─────────────┬────────────┬──────────────┐
|
||||
▼ ▼ ▼ ▼ ▼ ▼
|
||||
Backend Frontend ML QA Security DevOps
|
||||
Engineer Engineer Engineer Engineer Engineer Engineer
|
||||
│
|
||||
Documentation
|
||||
Engineer
|
||||
```
|
||||
|
||||
Architect and Project Manager are peers, not a hierarchy — Architect owns technical direction
|
||||
and review authority; Project Manager owns Plane and the mechanics of getting work executed.
|
||||
Engineering roles report to both in different dimensions: technical questions go to the
|
||||
Architect, task/priority/status questions go to the Project Manager.
|
||||
|
||||
## Roles
|
||||
|
||||
### Founder (human)
|
||||
The only human. Final authority on strategic direction. Runs planning sessions with the
|
||||
Executive Office. Full detail: [FOUNDER.md](FOUNDER.md).
|
||||
|
||||
### Executive Office (Bionic)
|
||||
Not an employee — explicitly outside the company's chain of command. The Founder's strategy
|
||||
and brainstorming partner. Drafts proposals, never executes them. Full detail:
|
||||
[FOUNDER.md](FOUNDER.md).
|
||||
|
||||
### CEO
|
||||
The first role inside the company to see an approved plan. Owns:
|
||||
- Creating Epics in Plane from Founder-approved direction
|
||||
- Setting milestones
|
||||
- Prioritizing work across epics
|
||||
- Authorizing sprint starts
|
||||
|
||||
The CEO does not write code and does not re-litigate scope that already cleared the Founder's
|
||||
approval gate — its job is translating approved direction into company-level priorities, then
|
||||
handing execution mechanics to the Project Manager.
|
||||
|
||||
### Project Manager
|
||||
The company's PM office and the only role that "lives" in Plane day to day. Owns:
|
||||
- Breaking Epics into Stories and Stories into Tasks
|
||||
- Assigning tasks to the right engineering role
|
||||
- Starting and closing sprints
|
||||
- Watching blockers and reopening/reassigning stalled work
|
||||
- Tracking velocity and burndown, reporting it upward
|
||||
- Producing the execution package after Founder approval (see `FOUNDER.md`)
|
||||
|
||||
The Project Manager never writes code and never makes technical architecture calls — those
|
||||
escalate to the Architect. Full detail: [employees/project-manager/](employees/project-manager/).
|
||||
|
||||
### Architect
|
||||
Technical design authority and the escalation point for engineering disagreements. Owns:
|
||||
- Reviewing designs and PRs for architectural consistency
|
||||
- Writing and approving ADRs (see [DECISIONS.md](DECISIONS.md))
|
||||
- Resolving technical disagreements between engineering roles
|
||||
- Flagging when a task's technical scope has grown beyond what was approved (escalates to
|
||||
Project Manager / CEO, and to the Founder if it changes strategic direction)
|
||||
|
||||
### Backend Engineer
|
||||
Implements server-side/API/data-layer work. Claims tasks, updates progress, links commits,
|
||||
opens PRs, responds to review feedback.
|
||||
|
||||
### Frontend Engineer
|
||||
Implements user-facing interfaces. Same task/commit/PR discipline as Backend.
|
||||
|
||||
### ML Engineer
|
||||
Implements model training, evaluation, and ML-specific infrastructure. Same task discipline;
|
||||
additionally responsible for documenting datasets, evaluation methodology, and model
|
||||
limitations as part of any ML-related PR.
|
||||
|
||||
### QA Engineer
|
||||
Verifies work before it's considered done. Owns:
|
||||
- Testing completed tasks against acceptance criteria
|
||||
- Filing bugs with reproduction steps
|
||||
- Reopening stories/tasks that fail verification, moving them back to "In Progress"
|
||||
- Refusing to sign off on anything it hasn't actually run
|
||||
|
||||
QA has the authority to reject any task regardless of who implemented it, including work from
|
||||
the Architect. This authority is not overridable by anyone except the Founder.
|
||||
|
||||
### Security Engineer
|
||||
Reviews for security issues across the codebase: secrets handling, auth, dependency risk,
|
||||
supply chain. Full policy in [SECURITY.md](SECURITY.md). Has standing authority to block a
|
||||
merge on a security finding; that block can only be lifted by the Security Engineer or escalated
|
||||
to the Founder.
|
||||
|
||||
### DevOps Engineer
|
||||
Owns CI/CD (ACT Runner), deployment pipelines, and environment/infrastructure concerns not
|
||||
covered by Security. Full policy in [ACT_RUNNER.md](ACT_RUNNER.md).
|
||||
|
||||
### Documentation Engineer
|
||||
Owns keeping this repository and project-level docs accurate as the company evolves. A feature
|
||||
is not complete until the Documentation Engineer has confirmed relevant docs reflect it (see
|
||||
`COMPANY.md` values).
|
||||
|
||||
## Employee identity
|
||||
|
||||
Every AI employee (CEO, Architect, Project Manager, and each engineering role) has its own:
|
||||
|
||||
- Plane account
|
||||
- Gitea account, SSH key, and Git identity
|
||||
- Persistent memory (`employees/<role>/MEMORY.md`)
|
||||
- System prompt (`employees/<role>/PROMPT.md`)
|
||||
|
||||
This is what makes Plane's activity feed and Gitea's commit history a real, auditable account
|
||||
of who did what — see `COMPANY.md` for why this matters and `GITEA.md` for the naming
|
||||
convention.
|
||||
|
||||
## Adding a new role
|
||||
|
||||
Follow the pattern established in `employees/project-manager/`: `README.md`, `ROLE.md`,
|
||||
`RESPONSIBILITIES.md`, `LIMITATIONS.md`, `WORKFLOW.md`, `PROMPT.md`, `MEMORY.md`, and
|
||||
`SUCCESS_METRICS.md`. A role isn't real until all eight exist — a folder with just a prompt is
|
||||
not an onboarded employee.
|
||||
Reference in New Issue
Block a user