@mushi-mushi/svelte 0.9.0 → 1.0.0

package/CONTRIBUTING.md

@@ -63,7 +63,7 @@ packages/
   verify/        Fix verification (BSL)
 apps/
   admin/         Admin dashboard (React + Tailwind)
-  docs/          Documentation site (planned)
+  docs/          Documentation site (Nextra — apps/docs)
 tooling/
   eslint-config/ Shared ESLint flat config
   tsconfig/      Shared TypeScript configs
@@ -81,6 +81,28 @@ tooling/
    ```
 6. Open a pull request
 
+### Documentation (docs-as-code)
+
+If your PR changes **user-visible SDK or CLI behavior**, update docs in the **same PR**:
+
+| Surface | When to update |
+| --- | --- |
+| `packages/*/README.md` | npm-facing install/API/config changes for that package |
+| `apps/docs/content/**/*.mdx` | Long-form guides, quickstarts, admin console docs |
+| Root `README.md` | Marketing stats only when counts change — run `pnpm check:docs-stats` |
+
+Guardrails (run locally before pushing):
+
+```bash
+pnpm check:docs-stats          # root README stat badges
+pnpm check:sdk-version-matrix  # apps/docs/content/sdks/index.mdx versions
+pnpm check:internal-doc-links  # dead /foo links in MDX
+pnpm check:bundle-docs         # @mushi-mushi/web size-limit vs README
+pnpm gen:llms-txt              # regenerate apps/docs/public/llms.txt after nav changes
+```
+
+README changes on npm packages only appear on [npmjs.com](https://www.npmjs.com) after the next **Changesets publish**.
+
 ## Changesets
 
 We use [Changesets](https://github.com/changesets/changesets) for versioning. If your PR modifies a published package (`core`, `web`, `react`, `vue`, `svelte`, `angular`, `react-native`, `cli`, `mcp`), add a changeset:
@@ -101,17 +123,6 @@ Releases are fully automated. Maintainers don't run `npm publish` by hand.
 
 If GitHub's anti-loop protection suppresses the auto re-fire (the squash merge can be attributed to `github-actions[bot]`), trigger the workflow manually: **Actions → release → Run workflow → master**.
 
-### Known CI/CD quirks and their automatic safeguards
-
-A handful of GitHub-Actions × Changesets edge cases have caused release-pipeline stalls in the past. Each is now caught automatically — keep these in mind when you see the symptom:
-
-| Symptom | Root cause | Automatic safeguard |
-| --- | --- | --- |
-| The `Build & Test` required check never registers on the `chore: version packages` PR — the PR stays "Required check missing" forever | `changeset-release/master` is pushed by `github-actions[bot]`. GitHub silently drops the downstream `pull_request` event to prevent bot loops (observed on PR #45, #102, #124). | `ci.yml` now also triggers on `push` to `changeset-release/master`, so `Build & Test` reports against the head commit directly. No empty-commit nudge needed. |
-| Release workflow fails with `No commits between master and changeset-release/master` after merging a PR with a new changeset. | A `.changeset/*.md` file whose YAML frontmatter only targets packages listed in `.changeset/config.json#ignore` (e.g. `@mushi-mushi/server`, `@mushi-mushi/admin`). `changeset version` produces no bumps, the version PR is empty, the next push errors (PR #102 / #121, 2026-05-19). | `pnpm check:changeset-orphans` runs in both `ci.yml` and `release.yml`. PR CI fails with an actionable message naming the orphan file *before* it can reach master. If you legitimately need to record an internal-only change, omit the changeset entirely — the diff lives in git history. |
-| Release workflow's `Audit signatures of installed dependencies` step fails with `npm ETARGET / No matching version found for @mushi-mushi/<pkg>@<ver>` seconds after the publish step succeeded. | npm's registry CDN can take up to ~30s to propagate a freshly-published manifest. The audit step shells out to `npm install` against the just-published version and races the CDN (observed 2026-05-20, run 26149167393). | The audit step retries with exponential backoff (1, 2, 4, 8, 16, 32s — 63s total) before failing. Sigstore signatures are written at publish time, so a one-off audit failure never indicates a corrupted package — `pnpm view <pkg> version` is the ground truth. |
-| Push to `master` after merging a PR doesn't fire the `Release` workflow. | Same anti-loop protection: when a squash merge is attributed to `github-actions[bot]`, GitHub may suppress the downstream `push` trigger. Sporadic — observed twice in the last 60 days. | `release.yml` keeps `workflow_dispatch` as the manual fallback. Recovery: **Actions → Release → Run workflow → master**. The `Build & Verify` job re-runs identically to the auto-fired path. |
-
 ### Adding a brand-new publishable package
 
 Trusted Publisher bindings are configured **per package** on `npmjs.com` and require the package to already exist on the registry. New packages therefore need a one-time bootstrap before OIDC can take over.

package/README.md

@@ -6,26 +6,50 @@ Svelte SDK for Mushi Mushi bug reporting. **API-only** — captures errors and s
 >
 > **Other frameworks:** [`@mushi-mushi/react`](https://npmjs.com/package/@mushi-mushi/react) · [`@mushi-mushi/vue`](https://npmjs.com/package/@mushi-mushi/vue) · [`@mushi-mushi/angular`](https://npmjs.com/package/@mushi-mushi/angular) · [`@mushi-mushi/react-native`](https://npmjs.com/package/@mushi-mushi/react-native) · [`@mushi-mushi/capacitor`](https://npmjs.com/package/@mushi-mushi/capacitor) · [`@mushi-mushi/web`](https://npmjs.com/package/@mushi-mushi/web) (vanilla JS)
 
+## Install
+
+```bash
+npm install @mushi-mushi/svelte @mushi-mushi/web
+# or: npx mushi-mushi
+```
+
+## Environment variables
+
+| Stack | Project ID | API key |
+| --- | --- | --- |
+| Vite / SvelteKit | `VITE_MUSHI_PROJECT_ID` | `VITE_MUSHI_API_KEY` |
+
+See [Project ID & API keys](https://docs.mushimushi.dev/concepts/credentials).
+
 ## Usage
 
 ```ts
 import { initMushi, getMushi } from '@mushi-mushi/svelte'
 
-initMushi({ projectId: 'proj_xxx', apiKey: 'mushi_xxx' })
+initMushi({
+  projectId: import.meta.env.VITE_MUSHI_PROJECT_ID,
+  apiKey: import.meta.env.VITE_MUSHI_API_KEY,
+})
 
-// Later
 const mushi = getMushi()
 mushi.submitReport({ title: 'broken', description: '...' })
 ```
 
-### With Widget UI
+### With widget UI
 
 ```ts
 import { initMushi } from '@mushi-mushi/svelte'
 import { Mushi } from '@mushi-mushi/web'
 
-initMushi({ projectId: 'proj_xxx', apiKey: 'mushi_xxx' })
-Mushi.init({ projectId: 'proj_xxx', apiKey: 'mushi_xxx' })
+initMushi({
+  projectId: import.meta.env.VITE_MUSHI_PROJECT_ID,
+  apiKey: import.meta.env.VITE_MUSHI_API_KEY,
+})
+
+Mushi.init({
+  projectId: import.meta.env.VITE_MUSHI_PROJECT_ID,
+  apiKey: import.meta.env.VITE_MUSHI_API_KEY,
+})
 ```
 
 ### SvelteKit error handler
@@ -36,7 +60,15 @@ import { createMushiErrorHandler } from '@mushi-mushi/svelte'
 export const handleError = createMushiErrorHandler()
 ```
 
-## Peer Dependencies
+## API
+
+| Export | Purpose |
+| --- | --- |
+| `initMushi(config)` | Initialize once at app startup |
+| `getMushi()` | Access the SDK instance |
+| `createMushiErrorHandler()` | SvelteKit `handleError` integration |
+
+## Peer dependencies
 
 - `svelte` >= 4
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mushi-mushi/svelte",
-  "version": "0.9.0",
+  "version": "1.0.0",
   "license": "MIT",
   "description": "Svelte SDK for Mushi Mushi — context-based init, SvelteKit error hook integration",
   "main": "./dist/index.js",
@@ -10,8 +10,8 @@
     "svelte": ">=4"
   },
   "dependencies": {
-    "@mushi-mushi/core": "^1.5.0",
-    "@mushi-mushi/web": "^1.5.0"
+    "@mushi-mushi/core": "^1.15.0",
+    "@mushi-mushi/web": "^1.14.1"
   },
   "devDependencies": {
     "eslint": "^10.3.0",