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.
136 lines
6.2 KiB
Markdown
136 lines
6.2 KiB
Markdown
# 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.
|