mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-31 12:22:14 +03:00
e7c0d93141
* feat(compression): update vendored GCF (Headroom) codec to spec v3.2 (nested flattening)
Homogeneous arrays whose rows carry nested objects/arrays now tabularize
via GCF v3.2 `>`-path flattening instead of a low-yield per-row fallback,
so nested MCP tool-result rows (meta:{...}, tags:[...]) compact like flat
rows. Round-trip stays lossless (order-insensitive deepEqual).
Re-vendored from current gcf-typescript into the Headroom generic-profile
codec (open-sse/services/compression/engines/headroom/gcf/); still zero
runtime deps, MIT, SPDX-marked, generic-profile only. Also folds in two
upstream round-trip-safety fixes: the [N]: inline-array quoting fix and
canonical decimal formatting.
Regression guard: tests/unit/compression/headroom-smartcrusher.test.ts
gains a deep-nested case (two-level object + array-of-objects) asserting
the v3.2 flatten paths and order-insensitive round-trip. Vendored-code
baseline bumps (complexity 2053->2055, cognitive 885->888, decode_generic
no-explicit-any 18->22) each carry an inline _rebaseline_2026_07_10_gcf_v3_2
justification noting the growth is the vendored surface, not new project code.
* chore(changelog): add fragment for headroom GCF v3.2 nested flattening (#6838)
* docs(readme): note Headroom handles nested arrays (GCF v3.2) in the engine-stack table
* docs(readme): note Headroom handles nested arrays (GCF v3.2) in the engine-stack table
* fix(compression): harden vendored GCF decoder against prototype pollution
The v3.2 flatten/unflatten paths (and the pre-existing inline-object parser)
built decoded objects with bracket assignment and `key in obj` membership,
so a hostile or unusual payload could pollute Object.prototype via a
`__proto__` path segment, and any key shadowing an Object.prototype member
(`toString`, `constructor`) was misparsed or wrongly flagged duplicate.
- Encoder (`analyzeFlattenable`): builds the shape map with `Object.create(null)`
and refuses to flatten objects carrying `__proto__`/`constructor`/`prototype`
keys (they round-trip whole instead).
- Decoder: `unflattenPaths` drops any path with an unsafe segment; a shared
`safeAssign` writes a literal `__proto__` key as an own data property
(JSON.parse semantics) instead of reassigning the prototype, used at every
object-build site; `checkDup` and orphan-merge use `hasOwnProperty` so
built-in-named keys are not spuriously treated as duplicates.
Also a losslessness fix: objects with keys named `toString`/`constructor`/
`valueOf` now round-trip. Regression guard: prototype-pollution + built-in-key
cases in tests/unit/compression/headroom-smartcrusher.test.ts. Prototype
pollution is JS/TS-specific; the Go/Python/Rust/Swift/Kotlin SDKs use native
maps and are unaffected.
* fix(compression): apply GCF decoder review hardening (hasOwnProperty sweep, unflatten null-guard, strict count)
Addresses the second-round review on the vendored codec:
- Replace every `key in obj` membership test with
`Object.prototype.hasOwnProperty.call(...)` across generic.ts (flatten
shape analysis, key-chain resolution, inline-schema/shared-array helpers,
row encode) so inherited names (`toString`/`constructor`) never match the
prototype chain, and remove a redundant `obj` re-declaration in the ">"
field attachment loop.
- `unflattenPaths` guards each intermediate segment: a missing OR non-object
slot is replaced with a fresh object before traversal, so malformed/hostile
input can no longer dereference a primitive and crash.
- Use the strict `parseCount` helper (not `parseInt`) for the shared-schema
count so malformed counts fail the mismatch check instead of coercing.
The decoder grew past the 800-line file-size cap; frozen at 880 in
file-size-baseline.json with a justification (vendored file kept faithful to
upstream gcf-typescript for clean re-vendoring). Verified: prototype-pollution
+ hostile-input + built-in-key round-trip probes, 54/54 compression tests,
typecheck, lint, cyclomatic/cognitive baselines unchanged, compression-budget.
* fix(compression): do not flatten a nested object that is null in any row (losslessness)
analyzeFlattenable skipped null values during shape analysis, so a field that
was an object in some rows and null in others was still flattened. On decode,
the null row's leaves resolved as absent ("~") and unflattened to a missing key
instead of null, silently dropping the value (e.g. {meta:{owner:null}} decoded
to {}). analyzeFlattenable now bails (returns null) when the field is null in
any row, routing it through the lossless whole-object attachment path. Applies
at every nesting depth via the existing recursion. Regression guard: null
nested-object cases in tests/unit/compression/headroom-smartcrusher.test.ts.
* fix(compression): narrow the null-nested flatten bail to intermediate nulls only
The previous fix bailed flattening whenever a nested field was null in any row.
That is correct but over-broad: a top-level null round-trips losslessly through
flattening (it emits "-" and reconstructs via the all-null rule). Only a null at
an intermediate nesting level loses data (its leaves encode as absent "~" and
unflatten to a missing key). Bail only when parentPath is non-empty, so top-level
nulls keep flattening (compression preserved) while intermediate nulls fall back
to the lossless attachment path. Matches GCF conformance fixtures 004/013.
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>