Package segments made only of dots, leading dots, a leading underscore on
unscoped names and .tgz/.tar/.tar.gz names are no longer accepted by the
installsource and registry checks. parseGitHubRepoSource refuses dot-leading
owners and dot-only repos such as the one TrimSuffix(".git") leaves from
"...git".
Refs #11353
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
A cli-pointer job publishes the Studio release's CLI archives as a GitHub
release vX.Y.Z (the only shape the 1.x updater accepts), records it
immutably in R2, then advances cli/{stable,preview}/latest.json. It reuses
the 1.x manifest validators and pointer ordering, only moves forward, and
is gated by STUDIO_PUBLISHES_CLI.
cli-gate requires CLI_PUBLISH_FROZEN so two lines never write the CLI
channels. cli-tag creates the vX.Y.Z tag with the release tag identity in
one inline step of a job that runs no repository code. An existing release
is trusted on its own checksums, never compared with a rebuild.
`@scope/[email protected]` and `[email protected]` were rejected by both
looksLikePackage implementations (Go installer and registry publish
validation), so an npm MCP entry could not pin its version. Both now accept
an optional `@<exact semver>` suffix and still refuse ranges, dist-tags,
empty versions, a repeated `@`, and anything with whitespace, shell
metacharacters, path segments or scheme prefixes.
A leading `-` is now refused as well, so a bare source can no longer be read
by npx as an option. The default MCP name drops the version suffix.
Pinning the top-level package does not pin its transitive dependencies.
internal/ was 141 packages side by side, so nothing but a reader's memory
said which were foundations and which assembled the rest. Each now sits in a
layer directory, and the directory is the declaration:
base L0 foundation with no domain in it
contract L1 types and interfaces the layers above agree on
model, tools, safety, ext, state, platform
L2 subsystems, peers of one another
runtime L3 the turn engine
session L4 the controller
assembly L5 the composition root
frontend L6 cli, serve, acp and the host adapters
Only paths change: package names, code and behaviour do not. Imports,
repolint and coverage baselines, sensitive paths, CI package lists and docs
follow the new paths; release notes keep the paths they were written with,
and sample paths inside tests and fixtures keep theirs.
repolint gains layer-order: a package may import its own layer and those
below it, read from where it lives. The 47 imports that point upward today
are recorded as that rule's opening debt (-allow-widen, a new rule's first
baseline) and can only go down. Most of it is config, which still reaches
into eight subsystems and is the next thing to take apart; the rest is
event, history and a few tools reaching into runtime for types that belong
in contract.
reasonix.io is built and deployed from main-v2 only. pages.yml, removed
in 68b031ae5, ran on main-v2 pushes. On studio the directory was a
remnant, and it still read release-notes/releases.json, which that
commit deleted. main-v2 keeps the site; nothing here published it.
- site/ (60 files) is deleted.
- ci.yml loses the site job, which ran site/'s node tests, and the
`site` output of the path filter. The code and desktop skip patterns
no longer name site/.
- .gitignore loses the five site build-output rules.
- The crash-report worker's shell comment names the reasonix.io website
instead of a stylesheet path that no longer exists here.
studio has no branch protection or required status checks, so dropping
the job leaves no check pending. actionlint passes and make lint is
clean. internal/fileref still skips site/.astro in file pickers: that is
workspace behavior for users' Astro projects, not a dependency on this
directory.
The account the kernel closes at each release is five integers with no
path, command or identity in it, so it can ride the channel that already
has consent: three closed enums added to the upload allow-list, and a
group on the dashboard beside the other settings metrics.
lease_hold contended | uncontended
lease_wait the existing latency tiers, contended holds only
lease_idle how much of the hold came after the last write asked
The third is the one that decides anything. A high contention rate with
a low idle share means the lease is held exactly as long as it is used,
and the proposal to release at the last verification would return
nothing; the reverse says the opposite.
Flushed on its own rather than into the turn's batch, because the lease
is released when a session's last run ends and that is not reliably
before the TurnDone that empties the batch. Nothing here changes who
reports: the policy is unchanged and still refuses a non-release build,
CI, DO_NOT_TRACK, and anything but an interactive session under `auto`.
A hold with no length has no idle share rather than a share of zero,
which would read as a hold measured to have been busy throughout.
The dashboard's group table moved to a file of its own instead of
stats.ts growing past its ceiling, and the 17 lines that file had been
carrying are reclaimed.
Opt-in metrics carried the anonymous install id so the dashboard could show a
deduplicated daily user per signal. Keeping that answer meant keeping a row per
install per signal per day — ~28M of them — and the 30-day COUNT(DISTINCT
install_id) over that table was the database's entire read bill: the primary
key leads with `date`, so each query could prune only the window and scanned
the whole table, eight signals an hour, ~5.4B rows a day for one module.
The client stops sending the id, the worker stops writing and creating the
tables, the hourly rollup that existed only to make that query survivable is
gone, and the dashboard's users/opens toggle goes with it. The aggregate
tables keep the same signals as event counts in ~180k rows.
migrate-drop-metric-users.sql drops the four retired tables. Deploy the worker
first — it stops creating them at runtime, and a DROP before that is rebuilt on
the next request.
* fix(desktop): add Windows crash attribution diagnostics
Problem: Windows LTSC 2019 abrupt exits could not be attributed reliably, test telemetry could reach production, and Diagnostics counted lifecycle events rather than affected installations.
Root cause: legacy startup state was replayable, WebView2 failures were inferred from log text without native process details, and the crash Worker lacked build-, runtime-, and installation-level aggregation.
Fix: fail-close Desktop test endpoints, consume legacy state atomically, add lifecycle v2 and native WebView2 Args2/Args3 observation, and extend privacy-bounded telemetry, D1 rollups, Diagnostics filters, and bilingual release runbooks.
Verification: go test ./... in root and desktop; focused race tests; Worker typecheck and 86 tests; frontend tests and production build; fresh and migrated SQLite schema validation; Windows amd64 Desktop and vendored WebView2 cross-compilation; git diff --check.
* refactor(diagnostics): satisfy owner size budgets
Problem: the initial diagnostics implementation exceeded the repository's incremental file and function size budgets in Desktop startup, Worker ingestion, and dashboard rendering owners.
Root cause: lifecycle initialization, installation aggregation, and group-detail rendering were added directly to already baselined entry-point files.
Fix: move lifecycle setup into its tracker owner, extract diagnostics-v2 storage and query policy, and isolate crash-group rendering without changing wire contracts or runtime behavior.
Verification: repolint; Worker typecheck and 86 tests; focused Desktop and repair tests; Windows amd64 Desktop cross-compilation; the unrelated transient updater test passed three consecutive focused reruns.
* test(repair): use WaitGroup.Go for claim race
Problem: the current PR lint rejected the manual WaitGroup Add/go/Done pattern in the concurrent legacy-state claim regression test.
Root cause: the test used the legacy goroutine setup even though the repository modernize rules require sync.WaitGroup.Go.
Fix: use WaitGroup.Go while preserving the explicit ready barrier and deterministic interleaving.
Verification: go test ./internal/repair; go test -race ./internal/repair; go run ./tools/repolint; git diff --check.
* fix(repair): serialize legacy startup claims
Problem: Windows CI observed zero reports when concurrent launches tried to consume one dead legacy startup record.
Root cause: concurrent pre-claim reads can keep Windows file handles open long enough for every rename attempt to fail.
Fix: acquire the existing non-blocking cross-process file lock before reading and atomically renaming the legacy record, so exactly one observer owns the claim path.
Verification: 100 concurrent-claim repetitions; 20 race-enabled repetitions; full internal/repair normal and race suites; Windows amd64 test compilation; repolint; git diff --check.
* fix(diagnostics): close Windows crash attribution gaps
Start lifecycle tracking after the Wails single-instance gate and serialize anonymous install identity creation across concurrent callers.
Wait for WebView2 navigation completion before recording renderer recovery, commit crash group/sample/aggregate writes in one D1 batch, and align runtime CLI schema and diagnostics ordering.
* fix(diagnostics): address PR review findings
Problem:
- Renderer recovery could consume an unrelated navigation and recoverable COM errors could terminate the desktop.
- Per-install daily rows overwrote WebView2 dimensions, relabeling earlier GPU and runtime events.
- The PR exceeded repository size gates and did not execute vendored patch tests in Windows CI.
Root cause:
- Recovery completion was not correlated with NavigationStarting IDs, and shared fatal error handling was reused.
- Mutable dimension columns and event counts lived in the same deduplicated installation row.
Fix:
- Correlate renderer reloads by navigation ID, keep recovery errors non-fatal, and default failed kind reads to unknown.
- Add immutable event-dimension facts for filters and distributions while retaining installation deduplication.
- Split diagnostics tests, trim size regressions, and run vendored WebView2 tests in Windows CI.
Verification:
- go test ./...
- targeted Desktop and internal/repair race tests
- Worker tests and typecheck
- Frontend 146-suite test run
- repolint, actionlint, gofmt, and Windows cross-compile
* fix(desktop): align raw bundle ratchet
Problem:
The Desktop CI inherited a main-v2 raw startup bundle size of 2204.8 KiB while the ratchet still allowed only 2203 KiB, so frontend builds stopped before all Desktop checks.
Root cause:
Recent always-loaded desktop contracts already moved the baseline beyond the old threshold, and this PR adds the required diagnostics privacy attribution copy without materially changing gzip size.
Fix:
Raise only the raw aggregate allowance to a tightly measured 2205 KiB and document the native diagnostics copy. Keep gzip, CSS, locale, and largest-chunk limits unchanged.
Verification:
- pnpm build
- go run ./tools/repolint
- git diff --check
* feat(desktop): add cross-platform crash diagnostics
Problem: Desktop runtime failures lacked reliable ownership, lifecycle attribution, and affected-install analytics across Windows and Linux.
Root cause: legacy startup records could replay, WebView2 diagnostics were platform-specific, and Worker aggregation mixed recovery outcomes into unstable groups.
Fix: add fail-open primary ownership and lifecycle v2, generic Web Runtime reports, native WebView2 and WebKitGTK observers, privacy-safe platform dimensions, additive D1 aggregates, and cross-platform Dashboard filters.
Verification: go test and race suites, go vet, golangci-lint, Worker typecheck/tests, frontend tests/build/bundle budgets, repolint, actionlint, and Windows amd64 cross-builds.
* fix(diagnostics): preserve future lifecycle schemas
Problem:
A future lifecycle schema that removes v2 PID or phase fields could be treated as an invalid v2 record and pruned after retention.
Root cause:
The consumer validated v2-specific fields before checking the schema version.
Fix:
Reject unknown schemas before applying v2 validation or cleanup, and cover an aged future record without current fields.
Verification:
- cd desktop && go test . -run '^TestDesktopLifecycle'
- cd desktop && go test -race . -run '^TestDesktopLifecycle'
- git diff --check
* fix(diagnostics): correlate WebKit reload events
Problem:
The native WebKitGTK recovery smoke classified a successful renderer reload as failed and could not reach the cooldown assertion.
Root cause:
WebKit can emit load-failed for the terminated navigation after web-process-terminated. The recovery state treated every pending load failure as belonging to the new reload.
Fix:
Track whether the recovery reload has emitted LOAD_STARTED and only accept load-failed and LOAD_FINISHED after that boundary. Reset the marker on every terminal path and extend the source contract test.
Verification:
GOCACHE=/tmp/reasonix-pr8169-go-cache go test . -run '^(TestWebKit|TestWebRuntime)'
git diff --check
* fix(diagnostics): defer WebKit recovery reload
Problem:
WebKitGTK 4.1 still timed out the success recovery smoke after load events were scoped to the recovery navigation.
Root cause:
Starting webkit_web_view_reload synchronously inside the web-process-terminated signal callback is unreliable while WebKit is still dispatching process teardown.
Fix:
Schedule the single recovery reload on the GTK main context's idle queue, retain the WebView until dispatch, and guard the helper with the pending recovery owner. Update the source contract test to enforce this deferred abnormal-only path.
Verification:
GOCACHE=/tmp/reasonix-pr8169-go-cache go test . -run '^(TestWebKit|TestWebRuntime)'
git diff --check
* test(diagnostics): isolate WebKit smoke scenarios
Problem:
After the deferred reload made the success smoke pass, the next scenario aborted inside WebKitGTK while constructing another test WebView in the same process.
Root cause:
The smoke harness repeatedly destroyed and recreated WebViews that share WebKitGTK's process-global default context. That cross-scenario lifecycle does not match the single-WebView Desktop process and leaves asynchronous teardown active between cases.
Fix:
Run success, failure, timeout, and cooldown scenarios in isolated test subprocesses. Keep the cooldown pair in one child and one WebView so repeated native termination and single-reload behavior remain covered.
Verification:
GOCACHE=/tmp/reasonix-pr8169-go-cache go test . -run '^(TestWebKit|TestWebRuntime)'
git diff --check
* test(diagnostics): keep WebKit smoke local
Problem:
The isolated success and cooldown smoke scenarios still reported reload failure while failure and timeout behaved correctly.
Root cause:
The test HTML used https://reasonix.invalid as its base URI. Reloading the terminated view attempted to resolve that unreachable URI, so the smoke measured a synthetic network failure instead of native process recovery.
Fix:
Load the smoke HTML with a NULL base URI, which WebKitGTK maps to local about:blank content and requires no network access.
Verification:
GOCACHE=/tmp/reasonix-pr8169-go-cache go test . -run '^(TestWebKit|TestWebRuntime)'
git diff --check
* test(diagnostics): use reloadable WebKit smoke URI
Problem:
The native success and cooldown scenarios still timed out with load_html content even after removing the unreachable base URI.
Root cause:
A transient document created by load_html does not provide a stable reloadable resource after its WebProcess is terminated on the tested WebKitGTK runtime.
Fix:
Load a fully local data URI before terminating the WebProcess. This provides a stable current URI for the same production reload call without adding network or filesystem I/O.
Verification:
GOCACHE=/tmp/reasonix-pr8169-go-cache go test . -run '^(TestWebKit|TestWebRuntime)'
git diff --check
* test(diagnostics): allow WebKit process startup
Problem:
The native smoke used a one-second recovery timeout and classified cold WebProcess startup under Xvfb as a failed reload.
Root cause:
The smoke-only timeout was substantially shorter than observed headless WebKitGTK process creation, while production correctly allows thirty seconds.
Fix:
Raise only the tagged smoke timeout to five seconds. Keep the production timeout at thirty seconds and the smoke safety timeout at fifteen seconds.
Verification:
GOCACHE=/tmp/reasonix-pr8169-go-cache go test . -run '^(TestWebKit|TestWebRuntime)'
git diff --check
* Automate diagnostics D1 migration before worker deploy
Problem:
The diagnostics-v2 schema had to be applied manually even though the production Cloudflare credential is available only to Actions. Deploying the new Worker first would make ingestion depend on missing D1 columns and tables.
Root cause:
The crash Worker workflow validated and deployed code but had no guarded database migration stage.
Fix:
Add a fail-closed schema inspector that skips a complete migration, applies the SQL only when entirely absent, rejects partial state, records the current D1 Time Travel bookmark, and verifies the final schema. Run it after tests and before Worker deployment.
Verification:
- npm test (96 tests)
- npm run typecheck
- node --check scripts/apply-diagnostics-v2.mjs
- bash scripts/release-workflows.test.sh
- actionlint v1.7.7
- git diff --check
* Keep diagnostics copy within locale bundle budget
Problem:
Merging the latest main-v2 bundle ratchets made the expanded Chinese telemetry disclosure exceed both locale budgets.
Root cause:
The cross-platform disclosure repeated verbose phrases for the anonymous identifier, runtime fields, abnormal-exit payload, and privacy exclusions.
Fix:
Compact the Simplified and Traditional Chinese copy while preserving upload timing, diagnostic dimensions, and excluded sensitive data. Keep the existing bundle budgets unchanged.
Verification:
- cd desktop/frontend && pnpm build
- node scripts/check-bundle-budget.mjs
- git diff --check
Problem:
- Email verification links landed on the static site instead of the accounts worker.
- Community responses exposed stored author emails, unverified users could affect moderation, and several account/community controls were incomplete.
- Related multi-statement writes and handle updates could leave partial or racy state.
Root cause:
- The frontend origin was reused as the verification endpoint origin.
- Public forum queries serialized internal identity columns and interaction routes did not share the verified-member gate.
- Forum writes used separate auto-commit statements and profile handles used a check-then-update sequence.
Fix:
- Add a canonical account worker origin, public profile and resend-verification UI.
- Return public handles, gate and rate-limit interactions, implement idempotent likes, and map validation failures to client errors.
- Use D1 transactional batches for related forum writes and atomically claim profile handles.
- Run focused tests and type checks before worker deployments.
Verification:
- accounts: 3 tests, TypeScript check, Wrangler dry-run
- forum: 4 tests, TypeScript check, Wrangler dry-run
- site: 55 tests, Astro build with 42 generated pages
Problem:
Dependabot reports 24 open alerts across the frontend and Worker lockfiles for vulnerable Hono, Undici, and PostCSS versions.
Root cause:
The Hono manifests allowed an affected release, while Miniflare and jsdom still pin Undici 7.28.0 transitively. The crash-report Vite tree also retained an affected PostCSS release.
Fix:
Raise the Hono security floor, pin Undici 7.29.0 through package-manager-native overrides, pin PostCSS 8.5.23 for crash-report, and regenerate all affected lockfiles.
Verification:
- pnpm/npm audit in all four projects
- Worker TypeScript checks
- crash-report Vitest suite (83 tests)
- desktop frontend production build and bundle budgets
- Wrangler dry-run builds for all three Workers
Two hardening fixes from the security triage:
- accounts worker: build email verification links from the configured
APP_ORIGIN instead of the request origin — the Host header is
caller-controlled, so a request-derived origin could point emailed links
at an attacker-chosen host. Tokens are now URL-encoded too. (#5550)
- subagent store: session lineage walks (sessionAncestors,
isAncestorSession) now route every session id — caller-provided and
read back from branch metadata — through parentSessionPath's
bare-filename validation instead of joining paths directly, so a
"../"-shaped id can no longer escape the session directory. (#5551)
Problem:
Recent hang telemetry mixed lifetime diagnostic counts with selected time windows, allowed synthetic versions to become the release baseline, and lacked enough context to distinguish WebView2 failures from UI measurement or sleep/resume artifacts.
Root cause:
Diagnostic group queries ignored the dashboard window, long code viewers fed virtual-row measurements back through React, the watchdog retained a pre-sleep heartbeat, and WebView2 failures were queued without per-session throttling or runtime attribution.
Fix:
Apply diagnostic window filters and stable release quorum rules, show deduplicated affected installs, use direct DOM virtualizer updates, reset the watchdog after sleep, tier heap reports, and add throttled WebView2 reports with runtime and occurrence context.
Verification:
Desktop Go tests, frontend focused tests and typecheck, crash-report worker tests and typecheck, and Windows amd64 cross-compilation passed.
With the rollup from #7279 populated, the 30-day view is the fast one: reading
it off metric_user_rollup measures 68ms against production, versus 5,667ms for
the live 7-day query it was defaulted to in #7271. Leaving the default at 7 days
now means defaulting everyone to the slower path and the less representative
window.
That also retires windowExplicit. It existed to stop a module default from
following the reader into other modules; with no module default left it is
always equivalent to windowDays === 7, so it is dead weight.
A precomputed window can go stale silently if the rollup cron stops, so the
panel heading now carries the oldest computed_at across the rollup — the cursor
refreshes a slice at a time, so that is how far behind the least recently
recomputed signal is.
Closes#7272.
The preferences module's 30-day COUNT(DISTINCT install_id) spans ~28M rows of
metric_users and D1 abandons it mid-query, so #7271 pinned the module to the
7-day window it can still finish. This computes the 30-day answer ahead of time
instead.
It has to be computed, not derived: a cross-day COUNT(DISTINCT) cannot be summed
from per-day totals, because an install active on twelve days would count twelve
times. Benchmarks ruled out the alternatives — storing one JSON row per install
per day and expanding it with json_each took 103s at production shape, worse
than what we have, because parsing JSON per row costs more than the I/O it
saves.
What does work is the query split by signal: measured against production, one
signal over the 30-day window is ~1s. An hourly cron walks the signal list eight
at a time behind a cursor, so a run stays well inside its CPU budget and a full
pass takes about seven hours. Each signal's rows are replaced in a single batch,
so a reader never observes one half-written, and a signal whose query is
abandoned still advances the cursor rather than blocking every signal behind it.
The dashboard reads the rollup for the 30-day desktop window and keeps querying
live everywhere else. Until the first pass completes the panel says the
precompute has not reached every signal yet, rather than showing an empty one.
Both tables are created at runtime, matching how ingest_sentinel_state and the
cli_* tables bootstrap, so no manual migration is needed.
metric_users takes ~1M rows a day, so its 30-day COUNT(DISTINCT install_id)
now spans ~28M rows and D1 gives up on it — measured against production, the
query comes back as a CPU-limit reset. Dropping the window-scan index in
#7258 fixed the tables around it but could not fix this one: the 7-day window
completes in 5.7s over 6.9M rows, the 30-day one does not complete at all.
So the module now defaults to 7 days. An explicitly chosen 30d still runs,
and when it fails it says so: metricUserRows returns null for did-not-complete
rather than folding it into the empty array, which the dashboard was rendering
as its no-metrics-yet state — a timeout reading as nobody using these settings.
A module default must not leak, so windowExplicit tracks whether the reader
picked the window; only a chosen 7d is carried into the other modules' links.
This is a stopgap. The real fix is pre-aggregation, which needs its own
design: a cross-day COUNT(DISTINCT) cannot be summed from daily rollups.
#7258 dropped the three desktop indexes that cost the dashboard its window
prune, but missed their cli_ mirrors — and those are worse than a stale
migration: ensureCLITelemetrySchema issues the CREATE INDEX statements on
every cold start, so dropping them in D1 only lasts until the next CLI
request. Production still had all six.
The cli_ tables carry the same primary keys as their desktop counterparts,
so they lose the same way. Remove the CREATE INDEX statements from both the
runtime schema and migrate-client-surface.sql, and extend the drop migration
to cover all six.
The migration is now ordered against a deploy: it must run after a worker
that no longer recreates them.
* perf(crash-worker): drop the window-scan indexes the dashboard loses to
Every dashboard aggregate is `WHERE date >= ... GROUP BY <other columns>`,
and each table's primary key already starts with `date`. Offering SQLite a
second index on the GROUP BY columns makes it prefer an ordered full-index
scan, which skips the window prune and reads every retained row back through
the table. The same query shape with a `date <` upper bound already picks the
primary key, which is why the previous-window delta was never slow.
Measured on seeded copies, 65 days retained against the 30-day window:
metric_users 5.3M rows 31.6s -> 3.3s
metrics 180k rows 807ms -> 88ms
pings 568k rows 672ms -> 459ms
No query filters these tables by the dropped columns, so this also takes
their maintenance cost off the ingest path.
* perf(site): bake contributor avatars as 128px webp
The prebuild wrote whatever GitHub handed back straight to `<login>.png`.
Of the 98 baked files, 58 were actually JPEG behind a .png name, 19 came
back at 420x420 despite the ?s= hint, and the heaviest 120x120 avatar was
76 KB. The homepage renders all 98 at 60 CSS px.
Re-encode through sharp at twice the largest rendered size instead of
trusting the response. Avatars 823 KB -> 252 KB; the homepage drops from
842 KB to 371 KB, still 103 requests but a little over half the bytes.
sharp was already resolved in the lockfile as an astro dependency; it is
promoted to a direct devDependency so the prebuild does not rely on hoisting.
* complete stable and preview channel loop
* fix(site): harden release-channel fallbacks and version scopes
Problem:
Website CLI Stable fallbacks pointed at GitHub releases/latest asset
URLs, incomplete GitHub releases were turned into 404 download links,
and Desktop/CLI Stable races overwrote every .rxv version chip.
Root cause:
CLI releases set make_latest:false so Latest belongs to Desktop Stable;
releaseAssetMap synthesized missing CLI assets; updateStableVersion was
shared across both product surfaces.
Fix:
- CLI fallback always uses the releases page, never /releases/latest.
- Require all 7 CLI assets before accepting a release (match Worker).
- Scope package-manager .rxv updates to CLI Stable only; desktop
version chips use data-release-version="desktop".
Verification:
node --test site/src/scripts/release-channels.test.mjs
site/src/scripts/download-link.test.mjs
* fix(desktop): unify update channel controls
Problem: The desktop settings page separated channel selection, update status, and install actions across detached rows.
Root cause: The channel picker and updater state machine were rendered as independent controls, so switching channels did not read as one actionable workflow.
Fix: Merge current version/status, Stable and Preview selection, manual refresh, auto-check guidance, and state-specific download/install actions into one compact settings flow. Add the localized channel auto-check hint for English, Simplified Chinese, and Traditional Chinese.
Verification: pnpm --dir desktop/frontend run typecheck; pnpm --dir desktop/frontend run check:css; pnpm --dir desktop/frontend run test:updater (18 passed); pnpm --dir desktop/frontend run build; git diff --cached --check.
* feat(cli): persist release channel selection
Problem:
CLI users had to repeat the verbose --channel flag, and a plain upgrade always returned to Stable instead of following the user's selected public channel.
Root cause:
The native updater had no user-global channel preference, while the website and docs exposed only one-off flag syntax.
Fix:
Add a user-global [cli].update_channel setting, support upgrade stable|preview as persistent switches, retain --channel as a one-off compatibility override, reject conflicting arguments, and synchronize English/Chinese docs plus website commands.
Verification:
- env -u DEEPSEEK_API_KEY GOCACHE=/private/tmp/reasonix-go-cache go test ./...
- env GOCACHE=/private/tmp/reasonix-go-cache go vet ./internal/cli ./internal/config
- npm test (site)
- npm run build (site)
- git diff --check
* fix(release): keep CLI channel pointers monotonic
Problem: Older Stable recovery runs and out-of-order Preview publishers could overwrite a newer public CLI channel pointer.
Root cause: The release workflow wrote cli/<channel>/latest.json unconditionally and had no channel-scoped serialization or strict version comparison.
Fix: Serialize CLI releases by channel, publish immutable per-tag metadata first, validate the current pointer, and move it only when a strict Stable or Preview version tuple is newer.
Verification: bash scripts/release-workflows.test.sh; bash -n scripts/compare-cli-release-tags.sh scripts/release-workflows.test.sh; git diff --check.
* fix(config): preserve symlinked config files
Problem: Persisting the selected CLI update channel could replace a symlinked user config with a regular file.
Root cause: AtomicWriteFile renamed a temporary file over the symlink path instead of the symlink's final target.
Fix: Resolve complete config symlink chains before atomic writes and route both incremental saves and Config.WriteFile through the shared helper.
Verification: go test ./internal/config; focused writable-target and multi-level symlink regression tests; go test ./...; go vet ./internal/cli ./internal/config.
* fix(release): harden stable and preview end-to-end
Problem:
The Stable/Preview loop still allowed stale or cross-channel release pointers, unsafe Desktop release origins and retries, updater events detached from their checked target, and concurrent config writers that could lose user changes.
Root cause:
Release publication lacked one immutable candidate and strict manifest/recovery contracts; Desktop operations were not bound to request, channel, and version; config locks followed logical paths and several writers loaded stale or malformed snapshots.
Fix:
- authorize Desktop candidates from protected main-v2, separate the current control plane from recovered source commits, validate immutable assets, and make GitHub/R2 publication monotonic and resumable
- bind Desktop checks, downloads, verification, and installs to one request/channel/version state machine with strict size and manifest validation
- validate CLI, Desktop, website, and Worker release data consistently across Stable and Preview
- canonicalize and pin config targets, serialize all affected writers, preserve safe symlinks, and fail closed on malformed configuration
Verification:
- go test -race ./...; go vet ./...; go build ./...
- cd desktop && go test -race ./... && go vet ./... && go build ./...
- frontend typecheck, updater tests (31), CSS checks, and production build
- site tests (44) and production build
- Worker typecheck and tests (74)
- release workflow contracts, actionlint, cache guard, shell syntax, diff check, and Linux/Windows cross-builds
Co-authored-by: ffff2004 <[email protected]>
* fix(config): remove obsolete edit wrappers
Problem:
The release-channel hardening left two private config edit wrappers unreachable, causing the pinned golangci-lint unused check to fail.
Root cause:
Callers now resolve and pin final config targets through the transactional edit path, but the superseded convenience wrappers remained in place.
Fix:
Remove only the two unreferenced wrappers while preserving the resolved-target and timeout helpers used by production code and concurrency tests.
Verification:
- go test ./internal/config
- go vet ./...
- golangci-lint v2.12.2 run --timeout=5m
- git diff --check
* fix(release): satisfy workflow shell lint
Problem:
The final CI lint job passed golangci-lint but failed actionlint because the CLI metadata publisher assigned expected_prerelease without reading it.
Root cause:
Prerelease validation moved into validate-cli-release-manifest.sh, leaving duplicate channel-specific shell assignments in the workflow.
Fix:
Remove the unused assignments and keep prerelease validation centralized in the manifest validator.
Verification:
- actionlint v1.7.7 on all release workflows
- bash scripts/release-workflows.test.sh
- bash -n on release helper scripts
- git diff --check
* fix(release): close desktop channel blockers
Problem:
Desktop Preview-to-Stable switches failed for older Debian Stable builds, updater Wails methods broke older one-argument callers, and config edit locks could split across TMPDIR or macOS case aliases.
Root cause:
The privileged helper rejected every downgrade, strict request binding reused legacy exported method names, and lock identity depended on process-local temp directories without Darwin path folding.
Fix:
Allow only signed public Preview-to-Stable Debian downgrades, preserve legacy updater methods beside strict request-bound APIs, and use a stable hardened per-user lock registry with Darwin alias normalization.
Verification:
Root and Desktop tests, Desktop race, Go vet/build, updater 31/31, site 44/44, Worker 74/74, release workflow contracts, cache guard, actionlint, golangci-lint, frontend typecheck/CSS/build, and focused cross-process/security regressions.
---------
Co-authored-by: ffff2004 <[email protected]>
* feat(cli): add privacy-preserving telemetry and crash reports
Summary:
- add bounded CLI usage metrics with explicit policy controls and silent retry behavior
- capture sanitized panic reports locally and require user confirmation before upload
- separate Desktop and CLI aggregates in the crash-report worker and stats dashboard
- document telemetry fields, privacy guarantees, report commands, and D1 migration requirements
Compatibility:
- default missing client surfaces to Desktop for existing clients and payloads
- migrate existing aggregate rows to the Desktop surface before deploying the new worker
Verification:
- go test ./internal/telemetry ./internal/crashreport ./internal/config ./internal/cli ./cmd/reasonix
- env -u DEEPSEEK_API_KEY go test ./...
- pnpm test (workers/crash-report, 49 tests)
- pnpm run typecheck (workers/crash-report)
- ./scripts/cache-guard.sh
* fix(stats): decouple CLI schema migration from Worker deploy
Problem:
The initial surface migration rebuilt the existing Desktop telemetry tables and changed their primary keys. Running it before the new Worker broke the released Worker's ON CONFLICT clauses, while deploying the Worker first queried columns that did not exist yet.
Root cause:
Desktop and CLI isolation was implemented by changing a shared persisted schema, which made the old and new Worker contracts mutually exclusive during rollout.
Fix:
Keep the released Desktop tables and primary keys unchanged, route CLI telemetry to additive cli_* tables, and let the new Worker initialize those tables with idempotent CREATE IF NOT EXISTS statements. Keep the migration additive and identical to the runtime bootstrap so migration, deployment, and rollback order no longer affect Desktop ingestion.
Verification:
- pnpm test (workers/crash-report, 54 tests)
- pnpm run typecheck (workers/crash-report)
- git diff --check
* fix(test): make crash report mode check portable
Problem:
The Windows CI job failed because os.FileMode reports synthesized POSIX bits on Windows rather than the 0600 mode requested by AtomicWriteFile.
Root cause:
The test treated Unix permission bits as a cross-platform ACL signal even though Windows enforces file access through inherited ACLs.
Fix:
Keep the 0600 assertion on Unix-like systems and skip only that non-portable mode-bit comparison on Windows while retaining all report creation, sanitization, and bounded-retention checks.
Verification:
- go test ./internal/crashreport
- GOOS=windows GOARCH=amd64 go test -c ./internal/crashreport
* fix(cli): preserve actionable crash report groups
Problem:
CLI panic reports used runtime/debug.Stack as their top frame, so unrelated panics collapsed into one fingerprint. Queue pruning also deleted reports written in an unknown future format.
Root cause:
Top-frame extraction selected the first source location without filtering capture/runtime frames, and pruning treated every JSON file as a current report.
Fix:
Select the first application frame with its sanitized function name, retain a safe fallback, and prune only recognized current-schema report files. Reject newer schemas from old-client listing so their fields remain untouched.
Verification:
- env -u DEEPSEEK_API_KEY go test ./...
- go test -race ./internal/crashreport ./cmd/reasonix
- go vet ./...
- pnpm test (workers/crash-report, 54 tests)
- pnpm run typecheck (workers/crash-report)
- Windows cross-compile of internal/crashreport
* fix(cli): request consent before telemetry upload
Problem:
A fresh release-build interactive CLI treated a missing telemetry setting as auto and could start anonymous uploads without first informing the user.
Root cause:
The runtime default and persisted decision state were conflated, and telemetry startup had no consent owner before the reporter launched its background flush.
Fix:
Preserve a missing cli_metrics field as an undecided state, show a localized one-time [Y/n] disclosure before the first eligible upload, persist auto or off before continuing, clean pending counters on rejection, and fail closed when saving fails. Keep CI, Safe Mode, development, environment opt-outs, and non-interactive sessions silent and disabled until a decision exists.
Verification:
- env -u DEEPSEEK_API_KEY go test ./...
- go test -race ./internal/telemetry ./internal/cli
- go vet ./...
- pnpm test (workers/crash-report, 54 tests)
- pnpm run typecheck (workers/crash-report)
- ./scripts/cache-guard.sh
- git diff --check
Context:
Reasonix needed one public Stable/Preview contract across native CLI archives and Desktop updates while keeping npm prerelease tags independent.
Changes:
- Add protected native CLI Preview prereleases without moving Homebrew or GitHub Latest.
- Add persistent Desktop Stable/Preview selection, channel-aware update state, R2 pointers, and legacy Canary compatibility.
- Preserve the complete production Windows payload and installer signing chain and fail closed when signing or Preview R2 prerequisites are unavailable.
- Add release gateway routing, workflow contracts, compatibility coverage, and bilingual settings copy.
Compatibility:
Missing and unknown Desktop channel settings remain Stable. Legacy canary, beta, and next settings normalize to Preview. New Preview clients reject stale test-signed Canary manifests while older clients retain the mirrored canary pointer.
Verification:
Root and Desktop Go suites, frontend test:all and production build, crash-report Worker typecheck and 45 tests, release workflow contracts, cache guard, release notes tests, six native CLI target builds, CodeQL, race, and Windows NSIS/portable CI all pass on head 97623c982.
Problem:
The repository had twelve open Dependabot alerts across the site, desktop frontend, and Cloudflare Worker development toolchains.
Root cause:
Direct dependency ranges and generated lockfiles still resolved vulnerable releases of Astro, PostCSS, sharp/libvips, SVGO, DOMPurify, and js-yaml.
Fix:
Upgrade the site to Astro 7.1.3, refresh the affected frontend transitive dependencies, and move all Worker projects to Wrangler 4.114.0 with compatible workers-types 5.x releases.
Verification:
- Site tests and Astro static production build
- Desktop TypeScript check, Mermaid sanitizer tests, and Vite production build
- Worker TypeScript checks and Wrangler deployment dry-runs
- Crash-report Worker test suite
* feat(desktop): add native crash diagnostics
Problem:
Windows users could report that the desktop closed and would not reopen, but native process exits, UI-thread stalls, WebView2 failures, and window-restore hangs left too little durable evidence for analysis.
Root cause:
The desktop only persisted panics from explicitly wrapped goroutines in one overwrite-prone file. Startup tracking stopped distinguishing a healthy process that later vanished, and Windows native/WebView2/window-restore failure paths were not connected to the diagnostic pipeline.
Fix:
Capture Go runtime fatal output, retain a bounded backward-compatible report queue, heartbeat startup lifecycle state, and attribute abnormal exits to coarse uptime, install, and update buckets. Add a Windows Wails-window watchdog, WebView2 process-failure classification, and durable window-restore journaling. Extend aggregate metric ingestion and the health dashboard, while redacting panic values, secrets, and personal path segments and documenting the telemetry behavior.
Verification:
- cd desktop && go test ./...
- cd desktop && go test -race . -run focused crash queue tests
- go test -race ./internal/repair -run TestStartupTracker
- Windows amd64 cross-compile of the desktop test binary
- desktop frontend typecheck, focused settings tests, and production build
- crash-report worker: 42 tests and TypeScript typecheck
- git diff --check
* test(desktop): make hang assertions platform-aware
Problem: Windows desktop CI expected macOS crash labels and metric buckets even though the watchdog correctly emits Windows-specific diagnostics.\n\nFix: derive the expected label, error type, and metric bucket from the same platform identity helpers used by the implementation.\n\nVerification: targeted macOS tests pass; Windows amd64 test binary cross-compiles successfully.
* fix(desktop): remove crash watchdog stalls
Problem: the Windows UI watchdog allocated a permanent syscall callback on every one-second heartbeat, and the window-restore journal used a crash-safe fsync/retry path immediately before showing the window.
Root cause: Windows callbacks cannot be released and the Go runtime has a finite callback table; AtomicWriteFile can also wait on antivirus-held rename locks.
Fix: register one serialized EnumWindows callback for the process, keep the restore journal best-effort without fsync/retry, and add long-run Windows plus journal regression coverage.
Verification: go test ./... (desktop); targeted race tests; go vet ./...; Windows amd64 cross-compile; cache guard.
* fix(desktop): make crash diagnostics process-safe
Problem:
Window restore diagnostics recorded success after Wails only queued UI-thread work, and routine duplicate launches shared the primary process's fatal-output file.
Root cause:
The restore timeout watched the WindowShow call instead of native window state, while fatal output used one process-global path before Wails enforced its single-instance lock.
Fix:
Wait asynchronously for the Windows window to become visible and non-minimised, fence superseded restore attempts, and retain the journal until a real acknowledgement. Store fatal output and structured-panic markers per PID, process only dead owners, and keep backward-compatible legacy dump ingestion.
Verification:
- cd desktop && go test ./...
- cd desktop && go test -race .
- cd desktop && go vet ./...
- Windows amd64 desktop test cross-compile
- ./scripts/cache-guard.sh
- git diff --check
* fix(desktop): support authorized Debian package updates
Problem:
Ubuntu users who installed the desktop .deb could not update in app because the updater could not replace root-owned system files.
Root cause:
Linux installs were treated uniformly as writable portable layouts, and the release manifest exposed only the tarball updater artifact.
Fix:
Detect dpkg-owned installs, publish signed native .deb metadata, and install upgrades through a packaged Polkit helper that re-verifies ownership, signatures, package identity, architecture, and version before delegating to apt. Preserve the portable tarball path and add user-facing progress, metrics, tests, and recovery documentation.
Verification:
- cd desktop && go test ./...
- cd desktop && go vet ./...
- pnpm --dir desktop/frontend test:typecheck
- pnpm --dir desktop/frontend test:updater
- pnpm --dir workers/crash-report typecheck
- pnpm --dir workers/crash-report test
- Linux amd64 helper test binary cross-compilation
- git diff --check
* fix(desktop): recover from updater mode changes
Problem:
The desktop CI failed on two unused updater helpers, and the UI could remain stuck in downloading or authorizing when install mode or manifest availability changed between updater steps.
Root cause:
The backend opened the manual download page and returned nil after reclassification, while the frontend treated nil as an in-flight operation with no terminal state. Two obsolete helper functions also remained after the refactor.
Fix:
Return and emit a typed manual-update error before opening the download page, preserve the manual fallback action in the shared updater state, add authorization/install/cancellation/reclassification coverage, and remove the unused functions.
Verification:
- cd desktop && go test ./...
- cd desktop && go vet ./...
- pnpm --dir desktop/frontend test:typecheck
- pnpm --dir desktop/frontend test:updater
- pnpm --dir desktop/frontend build
- pnpm --dir workers/crash-report typecheck
- pnpm --dir workers/crash-report test
- Linux amd64 update-helper test binary and production build
- git diff --check
* Fix Linux package smoke checks under pipefail
Problem:
Linux .deb contract smoke checks could fail on valid packages when the producer emitted more data after grep found its match.
Root cause:
The build script combined set -o pipefail with grep -q. Early grep exit could close the pipe and make dpkg-deb terminate with SIGPIPE, turning a successful contract match into a failed pipeline.
Fix:
Consume the complete dpkg-deb output with non-quiet grep redirected to /dev/null, and add a packaging guard that rejects the unsafe early-exit patterns.
Verification:
- cd desktop && go test ./...
- cd desktop && go test -run TestDesktopPackagesPreserveNativePlatformLaunchers -count=1 .
- pnpm --dir desktop/frontend test:updater
- bash -n scripts/desktop-build.sh
- git diff --check
* fix(registry): re-review publisher updates
Problem:
Publishers could replace the source, manifest, or metadata of an active package while it stayed live and retained its verified badge.
Root cause:
Registry moderation was triggered only when the public package kind changed, although every accepted republish creates a new immutable package version.
Fix:
Return every non-admin package update to pending review, clear verification, and cover active, hidden, rejected, and trusted-admin update paths.
Verification:
- workers/crash-report: npm test (35 passed)
- workers/crash-report: npm run typecheck
- git diff --check
* fix(registry): fence approvals to reviewed revision
Problem:
A stale moderation page could approve a package version submitted after the reviewer loaded the queue.
Root cause:
Approval requests carried only the slug and action, while both admin backends performed unconditional status updates.
Fix:
Bind approvals to the reviewed version, update timestamp, and status with one atomic D1 conditional update. Stale or old-page requests now fail closed across both admin interfaces.
Verification:
- worker tests: 41 passed
- worker typecheck
- site tests: 26 passed
- site production build
- git diff --check
* feat(registry): support plugin submissions
Problem:
The community registry exposed only skill and MCP package kinds even though the installer already supports plugin packages.
Root cause:
Plugin was absent from the site form, query and publish schemas, shared package types, and republish persistence.
Fix:
Add plugin as a first-class registry kind, require installable GitHub plugin sources, persist kind changes on republish, and expose plugin filtering and guidance in the site and moderation UI.
Verification:
- npm test (workers/crash-report)
- npm run typecheck (workers/crash-report)
- npm test (site)
- npm run build (site)
- Browser verification at /skills/
* fix(registry): re-review package reclassifications
Problem:
Package owners could reclassify an active or verified package as a plugin without returning it to moderation, and the publish API accepted plugin installers hidden behind skill or MCP kinds.
Root cause:
Republish persisted kind without coupling the change to status and verification, while validation only checked installer mismatches when kind itself was plugin.
Fix:
Return publisher-initiated active kind changes to pending, clear verification on every non-admin kind change, and require explicit installer kinds to match the public package kind.
Verification:
- npm test (workers/crash-report): 29 passed
- npm run typecheck (workers/crash-report)
- git diff --check
* fix(registry): disclose compatible plugin formats
Problem:
The registry publish form and API error claimed plugin submissions required a Reasonix-native manifest, even though the installer also accepts Codex and Claude plugin packages.
Root cause:
The submission guidance was written for the first native manifest path and was not updated when compatibility parsers and Claude marketplace support were added.
Fix:
List the native, Codex, Claude, and supported Claude marketplace manifests in both the form guidance and server validation error, with contract tests covering every format.
Verification:
- worker test suite: 30 tests passed
- worker TypeScript typecheck passed
- site test suite: 24 tests passed
- Astro production build passed
- git diff --check passed
* fix(registry): pin installs to declared package kind
Problem:
- Registry skill and MCP submissions could retain installKind=auto, while copied install requests omitted the declared kind.
Root cause:
- Only plugin submissions normalized auto, and the API echoed legacy installer values independently of the public package kind.
Fix:
- Normalize every submission and API response to the declared kind, and preserve that kind in publish and copy flows.
Verification:
- workers/crash-report: npm test; npm run typecheck
- site: npm test; npm run build
- git diff --check
* fix(registry): harden plugin source validation
Problem:
Plugin submissions could preserve control characters in copied install prompts, and non-canonical GitHub URLs could select paths outside the cloned repository.
Root cause:
The registry accepted any GitHub URL with two path segments while the Go installer ignored unsupported URL tails and joined tree paths without a containment check.
Fix:
Reject unsafe source characters and non-repository GitHub shapes, make the shared Go parser fail closed, and verify selected plugin roots remain inside the resolved clone.
Verification:
go test ./internal/installsource
env -u DEEPSEEK_API_KEY go test ./...
go vet ./...
npm test && npm run typecheck (workers/crash-report)
npm test && npm run build (site)
* fix: retire automatic Plan Mode
Problem:
Automatic Plan Mode created two different planning experiences, and users who had enabled it kept silently entering Plan Mode after the setting was removed.
Root cause:
The preference was persisted across TOML, desktop, CLI, controller, and classifier paths without a retirement migration or a single explicit-mode contract.
Fix:
Remove the setting and automatic classifier/runtime paths, migrate pre-v5 configs to manual-only behavior, retain safe read compatibility for old TOML and Wails clients, and update docs and metrics.
Verification:
- go test ./internal/config ./internal/control ./internal/boot ./internal/cli
- cd desktop && go test ./...
- pnpm build and pnpm test:typecheck in desktop/frontend
- settings-refresh-snapshot.test.tsx: 43 passed
- ./scripts/cache-guard.sh
- real-browser settings inspection with a clean console
* fix: remove obsolete desktop test helper
Problem:
The Linux desktop CI job failed golangci-lint after the Automatic Plan tests were removed.
Root cause:
A test-only turn runner and its context import were left behind without any remaining callers.
Fix:
Remove the obsolete helper and unused import.
Verification:
- cd desktop && go vet ./...
- cd desktop && go test ./...
* fix: preserve retired auto-plan compatibility
Problem:
Released desktop clients still submit the settings_auto_plan metric, and existing shell automation may still query or disable automatic Plan Mode.
Root cause:
The retirement removed both the worker enum value and the shell command, causing legacy metric batches to fail validation and safe compatibility commands to exit with an error.
Fix:
Keep settings_auto_plan as an input-only legacy metric signal, and retain a hidden config auto-plan shim that reports off, accepts off as a no-op, and rejects enable attempts. Add focused regressions for both contracts.
Verification:
- env -u DEEPSEEK_API_KEY go test ./internal/config ./internal/cli
- npm test in workers/crash-report
- npm run typecheck in workers/crash-report
- ./scripts/cache-guard.sh
- git diff --check
* fix: ignore unknown crash-report metrics
Problem:
A retired or future metric signal could invalidate an otherwise useful metrics batch, while a dedicated legacy allowlist only handled one historical signal.
Root cause:
The worker validated every counter signal with a strict enum before processing the batch.
Fix:
Keep strict validation for known counters, discard bounded unknown signals before storage, and treat an all-unknown batch as a successful no-op.
Verification:
- npm test (workers/crash-report)
- npm run typecheck (workers/crash-report)
- go test ./internal/cli -run TestConfigAutoPlanCompatibilityCommand|TestConfigLoadIgnoresRetiredAutoPlan -count=1
* fix: harden crash diagnostics and runtime failures
Problem:
Crash telemetry mixed actionable release failures with browser notices, development reports, and isolated timer spikes. Several recurring desktop crashes remained in virtualized React lists, Mermaid pan/zoom, legacy WebKit, and concurrent secret redaction.
Root cause:
Virtualizer measurement updates could re-enter React commits, svg-pan-zoom inverted singular matrices before layout stabilized, react-markdown assumed Object.hasOwn, and the key/value redactor relied on a complex regexp replacement path. Opaque Script errors also lacked safe grouping context.
Fix:
Separate diagnostic lanes and effective severities, preserve legacy fingerprints while adding optional safe hints, require sustained or corroborated lag, use direct DOM virtualizer updates, guard Mermaid layout synchronization, polyfill Object.hasOwn, and replace the backtracking redactor with a linear scanner.
Verification:
go test ./...
go vet ./...
go test -race ./internal/secrets
(cd desktop && go test ./...)
(cd desktop/frontend && pnpm test:all && pnpm build)
(cd workers/crash-report && npm test -- --run && npm run typecheck)
* fix: isolate development crash groups
Problem:
Development and stable reports shared one fingerprint, so a low-severity development observation could hide an actionable release crash.
Root cause:
The fingerprint omitted the report environment while the group upsert persisted low severity and dashboard classification trusted the latest version/channel.
Fix:
Keep stable hashes unchanged, namespace development fingerprints with dev:, preserve dashboard routes for both formats, and only reclassify legacy groups when both ends of their history are development builds.
Verification:
- npm test -- --run
- npm run typecheck
- npm exec -- wrangler deploy --dry-run --outdir /tmp/reasonix-pr-6678-worker-dryrun
- git diff --check
* fix: keep ambiguous legacy crash groups actionable
Problem:
Legacy crash groups could contain a stable observation between development reports and still be downgraded as development-only.
Root cause:
The dashboard inferred complete group provenance from first/last version metadata even though sample retention can prune middle release reports.
Fix:
Treat only the explicit dev: fingerprint namespace as proof of a development-only group, keep legacy hashes actionable, and cover dev-release-dev history in regression tests.
Verification:
- npm test -- --run
- npm run typecheck
- npm exec -- wrangler deploy --dry-run --outdir /tmp/reasonix-pr-6678-worker-dryrun
- git diff --check
Control #1 (#6442) accepts any package-name-shaped source, which is right
for kind=mcp (npx -y <pkg>) but wrong for kind=skill: install_source only
reaches the npx-package branch for kind auto/mcp, so a bare name like "123"
published as a skill resolves to an MCP server, not a skill — it slipped
through the syntactic gate. Guard it in PublishSchema so a skill source must
be a SKILL.md URL or a GitHub repo path.
The publish form stored any string as `source`, so submissions like a
free-text "这个来源是自己制作的" reached the review queue only to be
rejected for being uninstallable — install_source can't classify them, so
they were dead on arrival. Mirror install_source's own acceptance
(internal/installsource/names.go: http(s) URL, git:github.com/… shorthand,
or package name) in PublishSchema and refuse anything else — free text or a
publisher-local path — at publish time, with a matching client-side pattern
hint on the form.
Bring the crash worker under test: add vitest + a validation suite and wire
typecheck + test into the deploy step so a bad schema can't ship to
crash.reasonix.io. This is the worker's first test infra.
Setting the sentinel webhook previously required local Cloudflare
credentials (wrangler login / dashboard). The deploy workflow already
holds CLOUDFLARE_API_TOKEN, so mirror the GitHub repo secret into the
worker after each deploy instead; when the repo secret is unset the
step is a no-op and sentinel alerts stay log-only.
The 2026-07-03 D1 size-cap outage went unnoticed for ten days: clients
swallow ping failures by design, ingest handlers surfaced raw worker
exceptions, and nothing watched the write path.
- Wrap the D1 writes in /v1/ping, /v1/metrics and /v1/report so a
storage failure returns a deliberate 503 with a contextual log
instead of an opaque 500 (Cloudflare error 1101).
- Add a sentinel cron (4x/day, hours with guaranteed traffic) that
probes a canary write into pings (removed in the same run) and
today's real ping count, covering both write-path failures and
upstream ingest blackouts. Alerts post to the optional ALERT_WEBHOOK
secret (Feishu/Lark native payload, Slack-style {text} otherwise) and
always land in the worker logs.
The reasonix-crash D1 database grew until it hit the size cap on
2026-07-03; from then on every ingest write (/v1/ping, /v1/metrics,
/v1/report) threw and the /stats dashboard flatlined while reads kept
working. Add a scheduled trigger that deletes time-series rows past the
dashboard's query horizon so the database plateaus:
- pings, metric_users: keep 30 days (queries read at most -29 day)
- metrics: keep 60 days (the 30d view's previous-window delta reads
back to -59 day)
- reports/groups: untouched — triage queue and regression baseline,
growth already bounded by per-group sampling
Deletes run in 10k-row rowid chunks with a per-run backstop so a run
never holds one giant transaction but still drains a large backlog
after an ingest outage.
A skill published with a bare GitHub repo-root source (owner/repo, or a branch
root with no sub-path) silently mass-installs every SKILL.md in the repo: the
installsource planner misses plugin detection for repos that only ship a
.claude-plugin manifest and falls through to a full-repo skill scan.
Validate at publish time — a kind:skill submission whose source resolves to a
whole repo is now rejected with a 422 and guidance to point source at a single
skill (a /tree/<branch>/<path> subtree or a raw SKILL.md URL). MCP kinds and
non-GitHub sources are unaffected.
The community moderation table used the browser's auto table-layout, so the
long summary in the first column starved the meta columns: version/installs/
stars and the submitted date wrapped character-by-character. Switch that table
to table-layout:fixed with explicit column widths (new .reg-table + colgroup)
so no column is squeezed below its content.
Add a per-row "Copy for review" button that copies the whole submission (kind,
source, repo_url, homepage, tags, summary, README) to the clipboard in one
click, reusing the existing [data-copy] handler and .copy-btn feedback. A
reviewer can hand a submission off without hand-copying fields one by one. The
manifest snapshot lives on package_versions (frontmatter only), so source and
repo_url stay the pointers to the actual reviewable content.
Give the owner one admin console instead of a standalone, undeployed
registry worker. The registry source moves under the crash worker as a
second data plane (REGISTRY_DB); its public + publish API is served by
delegating to the folded Hono app, and a server-rendered Community tab
moderates user-published skills/MCP (approve/reject/hide/verify) gated on
the unified dashboard admin role, writing the shared audit log.
Requires a reasonix-registry D1 (schema in registry-schema.sql) before
the auto-deploy runs; the id in wrangler.toml is a placeholder.
Dashboard loads blocked on a fresh id.reasonix.io /me round-trip and ran
all nine aggregation queries regardless of the module shown. Cache the
resolved identity per token hash (60s), fetch only the active module's
data (metric_users COUNT(DISTINCT) now hits only /stats/preferences), and
index the groups/pings/metrics columns the filters and facets scan.
Publishing now requires a verified email; non-admin submissions land as 'pending' and stay out of the listing, detail, and activity feed until an admin approves them. Adds /v1/admin review endpoints (approve / reject / hide / verify) gated on the admin role. Versions of an already-approved package stay live; admins publish straight to active.
dependabot[bot]