chore: prepare the 0.1.1 release

AGENTS.md

@@ -16,6 +16,16 @@ Follow [module ownership](development/architecture.md). Shared DOM and reading p
 
 Use `<type>[optional scope]: <description>` for every new or renamed PR title, for example `docs: clarify CLI installation` or `fix(cli): preserve input files`. Allowed types are defined in [.github/semantic.yml](.github/semantic.yml): `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` and `revert`. Semantic PR checks the title only; valid commit messages do not compensate for an invalid PR title. Use the same convention for commit messages.
 
+## Changelog
+
+- Update [CHANGELOG.md](CHANGELOG.md) in the same pull request for significant user-visible changes. Compare the final behavior with the latest release tag rather than recording the sequence of commits that produced it.
+- Include public API migrations, new capabilities, correctness or compatibility changes, and meaningful performance improvements. Exclude tests, internal refactors, documentation, CI, tooling, and dependency maintenance unless they change supported or observable behavior.
+- Keep the permanent `## Unreleased` section at the top. Group entries under `### Breaking changes`, `### New features`, `### Improvements`, and `### Bug fixes` in that order, and include only categories that contain entries.
+- Write one bullet for each coherent behavior. Combine related commits, describe the observable impact, and give the required migration for breaking changes. Do not include pull request numbers, issue numbers, discarded intermediate APIs, or implementation history.
+- Write from the user's perspective: name the affected public API, element, CLI command, or workload and its observable result. Omit implementation mechanics unless users need them to migrate, understand compatibility, or assess risk.
+- Scope performance claims to the workload supported by evidence. Distinguish broad improvements from scenario-specific benchmark results, and do not generalize a microbenchmark into a library-wide claim.
+- During release preparation, move the accumulated entries from `## Unreleased` into `## vX.Y.Z (YYYY-MM-DD)` immediately below `## Unreleased`, using the actual UTC release date; keep `## Unreleased` in place for subsequent changes.
+
 ## Build and package boundaries
 
 Keep the root API usable without browser globals, scalar imports free of Canvas, and Web Component registration explicit. `pnpm test:bundle` checks real bundled consumers and fixed gzip limits without depending on Git history. Do not increase a limit simply to make a failure pass; explain the user-facing benefit of added bytes.

CHANGELOG.md

@@ -4,7 +4,14 @@ All significant changes to ScopeView are documented in this file.
 
 ## Unreleased
 
-- Include snapshot-scoped exact source context (`MetricInspectionContext`, `TraceInspectionContext`, `ProfileInspectionContext`) in headless `onInspect`/`onSelect` callbacks and component `scope-inspect`/`scope-select` events.
+## v0.1.1 (2026-10-29)
+
+### New features
+
+- Include snapshot-scoped exact source context (`MetricInspectionContext`, `TraceInspectionContext`, and `ProfileInspectionContext`) in headless `onInspect` and `onSelect` callbacks and Web Component `scope-inspect` and `scope-select` events.
+
+### Improvements
+
 - Reduce exact-reading formatting and narrow-label layout costs while preserving source values and chart geometry.
 
 ## v0.1.0 (2026-10-28)

RELEASE.md

@@ -50,7 +50,7 @@ Use the accepted artifact from the release run, after all verification and nativ
 
 ## Release procedure
 
-1. Prepare a commit with the intended `package.json` version and a dated changelog heading, for example `## v0.1.0 (2026-10-28)`. Keep the notes focused on the released behavior. Review and merge the changes.
+1. Prepare a commit with the intended `package.json` version and move the accumulated entries from `## Unreleased` under a dated changelog heading immediately below it, for example `## v0.1.0 (2026-10-28)`. Keep `## Unreleased` at the top and keep the notes focused on the released behavior. Review and merge the changes.
 2. Optionally run **Release** through `workflow_dispatch` on the candidate ref. This builds and tests all artifacts without publishing. Artifact retention is seven days.
 3. Create and push `v<version>` at that reviewed commit. This is the publication trigger. Tag/version mismatches and undated changelog entries fail before building. Never move a published tag or reuse an npm version.
 4. `release.yml` calls the normal verification workflow, packages and tests all six native targets, verifies checksums, then publishes the accepted npm bytes using OIDC. It creates the GitHub Release with those same artifacts and the changelog section.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@scopedb/scopeview",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "license": "Apache-2.0",
   "repository": {
     "type": "git",