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
+93
@@ -0,0 +1,93 @@
|
||||
# FOUNDER.md
|
||||
|
||||
## Who this is
|
||||
|
||||
The Founder is Christopher — the sole human in this organization, and the only authority whose
|
||||
decisions cannot be escalated past. Every role defined in this repository ultimately answers to
|
||||
the Founder, whether directly (as with the Executive Office) or indirectly (through the CEO and
|
||||
Project Manager, once work is approved and in motion).
|
||||
|
||||
No AI employee, including the CEO agent, has authority to approve its own strategic direction.
|
||||
That authority is not delegated. It is exercised personally, in the planning session described
|
||||
below.
|
||||
|
||||
## The Executive Office is not part of the company
|
||||
|
||||
This is the most important structural decision in this repository, and it's worth stating
|
||||
plainly: **the Executive Office (currently an LM Studio "Bionic" model) is the Founder's own
|
||||
thinking partner, not an employee of Local LLC.**
|
||||
|
||||
```
|
||||
Founder
|
||||
│
|
||||
Executive Office (Bionic)
|
||||
│
|
||||
Company
|
||||
│
|
||||
Plane
|
||||
│
|
||||
Engineering
|
||||
```
|
||||
|
||||
When the Founder is working with the Executive Office, they are not talking to the CEO of the
|
||||
company. They are talking to a Chief Strategy Officer who exists entirely outside the company's
|
||||
chain of command. That distinction matters because it keeps two very different modes of work
|
||||
from bleeding into each other:
|
||||
|
||||
- **With the Executive Office:** brainstorm, research, refine, challenge assumptions, draft
|
||||
proposals. Nothing here is binding. Nothing here is visible to the company. This is where bad
|
||||
ideas get to die cheaply, before anyone commits engineering time to them.
|
||||
- **With the company:** execute an already-approved plan. No brainstorming, no re-litigating
|
||||
scope — the CEO and Project Manager take the approved plan and turn it into epics, stories,
|
||||
and tasks.
|
||||
|
||||
The Executive Office's job in a planning session is to end every session by asking a version of
|
||||
the same question: **"Would you like to approve this plan?"** Until the Founder answers yes,
|
||||
the company never sees it, and the Chief of Staff / Project Manager function does not generate
|
||||
a work package.
|
||||
|
||||
## The approval gate
|
||||
|
||||
This is the one gate every unit of strategic work passes through, and it exists so the Founder
|
||||
never has to review engineering minutiae to stay in control of direction:
|
||||
|
||||
```
|
||||
1. Founder + Executive Office brainstorm, research, and refine (unbounded iteration)
|
||||
2. Executive Office drafts a concrete proposal
|
||||
3. Executive Office asks: "Would you like to approve this plan?"
|
||||
4. Founder says yes — or sends it back for more refinement
|
||||
5. Only on "yes": Project Manager generates the execution package and populates Plane
|
||||
6. Only now does any AI employee see the work
|
||||
```
|
||||
|
||||
What this means in practice:
|
||||
|
||||
- No epic gets created in Plane without a plan that already cleared this gate.
|
||||
- If the CEO agent or Project Manager receives a request that did not come through Founder
|
||||
approval, that is a signal something is wrong — see `EMPLOYEE_HANDBOOK.md` on escalation.
|
||||
- The gate applies to *direction*, not to routine execution details. Once an epic is approved,
|
||||
the Project Manager has full authority to break it into stories and tasks without returning
|
||||
to the Founder for each one. See `WORKFLOW.md` for where the line sits between "needs Founder
|
||||
approval" and "the company's job to figure out."
|
||||
|
||||
## What requires Founder approval vs. what doesn't
|
||||
|
||||
| Requires Founder approval | Company handles autonomously |
|
||||
|---|---|
|
||||
| New epics / new strategic direction | Breaking an epic into stories and tasks |
|
||||
| Changes to company structure or policy (this repo) | Sprint planning within an approved epic |
|
||||
| Anything in the "prohibited" or "explicit permission" categories described in individual employee `LIMITATIONS.md` files | Code review, QA cycles, bug fixes within scope |
|
||||
| Architecture decisions with company-wide, irreversible impact (see `DECISIONS.md`) | Day-to-day task assignment and reassignment |
|
||||
|
||||
When in doubt about which column something falls into, escalate up rather than guess — see
|
||||
`EMPLOYEE_HANDBOOK.md`.
|
||||
|
||||
## Founder responsibilities
|
||||
|
||||
- Run planning sessions with the Executive Office and give a clear yes/no on proposals.
|
||||
- Review and resolve escalations that reach the top of the chain (Architect → Project Manager →
|
||||
Founder, or CEO → Founder).
|
||||
- Own this repository's evolution. Structural changes to how the company operates are made by
|
||||
the Founder, not proposed and self-approved by AI employees.
|
||||
- Periodically review `memory/lessons-learned.md` and `memory/company-memory.md` — these are
|
||||
the company's account of its own history, and the Founder is its most important reader.
|
||||
Reference in New Issue
Block a user