errors.jsonl

{"id":"ERR-001","kind":"info","summary":"skills-ref package exposes agentskills, not skills-ref","context":"Running the Agent Skills reference check as `uvx skills-ref validate ./skills/block-runner` exits 1 because the Python package provides no executable named skills-ref.","remedy":"Run `uvx --from skills-ref agentskills validate ./skills/block-runner`; it validates the canonical bundle successfully.","resolved":true,"resolution":"workaround","resolved_ts":"2026-09-02T06:29:38Z","ts":"2026-09-02T06:29:38Z"}
{"id":"ERR-002","kind":"warning","summary":"Full Vitest can hit Gutenberg boot timeouts during concurrent model benchmarks","context":"A full `npm run verify` test phase timed out nine suites at exactly 30000ms on their first headless Gutenberg call while two live `scripts/bench.ts` Codex arms were running. The same 212-test suite had passed immediately before those benchmark processes started; there were no assertion mismatches.","remedy":"Do not run the full parallel Vitest suite alongside live multi-arm model benchmarks. Leave the benchmark processes alone, wait for them to finish, then rerun `npm run verify`; lightweight typecheck, build, private-reference, package, and focused installer checks can run separately.","resolved":false,"resolution":"recurrent","resolved_ts":null,"ts":"2026-09-02T06:37:00Z"}
{"id":"ERR-003","kind":"warning","summary":"Benchmark model CLIs were launched with write-capable bypass modes","context":"The Codex and Claude benchmark engines ran one model process per fixture from the repository while disabling approval and sandbox protections. The prompts asked models not to use tools, but the process boundary did not enforce that instruction, so a misbehaving cell could mutate the checkout under measurement.","remedy":"All benchmark engines now launch from the operating-system temporary directory. Codex uses a read-only sandbox, ignores user configuration, and does not persist sessions; Claude uses safe, restricted, non-persistent mode without bypass permissions. `test/benchmark.test.ts` locks this launch contract.","resolved":true,"resolution":"permanent","resolved_ts":"2026-09-02T07:12:59Z","ts":"2026-09-02T07:12:59Z"}
{"id":"ERR-002","kind":"warning","summary":"Full Vitest can hit Gutenberg boot timeouts during concurrent model benchmarks","context":"A full `npm run verify` test phase timed out multiple suites together on their first headless Gutenberg call because Vitest booted a heavy Gutenberg runtime independently in parallel workers. The failures occurred before assertions and disappeared when worker contention was removed.","remedy":"`vitest.config.ts` now disables file parallelism, so one Gutenberg runtime boots at a time. The normal `npm run verify` subsequently passed 13 files and 217 tests. Continue to avoid competing with live multi-arm model benchmarks because they add unrelated host load.","resolved":true,"resolution":"permanent","resolved_ts":"2026-09-02T07:22:18Z","ts":"2026-09-02T06:37:00Z"}
{"id":"ERR-004","kind":"error","summary":"Concurrent wp-env commands can erase the active runtime marker","context":"wp-env 11.12.0 rewrites wp-env-cache.json while loading configuration. Running the eight runtime-observation commands in parallel left only latestWordPressVersion in the cache; commands reported Environment not initialized immediately after a successful start.","remedy":"Run wp-env subprocesses sequentially. The integrated proof runner does this, and its follow-up WordPress run completed the same runtime observations successfully. Keep failed-run logs and ZIPs with the receipt; do not parallelize wp-env calls sharing one configuration.","resolved":true,"resolution":"workaround","resolved_ts":"2026-09-04T07:07:35.504Z","ts":"2026-09-04T07:07:35.525Z"}
{"id":"ERR-005","kind":"error","summary":"Standalone lock resolution can fail when a transitive registry version is unavailable","context":"The standalone plugin install/build test failed while resolving its dependency lock with npm ETARGET for @jsonjoy.com/fs-print@4.70.0. The full deterministic run otherwise passed 344 tests with four skips. This is a network-backed packaging check, not a purely offline unit test.","remedy":"Inspect the exact npm failure before rerunning. A subsequent registry lookup found the exact version; rerunning only the failed package test under the npm 11 toolchain passed in 18.25 seconds. Keep the initial failed result and the focused rerun separate. Do not change expected assertions or claim a root-cause fix: the initial registry inconsistency remains unproven, and clean dependency resolution still relies on registry availability.","resolved":true,"resolution":"workaround","resolved_ts":"2026-09-04T08:30:46Z","ts":"2026-09-04T08:30:46Z"}
{"id":"ERR-006","kind":"warning","summary":"wp-scripts inherits test mode when building a release fixture","context":"The production-source ZIP test revealed unminified CSS and source maps. Vitest sets NODE_ENV=test, and wp-scripts 34.2.0 only defaults NODE_ENV to production when it is unset. A successful build under the test runner therefore did not prove production packaging.","remedy":"Force NODE_ENV=production for ZIP builds in the standalone packaging test, WordPress fixture builder, and mutation rebuilds. Explicitly include development dependencies during npm ci because they contain the build toolchain. The packaging test now compiles a canonical plan, checks responsive and editor-only CSS inside the actual ZIP, verifies the bundled image bytes, and rejects source maps. The focused follow-up passed all 45 tests, including the clean install and production ZIP check. Real WordPress proof of the new artifact is still a separate gate.","resolved":true,"resolution":"permanent","resolved_ts":"2026-09-04T09:38:41Z","ts":"2026-09-04T09:38:41Z"}
{"id":"ERR-007","kind":"warning","summary":"Default SVG imports build successfully but break filtered WordPress image saves","context":"wp-scripts 34.2.0 uses SVGR and url-loader for SVGs imported from JavaScript, producing a data:image/svg+xml URL. WordPress 7.1 wp_kses_post strips its data: scheme and esc_url returns an empty value. A production build alone therefore did not prove usable native Image output.","remedy":"The owned compiler emits native SVG URL dependencies in asset-urls.mjs, where webpack emits the original SVG file rather than applying the JavaScript SVG loader. Preview and manifest include the helper; CSS-only SVGs retain normal CSS inlining. Tests inspect the exact SVG bytes and emitted filename in the production ZIP. The real WordPress fixture now includes an SVG: editor save/reopen and frontend decoding passed, as did a separate filtered post save and byte-for-byte HTTP asset check. The full profile still records its unrelated visual/manual-review gaps and upstream editor accessibility findings.","resolved":true,"resolution":"permanent","resolved_ts":"2026-09-04T10:48:00Z","ts":"2026-09-04T10:48:00Z"}
{"id":"ERR-008","kind":"warning","summary":"Production CSS minification removes bundled font license comments","context":"The real wp-scripts 34.2.0 production ZIP test removed the entire /*! font redistribution notice even though source-generation tests passed. A font file reached the archive without its required full notice.","remedy":"The canonical compiler emits font-licenses.txt with full notices and package-relative asset paths. Both standalone and supported existing-plugin profiles plan an explicit postbuild copy into the block build directory; existing hooks and replacement approval are preserved. The production ZIP test now verifies the real WOFF2 bytes and complete retained notice, then adds a second block and verifies both builds without changing the first source. The focused production test passed.","resolved":true,"resolution":"permanent","resolved_ts":"2026-09-04T11:42:00Z","ts":"2026-09-04T11:42:00Z"}
{"id":"ERR-009","kind":"error","summary":"Inherited npm allow-scripts settings can block isolated packaging tests","context":"npm run and npm exec exported a user-level allow-scripts setting as npm_config_allow_scripts. A nested npm install --package-lock-only then failed with EALLOWSCRIPTS because that environment setting is not permitted for project-scoped installs. The full verification test phase passed 460 tests with four skips and failed only this packaging setup.","remedy":"Do not change global npm settings or weaken test assertions. Launch the focused packaging test directly with node node_modules/vitest/vitest.mjs under the pinned npm 11 PATH, outside the npm run/exec environment. That clean-process rerun passed the full production archive and second-block checks in 121.20 seconds. Build, private-reference check, package inspection, and packed consumer checks also passed separately; retain the original failed verify result rather than calling it a single green run.","resolved":true,"resolution":"workaround","resolved_ts":"2026-09-04T11:42:00Z","ts":"2026-09-04T11:42:00Z"}
{"id":"ERR-009","kind":"error","summary":"Inherited npm allow-scripts settings can block isolated packaging tests","context":"npm run and npm exec exported a user-level allow-scripts setting as npm_config_allow_scripts. A nested npm install --package-lock-only then failed with EALLOWSCRIPTS because that environment setting is not permitted for project-scoped installs. The full verification test phase passed 460 tests with four skips and failed only this packaging setup.","remedy":"Generated-plugin npm children now read back only allow-scripts in the same working directory with its environment projections absent. They remove a projected value only when it exactly matches that effective configuration. Explicit different policies and failed probes remain unchanged; no npm configuration is modified. The public writer, fixture builder and mutation ZIP rebuilds share this boundary. Focused lifecycle checks and the full npm run verify passed: 475 tests, four opt-in mutation skips, typecheck, build, private-reference check and package dry run. Earlier failed evidence remains retained.","resolved":true,"resolution":"permanent","resolved_ts":"2026-09-04T12:48:16Z","ts":"2026-09-04T11:42:00Z"}
{"id":"ERR-010","kind":"error","summary":"Local Docker credential helper must be on PATH for wp-env","context":"The native WordPress control could not start because Docker Compose could not find docker-credential-osxkeychain. Docker was installed; its bundled credential helper was absent from the command environment PATH.","remedy":"Verify the installed Docker helper exists and prepend its containing binary directory for the local proof command. Do not inspect credentials, modify Docker authentication, or reset the environment. The rerun then collected both standalone WordPress 7.1 controls successfully. Keep the original startup failure separate from successful control evidence.","resolved":true,"resolution":"workaround","resolved_ts":"2026-09-04T12:48:16Z","ts":"2026-09-04T12:48:16Z"}