feat(web): add bilingual release history to Settings > About - #1791
techotaku39 wants to merge 20 commits into
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Findings
- [Major] Several entries describe cumulative auto-generated release ranges instead of the changes introduced by that version. The clearest examples are v0.16.3, v0.20.0, and v0.25.3; each repeats features already assigned to the immediately preceding release. Rebuild affected entries from
previous-tag...current-tag, not from a release body's potentially stale comparison base. See inline comment atweb/src/lib/releaseNotes.ts:665. - [Minor] The authoring guide says to update after tagging, but
release-all.tsbuilds and publishes before creating the tag. Following the guide leaves the shipped artifact without its own release note. Require the target entry before the release build. See inline comment atdocs/guide/release-notes-authoring.md:5. - [Minor] The 102,109-byte catalogue is synchronously pulled into the application entry graph because the router eagerly imports the About page. Lazy-load this route so session users do not download and parse the history until needed. See inline comment at
web/src/routes/settings/about.tsx:2.
Summary
Review mode: initial
Three findings: one release-history correctness issue and two release/performance regressions. The catalogue's tag set and UTC dates match the repository's stable GitHub Releases; semantic claims across all 74 releases remain a residual manual-verification risk.
Testing
Not run (automation). Static repository inspection and GitHub release/tag comparisons only; PR code was not executed.
HAPI Bot
| '增加 Gemini YOLO、Claude 技能发现、Codex 思考控制、终端字号和与模型无关的 Agent 接口；改进启动诊断与工作目录处理。', | ||
| [ | ||
| group('Agent capabilities', 'Agent 能力', [ | ||
| change('feature', 'Add Gemini YOLO, Codex reasoning effort, Claude skill-directory scanning, terminal font-size settings, and model-agnostic Agent interfaces.', '增加 Gemini YOLO、Codex 思考强度、Claude 技能目录扫描、终端字号设置和与模型无关的 Agent 接口。'), |
There was a problem hiding this comment.
[MAJOR] Build each entry from the immediately preceding release
This v0.16.3 bullet re-announces Gemini YOLO, Codex reasoning effort, Claude skill scanning, and spawn diagnostics, all of which the adjacent v0.16.2 entry already attributes at lines 674-683. The live v0.16.2...v0.16.3 comparison contains only the later terminal-font/model-interface and working-directory fixes. The same cumulative attribution occurs in v0.20.0 and v0.25.3 because their generated release bodies compare from older tags. Users therefore get an incorrect answer to “what changed in this version.” Audit affected entries against the immediately preceding tag comparison.
Suggested fix:
releaseNote('0.16.3', '2026-03-20',
'Add terminal font sizing and model-agnostic Agent interfaces; improve Runner and Codex working-directory handling.',
'增加终端字号和与模型无关的 Agent 接口；改进 Runner 与 Codex 的工作目录处理。',
[
group('Agent capabilities', 'Agent 能力', [
change('feature', 'Add terminal font-size settings and model-agnostic Agent interfaces.', '增加终端字号设置和与模型无关的 Agent 接口。'),
]),
group('Working-directory fixes', '工作目录修复', [
change('fix', 'Pass session cwd to Codex, preserve cwd for Runner launches, and warn before creating missing directories.', '向 Codex 传递会话目录，保留 Runner 启动目录，并在创建缺失目录前警告。'),
]),
]),|
|
||
| The in-app release history is maintained in `web/src/lib/releaseNotes.ts`. It | ||
| is bundled with the Web app so users can read it offline. Keep the catalog | ||
| newest-first and update it when a release is tagged. |
There was a problem hiding this comment.
[MINOR] Author the target entry before the release build
The guide says to update the catalogue “when a release is tagged,” but cli/scripts/release-all.ts:136-194 bumps the version, builds/publishes the embedded Web app, and only then commits and tags. Following this timing ships version X with version X-1 as the newest announcement; the catalogue test does not run in that release path. Document the pre-build timing and add a cheap preflight guard.
Suggested fix:
const releaseNotes = readFileSync(join(repoRoot, 'web/src/lib/releaseNotes.ts'), 'utf8')
if (!releaseNotes.includes(`releaseNote('${version}'`)) {
throw new Error(`Add release notes for ${version} before building the release`)
}| @@ -1,9 +1,17 @@ | |||
| import { PROTOCOL_VERSION } from '@hapi/protocol' | |||
| import { RELEASE_NOTES } from '@/lib/releaseNotes' | |||
There was a problem hiding this comment.
[MINOR] Keep the release catalogue out of the initial application chunk
This synchronous import adds the entire 102,109-byte catalogue (30,323 bytes when gzipped at source level) to the About module, and web/src/router.tsx:71 eagerly imports that module into the application entry graph. Every Web/PWA user pays the download and parse cost even when they only open sessions. Lazy-loading the About route still allows Workbox to precache the generated chunk for offline use.
Suggested fix:
import { lazy, Suspense } from 'react'
const LazySettingsAboutPage = lazy(() => import('@/routes/settings/about'))
const SettingsAboutRoute = () => (
<Suspense fallback={<LoadingState className="m-4" />}>
<LazySettingsAboutPage />
</Suspense>
)
// route definition
component: SettingsAboutRoute,
There was a problem hiding this comment.
Findings
- [Major] The documented pre-release sequence cannot pass its own catalog test —
web/src/lib/releaseNotes.test.ts:8requires the first entry to equal the current__APP_VERSION__, butdocs/guide/release-notes-authoring.md:10tells authors to merge the next version's entry beforecli/scripts/release-all.ts:153updates that version. A correctly prepended next release therefore fails the focused test and CI before it can be merged. The substring check atcli/scripts/release-all.ts:126also does not ensure that the target is the newest real catalog entry.
Suggested fix:// web/src/lib/releaseNotes.test.ts expect(RELEASE_NOTES.some((release) => release.version === __APP_VERSION__)).toBe(true) // cli/scripts/release-all.ts const latestReleaseVersion = releaseNotes.match( /export const RELEASE_NOTES = \[\s*releaseNote\('([^']+)'/, )?.[1] if (latestReleaseVersion !== version) { throw new Error(`Put release notes for ${version} first before building`) }
Questions
- None.
Summary
Review mode: follow-up after new commits
One Major release-workflow conflict remains. Residual risk: semantic accuracy across the 74 hand-authored historical entries is not fully machine-verifiable.
Testing
Not run (automation). Static inspection of the full latest diff, surrounding source, prior review, and tag-range commit history only; PR code was not executed.
HAPI Bot
| it('keeps every entry localized, linked, and newest-first', () => { | ||
| expect(RELEASE_NOTES.length).toBeGreaterThan(0) | ||
| expect(RELEASE_NOTES.length).toBeGreaterThanOrEqual(74) | ||
| expect(RELEASE_NOTES[0].version).toBe(__APP_VERSION__) |
There was a problem hiding this comment.
[MAJOR] Allow the next release note to be authored before the version bump
The new guide requires merging the target release entry before release-all.ts runs, but this assertion requires the first entry to remain the old __APP_VERSION__. Prepending the next release makes the documented focused test and CI fail, so the next release cannot follow the new sequence. Relax this test to require that the currently built version remains present, then make the release script validate that its target is structurally the first catalog entry rather than merely a matching substring.
Suggested fix:
expect(RELEASE_NOTES.some((release) => release.version === __APP_VERSION__)).toBe(true)And in cli/scripts/release-all.ts:
const latestReleaseVersion = releaseNotes.match(
/export const RELEASE_NOTES = \[\s*releaseNote\('([^']+)'/,
)?.[1]
if (latestReleaseVersion !== version) {
throw new Error(`Put release notes for ${version} first before building`)
}
There was a problem hiding this comment.
Findings
- [Minor] The new About-page Playwright coverage is not run by CI -
e2e/about-release-notes.spec.ts:5adds viewport-sensitive and native<details>interaction coverage, but.github/workflows/test.yml:16still invokes onlyterminal-wrap-fidelity.spec.tsandcomposer-copy.spec.ts. These assertions can regress without affecting the required test check.
Suggested fix:- run: bun run test:e2e -- terminal-wrap-fidelity.spec.ts composer-copy.spec.ts about-release-notes.spec.ts
Questions
- None.
Summary
Review mode: follow-up after new commits
One Minor testing gap remains. The prior release-sequencing Major is resolved. Residual risk: the semantic accuracy of 74 hand-authored bilingual summaries is not fully machine-verifiable.
Testing
Not run (automation). Static inspection only; executing PR code is disallowed for this review. GitHub integration check passed, while the main test check was still pending at review time.
HAPI Bot
|
|
||
| const fixture = '/e2e-fixtures/about-fixture.html' | ||
|
|
||
| test('renders localized release announcements on the mobile About page', async ({ page }) => { |
There was a problem hiding this comment.
[MINOR] Add this browser spec to the CI selection
The required test workflow currently runs only terminal-wrap-fidelity.spec.ts and composer-copy.spec.ts, so this new spec is skipped. That leaves the real viewport switching and native <details> click behavior covered only by a manual command.
Suggested fix:
- run: bun run test:e2e -- terminal-wrap-fidelity.spec.ts composer-copy.spec.ts about-release-notes.spec.ts
There was a problem hiding this comment.
Findings
- None.
Questions
- None.
Summary
Review mode: follow-up after new commits
The new commit adds about-release-notes.spec.ts to the required E2E selection at .github/workflows/test.yml:16, resolving the prior HAPI Bot finding. I re-reviewed the full latest diff; no Blocker, Major, Minor, or Nit findings met the 80% confidence threshold. The catalog contains all 74 stable release tags, and its version/date pairs match the repository release metadata. The required test and integration checks pass. PR code was not executed locally under the review security policy.
HAPI Bot
There was a problem hiding this comment.
Findings
-
[Major] Hide pre-release entries from the deployed app — the new authoring flow requires merging the target entry before running the release (
docs/guide/release-notes-authoring.md:11), and anyweb/**push tomainimmediately deploysapp.hapi.run(.github/workflows/webapp.yml:3). However, the About page renders the entire newest-first catalog atweb/src/routes/settings/about.tsx:28, while the catalog test only requires__APP_VERSION__to appear somewhere. Preparing the next release will therefore publish its version, date, details, and a not-yet-existing GitHub Release URL before the tag is created. Slice the catalog from the embedded app version and add a regression test with a future entry.Suggested fix:
const currentReleaseIndex = RELEASE_NOTES.findIndex( (release) => release.version === __APP_VERSION__, ) const visibleReleaseNotes = currentReleaseIndex >= 0 ? RELEASE_NOTES.slice(currentReleaseIndex) : RELEASE_NOTES // Render visibleReleaseNotes.map(...) below.
Questions
- None.
Summary
Review mode: follow-up after new commits
One Major release-flow issue found. The latest catalog metadata matches the 75 published stable releases, including v0.29.1. Static review only; PR code was not executed under the review security policy. Existing tests do not cover hiding a prepared future release from the current deployed app.
HAPI Bot
| title={t('settings.about.releaseNotes.title')} | ||
| description={t('settings.about.releaseNotes.description')} | ||
| > | ||
| {RELEASE_NOTES.map((release, index) => ( |
There was a problem hiding this comment.
[MAJOR] Hide entries newer than the embedded app version.
The new guide requires merging the next release entry before tagging, and .github/workflows/webapp.yml deploys every web/** push to main. Mapping the full newest-first catalog here makes app.hapi.run immediately show the unreleased version/date/details and a release URL that does not exist yet. The current catalog test only checks that __APP_VERSION__ exists somewhere, so it does not prevent this.
Suggested fix:
const currentReleaseIndex = RELEASE_NOTES.findIndex(
(release) => release.version === __APP_VERSION__,
)
const visibleReleaseNotes = currentReleaseIndex >= 0
? RELEASE_NOTES.slice(currentReleaseIndex)
: RELEASE_NOTES
// Render visibleReleaseNotes.map(...) here.Please also add a regression test with a future entry ahead of __APP_VERSION__ and assert that it is not rendered.
There was a problem hiding this comment.
Findings
-
[Major] Make the future-entry regression test independent of the current catalogue — once the next real release entry is prepended, the correct visible suffix is shorter than
RELEASE_NOTES, so the hard-coded0.29.1and full-length assertion fail during the exact preparation flow documented indocs/guide/release-notes-authoring.md:24. Evidence:web/src/lib/releaseNotes.test.ts:52.Suggested fix:
const currentIndex = RELEASE_NOTES.findIndex( (release) => release.version === __APP_VERSION__, ) const expected = RELEASE_NOTES.slice(currentIndex) const futureRelease = { ...RELEASE_NOTES[0], version: '999.0.0', date: '9999-12-31', url: 'https://github.com/tiann/hapi/releases/tag/v999.0.0', } expect(getVisibleReleaseNotes( __APP_VERSION__, [futureRelease, ...RELEASE_NOTES], )).toEqual(expected)
-
[Major] Remove current-release constants from the About E2E — the release script updates
APP_VERSIONbefore building and pushes that commit, while this test is now in the push workflow. On the next release, the visible count and first summary change, so75and the v0.29.1 copy make every release commit's CI fail. Evidence:e2e/about-release-notes.spec.ts:10, related flowcli/scripts/release-all.ts:156,.github/workflows/test.yml:16.Suggested fix:
import { APP_VERSION } from '../shared/src/buildInfo' import { getVisibleReleaseNotes, RELEASE_NOTES, } from '../web/src/lib/releaseNotes' const visibleReleaseNotes = getVisibleReleaseNotes(APP_VERSION, RELEASE_NOTES) const latestRelease = visibleReleaseNotes[0] await expect(page.locator('details')).toHaveCount(visibleReleaseNotes.length) await expect(page.locator('details').first().locator('p').first()) .toContainText(latestRelease.summary.en)
Questions
- None.
Summary
Review mode: follow-up after new commits
The prior future-release visibility issue is fixed in application code. Two Major test regressions remain: preparing the next catalogue entry breaks the new unit regression, and completing the next version bump makes the newly enabled E2E fail on the release commit. The 75 catalogue tags/dates match the 75 published non-prerelease GitHub releases.
Testing
- Not run (automation); static review only under the PR security policy.
HAPI Bot
| const visible = getVisibleReleaseNotes('0.29.1', preparedCatalog) | ||
|
|
||
| expect(visible[0].version).toBe('0.29.1') | ||
| expect(visible).toHaveLength(RELEASE_NOTES.length) |
There was a problem hiding this comment.
[MAJOR] Make this expectation relative to the embedded app version.
As soon as a real future release is added before 0.29.1, correct filtering excludes that entry, so visible is shorter than RELEASE_NOTES and this regression test fails during the documented preparation flow.
Suggested fix:
const currentIndex = RELEASE_NOTES.findIndex(
(release) => release.version === __APP_VERSION__,
)
const expected = RELEASE_NOTES.slice(currentIndex)
const futureRelease = {
...RELEASE_NOTES[0],
version: '999.0.0',
date: '9999-12-31',
url: 'https://github.com/tiann/hapi/releases/tag/v999.0.0',
}
expect(getVisibleReleaseNotes(
__APP_VERSION__,
[futureRelease, ...RELEASE_NOTES],
)).toEqual(expected)| await page.goto(fixture) | ||
|
|
||
| await expect(page.getByText("What's New")).toBeVisible() | ||
| await expect(page.locator('details')).toHaveCount(75) |
There was a problem hiding this comment.
[MAJOR] Do not pin the E2E to today's catalogue size and first release.
release-all.ts bumps APP_VERSION before building and pushes the release commit, and this spec is now part of the push workflow. The next bump exposes one more entry and changes the first summary, so the hard-coded count/copy makes release CI fail every time.
Suggested fix:
import { APP_VERSION } from '../shared/src/buildInfo'
import {
getVisibleReleaseNotes,
RELEASE_NOTES,
} from '../web/src/lib/releaseNotes'
const visibleReleaseNotes = getVisibleReleaseNotes(APP_VERSION, RELEASE_NOTES)
const latestRelease = visibleReleaseNotes[0]
await expect(page.locator('details')).toHaveCount(visibleReleaseNotes.length)
await expect(page.locator('details').first().locator('p').first())
.toContainText(latestRelease.summary.en)
There was a problem hiding this comment.
Findings
-
[Major] Make the About unit tests version-relative - the new tests pin v0.29.1, its date, copy, and change counts.
release-all.tsupdatesAPP_VERSIONbefore the release commit, Vitest reads that value throughvite.config.ts, and the push workflow then runs these tests. On the next release commit, the page correctly renders the newly added release first, so these assertions fail and leave every release CI red. Evidence:web/src/routes/settings/index.test.tsx:339(same issue in the Chinese case atweb/src/routes/settings/index.test.tsx:359; release sequencecli/scripts/release-all.ts:156).Suggested fix:
import { getVisibleReleaseNotes, RELEASE_NOTES } from '@/lib/releaseNotes' const latestRelease = getVisibleReleaseNotes(__APP_VERSION__, RELEASE_NOTES)[0] const changes = latestRelease.groups.flatMap((group) => group.changes) expect(screen.getByText(`v${latestRelease.version}`)).toBeInTheDocument() expect(screen.getByText(latestRelease.groups[0].changes[0].text.en)).toBeInTheDocument() expect(within(latestReleaseElement).getAllByText('Added', { exact: true })) .toHaveLength(changes.filter((change) => change.kind === 'feature').length)
Questions
- None.
Summary
Review mode: follow-up after new commits
The two prior Major findings were fixed in the new commits. One equivalent release-cycle regression remains in the About unit tests: their current-release constants will fail immediately after the next version bump.
Testing
- Not run (automation); static review only under the PR security policy. Current-head checks pass, but they use
APP_VERSION = 0.29.1and do not cover the next release bump.
HAPI Bot
| expect(screen.getByText('Protocol Version')).toBeInTheDocument() | ||
| expect(screen.getByRole('link', { name: 'hapi.run' })).toHaveAttribute('rel', 'noopener noreferrer') | ||
| expect(screen.getByText("What's New")).toBeInTheDocument() | ||
| expect(screen.getByText('v0.29.1')).toBeInTheDocument() |
There was a problem hiding this comment.
[MAJOR] Make these About assertions version-relative.
release-all.ts changes APP_VERSION before creating the release commit, and Vitest receives that value from vite.config.ts. Once the next release entry becomes visible, the page correctly renders that version first, but this test still requires v0.29.1, its exact copy/date, and fixed Added/Fixed counts. The push workflow will therefore fail on every release commit. The Chinese case below has the same pin.
Suggested fix:
import { getVisibleReleaseNotes, RELEASE_NOTES } from '@/lib/releaseNotes'
const latestRelease = getVisibleReleaseNotes(__APP_VERSION__, RELEASE_NOTES)[0]
const changes = latestRelease.groups.flatMap((group) => group.changes)
expect(screen.getByText(`v${latestRelease.version}`)).toBeInTheDocument()
expect(screen.getByText(latestRelease.groups[0].changes[0].text.en)).toBeInTheDocument()
expect(within(latestReleaseElement).getAllByText('Added', { exact: true }))
.toHaveLength(changes.filter((change) => change.kind === 'feature').length)
There was a problem hiding this comment.
Findings
-
[Major] Make badge assertions change-kind-relative too — the new version-relative unit assertions still call
getAllByTextfor both Added and Fixed, which throws beforetoHaveLength(0)when a release has none of that kind. The E2E likewise always requires Added/新增. Feature-only, fix-only, and note-only releases are valid and already represented in the catalogue, so bumping any such release toAPP_VERSIONmakes the release push CI fail. Evidence:web/src/routes/settings/index.test.tsx:349(Chinese case atweb/src/routes/settings/index.test.tsx:370; E2E ate2e/about-release-notes.spec.ts:22).Suggested fix:
const labels = { feature: { en: "Added", "zh-CN": "新增" }, fix: { en: "Fixed", "zh-CN": "修复" }, note: { en: "Note", "zh-CN": "说明" }, } as const for (const kind of ["feature", "fix", "note"] as const) { expect(within(latestReleaseElement).queryAllByText(labels[kind].en, { exact: true })) .toHaveLength(latestReleaseChanges.filter((change) => change.kind === kind).length) } const firstLabel = labels[latestReleaseChanges[0].kind] expect(within(latestReleaseElement).getByText(firstLabel.en, { exact: true })) .toHaveClass("relative", "top-px", "sm:top-[0.5px]")
Use
firstLabel["zh-CN"]in the localized unit/E2E assertions instead of hard-coding 新增.
Questions
- None.
Summary
Review mode: follow-up after new commits
One Major release-cycle regression remains: valid releases without an Added item, or without a Fixed item, still leave the push test workflow red.
Testing
- Static review only; PR code was not executed. Integration and Windows Codex MCP checks pass; the main test job is still pending.
HAPI Bot
There was a problem hiding this comment.
Findings
-
[Major] Keep the desktop badge assertion release-relative too --
e2e/about-release-notes.spec.ts:28still requires anAddedbadge even though the same test now derives the current release and supportsfeature,fix, andnote. Fix-only and note-only releases are valid and already exist in the catalogue; when either becomesAPP_VERSION, this required E2E fails in.github/workflows/test.yml:16before the release commit can go green.Suggested fix:
const firstKindLabel = releaseKindLabels[latestReleaseChanges[0].kind].en await expect( page.locator('details').first().getByText(firstKindLabel, { exact: true }).first(), ).toHaveClass(/sm:top-\[0\.5px\]/)
Questions
- None.
Summary
Review mode: follow-up after new commits
One Major release-cycle regression remains: the unit and localized E2E assertions are now change-kind-relative, but the desktop E2E badge assertion still assumes every release contains an Added item. Catalogue version/date pairs match all 75 published non-prerelease GitHub releases.
Testing
- Not run (automation); executing PR code is disallowed by the review security policy. GitHub integration and Windows Codex MCP checks pass; the main test job is still pending.
HAPI Bot
| await page.setViewportSize({ width: 1280, height: 844 }) | ||
| await expect(releaseSummary.getByText('🌟', { exact: true })).toBeHidden() | ||
| await expect(releaseSummary.getByText('⭐', { exact: true })).toBeVisible() | ||
| await expect(page.locator('details').first().getByText('Added', { exact: true }).first()).toHaveClass(/sm:top-\[0\.5px\]/) |
There was a problem hiding this comment.
[MAJOR] Keep this assertion change-kind-relative. This remaining hard-coded Added lookup makes the required E2E fail whenever the current release is fix-only or note-only, both valid catalogue shapes. Derive the label from the first current-release change, as the assertions below already do.
Suggested fix:
const firstKindLabel = releaseKindLabels[latestReleaseChanges[0].kind].en
await expect(
page.locator('details').first().getByText(firstKindLabel, { exact: true }).first(),
).toHaveClass(/sm:top-\[0\.5px\]/)
There was a problem hiding this comment.
Findings
- No findings.
Questions
- None.
Summary
Review mode: follow-up after new commits
No issues found on the fresh head. The prior hard-coded change-kind regression is resolved at e2e/about-release-notes.spec.ts:28; the latest full PR diff was reviewed. Residual risk: the 75-entry bilingual catalogue is primarily editorial data, so automated coverage validates structure, ordering, localization presence, current-version visibility, and rendering—not the semantic fidelity of every historical sentence.
Testing
- Not run (automation); executing PR code is disallowed by the review security policy.
- At review time: integration and windows-codex-mcp passed; the main test job remains in progress.
HAPI Bot
heavygee
added
enhancement
…e-notes # Conflicts: # .github/workflows/test.yml
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. This adds a supported capability missing from the existing page.
Evidence
- Snapshot PR description and issue #1790 establish the in-app, bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 renders only website, application version, and protocol version.
Approach — Pass
A bundled catalogue, lazy-loaded About page, version-based visibility, and pre-build release guard fit the existing architecture.
Evidence
- web/src/lib/releaseNotes.ts:23 hides entries preceding the current application version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:178 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:123 checks the target entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. Found one historical attribution defect. Historical claims were selectively checked against releases and tagged source; not every bilingual sentence was independently verified.
- [Minor] Remove later features from the v0.19.0 entry —
web/src/lib/releaseNotes.ts:594
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed, per the review boundary.
- Fixed-head CI: integration and windows-codex-mcp passed; test remained in progress.
- The merge-base diff passes git diff --check.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering; they do not verify historical feature attribution or the release preflight.
HAPI Bot
| ]), | ||
| group('Conversation and media', '对话与媒体', [ | ||
| change('feature', 'Show message timestamps, status indicators, image lightboxes, dynamic voice controls, and inline image display.', '显示消息时间戳、状态指示器、图片灯箱、动态语音控制和内联图片。'), | ||
| change('feature', 'Add conversation export, session workbench tools, and file/work-directory browsing improvements.', '增加对话导出、会话工作台工具及文件/工作目录浏览改进。'), |
There was a problem hiding this comment.
[Minor] Remove later features from the v0.19.0 entry
The v0.19.0 entry advertises conversation export and session workbench tools, but both arrived between v0.19.0 and v0.20.0: f086949 adds conversation export, and 18bcb52 adds the Scratchlist workbench. The v0.19.0 source contains neither capability. Users reading this entry therefore receive incorrect information about feature availability, and the same additions are already listed under v0.20.0.
Suggested fix
Remove the export and workbench claims from both translations of v0.19.0 and retain them under v0.20.0. Check nearby historical entries against adjacent tag deltas for similar attribution errors.
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. The existing page lacks this capability.
Evidence
- The snapshot description and issue #1790 establish the in-app, bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 renders only website, application version, and protocol version.
Approach — Pass
A bundled catalogue, lazy-loaded About route, version-based visibility, and pre-build release guard fit the existing architecture.
Evidence
- web/src/lib/releaseNotes.ts:23 hides prepared entries preceding the current application version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:179 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:123 checks the target entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the full fixed-head merge-base diff. The previous finding is fixed; one historical attribution issue remains. Historical claims were selectively verified against releases and tagged source.
- [Minor] Remove existing image features from v0.20.0 additions —
web/src/lib/releaseNotes.ts:573
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed, as required.
- Fixed-head CI: integration and windows-codex-mcp passed; test remained in progress.
- The merge-base diff passes git diff --check.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering; they do not verify historical attribution or the release preflight.
HAPI Bot
| change('feature', 'Add a backend voice picker with advanced controls and support pluggable Gemini Live and Qwen Realtime backends.', '增加带高级控制的语音后端选择器，并支持可插拔的 Gemini Live 与 Qwen Realtime 后端。'), | ||
| ]), | ||
| group('Agent and message controls', 'Agent 与消息控制', [ | ||
| change('feature', 'Add inline display_image, chat-image lightboxes, and a close button for mobile dialogs.', '增加内联 display_image、聊天图片灯箱和移动端对话框关闭按钮。'), |
There was a problem hiding this comment.
[Minor] Remove existing image features from v0.20.0 additions
The v0.20.0 entry presents display_image and chat-image lightboxes as new, but commits de5dc97 and cf378df introduced them before v0.19.0. Tagged v0.19.0 source already registers display_image and renders image attachments through ImagePreview; these implementations are unchanged in v0.20.0. This gives readers an incorrect account of what upgrading adds. The official v0.20.0 changelog spans v0.18.4..v0.20.0, which explains the duplicated attribution.
Suggested fix
Keep the mobile-dialog close-button addition in this bullet, remove the two image-feature additions from both translations, and retain those features under v0.19.0.
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. The existing page does not provide this capability.
Evidence
- The snapshot description and issue #1790 establish the in-app, bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 renders only website, application version, and protocol version.
Approach — Pass
A bundled catalogue, lazy-loaded About route, version-based visibility, and pre-build release guard fit the existing architecture and release sequence.
Evidence
- web/src/lib/releaseNotes.ts:23 filters prepared entries preceding the current application version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:179 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:123 checks the target entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. The previous image-feature attribution finding is fixed, but other carried-forward additions remain. Historical claims were selectively verified against releases and tagged source.
- [Minor] Remove remaining carried-forward feature additions —
web/src/lib/releaseNotes.ts:949
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed, as required.
- Fixed-head CI: integration and windows-codex-mcp passed; test remained in progress when checked.
- The merge-base diff passes git diff --check.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering; they do not verify historical attribution or the release preflight.
HAPI Bot
| '增加端到端加密 relay 服务，并修复 macOS relay 启动和 TLS 证书路径。', | ||
| [ | ||
| group('Encrypted relay', '加密 Relay', [ | ||
| change('feature', 'Provide an end-to-end encrypted relay that works without tunnel configuration.', '提供无需配置隧道即可使用的端到端加密 relay。'), |
There was a problem hiding this comment.
[Minor] Remove remaining carried-forward feature additions
The v0.8.2 entry labels encrypted relay support as Added, although commit 5defb6d introduced it before v0.8.0; the later relay changes fix runtime assets and paths. The official v0.8.2 body repeats the older highlight. Similarly, v0.25.0 lists conversation export as an addition at line 391, although f086949 introduced it in v0.20.0 and the export dialog and implementation are unchanged between v0.24.0 and v0.25.0. These entries misstate what upgrading to those versions adds.
Suggested fix
Remove the relay introduction from both v0.8.2 translations and its summary, retaining the actual fixes. Remove the generic conversation-export addition from v0.25.0. Keep those introductions under v0.8.0 and v0.20.0, and use adjacent tagged source changes to distinguish repeated highlights from new functionality.
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. The existing page does not provide this capability.
Evidence
- The snapshot description and issue #1790 establish the bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 renders only website and version information.
Approach — Pass
A bundled catalogue, lazy-loaded About route, version-based visibility, and pre-build release guard fit the existing architecture.
Evidence
- web/src/lib/releaseNotes.ts:23 filters entries preceding the current application version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:179 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:123 checks the target entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. The previous relay/export attribution finding is fixed, but two other historical additions remain misattributed. Historical behavior was selectively verified against tagged source.
- [Minor] Correct remaining historical feature attribution —
web/src/lib/releaseNotes.ts:476
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed, as required.
- Fixed-head CI: integration and windows-codex-mcp passed; test remained in progress when checked.
- The merge-base diff passes git diff --check.
- Catalogue versions and UTC dates match the published stable releases.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering; historical attribution and the release preflight lack regression coverage.
HAPI Bot
| '增加 Kimi Code、更多 Pi 与 Web 控制、模型感知工具、主题和目录元数据；改进 transcript、恢复和消息渲染稳定性。', | ||
| [ | ||
| group('Agent support and controls', 'Agent 支持与控制', [ | ||
| change('feature', 'Add Kimi Code support, Pi max thinking, skill_lookup for non-native agents, and tool-call duration details.', '增加 Kimi Code 支持、Pi max 思考级别、面向非原生 Agent 的 skill_lookup，以及工具调用耗时详情。'), |
There was a problem hiding this comment.
[Minor] Correct remaining historical feature attribution
The v0.23.0 entry says Kimi Code support was added, although 763f45a introduced it in v0.19.0. The later change, 22e9b38, adds local transcript synchronization and adapts configuration/model handling to the rewritten Kimi architecture. Likewise, line 388 lists Android Web Share Target integration under v0.25.0, although 2643f17 introduced it in v0.21.0 and its implementation is unchanged between v0.24.0 and v0.25.0. These statements mislead users about what upgrading adds.
Suggested fix
Describe the specific Kimi synchronization and compatibility changes in both v0.23.0 translations and summaries. Remove Android Web Share Target from v0.25.0 while retaining the companion push/pairing additions; keep its introduction under v0.21.0.
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. Existing behavior does not provide this capability.
Evidence
- The snapshot description and issue #1790 establish the bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 displays only website and version information.
Approach — Pass
A bundled catalogue, lazy-loaded route, version-based visibility, and pre-build release guard fit the existing architecture.
Evidence
- web/src/lib/releaseNotes.ts:23 filters prepared entries preceding the current version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:179 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:123 checks the target entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. Both previously flagged attributions are corrected. One additional historical claim needs correction; no runtime defect was identified.
- [Minor] Attribute outline search to its actual release —
web/src/lib/releaseNotes.ts:662
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed.
- Fixed-head CI: integration and windows-codex-mcp passed; test remained in progress.
- The merge-base diff passes git diff --check.
- All 79 catalogue versions and UTC dates match published stable releases; historical behavior was selectively checked against tagged source.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering. Release-preflight and offline lazy-route behavior lack direct regression coverage.
HAPI Bot
| '增加 Web 对话大纲和子 Agent 轨迹，并在恢复非活动会话时保留选定的权限模式。', | ||
| [ | ||
| group('Conversation navigation', '对话导航', [ | ||
| change('feature', 'Show a searchable conversation outline and subagent traces in tool details.', '显示可搜索的对话大纲，并在工具详情中展示子 Agent 轨迹。'), |
There was a problem hiding this comment.
[Minor] Attribute outline search to its actual release
The v0.17.3 entry advertises a searchable conversation outline. That tag's ConversationOutlinePanel only lists and navigates items; commit 33015b6 introduced the search input and filtering in v0.23.4. Both translations therefore promise functionality unavailable in v0.17.3.
Suggested fix
Remove “searchable” and “可搜索的” from the v0.17.3 bullet. Keep search attributed to v0.23.4, where it is already listed.
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. Existing functionality does not meet this use case.
Evidence
- The snapshot description and issue #1790 establish the bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 displays only website and version information.
Approach — Pass
A bundled catalogue, lazy-loaded About route, version-based visibility, and pre-build release guard fit the existing architecture and release sequence.
Evidence
- web/src/lib/releaseNotes.ts:23 hides prepared entries preceding the current version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:179 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:123 checks the target entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. No actionable defects identified. The previous outline-search attribution is corrected in both languages at web/src/lib/releaseNotes.ts:662. Historical claims were selectively verified against published releases and tagged source; runtime behavior was not executed.
No reportable code issues found.
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed, as required.
- Fixed-head CI: integration and windows-codex-mcp passed; test remained in progress when checked.
- The merge-base diff passes git diff --check.
- All 79 catalogue versions and UTC dates match published stable releases.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering. The release preflight and offline navigation through the lazy-loaded route lack direct regression coverage.
HAPI Bot
…e-notes # Conflicts: # .github/workflows/test.yml
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. The existing page does not provide this capability.
Evidence
- The snapshot description and issue #1790 establish the bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 displays only website and version information.
Approach — Pass
A bundled catalogue, lazy-loaded About route, version-based visibility, and pre-build release guard fit the existing architecture. The release-script defect below is fixable within this approach.
Evidence
- web/src/lib/releaseNotes.ts:23 hides entries preceding the current app version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:198 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:106 places catalogue validation before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. Found one release-blocking runtime defect. Historical claims were selectively checked; PR code was not executed.
- [Major] Import readFileSync before using it in release preflight —
cli/scripts/release-all.ts:108
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed, as required.
- Fixed-head CI: integration passed; test and windows-codex-mcp were still running when checked.
- The merge-base diff passes git diff --check.
- All 81 catalogue versions and UTC dates match published stable releases.
- Added tests cover catalogue structure, localization, future-entry visibility, and responsive rendering. Release-preflight execution and offline navigation through the lazy-loaded route lack direct regression coverage.
HAPI Bot
|
|
||
| // Release notes must be present before the embedded Web build runs. | ||
| const releaseNotesPath = join(repoRoot, 'web', 'src', 'lib', 'releaseNotes.ts'); | ||
| const releaseNotes = readFileSync(releaseNotesPath, 'utf-8'); |
There was a problem hiding this comment.
[Major] Import readFileSync before using it in release preflight
Running release-all.ts on main reaches this call, but readFileSync is neither imported nor defined. The script therefore throws a ReferenceError before updating versions or building, even when the target catalogue entry exists. Dry-run and publish-only invocations also fail. The CLI typecheck includes only src files, so it does not catch this scripts-directory error.
Suggested fix
Add import { readFileSync } from 'node:fs'; and add regression coverage that exercises the release preflight without building or publishing.
There was a problem hiding this comment.
Review mode: follow-up after new commits
Requirement — Pass
Bilingual release history lets users understand version changes inside About, including offline. Existing functionality does not meet this use case.
Evidence
- The snapshot description and issue #1790 establish the bilingual, offline use case.
- Base web/src/routes/settings/about.tsx:5 displays only website and version information.
Approach — Pass
A bundled catalogue, expandable entries, lazy-loaded route, and pre-build release guard fit the existing architecture and release sequence.
Evidence
- web/src/lib/releaseNotes.ts:23 hides prepared entries preceding the current app version.
- web/src/router.tsx:79 lazy-loads About; web/vite.config.ts:198 includes JavaScript chunks in offline precaching.
- cli/scripts/release-all.ts:107 checks the target catalogue entry before version updates and the embedded Web build.
Code — Reviewed
Reviewed the entire fixed-head merge-base diff. No actionable defects found. The previously reported missing readFileSync import is fixed. Historical release claims were selectively verified.
No reportable code issues found.
Testing
Not run (automation; PR code execution is prohibited).
- No PR code, tests, builds, or scripts were executed.
- Fixed-head CI: integration and windows-codex-mcp passed; test was still running when checked.
- The merge-base diff passes git diff --check.
- All 81 catalogue versions and UTC dates match published stable releases; versions are ordered newest-first.
- Added tests cover catalogue structure, localization, future-entry visibility, responsive rendering, and header interaction. Release-preflight execution and offline navigation through the lazy-loaded route lack direct regression coverage.
HAPI Bot
2 participants
Summary
covering 81 official releases from v0.1.3 through v0.30.7.
Added/Fixedlabels.Notelabel for releases where the official notes list no user-facingfunctional changes.
link it directly to the corresponding GitHub Release page.
instructions.
Problem / Motivation
The About page previously showed only application metadata. Users had to leave
the app and open GitHub Releases to understand what changed in each version.
The existing release workflow generates GitHub release notes, but it does not
surface them in the Web/PWA UI or provide a consistent bilingual authoring
format for future releases.
Implementation
web/src/lib/releaseNotes.ts.Release links, and
feature/fix/notechange kinds.each version describes changes introduced by that version.
prepared at the top of the catalogue before the release build.
application chunk.
🌟.⭐.docs/guide/release-notes-authoring.md.entry before the embedded Web build starts. Preparation-time validation only
requires the current app version to exist in the catalogue; the release
preflight requires the target version to be the first entry.
regression, plus About-page tests, a dedicated About fixture, and responsive
E2E coverage.
main-branch E2E coverage.
origin/mainand retain itscold-initial-tail.spec.tsandscrollbar-auto-hide.spec.tscoveragetogether with the About E2E.
This PR intentionally does not automate release-note generation in the release
workflow. Issue #1790 tracks the follow-up decision about AI generation,
reviewed release-note PRs, and release gating.
Validation
bun typecheck— passed after merging latestmain.bun run .\\node_modules\\vitest\\vitest.mjs run --config .\\vitest.config.ts src/routes/settings/index.test.tsx src/lib/releaseNotes.test.ts— 17 passed after merging latestmainand adding v0.30.6–v0.30.7.pwsh -NoProfile -File ..\\..\\scripts\\Invoke-HapiTaskPlaywright.ps1 -Name about-release-notes -Suite Root about-release-notes.spec.ts— 1 passed; verifies localized release announcements, responsive icons, version-link behavior, same-day release dates, and version-aware visibility.bun run build— passed after merging latestmain; the About route is emitted as a separate chunk.git diff --check— passed.Related Issues
Refs #1790
AI Disclosure
OpenAI Codex (GPT-5.6) assisted with GitHub release and pull-request research,
bilingual release-note drafting, implementation, documentation, conflict
resolution, and test execution.