detectJunkReads took its count from core's detector and re-derived its display and trend from the host's own JUNK_DIRS regex. The two lists disagreed: core classifies `vendor`, `site-packages`, `out` and `target` as junk; the host's did not. Core was already counting reads under those segments — the count is not what was wrong. The host's derivation was. In a repo whose junk reads all live under one of them — Go and PHP vendor, Python site-packages, Rust target, Java or Next out — the host loop matched nothing, so `recentJunkReads` stayed at zero. Where the window also had recent activity, `computeTrend` read that as fixed and returned 'resolved', and the finding was dropped. Whole ecosystems never saw it. In mixed repos it survived but rendered incoherently: the explanation quoted core's total while the directory list and the CLAUDE.md suggestion came from the narrower host counts, so the numbers did not add up and the suggested directories omitted the one actually causing the waste. Core now exports `junkSegmentOf`, which returns the exact segment that made a path junk. The host deletes JUNK_DIRS and JUNK_PATTERN outright and asks core in both loops — junk-reads and duplicate-reads, which had the same split. The host still names the directory for the payload, because a class alone cannot render `vendor/ (5x)`; it just no longer decides what junk means. Inside core, the precedence rule (dependency > build > vcs) lived in the order of three loops, and adding junkSegmentOf duplicated them. Both functions now consult one private helper, so the two cannot drift — a second copy of one rule is what caused this bug in the first place. Two display changes fall out. A path under two junk segments of the same table now names the first in path order rather than the first in array order, so `/x/build/dist/y` reports `build` where it used to report `dist`; the count is unchanged. Terminal junk directories and Windows-style paths are now matched, which the old slash-delimited regex missed — those align the host with what core was already counting. One robustness note: the old `JUNK_PATTERN.test()` coerced a truthy non-string `file_path`, while `junkSegmentOf` would throw on one. The type is narrowed at the point of use so the new path cannot throw where the old one could not. |
||
|---|---|---|
| .. | ||
| schemas | ||
| scripts | ||
| src | ||
| tests | ||
| package.json | ||
| README.md | ||
| tsconfig.build.json | ||
| tsconfig.json | ||
| tsup.config.ts | ||
| vitest.config.ts | ||
@codeburn/core
The pure decode/detect engine behind CodeBurn: provider session-log decoding for 36 AI coding tools, content-minimized observation envelopes, and detector contracts.
Status: 0.x. The engine is complete and battle-tested (it is the same code the CodeBurn CLI runs, proven byte-identical to the pre-extraction implementation on a frozen real-world corpus), but the public API may still change between 0.x minor versions. Pin accordingly.
What it does
- Decode: each provider module (
@codeburn/core/providers/<name>) turns that tool's raw session records into structured call data — tokens, models, timing, tool usage — with the provider's exact dedup and skip semantics. - Observations:
toObservationsmaps rich decode output into a strict, content-minimized envelope: only fingerprints, enums, numbers, timestamps, dedup keys, and canonical tool names cross the boundary. Enforced by an architecture gate and per-provider content-smuggling tests. - Detectors: contracts for waste/optimization findings over fingerprinted data.
What it deliberately does NOT do
No file or network I/O, no environment access, no clock reads, no pricing.
Hosts (the CodeBurn CLI, apps, or your own tooling) supply the records and apply
their own pricing. The only runtime dependency is zod.
Usage
import { decodeQwen } from '@codeburn/core/providers/qwen'
import { toObservations } from '@codeburn/core/providers/qwen'
import { OBSERVATION_SCHEMA_VERSION } from '@codeburn/core/schema'
const { calls, diagnostics } = decodeQwen({ records, seenKeys })
Each provider is its own subpath export; see package.json#exports for the full
list. JSON Schemas for the observation envelope ship under schemas/.
Part of the CodeBurn core extraction (RFC #796, tracking #809). MIT.