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 Issues8 Breadcrumbs Pull Requests Activity
Closed feature request

Component pages: blank-canvas layout opt-out (readme HTML as the whole page below the viewer)

Colby Knox · 2mo ago ·closed by Colby Knox

From Ray (relayed by Colby): his component pages ship a rich HTML readme, but the page renders every baked section first (symbol/footprint cards, datasheet embed, files grid), and his readme iframe lands below the pile. He wants a boolean to turn the baked middle off, so his page is essentially header, the 3D viewer, then his readme HTML as a blank canvas he fully controls, per component type.

Proposal: a manifest opt-out, along the lines of

"component": { "page_layout": "canvas" }

(or a boolean like hide_native_sections). When set, the overview renders: page header + tabs, the 3D viewer section, then the readme (HTML variant iframe first-class), and nothing else baked in between. The Files TAB stays (this hides the overview files grid, not the file browser); Issues/Releases/etc tabs unaffected.

Design questions to settle:

  1. Granularity: one boolean vs per-section flags (a sections allowlist would also cover someone who wants the datasheet embed but not the sym/fp cards). The files_display idea from the Files-shelf issue (#63) overlaps; one declared layout block could serve both.
  2. Does the 3D viewer stay mandatory in canvas mode, or is it opt-out too? Ray said "maybe below the 3D viewer", suggesting the viewer stays. Given the custom-viewer-slot system exists (#53), keeping the viewer slot (native or overridden) as the one guaranteed element seems right.
  3. Readme HTML sandbox stays exactly as-is (the CSP sandbox contract from the readme-html work); canvas mode changes ordering and suppression only, never privileges.

Companion ask filed separately: pointing a viewer slot at a shared alternate viewer.

3 Replies

Colby Knox · 2mo ago

Shipped and verified on prod, together with a stronger sibling that landed via PR #268.

Two layouts are now available, matching the granularity question in the proposal:

  1. component.page_layout: "canvas" (this issue's ask): the overview renders the page header + tabs, the 3D viewer slot (native or overridden, including the shared cross-page viewers from the companion issue), the metadata sidebar, and then the README (HTML iframe first-class) as a blank canvas. Every other baked section (Symbol & Footprint, Schematics, Datasheet, breadcrumbs) is suppressed. Ordering and suppression only: the README sandbox contract is untouched, and the Files tab plus every other tab stays.

  2. readme_only: true at the page.json top level (Ray's own PR #268): the page renders as JUST its README, no viewer, no sidebar, no typed body at all. The full escape hatch while a type's layout is being figured out.

Both are read from page.json per commit, so flipping them needs only a page.json push. Design question 1 (per-section allowlist) is deliberately deferred: the boolean covers the stated need, and an allowlist can supersede it compatibly if a real case shows up. Design question 2 resolved as proposed: the viewer slot stays in canvas mode and readme_only exists for the full opt-out.

Verified end to end on staging with a throwaway canvas component (README rendered, baked sections gone, sidebar kept, shared viewer in the slot) and covered by regression tests in the schematic-viewer and readme-only suites.

John Lauer · 1mo ago

Live layout observation on 9 September 2026: adom-wiki CLI 1.7.38, Hydrogen 1.0.311 (d071fcc18ad2832a226e0e81a691876e1ebb344a), authenticated production wiki. Wiki backend build was not available in this check.

The existing README-only option successfully fixes a project-kind hardware page whose nested research STEP was being chosen as an unrelated component hero. On adom/tmf8829-depth-lab, top-level readme_only: true removed the native hero while retaining the authenticated project README. No asset deletion or new repository was needed.

One nuance worth documenting or fixing: top-level sections: ["readme"] alone emitted SECTIONS_DECLARED saying only one block renders, and the committed page.json read back correctly, but the visible #sec-hero still contained a 450 px native 3D iframe. This persisted after a fresh cache-busted navigation. The page is type: component, kind: project. The stronger README-only flag removed it. Please make the sections hint/spec clear if hero is intentionally outside that allowlist, or align rendering with the documented allowlist behavior. Before/after metadata and live DOM evidence are attached; no claim about a backend cause.

revision70-project-webview

revision70-overview-live-check.json

revision70-readme-only-live.json

Colby Knox · 1mo ago

Documented rather than changed, and thank you for the exact DOM evidence. The behaviour you saw is by design: sections is the allowlist and order for the MAIN column (readme, viewers, breadcrumbs, custom blocks), while hero (the viewer slot) and info (the sidebar) always render, because this issue settled that the viewer slot is the one guaranteed element of a component page and readme_only is the full opt-out. The gap was the hint: it called sections an allowlist without naming the two blocks it does not govern, so 'sections: ["readme"]' read as a promise the page did not keep.

The SECTIONS_DECLARED hint now says: sections is an allowlist for the main column; hero (the viewer slot) and info (the sidebar) always render regardless; to drop the viewer too, set readme_only: true at the top level. On staging now, prod with the next tag. For adom/tmf8829-depth-lab, readme_only is the right flag for exactly the case you hit (a nested research STEP being picked as the hero of a project page); a project-kind page never inferring a hero from a nested STEP is a separate question I will keep in mind alongside the #180 board work, where the same class of guess was removed for symbols and footprints.

Log in to reply.