Frank
8af40c402b
Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and `merge --ff-only` refuses while tracked paths are dirty. Discard is not available here (workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed. - `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new prose — the commit exists so the trunk merge can proceed. - `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat owns (AGENTS.md § Live-sync tiers). `ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the inert all-zero AWS example id — and they appear inside the two skill pages that teach that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal dies with this landing. No `--no-verify` was used: the gate ran and its verdict is recorded here. Refs #61
2.5 KiB
name, description
| name | description |
|---|---|
| xdg-open-tab-proof-niri | Prove an xdg-open URL actually landed a tab in Frank's Firefox on niri, instead of reporting the law-compliant "opened in your browser" blind. |
AGENTS.md (dank/command-center) requires opening every PR in Frank's browser with xdg-open <PR-URL>. xdg-open exits 0 whether or not a tab appeared, and its stderr is easy to swallow (>/dev/null 2>&1 &), so "opened in your browser" is normally an unverified claim. Prove it before saying it.
The proof that works
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export WAYLAND_DISPLAY=${WAYLAND_DISPLAY:-wayland-1}
niri msg windows | grep -iA2 'firefox\|gitea\|pull'
Expected — the tab title is the page title, so it doubles as confirmation you opened the right object:
Title: "#61 - fix(#60): checks that lied… - command-center - Frank's Dank Gitea… — Mozilla Firefox"
App ID: "firefox"
PID: 1150647
Why the obvious checks fail here
- The computer/AX window list does not list Firefox.
computer.windows()on this Wayland backend returned only ghostty windows — Firefox exposes no ATSPI top-level unless accessibility is already active inside it — so an empty list is not evidence the tab is missing. capture: false,displayCount: 0incomputer.capabilities()mean screenshots are unavailable (display asleep); a blank screenshot proves nothing either way.wmctrl -l/hyprctldo not exist on niri.niri msg windowsis the window census, andniri msg outputsis the output census.pgrep -af firefoxonly shows the process tree (one parent +-contentprocchildren); a tab never appears there.- The web page itself is not proof: Gitea's
/dank/<repo>/pulls/NHTML answers 404 without a session cookie even though the API and the browser both work.
Dispatch recipe (when nothing is running, or nothing landed)
XDG_RUNTIME_DIR=/run/user/$(id -u) WAYLAND_DISPLAY="${WAYLAND_DISPLAY:-wayland-1}" \
xdg-open https://gitea.franksdank.cloud/dank/<repo>/pulls/N
Give it the https://gitea.franksdank.cloud/… form, not the LAN 192.168.0.143:3000 form the API returns — that is the host Frank's bookmarks and cert expectations use. A running Firefox receives the URL as a new tab in the existing instance; re-dispatching opens a second tab, which is a cheap, idempotent way to recover from a swallowed failure.
Related: gitea-pr-api-cycle (the API cycle whose final step this verifies), omp-tui-live-visual-verify (same rule for terminal UIs: observe the real surface).