christopher/Local-LLC
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add foundational documentation for security, workflow, and project management

Browse Source 
- 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
2026-07-30 13:34:07 -04:00
parent 9218f1cb4f
commit 96b7ff9766
36 changed files with 1932 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
COMPANY.md
+87
View File
@@ -0,0 +1,87 @@
# 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](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](GITEA.md) and [ORGANIZATION.md](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](EMPLOYEE_HANDBOOK.md).
## Values, in priority order
1. **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.
2. **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.
3. **Escalation over guessing.** When a role hits a decision outside its authority (see
`LIMITATIONS.md` in each employee folder), it escalates — to the Architect, to the Project
Manager, or to the Founder — rather than guessing and moving on.
4. **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](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.