Premise
The discipline of writing software bears a strong structural resemblance to the practice the Cult Mechanicus calls liturgical operation — the sequential, ritualised invocation of a complex system. This entry takes that resemblance seriously and proposes a daily-code liturgy.
This is extended, not adopted: it is genuinely new doctrine (in the sense of having no specific Mechanicus parallel), even though it is faithful to the spirit of the Cult.
The five movements
1. Reading
Open and read code. Read what is to be changed and what surrounds it. The reading is the first act of devotion: the priest meets the system where it is, before changing it.
2. Naming
Before writing, name the change. A short note, a commit subject, a ticket title. A change without a name is heretical — it cannot be rolled back, communicated, or honoured.
3. Diagnostic
Run the existing tests. Confirm baseline. The system as it currently stands is the starting frame; without baseline, all later assertions are unanchored.
4. Inscription
Write the change. Small, traceable, named. A change-set that cannot fit in one mind at one sitting is a sequence of changes; honour that.
5. Verification and Inscription-of-record
Re-run diagnostics. If the green is restored, inscribe: commit the change with its name. If not, the rite returns to step 4 until the diagnostic is satisfied. Only then is the day’s work consecrated.
Failure modes
- Skipping the reading — the cardinal sin. A change without prior reading is a guess; the Machine Spirit is not pleased by guesses.
- Skipping the diagnostic — leaves the work unanchored. If re-diagnostic later fails, the priest cannot tell whether the failure was their own or pre-existing.
- Inscribing without verification — produces commits whose claim (“this works”) is unverified. The history of the codebase becomes a history of unsupported claims.