Repository navigation
release: 0.19.0 - #257
Merged
Merged
release: 0.19.0#257
Conversation
…ipts run before an install v0.19.1's release stopped at its tag checks: check-browser-runtime-pin.mjs could not load zod, which it had begun importing to parse its upstream answers, because the tag-checks job installed nothing. No pull-request run executes that job, so every check on PR #255 was green. The weekly pin job had the same gap. Both jobs now install the dependencies before the pin check. The new gate scripts/check-workflow-scripts.mjs (npm run check:workflow-scripts, in quality:gates and the hosted static gates) bundles every script a workflow step runs before its job's install with esbuild, every package external, and fails on any package the script or a file it reaches imports. Red on the defect (exit 1, both jobs named with the importing files), green with the fix, red again with the release job's install removed, restored green (docs/certification/cifinal0190.md section 16). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
0.19.1's tag was refused by its own tag checks before anything was built or published (the pin check could not load zod in a job that installed nothing). A tag never moves, so the release ships as 0.19.2: the version, the CHANGELOG section (renamed, with both refused tags under Release infrastructure), the roadmap, PLAN's release records (0.19.1 never published; 0.19.2 preparation) and certification section 16. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…sed release A review of the release jobs after the tag checks (none has run since 0.18.2) against PR #255's real CI artifacts found two faults: - "stage the Linux helper release assets" ran unzip on release/*.vsix, which with seven packages exits 11 before the GitHub Release, and read dist/voiceLinux.js, a loader whose code lives in the runtime archive. The step now reads the voiceLinux.js member of every VSIX's runtime.bundles.json.br (new scripts/runtime-archive-member.mjs) and checks each against the staged helpers. - A release that reused CI artifacts skipped its build and kept no source-tree receipt, so findRecovery refused it. The reuse job now uploads the receipt, and findRecovery accepts a passed reuse job with a skipped build. Proved on this PC: the old step exits 11 on the seven real packages, the new one exits 0 with all seven accepted and exits 1 with one helper byte changed; against the real GitHub API the old findRecovery refuses the reused v0.18.2 release run and the new one accepts it, while still refusing ineligible runs (docs/certification/cifinal0190.md section 17). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3ea631f6bb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
By the owner's order a failed check never moves the version. The two refused tags, v0.19.0 (e48e8c6) and v0.19.1 (ff7c78d), published nothing on any channel and are deleted; 0.19.0 is tagged again on this pull request's merge. The version, the CHANGELOG section, PLAN's 0.19.0 record (the two refused tags folded into it), the roadmap and certification section 18 say 0.19.0 again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RandyNorthrup
changed the title
…est lines Review findings on PR #257: - check-workflow-scripts.mjs read only `node <file>`, so a helper loaded from inline `node -e "import ... from './scripts/...'"` code before an install went unchecked (build.yml, forks.yml, hosts.yml). It now reads inline -e/--eval/-p/--print code: relative imports are followed like a file node runs, and a package import fails on its own. Drills: a package import added to build-vault-peer.mjs fails all three workflows; one added to build.yml's pre-install inline code fails that step; both restored green. - The manifest test lines added for the receipt only counted workflow text; they are removed, and the recovery proof stays the real-API run (docs/certification/cifinal0190.md sections 17 and 19). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both went red on slow hosted Windows runners in code nothing here changed: runnerHelperNative's native job case passed 60 s (about 7 s on this PC), and the schedule background entry case passed the integration runs' 20 s budget twice (PR #255, PR #257; 7 to 11 s warm). Owner's rule (2026-10-16): no limit of ours that is not about a model. The native case, its status poll and its PowerShell probe now wait however long the machine takes; each schedule-entry test is .timeout(0) (mocha copies a suite's timeout into a test as it is added, so it is set on each test). The other suites keep the repository's budget. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
REPORT_SOURCE_TIMEOUT_MS (5 s) abandoned report source reads: on slow Windows CI runners real store reads came back `unavailable`, failing storeProject.test.ts and reportProductionTransport.test.ts at random. Only a provider's documented limit, a value the person set, or the person's own cancel may stop a read, so every deadline use is gone and the constant is deleted. - cache.ts read: the 5 s timer is gone; the caller's signal ends the read, and the controller only stops pages still in flight once it settles. The dispatch's `timedOut` step and admission's `timedOut` event go with it (nothing could raise them); an abort refuses as `source-cancelled` instead of `source-deadline`. - cache.ts rateLimit: a limited answer naming no future instant held the origin for an invented 5 s, refusing every read to it without asking. That stops the product's work on a clock of ours, so it is removed: only the server's own Retry-After, or GitHub's reset at the floor, holds the origin; otherwise the next read asks the server again and its answer says whether it is still limited. - github.ts: `gh api` runs with no deadline (`timeout: Infinity`); the post's 5 s timer is gone, only the caller's signal ends it (`post-cancelled`), and a dispatched post still stays uncertain. - local.ts localSource: no default deadline; one binds only when the caller hands it in (none does in production now), and a non-finite value names none, so nothing arms a timer with undefined or NaN. The deadline race and settle grace move into readBeforeDeadline. - engine.ts: no deadline on the generation's read context; the check journal's `commit` takes the turn's signal (verifyLoop.ts, reportCheckBundle.ts, ModelApiHost.ts), so Stop ends it. - main.ts readSaved, selections.ts, sources.ts reportGitIo, playbookSchedulesInputs.ts: the 5 s abort, the git `timeout` and the lease-wait deadline are gone; the schedules read now waits for the holder's release or the lease's expiry, or the caller's cancel. - commands.ts execResourceFile: `timeout: Infinity` names no deadline, as src/host/git.ts reads it; absent and finite timeouts unchanged. Without it, dropping the git/gh timeouts would have swapped 5 s for the runner's 20 s default. - local.ts sourceFreshness and checkRuns.ts only label `fresh`/`stale` by age; they keep the 5,000 ms figure as REPORT_SOURCE_FRESH_MS, which stops nothing. - reportSourceReasons.cancelled loses "or timed out" in English and the 14 tables; PLAN.md D93's "Timeouts per source" rule is replaced. Tests: playbookSchedulesInputs' "held lease as busy" and "queued reader on its deadline" asserted the removed 5 s deadline; one real held-lease case now proves the read waits past 6 s and reads once the holder lets go. "ends every refresh busy" waited out five deadlines; it now cancels five refreshes by their own signals and checks none acquired the lease. reportEngineCancellation renames its handed-deadline case and retires the admission owner with `aborted`, since `timedOut` is gone. Drills (docs/certification/lim-reports.md): AbortSignal.timeout(1) on the network read turns the two store suites red (exit 1, 7 failed, "(source-cancelled): expected 'unavailable' to be 'ok'"), green once restored (exit 0); a restored lease deadline turns the held-lease case red (exit 1), green once removed (exit 0). scripts/catch-baseline.json: eight sites keep their handlers and classes; their identity hashes moved because nearby code changed. Audited and regenerated; no SWALLOW, GENERIC or CLEANUP count changed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s (D121) Hosted CI failed windowsScreenRecorderNative.test.ts: runProgram's default PROCESS_TABLE_TIMEOUT_MS (20 s) killed Windows PowerShell's cold start (`[Security.Principal.WindowsIdentity]::GetCurrent().User.Value`, killed: true, SIGTERM). Under D121/D208 only a provider's documented limit, a value the person set, a deadline the caller passes, or the person's own cancel may stop work. Every use of the constant as a deadline is gone and the constant is deleted. - runProgram: no default timeout; execFile gets one only from the caller. - runTreeSync (POSIX supervisor): spec.timeout and spawnSync's timeout come only from a positive caller timeout. The supervisor arms its timer only when spec.timeout is a finite positive number: setTimeout(fn, undefined) fires at once and would kill every effect with no caller deadline. spawnSync gets no timeout at all without one. The SIGSTOP/SIGKILL grace (cleanupMs, POSIX_TREE_EXIT_WAIT_MS) is unchanged. - runBootstrap and execResourceFile: callerStop() (core/timeouts.ts) combines only the caller's signal and positive deadline that exist; neither means no stop signal (timeout 0 is none, as with execFile). - Bootstrap taskkill and runTreeProgram: no timeout; boundedTreeProgram's time bound is optional (macRss keeps passing its own). - Windows recorder: after Stop/Cancel the driver waits for the helper's own exit instead of killing it at 20 s. Two paths settled only through that clock and now settle without one: a dead helper channel (send throws) is killed at once, since nothing could ever answer the request; and the person's Cancel, or the window closing, while a stop is already pending kills the helper at once (before, the second request was a no-op and the clock ended it). Internal end requests from helper frames are unchanged. - Vault feeder: termination is awaited itself, no longer raced against a 20 s rejection with vault.noAccess; the sudo -K cleanup run takes the runner's own timeoutMs instead of min(timeoutMs, 20 s). - windowsScreenRecorderNative.test.ts: the two execFileGuarded calls lose their PROCESS_TABLE_TIMEOUT_MS timeout (no limit of ours in tests). No existing test asserted the 20 s deadline, so none was removed. - New test/unit/treeSyncNoDeadline.test.ts (POSIX only): an effect with no caller timeout runs to its end through the real supervisor, /bin/sh and ps; a caller's 300 ms timeout still ends it with ETIMEDOUT. Drilled red under WSL with the supervisor guard removed (record in docs/certification/nolimitsprocs0190.md). - Catch baseline: the four catch sites whose code changed here (two CLEANUP and one GENERIC in record/windows.ts, one CLEANUP in vaultExecSpawn.ts) got new identities; classes and per-area counts are unchanged, so the baseline was regenerated after auditing them. - PLAN.md section 8 SPAWN017B rows and the SPAWN017B follow-up line no longer promise a deadline; CHANGELOG [0.19.0] Fixed entry added. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts: # src/core/resources/commands.ts
…eads The supervisor read the process table, and re-read each identity before a signal, with a 2 s timeout of ours; a slow ps then threw, and the supervisor ended the effect as failed though no caller set a deadline. It now waits for ps, and the spawnSync clock that backed a caller's deadline by 4 s is gone (it could kill the supervisor mid-cleanup and leave the tree running): only the supervisor's own clock, at the caller's deadline, ends a tree. Also: the created-registry sweep's 5,000-file case waits however long it takes (7.5 to 16.2 s on this project's Windows PC against a 15 s budget), the CHANGELOG names the report-read fix, and certification section 20 records PR #257's third run and these changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ck prints its log On Windows the schedule wake test is registered with test.skip, which in mocha's TDD interface returns nothing, so the chained .timeout(0) threw in the integration run (PR #257, CI run 39703467949). The timeout now goes on that test only where it runs. The vault panel flow's toast check named no cause when the first open showed two failure toasts on a hosted Windows runner; it now prints the panel's log with them (certification section 20). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
RandyNorthrup
added a commit
that referenced
this pull request
Oct 22, 2026
… went through PR #258's first run failed in posixVaultPanelFlow on hosted macOS: after Unlock the panel still read "locked" when the step's wait ended, with no toast and no log, in product code that was green on every macOS shard of PR #257. The message now adds how many frames the panel published and its last states, so a repeat shows whether the step ever ran (docs/certification/cifinal0190.md section 22). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 0.19.0 release, tagged again. Two earlier tags stopped at the release's own tag checks before anything was built or published, and both are deleted (owner's order: a failed check never moves the version):
v0.19.0one48e8c6bce: the browser check's runtime pin was more than 14 days behind Stable (renewed in PR Release 0.19.1 #255).v0.19.1onff7c78d7a3:check-browser-runtime-pin.mjscould not loadzod, which it began importing in PR Release 0.19.1 #255, because the tag-checks job installed nothing. No pull-request run executes that job.What changes
npm run check:workflow-scripts(inquality:gatesand the hosted static gates): everynode scripts/...step that runs before its job's install may import Node built-ins only, read through esbuild's metafile. It fails on main's workflows with exactly this defect and passes with the fix.unzip -p release/*.vsixexits 11 with seven packages, anddist/voiceLinux.jsis only a loader. The step now reads each VSIX'svoiceLinux.jsfrom its runtime archive (scripts/runtime-archive-member.mjs) and checks all seven against the staged helpers.findRecoveryaccepts a passed reuse job with a skipped build.[0.19.0](both refused tags under Release infrastructure), PLAN's 0.19.0 record and the roadmap at 0.19.0.Proof
npm run buildexit 0;test/unit/manifest.test.ts40/40.docs/certification/cifinal0190.md§15–§18:findRecoveryagainst the real GitHub API (the reused v0.18.2 run refused, then accepted; ineligible runs still refused).verifyPublishedreads.🤖 Generated with Claude Code