founder-os-init

Founder OS Init

This is the one resumable path from an installed package to a useful first daily brief. It runs as the Chief of Staff. It orchestrates the owner agents; it does not borrow their files or call a scaffold an activation.

Activation exists only when a valid brief has been persisted at reviews/daily/YYYY-MM-DD.md in the workspace resolved at preflight. Until then the workspace is incomplete and the next /founder-os-init continues it.

When to use

Run immediately after install, after moving FOUNDER_OS_HOME, or to resume an interrupted first run. Do not use it to refresh an activated workspace; that is /founder-os-doctor.

Start with Stage 0. Do not ask whether the founder is ready and do not mutate a workspace before preflight succeeds.

Inputs

• references/ownership.yaml — the only source for scaffold paths, headings and owners.
• references/multi-business.md and ~/.founder-os/businesses.yaml, when the registry exists.
• $FOUNDER_OS_HOME, default ./founder-os/.
• the canonical Founder OS context injected into this session;
• existing workspace files and reviews/daily/, read before any question.

Shared sibling request

Every owner transition returns one request to the main thread with exactly role, workflow, workspace_id, correlation_id, handoff, and expected_persistence. It carries one bounded handoff of at most 4096 UTF-8 bytes. The main thread passes that carried answer unchanged; it validates and executes the request, while this workflow does not execute another role. Native and generic execution both use the byte-identical packaged role under references/orchestration.md.

Stage 0 — Preflight

Stage 0 is read-only. Finish every check before the first workspace write:

1. Confirm the plugin manifest, CLAUDE.md, references/house-rules.md, references/ownership.yaml, references/multi-business.md and every downstream skill named below exist in the installed package.
2. Before normal target resolution, read an explicit resume tuple from the invocation when one was supplied. It is complete only when it names the exact recorded FOUNDER_OS_HOME, business slug and resolved workspace path; a partial tuple stops instead of being guessed.
3. Resolve the target using the resume-resolution table below. Treat the resulting path, FOUNDER_OS_HOME and business slug as one frozen resolved workspace tuple for the entire run.
4. Validate the registry without rewriting it. A second-business request follows references/multi-business.md; an ambiguous or invalid slug stops.
5. Check from filesystem metadata that the target or its nearest existing parent is writable. Do not create a probe file.
6. Confirm the canonical context is present and carries CLAUDE.md, the house rules, ownership map and resolved workspace.
7. Apply the daily-review validity invariant: in this resolved workspace, a candidate reviews/daily/YYYY-MM-DD.md is valid only when it contains the headings declared for reviews/daily/ by references/ownership.yaml, with a non-empty ## The one thing and ## The trade. Stage 6 uses this exact invariant again; there is no weaker activation check.
8. If the selected workspace's decisions/*-founder-os-installed.md already carries a target checkpoint, compare its FOUNDER_OS_HOME, business slug and resolved path with the selected tuple. Any mismatch outside the confirmed-relocation case stops before a read or write outside the selected workspace.
9. Read the target's charter.md, owned outputs and reviews/daily/, then classify exactly one activation state: