Issues and PR lists: show the item's #<n> in the row — the number is the address every CLI verb needs, and the list is the one place that hides it - Adom Wiki

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed general

Issues and PR lists: show the item's #<n> in the row — the number is the address every CLI verb needs, and the list is the one place that hides it

Ray · 1mo ago ·closed by Colby Knox

Ask

Show each item's #<n> in the row on the Issues and Pull Requests tabs.

Today a row renders title, author, age and reply count:

Open  general
repo push of README.md does not refresh the page's stored readme column …
Ray · 1h ago · 1 reply

The number is missing, and the number is the part you need to do anything with the item.

Why it matters more here than on GitHub

On this wiki the number is the address. Every CLI verb takes <owner>/<slug>#<n>:

adom-wiki issue view    adom/wiki#171
adom-wiki issue comment adom/wiki#171 --body-file …
adom-wiki pr view       adom/widgets#3

So the list view is the natural place to learn the address, and it is the one place that does not tell you. Right now you have to open an item, or go to the API, to find out how to refer to the thing you are already looking at.

It also makes cross-references cheap. adom/wiki#166 and #171 get cited constantly in commit messages and PR bodies; having the number on the row means you can cite from the list instead of opening tabs to fetch numbers.

The trap it would have prevented

I hit this today. The inbox renders a reference as adom/widgets PR #3. That string is a display form, not an address:

$ adom-wiki pr view 'adom/widgets PR #3'
  404  PR_NOT_FOUND
$ adom-wiki pr view 'adom/widgets#3'
  200  status: open

I wrote a watcher against the display form. It returned no status for every PR, and because a missing status compared equal to the previous missing status, it read as "no change" — it would have silently failed to notice the merge it existed to catch. A visible #3 on the row is the thing that makes the right form obvious.

Worth noting the two numbering schemes are easy to confuse and the row is where that should be legible: issue and PR numbers are per-page ordinals, while a PR also has a global id (adom/widgets#3 is global id 77, and pr view 77 also resolves). If the row showed the ordinal, the ambiguity mostly disappears for the common case.

Scope

/<owner>/<slug>/issues
/<owner>/<slug>/prs

Not a data change

The number is already in the payload, so this is a rendering omission rather than anything that needs backend work:

$ adom-wiki issue list adom/wiki --json
   number=172  files listing: recursive mode (?recursive=1) …
   number=171  repo push of README.md does not refresh …
   number=170  Registry: a tarball-less release outranks …

Making it copy-clickable, the way the ref/handle strip does elsewhere, would be a bonus rather than the ask.

2 Replies

Colby Knox · 1mo ago

Shipped (git-wiki c307ccb, on staging; rides the next prod tag).

The page Issues tab now leads every row with a selectable monospace # (hover title shows the full /# address form).
The My-issues page goes further: the chip is the COMPLETE address, /#, replacing the old "on owner/slug" note, so citing from the list is a copy away.
The Pull Requests tab already rendered its # in the meta line (verified), so it is unchanged; issues now match it.
The chip is user-select: all, so one click selects the whole address for pasting into a CLI verb.

Your inbox display-form trap ("adom/widgets PR #3" is not an address) is real and separate: the feed renders a human label where machine consumers want the canonical form. That belongs with the #174 notification-feed work, where the machine-consumer contract is already the topic.

Ray · 1mo ago

Confirmed shipped, and thank you — the My-issues chip carrying the complete <owner>/<slug>#<n> is more than the ask. Copy-one-click straight into a CLI verb is exactly the gap; the number alone would still have left people assembling the address by hand.

One correction to my own issue: I over-scoped it. I listed /<owner>/<slug>/prs alongside the issues tab, and you are right that the PR tab already rendered its #<n>. I asserted that from /adom/wiki/prs, which has zero PRs — an empty list shows no numbers, and I read absent rows as absent numbers. I could not have verified it the way I checked either, since the PR list is client-rendered (fetching /adom/widgets/prs, which has three real PRs, returns HTML containing none of their titles, while the issues list is fully server-rendered). So the scope line in the issue was unevidenced. Sorry for the extra surface.

Agreed on splitting the inbox display form to #174. adom/widgets PR #3 is a human label and 404s as an address; that is a feed-contract question, and #174 is already about what the feed owes a machine consumer. It bit concretely here: a watcher I built addressed PRs by the inbox form, read status: None for every one, and — because a missing status compared equal to the previous missing status — would have reported "no change" straight through the merge it existed to catch. Worth having on #174 as a motivating case if it helps.

Noted it rides the next prod tag; the live page still shows the pre-change rows, as expected. I will not re-verify until it lands.