chore(release): 0.84.0

[vutuanlinh2k2]

Release 0.84.0.

Includes:

• feat(chat): lead the composer bottom row with the attach buttons #180 — feat(chat): lead the composer bottom row with the attach buttons

Merging bumps package.json on main, which triggers the Auto Release & Publish workflow (npm + GitHub Packages + GitHub release v0.84.0).

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	59.2s (2 bridge agents)
Total	59.2s

💰 Value — sound

One-line version bump 0.83.0 → 0.84.0 in package.json that triggers the established auto-release workflow; matches the repo's documented release mechanism and prior release commits exactly. Ship.

• What it does: Bumps package.json version from 0.83.0 to 0.84.0 (package.json:3). Per CLAUDE.md and .github/workflows/release.yml, a push to main changing the version field triggers build + npm/GitHub Packages publish + GitHub Release v0.84.0. The released content is #180 (95dee0c), the chat composer change already merged to main.
• Goals it achieves: Publish the work merged since 0.83.0 (specifically #180) as a new npm/GitHub Packages release with a tagged GitHub release. This is the repo's only release trigger — version bump on main IS the release act.
• Assessment: Good, and exactly in the grain of the codebase. The prior release 0.83.0 (00b8b06) is byte-for-byte the same shape: a one-line package.json bump and nothing else. 11 prior chore(release) commits follow this pattern. Version number is a sensible minor bump for a feature release (#180 is feat(chat)). Nothing reinvented, nothing disproportionate.
• Better / existing approach: None — this is the right approach. Verified against the repo's documented release contract (CLAUDE.md 'Release flow': bumping the version is the release trigger) and the identical precedent commit 00b8b06. One observation outside this PR's diff: CHANGELOG.md's newest entry is 0.81.0 (CHANGELOG.md:3) while 0.82.0–0.84.0 have shipped/are shipping without entries — a pre-existing maintenance drift ac
• Model: opencode/kimi-for-coding/k2p7
• Bridge attempts: 1

🎯 Usefulness — sound

Routine one-line version bump (0.83.0 → 0.84.0) that triggers the repo's established OIDC auto-release workflow to ship the already-merged #180 chat composer change.

• Integration: The version field is the sole release trigger per .github/workflows/release.yml:3-6 (push to main, paths: [package.json], gated on the v0.84.0 GitHub release not yet existing). This is the canonical, repeatedly-used integration path — identical to the 0.83.0 (#179) and 0.71.0 (#167) releases. The content it releases, commit 95dee0c (#180), is already on main and will be picked up by the build/publ
• Fit with existing patterns: Matches the codebase's documented and established release pattern precisely (CLAUDE.md: 'Bumping the version is the release trigger'). No competing mechanism; no alternative design — this is the design.
• Real-world viability: The workflow is idempotent-safe (the 'Check for version change' step re-checks for an existing v0.84.0 release, so a re-run won't double-publish), concurrency-serialized (concurrency group 'release-publish', cancel-in-progress: false at release.yml:16-18), and publishes to npm + GitHub Packages + creates the GitHub release with --generate-notes. Robust on the happy path and the re-run path.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260716T065505Z}

[tangletools]

✅ No Blockers — 1213d7ed

Review health 100/100 · Reviewer score 92/100 · Confidence 65/100 · 2 findings (2 low)

	glm	kimi-code	aggregate
Readiness	92	92	92
Confidence	65	65	65
Correctness	92	92	92
Security	92	92	92
Testing	92	92	92
Architecture	92	92	92

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision.

🟡 LOW CHANGELOG has no 0.84.0 entry — package.json

CLAUDE.md states 'CHANGELOG.md is hand-maintained -- add an entry when bumping the version.' Verified via git show <base>:CHANGELOG.md that the latest entry is 0.81.0; 0.82.0, 0.83.0, and this 0.84.0 bump all lack entries. This is consistent with the prior two release commits (00b8b06, 4531350-era) so it is a pre-existing drift rather than a new regression, and CHANGELOG.md is outside this shot's changed-file scope. Flagging only as a housekeeping nit for whoever owns release notes; does not block this version bump.

🟡 LOW package-lock.json version left stale (pre-existing pattern) — package.json

The bump to 0.84.0 does not sync package-lock.json, whose root "version" fields (lines 3 and 9) still read 0.10.2. Evidence shows this is pre-existing — the base package.json was 0.83.0 while the lockfile already said 0.10.2, and the prior release commit 00b8b06 also bumped package.json alone. Impact is nil for publishing (release.yml reads package.json directly and npm publish ignores the lockfile version); it is cosmetic metadata drift. Optional fix: run npm install --package-lock-only or npm version in future releases to keep the lockfile in sync.

---

_{tangletools · 2026-07-16T06:55:13Z · trace}

[tangletools]

✅ Approved — 2 non-blocking findings — 1213d7ed

Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 1/1 planned shots over 1 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-16T06:55:13Z · immutable trace}

[tangletools]

✅ Refreshed approval after new commits — 8bb0b563

A previous trusted approval on this PR was invalidated by new commits.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: stale_approval_refresh · 2026-07-16T06:56:51Z}

[vutuanlinh2k2]

Thanks — addressing both LOW findings:

1. CHANGELOG missing 0.84.0 entry — fixed (8bb0b56). Added a ## 0.84.0 → ### Chat entry describing the AgentComposer attach-button reorder, per the CLAUDE.md rule that CHANGELOG.md is hand-maintained on version bumps. Scoped to this bump only — the pre-existing 0.82.0/0.83.0 gaps are prior release authors' to backfill, and I don't have the change context for those.

2. package-lock.json version stale (0.10.2) — won't fix (pre-existing, nil impact). This repo publishes via pnpm (release.yml runs pnpm install --frozen-lockfile); package-lock.json is a vestigial npm lockfile that isn't the source of truth, and release.yml reads the version straight from package.json. The base was already package.json@0.83.0 / lockfile 0.10.2, and the prior release (#179) bumped package.json alone with CI green — so this is longstanding decoupling, not a regression from this PR. Syncing it is out of scope here; better handled as its own housekeeping change.