The failure notifier is unreachable on a first install #12

Problem / context

install.sh is written as a sequence of converging steps, and its ordering rationale is stated inline wherever it matters (macos-dynamic-wallpaper is "ordered before the themes on purpose"; the legacy migration documents at length why working copies are renamed before anything is removed). The notifier's placement is the one that was never reasoned about: it sits with macarchy-doctor.service under "Wiring the machine's own health report" because both are health-reporting units, which is a tidy grouping and the wrong constraint.

This is the same defect shape #10 just fixed twice: an artifact installed after the thing that consumes it. There it was the theme's wallpapers landing after the unit that reads them; here it is the notifier template landing after the units that name it. Worth noting because it suggests the ordering constraint is worth stating explicitly rather than rediscovering per artifact.

No ADRs in this repo — nothing to check against (docs/adr/ absent; the profile records none).

Approaches

A. Move the template install to the top, before the repo loop. Three lines move. The template is a static file in this repo, depends on nothing, and needs no omarchy — there is no reason for it to be late. Smallest possible diff; fixes the cause.

B. Have each component repo ship its own notifier template. Removes the cross-repo ordering dependency entirely, but duplicates one file across three repos and makes macarchy-install no longer the owner of the health-report story. Trades a one-line ordering fix for a synchronisation problem.

C. Only strengthen the doctor check, leave the ordering alone. The doctor would report the truth, which is an improvement — but it would report a MISS on every first install for a condition the installer could simply have avoided. Fixing the diagnosis without fixing the disease.

Recommendation

A, plus the doctor half of C — they answer different questions. A makes the notifier reachable; the strengthened check makes the doctor able to notice if it ever stops being reachable, which is what would have caught this in the first place. B is rejected: one file, one owner.

Goal

The notifier template is installed before any unit that names it in OnFailure=, and doctor.sh can tell a reachable notifier from a merely present file.

Scope

• install.sh — move the macarchy-failed@.service install ahead of the component installs.
• doctor.sh — the failure notifier check verifies reachability, not just existence.

Non-goals

• Changing which units declare OnFailure=, or the notifier's own behaviour.
• Moving macarchy-doctor.service; only the template has an ordering constraint.

Design

flowchart TD
    A[sanity + packages] --> B[install macarchy-failed@.service]
    B --> C[repo clone loop]
    C --> D[macarchy-core: auto-appearance, bar-contrast]
    D --> E[macarchy-touchbar]
    E --> F[…]
    F --> G[macarchy-doctor.service stays here]

The template is a static file in this repo's systemd/. It needs no clone, no omarchy, no session — so it can be installed immediately after the sanity checks, before anything that could fail while naming it.

The doctor's check becomes: for each unit on disk that declares OnFailure=macarchy-failed@…, the template it resolves to must exist. systemctl --user show -p CanStart on an instance is not usable here (an instance of a template is always startable in principle); reading the OnFailure= declarations and checking the template file is the honest test, and it is what a human would do.

Edge cases

• No unit declares OnFailure= at all → the check has nothing to verify, and says so rather than passing silently.
• A unit names a different notifier template → reported by name, not assumed to be ours.
• The template exists but systemd --user has not reloaded → out of scope; install.sh already runs daemon-reload.

Assumptions

• macarchy-doctor.service has no ordering constraint of its own — it is enabled, not started, at install time. Unverified; if it turns out to need late placement, only the template moves, which is what this spec says anyway.

Acceptance criteria

1. On a one-pass clean install, journalctl --user -u macarchy-auto-appearance.service contains no Failed to enqueue OnFailure= job line.
2. install.sh installs macarchy-failed@.service before the first component install; grep -n shows its line number below the sanity section and above the repo loop.
3. doctor.sh reports MISS when a unit on disk declares OnFailure=macarchy-failed@… and the template is absent.
4. doctor.sh still reports ok on a correctly installed machine, and names what it verified.
5. Two install.sh passes remain idempotent — the template install converges, it does not re-copy noisily.

Testing decisions

Seams under test: doctor.sh's MISS/ok output lines, and install.sh's ordering as read by grep -n — the same text-level seams tests/test_doctor_noop_signals.sh and tests/test_doctor_touchbar_modules.sh already assert through.
Prior art: tests/test_doctor_noop_signals.sh — temp HOME, PATH stubs, a fixture the stub replays.
A good test here: a temp HOME holding one unit file that declares OnFailure=macarchy-failed@%n.service, with and without the template beside it, asserting the check flips.

Out of scope

• Any change to macarchy-core's or macarchy-touchbar's unit files.
• Making the notifier itself more informative.