mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 02:54:26 +00:00
A run-wide draw proved one distribution and said nothing about the other four, while reporting green. Both are matrix-row axes now, assigned by the same deterministic rotation mode and tor already use, so one sweep exercises every distribution and every filesystem. The two read the row's position like an odometer, the distro as the low digit. Turning both on the position directly covers only n of the n x m pairs whenever the pools are the same length, and no sweep unlocks it. Both are part of a row's identity: glyphs in the job label, columns in the plan table, shards in the artifact name. Both are selectable through %distro and /filesystem, and a retrigger replays the distro off a failed title. It leaves the filesystem out, because a title states the kind the matrix assigned and a deploy may have fallen back from it. A row's filesystem is a preference unless a human names it, on the run or in a token. Reading the matrix's own narrowing as a demand would fail rows for every transient condition the applying step is built to tolerate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Architecture Decisions 🧭
This directory holds the architecture decision records of Infinito.Nexus. A record states one decision that shapes the system, the forces that constrain it, and what living with it costs.
Scope 📋
- A record MUST cover a decision whose reversal would be expensive: a contract between components, a data or naming shape other code depends on, or a rule that governs a whole subsystem.
- A record MUST NOT be written for a choice that a reader can recover from the code alone, such as a helper's signature or a local refactoring.
- A record MUST describe the decision as it stands today, including the alternatives that were weighed and why they lost, so a later reader can tell a deliberate constraint from an accident.
- A record MUST be numbered in the order it was accepted, and its number MUST NOT be reused.
- A superseded record MUST stay in place with its status changed and a link to the record that replaces it, because the reasoning it carries is what makes the replacement legible.