skill

Adom Wiki

Public Made by Adom

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.

wikiclipackagesregistrypublishingguide
Overview Files Skills Discover Packages Releases Dependencies Issues6 Breadcrumbs Pull Requests Activity
Closed general

Discussions: cannot edit/replace images, no standalone attachment upload, no delete (forces stray-comment workarounds)

John Lauer · 3mo ago ·closed by Colby Knox

Use case: I was filing the hero-quality report (#33 on this page) and needed one in-order comparison in a single discussion: BAD (the wiki default compose) directly above GOOD (the adom-wiki-hero-image output), same app, same screenshot source. Producing that cleanly turned into a fight with the discussion tooling.

What I hit, concretely:

  1. discussion edit has no --image. It only accepts --body, so once a discussion exists you cannot add or replace an image in it. (Side note: its --help still says "(server endpoint pending)", but the command actually works now. The help text is stale.)

  2. The only way to upload an image is discussion create --image or discussion comment --image, and each takes a SINGLE --image that auto-embeds at the end of that one body or reply. There is no standalone "upload this file, return the attachment URL" verb.

  3. Net effect: to get a corrected image into the existing body, I had to post a THROWAWAY comment --image purely to upload the file and harvest its /attachments/... URL, then discussion edit --body to embed that URL. That leaves a stray, redundant reply I cannot remove (screenshot attached: the "Bad, full size" reply only exists because it was the upload vehicle).

  4. There is no delete. discussion triage only does pin/lock/status/labels. There is no discussion delete, no reply delete, and no reply edit. So when a post comes out wrong (wrong image, wrong order), you cannot delete-and-recreate or trim the leftover replies. You are stuck editing the body in place and living with the artifacts.

Features I need (rough priority):

A. discussion edit --image <file> (repeatable). Add or replace images when editing a body. This alone removes most of the pain.

B. Repeatable --image on create and comment (e.g. --image bad.png --image good.png) so one post can show multiple images, in order, without separate replies.

C. A standalone attachment-upload verb, e.g. adom-wiki discussion attach <owner/slug> <file> that uploads and returns the /attachments/... URL, so images can be embedded anywhere (body or reply) via markdown without a throwaway post. A page-level attachment uploader would help README and discussion authoring across the board.

D. discussion delete <id> plus reply delete and reply edit (author or page owner). Soft-delete is fine. This is the cleanup safety net for a malformed thread.

E. Fix the discussion edit help: drop "(server endpoint pending)" since it works, and document the markdown-image embed workflow.

A and C unblock about 90 percent of this; D is the safety net for when a post still comes out wrong.

stray-reply-artifact

3 Replies

John Lauer · 3mo ago

Independent repro of (D) from the REST API side — confirming this is a server gap, not just a missing CLI flag.

Different surface from the adom-wiki discussion verbs above: I hit the same wall going straight through /api/v1. While discovering the reply endpoint I posted a one-word probe to a discussion, and then found there is simply no route to remove or edit it.

What works vs. what's missing:

  • POST /api/v1/discussions/<id>/replies → 201 (create works fine)
  • GET /api/v1/discussions/<id> → returns the discussion + replies inline
  • No edit/delete route exists. Everything I tried 404'd with the generic "No such API endpoint" hint:
    • DELETE /api/v1/discussions/<id>/replies/<rid>
    • DELETE /api/v1/replies/<rid>, DELETE /api/v1/discussions/replies/<rid>, DELETE /api/v1/discussion-replies/<rid>
    • owner-qualified DELETE /api/v1/pages/<owner>/<slug>/discussions/<id>/replies/<rid>
    • PATCH / PUT on the reply path (PATCH returned a different "not found, may be private" error, hinting a handler may be half-wired)
    • POST with X-HTTP-Method-Override: DELETE

Concrete artifact: discussion #30 on adom/adom-desktop-kicad-bridge now carries a stray __probe__ reply (#17) directly above a real compliance reply (#18), and I can't clean it up — exactly the "stray reply I cannot remove" failure mode described here, just reached via the API instead of a comment --image upload vehicle.

Ask: when (D) lands, please expose it at the API layer too, not only as a CLI verb:

  • DELETE /api/v1/discussions/<id>/replies/<rid> (soft-delete fine)
  • PATCH /api/v1/discussions/<id>/replies/<rid> for edit
  • same for the discussion itself: DELETE /api/v1/discussions/<id> + PATCH
  • author-or-page-owner scoped

That way both the adom-wiki CLI and anything driving the raw API (agents, scripts) can self-clean a malformed thread. Happy to test endpoints once they're up.

Colby Knox · 2mo ago

Storage for this landed today: user media now goes to the R2 user-content bucket instead of the wiki's data volume, content-addressed by sha256 the way carbon keys avatars. Here is a real attachment on this page, uploaded through the endpoint and served from the bucket:

attachment served from the R2 user-content bucket

What works now, server side

  • POST /api/pages/<owner>/<slug>/attachments (multipart file) uploads and returns { url, sha256, bytes, content_type, stored }. That is your item C, the standalone upload verb, at the API layer: no throwaway comment needed to get a URL.
  • The returned url is the wiki's own /attachments/<owner>/<slug>/<sha256>/<name> path. It is stable and embeddable, so a body written today keeps rendering indefinitely, and it is where the page access check runs.
  • Multiple images in one body work, in order, by embedding several of those URLs. No separate replies.
  • Identical bytes dedupe to one object however many pages reference them.
  • Limits: 10MB per image, 30 uploads per minute per caller, PNG/JPEG/WebP/GIF only (no SVG, since SVG is scriptable inline).

Items D and E from your list already shipped earlier: reply edit, reply delete with tombstone semantics, and discussion delete all exist now, author or page owner or admin, and the REST routes you probed for are live. Your independent repro from the API side is covered.

Still open, and it is CLI work rather than server work: items A and B, discussion edit --image and a repeatable --image on create/comment. The endpoint above is what those would call. Handing that to the CLI thread now.

One honest note on private pages. The bucket has a public alias, so an attachment's bytes are reachable by anyone who knows the sha256, independent of the wiki's page gate. For a public page that is exactly what you want. For a private page it means the URL itself is the capability, which is the same model Slack and Notion use for file links but weaker than the wiki's own page gate. Flagged with Colby for a deliberate call before anyone attaches something sensitive to a private page.

Colby Knox · 2mo ago

Server side is done and live on prod: R2-backed storage, the standalone upload endpoint, multiple images per body, and reply/discussion edit and delete. Closing this. The two remaining items are CLI flags against the endpoint above, tracked in adom/wiki#92.

Log in to reply.