feat: Phase 3 recipes file, spotify_play, and locked-screen refusal

Phase 3 of AGENTS.md section 11.

Recipes file (FR-5)
- recipes/ holds one hand-editable file per task; recipes/spotify_play.recipe
  is the first one.
- internal/recipe parses directives, guards, parameters and steps, and runs
  them with a per-step and a whole-run timeout (FR-11).
- Steps name text ("tap the element whose text is Search"), never coordinates.
- guards name screens Artemis must never tap on, so a signed-out or
  first-run Spotify fails with its own reason (FR-8).
- Every run appends task, params, steps, result and duration to
  logs/runs.jsonl (FR-10).

spotify_play
- launch, search, play, then wait for the transport button to say "Pause".
- internal/ui/rows.go adds tap_row: a result row is a clickable container with
  a title and a subtitle, so a one-line search suggestion is not a result, and
  the tap lands on the row's centre rather than on its "More options" button.
  This fixes a real wrong tap: a plain text tap hit a 126x12 pixel
  "More options for song Honky Tonk Women - Live" button.

Locked screen (AGENTS.md section 13 Q2, decided)
- Artemis fails loudly on a secure keyguard and never types a PIN. No secret is
  stored. A non-secure keyguard is still dismissed.
- internal/ui/keyguard.go reads the KeyguardServiceDelegate block plus
  cmd lock_settings is-user-secure.
- Every acting command wakes the screen before it checks the keyguard: a dozing
  phone reports showing=false, because the lock screen is not drawn yet.
- AGENTS.md records the decision and that storing a PIN for auto-unlock is
  rejected for now.

Verified live: the phone locked itself mid-session, and keyguard, tap and
run spotify_play all refused with "phone is locked; unlock it and retry".
The live end-to-end playback run still needs an unlocked phone.
This commit is contained in:
2026-10-16 13:24:22 +11:00
parent 7767651c11
commit 2604fea483
15 changed files with 2192 additions and 23 deletions

View File

@@ -176,12 +176,23 @@ Resolved:
was USB-only and is removed in this NixOS release anyway. Go is likewise run
from a one-off `nix shell nixpkgs#go`, not installed system-wide. Never run
`nixos-rebuild` on `.13`: it runs the Hub, MQTT and every service.
6. **Locked screen — Artemis fails loudly. It never unlocks the phone.** It
detects a secure keyguard (PIN, pattern or password) before acting and
refuses with `phone is locked; unlock it and retry`. It does not dismiss a
secure keyguard and it does not type anything into one. A *non-secure*
keyguard (the phone has no PIN at all) is still dismissed, because that
screen guards nothing. **No PIN is stored, read or transmitted**, and there
is no secret for one. **Storing a PIN for auto-unlock is rejected for now** —
the phone is a pocket device, and Artemis is a convenience, not a reason to
keep Sam's unlock credential in a service on `.13`. This is revisit-able if
the daily friction turns out to be worse than the risk.
Remaining:
1. Which tasks after Spotify and maps? (WhatsApp message? Other music apps?)
2. Locked screen: must Artemis unlock it, or does Sam leave it awake?
3. Action API shape: one generic `/act`, or one endpoint per task?
4. **Service packaging** for Artemis on `.13` — container or systemd — is still
2. Action API shape: one generic `/act`, or one endpoint per task?
3. **Service packaging** for Artemis on `.13` — container or systemd — is still
open. ADB can be awkward in a container, so this is decided in Phase 6. The
tooling-placement half of the old Q4 is resolved above.
5. Speed: what is an acceptable time for a 6-step recipe?
4. Speed: what is an acceptable time for a 6-step recipe?
5. The recipes file has grown `guard`, `tap_if` and `wait_gone` verbs. If it
keeps growing, decide whether the format stays bespoke or moves to YAML.