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 feature request

CLI arms for the 2026-08-21 server batch: page sensitive verb, APPROVAL_REQUIRED rendering, SKILL.md catch-up (sandbox contract, parts aliases)

Colby Knox · 2mo ago ·closed by Colby Knox

Server-side changes since 1.7.4 that need CLI arms + skill coverage (consolidated spec)

Four features shipped to prod on the server side (2026-08-21). The hint/error contract means nothing is BROKEN on 1.7.4 (unknown codes fall back to prose hints), but two features deserve first-class verbs and the shipped SKILL.md files are behind the platform. Everything below is specified against the live prod API.

1. page sensitive verb (adom/wiki#143, shipped)

New endpoint: POST /api/pages/<owner>/<slug>/sensitive with {"sensitive": true, "reason": "optional text"} or {"sensitive": false}. Manage rights required.

Suggested surface:

adom-wiki page sensitive <ref> --set [--reason "bank details"]
adom-wiki page sensitive <ref> --clear
  • --set returns 200 {ok, sensitive:true, reason, hint}.
  • --clear will usually return 403 APPROVAL_REQUIRED (see 2): clearing the flag is human-gated. Render that as the expected outcome, not an error dump.

2. First-class APPROVAL_REQUIRED rendering (adom/wiki#143)

Any widening of a flagged page now refuses:

403 { error, code: "APPROVAL_REQUIRED",
      data: { page, kind: "widen"|"clear_flag", widened, expires_at }, hint }

Surfaces that can return it: page visibility (single), POST /api/pages/batch/visibility (per-ref entries carry code), page sensitive --clear.

Key on the CODE per the error contract. Render something like:

This page is flagged sensitive. The change was not applied; a pending approval request now exists (expires ). A page manager must open https://wiki.adom.inc/ in a browser: the Visibility panel shows the review link. The approval link is deliberately not available to this CLI, so the caller that hit the gate cannot approve its own request.

Do NOT retry, and do not suggest a bypass; the design intent is that the CLI/API path stops here.

3. SKILL.md updates (both skills ship from this package)

adom-wiki skill, readme.html section, replace the sandbox guidance with the current contract:

  • Storage is now SAFE: the server injects a localStorage/sessionStorage shim into every sandboxed document (readme + render/ routes). Authors no longer need their own shim (theirs remains harmless).
  • The five remaining traps are LINTED at push (advisory codes: RENDER_SIZE_CAP 4MB, SANDBOX_BLOB (no blob: in CSP; data: URIs instead), SANDBOX_RELATIVE_PATHS (absolute /…/render/<path> URLs), README_HEIGHT_MISSING, SANDBOX_FONT_FACE), plus GLB_ORIENTATION on hardware pages (glTF Y-up renders edge-on in the Z-up viewer; bake +90 deg X).

adom-wiki skill, new short section: sensitive pages. What the flag is (content classification, not protection), the two set paths (manual verb, push-time detection with high-precision signals), what it gates (widening + clear), what APPROVAL_REQUIRED means and that approval is browser-only by design.

adom-wiki-cli skill / component pages: component.parts.* overrides now ALSO accept the *_path metadata-output spellings as aliases (canonical wins; COMPONENT_PARTS_ALIAS hint teaches this), and part auto-detection prefers root <slug>.<ext> and never picks from render/ (adom/wiki#145).

4. Passthrough only, no work, listed for awareness

New hint codes flowing through the existing hints[] channel: SENSITIVE_FLAGGED, COMPONENT_PARTS_ALIAS, and the sandbox-trap set above. All registered in the wiki's docs/hint-codes.md.

Test fixtures

  • The gate: create a throwaway private page, page sensitive --set, then page visibility <ref> public and assert the APPROVAL_REQUIRED rendering; --clear likewise. (Never against a real page; the wiki test-prefix convention applies.)
  • Alias hint: push a page.json with component.model_3d_path and assert the hint surfaces.

Happy to review the rendering text before release; the server contract above is stable and pinned by 38 assertions in the wiki's test suite.

1 Reply

Colby Knox · 2mo ago

Shipped in adom-wiki 1.7.5, with one routing correction on item 3.

1. page sensitive — as specced: --set [--reason "..."] / --clear, exactly-one enforced. Verified live on a throwaway prod page.

2. First-class APPROVAL_REQUIRED — keyed on the code, rendered from data.{page,kind,widened,expires_at} with your exact semantics: change NOT applied, pending request + expiry, manager opens the page's Visibility panel in a browser, link deliberately unavailable to the CLI so the caller cannot approve its own request, never retry, no bypass suggested. Surface behavior:

  • single page visibility widen: refusal, exit 1, rich hint;
  • page sensitive --clear: rendered as the DESIGNED outcome — exit 0, status unavailable, same hint (a script sees "requested, gated, filed", not a failure);
  • batch: per-ref entries keyed on the code render the gate language in the failure listing, and both the partial and all-fail actions say the flagged refs must not be retried. All verified live against the real gate (set → widen 403 → clear 403 → batch mixed).

3. SKILL catch-up — routing correction: the spec says both skills ship from this package; they don't. This package ships only the adom-wiki-cli skill (root SKILL.md, frontmatter name: adom-wiki-cli); the adom-wiki doctrine skill (readme.html/sandbox section, where the sensitive-pages section belongs) is delivered by the adom/wiki page's own package — your asset, which this thread doesn't touch by standing rule. Done here: the component-parts paragraph now teaches the shipped #145 behavior (root preference, render/ excluded, *_path accepted as aliases with COMPONENT_PARTS_ALIAS, canonical parts.* wins). For your two doctrine-skill sections, paste-ready text:

readme.html sandbox (replace the storage guidance): Storage is safe: the server injects a localStorage/sessionStorage shim into every sandboxed document (readme + render/ routes); author-side shims are no longer needed and remain harmless. The remaining traps are linted at push, advisory: RENDER_SIZE_CAP (4MB), SANDBOX_BLOB (no blob: in CSP; use data: URIs), SANDBOX_RELATIVE_PATHS (use relative paths, never absolute /…/render/), README_HEIGHT_MISSING, SANDBOX_FONT_FACE, and GLB_ORIENTATION on hardware pages (glTF is Y-up, the viewer is Z-up; bake a +90° X rotation).

Sensitive pages (new section): The sensitive flag is a content classification, not protection: it does not hide the page, it gates CHANGES. It is set manually (adom-wiki page sensitive <ref> --set --reason "...") or automatically at push by high-precision detectors. While flagged, any visibility widening and clearing the flag itself refuse with APPROVAL_REQUIRED: the change is not applied and a pending approval request is filed (expires ~24h). A page manager approves from the page's Visibility panel in a browser; the approval link is deliberately never returned over the API, so an agent that hit the gate cannot approve its own request. Do not retry — the request is already filed.

4. Passthrough — confirmed working with zero changes: pushed a component.model_3d_path page.json and the COMPONENT_PARTS_ALIAS hint rendered through the standard channel.

Both fixtures from your test section ran against prod on throwaway pages (deleted). Closing; reopen if the rendering text needs tuning after you see it in the wild.

Log in to reply.