# Forking: Exit as a First-Class Right Article 7 of the kernel guarantees the right to fork: any citizen or group may take the constitutional text, its history, and the public ledger, and continue under their own governance. The tooling's job is to make exit *cheap and legible* — a fork is not a schism, it's a branch, and branches can track, diverge, and even merge back. The design target from the project premise: **same document, different config**. A family, a Discord server, a DAO — each runs the same kernel with different userland modules and parameters. ## Anatomy of a fork `govtool fork init` produces a new repository containing: ``` fork.yaml # the fork manifest (see below) constitution/ version.yaml # starts at upstream's version, then diverges kernel/ # copied from upstream at the forked version invariants.yaml userland/ # yours to replace, parameterize, extend citizens/ registry.yaml # YOUR citizens — never copied from upstream ledger/ # fresh ledger; genesis entry references upstream ``` ### `fork.yaml` — the fork manifest ```yaml fork: name: "lindqvist-household" created_at: "2024-06-01T12:00:00Z" upstream: url: "https://github.com/fablepool/constitution" forked_at_version: "0.2.0" forked_at_commit: "" forked_at_ledger_hash: "" tracking: auto_patch: true # auto-adopt upstream PATCH releases review_minor: true # MINOR releases require local review (no vote) vote_major: true # MAJOR releases require a local ratification vote overrides: {} # userland parameter overrides, recorded explicitly ``` Three things to notice: 1. **Provenance is cryptographic, not social.** The manifest pins the exact upstream commit *and* the upstream ledger head hash at fork time. Anyone can verify what the fork started from. Your own ledger's genesis entry embeds the same references, so the lineage is in the chain itself. 2. **Citizens never transfer.** A fork's registry starts from whoever the forkers enroll. Upstream has no authority over a fork's membership and vice versa. 3. **Tracking policy mirrors governance semver.** Patches flow freely, minors get eyes, majors get votes. These are defaults; a fork can amend its own `fork.yaml` tracking policy — which, since the manifest is constitutional text in the fork, goes through the fork's own gate. ## Commands ### `govtool fork init --name [--upstream ]` Clones the constitutional text at the current version into ``, writes `fork.yaml`, creates a fresh ledger with a genesis entry referencing the upstream commit and ledger head, and initializes an empty citizen registry (enroll your first citizens with `govtool keys generate` + registry amendments — in a brand-new fork with zero citizens, the genesis enrollment is the bootstrap exception, recorded as such in the ledger, exactly as upstream's own genesis was). ### `govtool fork status` Reports: upstream version vs. local base version, divergence summary (which articles/modules differ from upstream at the forked version), and pending upstream releases by bump type. ### `govtool fork diff [--upstream-version ]` Structured (data-level, not textual) diff between the local constitution and a given upstream release: per-file, per-rule, annotated with the classification each difference *would* carry. This is the document a fork's citizens read before a sync vote. ### `govtool fork sync [--take ]` Applies upstream releases according to the tracking policy: - **PATCH** releases merge automatically into non-overridden values (if `auto_patch`). Overridden parameters are never silently clobbered — a patch touching an overridden key is reported and skipped unless `--take` is explicit. - **MINOR** releases are staged as a local branch for review. - **MAJOR** releases are staged as a local *proposal* — `fork sync` registers it through the fork's own pipeline, and it merges only if the fork's citizens ratify it at the fork's own kernel-major tier. An upstream supermajority cannot reach into a fork; only the fork's own supermajority can. Every sync (applied or refused) is a ledger entry in the fork's chain, referencing the upstream release tag and ledger hash. Refusals are data too. ## Parameterization vs. divergence There are two distinct ways a fork differs from upstream, and the tooling keeps them separate on purpose: - **Overrides** (`overrides:` in `fork.yaml`, plus userland module edits) — the intended mechanism. A household sets the funding-pool quorum to 2-of-3; a DAO sets a 7-day voting window. Overrides survive syncs cleanly. - **Kernel divergence** — editing kernel articles locally. Allowed (it's your fork), but `fork status` flags it loudly, and synced kernel changes from upstream will conflict. A fork that diverges at the kernel is a new constitutional lineage, and the tooling says so plainly rather than papering over it. ## Merging back A fork that evolved something valuable sends it upstream the ordinary way: as an amendment PR against upstream, through upstream's gate, voted by upstream's citizens. There is no privileged back-channel for forks — which is exactly what makes a fork's upstream contribution trustworthy. The fork's ledger provides provenance: "this rule survived two years of use across 40 households" is an argument upstream voters can verify. ## Why exit-by-default matters Cheap, legible exit is the constraint that keeps voice honest. Every amendment upstream passes is implicitly priced against "or the minority forks." The kernel makes the right unremovable (it's an invariant — removing Article 7 fails the gate at the invariant check regardless of vote count), and the tooling makes the right *practical*. A right you can't operationalize in an afternoon is decoration.