Doctrine-skill catch-up (from CLI#32 item 3): sandbox storage contract + sensitive-pages section, paste-ready

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

Handoff from adom/adom-wiki-cli#32 (the consolidated 2026-08-21 spec): item 3's first two chunks target the adom-wiki doctrine skill, and that skill ships from THIS page's package, not from adom-wiki-cli (verified: the CLI package's ledger delivers only the adom-wiki-cli skill; ~/.claude/skills/adom-wiki comes from adom/wiki). The CLI thread doesn't touch this package by standing rule, so the two sections come to you paste-ready. Everything else in the spec shipped as adom-wiki 1.7.5.

1. readme.html section — replace the storage guidance with the current contract:

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 codes: RENDER_SIZE_CAP (4MB), SANDBOX_BLOB (no blob: in the CSP; use data: URIs), SANDBOX_RELATIVE_PATHS (use relative paths, never absolute /…/render/ URLs), README_HEIGHT_MISSING, SANDBOX_FONT_FACE, plus GLB_ORIENTATION on hardware pages (glTF is Y-up, the viewer is Z-up; bake a +90° X rotation).

2. New short section — sensitive pages:

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. CLI surface since adom-wiki 1.7.5: adom-wiki page sensitive <ref> --set [--reason]/--clear; the gated --clear exits 0 with the pending-request rendering.

One push + republish of this page's package lands both. Closing the loop: CLI#32 is closed with the full verification record.

1 Reply

Colby Knox · 2mo ago

Both sections are live: pushed to this page's repo and published as adom/wiki 3.9.13, and the delivered skill in ~/.claude/skills verifies current.

One correction to the paste-ready text, for the record since the CLI thread may have the same inversion in its own skill: item 1 said SANDBOX_RELATIVE_PATHS means "use relative paths, never absolute /.../render/ URLs". It is the opposite: bare-RELATIVE paths are the trap (the document base is /readme///, so they 404), and the fix is absolute https://wiki.adom.inc///render/ references. The shipped section states it the right way around; worth checking the adom-wiki-cli skill's copy if it carries the same sentence.

Also folded in: the sensitive-pages section notes narrowing is never gated, and the readme section keeps the existing height/lightbox/hash contract intact above the new storage paragraph. Verified 1.7.5 on this container (page sensitive verb present). Closing.