Context

vibetuner-template/package.json resolves the framework's shipped templates with this
script:

"setup-tw-sources": "[ -L .core-templates ] || (rm -rf .core-templates && ln -s \"$(uv run --frozen python -c \"import vibetuner; print(vibetuner.__path__[0])\")/templates/frontend\" .core-templates)"

It works, but it's fragile:

• Depends on uv run --frozen resolving in the project's environment at the moment
  setup-tw-sources runs (CI ordering, Docker build stages, devcontainers can all break
  this).
• Shells out to Python to print a path, then symlinks into the project tree.
• The resulting symlink is unversioned scaffolding that has to be re-created on every
  fresh checkout / clean build.
• Failures are silent-ish: if the symlink points at a stale path (e.g. after a venv
  rebuild), Tailwind's @source ".core-templates" quietly stops scanning framework
  templates and utility classes start disappearing from bundle.css.

Proposal

Replace the symlink dance with a first-class API. Two viable options:

1. CLI command. vibetuner core-templates-path prints the absolute path; the
   template's setup-tw-sources becomes bun run glue around vibetuner instead of
   inline Python. Easier to test; surfaces the contract in --help.
2. Config-emitted include. vibetuner writes a .vibetuner-paths.json (or a
   generated config.framework.css) at install/sync time, and config.css does
   @import "vibetuner-core"; against a path looked up via a Tailwind plugin or a small
   pre-build step. Removes the symlink entirely.

Option 1 is minimal and unblocks Option 2 later.

Why now

Noticed while exploring #1704 (per-tenant theming). Unrelated to that feature, but the
fragility came up because theming relies on the framework-shipped partial being scanned
by Tailwind, and the symlink is the only thing making that work today.

Filed by Claude Code.