@italone/solace 0.0.1

package/docs/devtools.md

@@ -0,0 +1,145 @@
+# DevTools
+
+Solace exposes a narrow public DevTools integration surface through `solace/devtools`. This document records the public
+lifecycle, private runtime boundary, and safe constraints for future instrumentation.
+
+## Goals
+
+- Help developers inspect component, reactivity, scheduler, renderer, and store behavior.
+- Keep instrumentation opt-in.
+- Avoid stabilizing internal runtime objects as public API.
+- Avoid adding measurable overhead to production builds or benchmarks.
+
+## Non-Goals
+
+- No browser extension, custom panel, network transport, storage persistence, or automatic telemetry in the current phase.
+
+## Public API
+
+DevTools integrations should import from the `solace/devtools` subpath:
+
+```ts
+import { createDevtoolsRecorder, onDevtoolsEvent } from "solace/devtools";
+import type { DevtoolsEvent } from "solace/devtools";
+```
+
+The public subpath exports listener and recorder APIs only. It does not export emit helpers, listener-state helpers,
+global cleanup helpers, serializers, DOM nodes, VNode trees, component instances, props, reactive targets, store state,
+action arguments, or action results.
+
+## Public API Lifecycle
+
+`solace/devtools` is the only supported public DevTools entry point. New runtime exports require package boundary tests,
+packed consumer smoke coverage, documentation, and a project log entry before they are treated as supported API.
+
+Event payload additions must remain small serializable summaries and must update payload stability coverage. They should
+not include raw props, state, DOM nodes, VNodes, reactive targets, action arguments, action results, stack traces, or
+user content.
+
+Renames or removals require an intentional breaking-change plan. Internal helpers remain private even when public APIs
+reuse them internally, and incidental runtime cleanup must not change the public subpath shape.
+
+## Candidate Capabilities
+
+| Area       | Useful Signals                                         | Notes                                                                        |
+| ---------- | ------------------------------------------------------ | ---------------------------------------------------------------------------- |
+| Components | mount, update, unmount, props, emits, lifecycle hooks  | Component lifecycle and emit summaries are emitted by the internal event bus |
+| Reactivity | effect creation, dependency tracking, triggers, stops  | Trigger summaries are emitted without raw targets, keys, or values           |
+| Scheduler  | queued jobs, flush duration, skipped stale jobs        | `scheduler:flush` summary is emitted by the internal event bus               |
+| Renderer   | element mount, prop patch, child diff, unmount         | Element summaries are emitted without DOM nodes or VNode trees               |
+| Store      | action calls, narrow state paths, getter recomputation | Action summaries are emitted without args, results, or state                 |
+
+## Hook Boundary
+
+Solace has an internal event bus in `src/devtools/events.ts`. Runtime modules emit through that internal bus, while
+public integrations subscribe through `solace/devtools`. The package root intentionally does not export DevTools APIs.
+
+```ts
+type DevtoolsEvent =
+  | { type: "component:mount"; id: number; name: string }
+  | { type: "component:update"; id: number; name: string }
+  | { type: "component:unmount"; id: number; name: string }
+  | { type: "component:emit"; id: number; name: string; event: string; handlerCount: number }
+  | { type: "scheduler:flush"; queuedJobs: number; dedupedJobs: number; durationMs: number }
+  | {
+      type: "reactivity:trigger";
+      targetType: string;
+      keyType: string;
+      effectCount: number;
+      scheduledEffects: number;
+      runEffects: number;
+    }
+  | {
+      type: "renderer:element";
+      operation: "mount" | "update" | "unmount";
+      tag: string;
+    }
+  | {
+      type: "store:action";
+      name: string;
+      status: "success" | "error";
+      durationMs: number;
+    };
+```
+
+`component:emit` summaries include the component id, component name, emitted event name, and callable handler count only.
+They do not include emitted arguments, raw props, handler functions, component instances, VNodes, DOM nodes, or user
+content.
+
+`scheduler:flush` summaries include executed job count, deduped queue attempt count, and flush duration only. They do
+not include scheduler job functions, function names, stack traces, component instances, reactive effects, VNodes, DOM
+nodes, or user data.
+
+Future runtime modules should emit small serializable events only when a listener is registered. If no listener is registered, the runtime should do no meaningful extra work.
+
+`serializeDevtoolsEvent(event)` is available only from the internal event bus module. It returns an explicit plain-object
+copy for the current event union and is used by integration tests to lock the payload boundary. It is not exported from
+the package root.
+
+`createDevtoolsRecorder()` is public through `solace/devtools`. It installs a listener, stores serialized events in
+memory, exposes `snapshot()` for a copy of collected events, exposes `clear()` to reset the current capture window, and
+exposes `stop()` to remove the listener. Pass `{ limit }` to keep only the latest N events in memory. It does not
+persist data, send data over the network, write to storage, or install third-party scripts.
+
+Production package builds do not publish JavaScript sourcemaps. This keeps internal DevTools wiring visible in source
+control but out of package artifacts, so consumers do not accidentally couple to private helper names or module layout.
+
+## Privacy And Safety
+
+- Do not emit full props, state, DOM nodes, or reactive targets by default.
+- Redact or summarize values before exposing them to tooling.
+- Keep hooks disabled unless a dev-only listener is installed.
+- Do not send data over the network.
+
+## Performance Constraints
+
+- Production builds should not pay for DevTools instrumentation.
+- Benchmark commands should run with DevTools disabled.
+- Hook payload construction should be lazy or guarded by a listener check.
+- Component tree and dependency graph snapshots should be explicit actions, not automatic on every update.
+
+## Phased Roadmap
+
+1. **Event model design**: completed for initial component and scheduler summary events.
+2. **Development-only event bus**: internal event bus exists in `src/devtools/events.ts`.
+3. **Scheduler flush and dedupe summary**: `scheduler:flush` reports executed jobs, deduped queue attempts, and duration.
+4. **Component lifecycle summaries**: component mount/update/unmount summaries emit id and name only.
+5. **Component emit summaries**: `component:emit` is emitted with event name and callable handler count only.
+6. **Store action summaries**: `store:action` is emitted after action success or error without raw values.
+7. **Reactivity trigger summaries**: `reactivity:trigger` is emitted without raw targets, keys, or values.
+8. **Renderer element summaries**: `renderer:element` is emitted for element mount/update/unmount without DOM nodes or VNode trees.
+9. **Payload stability smoke**: integrated runtime events serialize to JSON-safe payloads with allowed fields only.
+10. **Internal recorder boundary**: `createDevtoolsRecorder()` captures serialized event snapshots for examples and experiments.
+11. **Example-oriented recorder smoke**: a todo-style interaction validates recorder capture after clearing initial mount noise.
+12. **Bounded recorder captures**: `createDevtoolsRecorder({ limit })` keeps recorder memory bounded for examples and experiments.
+13. **Large-list recorder smoke**: a 10,000-row keyed update validates public recorder snapshots remain serialized summaries without DOM, VNode, raw state, or row data.
+14. **Public package boundary guard**: package exports tests verify DevTools internals are not available from the package root.
+15. **Public DevTools subpath**: `solace/devtools` exposes listener and recorder APIs without internal emit helpers.
+16. **Production artifact boundary**: package builds do not publish JavaScript sourcemaps that expose internal wiring.
+17. **Inspector UI or browser extension**: build only after event payloads prove stable in examples.
+
+## Recommendation
+
+Do not implement a DevTools UI yet. The public `solace/devtools` subpath is a low-level integration surface for examples,
+tests, and future inspector tooling. Build a browser extension or custom panel only after more payloads prove stable in
+real examples.

package/docs/examples.md

@@ -0,0 +1,78 @@
+# Examples
+
+Solace includes three Vite examples that exercise the runtime from small state updates to larger keyed lists.
+
+## Basic Counter
+
+Run:
+
+```bash
+pnpm dev
+```
+
+Location: `examples/basic-counter`
+
+Coverage:
+
+- JSX automatic runtime.
+- `reactive` state.
+- DOM event patching through `onClick`.
+- Reactive re-render after a button click.
+
+The Playwright test `tests/e2e/basic-counter.spec.ts` verifies that the counter starts at `count: 0` and increments to `count: 1`.
+
+## Todo App
+
+Run:
+
+```bash
+pnpm dev:todo
+```
+
+Location: `examples/todo-app`
+
+Coverage:
+
+- Form submit handling.
+- Controlled input updates with `onInput`.
+- Keyed list rendering.
+- Checkbox state toggles.
+- Item deletion.
+
+The Playwright test `tests/e2e/todo-app.spec.ts` verifies add, toggle, and delete flows.
+
+## Large List
+
+Run:
+
+```bash
+pnpm dev:large
+```
+
+Location: `examples/large-list`
+
+Coverage:
+
+- 10,000 keyed rows.
+- Class and text patching.
+- A targeted state update from row 1 to row 5000.
+
+The Playwright test `tests/e2e/large-list.spec.ts` verifies the list renders 10,000 rows and updates the selected row marker.
+
+## E2E Validation
+
+Run all browser examples through Playwright:
+
+```bash
+pnpm test:e2e
+```
+
+The Playwright config starts each example on a fixed localhost port:
+
+| Example       | Port   |
+| ------------- | ------ |
+| Basic counter | `5174` |
+| Todo app      | `5175` |
+| Large list    | `5176` |
+
+`pnpm release:check` also runs these e2e tests after quality checks, coverage, package smoke, jsdom benchmark smoke, and the Chromium production browser benchmark.

package/docs/package-usage.md

@@ -0,0 +1,96 @@
+# Package Usage
+
+## Install
+
+The package is publishable, so registry install is valid after release:
+
+```bash
+pnpm add @italone/solace
+```
+
+Before that release decision, run `pnpm release:readiness` to check local release metadata and validate package consumption with the packed-consumer smoke test described below.
+
+## Import Runtime APIs
+
+```ts
+import { createApp, h, reactive } from "@italone/solace";
+
+const state = reactive({ count: 0 });
+
+const App = () =>
+  h(
+    "button",
+    {
+      onClick: () => {
+        state.count += 1;
+      },
+    },
+    `count: ${state.count}`,
+  );
+
+createApp(App).mount(document.querySelector("#app") as Element);
+```
+
+## Use JSX
+
+Configure TypeScript with the Solace JSX runtime:
+
+```json
+{
+  "compilerOptions": {
+    "jsx": "react-jsx",
+    "jsxImportSource": "@italone/solace"
+  }
+}
+```
+
+Then write components with JSX:
+
+```tsx
+import { createApp, reactive } from "@italone/solace";
+
+const state = reactive({ count: 0 });
+
+const App = () => (
+  <button
+    onClick={() => {
+      state.count += 1;
+    }}
+  >
+    count: {state.count}
+  </button>
+);
+
+createApp(App).mount(document.querySelector("#app") as Element);
+```
+
+## Public Entry Points
+
+- `@italone/solace`: core runtime APIs.
+- `@italone/solace/jsx-runtime`: TypeScript automatic JSX runtime.
+- `@italone/solace/jsx-dev-runtime`: development JSX runtime used by Vite.
+- `@italone/solace/devtools`: low-level DevTools listener and recorder APIs.
+
+Do not import from `src/**`, `dist/**`, or internal runtime modules directly. Those paths are implementation details and are not part of the package compatibility contract.
+
+## Verify A Packed Consumer
+
+Before release, run the package consumer smoke test:
+
+```bash
+pnpm package:smoke
+```
+
+The smoke test builds Solace, packs the current package, installs the tarball into a temporary consumer project, typechecks a JSX entry file, and verifies ESM and CJS imports for all public entry points.
+
+For the full local release gate, run:
+
+```bash
+pnpm release:check
+```
+
+That command runs quality checks including format check, coverage thresholds, package consumer smoke, jsdom benchmark smoke, Chromium production browser benchmark, and browser e2e tests.
+
+See `docs/release.md` for versioning and publish steps.
+
+See `docs/examples.md` for runnable Vite examples and their e2e coverage.

package/docs/performance.md

@@ -0,0 +1,230 @@
+# Performance
+
+This document defines how Solace performance should be measured. It does not claim unverified results.
+
+## Current Validation
+
+The repository currently validates behavior with:
+
+- Unit tests for reactivity, scheduler, renderer, components, events, JSX runtime, store, and package exports.
+- Playwright e2e tests for basic counter, todo app, and a 10,000-row large list example.
+- Rollup production build checks.
+- Tinybench smoke benchmarks for initial render, list diff, keyed insert/remove/move/reorder,
+  Fragment rendering, batched component updates, and mount/unmount loops.
+- Chromium browser production benchmark for large-list initial render, reactive update, and unmount
+  through `pnpm benchmark:browser`.
+
+The large-list e2e test confirms that 10,000 rows can render and one selected row can update in a browser smoke test. It is not a benchmark result.
+
+## Latest Local Benchmark Run
+
+Date: 2026-07-20
+
+Environment:
+
+| Item         | Value                   |
+| ------------ | ----------------------- |
+| OS           | Darwin 25.4.0 arm64 arm |
+| Node         | v22.22.2                |
+| Runtime      | darwin arm64            |
+| Vitest       | 4.1.10                  |
+| CPU / memory | Recorded by metadata    |
+
+Command:
+
+```bash
+SOLACE_BENCHMARK_HISTORY_PATH=.benchmark-history/jsdom.jsonl SOLACE_BENCHMARK_SAMPLE_SIZE=3 pnpm benchmark
+```
+
+The command logs a `benchmark metadata` JSON line before running the jsdom benchmark suite. The metadata includes package name/version, Node version, OS platform/release/architecture, CPU model, logical CPU count, total memory, benchmark runner, benchmark environment, sample size, and an ISO timestamp.
+
+`sampleSize` defaults to `1` so `pnpm benchmark` remains a smoke benchmark run. Set
+`SOLACE_BENCHMARK_SAMPLE_SIZE=3 pnpm benchmark` to run three independent Vitest benchmark samples.
+The command reports the configured sample size in metadata, but it does not yet aggregate medians.
+
+Set `SOLACE_BENCHMARK_HISTORY_PATH=.benchmark-history/jsdom.jsonl pnpm benchmark` to append one
+JSONL record after a successful jsdom benchmark run. History recording is opt-in and records
+metadata plus run status. Records created by the current benchmark runner also include
+task-level Tinybench metrics under `summary.tasks`.
+
+The local ignored jsdom history currently contains records with task-level Tinybench metrics when created by the current
+benchmark runner. `pnpm benchmark:history -- --json` summarizes those jsdom task metrics with count, median, p95, and
+variance while still accepting older metadata-only records.
+
+Result summary:
+
+| Scenario                                         | File                                          | Status | Notes                                                                                                                                      |
+| ------------------------------------------------ | --------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| 1,000 component initial render                   | `tests/performance/render.bench.ts`           | Passed | Uses jsdom and Tinybench, intended for trend tracking                                                                                      |
+| 10,000 row create/update/delete/reorder          | `tests/performance/list-diff.bench.ts`        | Passed | Covers list creation, text-to-list mount, initial element child mount, unkeyed append/remove, local text update, delete, and keyed reorder |
+| 10,000 row keyed local insert/remove/move        | `tests/performance/list-diff.bench.ts`        | Passed | Covers focused middle insert, middle remove, tail-to-head move, mixed insert/move, adjacent insert/move, and adjacent remove/move          |
+| 5,000 Fragment child initial render/patch/insert | `tests/performance/fragment.bench.ts`         | Passed | Covers Fragment child mount, keyed text patch, and keyed middle insert                                                                     |
+| 1,000 component batched reactive update          | `tests/performance/component-update.bench.ts` | Passed | Covers scheduler batching across many component consumers                                                                                  |
+| Component mount/unmount loop                     | `tests/performance/memory.bench.ts`           | Passed | Observes repeated cleanup path and records heap delta during the run                                                                       |
+
+Conclusion:
+
+- The benchmark command is reproducible and currently passes.
+- These runs are smoke benchmarks in jsdom, not browser production benchmarks.
+- No claim is made that Solace meets or exceeds a specific framework performance target yet.
+- The latest renderer follow-ups batch all-element Fragment initial mounts through a `DocumentFragment`,
+  batch all-element array children during element initial mount and text-to-array child replacement, skip
+  stable child component updates when parent rerenders do not change child props or children, skip
+  unchanged keyed element sibling patches during local list updates, and avoid prop patching plus `Object.keys`
+  props scans for keyed child-only updates. Unkeyed appended all-element suffixes
+  batch through a `DocumentFragment` after index patching, and safe removed leaf suffixes detach through
+  a temporary `DocumentFragment`, including adjacent old keyed runs removed during mixed placement. Keyed
+  mixed insert/move patches now mount new children directly at their final anchor instead of appending and
+  moving them. Contiguous all-element keyed insert segments also batch through a `DocumentFragment` before
+  one parent insert, including adjacent new runs discovered during mixed keyed placement. The component update path
+  also avoids repeated enqueue attempts while a component update is already pending. The component initial mount path
+  also batches child inserts through a `DocumentFragment`. The initial element mount path now uses a conservative props
+  fast path for ordinary attributes, avoiding `Object.entries()` scans and redundant attribute removals on fresh
+  elements. It also uses a direct HTML `className` fast path for `class` props while keeping the existing attribute
+  fallback for non-HTML nodes. Next optimization work should focus on additional browser trend samples.
+
+## Browser Production Benchmark
+
+Command:
+
+```bash
+pnpm benchmark:browser
+```
+
+This command builds `examples/performance-benchmark`, serves the production output through Vite
+preview, and runs `tests/e2e/browser-benchmark.spec.ts` in Chromium.
+
+Measured scenarios:
+
+| Scenario                    | Scale       | Assertion                              |
+| --------------------------- | ----------- | -------------------------------------- |
+| Initial large-list render   | 10,000 rows | selected row 1 is rendered             |
+| Reactive selected-row patch | 10,000 rows | selected row 5000 reflects final state |
+| Large-list unmount          | 10,000 rows | row nodes are removed                  |
+
+The command logs a `browser benchmark summary` JSON line. It intentionally does not enforce absolute
+timing thresholds because browser, CPU, power mode, and background process variance can dominate
+individual runs.
+
+The summary also includes reproducibility metadata:
+
+| Field                                                                        | Source                          |
+| ---------------------------------------------------------------------------- | ------------------------------- |
+| `metadata.packageName` / `metadata.packageVersion`                           | `package.json`                  |
+| `metadata.node`                                                              | `process.version`               |
+| `metadata.platform`, `metadata.release`, `metadata.arch`                     | Node `os` module                |
+| `metadata.cpuModel`, `metadata.logicalCpuCount`, `metadata.totalMemoryBytes` | Node `os` module                |
+| `metadata.browserName`, `metadata.browserVersion`, `metadata.projectName`    | Playwright                      |
+| `metadata.sampleSize`                                                        | Current benchmark harness       |
+| `metadata.runAt`                                                             | ISO timestamp for the local run |
+
+`metadata.sampleSize` defaults to `1` so `pnpm benchmark:browser` remains a smoke benchmark run. Set
+`SOLACE_BROWSER_BENCHMARK_SAMPLE_SIZE=3 pnpm benchmark:browser` to run three independent browser benchmark samples in
+one Playwright run. The command logs one `browser benchmark summary` line per sample.
+
+Set `SOLACE_BROWSER_BENCHMARK_HISTORY_PATH=.benchmark-history/browser.jsonl pnpm benchmark:browser`
+to append one JSONL record after each successful Chromium production benchmark sample. Browser history
+records persist the existing summary object; they do not add timing thresholds or statistical aggregation.
+
+Run `pnpm benchmark:history` to summarize local JSONL history from `.benchmark-history/jsdom.jsonl`
+and `.benchmark-history/browser.jsonl`. Use `pnpm benchmark:history -- --json <path>` for
+machine-readable output. The summary reports record counts plus median, p95, and variance for
+numeric browser timing metrics and jsdom task metrics; it does not enforce thresholds.
+
+Use `pnpm benchmark:history -- --min-browser-count 5` to require each browser benchmark scenario
+to have at least five local history records. This is an opt-in trend quality gate for local or CI
+checks; it is not a timing threshold and does not compare measured performance against a target.
+Use `pnpm benchmark:history -- --latest-browser-count 5` to summarize only the latest five browser
+records per scenario while leaving jsdom record counts in the summary. This is useful when older
+slow samples dominate full-history p95 and the next runtime hotspot needs a fresher trend window.
+Run `pnpm benchmark:history -- --help` to list the supported summary options.
+
+### Latest Local Browser History Summary
+
+Date: 2026-07-20
+
+Local history command:
+
+```bash
+pnpm benchmark:history -- --min-browser-count 20 --json
+```
+
+The local ignored history currently contains forty-five Chromium `large-list` production benchmark records. The
+`--min-browser-count 20` trend gate passes locally. p95 still reflects the slowest observed samples and should be
+treated as trend context only, not a release threshold.
+
+| Metric            | Count | Median | p95  | Variance |
+| ----------------- | ----- | ------ | ---- | -------- |
+| `initialRenderMs` | 45    | 7.7    | 15.7 | 18.98    |
+| `updateMs`        | 45    | 3.6    | 6.1  | 4.23     |
+| `unmountMs`       | 45    | 1.2    | 1.4  | 0.14     |
+
+Latest-window command:
+
+```bash
+pnpm benchmark:history -- --latest-browser-count 5 --min-browser-count 5 --json
+```
+
+The latest five Chromium `large-list` records still show a slow-sample ceiling on initial render, but the median
+remains lower than the preceding full-history window.
+
+| Metric            | Count | Median | p95  | Variance |
+| ----------------- | ----- | ------ | ---- | -------- |
+| `initialRenderMs` | 5     | 7.7    | 16.2 | 13.46    |
+| `updateMs`        | 5     | 4.0    | 6.1  | 0.93     |
+| `unmountMs`       | 5     | 1.2    | 1.3  | 0.01     |
+
+## Benchmark Principles
+
+Benchmarks should:
+
+- Run in production mode where possible.
+- Separate initial render, update, and unmount costs.
+- Record browser, OS, Node, package version, and commit.
+- Avoid comparing development builds against production builds.
+- Report medians and variance, not a single best run.
+- Keep benchmark fixtures in source control.
+
+## Suggested Benchmarks
+
+### Reactivity
+
+- Create many reactive objects.
+- Track many effects.
+- Trigger narrow and broad dependency sets.
+- Measure computed cache hits and invalidations.
+
+### Renderer
+
+- Mount 1,000 and 10,000 simple elements.
+- Patch text props across a large list.
+- Insert, remove, and move keyed children.
+- Unmount nested component trees.
+
+### Components
+
+- Mount many small components.
+- Batch repeated state writes in one tick.
+- Repeatedly mount and unmount component subtrees.
+- Verify no retained effects after unmount.
+
+### Store
+
+- Read state directly in components.
+- Read computed getters in components.
+- Dispatch actions that update narrow state paths.
+
+## Reporting Template
+
+```text
+Scenario:
+Build mode:
+Browser / Node:
+Machine:
+Sample size:
+Median:
+p95:
+Notes:
+```
+
+Performance claims should only be added after this data exists.

package/docs/release.md

@@ -0,0 +1,67 @@
+# Release
+
+Solace uses Changesets for version notes and package version updates.
+
+## Local Release Gate
+
+Run the full local gate before preparing a release:
+
+```bash
+pnpm release:check
+```
+
+This runs format check, typecheck, JSX dev typecheck, lint, default tests, package exports tests, coverage thresholds, package consumer smoke, jsdom benchmark smoke, Chromium production browser benchmark, and browser e2e tests.
+
+The GitHub Actions CI workflow keeps these checks split into named steps and also runs both benchmark commands: `pnpm benchmark` and `pnpm benchmark:browser`.
+
+CI also runs `pnpm release:readiness` before the longer checks so package metadata and release script drift fail early.
+
+## Release Readiness
+
+Run the local metadata readiness check before changing publishability:
+
+```bash
+pnpm release:readiness
+```
+
+This command checks local package metadata, package entry points, release scripts, and Changesets public access configuration. It does not contact npm and does not publish.
+
+The package is now publishable. To verify the stricter publishable mode before publishing, run:
+
+```bash
+pnpm release:readiness -- --publishable
+```
+
+## Prepare A Version
+
+Create a changeset for user-visible changes:
+
+```bash
+pnpm changeset
+```
+
+Apply pending changesets to `package.json` and changelog files:
+
+```bash
+pnpm release:version
+```
+
+## Publish
+
+Before publishing, explicitly confirm:
+
+- the npm package name `@italone/solace` is available or controlled by the maintainer,
+- npm authentication and organization access are configured,
+- public access is intended,
+- `pnpm release:readiness -- --publishable` passes,
+- `pnpm release:check` passes,
+- `pnpm package:smoke` passes after the final version update,
+- Changesets versioning has been run for user-visible changes.
+
+After that decision, run:
+
+```bash
+pnpm release:publish
+```
+
+`release:publish` runs the full local release gate before `changeset publish`.