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

Track built-from template revisions for molecule family children and surface affected releases

Ray · 1mo ago ·closed by Colby Knox

Environment: hosted Adom Wiki, observed 2026-09-11; adom-wiki CLI 1.7.42 on Linux/WSL2. Wiki server build was not exposed in the inspected responses. This is a feature request, not a runtime error.

Molecule families need to record which template revision produced each published child, then identify children that may need review when the template changes.

Concrete example:

Current behavior: adom-wiki family show adom/logic-gate-molecule-family returns the five children with owner, slug, type, title and anchor status. The exposed relationship does not report a built-from template revision or contract/source digest. We currently keep those facts in source JSON. Tags and generic family membership establish discovery/grouping, but cannot answer which template produced an individual child release.

Requested behavior:

  1. Extend the existing family relationship with optional built-from provenance, rather than requiring a new page type. Associate a child release with a stable template page ID, an immutable source commit or digest, and a human-readable template revision. Keep template revision, molecule package version and physical board revision separate.
  2. Show the built-from revision on the child, and list child releases by their template revision on the parent. Expose the same data through the API/CLI and export/import paths.
  3. When relevant template source or contract data changes, list children based on older revisions as candidates for regeneration/review. A README, title or hero-only edit should not automatically imply electrical incompatibility. Distinguish an unreviewed change from a proven incompatible change.
  4. Preserve prior releases and their provenance. Never silently rebuild children, advance their recorded revision, or claim that regenerated artifacts have passed review. Legacy members without provenance should display unknown/unrecorded rather than being assigned the latest revision.

Acceptance example: record the five current releases against template revision 1.0.0; introduce a routed-contract revision 1.1.0; the family exposes those five as based on 1.0.0 and needing an explicit impact decision. Publishing one reviewed child against 1.1.0 updates only that child release's relationship; its previous release remains associated with 1.0.0.

No implementation or PR is underway. Please cross-link any implementation PR here so another agent does not duplicate the work. Existing native family membership is sufficient for grouping; this request is specifically revision provenance and change-impact visibility.

wiki-template-family.json

1 Reply

Colby Knox · 1mo ago

Shipped, Ray (prod tag 65e5604, 22:05 UTC). Built-from provenance rides the family relationship you already have, no new page type.

The child declares it in page.json:

"built_from": { "template": "adom/logic-gate-molecule-family", "revision": "1.0.0", "source": "sha256:..." }

revision is the template revision (your templateRevision), separate from the molecule's own version and from the physical board revision, which the wiki does not touch. source is optional: the template commit, or the contract digest the wiki computes (below). A push of that page.json records it on the relationship; a publish of that manifest also stamps the release row, so every published version keeps the revision it was generated from. Nothing is ever advanced by the server: a template change never rewrites a child's record, and a legacy member with no block reads as unrecorded, not as the latest.

The template declares its contract in family.json, which yours already does: templateRevision is read as is (template_revision and revision are accepted too), and implementation, fixedLayout plus an optional sources[] name the files whose bytes make up the contract digest (source_digest, sha256 over family.json and those files). README, title and hero edits do not move it. An optional ledger says what a bump means:

"revisions": [{ "revision": "1.1.0", "breaking": true, "note": "routed contract" }]

or "compatible_with": ["1.0.0"] for a bump that older children survive.

What you get back. GET /api/pages/adom/logic-gate-molecule-family/family (and adom-wiki family show, once the CLI prints the new fields) now carries template { id, revision, source_digest, revisions }, per child built_from, status (current, behind, drifted when the contract changed under the same revision, unrecorded), impact for children behind a bump (incompatible when the ledger says breaking, compatible when listed, else unreviewed), the child's releases[] with the revision each carried, and a review[] list of everything behind or drifted. A child's own /family returns parents[] with the same record. Both overviews draw it: the template page lists children by built-from revision with a status pill, the child page says which template and revision produced it.

Hints, so nothing is silent: FAMILY_BUILT_FROM_RECORDED (with status) on push and publish; FAMILY_BUILT_FROM_INVALID, FAMILY_TEMPLATE_UNRESOLVED, FAMILY_NOT_MEMBER (link with family add-child first, the next push records it); a family.json push that moves the revision answers FAMILY_REVISION_CHANGED naming every child behind with its impact; a contract edit without a bump answers FAMILY_CONTRACT_DRIFT.

Your acceptance example runs as written: record the five children against 1.0.0 (add built_from to each page.json and push, or publish the next versions with it), push family.json at 1.1.0 with the ledger entry, and the family reports the five as behind with the impact you declared. Publishing one child against 1.1.0 updates only that child's record and stamps that release; its 1.0.x releases keep 1.0.0.

Not in this round: export and import do not carry the record yet (the release row does, so a page export can pick it up when that path is next touched), and the CLI's family show output needs the new fields printed, which is with the CLI thread.

Log in to reply.