Conversation
Keep backend handoff, build orchestration, dev status, and Vite rebuild metadata under the ignored .n-apt runtime directory. Add a shared path module and regression coverage so development state cannot leak into the repository root.
Expose mock-source metadata through the backend and frontend contracts so capture controls can enforce the supported format and encryption rules. Persist completed downloads with retention, improve capture status feedback, and keep geolocation available across capture formats. Include focused frontend and backend coverage plus main-app screenshots for the pull request.
Refresh the generated article page from the updated source, including the Estimated Calories section and the current article copy. Keep the reviewed main-app screenshots available alongside the generated docs for the pull request.
Owner
Author
|
...um thanks GPT! |
Update the compatible Vitest and csv-parse releases and refresh the lockfile. Move the existing security overrides to patched sharp, adm-zip, and toml versions so npm audit reports no remaining advisories.
Initialize the PBKDF2 output buffer through its type default before the derivation fills it. This preserves the existing key derivation contract while removing the all-zero key-shaped literal flagged by CodeQL.
Stamp v5 I/Q and NAPT captures with a SHA-256 digest over the complete file, verify the digest before playback, and surface a deliberate Play anyway path for modified files. Keep legacy formats readable, update the Rust and WebUSB writers together, and cover stamping, tamper detection, and format behavior with focused tests.
ceane
changed the title
Navigation and pan bounds fell back to the active channel whenever the device range had not hydrated, pinning scrolling inside the selected channel. Fall back to the global spectrum bounds instead. HackRF live retune stopped and restarted the native RX stream on every VFO tick, which stalled scrolling. Retune in place and drain the stale queue instead, and publish live pan updates once per display frame rather than on a 50 ms / 20 Hz cadence. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
The store's live acquisition bounds fell back to the active channel's frame whenever the device spectrum bounds had not hydrated. Every scroll therefore re-clamped the acquisition window into the channel on the next range sync, so the spectrum elastically snapped back to the channel edge. Fall back to the global spectrum bounds instead.
The live sample-rate reconciliation effect republished a channel-anchored range (channel start + acquisition span) whenever frequencyRange changed, including a user pan. In Whole Channel mode each scroll tick was therefore undone on the next render and the viewport elastically snapped back to the channel edges. Reconcile only the acquisition span; the position belongs to explicit channel and sample-rate actions. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
The baseband filter toggle wrote 0 when switched off but never touched the pin, so the auto-track effect immediately restored the sample rate and the toggle looked dead until a value was typed. Worse, that 0 was published as tuner_bandwidth, which is not a valid MAX2837 filter width; the write failed the filter set and tore the live stream down onto the placeholder. Remove the off state: the filter always mirrors the active sample rate unless a custom value is pinned, clearing the field resumes mirroring, and a zero width is never published — the frontend resolves a clear to the sample rate and the backend skips a zero instead of touching the device. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
…le rate The off state stays. Switching the filter off now pins the disabled state so auto-tracking cannot switch it straight back on, and zero is held in state for the toggle to render but is never published to the hardware. While the filter is enabled and unpinned, the sample rate is the value and it is now derived for display rather than trusted from the published prop: publishing the same rate again does not change the prop, so a cleared field was left showing 0. Clearing now only unpins, and blurring remounts the input so it repopulates from the current sample rate. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
Remove unused node-notifier packages, add the TypeScript scripts directory to the typecheck boundary, and vendor a patched block crate for the Metal-backed Rust build under future-incompat linting.
Both were refs, so mutating them triggered no render. Effects therefore kept running against a stale mode/rate until an unrelated render refreshed them, which made the sample rate and the whole-channel viewport behave inconsistently and converge only after further interaction. The live sample-rate reconciliation also built its window with the active channel bounds, so a span disagreement republished a channel-clamped window — the viewport was pulled back inside the channel and the publish could repeat. It now only reconciles the acquisition span around the current centre. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
Manifest-only upgrade pass; no source changes were required. - tokio-tungstenite 0.29 -> 0.30 - tower-http 0.6 -> 0.7 (our crate now links 0.7.1; reqwest still pulls 0.6.11) - yawc 0.3.3 -> 0.4 - validator 0.20 -> 0.21 - base64 0.22 -> 0.23 - metal 0.31 -> 0.33 (behind the optional mock_apt_metal feature) - axum-test 20 -> 21, serial_test 3.2 -> 4, pastey 0.1.1 -> 0.2.3 - redis floor 1.6 -> 1.7 to match what was already resolving Verified: RUSTFLAGS="-D warnings" cargo check --workspace --all-targets (with and without --all-features), cargo bench --no-run, and all 16 CI-listed nextest suites pass. cargo audit stays clean. metal 0.33 still pulls both `paste` (RUSTSEC-2024-0436, unmaintained) and `block`, so the vendored vendor/block patch remains required. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
aes-gcm 0.10 -> 0.11 moves the crate onto the aead 0.6 generation (aead 0.5 -> 0.6, aes 0.8 -> 0.9, cipher 0.4 -> 0.5, ghash/polyval bumped), aligning it with the hmac 0.13 / sha2 0.11 / pbkdf2 0.13 generation already in use. aead 0.6 deprecated `Array::from_slice`, which the crate compiled with `-D warnings` correctly rejected. Replaced both `Nonce::from_slice(...)` call sites with the fallible `Nonce::try_from(...)` and switched `encrypt`/`decrypt` to the `&Nonce` signatures. The 12-byte IV is fixed-width so the conversion cannot fail, but the error is threaded through rather than unwrapped. Wire format is unchanged (12-byte IV || ciphertext || 16-byte GCM tag). Verified: RUSTFLAGS="-D warnings" cargo check --workspace --all-targets (with and without --all-features), cargo nextest --lib (378/378), and all 16 CI-listed suites pass. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
The repo carried three Cargo manifests pinning two different wasm-bindgen generations, and `test/wasm` was resolving behind the root crate: root wasm-bindgen 0.2.128 js-sys/web-sys 0.3.105 test/wasm wasm-bindgen 0.2.121 js-sys/web-sys 0.3.98 getrandom 0.2 (js) `test/wasm` depends on n-apt-backend by path, so it was exercising the project's WASM behaviour against a different wasm-bindgen than we ship. Raised its floors to 0.2.128 / 0.3.105 / wasm-bindgen-test 0.3.78 and moved `getrandom` from 0.2 with the `js` feature to 0.4 with `wasm_js`, matching the root manifest. Root floors were documenting-only (caret ranges already resolved to these versions) but are now stated explicitly. Deleted Cargo-wasm.toml, which declared a package `n-apt-wasm-tests` that nothing referenced -- `grep -rn Cargo-wasm` across the tree returns zero hits, and the WASM suite actually runs from test/wasm/Cargo.toml (package `wasm-tests`) via test/wasm/test_runner.sh. Verified: cargo check --workspace --all-targets; test/wasm checks clean for wasm32-unknown-unknown; `wasm-pack test --node` 13/13 pass (wasm-pack auto-installed the matching wasm-bindgen-cli 0.2.128); `npm run build:wasm` succeeds; safetyWasm + useWasmSimdMath jest suites pass against the regenerated glue. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
Lockfile-only pass: package.json is unchanged, every package stays inside its declared range. zod 4.4.3 -> 4.5.4 jest 30.4.2 -> 30.5.1 jest-environment-jsdom 30.4.1 -> 30.5.1 @testing-library/react 16.3.2 -> 16.3.3 @testing-library/user-event 14.6.4 -> 14.6.7 @react-three/postprocessing 3.0.5 -> 3.1.1 express-rate-limit 8.6.2 -> 8.7.0 isbot 5.2.1 -> 5.2.2 libheif-js 1.19.8 -> 1.23.2 @types/react-dom 19.2.4 -> 19.2.7 A bare `npm update` cannot run in this repo. Two pre-existing blockers, both worked around the same way CI already does: 1. ERESOLVE: ts-jest 29.4.11 peers `typescript >=4.3 <7` while the project is on typescript 7.0.2 (the @typescript/typescript6 shim exists precisely to give ts-jest a TS 6). CI uses `npm ci --legacy-peer-deps`. 2. ETARGET: `min-release-age=7` in .npmrc refuses to re-resolve the adm-zip@^0.6.1 override, whose 0.6 line was published inside the cooling window. A bare `npm install --dry-run` still resolves fine, so this only affects the update path. Updates were therefore applied with a package-scoped `npm update <names> --legacy-peer-deps`, which leaves the manifest alone. Verified: npm run typecheck clean, npm run lint unchanged at 11 warnings / 0 errors, jest test/ts 319 suites / 2619 tests all pass. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
Exact-version bumps across the pinned frontend set; no source changes were
required (typecheck, lint and the full suite all stayed green).
@mui/material + @mui/icons-material 9.2.0 -> 9.4.0
@radix-ui/react-* (26 packages) -> latest patch
react-router / @react-router/node / dev 8.3.0 -> 8.3.1
@playwright/test + playwright 1.61.1 -> 1.63.0
tailwindcss + @tailwindcss/{postcss,vite} 4.3.2 -> 4.3.3
@vitejs/plugin-react 6.0.3 -> 6.1.1
lucide-react 1.23.0 -> 1.43.0
recharts 3.9.2 -> 3.10.1
styled-components 6.4.3 -> 6.5.3
marked 18.0.5, dexie 4.4.5, dompurify 3.4.15, sonner 2.0.8,
@xyflow/react 12.11.6, input-otp 1.5.0, ink 7.1.1, redis 6.2.1
@types/node 26.5.0, @types/react 19.2.18, @types/three 0.185.4,
@webgpu/types 0.1.72, ts-jest 29.4.12, tsx 4.23.13
concurrently 10.0.5, wgsl-test 0.2.34, autoprefixer 10.5.5,
react-resizable-panels 4.12.4, @chenglou/pretext 0.0.9
@types/three stays on the 0.185 line deliberately: three itself is held at
0.185.1 because @types/three has no 0.186 release yet.
Flakiness observed and investigated: the first full jest run after the
install reported 6 failures, dominated by bare "Exceeded timeout of 5000 ms"
on userEvent-driven route tests. Two subsequent full runs (319 suites /
2619 tests) and three isolated runs of the suite that timed out were all
green, so this is load-induced, not a regression from these bumps.
jest.config.cjs sets no testTimeout, so everything rides jest's 5s default
while the slowest suite already takes ~12s. Flagged separately.
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
vitest 4.1.11 -> 5.0.0 @vitest/coverage-v8 4.1.11 -> 5.0.0 @vitest/browser-playwright 4.1.11 -> 5.0.0 @testing-library/jest-dom 6.9.1 -> 7.0.1 The vitest cluster moves together: the coverage and browser providers declare a peer on the vitest major. No config migration was needed -- vite.config.js carries no vitest `test` block (only a `vitest/config` type reference), so the shader run uses vitest's defaults plus the flags in the `test:shader` script. Verified: `npm run test:shader` 12 files / 52 tests pass on vitest 5.0.0; `npm run typecheck` clean; jest test/ts 319 suites / 2619 tests pass. Correction to the previous commit's flakiness note: the 6 failures I saw were caused by the disk being 100% full (jest's haste-map cache write failed with ENOSPC), not by these bumps. With space freed the suite is deterministically green. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
framer-motion 12.42.2 -> 13.2.0 (used by 6 components)
katex 0.17.0 -> 0.18.7
elkjs 0.11.1 -> 0.12.0 (dynamic import in demodLayoutWorker)
chalk 5.6.2 -> 6.0.0 (build orchestrator; chalk 6 drops the
./package.json export subpath)
archiver 6.0.2 -> 8.0.0 (legal-app-server)
@use-gpu/wgsl 0.19.0 -> 0.20.0
@google/genai 2.10.0 -> 2.21.0
No source changes were required; typecheck and lint stayed green.
katex note: this does NOT unify katex. react-katex 3.1.0 and rehype-katex
7.0.1 both declare `katex: ^0.16.0` and carry their own nested katex 0.16.47,
while the top level and @types/katex 0.16.8 sit on different generations.
The bundle already shipped two katex runtimes before this pass, and this bump
makes it three. Unifying it means replacing react-katex (or waiting for its
range to move) -- separate work, not a version bump.
`npm run lint:katex` fails with 4 errors, but this is pre-existing and NOT
caused by the katex bump: pinning katex back to 0.17.0 reproduces the exact
same 4 errors and exit code 2. The script is not wired into CI or any test
script, and two of its four "errors" are false positives -- it extracts any
`const X = "...\..."` containing a backslash as LaTeX, so it flags template
literals like `${sourceId}\0${mode ?? "active"}`.
Deliberately NOT bumped:
- better-sqlite3 12 -> 13: native module needing node-gyp, and the Xcode
developer dir is currently missing so no native rebuild can succeed.
- `motion` 12.42.2: provably unused (zero imports repo-wide) and duplicates
framer-motion, the same library under its newer package name.
- three 0.185.1: @types/three has no 0.186 release yet.
Verified: typecheck clean; lint unchanged at 11 warnings / 0 errors;
test:shader 12 files / 52 tests; jest test/ts 319 suites / 2619 tests pass.
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
oxlint 1.73.0 -> 1.82.0
oxfmt 0.58.0 -> 0.67.0
oxlint 1.82 adds one rule, which flagged exactly one new warning:
no-unused-vars: Parameter '_' is declared but never used
-> scripts/data/cleanEntities.cjs:196
Array.from(this.US_STATES.entries()).find(([_, name]) => ...)
Even though the rule's own message says unused parameters should start with
'_', it rejects '_' itself. Rather than suppress it, the unused binding is
dropped: `.find(([, name]) => ...)`. Behaviour is identical (verified the
lookup still resolves).
Lint is back to the pre-existing 11 warnings / 0 errors (94 rules).
oxfmt note: `npm run format:check` fails, but it was already failing before
this bump -- oxfmt 0.58.0 reports 298 non-conforming files and 0.67.0 reports
300. That is pre-existing repo-wide formatting drift, it is not a CI gate,
and I deliberately did not run `npm run format` here because a ~300-file
mechanical rewrite does not belong in a dependency commit.
Verified: lint 11 warnings / 0 errors; typecheck clean; test:shader 12 files /
52 tests; jest test/ts 319 suites / 2619 tests pass; edited script passes
`node --check`.
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
CI pins node 26.x in four places while package.json only advertises `engines.node: ">=22.22.0"`, so local and CI runtimes could drift. Added `.nvmrc` (26) so the 26 line used by CI is the default locally. `engines.node` is deliberately left loose: it is the constraint applied to consumers on install, and raising it to 26 would be a breaking change to make in a dependency commit. Added `.github/dependabot.yml` covering npm, cargo and github-actions, weekly and grouped. This also makes the SHA-pinned actions in test.yml self-updating rather than hand-maintained. The npm entry sets a 7-day `cooldown` to match the `min-release-age=7` already enforced in .npmrc, so Dependabot does not propose versions that npm would then refuse to install. Grouped updates cover the clusters that must move together (vitest + @vitest/*, react-router + @react-router/*, tailwindcss + @tailwindcss/*, @radix-ui/*, playwright + @playwright/test, and @types/*, since type packages must not outrun their runtime). Caveat recorded in the file: Dependabot's cargo support expects a lockfile it can reason about, and Cargo.lock is currently gitignored, so that entry may not produce useful PRs until Cargo.lock is committed. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
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.
Summary
.n-apt/is_mock) metadata through the websocket and frontend schemas/docsarticle outputnpm auditis cleanScreenshots
Validation
npm audit --audit-level=moderate— 0 vulnerabilitiesnpm run typechecknpx jest --runInBand test/ts/IQCaptureControlsSection.test.tsx test/ts/runtimePaths.test.ts— 17 passedRUSTC_WRAPPER= CARGO_TARGET_DIR=/private/tmp/napt-target-housekeeping cargo test --lib crypto::tests— 14 passedRUSTC_WRAPPER= CARGO_TARGET_DIR=/private/tmp/napt-target-housekeeping cargo test --test server_tests --quiet— 8 passedThe article update is included in the branch but does not have a separate screenshot.