Shopify bundle: canonical config shape for per-project allowed_tasks opt-in?

[havardljohansen]

Following the Shopify bundle merge in #7 (2026-05-08), wiring up actual per-project enablement on the four Frontkom Shopify repos. The PR commit messages note that the bundles: [shopify] CLAUDE.md gate was dropped per review feedback and that per-project enablement now happens through the dispatcher's allowed_tasks list, but I can't tell from the merged tree where exactly that config lives or what shape it takes.

What I need to know

Which file (in the target project repo? in this skill repo?) declares per-project allowed_tasks, and what's the canonical schema?

Some specific candidates I considered:

1. A .night-shift.yml at each project's root (the boilerplate's old NIGHT_SHIFT_SHOPIFY.md proposed this — now stale)
2. An entry in this skill's manifest.yml under each project's allowed-tasks map
3. A GitHub Actions secret or var (e.g., NIGHT_SHIFT_TASKS) per project
4. Something else / a combination

Concrete plan once we know

Per the boilerplate's NIGHT_SHIFT_SHOPIFY.md matrix, I'd wire up:

• frontkom/claude-shopify-boilerplate (canary): both Shopify tasks
• frontkom/shopify-theme-afwigen: both
• frontkom/shopify-theme-bomathestore: both
• frontkom/shopify-theme-sykehusklovnene: both (Dawn baseline established 2026-05-11; safe)
• frontkom/shopify-theme-hovedsmann: shopify-audit-migration-risk only initially (Athens partial-fork makes auto-cherry-pick risky per the project's HOVEDSMANN_DISCOVERIES doc; will re-evaluate after next manual Athens cherry-pick)

Happy to send a PR with the per-project configs once you point at the right file + shape.

cc: discussed with @perandre during PR #7 review. Posting as issue for durable reference and so future Shopify projects can follow the same pattern.

[perandre]

Tasks are picked in the setup process. Another way to simplify things, would be to state that setup always is done from the repo you are targeting, and then get recommended tasks based on that. Then Shopify tasks would be invisible to, say, a NextJS repo on setup.