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.5 KiB
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.mdon 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.mdfor 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.mdandmemory/company-memory.md— these are the company's account of its own history, and the Founder is its most important reader.