1. Kernel lives in GIT — mirrored/cloned via forgejo (github->openbeagle sync per system-topology), read-only for us. 2. A SMALL Fossil INFRASTRUCTURE repo sits BESIDE it (e.g. ti-kernel-infra.fossil) holding OUR work: board bring-up configs, patch series / patches against the kernel, build recipes, and the agent tickets/threads/wiki for this work. Small, fully Fossil-native (gets our threads/branches coordination substrate). 3. The infra repo references the git kernel as a PINNED PEER DEPENDENCY: a peer-dep edge (PeerRegistry, shipped) carrying the kernel's VERSION PIN (the commit/tag we build+test against) + read binding (ro_bind so a session reads the kernel at the pin) + the ticket channel for kernel-needs. This is exactly the cohosted-vs-peer-dependency model (ticket e1465affdf) applied to a git upstream.

Generalize into the IMPORT PATH: import-project should distinguish "import small git/fossil history INTO fossil" vs "register a large git upstream as a git-native PINNED PEER (no import)". Add a size/commit-count threshold or an explicit --as-peer mode that clones the git mirror + creates/points the fossil infra repo's peer-dep instead of running fast-export|import. Also fold in: the disk_tmp fast-export materialization (178GB file vs a streaming pipe) should be fixed OR the import should refuse repos above a threshold with this peer path as the guided alternative. Related: cohosted-vs-peer-dependency (e1465affdf), multi-repo-dependencies (24415a30c7), beaglebadge-onboarding (bb8fc57110 — Interactor is the same pattern: git submodule = pinned peer), architecture T2 mirror-sync (the git side).

REFINEMENT (operator, 2026-07-09): the fossil infra repo must also DRIVE DEVELOPMENT on the git repo — we sometimes need to EDIT the git kernel, not just read it at a pin. So the peer edge for this case is READ-WRITE (a drive edge), not the read-only ro_bind of a pure pinned dependency. Two planes:

- FOSSIL infra repo = CONTROL/DRIVE plane: threads (coordination, sessions, review), config (version pin, build recipes, board configs), tickets, wiki. Fossil-native so it carries our threads/branches coordination substrate.
- GIT kernel = EDITABLE code plane: a kernel-dev session gets a WRITABLE git checkout (rw bind, not ro_bind), edits it, and changes land as GIT COMMITS on a working branch that flow back to github/openbeagle via the git-write path (forgejo mirror / desktop bridge / the git remote). The version PIN in the fossil repo advances DELIBERATELY when we adopt kernel changes.

Session flow: read+edit the git checkout -> git commit on a working branch -> the why/what/review lives in the fossil infra repo's thread; pin bump is a reviewed act. This is distinct from a pure read-only pinned peer (that's for upstreams we only consume). Distinguish in the peer model: peer-dep edges gain a MODE (read-only-consume vs drive-edit); drive-edit gives the session a writable git working tree + a git-commit/push path, and pairs the fossil control repo with the git target. Note this also differs from architecture T2 mirror-sync (that publishes OUR fossil work out to git); here sessions edit the git kernel DIRECTLY while fossil holds only coordination/config. Ties: cohosted-vs-peer-dependency (e1465affdf) — the pin + ticket-channel still apply; the new axis is read-only vs drive.

CORRECTION to the read-only-vs-drive framing (operator, 2026-07-09): do NOT treat "read-only-consume" as a distinct default class. "We haven't edited it yet" does NOT mean "we won't" — every git peer is DRIVE-EDIT-CAPABLE by default; the pin + a working branch track wherever development is (or will be) happening. A peer we're only tracking today is just a drive-edit peer we haven't pushed to yet, not a locked read-only one. So don't provision read-only-only; provision the writable working tree + git commit/push path as the norm, with the pin/ticket-channel on top.

CONCRETE PROOF — the `badge-snake` branch: the TI kernel import was `--branch badge-snake`, and badge-snake is AGENT-BASED KERNEL DEVELOPMENT done on the BeagleBadge and pushed by the operator. So the kernel already carries our working development line — it's an active drive-edit target, not a passive upstream. The fossil infra repo's job is to DRIVE this development line (badge-snake): threads/review/config/pin in fossil, the actual kernel edits as git commits on badge-snake, flowing back to github/openbeagle. This is the SAME pattern as beaglebadge-onboarding (bb8fc57110): the badge does agent development on a git repo (Interactor there, kernel badge-snake here) and pushes it; the desktop bridge + forgejo carry it. Fold the kernel-infra design into that badge/peer development story rather than a separate read-only reference. The version pin still advances deliberately; the ticket channel still applies; the difference from a passive dependency is simply that we have (and expect) a live working branch.