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.
94 lines
4.5 KiB
Markdown
94 lines
4.5 KiB
Markdown
# 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.
|