base-themes 0.1.2 → 0.1.3

package/docs/adoption-dashboard.md

@@ -0,0 +1,149 @@
+# Adoption Dashboard
+
+This dashboard tracks whether Base Themes has enough public evidence that users are willing to use it. It is intentionally separate from release readiness: passing builds, tests, package smoke checks, and SEO checks means the project is ready to ship, not that the market has adopted it.
+
+## Current Status
+
+Latest saved telemetry, campaign, and external-action evidence reports are generated under `research/` when maintainers run the live commands. Those generated execution records are intentionally not required for CI or release-readiness checks.
+
+Current public adoption score: **1/4**
+
+| Signal | Current | Status |
+| --- | --- | --- |
+| npm weekly downloads `>= 100` | `374` | Pass |
+| GitHub stars `>= 10` | `0` | Not yet |
+| External human issue or PR present | `0` | Not yet |
+| At least one fork | `0` | Not yet |
+
+Conclusion: the project has package download activity, but does not yet have enough public GitHub or community signal to claim the strategy has succeeded.
+
+`npm run launch:actions` can generate a live promotion wave, channel-specific post copy, share assets, and record fields for external post URLs plus T+1, T+7, and T+30 telemetry evidence when maintainers need an execution pack.
+
+## Completion Gate
+
+Treat the future-development strategy as externally validated only when at least three of the four public signals pass in a telemetry report:
+
+- npm weekly downloads are at least `100` and stable or growing.
+- GitHub stars are at least `10`.
+- At least one non-maintainer, non-bot issue or PR exists.
+- At least one fork exists.
+
+Supporting private signals can strengthen confidence but should not replace public evidence:
+
+- Cloudflare unique visitors and route views.
+- GitHub traffic views, clones, referrers, and popular paths.
+- Install command copies and GitHub outbound clicks.
+- Theme, block, registry, and CLI page depth.
+- Google Search Console impressions, indexed pages, queries, and CTR.
+- Community gallery submissions with permission to feature.
+- Show and tell Discussions, external repos, public project URLs, and permissioned community proof from [community-proof-telemetry.md](./community-proof-telemetry.md).
+
+## Measurement Commands
+
+Run public telemetry:
+
+```bash
+npm run telemetry:collect
+npm run telemetry:check
+npm run telemetry:check -- --live
+npm run telemetry:fixtures
+npm run launch:status
+npm run launch:status -- --live
+npm run launch:actions
+npm run launch:actions -- --live
+npm run launch:campaign
+```
+
+Run with GitHub traffic when a token has repository traffic permission:
+
+```bash
+GITHUB_TOKEN=... npm run telemetry:collect
+```
+
+Run with local website/search exports when provider dashboards have data:
+
+```bash
+ANALYTICS_EXPORT=path/to/analytics-events.jsonl SEARCH_CONSOLE_EXPORT=path/to/search-console-export.csv npm run telemetry:collect
+```
+
+Verify import parsing with bundled sanitized fixtures before relying on provider exports:
+
+```bash
+npm run telemetry:fixtures
+```
+
+Run with registry/agent access logs when CDN or server logs are available:
+
+```bash
+REGISTRY_ACCESS_EXPORT=path/to/registry-access.jsonl npm run telemetry:collect
+```
+
+Run with manually exported community proof when Discussions, gallery submissions, external repos, or project URLs exist:
+
+```bash
+COMMUNITY_PROOF_EXPORT=path/to/community-proof.csv npm run telemetry:collect
+```
+
+Run with bundle performance budgets after building the docs site:
+
+```bash
+npm run build
+npm run bundle:report -- --json > path/to/bundle-report.json
+BUNDLE_REPORT_EXPORT=path/to/bundle-report.json npm run telemetry:collect
+```
+
+Check release readiness separately:
+
+```bash
+npm run registry:check
+npm run lint
+npm run test
+npm run build
+npm run seo:check
+npm run bundle:report
+npm run analytics:check
+npm run community:check
+npm run telemetry:check
+npm run telemetry:check -- --live
+npm run telemetry:fixtures
+npm run launch:check
+npm run launch:status
+npm run launch:status -- --live
+npm run launch:actions
+npm run launch:actions -- --live
+npm run launch:campaign
+npm run package:smoke
+npm pack --dry-run
+```
+
+## Evidence Gaps
+
+| Gap | Needed Access | Why It Matters |
+| --- | --- | --- |
+| GitHub traffic | `GITHUB_TOKEN` with repository traffic access | Shows views, clones, referrers, and popular content after launch. |
+| Website analytics | Cloudflare or privacy-friendly analytics endpoint from [analytics-setup.md](./analytics-setup.md), optionally imported with `ANALYTICS_EXPORT` | Shows whether SEO/docs/block routes convert to install or GitHub clicks. |
+| Search analytics | Google Search Console and [search-console-setup.md](./search-console-setup.md) | Shows whether theme, component, and Base UI comparison pages are indexed and queried. |
+| Registry usage | CDN/server logs from [registry-access-telemetry.md](./registry-access-telemetry.md), or issue-based reports | Shows whether registry metadata and agent workflows are actually consumed. |
+| Community proof | GitHub gallery issues, Show and tell Discussions, external repos, or [community-proof-telemetry.md](./community-proof-telemetry.md) exports | Shows real usage outside maintainer demos. |
+
+## Operating Loop
+
+1. Ship only after release-readiness checks pass.
+2. Use [release-announcement-kit.md](./release-announcement-kit.md) to share the release and ask for one concrete action.
+3. Use [search-console-setup.md](./search-console-setup.md) to submit the sitemap, inspect high-intent routes, and monitor search queries after deploy.
+4. Use [registry-access-telemetry.md](./registry-access-telemetry.md) to import registry, `llms.txt`, `llms-full.txt`, CLI, and agent-route access logs when available.
+5. Use [community-proof-telemetry.md](./community-proof-telemetry.md) to import accepted Discussions, gallery submissions, external repos, and public project URLs when available.
+6. Run telemetry at T+0, T+1 day, T+7 days, and T+30 days.
+7. Run `npm run launch:status` after each telemetry pass to summarize the current public score, previous-report signal trend, missing signals, recommended good-first issue URLs, telemetry collection errors, and next action without manually diffing JSON; use `npm run launch:status -- --live` before an external announcement when you want current GitHub/npm data without writing a new report.
+8. Run `npm run launch:actions` while the gate is unmet to get a focused action list, previous-report signal trend, and share assets for the missing star, fork, external issue/PR, or download signals; use `npm run launch:actions -- --live` before promotion to derive that list from current public data, or `npm run launch:campaign` to write the live campaign JSON and Markdown pack to `research/`.
+9. Compare slope instead of only one snapshot.
+10. Prioritize the next product iteration from observed blockers:
+   - Low installs: improve README, npm metadata, examples, and install snippets.
+   - Low stars/forks: improve positioning, screenshots, and shareable routes.
+   - Low issues/PRs: add contribution prompts, good-first issues, and clearer component/theme request templates.
+   - Low docs conversion: improve route CTAs, package examples, and CLI doctor guidance.
+   - Repeated integration failures: fix package exports, CSS import docs, peer dependencies, or framework examples.
+
+## Decision Rule
+
+Do not mark the strategy complete while the adoption score is below `3/4`. Continue local adoption-funnel work until all realistic in-repo improvements are exhausted, then publish, promote, measure, and iterate from real user behavior.

package/docs/analytics-setup.md

@@ -0,0 +1,145 @@
+# Analytics Setup
+
+Base Themes uses optional, privacy-light product-funnel events to understand whether the docs site turns visitors into package installs, GitHub visits, theme exploration, block sharing, and registry usage.
+
+No analytics request is sent unless `VITE_ANALYTICS_ENDPOINT` is configured at docs build time.
+
+## Event Contract
+
+The frontend sends this JSON shape:
+
+```json
+{
+  "name": "install_command_copy",
+  "path": "/docs/installation",
+  "timestamp": "2026-05-29T00:00:00.000Z",
+  "properties": {
+    "source": "landing"
+  }
+}
+```
+
+Allowed event names:
+
+- `route_view`
+- `internal_navigation`
+- `install_command_copy`
+- `github_outbound_click`
+- `theme_style_cycle`
+- `theme_style_select`
+- `theme_snippet_copy`
+- `color_theme_toggle`
+- `block_share_copy`
+
+Allowed properties:
+
+- `block`
+- `campaign`
+- `component`
+- `content`
+- `detail`
+- `from`
+- `label`
+- `medium`
+- `path`
+- `source`
+- `target`
+- `themeStyle`
+- `to`
+
+Do not add personal identifiers, user IDs, emails, IP-derived identifiers, full user agents, or free-form text fields to analytics payloads.
+
+## Receiver
+
+The optional receiver lives at [workers/analytics-receiver.mjs](../workers/analytics-receiver.mjs). It:
+
+- accepts only `POST` JSON requests and CORS preflight `OPTIONS` requests;
+- accepts only configured origins through `ALLOWED_ORIGINS`;
+- rejects unknown event names;
+- keeps only whitelisted primitive properties;
+- logs one sanitized JSON event per accepted request;
+- optionally writes to a Cloudflare Queue binding named `ANALYTICS_QUEUE`;
+- optionally writes a basic Cloudflare Analytics Engine data point through `BASE_THEMES_ANALYTICS`.
+
+Validate the receiver locally:
+
+```bash
+npm run analytics:check
+```
+
+## Cloudflare Deployment Model
+
+The receiver can be deployed as a separate Worker from the docs site. Keeping it separate avoids changing the static assets deployment path and lets analytics be disabled without affecting docs availability.
+
+Worker config lives at [wrangler.analytics.jsonc](../wrangler.analytics.jsonc):
+
+```jsonc
+{
+  "$schema": "node_modules/wrangler/config-schema.json",
+  "name": "base-themes-analytics",
+  "main": "workers/analytics-receiver.mjs",
+  "compatibility_date": "2026-05-29",
+  "observability": {
+    "enabled": true
+  },
+  "vars": {
+    "ALLOWED_ORIGINS": "https://base-themes.bangwu.me,http://localhost:5175,http://localhost:5176"
+  }
+}
+```
+
+Update `ALLOWED_ORIGINS` before deploying preview environments or a custom docs domain. Use a comma-separated list of exact origins.
+
+Deploy the receiver:
+
+```bash
+npx wrangler deploy --config wrangler.analytics.jsonc
+```
+
+Build the docs site with the endpoint:
+
+```bash
+VITE_ANALYTICS_ENDPOINT=https://base-themes-analytics.<account>.workers.dev npm run build:docs
+```
+
+Then deploy the docs site normally:
+
+```bash
+npm run deploy
+```
+
+## Launch Metrics
+
+After a release announcement, compare these event counts with public telemetry:
+
+| Event | Funnel Question |
+| --- | --- |
+| `route_view` | Which docs, theme, block, and CLI routes did visitors actually open? |
+| `install_command_copy` | Did visitors reach install intent? |
+| `github_outbound_click` | Did visitors move from docs to GitHub stars, forks, Show and tell Discussions, feature issues, bug reports, or gallery submissions? Check `source` and `target` values such as `repo-star`, `repo-fork`, `show-and-tell`, `feature-request`, and `gallery-submission`. |
+| `theme_style_select` | Which visual systems attracted exploration? |
+| `theme_snippet_copy` | Which theme package or CSS snippets were useful enough to copy? Check `detail`, `label`, and `themeStyle` when present. |
+| `block_share_copy` | Which blocks were compelling enough to share? |
+| `internal_navigation` | Did visitors move from landing pages into docs, themes, blocks, or registry pages? |
+
+Use these results alongside `npm run telemetry:collect`. Website events are supporting evidence; public adoption still requires npm/GitHub/community signals.
+
+To include exported Worker logs or sanitized event rows in the telemetry report, write one JSON event per line or export a CSV/JSON file with `name`, `path`, `timestamp`, and optional `properties`, then run:
+
+```bash
+ANALYTICS_EXPORT=path/to/analytics-events.jsonl npm run telemetry:collect
+```
+
+The bundled fixture at `research/telemetry-fixtures/analytics-events.jsonl` is checked by:
+
+```bash
+npm run telemetry:fixtures
+```
+
+The telemetry importer summarizes total events, route views, install command copies, GitHub outbound clicks, block shares, theme snippet copies, theme selections, top routes, top GitHub click targets, and top launch attribution values. Keep exports sanitized: do not include IP addresses, user agents, cookies, emails, request headers, or free-form user text.
+
+Launch attribution uses the standard `utm_campaign`, `utm_source`, `utm_medium`, and `utm_content` query parameters. The docs app attaches those values to every funnel event as `campaign`, `source`, `medium`, and `content`; `npm run telemetry:collect` summarizes top campaigns, sources, mediums, GitHub-click sources, install-copy sources, and campaign/source conversion funnels when `ANALYTICS_EXPORT` is provided.
+
+## Privacy Notes
+
+The receiver intentionally does not set cookies, does not assign visitor IDs, and does not store request headers. Cloudflare platform logs may still include operational metadata depending on account settings, so keep published privacy language conservative and accurate.

package/docs/community-gallery-proposal.md

@@ -0,0 +1,64 @@
+# Community Gallery Proposal
+
+Base Themes should treat a community gallery as a discovery and trust surface, not as a paid marketplace until adoption data supports that move.
+
+## Goals
+
+- Show real applications, copied blocks, and theme customizations built with `base-themes`.
+- Give contributors a lightweight path to share themes, block variants, and integration examples.
+- Create public evidence that the package is useful outside the maintainer's own docs site.
+
+## Initial Submission Model
+
+Start with GitHub issues instead of a custom backend. Add a `gallery-submission` label and ask contributors for:
+
+- Project or screenshot title.
+- Public URL or repository link.
+- Base Themes version.
+- Theme style and custom CSS variables used.
+- Components or blocks used.
+- One 1280x720 screenshot.
+- Permission to feature the submission in the docs site and README.
+
+Use GitHub Discussions for lighter-weight show-and-tell before a submission is ready for gallery consideration. The versioned template at [.github/DISCUSSION_TEMPLATE/show-and-tell.yml](../.github/DISCUSSION_TEMPLATE/show-and-tell.yml) asks for the project name, URL or repository, selected theme style, components or blocks used, what worked, and what was missing. A discussion can become a gallery issue only when the user explicitly grants permission through the gallery submission template.
+
+## Acceptance Criteria
+
+- The screenshot must show an actual UI built with Base Themes components, blocks, or theme tokens.
+- The submission must include enough implementation detail for another user to reproduce the setup.
+- The UI must not imply official endorsement of a third-party product.
+- The project must be suitable for an open-source documentation site.
+
+## Gallery Data Shape
+
+When there are at least five accepted submissions, move accepted entries into `src/docs/communityGallery.json`:
+
+```json
+[
+  {
+    "title": "Ops Dashboard Theme",
+    "url": "https://example.com",
+    "repo": "https://github.com/example/base-themes-dashboard",
+    "screenshot": "/community/ops-dashboard.png",
+    "style": "enterprise",
+    "components": ["button", "select", "tabs"],
+    "blocks": ["dashboard-shell", "data-table"]
+  }
+]
+```
+
+## Rollout
+
+1. Add the `type: gallery` and `community` labels from [.github/labels.json](../.github/labels.json), then link this proposal from README contribution notes.
+2. Enable GitHub Discussions with a `Show and tell` category, then use the discussion template for early feedback and screenshots that are not yet permissioned gallery entries.
+3. Collect submissions manually through issues until there is enough volume to justify a docs route.
+4. Add `/community` only after accepted entries exist, so the page launches with real proof instead of placeholders.
+5. Track outbound project clicks, discussion clicks, and gallery submission clicks through the existing optional analytics hook.
+
+Run `npm run community:check` after editing the gallery issue template, show-and-tell discussion template, label manifest, or this proposal. The check verifies that gallery labels exist, that the submission template keeps explicit permission-to-feature language, and that the discussion template asks for adoption feedback instead of generic promotion.
+
+## Success Signals
+
+- At least five valid external submissions.
+- Gallery entries drive docs sessions to install, registry, or GitHub outbound clicks.
+- Submissions reveal repeated requests for a block, theme style, or integration guide.

package/docs/community-proof-telemetry.md

@@ -0,0 +1,47 @@
+# Community Proof Telemetry
+
+Community proof is supporting evidence for adoption. It does not replace the public completion gate in [adoption-dashboard.md](./adoption-dashboard.md), but it helps explain whether users are moving from docs into Show and tell Discussions, gallery submissions, forks, issues, PRs, and real project usage.
+
+## Export Format
+
+Create a CSV, JSON array, or JSONL file with one row per accepted signal. Supported fields:
+
+| Field | Description |
+| --- | --- |
+| `type` | `discussion`, `gallery`, `repo`, `url`, `issue`, or `pr`. Aliases such as `show-and-tell`, `gallery-submission`, `repository`, and `pull-request` are normalized. |
+| `title` | Project, discussion, issue, PR, or submission title. |
+| `url` | Public GitHub Discussion, issue, PR, repository, project, or screenshot URL. |
+| `author` | GitHub login or public author name when available. |
+| `style` | Base Themes `data-style`, such as `enterprise`, `bento`, or `terminal`. |
+| `permissionToFeature` | `true` / `false`; only permissioned submissions should become README or docs gallery entries. |
+| `timestamp` | Optional ISO date or export date. |
+
+Example CSV:
+
+```csv
+type,title,url,author,style,permissionToFeature,timestamp
+discussion,Enterprise dashboard feedback,https://github.com/markbang/base-themes/discussions/12,octo-user,enterprise,false,2026-06-01
+gallery,Internal tools screenshot,https://github.com/markbang/base-themes/issues/18,acme-dev,data-dense,true,2026-06-02
+repo,Base Themes starter,https://github.com/example/base-themes-starter,example,bento,false,2026-06-03
+```
+
+Run:
+
+```bash
+COMMUNITY_PROOF_EXPORT=path/to/community-proof.csv npm run telemetry:collect
+```
+
+Validate the importer with the bundled sanitized fixture:
+
+```bash
+npm run telemetry:fixtures
+```
+
+The checked fixture lives at `research/telemetry-fixtures/community-proof.csv` and covers a Discussion, gallery submission, external repo, and external project URL.
+
+## Interpretation
+
+- Discussions are early qualitative feedback; use them to prioritize docs, missing components, and source-copy friction.
+- Permissioned gallery submissions are stronger proof than generic screenshots because they can become public README/docs evidence.
+- External repos and project URLs help identify real integration patterns even when users do not open issues.
+- Community proof can support confidence, but the strategy is externally validated only when the public gate reaches at least `3/4`.

package/docs/contributor-issue-seeds.md

@@ -0,0 +1,240 @@
+# Contributor Issue Seeds
+
+Use these issue seeds to create a small public backlog for first-time contributors. They are intentionally scoped to adoption-funnel work: each issue should help a new user install, understand, customize, verify, or share Base Themes.
+
+Apply labels from the project vocabulary where possible:
+
+- `type: docs`, `type: feature`, `type: component`, `type: theme`, `type: block`, `type: registry`, `type: accessibility`
+- `area: docs`, `area: website`, `area: components`, `area: tokens`, `area: examples`, `area: ci`
+- `type: good first issue`, `type: help wanted`
+- `priority: low`, `priority: medium`
+
+The label vocabulary is versioned in [.github/labels.json](../.github/labels.json). Run `npm run community:check` after changing this file, issue templates, or the label manifest so seed issues stay publishable without label drift.
+
+Render prefilled issue URLs before a release announcement:
+
+```bash
+npm run community:issues
+npm run community:issues -- --json
+npm run community:issues -- --gh
+```
+
+`community:issues` does not publish anything by itself. It turns the seed issues below into prefilled GitHub URLs, JSON for release tooling, or `gh issue create` commands for maintainers with GitHub CLI access.
+
+## Seed 1: Add a Focused Button Accessibility Example
+
+Title:
+
+```text
+[Docs]: Add a Button accessibility example for loading and disabled states
+```
+
+Labels:
+
+```text
+type: docs, type: accessibility, area: components, type: good first issue
+```
+
+Body:
+
+```md
+## Problem
+
+New users can render `Button`, but the docs should show how to handle common accessible states such as `disabled`, pending actions, and icon-only labels.
+
+## Scope
+
+- Add one concise Button example to the component docs.
+- Include disabled and loading/pending usage.
+- Include an icon-only button with an accessible label if the existing Button API supports it.
+- Keep the example copy-pasteable.
+
+## Acceptance Criteria
+
+- The docs route still builds.
+- The example uses public `base-themes` exports only.
+- `npm run lint` and `npm run build` pass.
+```
+
+## Seed 2: Add a Theme Token Customization Recipe
+
+Title:
+
+```text
+[Docs]: Add a copy-paste theme token customization recipe
+```
+
+Labels:
+
+```text
+type: docs, type: theme, area: tokens, type: good first issue
+```
+
+Body:
+
+```md
+## Problem
+
+Users can switch `data-style`, but they need a short recipe for overriding a few CSS variables without forking the whole theme.
+
+## Scope
+
+- Add a docs example that customizes primary color, radius, and surface tokens.
+- Explain where the CSS should live in a Vite or Next app.
+- Link the recipe from the theming or theme customization docs route.
+
+## Acceptance Criteria
+
+- The recipe is copy-pasteable.
+- It preserves the `data-style` / `data-theme` contract.
+- `npm run lint`, `npm run build`, and `npm run seo:check` pass.
+```
+
+## Seed 3: Add a Vite Install Troubleshooting Note
+
+Title:
+
+```text
+[Docs]: Add Vite troubleshooting for CSS imports and peer dependencies
+```
+
+Labels:
+
+```text
+type: docs, area: examples, type: good first issue
+```
+
+Body:
+
+```md
+## Problem
+
+Fresh Vite users may miss the required `base-themes/styles.css` side-effect import or install mismatched React/Base UI peer dependencies.
+
+## Scope
+
+- Add a short troubleshooting section to the Vite example README or installation docs.
+- Cover missing styles, TypeScript CSS module declarations, and peer dependency versions.
+- Keep commands current with the package README.
+
+## Acceptance Criteria
+
+- `examples/vite` still builds.
+- The docs do not duplicate large README sections.
+- `npm run example:vite:build` passes.
+```
+
+## Seed 4: Add a Registry Plan Example for a Real Screen
+
+Title:
+
+```text
+[Registry]: Document a source-copy plan for a dashboard screen
+```
+
+Labels:
+
+```text
+type: registry, area: docs, type: good first issue
+```
+
+Body:
+
+```md
+## Problem
+
+The CLI can generate a registry plan, but users need a concrete example that maps a product screen to components, blocks, files, and dependencies.
+
+## Scope
+
+- Add one docs snippet that runs `npx base-themes plan button select tabs block:dashboard-shell theme:enterprise --json`.
+- Explain what the plan output means for copy-based workflows.
+- Link to the dashboard block route and CLI docs.
+
+## Acceptance Criteria
+
+- The command works against the current registry.
+- `npm run example:registry-copy -- plan button select tabs block:dashboard-shell theme:enterprise --json` passes.
+- `npm run registry:check` passes.
+```
+
+## Seed 5: Add a Small Block Variant
+
+Title:
+
+```text
+[Block]: Add a compact metrics strip block
+```
+
+Labels:
+
+```text
+type: block, area: components, type: help wanted, priority: medium
+```
+
+Body:
+
+```md
+## Problem
+
+Dashboards often need a compact metrics strip. A small block variant gives users another realistic starting point without adding a full template.
+
+## Scope
+
+- Build a responsive metrics strip from existing Base Themes components and CSS tokens.
+- Add the block source under `src/blocks`.
+- Add a registry entry with files and dependencies.
+- Add a docs preview or include it in the blocks route.
+
+## Acceptance Criteria
+
+- The block works in light and dark mode.
+- The block is keyboard-safe and does not depend on private docs-only APIs.
+- `npm run registry:check`, `npm run lint`, and `npm run build` pass.
+```
+
+## Seed 6: Improve Community Gallery Submission Guidance
+
+Title:
+
+```text
+[Docs]: Add a minimal community gallery submission example
+```
+
+Labels:
+
+```text
+type: docs, area: website, type: good first issue
+```
+
+Body:
+
+```md
+## Problem
+
+The gallery issue template exists, but users may not know what a useful submission looks like.
+
+## Scope
+
+- Add one example submission to `docs/community-gallery-proposal.md`.
+- Show title, screenshot expectations, version, `data-style`, components, blocks, and permission language.
+- Keep it generic and do not invent a real user/project.
+
+## Acceptance Criteria
+
+- The example helps users submit real projects without adding fake gallery entries.
+- The docs continue to state that the gallery should launch only after enough external usage exists.
+```
+
+## Publishing Notes
+
+Create two or three of these issues before a release announcement. Do not flood the tracker. The goal is to give interested users a clear next action after they star, fork, or try the package.
+
+After publishing seed issues, link the best ones from announcement replies, GitHub Discussions, or the release notes when someone asks how to help.
+
+Suggested release sequence:
+
+1. Run `npm run community:issues` and open two or three prefilled URLs.
+2. Add `type: good first issue` or `type: help wanted` labels exactly as rendered.
+3. Link the published issues from the GitHub release and launch posts.
+4. Keep the remaining seeds unpublished until there is real contributor interest or repeated user feedback.