EmiBSD Governance

Ferffy, the EmiBSD mascot: a centolla, the child of Ferris (Rust's crab) and Puffy (OpenBSD's pufferfish).

The rules, decisions and plans that bind every EmiBSD repository.

The rules, decisions and plans that govern every repository of EmiBSD, and the workspace that holds their clones.

EmiBSD is an experiment by Emilio Navarrete Lineros: the OpenBSD kernel carried into Rust, first as a faithful file-by-file port (LandingZone) and then redesigned so that the compiler, not a reviewer, rules out memory errors (Kernel); then a userland written from scratch under one contract (Userland). The code is written by Claude Code agents under written rules; the maintainer takes every decision and approves every commit. Pre-alpha: boots only in QEMU on arm64 and runs OpenBSD's own userland unmodified.

EmiBSD is not affiliated with or endorsed by the OpenBSD project.

The repositories

flowchart LR
    subgraph forks["Forks: read-only mirrors"]
        direction TB
        obsd["OpenBSD-src"]
        rust["rust"]
        llvmrs["llvm-project"]
        cargo["cargo"]
    end
    subgraph repos["Repositories"]
        direction LR
        dev["DevTools"]
        lz["LandingZone"]
        ul["Userland"]
        k["Kernel"]
        os["OS"]
    end
    rust --> dev
    llvmrs --> dev
    cargo --> dev
    obsd --> lz
    obsd --> ul
    lz --> k
    lz -. pin .-> ul
    dev --> lz
    dev --> ul
    dev --> k
    k --> os
    ul --> os
    dev --> os

Loading

docs/architecture.md explains every arrow. Website is the public site and .github holds the organisation profile and the community health files (security policy, contributing).

What is here

Path	What
docs/invariants.md	The rules every repository obeys, with their reasons.
docs/process.md	How the work is done: agents write, the maintainer decides and approves.
docs/architecture.md	The repositories, the forks and the flows between them.
docs/roadmap.md	The milestones of every repository on one page.
decisions/	The decision log: one file per cross-repository decision, numbered G-NNNN and dated.
policies/	Licences, dependencies, AI disclosure.
CLAUDE.md, .claude/	The instructions the agents read when working from this directory.

How a decision is taken

1. An agent, or the maintainer, finds a question that crosses repositories: a name, a boundary, a licence, a tool, a phase.
2. The agent writes it as a proposal in decisions/ with the options and a recommendation, status proposed. It never takes the decision.
3. The maintainer decides, in conversation; the file records the decision, its date and its consequences, status accepted.
4. The repositories it binds follow it. It reaches them as text of their own, carried there on the maintainer's explicit OK; no repository links or cites this one (G-0017, proposed).
5. A later decision that replaces it sets it to superseded and points forward; nothing is deleted from the log.

Repository-internal decisions stay in that repository's own log (Kernel's docs/PHASE2.md, Userland's docs/PROGRAM.md, DevTools' docs/DECISIONS.md); this log is for what crosses them, and nothing more: what a repository does inside itself is described in that repository.

Licence

ISC, see LICENSE.