[barbatdev]

Summary

• Removes the agents block (refactoria-agents mod) from the refactoria layout; waiting alerts already live on the space rows and machine headers. The mod files stay in the repo.
• Adds refactoria-prs: open PRs of the active space's repo, each with a combined checks dot (green pass, red fail, amber running, gray none); click opens the PR in the browser.
  • Repo from git remote get-url origin where the space lives (any machine); gh pr list -R runs locally, so remote machines need no GitHub login.
  • Refreshes on space switch and every 60s; says so when there is no space, no GitHub repo or no open PRs.
• install.sh and herdr-screens link the new mod.

Test plan

• node --check, herdr-app check on the mod, bash -n install.sh, fish -n herdr-screens.fish
• Live screenshot: panel lists the 4 open PRs of barbatdev/cortex-dotfiles
• Not yet seen on a remote space or a non-GitHub folder

🤖 Generated with Claude Code

https://claude.ai/code/session_01A9D7ph123Jn8iB1eGbr8Nz

[barbatdev]

Fleet review (deepseek)

Lens: evidence + test design. The change is small and internally consistent: the refactoria layout block, install.sh and herdr-screens all link refactoria-prs, the mod renders every state the PR body names (no space, not a GitHub repo, no open PRs, gh failure), and a row marks draft PRs and shows the combined checks dot. The diff matches the body; the gaps are evidence, not behavior. The two exported pure functions (slug, checks) have no tests, the remote-space and non-GitHub branches are untested by the author's own admission, and the refresh path silently drops a space switch while a fetch is in flight. No blocking finding.

Suggestion (2)

• A space switch that lands during an in-flight fetch is dropped (herdr/desktop/mods/refactoria-prs/main.js:49): refresh returns on this.loading before it records the new space in this.key, so a switch that arrives while a request is pending is never taken: the in-flight call still passes its own key === this.key check and writes the previous space's repo and PR list, and the panel keeps showing them until that call settles. Neither exec call passes a timeout, so if the process never returns, the guard never clears and every later refresh (including the 60s fallback) is skipped. Missing test condition: switch space A to B while the git/gh call is pending (or make exec never resolve) and assert the panel ends on B's repo, or on a loading state, instead of A's rows.
• slug() and checks() are exported but have no tests (herdr/desktop/mods/refactoria-prs/main.js:20): These are the only two pure functions in the file and both are exported, so a plain node/vitest file covers them; today the checks-dot colour and the repo detection are verified only by node --check and one screenshot. Missing test conditions. slug(): git@github.com:owner/repo.git, https://github.com/owner/repo, the same URL with a trailing slash, an ssh host alias git@alias:owner/repo, an empty string and a non-GitHub URL, plus the empty stdout that git remote get-url origin produces when the space is not a repo (the panel relies on null for its "Not a GitHub repo" state). checks(): empty rollup -> none; one FAILURE among SUCCESS checks -> fail; one IN_PROGRESS among SUCCESS -> pending; a StatusContext with state ERROR -> fail; a COMPLETED CheckRun with conclusion null -> pending.

Question (1)

• Every conclusion outside the two lists reads as a green pass (herdr/desktop/mods/refactoria-prs/main.js:28): states maps a COMPLETED CheckRun to its conclusion and then falls back to pass for anything not in the fail list or the pending list, which includes STALE, NEUTRAL and SKIPPED; a COMPLETED check with a null conclusion lands in pending instead, because null is in that list. The PR body defines green pass, red fail, amber running and gray none, but not where STALE belongs. Question: is a stale check meant to read as green here, and should a check whose conclusion is null read as amber? Whichever you decide, the test conditions above should pin it.

Verdict: ready to merge

[barbatdev]

Fleet review (glm)

Lens: requirements + adversarial. The PR replaces the agents panel with a pull-requests panel and delivers what its body promises: the layout block swaps to refactoria-prs, the mod is linked from install.sh and herdr-screens, the panel reads the repo from the active space's git origin, lists open PRs with a combined checks dot, refreshes on switch and every 60s, and shows explicit notes for no space / not a GitHub repo / no open PRs. The refresh logic handles space switches during an in-flight request (stale results dropped via key comparison, loading guard), and gh/git failures degrade to an error note instead of breaking the panel. No linked issue; the PR body's own summary was used as criteria and is satisfied. No blocking defects found; two minor robustness notes and one open verification question from the PR's own test plan.

Suggestion (2)

• slug() can extract a wrong owner/name from nested-path remotes (herdr/desktop/mods/refactoria-prs/main.js:19): The regex anchors on the last ':owner/name' or '/owner/name' segment, so a remote with more than two path segments (e.g. a GitLab subgroup URL 'https://host/group/subgroup/repo.git' or a bare filesystem path '/srv/git/repo.git') resolves to the last two segments ('subgroup/repo', 'git/repo'), which is not a valid -R value for GitHub. The panel then shows the gh error instead of PRs. Self-degrading and this repo is GitHub-only, so not blocking.
• checks() reports CANCELLED as a failure (herdr/desktop/mods/refactoria-prs/main.js:25): CANCELLED and STARTUP_FAILURE are in the fail set, so a workflow run someone manually cancelled (or that failed at startup for infra reasons) paints the dot red for a PR that has no failing code check. Consider whether a cancelled run should read as 'fail' or as a neutral state in this dashboard.

Question (1)

• Remote-space and non-GitHub-folder paths are still unverified (herdr/desktop/mods/refactoria-prs/main.js): The PR's own test plan leaves 'Not yet seen on a remote space or a non-GitHub folder' unchecked. The remote-machine path is the main behavioral difference versus reading the repo locally, and the exec failure path ('Could not reach the repo') has not been observed live.

Verdict: ready to merge