General: Remove docs/, record the first HONOR/MagicOS lead in the ledger (#67)

Both remaining files under docs/ were added after 0566324, which deleted the
folder with the stated policy that source of truth is the code plus its
comments and the .claude rules, not separately-maintained docs. They had
already decayed in exactly the way that commit predicted.

docs/plans/lineageos-adapter.md is fully superseded: the provider-to-mechanism
table is a real enum with the reasoning as KDoc in LineageHealthProbe, the
qualification rationale is in the device-qualification skill, and the gate,
keys and SELinux trap are in rules/privileged-access.md. It is also wrong now,
still describing the codename allowlist as empty pending a Pixel 6 run that
came back NO-GO.

docs/support/kindmail-system-prompt.md was inert. The support assistant loads
prompts from Gmail threads, so editing the repo copy changed no reply, and the
two copies had drifted in both directions: Gmail carried a Play closed-beta
section and the revised Pro wording, the repo carried the LineageOS wizard
exception. That paragraph was folded into the live prompt before deletion,
along with fixes for the Xiaomi HyperOS 3 and GrapheneOS rows the table was
missing.

Adds a HONOR/MagicOS entry to the qualification ledger for the Magic8 Pro
BKQ-N49 discovery report (issue #66): the 2x2 mode table, both keys reading
1-when-disabled, and the two blockers, no behavioral evidence for either key
and no identified gate signal for MagicOS. Also repoints a comment in
OemChargingShortcuts that still referenced docs/SAMSUNG_SPIKE_RESULTS.md,
deleted in 0566324.

Author: d4rken

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

@@ -219,3 +219,46 @@ only after adding a row here. Detailed run narratives live in each adapter's lan
         Verified-devices row before adding its codename to `XiaomiHyperOs3ChargingAdapter.QUALIFIED_CODENAMES`.
 - **Pixel** — wireless at-threshold hold/charge-past and the widget under Shizuku-only remain unexercised (both share
   the verified wired mechanism).
+- **HONOR / MagicOS** — **no adapter of any kind exists** (not even a lab adapter), so HONOR devices fall through
+  every probe to the null branch of `AdapterRegistry` and `adapter=none` is a genuine registry miss. There is no
+  HONOR-related read anywhere in the codebase: no property, no system feature, no package lookup.
+    - **First HONOR mapping candidate (support mail, 2026-08-14): HONOR Magic8 Pro `BKQ-N49`** (codename `HNBKQ`
+      from the fingerprint, MagicOS 10.0.0.193, Android 16 / SDK 36, contribution schema 2, app 0.3.2-beta0). The
+      three earlier HONOR reports produced nothing: #35 (`MTN-NX1M`, Magic8 Lite) captured `changed_rows=0` across
+      all three namespaces, #40 and #47 carried no capture at all.
+    - The contributor captured the **full 2×2 factorial** of two independent features, which is the only capture
+      design that can attribute two keys to two features. Both changed rows are in the `system` namespace:
+
+      | Mode | Smart battery capacity | smart charge | `UserSmartPeakCap` | `asw_ui_state` |
+      | --- | --- | --- | --- | --- |
+      | off | off | off | 1 | 1 |
+      | Smart battery capacity | **on** | off | 0 | 1 |
+      | smart charge | off | **on** | 1 | 0 |
+      | both | **on** | **on** | 0 | 0 |
+
+      `UserSmartPeakCap` anti-correlates perfectly with Smart battery capacity, `asw_ui_state` with smart charge;
+      both are **1-when-disabled**. Inverted polarity is not itself a problem (every adapter owns its decode), and
+      "peak capacity 1 = uncapped" fits the name equally well.
+    - **Blocker 1 — no behavioral evidence.** All four `user_reported_effect` values are `unsure`, so nothing
+      here distinguishes a real control from a mirror. `asw_ui_state` is specifically suspect: a `_ui_`-named key
+      is the same class as the Oplus `_status` mirrors that `OnePlusChargingAdapter` deliberately never writes.
+      If it is a mirror, the real smart-charge control produced no diff row at all and lives outside the settings
+      providers. **Next step is the both-direction external-write test** (`settings put system <key> <value>` from
+      the shell UID, then check whether HONOR's own battery screen and the charging hardware follow), the same
+      test that settled `tanzanite`. The contributor completed the Shizuku-gated wizard, so they have a working
+      Shizuku setup and are a strong candidate to run it.
+    - **Blocker 2 — no gate signal identified.** The fingerprint is stock-shaped
+      (`HONOR/BKQ-N49/HNBKQ:16/HONORBKQ-N49/10.0.0.193C636E4R106P1:user/release-keys`), so fingerprint sniffing
+      is out for the same reason it was for LineageOS. Whether a MagicOS-exclusive property analogous to
+      `ro.mi.os.version.code` exists **and is readable from an `untrusted_app` process** is unknown and cannot be
+      settled by adb `getprop` (adb runs as shell — see the SELinux trap above). `Build.MANUFACTURER == "HONOR"`
+      alone is a manufacturer gate with no ROM scoping, weaker than every existing OEM gate.
+    - **Level-reporting hazard to test at qualification.** The reporter states Smart battery capacity "still
+      displays 100% when fully charged" while capping. A ROM reporting a synthetic 100% at a real ~80% would
+      trip `full = status == BATTERY_STATUS_FULL || percent >= 100` in `ChargeSessionService`, ending a session
+      early via `RESTORE_FULL`, and would corrupt `StatsLimitHitDetector`. Verify before any adapter ships.
+    - `rom_version=magicos 10.0.0.193` in the report is **free text typed by the contributor**, not a detector
+      output; `one_ui_version=none` / `hyperos_version=none` are the real detectors correctly returning null.
+      Note also that contribution reports carry **no codename field** (unlike the direct device-support report),
+      so an allowlist entry can only come from the fingerprint or a follow-up.
+    - Tracking: GitHub issue #66.

app/src/main/java/eu/darken/amply/charging/core/adapter/OemChargingShortcuts.kt

@@ -13,7 +13,8 @@ import eu.darken.amply.charging.core.DeviceInfo
  * can fall back to manual navigation guidance instead of launching an intent that goes nowhere.
  */
 object OemChargingShortcuts {
-    // Samsung's exported battery-protection activity action (docs/SAMSUNG_SPIKE_RESULTS.md).
+    // Samsung's exported battery-protection activity action, from the Samsung qualification run
+    // (.claude/skills/device-qualification).
     private const val SAMSUNG_ACTION = "com.samsung.android.sm.ACTION_BATTERY_PROTECTION"
 
     fun resolve(context: Context, device: DeviceInfo): Intent? {