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 general

Org settings pages: the wiki-side decisions left over from adom-wiki-cli#59

Colby Knox · 22d ago ·closed by Colby Knox

Carried over from adom/adom-wiki-cli#59 (John's org-default settings request), so it can close on the CLI side. The CLI half is done: adom-wiki settings show|get|set (1.7.55) reads and writes /org-settings, one file per integration at integrations/.json, schema adom.org-integration/1, members-only through the page's own visibility, and refuses anything shaped like a secret. fusion-bridge 1.10.35 uses it, and adom/org-settings is live.

What is left belongs to the wiki. John agreed with the position on each:

  1. A page type for settings or data. adom/org-settings had to be created as a skill, because no type fits a page that only holds data, and the package route refuses anything but app, skill, bootstrap and component. Position: a data or settings type, or an explicit exemption for the reserved org-settings slug, so it stops posing as a skill in listings and search.
  2. One org-default repo or two. Position: two. brand has a human confirm gate; integration ids are written by tools, for other reasons.
  3. Auto-create or create on first write. Position: on first write. An empty page that exists would make 'this org has not set one up' ambiguous, where a 404 means exactly that today.
  4. Which org is the caller's. Position: explicit, defaulting only when whoami lists exactly one org; several orgs is an error that lists them, never a guess.

Nothing is blocked on these today; they decide whether org-settings becomes a first-class slug like brand.

2 Replies

Colby Knox · 22d ago

Wiki side done (git-wiki b6b1333, on staging; prod with the next tag).

  1. Page type: went with the brand precedent, a reserved slug rather than a new type (a type would ripple through manifests, the package route, listings and the CLI). /org-settings and /brand stay skill-typed by storage but are no longer skills anywhere a reader looks: left out of /skills, /api/pages (unless ?owner= names the owner), search, /api/discover, trending and the homepage grid, and they carry their own badge (Org settings, Brand guide). org-settings in addition must be a skill page (ORG_SETTINGS_SLUG_RESERVED), never goes public (ORG_SETTINGS_MEMBERS_ONLY on create, rename and visibility public) and never publishes as a package (ORG_SETTINGS_NOT_A_PACKAGE).
  2. Two repos: agreed; nothing to build.
  3. Create on first write: the wiki creates nothing; a 404 keeps meaning not set up.
  4. Which org: the client's to say; the wiki never guesses.

Codes are in docs/hint-codes.md; the rule is in docs/git-wiki-api-reference.md under Reserved owner pages.

Colby Knox · 22d ago

On prod (git-wiki 9d51d1a). Deploy watched at one-second resolution: zero non-200 responses through the swap.

Log in to reply.