Phase 408 — local stone/repo contract

Why this phase exists

Phase 407 made the architecture honest:

Nix-sourced system payloads are bootstrap-only.
Final system packages must become .stone packages.

The next temptation is to jump straight to a public server:

repo.onix-os.com

That will be useful later, but it is too early for the current problem.

Right now we need a smaller loop:

build a local .stone
put it in a local moss repo
install it into the ONIX image
boot and prove the image still works

That is what Phase 408 defines.

The phase split

The split is:

4xx = local bootstrap stones needed to replace current Nix-sourced system payloads
5xx = real stone factory, recipe repository, remote publishing, repo.onix-os.com

This means Phase 4 is still allowed to be practical and local.

It does not need:

• remote hosting,
• signing policy,
• retention policy,
• package promotion,
• CDN/cache design,
• production repository layout.

Those belong later.

Local paths

Phase 408 defines these generated artifact paths:

artifacts/onix-stones/
artifacts/onix-local-repo/
artifacts/onix-stone-work/

They are ignored by git because they are build outputs.

Meaning:

Phase 408 also reserves a source path:

vm/phase4/stone-recipes/

That is where the first local bootstrap recipes can live while Phase 4 is still proving the replacement loop.

Later, when the recipe system is real, these can move or be mirrored into a proper onix-os/recipes style repository.

Why not remote publishing yet?

A remote repo is not hard to host.

A static server is enough:

repo.onix-os.com/bootstrap/
repo.onix-os.com/unstable/

The harder part is knowing the repo layout is correct and that ONIX can consume it.

So we prove the local loop first:

.stone -> local repo -> image install -> boot proof

Only after that should a 5xx phase publish the same repo shape remotely.

Planned local replacement path

The current local plan is:

408 — define local stone/repo contract
409 — build `onix-busybox.stone`
410 — install/use `onix-busybox` in the image
411 — rerun shell/network/SSH proofs against stone BusyBox
412 — build `onix-dropbear.stone`
413 — install/use `onix-dropbear` and rerun SSH proof
414 — systemd stone dependency audit
415 — build first `onix-systemd.stone`
416 — install `onix-systemd` into the image
417 — boot with `onix-systemd` as PID 1
418 — move bootstrap units/defaults into stone ownership
419 — audit no Nix-sourced systemd/busybox/dropbear payload remains

This sequence is deliberately incremental.

BusyBox comes first because it provides:

/bin/sh
basic command applets
network proof tools
SSH proof command tools

Dropbear comes next because Phase 406 already proved the SSH behavior.

Systemd comes after that because it is larger and has more dependencies:

PID 1
udev
sysusers
tmpfiles
unit search path
service startup
boot target behavior

Systemd may become multiple stones. Phase 414 exists to discover that before we pretend a single recipe is enough.

What make phase 408 does

Run:

make phase 408

It creates/verifies:

artifacts/onix-stones/
artifacts/onix-local-repo/
artifacts/onix-stone-work/
vm/phase4/stone-recipes/

It writes small CONTRACT.txt files into the generated artifact directories so the purpose of each directory is visible if you inspect them.

It also checks this book page for the key contract terms, including:

artifacts/onix-stones
artifacts/onix-local-repo
vm/phase4/stone-recipes
5xx = real stone factory
409 — build onix-busybox.stone
414 — systemd stone dependency audit

Expected success:

==> success
Phase 408 local stone/repo contract is ready.

What this phase does not do

Phase 408 does not build any stones.

It does not:

• build BusyBox,
• generate a moss repo index,
• install a package into the image,
• boot QEMU,
• publish to repo.onix-os.com.

It only makes the next steps precise.

The next real build phase should be:

409 — build onix-busybox.stone