# Changelog

## Score

- CAI 52 → 51 (-0.8)

## Lenses

- Code Health 44 → 41 (-3.5)
- Architecture 81 → 81 (+0.0)
- Maturity 50 → 54 (+4.8)
- Readiness 52 → 52 (-0.0)
- Security 88 → 84 (-4.5)
- Performance 74 → 74 (+0.0)

## Resolved (9)

- Ambiguous naming for output configuration. `setOutput` is a standard setter, but `toKernelOutput` is unclear. It is not immediately obvious if `toKernelOutput` is a transformation helper, a builder pattern method, or a redundant setter. Given `setOutput` exists, `toKernelOutput` appears to be a confusingly named duplicate or a legacy alias.
- Confusing signature-related methods. `build()` is a lifecycle method. `buildSignature` and `getSignature` appear to do similar things (generating or retrieving a signature) but have different signatures and contexts. `getSignature` is static-like (takes kernel and args), while `buildSignature` is an instance method. This creates ambiguity about when to use which.
- High CVE: [GHSA redacted] (package-lock.json)
- High CVE: [GHSA redacted] (package-lock.json)
- Inconsistent configuration pattern. The `Kernel` class uses a massive number of `set*` methods for configuration, while other settings are exposed as direct public fields (e.g., `Kernel.debug`, `Kernel.graphical`, `Kernel.asyncMode`, `Kernel.precision`, etc.). This forces users to choose between using setters or direct property assignment, leading to inconsistent usage patterns and potential state synchronization issues if both are allowed.
- Off-boarding risk: anonymized user #1
- Redundant exposure of backend-specific pixel retrieval methods. The base `Kernel` class exposes `getPixels`, but the concrete implementations (`GLKernel`, `CPUKernel`) also expose their own `getPixels` methods. This suggests the base method might be a passthrough or that the API surface is leaking implementation details. More critically, `GLKernel` exposes multiple specific reading methods (`readPackedPixelsToUint8Array`, `readFloatPixelsToFloat32Array`, `readFloatPixelsToFloat32Array`) that duplicate the intent of extracting data, likely for performance or format specificity, but these are not mirrored in `CPUKernel` or the base `Kernel` interface, creating an inconsistent data retrieval API.
- Skipped (documented): (unnamed test) (test/playwright/qunit.spec.js)
- Workflow token permissions not restricted

## New (14)

- Deprecated: glob (package-lock.json)
- Deprecated: prebuild-install (package-lock.json)
- High secret: WD-SECRET-0005 (package-lock.json)
- Off-boarding risk: anonymized user #1
- Orphaned file (src/backend/cpu/kernel-string.js)
- Orphaned file (src/backend/function-tracer.js)
- Orphaned file (src/backend/web-gl/kernel-value-maps.js)
- Orphaned file (src/backend/web-gl/kernel-value/unsigned-array.js)
- Orphaned file (src/backend/web-gl2/kernel-value-maps.js)
- Orphaned knowledge (src/backend/function-builder.js)
- Rotate the exposed credentials — git history can't be un-committed
- Skipped test: (unnamed test) (test/playwright/qunit.spec.js)
- Workflow token permissions not restricted (.github/workflows/browserstack.yml)
- Workflow token permissions not restricted (.github/workflows/ci.yml)