Charging: Record the HyperOS 3 cap-percent follow-up in the qualification ledger (#61)

* Charging: Record the HyperOS 3 cap-percent follow-up in the qualification ledger

A GitHub follow-up (PR #52 comment / issue #48) from the tanzanite
contributor claims mode 2 hard-caps at 80% with a dumpsys snapshot at
the cap. Recorded as a cap-percent candidate (80) only: a single
snapshot with status=2 (charging) and no hold/current observation is
not hold evidence, and how the mode was set is unstated, so daemon
enforcement of external writes stays unproven. The requested follow-up
runs (sustained hold, both-direction external-write test) are listed
in the issue #48 thread.

* Charging: Record the second HyperOS 3 data point (marblein, no hard-cap mode)

A Poco F5 contribution report (HyperOS 3.0.2 / Android 15) shows only
the two HyperOS-2-style modes on security_pc_secure_protect_mode_key,
answering the ledger's open question: the tanzanite hard-cap value 2 is
not HyperOS-3-wide but model- and/or Android-16-dependent, so a future
HyperOS 3 gate cannot infer it from the version code alone. Caveats
recorded: one wizard row withheld by the contributor, prior root with
FDE.ai charge-limit control.

Author: d4rken

.claude/skills/device-qualification/SKILL.md

@@ -150,9 +150,30 @@ only after adding a row here. Detailed run narratives live in each adapter's lan
     was written as a garbage-value guard; `2` is now known to be a real, named OEM mode). This is a settings mapping
     only: **no behavioral evidence** (the optional effect prompts were skipped), the cap percentage is unknown
     (modeling mode `2` needs a concrete `FixedLimit` percent), factory/absent-key semantics on HyperOS 3 are
-    unknown, and whether value `2` is HyperOS-3-wide or model-specific is unconfirmed. A full qualification would
+    unknown, and whether value `2` is HyperOS-3-wide or model-specific was initially unconfirmed (answered
+    2026-08-13: **not** HyperOS-3-wide — see the marblein data point below). A full qualification would
     also need the boundary write domain widened from `{"0","1"}` (`ChargingControlUserService`). The contributor
     has a working Shizuku setup (clean three-namespace, three-mode capture) — a strong candidate for a follow-up
-    qualification run; the report thread is in support mail ("Amply device-support discovery", 2026-08-07).
+    qualification run; the report thread is in support mail ("Amply device-support discovery", 2026-08-07) and
+    GitHub issue #48.
+    - **Follow-up (2026-08-13, comment on PR #52, same `tanzanite` device): cap-percent candidate 80 — still
+      unqualified.** The contributor claims mode `2` hard-caps at 80% and attached a `dumpsys battery` snapshot
+      at the cap (`level: 80`, `AC powered: true`). Not accepted as hold evidence: it is a single snapshot (no
+      sustained-hold observation, no current reading — a battery passing through 80 looks identical), the dump
+      itself reports `status: 2` (= CHARGING) with `Charging state: 0` / `Charging policy: 0` (no hardware hold
+      signal), and how mode `2` was set (native UI vs external write) is unstated — so daemon enforcement of
+      **external** writes, the decisive question for Amply and open even on qualified HyperOS 2, remains
+      unproven. Follow-up runs requested in the issue #48 thread: sustained hold at 80 with `current_now`, and
+      the both-direction external-write test (adb `settings put` to `2` below the cap → hold; back to `0`
+      mid-hold → charging resumes past 80).
+    - **Second HyperOS 3 data point (support mail, 2026-08-13): the hard-cap mode is NOT HyperOS-3-wide.** A
+      Poco F5 `23049PCD8I` (`marblein`, Android 15 / SDK 35, HyperOS 3.0.2, ROM `OS3.0.2.0.VMRINXM`) reported
+      via the contribution wizard only the two HyperOS-2-style modes on the same key (`1` = Intelligent
+      charging, `0` = Charge fully) — no value `2` and no hard-cap option captured. So mode `2` is model-
+      and/or Android-16/OS-3.0.3-dependent, and a future HyperOS 3 gate cannot infer the hard-cap mode from
+      `ro.mi.os.version.code == 3` alone. Caveats: the wizard saw `changed_rows=2` but the contributor withheld
+      one row in the privacy review (mapping possibly incomplete), and the device was previously rooted with
+      FDE.ai driving the charge limit. Thread: support mail "Amply device-support discovery", 2026-08-13; the
+      contributor was asked whether the settings screen shows any third mode / 80% option.
 - **Pixel** — wireless at-threshold hold/charge-past and the widget under Shizuku-only remain unexercised (both share
   the verified wired mechanism).