Components: locate, audit, and migrate `@stacksjs/components` to all-stx

[glennmichael123]

Context

Glenn is integrating @stacksjs/components into training. Per Chris's 2026-05-06 11:09 PM Discord exchange:

Glenn: "i am now trying to integreate @stacksjs/components to it"
Chris: "ive wondered, those likely should be stx components, right?"
Glenn: "they should be"

So the agreed direction is: every component in @stacksjs/components should be an .stx file, usable from any stx app (paweldregan, training, trailbuddy, pet-store, etc.).

Problem we hit while triaging

@stacksjs/components doesn't have a clear, single, canonical location. The stacksjs/stacks monorepo has storage/framework/libs/components/{stx,web} but those packages are scaffolds named @stacksjs/hello-world-vue and @stacksjs/hello-world-elements, not @stacksjs/components. There's no stacksjs/components repo on GitHub either.

Step 0 is figuring out where the canonical components surface lives.

Acceptance

1. Locate the canonical home for @stacksjs/components. Either:
   • A workspace inside this monorepo (likely storage/framework/libs/components/* after renaming the scaffolds), or
   • A separate repo (then file the migration there and close this with a pointer).
2. Audit every component currently shipped (or intended to ship) under @stacksjs/components. For each, record: what framework it's authored in (Vue / web component / stx / something else), and what surfaces consume it.
3. Migrate any non-stx component to stx. Per the standing rule (replace, don't just remove): no removal-only commits.
4. Validate by importing a few migrated components from paweldregan, training, and trailbuddy and confirming they render + behave correctly.
5. Document the canonical import path so all our stx apps can grab them consistently.

Why this matters

• Glenn is blocked / friction while integrating into training because the package boundary is unclear.
• Pet-store will need the same components soon — getting this clean before another consumer lands prevents migration churn later.
• "Stacks should be self-hosted on its own primitives" — having UI components authored in our own templating language is part of that story.

Out of scope (file separately if needed)

• Actually building new components.
• Theming surface for components.
• Component-library docs site.

Related

• paweldregan#10 — analytics rollout will probably also pull from this surface.
• pet-store#1 — pet-store will need these.