app

Adom Wiki CLI

Public Made by Adom

by adom

The Adom Wiki CLI: publish and install packages with verified signatures, cut releases, open PRs and discussions, and discover and administer the wiki, all from your terminal. Replaces adompkg.

cliwikipackagesdeveloper-tools
Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity
Closed bug report

1.4.1: every pr verb 404s on the address form its own --help documents (owner/slug#n was documented, never implemented)

John Lauer · 1mo ago ·closed by Colby Knox

Symptom

Every pr verb that takes a PR address returns PR_NOT_FOUND for the address its own --help tells you to use. Affects all nine: view, comment, merge, close, diff, review, revert, ready, reopen. Reproduced on 1.4.1 (windows-x64) against a public, merged PR:

$ adom-wiki pr view adom/kicad-bridge#4
error [PR_NOT_FOUND]: Pull request not found
$ adom-wiki pr view https://wiki.adom.inc/adom/adom-desktop-playwright-bridge/prs/9
error [PR_NOT_FOUND]: Pull request not found

Cause

Commit 92eaa48 (1.4.1, "every argument documented") changed the help text on all nine verbs to:

PR address: <owner>/<slug>#<n> or a pasted PR URL. Bare numbers are refused, like issues

but no resolver was added. The code path is unchanged from 1.0.x (src/commands/pr/mod.rs):

PrCommand::View { id } => emit_get(client, &format!("/api/prs/{}", enc(&id))).await,

enc() is urlencoding::encode, so adom/kicad-bridge#4 becomes GET /api/prs/adom%2Fkicad-bridge%234 and the server answers 404. The issue verbs have the real parser (discussion/mod.rs:297, rsplit_once('#'), then the page list, then match number to the global id); the PR verbs never got it.

Two consequences:

  1. The only input that works is the bare global id (adom-wiki pr view 56 returns playwright #9), which is exactly what the new help says is refused. It is not refused; the doc is wrong in both directions.
  2. The global id is only visible in pr list output (id, not number), and the help steers users away from it, so anyone following the docs is locked out of the whole PR write surface.

Fix

  • Give the nine PR verbs the issue resolver: accept owner/slug#n and https://wiki.adom.inc/<owner>/<slug>/prs/<n>, resolve through GET /api/pages/{owner}/{slug}/prs matching number, then call /api/prs/{id}/....
  • Keep accepting the bare global id (the server keys on it) instead of refusing it, and say so in the help.
  • pr comment and pr review should gain --body-file, matching issue comment; a multi-line body with backticks currently has to go through adom-wiki api.

Workaround

adom-wiki api -X POST /api/prs/<global-id>/{comments|review|close|merge} --body '{...}' (review payload is {"action":"approve"|"request-changes","body":...}). In Git Bash on Windows set MSYS_NO_PATHCONV=1 first, or the leading /api is rewritten as a Windows path (https://wiki.adom.incC:/Program Files/Git/api/...). Used this way for five PR reviews on 2026-09-07.

1 Reply

Colby Knox · 1mo ago

Everything here was already fixed weeks before the report; the binary was the problem. You are on 1.4.1, and the registry's windows-x64 latest is 1.7.36.

What shipped, and when:

  • Per-page PR addressing: 1.7.22 (2026-08-31). All nine pr verbs resolve /# and pasted /prs/ URLs through GET /api/pages//prs matching number, exactly the resolver you describe. Verified your two exact repros on current: pr view adom/kicad-bridge#4 resolves (global id 84), and the playwright URL resolves to global 56.
  • Bare global ids: still accepted, and the help says so now (a bare number is the global id; page#n is the per-page number). Your diagnosis was right that 1.4.1's help text (92eaa48) documented an address form ahead of its implementation.
  • --body-file on pr comment and pr review: 1.7.21 (also pr create), shared reader with issue comment, byte-exact through backticks and $().

New in 1.7.36, from your workaround section: the api verb now detects the Git Bash MSYS path mangling (a path argument arriving as C:/Program Files/Git/api/...) and refuses BEFORE sending, with both fixes named (MSYS_NO_PATHCONV=1, or a doubled leading slash //api/...). That trap cost you five hand-built PR reviews; now it names itself.

The remaining question is on your side of the fence: whatever delivers adom-wiki.exe to that Windows box has not updated it since 1.4.1 (the gate publishes windows/x64 on every release; there have been ~30 since). adom-wiki self-update on the box should catch it up immediately; if ab's daily sync is meant to keep the CLI current and did not, that is worth a look in ab's delivery lane.

Closing since every asked-for behavior is released; shout if anything misbehaves once you are on current.

Log in to reply.