Project history

Chronology

1. Origin

   Observation was not enough

   The project moved from inspecting mining machines toward building a complete bootable appliance that could own startup, state, runtime generation, mining and recovery locally.

2. 2026-07-04

   Product contract fixed first

   The project adopted a strict contract: CPU-only, pool-neutral, local-first, no account, no activation, no RIGOS fee, no forced pool and no remote kill switch.

3. USB pipeline

   First bootable image path

   BIOS and UEFI boot paths, immutable appliance roots and a separate persistent-state partition turned the project into an operating image rather than a collection of host scripts.

4. Persistent state

   Durable authority separated from root

   Configuration revisions, the current revision pointer, SSH host identity, recovery credential records and health budget moved into persistent state. Runtime files became generated output rather than the source of truth.

5. Firstboot

   Configuration moved to the physical console

   The firstboot interface was placed on tty1. Whiptail drawing and answer capture used separate streams so the interface remained visible while configuration input was committed correctly.

6. Physical failure

   The systemd transaction authority was wrong

   Real hardware showed that a utility-mode conflict could remove firstboot from the initial boot transaction before service conditions were evaluated. The service file looked conditional, but the transaction graph had already decided otherwise.

7. Alpha.22

   Kernel command line became mode authority

   The fix moved boot-mode authority to kernel command-line conditions and repaired the physical firstboot transaction defect. Alpha.22 became the first functional physical preview.

8. Alpha.23 and Alpha.24

   Hardening after real defects

   Miner health observation, bounded supervision, network inspection, hostname synchronization and a namespace correction for persistent miner-health state were added after physical behavior exposed weak edges.

9. Alpha.25

   Operator surface and recorded evidence

   The short rig command, public JSON allowlists, automation-friendly status, preserved startup gates and sanitized physical health evidence completed the frozen functional milestone.

10. Current

    Development paused

    Alpha.25 is frozen as an experimental appliance milestone. It is physically functional, but the project does not claim stable unattended operation or production readiness.

The firstboot defect

The defect demonstrates a low-level systems rule: a service condition does not help when the service has already been removed from the transaction that would evaluate it.

incorrect model:
  service enters transaction
      -> kernel command-line condition is evaluated
      -> service is skipped or started

physical result:
  conflict removes service from transaction
      -> condition never gains authority
      -> firstboot never appears

repair:
  kernel command line defines the boot mode
      -> transaction is built correctly
      -> firstboot exists only in the intended mode

Engineering lessons

• A boot graph is executable architecture. Unit files cannot be reviewed as isolated text.
• Persistent configuration should be committed and activated rather than edited in place as live runtime state.
• Recovery should remain observable and explicit. Automatic destructive repair destroys evidence.
• Operator convenience must not bypass state, runtime, huge-page and network gates.
• Physical samples prove only the machine and conditions that were observed.

Commit landmarks

• Adopt the RIGOS product contract
• Add the first bootable RIGOS image pipeline
• Canonical project-history document