CLI: issue edit --image, and repeatable --image on create/comment

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

Colby Knox · 2mo ago ·closed by Colby Knox

Follow-up to adom/wiki#7, which is closed now that the server side is done: user media is stored in the R2 user-content bucket, POST /api/pages/<owner>/<slug>/attachments exists as a standalone upload verb, and reply/discussion edit and delete are live.

Two of John's five items are CLI-side and still open. The endpoint they need already exists, so these are wiring, not new server work.

A. adom-wiki issue edit --image

issue create and issue comment both take --image; issue edit does not. So a body whose image is wrong can be reworded but its image cannot be replaced, which is the workaround loop the original issue was about. The CLI should upload, then substitute into the body it PATCHes.

B. Repeatable --image

--image is single-valued on both verbs that have it. Attaching three screenshots to one issue means three replies today. Make the flag repeatable and embed the URLs in flag order.

Contract the CLI must respect

The endpoint returns the wiki's own path, /attachments/<owner>/<slug>/<sha256>/<name>. Embed that verbatim. Do not rewrite it into a bucket or alias URL: the wiki path is where the page access check runs, and a bucket URL both skips that check and hardcodes a storage backend the server is free to change.

Behavior worth surfacing in errors rather than rediscovering: 10MB per image, 30 uploads per minute per caller, png/jpg/jpeg/webp/gif only. A rejected type returns BAD_ATTACHMENT_TYPE with the allowed list in data.allowed, so the CLI can print the list without carrying its own copy.

1 Reply

Colby Knox · 2mo ago

Both CLI items shipped in adom-wiki-cli 1.0.77, wiki latest now, plus the neighbors that made sense in the same pass.

A. issue edit --image exists, with the append semantics your writeup recommended: --image appends to the body being written, and with --image alone the CLI fetches the CURRENT body first and appends to it, so a wrong image is fixed in one command instead of delete-and-repost. Replacing images stays explicit through --body/--body-file, which carry the full text anyway.

B. --image is repeatable on issue create, issue comment, issue edit, AND pr comment (parity was free); URLs embed in flag order. Also shipped: page attach <files...> as the standalone verb (your item C), printing the wiki URLs plus sha256/bytes/stored, with stored:'local' surfaced as a bucket-fallback diagnostic rather than an error.

The contract is pinned where it cannot drift: the upload helper's doc comment and the shipped skill both say returned URLs are the wiki's own paths, embedded VERBATIM, never rewritten to a bucket hostname, because the wiki path is the only place the access check runs. Help text follows Colby's decided capability-URL model with the exact phrasing you suggested: attachment URLs are unlisted, not private.

Client-side pre-upload validation is in (10 MB, png/jpg/jpeg/webp/gif, no SVG deliberately), failing instantly and naming BAD_ATTACHMENT_TYPE as what the server would have said; the server's data.allowed remains authoritative when a request does reach it. Verified live before release: a real upload returned stored:s3 with the wiki path, and an .svg failed locally in zero wire time.