Its job is to turn a plain FreeBSD installation into a Fruix builder: an environment capable of evaluating and materializing a pinned Fruix checkout.

What belongs here

Bootstrap-only responsibilities such as:

host environment checks
locating or building bootstrap Guile / support bits
wrapper entrypoints that invoke a pinned Fruix checkout
validation of the path from vanilla FreeBSD to first Fruix artifact

What does not belong here

Long-lived Fruix product logic should live in the canonical fruix repo/channel instead:

package definitions
system definitions
installer logic
deployment logic
installed-node lifecycle behavior
long-lived metadata semantics

Default channel checkout

Bootstrap currently assumes a sibling canonical Fruix checkout at:

../fruix

and bakes in the original channel repo URL as the default origin reference:

https://git.teralink.net/self/fruix.git

Override the checkout location with:

FRUIX_CHANNEL_DIR=/path/to/fruix

Builder preparation

The main bootstrap entry point is:

./bootstrap/prepare-builder

It prepares a reusable per-user builder environment under:

~/.local/opt/fruix-builder

including:

a local fixed Guile build
local Guile extension modules
a local Shepherd install
a Guix source checkout used by the current Fruix code

After that, ./bin/fruix will automatically prefer that builder root if present.

On the current foreign-FreeBSD host path, preparing the builder is mostly a user-space action, but materializing full Fruix system artifacts may still require sudo because some host inputs are root-readable only and some system-oriented build steps still assume elevated access.

Design docs

docs/bootstrap.md — boundary definition
docs/PLAN_5.md — migration plan

Intended lifecycle

plain FreeBSD
  -> fruix-bootstrap
      -> Fruix builder
          -> pinned fruix checkout
              -> build installer ISO / VM image / system closure
                  -> booted Fruix node
                      -> future lifecycle managed by fruix