[Luna] Run baseline hardware acceptance test on CachyOS

[YangYuS8]

Goal

Run Vigilia's first evidence-based acceptance test on the actual CachyOS laptop, identify reproducible defects, and create focused follow-up issues/PRs. Do not begin broad refactoring before the baseline is recorded.

Starting point

• update to the latest main and record the exact commit with git rev-parse HEAD
• read AGENTS.md
• follow docs/TESTING.md
• use this GitHub issue as the canonical task and test record

Recommended launch from the repository root:

hermes -p Luna

Suggested instruction:

Read AGENTS.md and process GitHub issue #2. Follow docs/TESTING.md, record observable evidence before editing code, and report blockers explicitly.

Required baseline

• Record OS, kernel, Niri/Wayland session, laptop model, camera node, AC power-supply node, Motion version, and Hermes version
• Run ./scripts/verify.sh
• Run installation twice and confirm existing configuration is preserved
• Test local-only mode or vigilia-test-notify
• Arm Vigilia and trigger one controlled camera-motion event
• Confirm the expected picture, movie, TSV events, and journal entries
• Confirm default Motion web-control and stream ports remain disabled
• Unplug the charger once, wait at least ten seconds, and reconnect it once
• Confirm one ordered disconnect/reconnect pair with plausible duration and battery state
• Confirm camera monitoring continues during the AC event
• Unlock and confirm all Vigilia services stop and the camera indicator turns off
• Test notification failure and confirm local evidence remains intact
• Run ./scripts/collect-diagnostics.sh, review/redact the report, and attach only safe excerpts or the reviewed artifact

Reporting format

Post a comment containing:

1. exact commit and branch;
2. commands executed;
3. pass/fail result for every checklist item;
4. minimal relevant event lines and journal excerpts;
5. diagnostics artifact location;
6. each reproducible defect with expected vs. actual behavior;
7. blockers requiring a human action;
8. the exact next action.

Do not upload camera images/video containing other people, vigilia.env, ntfy topics/tokens, raw credentials, or unreviewed diagnostics.

Follow-up policy

• Create one child issue for each independent defect.
• Use a separate branch and focused PR for each fix.
• A git worktree is optional when parallel isolation is useful.
• Link the child issue and PR back here.
• Re-run only the relevant acceptance cases after each fix, then run the complete baseline before closing this issue.
• Keep this issue open with an explicit blocker when a physical action or user decision is still required; do not infer a pass.

Completion criteria

This issue is complete only when the baseline matrix is fully reported, all failures are represented by linked follow-up issues or resolved PRs, and residual risks are stated explicitly.

[YangYuS8]

Baseline hardware acceptance — partial, evidence-backed

Environment

• Initial baseline commit/branch: 8f79bf0e62d374e91f9df56e5921b145be1d8a87 on main (synchronized with origin/main before testing)
• OS/kernel: CachyOS 7.1.5-1-cachyos
• Desktop/session: Niri, Wayland
• Laptop: GLO-NX6
• Camera: HD Camera at /dev/video0 (also /dev/video1); baseline has MJPEG 1280x720 and YUYV 640x480 capability
• AC source: ACAD (type=Mains), battery BAT1
• Motion: installed as 4.7.1-1.1 during this controlled test (initially absent)
• Hermes: 0.19.1
• Notification mode: local-only by default; controlled unreachable-ntfy failure used only http://127.0.0.1:9, then configuration was restored to local-only

Commands executed

• git fetch origin && git merge --ff-only origin/main && git rev-parse HEAD
• ./scripts/verify.sh
• ./install.sh twice; vigilia-status
• v4l2-ctl --list-devices; v4l2-ctl -d /dev/video0 --list-formats-ext
• Motion user-service starts/stops; ss -lntup; systemd-inhibit --list
• Controlled V4L2 one-frame perturbation followed by Motion capture observation
• Controlled notification failure with an unreachable loopback URL
• Simulated lock lifecycle with LOCK_COMMAND="sleep 8" (not a substitute for an interactive swaylock unlock)
• ./scripts/collect-diagnostics.sh artifacts/vigilia-diagnostics-post-test.txt and manual privacy review

Cases

• Static verification — passed: Bash syntax for 12 files; default Motion web-control/stream ports disabled. ShellCheck unavailable, so no ShellCheck result.
• Install/idempotence after dependency availability — passed: two installs preserved vigilia.env; generated config mode 0600; commands resolve; target inactive before arming.
• Local-only notification — passed: vigilia-test-notify exited 0 with empty topic; local event persisted while motion/power services stayed active.
• Motion service / network exposure — passed: Motion 4.7.1 started against generated config and opened /dev/video0; no Motion control/stream listener was observed while active.
• Controlled motion evidence — passed: controlled camera perturbation produced MOTION_START and PICTURE_SAVED for event 01; a JPEG and MKV were created. No image/video is attached.
• AC disconnect/reconnect — blocked: the 90-second physical disconnect window ended with ACAD/online=1, so no AC_DISCONNECTED/AC_RECONNECTED evidence exists. This is not a pass.
• Service continuity during armed mode — passed: motion, power, and inhibit services active concurrently; a Vigilia sleep:idle blocking inhibitor was present.
• [~] Lock/disarm lifecycle — partially passed: simulated blocking lock-command exit stopped target/power/inhibit and recorded DISARMED reason=unlock; motion was briefly deactivating then verified inactive with no camera owner. Two manual disarms were harmless. Interactive swaylock unlock and physical LED observation remain untested.
• Network failure — passed: unreachable loopback ntfy generated NOTIFY_FAILED after MOTION_START; motion and power services remained active; the event log contained no token/Authorization string.
• Diagnostics — generated and reviewed locally. It contains user home paths and capture filenames, so it is intentionally not attached.

Minimal redacted evidence

2026-08-02T16:54:27+08:00  MOTION_START    event=01
2026-08-02T16:54:27+08:00  PICTURE_SAVED  event=01 file=<capture>
Motion capture metadata: <event-01.jpg> 27985 bytes; <event-01.mkv> 1835008 bytes
2026-08-02T16:55:26+08:00  MOTION_START    event=notify-failure-test
2026-08-02T16:55:26+08:00  NOTIFY_FAILED   title=Vigilia detected movement
2026-08-02T16:56:07+08:00  ARMED           services=motion,power,inhibit
2026-08-02T16:56:15+08:00  DISARMED        reason=unlock

Findings and follow-up

1. Installer falsely succeeded with motion absent. Child issue fix: fail before writing installation state when runtime dependencies are missing #4; repair PR fix: prevent partial installs when dependencies are unavailable #6 (ae8d423) prevents every installation side effect when a required command is missing. Isolated HOME/PATH regression: missing Motion -> exit 1 and no command/config state; complete command set -> install succeeds. PR is open and has no CI checks configured yet.
2. Camera configuration negotiated away from requested resolution. Motion requested 1280x720 without pixel format, then logged a fallback to YUYV 640x480. The event still produced a JPEG/MKV, but the configured value was not honored. Tracked independently in child issue fix: make default Motion capture format and resolution explicit for the baseline camera #5.

Blockers / exact next action

• Physical AC disconnect/reconnect was not performed within the test window. Re-run that one controlled case with the charger physically unplugged for at least 10 seconds, then confirm exactly one ordered pair and duration.
• Re-run the genuine swaylock unlock plus camera-LED observation in a controlled room.
• Review/merge PR fix: prevent partial installs when dependencies are unavailable #6, then re-run the full baseline on its merged commit before closing this issue.

[YangYuS8]

Maintainer acceptance review

Luna 的本轮基线报告验收通过，作为部分完成、证据充分的基线是合格的：

• 明确区分了通过、部分通过和阻塞项；
• 没有把未实际完成的 AC 拔插或真实 swaylock 解锁声称为成功；
• 摄像头事件、录像/抓拍、本地日志、通知失败降级和服务并行运行均提供了最小脱敏证据；
• 两个独立缺陷拆分合理，没有进行无关重构。

PR #6 已经独立回归验收并 squash 合并为 6f373d633c003d7925fd112498edc1df9df0714f，issue #4 已关闭。issue #5 保持开放，问题和验收目标有效。

本 issue 继续保持开放。剩余必需动作：

1. 更新到最新 main，记录新的基线提交；
2. 实际拔掉充电器至少 10 秒并重新插入，确认恰好一组有序的 AC_DISCONNECTED / AC_RECONNECTED 事件及合理持续时间；
3. 使用真实 swaylock 完成解锁，确认所有服务停止且摄像头指示灯熄灭；
4. 在最新 main 上重跑完整基线；
5. issue fix: make default Motion capture format and resolution explicit for the baseline camera #5 修复后重新执行受影响的摄像头验收项。

在上述证据齐全前不要关闭 #2。

[YangYuS8]

Pending physical acceptance — operator actions required

The remaining two baseline cases must be performed on the owner-operated laptop; no simulation will be used.

1. AC disconnect/reconnect

When to begin: only after Luna posts a separate AC TEST READY reply in this issue. That reply means vigilia-power.service and vigilia-motion.service are active and the event baseline is recorded.

Your exact actions:

1. In the controlled room, unplug the laptop charger once.
2. Keep it unplugged for at least 12 seconds (the acceptance minimum is 10 seconds; the additional margin avoids a boundary race).
3. Reconnect the same charger once. Do not repeatedly dock/undock or move the camera during this interval.

What Luna will check afterward: exactly one ordered AC_DISCONNECTED then AC_RECONNECTED line; a plausible duration of at least 10 seconds; battery status/capacity in both events when exposed; continued vigilia-motion.service health; and separate local notification-failure evidence if notification delivery fails.

2. Real swaylock unlock and camera LED

When to begin: only after Luna posts a separate SWAYLOCK TEST READY reply in this issue. That reply means vigilia-arm is about to invoke the configured real swaylock, not a substitute command.

Your exact actions:

1. Confirm no bystander is in the camera frame, then let the real lock screen appear.
2. Observe that the camera indicator is active while locked.
3. Unlock normally using your usual local session credentials.
4. Within 15 seconds after the desktop returns, observe that the camera indicator has turned off. Do not force-stop services manually.

What Luna will check afterward: DISARMED reason=unlock; inactive target, motion, power, and inhibit services; no process retaining /dev/video0; and relevant user-journal ordering. If the LED remains on or normal unlock fails, stop immediately and report it here.

Until each corresponding READY signal, do not begin the physical action. The upcoming camera-format PR validation is independent of these two cases.

[YangYuS8]

Incremental update — #5 camera-format validation

• New baseline: 6f373d633c003d7925fd112498edc1df9df0714f on main; dedicated repair worktree/branch: fix/motion-format-observability.
• Investigated the real baseline before editing: Motion 4.7.1 accepted the old 1280x720 request only by falling back to YUYV 640x480; V4L2 confirmed the final active format. The candidate deliberately uses generic 640x480 and does not pin a GLO-NX6-specific v4l2_palette.

Commands run

• ./scripts/test-motion-format.sh
• ./scripts/verify.sh
• isolated new-install template and V4L2-preflight checks
• staged systemd-analyze --user verify
• real /dev/video0 Motion run with v4l2-ctl --get-fmt-video, event/capture metadata review, and ss -lntup
• reviewed ./scripts/collect-diagnostics.sh output locally; it contains home paths/capture names and is not attached

Result

• Candidate probe records CAMERA_FORMAT_ACTIVE, CAMERA_FORMAT_DEGRADED, or CAMERA_FORMAT_UNKNOWN in the local TSV/journal. vigilia-status exposes the latest format line.
• Real candidate hardware evidence: CAMERA_FORMAT_ACTIVE requested=640x480 actual=640x480 format=YUYV device=<video>.
• Controlled movement produced motion start, representative JPEG, completed MKV, and ordered local event lines. The final 60-second window produced two events rather than one; this is recorded as a motion-threshold observation, not silently treated as an exact-one-event pass.
• No Motion web-control or stream listener was observed.
• All Vigilia services are inactive after testing.

Remaining blockers / next action

• AC disconnect/reconnect and genuine swaylock unlock/LED cases remain pending and will be performed only after their separate READY signals, as documented in the prior comment.
• Await independent review before committing/opening the fix: make default Motion capture format and resolution explicit for the baseline camera #5 PR. No capture, event TSV, diagnostic, or user configuration is committed.

[YangYuS8]

Incremental update — #5 PR opened after final controlled acceptance

• Commit: 5fd4ff925aa8433796f718ec6e0ad498e17fc4cd (fix: record negotiated Motion capture format)
• PR: fix: record negotiated Motion capture format #7 — fix: record negotiated Motion capture format #7 (open; no GitHub check runs are configured yet)

Final commands and outcomes

• ./scripts/test-motion-format.sh — passed, including stabilized V4L2 sample sequence and explicit ACTIVE/DEGRADED/UNKNOWN behavior.
• ./scripts/verify.sh — passed: Bash syntax for 14 files, format regression, no default Motion control/stream port. ShellCheck remains unavailable.
• systemd-analyze --user verify systemd/user/vigilia-motion.service — passed.
• Confirmed final independent review after the sampling-race repair: no security or logic blockers.
• Final operator-confirmed real /dev/video0 movement window: one ordered MOTION_START -> PICTURE_SAVED -> MOVIE_SAVED; JPEG 27380 bytes and MKV 1996347 bytes were created locally (not attached); CAMERA_FORMAT_ACTIVE requested=640x480 actual=640x480 format=YUYV device=<video> was recorded; no Motion control/stream listener was observed.

Current blockers / next action

• fix: make default Motion capture format and resolution explicit for the baseline camera #5 now awaits PR fix: record negotiated Motion capture format #7 review/merge. It remains open until the merged commit is revalidated as appropriate.
• The real AC disconnect/reconnect and genuine swaylock/LED lifecycle tests remain blocked on their separately announced operator-ready windows; no simulation has been substituted.

[YangYuS8]

Incremental update — real AC disconnect/reconnect accepted

• Commit/branch: 6f373d633c003d7925fd112498edc1df9df0714f on main.
• Operator-confirmed physical sequence: starting from ACAD=1, charger unplugged once, held for the requested 12 seconds, then reconnected once. No simulated power state was used.

Commands / evidence

• Started real vigilia-motion.service and vigilia-power.service; recorded POWER_WATCH_STARTED baseline.
• Monitored /sys/class/power_supply/ACAD/online, then reviewed TSV, user journal, service state, ss -lntup, and a locally reviewed diagnostics report.
• Exactly one ordered pair was recorded:
  • AC_DISCONNECTED at 18:15:39+08:00, battery 100%, Full;
  • AC_RECONNECTED at 18:15:59+08:00, duration=20s, battery 100%, Discharging.
• Duration is plausible for the controlled interval. Both motion and power services stayed active after reconnect. No Motion control/stream listener was observed.
• Current final state: ACAD=1, battery Full/100%, target and all Vigilia services inactive after controlled cleanup.
• ./scripts/collect-diagnostics.sh artifacts/vigilia-diagnostics-ac-test.txt completed; it has 36 home-path/capture-path occurrences, so it was reviewed but not attached. No ntfy token/topic/Authorization indicator was found in the report.

Result / remaining blocker

• Real AC disconnect/reconnect acceptance case is now passed.
• Genuine swaylock unlock plus physical camera-LED observation remains the only baseline hardware blocker. Luna will present a click-to-confirm readiness action before starting that physical test; no simulated substitute will be used.