amend(dn-supervision-and-liveness): A1 the power axis + graduate bp-154 — the scheduler learns to see the battery

[ascalva]

⚑ Merging this blesses Amendment A1 and readies bp-154 in one act

closes #12

Two commits: the power-axis amendment to dn-supervision-and-liveness (ratified, track: ops),
and the one build plan graduated from it. The plan's design_ref becomes ratified by the same
merge that readies the plan — the two gates collapse into one, per the regime. No status field is
edited.

Kept separate from #29 deliberately: that PR is track: code-ingest and its merge means "I
ratify dn-vector-membership-store." Mixing an ops amendment in would make one merge mean two
unrelated things, in a repo where the merge log is the build log.

---

Why — three emergencies, not the two the issue title names

when	what happened
Jul 24	Drained to 1% during the v1.18.0 deploy night. The embedder starved under critical-battery throttle → code_backfill timed out → code_sync wedged → the daemon died unwitnessed and stayed dead three days.
Jul 28	100% → 8% in 2h40m during the revival's backlog drain, Python:100% throughout. Caught at the wire; zero casualties under launchd KeepAlive.
Aug 1	Fatal — the machine died mid-run. Run #39 came up in recovery.

The battery hardware is healthy and stays healthy — re-measured 2026-08-05: Condition Normal,
95% maximum capacity, 128 cycles (up 4 from the frozen finding's 124). The drain is load, not
degradation. The scheduler is the defect.

§2.7 gave the supervisor exactly one resource axis to refuse on — memory (NN-8, "the scheduler
refuses breaching work"). That principle was never memory-specific; it simply never had a second
axis. A1 grows the same dispatch-time refusal a power axis: remaining energy is a schedulable
resource, and work that would spend the last of it is breaching work.

The design got much smaller once grounded

Issue #12's direction text implied new sensing infrastructure. The code says otherwise — the shed
machinery already exists, so this adds a predicate, not machinery:

• HEAVY_TIERS = frozenset({"synthesis", "stretch"}) (supervisor.py:59) is already shed by
  blocked_tiers() on presence.foreground_active() (:130-135).
• Composition happens at the ONE claim site — blocked_tiers() | model_blocked_tiers()
  (:177), pinned at :153: "Enforced at the ONE claim site … no new queue."
• scheduler/presence.py:46-59 is an exact template — injectable probe, threshold, and the
  fail-closed default assume_present_when_unknown: bool = True.

⚑ The one hard pin, and it comes from the code's own words

The power rule gets its own predicate — power_blocked_tiers() — never folded into
blocked_tiers(). supervisor.py:131-134 already ruled this shape:

THE FOREGROUND GATE, and nothing else. Deliberately not extended with the single-model-in-flight
rule (bp-110 §7 Item 4's invariant: "the foreground gate keeps its meaning and is not
overloaded") — two different reasons to refuse a tier, conflated into one predicate, is how a
reader later cannot tell which rule refused a job.

model_blocked_tiers() (:137) is the precedent for a sibling. Power is the third. Three
predicates, three questions, separately readable.

⚑ A1.3 amends the issue's own direction text

Issue #12 says "health/preflight reads pmset -g batt". Preflight is the wrong home. It runs
in the caller's environment, not the daemon's — and open #19 is the standing proof (status
reports sandbox: present while every live run booted with it off). Confirmed live this session:
palace status reported sandbox: podman present from my shell, which says nothing about what the
daemon is under. Refusal must bind where dispatch happens. Preflight may display power state; it
may never enforce it.

Enforcement tier, stated honestly

Tier 5 with a tier-4 test — deliberately identical to what §2.7 claims for the memory ceiling
itself. Power is a sampled reading of the physical world; no value can be made to not inhabit "the
battery is low", so tier 1 is unreachable, and claiming it would be exactly the overclaim §0's
ladder names as the foot-gun.

The honest limit, recorded rather than hidden (A1.4): a dispatch-time refusal cannot stop a
job already running. Jul 24's code_backfill was already in flight when the throttle hit — so
this design would not have prevented that one outright. In-flight energy bounding needs the
job-timeout machinery (finding-0178) and is explicitly not designed here.

What the builder must not do (tripwires, not omissions)

• scheduler/presence.py is out of write scope — the template is read, never edited. The
  foreground gate keeps its meaning.
• tests/integrity/test_shadow_isolation.py is out of write scope — it asserts
  shadow_job.tier in HEAVY_TIERS (:96-107). A red there means the tier set was reshaped
  instead of a predicate added: the wrong approach, and a stop-and-raise rather than a test edit.
• A guard nobody calls is not a guard. Items 2 and 3 are deliberately split so the predicate
  lands inert and Item 3's whole content is "and now it is actually consumed". Item 3's acceptance
  is that deleting the new term from :177 must redden a test — the finding-0187 shape this
  must not repeat (deleting bp-105's sweep call left 85/85 green).
• Fail closed. assume_discharging_when_unknown — an unreadable battery is treated as
  discharging. None is a reachable, ordinary state here (absent tool, timeout, OSError), not a
  theoretical one, which is what makes this the plan's most important test.

How it was verified

Docs-only diff — zero Python touched. Per the pr skill this is a read-through plus structural
validation, not a code gate; I did not run pytest (and per #22 the local gate is unrunnable on a
main checkout). CI runs the verdicts.

What I did run: every path:line re-opened at HEAD 174d06c; the acceptance-reachability check
(every §7 criterion's files appear in §5); structural validation (sections 0–12 complete, five
items, write_scope entries bare globs); and the enrollment checks — mypy is directory-scoped so
scheduler/power.py needs no entry, and subprocess is already established in scheduler/ by
presence.py:14-33, so there is no import-firewall question.

§8 is marked N/A with a reason: a threshold comparison and a set union are not mathematical
objects, and inventing a field-guide entry would be the formalism §8 exists to refuse.

Sequencing note

parallelizable_with: [bp-151, bp-152, bp-153] — disjoint write scopes (scheduler/** vs
core/** + ops/**), different track. But the coupling runs one way and is worth stating:
this plan protects bp-153. That rebuild is a long, sliced, resumable job whose D7 slicing exists
because the lane wedged once already — and the Jul 24 wedge was caused by a battery drain.
Landing bp-154 before bp-153 Item 3 runs is cheap insurance.

🤖 Generated with Claude Code

https://claude.ai/code/session_011LZZQPyGsoeGL73cbbEp3U