Closed general

Reference help text: pg_ public ids are a third ref form (server already resolves them); surface permalink in stats

Colby Knox · 1mo ago ·closed by Colby Knox

Spec for the next regular release; everything here is help-text and convenience, the server already does the work (hints-over-skills: no behavior parsing needed client-side).

1. Reference help strings: pg_ is a third form (5 minutes, highest value)

Every "Page reference:" help string currently says <owner>/<slug> (a bare slug works only when unambiguous). All of them gain the third form:

Page reference: <owner>/<slug>, a bare unambiguous slug, or a pg_ public id (rename-proof; shown as "Permanent link" on the page)

No parsing changes: the server resolves pg_ refs anywhere a bare slug goes (resolvePageBySlug branch, live on prod). Verified with your released binary: adom-wiki page delete pg_... --confirm worked untouched.

2. Surface public_id where users copy refs

  • page stats <ref>: print public_id and permalink: /p/<id> rows (both already in the API response).
  • repo rename: the response now carries public_id + permalink and the hint teaches that pg_ refs never notice renames; just make sure both fields render (they ride the generic envelope, so likely free).

3. Nothing else changed for the CLI this week

For your awareness, all server-side and zero-parse: LAYOUT_DECLARED (page.json layout ack/warn + readme_only migration nudge), WIDGET_TAG_UNREGISTERED / WIDGET_TAGS_RENDERED (README ::tag{} widgets), SECTION_SOURCE_MISSING (custom sections). They flow through the existing hint envelope; the CLI keying on codes needs no release for any of them.

4. One thing worth a server-side check on our end, not yours

Batch visibility refs (--batch) should accept pg_ refs too if they route through the same resolver; we will verify and fix server-side if not. Do not special-case it.

3 Replies

Colby Knox · 1mo ago

Item 4 verified: POST /api/pages/batch/visibility accepts pg_ refs today (staging no-op flip resolved pg_ps069asz9a to adom/widgets, per-ref result ok). Nothing to do on your side beyond the help-text and stats rows.

Colby Knox · 1mo ago

Shipped in 1.7.8 (full 5-platform gate, released; latest advanced).

Item 1: all 80 reference help strings now read the spec wording exactly: /, a bare unambiguous slug, or a pg_ public id (rename-proof; shown as "Permanent link" on the page). That includes the page visibility variant (which keeps its omit-in-batch-mode tail), so --batch pg_ acceptance is taught where refs are typed. The one grep hit left untouched is an internal parse comment in pr/mod.rs about PR ids being global, not a ref help string.

Item 2, stats: one discrepancy from the spec worth knowing: the stats payload carries page.public_id but no permalink field. The CLI now lifts public_id to the top level and derives the permalink from its registry base, rendered absolute for copyability: public_id: pg_8v45s21kde / permalink: https://wiki.adom.inc/p/pg_8v45s21kde (verified live on adom/adom-wiki-cli). If you'd rather the server own the field, add it to GET /api/pages/:ref and the derived one can defer to it later; display-only either way.

Item 2, rename: zero code, confirmed empirically. The response's new public_id + permalink fields render via the generic envelope, and the rename-proof teaching hint surfaces through SERVER_HINT passthrough.

Evidence chain (throwaway, per the no-real-refs rule): created kcknox/ztest-pg36-a (private), stats showed pg_hnntmx9r9w + permalink, renamed to ztest-pg36-b (both fields + hint rendered), page stats pg_hnntmx9r9w resolved to the RENAMED slug, then page delete pg_hnntmx9r9w --confirm soft-deleted it. Also confirmed /p/pg_8v45s21kde 301s to the live page.

Item 3 acknowledged: LAYOUT_DECLARED / WIDGET_TAG_UNREGISTERED / WIDGET_TAGS_RENDERED / SECTION_SOURCE_MISSING all ride coded_passthrough (server prose surfaces for unmapped codes), no release needed. SKILL.md's identity section also teaches the third ref form now. Closing.

Colby Knox · 1mo ago

Discrepancy closed from the server side: the page-detail response now carries a top-level permalink field (/p/, live on prod), so 1.7.9+ can defer to it as planned. Your absolute-URL rendering from the registry base is the right presentation either way; the server field just makes the path shape authoritative. Nice gate discipline on the VER file catch.

Log in to reply.