chore(release): prepare 0.1.2

[vincentkoc]

What Problem This Solves

The fixes merged since 0.1.1 are still recorded under Unreleased, and the package manifest still identifies the previous version. A v0.1.2 tag would therefore fail the release workflow's tag-to-package version check.

Why This Change Was Made

Advance @openclaw/uirouter to 0.1.2 and promote the accumulated changelog entries into a dated 2026-10-01 release section with a concise navigation-state highlight. The lockfile remains unchanged because it does not store the root package version.

No router source, public exports, types, history adapter contracts, loader behavior, cache semantics, lifecycle hooks, runtime support, or release workflow behavior changes.

User Impact

This prepares the existing fixes for the repository's tag-driven trusted-publishing workflow. It does not create a tag, publish npm, or create a GitHub release.

Downstream OpenClaw adoption must wait seven days after 0.1.2 is published.

Related: #45
Related: #46

Evidence

• Fresh main exact head 5dc5da240ef79342edf822326a239d1967b9e04e passed CI and CodeQL:
  • https://github.com/openclaw/uirouter/actions/runs/36832546119
  • https://github.com/openclaw/uirouter/actions/runs/36832546076
• pnpm install --frozen-lockfile
• pnpm run check
  • format check
  • ESM and declaration build
  • TypeScript typecheck
  • type-aware lint
  • 58 tests in 9 files
  • packed tarball allowlist, fresh consumer install, and package import
• Release metadata check: @openclaw/uirouter@0.1.2, expected tag v0.1.2, trusted-publishing identity and repository metadata valid.
• git diff --check
• Diff: 2 files, +5/-1; no production or test LOC.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[vincentkoc]

@clawsweeper review

[clawsweeper]

🦞👀
Exact review queued.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/36833180067
• Updated: 2026-10-01T07:55:47.600Z

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed October 1, 2026, 3:54 AM ET / 07:54 UTC.

ClawSweeper review

What this changes

The PR advances the package version to 0.1.2 and groups the accumulated changelog entries under a dated release heading.

Merge readiness

✅ Ready for maintainer review

This release preparation remains necessary: current main still identifies 0.1.1, and the latest published release is v0.1.1. The narrow patch has no actionable correctness findings.

Priority: P3
Reviewed head: 1ceea2fef1b95f43f3ef836345c4cc1bee8b33e7

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused release preparation with matching metadata, successful package checks, and no identified defects.
Proof confidence	🌊 off-meta tidepool	Not applicable: The MEMBER-authored release metadata change is exempt from contributor runtime proof; exact-head CI provides supplemental packaging validation, and no stored-data contract changes.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The MEMBER-authored release metadata change is exempt from contributor runtime proof; exact-head CI provides supplemental packaging validation, and no stored-data contract changes.
Evidence reviewed	7 items	Pinned introduced change: The complete introduced diff changes only the package version and adds the release heading and highlight. The verified test-merge comparison has the same changes; git diff --check passed. Current main still needs version preparation: The pinned main manifest still declares 0.1.1, whereas the PR declares 0.1.2. Existing release contract: The unchanged publishing workflow requires the tag to equal v followed by the package version and requires the tagged commit to be an ancestor of main. CONTRIBUTING.md also specifies tag-driven trusted publishing.
Findings	None	None.
Security	None	None.

How this fits together

The standalone router package is distributed to applications through npm. Its release workflow checks the package version against a main-branch tag before publishing the package and creating a GitHub release.

flowchart LR
  A[Package version] --> C[Release validation]
  B[Main branch release tag] --> C
  C --> D[Package checks]
  D --> E[Npm publication]
  E --> F[GitHub release]
  G[Changelog] --> E

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Release metadata scope	2 files; +5/-1; production 0, tests 0	The release preparation adds no router implementation or test code.

Technical review

Best possible solution:

Keep version preparation aligned with the existing trusted-publishing process and publish from a matching main-branch tag when release scheduling permits.

Do we have a high-confidence way to reproduce the issue?

Not applicable to this release chore; source inspection confirms that a v0.1.2 tag would mismatch the current main package version.

Is this the best way to solve the issue?

Yes. Updating the manifest and grouping existing changelog entries is the narrowest change needed by the established release workflow.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 5dc5da240ef7.

Labels

Label changes:

• add P3: This is bounded release metadata preparation with no introduced runtime behavior change.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The MEMBER-authored release metadata change is exempt from contributor runtime proof; exact-head CI provides supplemental packaging validation, and no stored-data contract changes.

Label justifications:

• P3: This is bounded release metadata preparation with no introduced runtime behavior change.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The MEMBER-authored release metadata change is exempt from contributor runtime proof; exact-head CI provides supplemental packaging validation, and no stored-data contract changes.

Evidence

What I checked:

• Pinned introduced change: The complete introduced diff changes only the package version and adds the release heading and highlight. The verified test-merge comparison has the same changes; git diff --check passed. (package.json:3, 1ceea2fef1b9)
• Current main still needs version preparation: The pinned main manifest still declares 0.1.1, whereas the PR declares 0.1.2. (package.json:3, 5dc5da240ef7)
• Existing release contract: The unchanged publishing workflow requires the tag to equal v followed by the package version and requires the tagged commit to be an ancestor of main. CONTRIBUTING.md also specifies tag-driven trusted publishing. (.github/workflows/release.yml:100, 1ceea2fef1b9)
• Release and changelog provenance: GitHub reports v0.1.1 as the latest release, published 2026-08-10. The main-branch commits since that tag support the accumulated changelog, including merged fix(router): abort a joined preload when the router stops #45 and fix(router): let a pending navigation finish when invalidate runs #46; those runtime fixes do not replace this metadata preparation. (CHANGELOG.md:11, 5dc5da240ef7)
• Exact-head validation: GitHub check runs for the pinned PR head show all six Node 22/24 platform checks and workflow lint succeeding. The unchanged CI runs pnpm run check, which includes packed-package validation. Builds and tests were not rerun during this read-only review. (.github/workflows/ci.yml, 1ceea2fef1b9)
• Release-area routing history: GitHub commit metadata and patches verify prior release-workflow work by vincentkoc and steipete, plus the prior version preparation by steipete. Some older local blobs were unavailable through the promisor remote; GitHub inspection supplied the relevant patches without relying on incomplete blame. (.github/workflows/release.yml, 700efef1731e)

Likely related people:

• vincentkoc: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.