Adom Bridge

Update: ONE private page for every product, adom/insiders, with a file per product. ab's insiders manifest is adom/insiders/files/adom-bridge/version.json (probe it with the user's session token as Bearer; 200 = follow, else the public page). Bridges: adom/insiders/files//... for binary manifests, plus the registry tag in adom/wiki#168. One access list for everything.

SDK ask (John 2026-09-02): ship the release-tier pattern as a design page in the Adom Bridge SDK so third parties inherit it: (1) the manifest probe (try the private page with the user's login, else public), (2) a publish script that defaults to the private tier, (3) promote/rollback with the human's attestation stored in the manifest, (4) the registry insiders tag. Three postures a bridge author picks from: public-only (no insiders manifest), two-tiered (own private page as the insiders list), private-only (a private page IS the audience; no public tier ever, e.g. Drew's puma-machine bridge). adom/insiders is Adom's instance of the pattern, not a shared clearing house. Reference text: https://wiki.adom.inc/adom/insiders README.

Scope correction (John 2026-09-02): this public issue must not carry Adom's internal release mechanics, and the body above does. Treat the body as withdrawn. The ONLY deliverable tracked here is public and generic: a design pattern page in the Adom Bridge SDK for a third party to run their OWN early-release tier for their bridge: (1) a private wiki page whose readers are the tier, (2) the updater probes that page's manifest with the user's login and falls back to the public manifest, (3) a publish script that writes the private tier by default, (4) promote/rollback with the human's attestation stored in the manifest, (5) one plain semver per build in both tiers, (6) the registry dist-tag for skill packages. No Adom page names, no Adom lists, no Adom scripts by path. Adom's own adoption is tracked privately.

Per the scope correction: the SDK design page is DONE and generic. The Bridge SDK publish skill (in the adom/adom-bridge skills pkg, "Release tiers" section) now documents the pattern for a third party to run their own early-release tier, with all six elements and nothing Adom-specific:

1. A private wiki page whose READERS are the tier (page access is the membership list; nothing else to maintain).
2. The updater probes that page's manifest with the user's own login as Bearer; 200 = follow it; every failure mode falls back to the public manifest silently, so a public user stays oblivious. The Bearer is scoped to the private page's URLs only.
3. A publish flow that writes the private tier by default and refuses the public manifest without an attestation.
4. Promote/rollback that require and store the human's exact words in the manifest (promotion_attestation / rollback_attestation, with by/at stamps); an AI passes the words through verbatim or does not promote.
5. One plain semver per build in both tiers: the tier is where the manifest lives, never what the version is called; promote moves a version, it never rewrites one.
6. The registry dist-tag for skills packages (adom/wiki#168) so pkg-tiering matches manifest-tiering once it lands; until then, pkg latest is effectively the public tier and publishes at promote time.

Three postures a bridge author picks from: public-only (default, nothing changes), two-tiered (the above), private-only (the private page IS the page; no public tier ever). My earlier implementation reply carried internal mechanics and is deleted per the correction; internal adoption is tracked privately.

Closing: the public deliverable (the generic early-release-tier pattern in the Bridge SDK publish skill, all six elements, nothing Adom-specific) shipped on 2026-09-02 and nothing else is tracked here.