agent-check.yml `windows` job fails on every branch: `MaxMin` is not published in ms609.github.io/packages, so pak cannot resolve it

[ms609]

The windows job of agent-check.yml fails on every branch of this fork, in the
Set up R dependencies step, before a single line is compiled. ubuntu-arm64 passes.

! error in pak subprocess
Caused by error:
! Could not solve package dependencies:
* deps::.: Can't install dependency MaxMin
* MaxMin: Can't find package called MaxMin.
* any::sessioninfo: dependency conflict

Cause — corrected 2026-08-04

The first version of this issue said the cause was a missing Remotes:/repository field. That
was wrong: DESCRIPTION:78 already carries
Additional_repositories: https://ms609.github.io/packages. The real cause is one level up.

MaxMin is not published in that repository. It currently serves ten packages — and MaxMin
is not one of them:

BigTreeDist  BigTreeTools  moments  palec  TBRDist
Ternary      TreeDist      TreeDistData  TreeSearch  TreeTools

Verified with available.packages(repos = "https://ms609.github.io/packages/", type = "source")
→ 10 rows, "MaxMin" %in% rownames(.) → FALSE. The trailing slash makes no difference (both
forms resolve to the same 10). So no edit to DESCRIPTION or to the workflow can fix this
while MaxMin is absent from the index — the index is what pak resolves against.

MaxMin is a genuine dependency, not vestigial: used in R/WideSample.R,
tests/testthat/test-WideSample.R and inst/Parsimony/global.R. And ms609/MaxMin exists and
is public (pushed 2026-07-08), so nothing here needs a secret.

Secondary point, relevant only after publishing: Additional_repositories is a CRAN-check
convention — it tells R CMD check where a non-CRAN Suggests lives. It is not reliably a pak
resolution source, and pak resolves against getOption("repos"). agent-check.yml calls
r-lib/actions/setup-r-dependencies@v2 at lines 56 and 115 and passes no extra-repositories:
input, so the drat repo never enters repos on either leg. The field being present and the
job still failing is consistent with that.

For completeness on why the two legs differ: ubuntu-arm64 passes, so it is resolving
Suggests differently (or tolerating an unresolvable one) rather than proving the repo is
reachable from Linux.

Fix

1. Publish MaxMin to https://ms609.github.io/packages. Required under any approach, and it
   is an action in the MaxMin/drat repo, not here. The repository already serves Windows binaries
   for R 4.4/4.5/4.6 (4.7 absent), so once MaxMin is there the Windows leg gets a binary rather
   than a source build — which is the reason to prefer this route.
2. Add extra-repositories: https://ms609.github.io/packages to both
   setup-r-dependencies steps in agent-check.yml, so pak actually looks there instead of
   relying on Additional_repositories. Cheap, and it removes the ambiguity above. Worth
   auditing the other workflows for the same omission.
3. Interim, if CI needs unblocking before (1): Remotes: ms609/MaxMin resolves today from
   the public GitHub repo, as a source build. The cost is a field CRAN reviewers ask to be
   removed — presumably why the sibling CRAN packages (Consensus:43, TreeDist:42) use
   Additional_repositories and only the non-CRAN StratoBayes uses Remotes:.

Also unresolved: the same error reports any::sessioninfo: dependency conflict, which may be a
second independent problem rather than fallout from the first.

Evidence that it is branch-independent

Two unrelated branches, minutes apart, same step, byte-identical error:

Run	Branch	ubuntu-arm64	windows
30908977215	feature/redteam-area12 (docs + one C++ comment)	success	failure
30908703022	claude/treesearch-issue-38-8103cc	—	failure

Why this matters more than one red job

AGENTS.md names GHA dispatch the primary validation path, and the feature-branch lifecycle
says to open a PR "on GHA success". As things stand no branch can reach that state, so either
every agent blocks forever or every agent learns to merge past a red check — and the second is
how a real Windows regression gets waved through later. Windows is the platform this project has
historically been bitten on (MinGW emutls teardown, DLL locking, the nm | sed .def
truncation that src/TreeSearch-win.def exists to prevent), so it is the wrong job to leave
broken.

Found by the 2026-08-04 area-12 red-team round, which hit it dispatching its own validation.
Unrelated to that round's diff — filed separately so it is not buried in a docs PR.

[ms609]

Corrected the diagnosis above. The original text blamed a missing repository field; DESCRIPTION:78 already has Additional_repositories: https://ms609.github.io/packages. The actual blocker is that MaxMin is absent from that repository's index (10 packages, MaxMin not among them), so no DESCRIPTION or workflow edit can resolve it until MaxMin is published there.

[ms609]

Claimed — working on feature/ci-maxmin-windows (worktree ../worktrees/TS-ci-maxmin).

Diagnosis is now settled and it is not a registration problem: bin/windows/MaxMin_latest.zip is the deliberate flat alias documented in ms609/packages' tools/publish-maxmin.R, it is live (HTTP 200), and it is Built: R 4.6.1 — which is exactly the current R release, so it matches r-version: "release". The bug is in this repo: agent-check.yml's arm64 leg carries the url:: MaxMin line (:69) and the windows leg has no extra-packages: block at all. Correcting the issue body.

[ms609]

Root cause found, and it is two mechanisms, not one. Correcting my earlier candidate fixes, all three of which were wrong.

1. url:: is needed for the lockfile solve. pak does not read Additional_repositories (as ms609/packages' tools/publish-maxmin.R already recorded from a 2026-08-03 test), so the drat's indexed contrib/ layout is invisible to it. The Linux legs name their flat alias; the Windows and macOS legs named nothing. Adding url::.../bin/windows/MaxMin_latest.zip fixes that phase — the run logged ✔ Installed MaxMin 0.0.0.9004.

2. But that alone still fails, on a second solve. Seconds later the same step died with a different ref:

* local::.: Can't install dependency MaxMin

setup-r-dependencies' "Check whether pandoc needs to be installed" step runs

pak::pkg_deps(".", dependencies = list(direct = "all", indirect = character()))

a fresh solve that sees neither the lockfile just built nor extra-packages, so it looks MaxMin up by name and fails — despite MaxMin being installed moments earlier. That branch only runs when Sys.which("pandoc") == "". Linux runners ship pandoc and return early; Windows and macOS runners do not. That asymmetry is the whole reason this was a non-Linux-only failure, and why the arm64 leg's url:: line has always sufficed there.

Fix: pin install-pandoc explicitly so auto-detect never runs — true where the job checks with vignettes, false for the shinytest2 job. The quarto auto-detect needs no equivalent: it globs for *.qmd and never calls pkg_deps.

Corrections to the body above, for the record: (a) it first blamed a missing repository field, but DESCRIPTION:78 already carries Additional_repositories; (b) it then said MaxMin needed publishing, but it is published — bin/windows/MaxMin_latest.zip is live and Built: R 4.6.1, matching the current release; (c) its candidate fix 2 proposed an extra-repositories: input, which does not exist on r-lib/actions/setup-r-dependencies (inputs are cache, cache-version, extra-packages, needs, packages, pak-version, working-directory, dependencies, upgrade, lockfile-create-lib, install-pandoc, pandoc-version, install-quarto, quarto-version). Each was asserted from plausibility; the fix only became correct after reading the action's source.

Verified on feature/ci-maxmin-windows (run 30916727681): "Set up R dependencies" now completes successfully on Windows, and the job proceeds to R CMD check.