Closed bug report

Skill should cover linking component dependencies + clarify the Dependencies graph is registry-layer (repo push won't populate it)

noah · 12d ago ·closed by Colby Knox

Context

Followed this skills guidance to publish component pages and link one as a dependency of another (a board component depending on a part component), to populate the boards Dependencies graph on its wiki page. A few gaps in the skill`s coverage cost real time. Project specifics omitted (the board is a private project).

Gaps / asks

  1. Make explicit that the Dependencies GRAPH is fed ONLY by the PUBLISHED package version. The skill already teaches the two-layer model (git page repo via repo push vs package registry via pkg publish, "not synced"). But it doesnt connect that to the Dependencies tab/graph: declaring dependenciesin package.json andrepo push-ing it leaves the graph empty ("Depends on 0"). The graph reads from the published package versions dependencies, so you must pkg publish. This surprised me given repo push is the headline "host your source" verb. Ask: add a short "how dependencies show up" note — deps live in the published package; repo-pushing package.json does not populate the graph.

  2. Add a worked recipe for LINKING one component page as a dependency of another. Nothing in the skill shows the actual flow: (a) publish the target component page, (b) add "adom/<target-slug>": "^x" to the dependents package.json dependencies, (c) pkg publish the dependent so the edge appears in its graph and the targets Dependents list. Ask: add this as a small example.

  3. State the component publish hard-gates. pkg publish of a component is rejected server-side (not bypassable with --skip-lint) unless the tarball includes BOTH a hero screenshot image AND a 3D source file (.step / .stp / .glb). Worth calling out so users know a component page cannot be published without a 3D model (a schematic-only / no-layout board has to ship a placeholder 3D to publish at all).

  4. Warn that page type is immutable. A page created as the wrong type cannot be converted; it must be hard-deleted and recreated to become a component. Since the board browser (adom-project-manager) lists only type=component, getting the type right at creation matters. Ask: a one-line warning + "create it as component from the start".

Environment

  • adom-wiki CLI 1.0.22, authenticated (org member + admin)
  • Reproduced 2026-07-09

1 Reply

Colby Knox · 11d ago

Shipped in adom/wiki skill 3.8.0 (page copy live, tarball updated so installs get it). All four asks landed, each verified against the server source first:

  1. New section 'Dependencies on the page come from the PUBLISHED package (not repo push)': the graph/Used-by read ONLY the last published version's dependencies (setPageDeps runs on publish alone; repo push never touches package_deps). Confirmed in lib/deps.js.

  2. Worked recipe added: publish the target part, declare the owner-qualified dep in the dependent's package.json, publish the dependent; that third step is what draws the edge and populates the target's Dependents.

  3. Component hard-gates documented: server-side (not --skip-lint-bypassable) requirement of a hero screenshot AND a 3D source file (.step/.stp/.glb) in the tarball, including the placeholder-3D reality for schematic-only boards. Confirmed at lib/packages.js:488 plus the global hero gate.

  4. Type immutability warned, with 'create it as component from the start' and the board-browser type=component filter as the motivation. Confirmed: type is absent from the reindex UPDATE set, so nothing can change it after creation.

Thanks for the precise report; the time it cost you is exactly what the skill is supposed to prevent.

Log in to reply.