aslice Build Infrastructure — One Harness, Two Scales

State, identity, privilege, and recovery contracts: STATE-AND-RECOVERY. Protected-volume patching: SYSTEM-VOLUMES. These specifications do not establish completed implementation or platform validation.

• Status: Design draft, v0.27 — September 2026
• Companion to: DESIGN.md, PACKAGE-FORMAT.md, TOOLCHAIN.md
• Scope: the build harness (aslice build), farm orchestration (aslice farm), scheduling, worker trust, the VM test matrix, and the pipeline from build result to published repository.
• Vocabulary: NOMENCLATURE.md — project terms, acronyms, and the Homebrew translation table.

1. The founding axiom

The farm is not a special system. Every build the project runs goes through the machinery a user invokes with aslice build. Contributors can reproduce a job on a Mac with the required CPU, OS, and resources. Three properties follow from this axiom:

• Debuggability. A failing farm build can be reproduced locally with one command on a compatible machine, using the same pinned inputs and harness. Host and guest capabilities still matter (§6.1).
• Resilience. A farm outage costs binary freshness, never user capability: the farm's pipeline is the user's pipeline, so users can always build from source.
• Trust. Reproducibility cross-checks (§7) are volunteers running the same harness — no special access, no special build of the tooling.

The axiom is not free: the harness must serve an unattended fleet and a human at a keyboard equally well. Everything below is shaped by that requirement.

2. The harness: one binary, four modes, one sandboxed core

aslice build <what>           # user mode: build one package (or a formula dir) locally
aslice farm plan              # coordinator: compute the build plan from an orchard
aslice farm coordinator       # coordinator: schedule → gate → collect
aslice farm agent [--once]    # worker mode: pull signed jobs, build, upload results
aslice farm agent --vm-guest  # guest mode: run tests inside a matrix VM (§8)

All four modes orchestrate; none executes package code itself. They always delegate execution to the privilege-separated helpers of DESIGN §5.1: aslice-fetch, aslice-extract, and aslice-build. The last runs Starlark under Seatbelt; the harness spawns it for each phase with that phase's policy profile. A user's shell and a farm agent invoke the same executor bytes.

2.1 Jobs are closed worlds

Every farm execution of package-controlled build or test code runs in a disposable VM: official recipes, PRs, autobumps, and third-party orchards have the same boundary. Create an instance from a verified immutable image; mount authenticated inputs read-only; run phase-specific sandbox profiles; export results to untrusted staging; destroy the instance. Keep agent credentials, coordinator control channels, signing keys, timestamp keys, and publication authority outside package execution. The host agent validates guest results before authenticating its receipt.

Record image digest, harness digest, all input identities, worker identity, physical builder identity, and isolation lifecycle evidence in the build-evidence contract. PR caches are separate from release caches. Reusable compiler outputs require authenticated complete input keys (recipe, sources, toolchain, dependencies, flags, image, and harness) and applicable validation gates; a PR result cannot seed a trusted release cache merely by matching its claimed key. VM isolation and cache admission require macOS integration tests before launch.

A job is the complete, self-contained description of one build:

{
  "job_version": 1,
  "orchard":   { "repo": "aslice/orchard-extended", "commit": "c3f7…" },
  "package":   { "name": "ffmpeg", "version": "7.1.0", "revision": 0,
                 "variants": { "x265": true }, "flavor": "v3", "min_os": "10.11" },
  "toolchain": { "build_id": "7c19…", "digest": "sha256:…", "url": "…" },
  "deps":      [ { "name": "x264", "build_id": "77aa10b2", "digest": "sha256:…", "url": "…" } ],
  "sources":   [ { "url": "…", "sha256": "40973d…" } ],
  "sandbox":   { "test_network": false },
  "resources": { "jobs": 8, "ram_gb": 8, "disk_gb": 20, "timeout_min": 90 },
  "repro_of":  null
}

A job pins toolchain, dependencies, sources, and recipe. Its manifest hash identifies the requested build inputs; it is not the hash of the result. The canonical artifact manifest determines artifact_id after building, and delivered archive bytes determine blob_digest (STATE-AND-RECOVERY §1). aslice build --reproduce and farm verification compare the same build inputs and evidence under §7.3, with mismatches quarantined rather than assigned an expected output identity.

2.2 Results are the job's mirror

{
  "job_sha256": "…",
  "agent":      { "id": "mbp-2015", "key_fp": "…", "os": "12.7", "flavor": "v3" },
  "slice":      { "digest": "sha256:…", "size": 18112331 },
  "abi_report": "abi/ffmpeg-7.1.0-v3.json",
  "log":        "logs/ffmpeg-7.1.0-v3.jsonl.gz",
  "timings":    { "fetch_s": 4.1, "build_s": 412.7, "test_s": 38.0 },
  "provenance": { "builder": "aslice 0.9.1", "started": "…", "finished": "…" }
}

Timings feed the farm dashboard and the "build pain" prebuild signal (DESIGN §9.4); they are measured on the farm, never on users' machines.

3. The pipeline, shared at both scales

The phases are defined in PACKAGE-FORMAT §6.1; what follows is the infrastructure behind each:

Determinism is a property of the harness, not of the formula: LC_ALL=C, TZ=UTC, a pinned SOURCE_DATE_EPOCH, prefix-mapping, and a scrubbed environment (DESIGN §9.5). The toolchain slice mounts at its canonical store path, so -ffile-prefix-map output is byte-for-byte identical between farm and user builds.

For type = "binary" formulae, the same command runs the compressed pipeline (fetch → verify hash+signer → extract payload → abi-scan → pack). Declared grafts are extracted and hash-verified with the payload but never run by the harness — rehearsal is a farm job (§6.4), not a pipeline phase. The farm's redistribute = true slices come from exactly this path — and a user can dry-run a vendor repack locally, auditing what a vendor slice would contain before installing it.

4. User mode: aslice build

aslice build extended:ffmpeg                                # resolve like install, but always compile
aslice build ./orchards/extended/ffmpeg                # build a formula directory (maintainer loop)
aslice build extended:ffmpeg --variant +x265 --cflags="-O3 -march=native"
aslice build --reproduce extended:ffmpeg 7.1.0 v3 2f4a9c1e  # rebuild a published slice, compare digests
aslice build extended:ffmpeg --offline                      # air-gapped; pre-fetched sources only
aslice build extended:ffmpeg --keep --shell                 # keep build dir; sandboxed shell at the failed phase

• Results are first-class installs. The output enters the store with origin = local-build, recorded flags, and the identity rules of DESIGN §7.2, interoperating with the prebuilt world through the ABI contract like any slice. aslice install --build-from-source and --variant/--cflags builds are, literally, this command followed by an install step.
• Resource manners. The default is jobs = cores − 1 (override ASLICE_BUILD_JOBS); RAM/disk watermarks refuse builds that would thrash the machine; the build directory lives on tmpfs when RAM allows; ccache is keyed by complete authenticated recipe, source, dependency, toolchain, flags, flavor, image, and harness inputs under cache/ccache. A laptop stays usable while it compiles.
• Failure UX. Structured per-phase logs (cache/build/<id>/log.jsonl plus a rendered tail), --resume-from <phase>, and --shell, which drops you into the exact sandboxed environment at the failed phase. Maintainer iteration never requires re-fetching or re-unpacking.
• Cleanup. Successful build directories are deleted; failures are kept for 7 days (configurable) and swept by aslice clean.
• No daemons. Builds are on-demand processes; farm agent runs when the user starts it and not before. Nothing auto-launches, nothing phones home, nothing idles in the background.

5. Farm topology

DESIGN §9.3 lists the hardware; here each machine is given its role:

No new hardware purchase is required by this topology. CPU configuration, RAM, storage, and build/guest concurrency remain unspecified until measured during bring-up. Core 2 Duo smoke testing is optional future coverage, outside the owned inventory. Community Macs may supply reproduction evidence (§7.4); they are not assumed capacity.

5.1 Capability inventory and qualification

The worker-capabilities schema stores signed enrollment evidence separately from observations. A fixture is not enrollment or qualification. Established inventory is limited to these owned machines and intended roles:

Inventory each physical identity, host and guest OS, image/hypervisor versions, cumulative CPU and OS register-state support, RAM/disk budgets, and measured build/test/VM preparation durations. Unknown measurements are null with pending qualification; do not enroll them as usable capabilities. Run feature probes and representative builds/tests inside each guest, retain receipts, then qualify only successful combinations. Requalify after CPU, OS, image, hypervisor, or resource-policy changes. Independent rebuilds require distinct qualified physical builders; two guests on one Mac do not count. A second independent v3 builder is missing and remains a release blocker wherever required. Procurement and volunteer enrollment are outside this update.

The coordinator is boring by design: one process on the Mac Pro, a SQLite queue, an orchard checkout. Its state is reconstructed from archived orchard commits, signed plans/results, enrollment and lease history, quarantine decisions, and gate evidence, as specified in DATABASE. Git and result bytes alone do not preserve those decisions. Agents exchange jobs and results; they never share the coordinator database. The GitHub Actions integration is a thin adapter — a self-hosted runner job that executes aslice farm agent --once — so the system of record never depends on Actions semantics (DESIGN §9.2).

The signing host is a dedicated networked release Pi holding distinct targets, snapshot, and slice-signing keys. A separate offline root Pi holds the 1-of-1 root. Both use encrypted software keys and offline backups; KEY-RUNBOOK governs custody and recovery. The restricted VM on the Mac Pro is the publisher: it checks gates, delivers authenticated release candidates automatically, verifies returned signatures, stages complete releases, and activates them atomically. It holds repository credentials and the timestamp key only; build guests receive neither and cannot submit signing requests. The release Pi runs no package builds or supplied scripts. Shared-host compromise can corrupt evidence and publication and expose the timestamp key (§7.2); online signer compromise can authorize malicious releases. Offline root custody permits authority replacement but cannot undo installations or establish content safety. The Pis are existing devices; validate their OS and signing tools before launch. Initial setup and unlocking after signer restart may require the owner; routine releases require no intervention. These services remain implementation work.

6. Scheduling: plan, lanes, leases

6.1 The build plan

aslice farm plan computes the work: it diffs the orchard in git, expands each affected formula into jobs across its declared matrix — every flavor its min_os allows, with smoke tests for each OS release in [min_os, 12] — and topologically orders the resulting DAG.

Assignment requires detected CPU features, OS support for those features, validated guest capabilities, and available resources. Within the owned farm, complete v3 jobs run exclusively on the laptop. A compiler can emit v3 machine code on a weaker CPU, but configure probes, generated build tools, dependencies, and tests may execute it during the same job. Code generation alone does not establish that the package can build on the Mac Pro. Its VMs cannot supply the missing v3 execution capability.

When the laptop is unavailable, v3 work stays queued; eligible v1/v2 jobs continue on the Mac Pro. Unsupported flavors are never assigned or silently substituted. Required OS/flavor tests and independent rebuilds without a capable worker remain pending. Capacity shortages do not narrow a formula's declared support or waive a gate. Resource values in example job manifests (§2.1) are illustrative, not measured capacity or concurrency commitments.

A recipe, source, toolchain, build-configuration, or selected dependency change invalidates the affected transitive consumer closure by default. This includes static libraries, headers, generated code, and bundled components, even when no exported ABI changes. Keep recipe edges (declared build/runtime/embedded inputs) separate from actual artifact bindings. Traverse both to find consumers; incomplete binding or component evidence keeps coverage unknown. Each rebuild records its triggering old/new input identities and dependency path and receives a new revision when required by package identity rules.

The ABI gate remains a compatibility check (ORCHARD-POLICY §10); a compatible ABI does not exempt a consumer from security remediation. Freeze and publish the complete authorized provider/consumer set atomically. Across orchards, coordinate separately authorized candidates; consumers outside the publisher's authority that cannot be rebuilt stay visibly affected in advisories and reports. Publication must not claim those consumers are fixed. OBS transitive rebuild scheduling is an upstream precedent for dependency-driven rebuilding.

6.2 Lanes

Job kind and dispatch priority are independent. Kind is build, test, rebuild, vendor, or graft. Priority is security, approved-release, freshness, or backfill, in that order. Only authorized security incidents receive security priority. Non-security work continuously ready for 24 hours ages to approved-release priority; order that class FIFO by ready time, then job digest. A dependency becoming unready resets ready time; busy workers do not. Backfill uses the farm value signals in DESIGN §9.4, never download counts.

Dispatch only dependency-ready, authorized, non-quarantined jobs to workers whose qualified capabilities and free resources satisfy every requirement. Prefer capable non-v3 workers for v1/v2 work to preserve scarce v3 capacity. Distinguish waiting-worker (capable workers busy/offline) from no-capable-worker (no qualified worker), and list missing OS tests, independent rebuilds, and every other publication blocker.

Coalesce superseded queued jobs by authenticated input identity and logical matrix slot; retain the supersession record and replacement job. Running jobs finish unless explicitly cancelled. Cancellation terminates the disposable guest, revokes its lease, and retains logs, partial results, and a cancellation receipt; late results cannot satisfy gates. No arbitrary compiler checkpoint/resume is promised. Phase reuse requires verified complete inputs and a new disposable guest.

6.3 Leases, not locks

An agent leases a job and sends heartbeats to retain the lease. If the lease expires, an unresolved job returns to the queue with the same input identity; cancelled and superseded jobs stay terminal. A late result retains evidence but cannot satisfy a revoked or replacement lease. Results are keyed by job-manifest hash, so duplicate results are discarded. The system is idempotent, allowing the farm to resume after power is removed and restored.

6.4 PR gates

An orchard PR runs the changed formulae and their affected transitive consumer plan: lint → build every declared flavor → smoke-test every OS on the VM matrix → ABI gate if a provider → graft rehearsal if graft-bearing. Rehearsal runs each declared graft in the per-OS VM matrix under instrumentation and diffs observed writes, kext loads, daemon installs, and network access against the declared behavior manifest (DESIGN §12.15); a deviation or under-declaration fails the PR, and only an exact match lets the signing host sign the manifest into the index. Merge is blocked until green; automatic signing and subsequent publisher activation happen post-merge (§9).

7. Trust: owner merge authorizes processing, agents produce evidence

7.1 Quarantine

Every agent result lands in an untrusted staging area, and nothing from staging is ever served. The publisher prepares a release bundle only after:

1. lint/policy re-check of the formula at the job's orchard commit;
2. the independently rebuilt unsigned or normalized evidence matches where the reproducibility class demands it (§7.3);
3. the smoke test passed on the claimed OS × flavor;
4. the ABI report is sane (no unexplained fingerprint regressions);
5. the slice passes the malware-signature gate (§7.5) — scanned against current definitions, verdict recorded in its provenance;
6. for graft-bearing slices, the per-OS rehearsal receipts show exact matches against the declared behavior manifest, and the manifest itself is signed at promotion (§6.4) — no exact receipt, no promotion.

Missing required tests or independent rebuilds leave promotion pending; unavailable capacity is never a pass. Only then: aslice repo build prepares the bundle, the networked release Pi automatically verifies it and signs with repo sign, and the publisher re-verifies it before repo publish (KEY-RUNBOOK §2.1).

7.2 Agents are expendable

An agent holds the coordinator's public key (unsigned or unknown jobs are refused), a per-agent Ed25519 identity for result signing, a dedicated _aslicefarm user, and Seatbelt phase profiles. Build guests hold no agent identity keys, publication credentials, or repository signing keys. The host agent authenticates result envelopes outside package execution; guest claims remain untrusted evidence. A compromised guest can falsify evidence or disrupt jobs; quarantine and independent rebuilds reduce that risk but do not prove arbitrary package code safe. A compromise that reaches the shared Mac Pro host or hypervisor can corrupt gate evidence, staging, and publication and expose the publisher's timestamp key. Root authority remains offline, but forged release evidence can mislead automatic verification; publisher authentication alone does not establish content safety. Treat this as a signing incident under KEY-RUNBOOK §4.

All package-controlled farm code, including official recipes, PRs, autobumps, and third-party orchards, runs in disposable VMs (§2.1). Seatbelt profiles remain an additional in-guest boundary; recipe approval does not grant host execution.

7.3 Reproducibility classes

Not every package is bit-reproducible yet, and the record must say so. Each formula's provenance carries a class:

The two owned machines can cross-check v1/v2 jobs on independent physical builders when both are available. They provide only one physical v3 builder. A second VM or repeated run on the laptop is not an independent physical rebuild. Where the class or package policy requires an independent v3 rebuild, promotion remains pending until a capable independent evidence builder is available; neither the requirement nor the class is weakened to fit capacity. This also applies to the scanner genesis requirement (§7.5).

7.4 Community builders — the user's machine, enlisted safely

The harness runs anywhere — so anyone can enroll a spare Mac:

aslice farm enroll --project https://farm.aslice.sh   # issues agent key, pins coordinator key
aslice farm agent --reproduce-only                     # verification jobs only, forever

A community agent receives only repro_of jobs: rebuild a staged or published job manifest and compare digests. Staged jobs allow required independent evidence to arrive before promotion (§7.3), including scanner genesis (§7.5). The results are pure evidence — agreement raises a slice's reproducibility confidence (feeding the reproducible: true badge of DESIGN §9.5); disagreement files an automatic investigation event. A community agent is never asked for, and never given, the ability to produce a served artifact.

The project gains a distributed rebuild network on the very machines the software targets; the volunteer gains dashboard credit and a warm Mac mini. This is "the farm must be runnable on a user's machine" answered at the trust level: identical code, zero authority.

7.5 The malware-signature gate

Every staged slice is scanned against current ClamAV definitions before the publisher may include it in a release bundle. The gate exists for the two moments when the trust model is thinnest. The first is the autobump bot's first fetch of a brand-new upstream tarball: the hash is computed from that very fetch, so nothing has pinned it yet. The second is the vendor-payload lane, where bundled adware and PUPs are the documented pathology of the .pkg/.dmg ecosystem (ORCHARD-POLICY §12). Each scan verdict — scanner version, definitions date, result — is recorded in the slice's provenance: every published artifact carries its receipt, and scan coverage is a dashboard number.

• The scanner is the orchard's own clamav core package. The farm dogfoods the orchard (ORCHARD-POLICY §2: farm tooling is core by definition), running the same slice any user can install. Definitions refresh daily via freshclam on the farm network, and a scanner whose definitions are stale beyond 48 hours pauses promotion rather than scanning with dead signatures: the freshness of the gate is itself gated.
• A detection quarantines the slice permanently, files an investigation event, and pages the named maintainer. Nothing is auto-deleted, and nothing is auto-"cleaned": the verdict is a human decision. For vendor payloads the only options are rejection or a maintainer-documented exclusion in the formula, since a modified payload would break byte-integrity against the pinned signer.
• Genesis is a documented exception, not a silent gap. The pattern is the same one used for the toolchain genesis and the TUF root ceremony, applied to the chicken-and-egg of a scanner that is itself a package: 1. The first clamav build is scanned by a throwaway scanner. A maintainer hand-builds ClamAV from the same hash-pinned, upstream-GPG-verified source inside a quarantined VM, scans the staged slice, and records the verdict with scanner = "bootstrap-handbuilt" in its provenance. The orchard package never scans itself into existence. 2. The other five §7.1 gates carry their full weight for that first build: pinned and signature-verified sources, the sandboxed pipeline, owner approval under the single-owner policy (ORCHARD-POLICY §17), and a hard bitwise reproducibility requirement with an independent evidence rebuild (§7.4) before promotion. The scanner gate is one layer of six; genesis is when the other five stand up straight. 3. The gate's go-live — the first snapshot in which the packaged scanner runs the quarantine worker — is recorded in the transparency log. Slices published before it are marked pre-gate on the dashboard: annotated, never rewritten. 4. Backlog sweep. The packaged scanner then re-scans every pre-gate slice against current definitions, including its own origin slice, and scan coverage climbs publicly to 100%. The origin slice's bootstrap receipt stays as-is.
• Scope. Signature scanning catches known malware — nothing more. Against a novel supply-chain backdoor it does nothing; that threat belongs to provenance, reproducibility classes, and review, and this gate changes nothing there. What the gate replaces on this platform is XProtect, which Apple no longer updates for 10.11–12: the farm maintains the definitions the built-in layer stopped receiving.
• Client-side: nothing. No scan-on-install machinery, no daemon, no definitions slice pushed at users. A user who wants on-demand scanning installs the same clamav package the farm runs and drives it themselves; the charter's no-telemetry, no-background-anything rules apply to security features as to everything else.

8. The VM test matrix

Builds use the pinned toolchain and archived SDK on a capable worker (DESIGN §4.3); tests run on the claimed OS and flavor. The target matrix has seven releases: 10.11, 10.12, 10.13, 10.14, 10.15, 11, and 12. Run it in batches on the two owned Macs, with concurrency set only after measuring resources. Seven releases does not mean seven simultaneous guests.

Bring-up must validate the chosen hypervisor version, host OS, each guest's boot and test behavior, and CPU features visible inside it. VMware Fusion or Parallels are candidates, not verified configurations. The Mac Pro supplies compatible v1/v2 guests; v3 guests require the laptop and validated feature exposure. A guest cannot add CPU instructions the physical host lacks. Coverage remains planned until recorded by successful runs; an unavailable required OS/flavor combination blocks its gate.

• Each release has a golden image, snapshotted clean. A test run is: revert → boot → mount a read-only shared folder containing the staged slice → aslice farm agent --vm-guest executes tests.star → structured results out → revert. No guest has network beyond the coordinator wire; no state survives between runs.
• Image genesis is documented and archived. Per release: the Apple installer app → createinstallmedia (or the virtualization app's new-VM flow) → minimal install → golden snapshot. The installer apps are archived, with their sha256, in the farm's installer manifest: Apple can and does pull old installers, and the matrix must be re-creatable from nothing but the archive. Installers, images, and manifest are in the never-lose set (GENESIS §3).
• Archive validated images and their host/hypervisor requirements; revalidate after host or virtualization changes. Image retention does not establish continuing compatibility.
• Real Core 2 Duo v1 smoke testing is optional future coverage. Neither owned Mac nor an OS VM establishes coverage of that older silicon.
• Graft rehearsal rides the same matrix. A graft-bearing install is rehearsed once per OS release the artifact targets: revert → boot → install under instrumentation → diff observed behavior against the declared behavior manifest → revert (§6.4). The no-network guest rule doubles as the graft's first exam question — a manifest declaring no network access rehearses with the wire off.

9. From result to repository

The environment and release-version contract is ORCHARD-POLICY §18.1 and ORCHARD-POLICY §18.2, for aslice and every orchard, including third-party orchards. For normal releases, build the candidate on develop (dev), then promote the identical artifact inventory to beta (staging) and master (prod) in the same repository. The flow below runs for the authorized destination environment; promotion reuses frozen artifacts and authenticated build receipts instead of scheduling new served builds. Destination tests and current security checks still apply. Branch merges that change release content require a new base version and a fresh dev candidate. Environment suffixes belong to external release metadata, never rewritten payloads. Operational configuration is supplied externally.

Diagram source

flowchart TD
    merge["Owner-approved orchard merge"] --> ci["CI"]
    ci --> staging["Agent staging (untrusted)"]
    staging --> gates["Publisher: quarantine gates"]
    gates --> build["repo build"]
    build --> candidate["Authenticated candidate"]
    candidate --> verify["Networked release Pi: verify authorization, gates, state"]
    verify --> sign["repo sign"]
    sign --> reverify["Publisher: re-verify"]
    reverify --> complete["Stage complete set"]
    complete --> publish["repo publish (atomic)"]
    publish --> refresh["Client metadata refresh"]
    refresh --> client["search / install / upgrade"]
    client --> log["Transparency-log append (snapshot hash, public)"]
    log --> dashboard["Dashboard update"]

KEY-RUNBOOK §2.1 specifies candidate contents, authenticated owner-merge authorization, retained signing state, serialized publication, and idempotent retries. Owner merge is the final human approval, including new core slices. Stale candidates must reconcile against current repository and signing state before signing again. The root Pi is not used for routine releases. The publisher refreshes timestamps daily for the valid approved snapshot; targets/snapshot renew automatically below 30 days using the last approved content. Root renewal and top-level key replacement remain offline operations (KEY-RUNBOOK §1.1 and KEY-RUNBOOK §3). Client metadata refresh makes releases discoverable; publication does not force installation. Execute the end-to-end and failure drills in KEY-RUNBOOK §7 before launch.

Isolated security candidates use the maintenance branch mapping, identical gates and inventories, and an expected production baseline checked under the activation fence. Maintenance does not require merging unrelated ordinary development.

The index snapshot is published atomically with its dependent rebuilds (§6.1). Those builds are part of the frozen dev candidate and are reused in staging and prod. Missing required flavor builds, tests, rehearsals, or independent rebuilds keep the affected publication set pending; laptop absence never permits a partial provider/dependent update. Retention follows STATE-AND-RECOVERY §8: all published historical snapshots and their referenced hosted objects are retained under a currently authorized archive catalog.

The same publish deposits every source artifact the build fetched into the tree's blobs/sha256/ area: the vendored-source archive (DESIGN §9.6). Upstreams delete, reshuffle, and re-roll tarballs constantly. An orchard that vendors its sources never notices, and a from-nothing re-standup never starves (GENESIS §2).

10. Farm-side metrics (the only kind there are)

No user telemetry exists anywhere in this system (DESIGN §2.2 N7). What the farm publishes concerns the farm: median days behind upstream (freshness health), build pain per package (feeds DESIGN §9.4), reproducibility coverage percentage, queue depth per job kind and priority, per-OS × flavor test pass rates, fleet status. Include signing health: remaining root/targets/snapshot validity, root-renewal alerts at 30 days, automatic targets/snapshot renewal below 30 days, signer availability and renewal failures, and daily timestamp-refresh failures (KEY-RUNBOOK §1.1). All of it is computed from the farm's own operation and published on the static dashboard at aslice.sh/dashboard, the transparency surface of DESIGN §13.4.

11. Failure modes, planned

DATABASE defines coordinated backup boundaries for coordinator, publisher, and signer. Retain reservations, fence epochs, quarantine decisions, and publication evidence outside SQLite; keep independent off-site copies. Missing records do not become successful gates after reconstruction.

12. Roadmap mapping

• Phase 0: the harness skeleton — aslice build local mode with the full sandboxed pipeline; toolchain-as-slice; job/result schemas; farm plan. The from-nothing sequence (GENESIS §1) is executed end-to-end and written down as it runs: the project must be able to stand up from nothing, repeatedly, before it has users.
• Phase 1: coordinator + agents + leases; Actions adapter; VM matrix bring-up; PR gates for the core orchard; staging → quarantine → automatic networked signing → atomic publisher pipeline including the §7.5 malware-signature gate, bootstrapped per its genesis protocol, with the clamav core package the gate runs on.
• Phase 2: dependency-driven transitive rebuild cascades with ABI compatibility gates; vendor-repackaging lane including graft rehearsal (§6.4); backfill lane with DESIGN §9.4 priorities; public dashboard.
• Phase 3: two-machine v1/v2 cross-checks for core; capable independent evidence builders for required v3 rebuilds; community evidence builders (enroll, --reproduce-only); transparency log; reproducibility class upgrades as a standing program.

History

Source document