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:
19
AGENTS.md
19
AGENTS.md
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user