adom/core should depend on (or bundle) adom/definitions — the canonical glossary reaches no workspace - Adom Core

Overview Files Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

adom/core should depend on (or bundle) adom/definitions — the canonical glossary reaches no workspace

John Lauer · 5d ago ·closed by Colby Knox

adom/definitions (Kyle's canonical glossary — real-view/fake-view rules, platform terms, and now the Display Surfaces section: webview/wv, pup, native browser, hdbw, the Simple Browser ban) is a proper skill package with an installer, but NOTHING depends on it: not adom/core, not any bootstrap. So the one page that defines our shared vocabulary is never installed in any workspace, and workspace AIs guess at terms (observed 2026-07-17: a fresh HD workspace AI could not resolve 'hdbw' and used the banned two-word 'Web View' — both defined on the page).

Proposal: add adom/definitions to adom/core's dependency tree (it is platform-generic, tiny, and exactly the 'every workspace needs this' shape). Alternative: bundle it in the bootstraps like the hd-* skills, but core is the broader net since web-Hydrogen workspaces need the vocabulary too.

Page was fully de-staled today (AV marked deprecated with the webview redirect, HD/AD defined, registry-native skill model, slug URLs, Display Surfaces added). It is ready to ship as-is. Note its package layer needs a hero to republish (same Kyle-era gap as app-creator/adom-desktop-demo).

1 Reply

Colby Knox · 5d ago

Done, both halves, verified end to end.

The hero gap is closed first (it was the republish blocker you flagged): adom/definitions now has a billboard hero, built with the adom-wiki-hero-image skill (bleed-bottom layout, pill-field theme, the glossary's own Display Surfaces entries as the product shot: webview/wv, pup, hdbw, real-view, fake-view, and the Simple Browser ban). Live on the page, anon-verified.
adom/core 4.13.2 is published with adom/definitions ^1.0.0 in the dependency tree. Verified the whole path, not just the publish: a fresh resolve of adom/core returns definitions 1.0.0 in the tree, and a real adom-wiki pkg install adom/core on this container delivered the skill to ~/.claude/skills/definitions with its installer. Every workspace picks it up on its next auto-update pass (the hook runs ~every 30 minutes, prompt or cron), so the observed failure mode (a fresh workspace AI unable to resolve 'hdbw' and writing the banned two-word form) ages out fleet-wide within the hour.

Your alternative (bundling in bootstraps) was not needed: core is the broader net, exactly as you argued, and now that bootstraps run install.sh like everything else (#197 -> adom-wiki-cli 1.0.42), there is no mechanical difference left between the two paths anyway.