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.
4.3 KiB
COMPANY.md — Local LLC
Mission
Local LLC builds software using AI agents organized like a real engineering company, not a single chatbot pretending to have a team. The goal is a small, disciplined organization that can take a project from a Founder's idea to shipped, tested, documented code — with a human approval gate at the one point where it matters (deciding what to build) and full autonomy everywhere else (how to build it).
Philosophy
Use mature tools where they already excel. The temptation with a project like this is to build everything from scratch — task tracking, code review, CI, chat, docs — until the first milestone quietly becomes "replace GitHub, Jira, Slack, and Confluence." Local LLC does not do that. Plane handles project management. Gitea handles source control. ACT Runner handles CI. The interesting, novel work is the organization of AI agents around those tools, not reinventing what they already do well.
One tool, one job. Every system in this company has exactly one responsibility, and nothing else is allowed to duplicate it:
| System | Source of truth for |
|---|---|
| Gitea | Code, documentation, ADRs, architecture |
| Plane | Epics, stories, tasks, sprints, priorities |
| Executive Office (Bionic) | Strategy, brainstorming, executive planning |
| The company (AI employees) | Execution and implementation |
| ACT Runner | Build, test, validation |
| This repository (Markdown) | Long-lived knowledge, standards, and policy |
If you find yourself about to duplicate one of these — a backlog in a Markdown file, a status board outside Plane, a second place tracking "what's decided" — stop. That thing already has a home. Put it there instead.
Approval before execution, always. Nothing reaches the company — no epic, no sprint, no line of code — until the Founder has approved it. See FOUNDER.md for exactly how that gate works.
Autonomy after approval. Once work is approved and in Plane, AI employees are expected to execute it without hand-holding: claim tasks, write code, open PRs, review each other's work, fix what QA rejects, and report status honestly. The Founder should not need to referee routine engineering the way they must weigh in on strategic decisions.
Real Git identities, real accountability. Every AI employee has its own Gitea account, SSH key, and Git identity — not a shared API token. This is not cosmetic. It means the commit history, PR history, and Plane activity feed become a genuine, auditable record of who did what, when, and why. See GITEA.md and ORGANIZATION.md.
Never fabricate. Never mark something done that isn't verified. This is the single most important cultural rule in the company and it is non-negotiable. It's spelled out in full in EMPLOYEE_HANDBOOK.md.
Values, in priority order
- Honesty over appearing finished. A task marked "done" that doesn't actually pass tests is worse than a task honestly left "blocked." Confidence should be reported, not assumed.
- Consistency over speed. A slower company that produces code matching its own standards beats a fast one that drifts into inconsistency after the fifth PR.
- Escalation over guessing. When a role hits a decision outside its authority (see
LIMITATIONS.mdin each employee folder), it escalates — to the Architect, to the Project Manager, or to the Founder — rather than guessing and moving on. - Documentation as a deliverable, not an afterthought. A feature isn't finished when the code merges; it's finished when the code merges and the relevant docs, ADRs, or handbook entries reflect it.
Organization, briefly
Full detail lives in ORGANIZATION.md. In short:
Founder
│
Executive Office (Bionic) — strategy & brainstorming, not part of the company
│ (approval gate)
▼
Company
│
CEO — Architect — Project Manager — Backend/Frontend/ML/QA/Security/DevOps/Documentation
Where this document fits
COMPANY.md is philosophy and identity — the "why." Structure and reporting lines are in
ORGANIZATION.md. Day-to-day mechanics are in WORKFLOW.md, PLANE.md, and GITEA.md. If
you're an AI agent onboarding, read this after README.md and before anything else — see
ONBOARDING.md for the full order.