From e61f8360b8befa8d78738c8e33a90673e5662057 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Thu, 1 Oct 2026 06:58:59 +0000 Subject: [PATCH] chore: release packages AI-Mode: agent --- .changeset/internal-identifiers.md | 13 -------- .changeset/observation-end-until.md | 15 ---------- .changeset/renames-follow-the-file.md | 13 -------- .changeset/trend-comparability.md | 18 ----------- packages/cli/CHANGELOG.md | 40 +++++++++++++++++++++++++ packages/cli/package.json | 2 +- packages/core/CHANGELOG.md | 43 +++++++++++++++++++++++++++ packages/core/package.json | 2 +- packages/metrics/CHANGELOG.md | 39 ++++++++++++++++++++++++ packages/metrics/package.json | 2 +- 10 files changed, 125 insertions(+), 62 deletions(-) delete mode 100644 .changeset/internal-identifiers.md delete mode 100644 .changeset/observation-end-until.md delete mode 100644 .changeset/renames-follow-the-file.md delete mode 100644 .changeset/trend-comparability.md diff --git a/.changeset/internal-identifiers.md b/.changeset/internal-identifiers.md deleted file mode 100644 index be8a78d..0000000 --- a/.changeset/internal-identifiers.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -'@evidtrail/core': minor -'@evidtrail/cli': patch ---- - -The rename reaches the identifiers no user ever sees - -The 1.2 rename deliberately stopped at the surface: config file, environment variable, command name, markers. The code underneath still said `AidaConfig`, `installAidaHook`, `loadAidaConfig`, `isAidaHookInstalled`, and the schema lived in `aida-config.ts`. Harmless to run, confusing to read, and a trap for anyone opening the source after arriving from the new name. - -- `@evidtrail/core` exports **`EvidtrailConfig`**; the schema file is `evidtrail-config.ts`. `AidaConfig` is a published export, so it stays as a deprecated alias of the same schema until the next major — renaming it outright would break importers on a minor upgrade, which is the opposite of what the rename promised. A test asserts the two are the same object. -- CLI internals drop the prefix rather than swapping it, where the surrounding module already says which tool it is: `loadConfig`, `installHook`, `uninstallHook`, `isHookInstalled`, `stripHookBlock`, `existingWorkflow`. Only `isEvidtrailHook` keeps a name, because its whole job is telling our hook from someone else's. - -No behaviour changes: same schema, same checks, same output. diff --git a/.changeset/observation-end-until.md b/.changeset/observation-end-until.md deleted file mode 100644 index 46e6f22..0000000 --- a/.changeset/observation-end-until.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -'@evidtrail/core': patch -'@evidtrail/metrics': patch -'@evidtrail/cli': patch ---- - -Observation stops at `--until`: a bounded run no longer reads truncated files as untouched, or a truncated month as mature - -Found by an external review, reproduced, and it flatters: with `--until 2 Jan`, a file added on 1 Jan and edited on 4 Jan was reported as having survived a 7-day window untouched (0/1, 0%). The edit had been cut out of the stream, but every elapsed-time measurement still ran to the collection date months later, so "nothing happened" and "we stopped looking" were indistinguishable. The trend inherited the slip: a month cut short by the bound passed the maturity gate and entered the headline comparison with a window it never had. - -- **Metrics**: observation ends at the earlier of the collection time and the `until` bound (`observationEndOf`). Persistence, rapid retouch, the recent-coverage window and trend maturity all run to that instant. The artifact records it as `window.observationEnd`. -- **Collect**: `since` and `until` are stored in the stream as the resolved instants, not the flag text. `--until 10d` re-read tomorrow would name a different day, and a metrics artifact must be a pure function of its input. -- **Report**: a bounded run says so next to the change-signals table — files first touched shortly before the bound are *too recent*, not untouched. - -Runs without `--until` are unchanged. On external repositories bounded ten days back, files that had been promoted to *eligible* return to *too recent* (aspire: 362 → 723 at 30 days is the direction to expect; exact figures in the pull request). diff --git a/.changeset/renames-follow-the-file.md b/.changeset/renames-follow-the-file.md deleted file mode 100644 index 3bf8bb4..0000000 --- a/.changeset/renames-follow-the-file.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -'@evidtrail/core': patch -'@evidtrail/metrics': patch ---- - -Renames follow the file: a moved file is one file, not a phantom path plus a stranger - -Found by an external review, reproduced, and it flatters: `old.ts` → `git mv new.ts` → edit `new.ts` produced three paths in the stream — `old.ts`, `old.ts => new.ts` and `new.ts` — with the rename filed as a *modification* of a file that never existed. Every rename in a repository was one more eligible file that could never be retouched, and the real file's later edits were filed under a name its first touch had never been recorded against. On react-router, 1,956 renames were doing this. - -- **core** — `git log --numstat` names a renamed file as `old => new` or `dir/{old => new}/file`; both forms are now parsed (`splitRenamePath`). The stream records the file under its new name with `previousPath` set and status `renamed` (additive field, no schema bump). PR-scoped collection (`git show`) gets the same parsing. -- **metrics** — a file's lifecycle follows it across a rename. A pure rename (no lines changed) is not a touch: nothing about the code happened, only its address. A rename that also edits is one. Hotfix linking carries the touch history across the move the same way. - -Direction of the change on real repositories: eligible files go down, retouches go up, and the rate rises — the phantom paths had been padding the denominator with files nothing could ever touch. Exact figures in the pull request. diff --git a/.changeset/trend-comparability.md b/.changeset/trend-comparability.md deleted file mode 100644 index 9f3cb66..0000000 --- a/.changeset/trend-comparability.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -'@evidtrail/core': patch -'@evidtrail/metrics': patch -'@evidtrail/cli': patch ---- - -The trend says when two periods are not comparable by size; the report drops three phrases that promised more than the numbers hold - -**Comparability by size (#102).** Maturity answers "have both periods had the same time?"; nothing answered "is there enough in each, and are they alike enough, for a delta to mean anything?". Found on this repository: 5 commits over 18 files against 18 commits over 53 files, two empty months between, rendered as a +60.9 pt change in rapid retouch. The arithmetic was right; the reading it invited was not. - -- `latestComparison.comparability` (additive): eligible files and authored commits per side, and a status — `ok`, `weak` (sizes differ beyond 3×) or `insufficient` (a side has fewer than 10 eligible files) — with the reasons spelled out. -- The report shows a weak delta and labels it: *a change of pace is being measured along with any change in the code*. An insufficient one is withheld with the reason, the rows still shown. The pair is never swapped for a friendlier one. - -**Words.** "How code holds up" → "how often code is touched again"; "below is better than average" → "below is fewer than its share predicts". The Data Quality section now says how many AI commits carry a tool signal but no autonomy level: coverage counts them as evidence, the autonomy sections count them as `unknown`, and 100% coverage was reading as 100% known. - -**Windowed runs.** With `--since`, a file's clock starts at its first touch inside the window, so the population differs from a full-history run (68% vs 90% on the same repository). The report now says so next to the table. - -**Codex.** `codex` joins the default tool names: "generated by Codex" was returning no evidence while the same sentence with Claude was inferred AI. The hook does not auto-detect Codex, because Codex documents no environment variable for spawned commands and a guess that could be wrong is worse than an honest `unknown`; the README says to declare with `EVIDTRAIL_MODE`. diff --git a/packages/cli/CHANGELOG.md b/packages/cli/CHANGELOG.md index 4901e8e..1ae25fc 100644 --- a/packages/cli/CHANGELOG.md +++ b/packages/cli/CHANGELOG.md @@ -1,5 +1,45 @@ # @aida/cli +## 1.2.1 + +### Patch Changes + +- bf37d7c: The rename reaches the identifiers no user ever sees + + The 1.2 rename deliberately stopped at the surface: config file, environment variable, command name, markers. The code underneath still said `AidaConfig`, `installAidaHook`, `loadAidaConfig`, `isAidaHookInstalled`, and the schema lived in `aida-config.ts`. Harmless to run, confusing to read, and a trap for anyone opening the source after arriving from the new name. + - `@evidtrail/core` exports **`EvidtrailConfig`**; the schema file is `evidtrail-config.ts`. `AidaConfig` is a published export, so it stays as a deprecated alias of the same schema until the next major — renaming it outright would break importers on a minor upgrade, which is the opposite of what the rename promised. A test asserts the two are the same object. + - CLI internals drop the prefix rather than swapping it, where the surrounding module already says which tool it is: `loadConfig`, `installHook`, `uninstallHook`, `isHookInstalled`, `stripHookBlock`, `existingWorkflow`. Only `isEvidtrailHook` keeps a name, because its whole job is telling our hook from someone else's. + + No behaviour changes: same schema, same checks, same output. + +- b02ad4a: Observation stops at `--until`: a bounded run no longer reads truncated files as untouched, or a truncated month as mature + + Found by an external review, reproduced, and it flatters: with `--until 2 Jan`, a file added on 1 Jan and edited on 4 Jan was reported as having survived a 7-day window untouched (0/1, 0%). The edit had been cut out of the stream, but every elapsed-time measurement still ran to the collection date months later, so "nothing happened" and "we stopped looking" were indistinguishable. The trend inherited the slip: a month cut short by the bound passed the maturity gate and entered the headline comparison with a window it never had. + - **Metrics**: observation ends at the earlier of the collection time and the `until` bound (`observationEndOf`). Persistence, rapid retouch, the recent-coverage window and trend maturity all run to that instant. The artifact records it as `window.observationEnd`. + - **Collect**: `since` and `until` are stored in the stream as the resolved instants, not the flag text. `--until 10d` re-read tomorrow would name a different day, and a metrics artifact must be a pure function of its input. + - **Report**: a bounded run says so next to the change-signals table — files first touched shortly before the bound are _too recent_, not untouched. + + Runs without `--until` are unchanged. On external repositories bounded ten days back, files that had been promoted to _eligible_ return to _too recent_ (aspire: 362 → 723 at 30 days is the direction to expect; exact figures in the pull request). + +- 46bd263: The trend says when two periods are not comparable by size; the report drops three phrases that promised more than the numbers hold + + **Comparability by size (#102).** Maturity answers "have both periods had the same time?"; nothing answered "is there enough in each, and are they alike enough, for a delta to mean anything?". Found on this repository: 5 commits over 18 files against 18 commits over 53 files, two empty months between, rendered as a +60.9 pt change in rapid retouch. The arithmetic was right; the reading it invited was not. + - `latestComparison.comparability` (additive): eligible files and authored commits per side, and a status — `ok`, `weak` (sizes differ beyond 3×) or `insufficient` (a side has fewer than 10 eligible files) — with the reasons spelled out. + - The report shows a weak delta and labels it: _a change of pace is being measured along with any change in the code_. An insufficient one is withheld with the reason, the rows still shown. The pair is never swapped for a friendlier one. + + **Words.** "How code holds up" → "how often code is touched again"; "below is better than average" → "below is fewer than its share predicts". The Data Quality section now says how many AI commits carry a tool signal but no autonomy level: coverage counts them as evidence, the autonomy sections count them as `unknown`, and 100% coverage was reading as 100% known. + + **Windowed runs.** With `--since`, a file's clock starts at its first touch inside the window, so the population differs from a full-history run (68% vs 90% on the same repository). The report now says so next to the table. + + **Codex.** `codex` joins the default tool names: "generated by Codex" was returning no evidence while the same sentence with Claude was inferred AI. The hook does not auto-detect Codex, because Codex documents no environment variable for spawned commands and a guess that could be wrong is worse than an honest `unknown`; the README says to declare with `EVIDTRAIL_MODE`. + +- Updated dependencies [bf37d7c] +- Updated dependencies [b02ad4a] +- Updated dependencies [0987339] +- Updated dependencies [46bd263] + - @evidtrail/core@1.2.0 + - @evidtrail/metrics@1.1.1 + ## 1.2.0 ### Minor Changes diff --git a/packages/cli/package.json b/packages/cli/package.json index c642e10..17c4905 100644 --- a/packages/cli/package.json +++ b/packages/cli/package.json @@ -1,6 +1,6 @@ { "name": "@evidtrail/cli", - "version": "1.2.0", + "version": "1.2.1", "description": "Auditable AI provenance and change signals from git — CLI and GitHub Action. An auditable ledger of AI provenance and change signals for your git repositories — honest about what git can and cannot prove.", "type": "module", "main": "dist/index.js", diff --git a/packages/core/CHANGELOG.md b/packages/core/CHANGELOG.md index 643eeef..13b9610 100644 --- a/packages/core/CHANGELOG.md +++ b/packages/core/CHANGELOG.md @@ -1,5 +1,48 @@ # @aida/core +## 1.2.0 + +### Minor Changes + +- bf37d7c: The rename reaches the identifiers no user ever sees + + The 1.2 rename deliberately stopped at the surface: config file, environment variable, command name, markers. The code underneath still said `AidaConfig`, `installAidaHook`, `loadAidaConfig`, `isAidaHookInstalled`, and the schema lived in `aida-config.ts`. Harmless to run, confusing to read, and a trap for anyone opening the source after arriving from the new name. + - `@evidtrail/core` exports **`EvidtrailConfig`**; the schema file is `evidtrail-config.ts`. `AidaConfig` is a published export, so it stays as a deprecated alias of the same schema until the next major — renaming it outright would break importers on a minor upgrade, which is the opposite of what the rename promised. A test asserts the two are the same object. + - CLI internals drop the prefix rather than swapping it, where the surrounding module already says which tool it is: `loadConfig`, `installHook`, `uninstallHook`, `isHookInstalled`, `stripHookBlock`, `existingWorkflow`. Only `isEvidtrailHook` keeps a name, because its whole job is telling our hook from someone else's. + + No behaviour changes: same schema, same checks, same output. + +### Patch Changes + +- b02ad4a: Observation stops at `--until`: a bounded run no longer reads truncated files as untouched, or a truncated month as mature + + Found by an external review, reproduced, and it flatters: with `--until 2 Jan`, a file added on 1 Jan and edited on 4 Jan was reported as having survived a 7-day window untouched (0/1, 0%). The edit had been cut out of the stream, but every elapsed-time measurement still ran to the collection date months later, so "nothing happened" and "we stopped looking" were indistinguishable. The trend inherited the slip: a month cut short by the bound passed the maturity gate and entered the headline comparison with a window it never had. + - **Metrics**: observation ends at the earlier of the collection time and the `until` bound (`observationEndOf`). Persistence, rapid retouch, the recent-coverage window and trend maturity all run to that instant. The artifact records it as `window.observationEnd`. + - **Collect**: `since` and `until` are stored in the stream as the resolved instants, not the flag text. `--until 10d` re-read tomorrow would name a different day, and a metrics artifact must be a pure function of its input. + - **Report**: a bounded run says so next to the change-signals table — files first touched shortly before the bound are _too recent_, not untouched. + + Runs without `--until` are unchanged. On external repositories bounded ten days back, files that had been promoted to _eligible_ return to _too recent_ (aspire: 362 → 723 at 30 days is the direction to expect; exact figures in the pull request). + +- 0987339: Renames follow the file: a moved file is one file, not a phantom path plus a stranger + + Found by an external review, reproduced, and it flatters: `old.ts` → `git mv new.ts` → edit `new.ts` produced three paths in the stream — `old.ts`, `old.ts => new.ts` and `new.ts` — with the rename filed as a _modification_ of a file that never existed. Every rename in a repository was one more eligible file that could never be retouched, and the real file's later edits were filed under a name its first touch had never been recorded against. On react-router, 1,956 renames were doing this. + - **core** — `git log --numstat` names a renamed file as `old => new` or `dir/{old => new}/file`; both forms are now parsed (`splitRenamePath`). The stream records the file under its new name with `previousPath` set and status `renamed` (additive field, no schema bump). PR-scoped collection (`git show`) gets the same parsing. + - **metrics** — a file's lifecycle follows it across a rename. A pure rename (no lines changed) is not a touch: nothing about the code happened, only its address. A rename that also edits is one. Hotfix linking carries the touch history across the move the same way. + + Direction of the change on real repositories: eligible files go down, retouches go up, and the rate rises — the phantom paths had been padding the denominator with files nothing could ever touch. Exact figures in the pull request. + +- 46bd263: The trend says when two periods are not comparable by size; the report drops three phrases that promised more than the numbers hold + + **Comparability by size (#102).** Maturity answers "have both periods had the same time?"; nothing answered "is there enough in each, and are they alike enough, for a delta to mean anything?". Found on this repository: 5 commits over 18 files against 18 commits over 53 files, two empty months between, rendered as a +60.9 pt change in rapid retouch. The arithmetic was right; the reading it invited was not. + - `latestComparison.comparability` (additive): eligible files and authored commits per side, and a status — `ok`, `weak` (sizes differ beyond 3×) or `insufficient` (a side has fewer than 10 eligible files) — with the reasons spelled out. + - The report shows a weak delta and labels it: _a change of pace is being measured along with any change in the code_. An insufficient one is withheld with the reason, the rows still shown. The pair is never swapped for a friendlier one. + + **Words.** "How code holds up" → "how often code is touched again"; "below is better than average" → "below is fewer than its share predicts". The Data Quality section now says how many AI commits carry a tool signal but no autonomy level: coverage counts them as evidence, the autonomy sections count them as `unknown`, and 100% coverage was reading as 100% known. + + **Windowed runs.** With `--since`, a file's clock starts at its first touch inside the window, so the population differs from a full-history run (68% vs 90% on the same repository). The report now says so next to the table. + + **Codex.** `codex` joins the default tool names: "generated by Codex" was returning no evidence while the same sentence with Claude was inferred AI. The hook does not auto-detect Codex, because Codex documents no environment variable for spawned commands and a guess that could be wrong is worse than an honest `unknown`; the README says to declare with `EVIDTRAIL_MODE`. + ## 1.1.0 ### Minor Changes diff --git a/packages/core/package.json b/packages/core/package.json index 646dd4d..904d941 100644 --- a/packages/core/package.json +++ b/packages/core/package.json @@ -1,6 +1,6 @@ { "name": "@evidtrail/core", - "version": "1.1.0", + "version": "1.2.0", "description": "Git collection, two-axis AI attribution (mode × evidence), and versioned schemas for evidtrail. An auditable ledger of AI provenance and change signals for your git repositories — honest about what git can and cannot prove.", "type": "module", "main": "dist/index.js", diff --git a/packages/metrics/CHANGELOG.md b/packages/metrics/CHANGELOG.md index aac142a..d5a3422 100644 --- a/packages/metrics/CHANGELOG.md +++ b/packages/metrics/CHANGELOG.md @@ -1,5 +1,44 @@ # @aida/metrics +## 1.1.1 + +### Patch Changes + +- b02ad4a: Observation stops at `--until`: a bounded run no longer reads truncated files as untouched, or a truncated month as mature + + Found by an external review, reproduced, and it flatters: with `--until 2 Jan`, a file added on 1 Jan and edited on 4 Jan was reported as having survived a 7-day window untouched (0/1, 0%). The edit had been cut out of the stream, but every elapsed-time measurement still ran to the collection date months later, so "nothing happened" and "we stopped looking" were indistinguishable. The trend inherited the slip: a month cut short by the bound passed the maturity gate and entered the headline comparison with a window it never had. + - **Metrics**: observation ends at the earlier of the collection time and the `until` bound (`observationEndOf`). Persistence, rapid retouch, the recent-coverage window and trend maturity all run to that instant. The artifact records it as `window.observationEnd`. + - **Collect**: `since` and `until` are stored in the stream as the resolved instants, not the flag text. `--until 10d` re-read tomorrow would name a different day, and a metrics artifact must be a pure function of its input. + - **Report**: a bounded run says so next to the change-signals table — files first touched shortly before the bound are _too recent_, not untouched. + + Runs without `--until` are unchanged. On external repositories bounded ten days back, files that had been promoted to _eligible_ return to _too recent_ (aspire: 362 → 723 at 30 days is the direction to expect; exact figures in the pull request). + +- 0987339: Renames follow the file: a moved file is one file, not a phantom path plus a stranger + + Found by an external review, reproduced, and it flatters: `old.ts` → `git mv new.ts` → edit `new.ts` produced three paths in the stream — `old.ts`, `old.ts => new.ts` and `new.ts` — with the rename filed as a _modification_ of a file that never existed. Every rename in a repository was one more eligible file that could never be retouched, and the real file's later edits were filed under a name its first touch had never been recorded against. On react-router, 1,956 renames were doing this. + - **core** — `git log --numstat` names a renamed file as `old => new` or `dir/{old => new}/file`; both forms are now parsed (`splitRenamePath`). The stream records the file under its new name with `previousPath` set and status `renamed` (additive field, no schema bump). PR-scoped collection (`git show`) gets the same parsing. + - **metrics** — a file's lifecycle follows it across a rename. A pure rename (no lines changed) is not a touch: nothing about the code happened, only its address. A rename that also edits is one. Hotfix linking carries the touch history across the move the same way. + + Direction of the change on real repositories: eligible files go down, retouches go up, and the rate rises — the phantom paths had been padding the denominator with files nothing could ever touch. Exact figures in the pull request. + +- 46bd263: The trend says when two periods are not comparable by size; the report drops three phrases that promised more than the numbers hold + + **Comparability by size (#102).** Maturity answers "have both periods had the same time?"; nothing answered "is there enough in each, and are they alike enough, for a delta to mean anything?". Found on this repository: 5 commits over 18 files against 18 commits over 53 files, two empty months between, rendered as a +60.9 pt change in rapid retouch. The arithmetic was right; the reading it invited was not. + - `latestComparison.comparability` (additive): eligible files and authored commits per side, and a status — `ok`, `weak` (sizes differ beyond 3×) or `insufficient` (a side has fewer than 10 eligible files) — with the reasons spelled out. + - The report shows a weak delta and labels it: _a change of pace is being measured along with any change in the code_. An insufficient one is withheld with the reason, the rows still shown. The pair is never swapped for a friendlier one. + + **Words.** "How code holds up" → "how often code is touched again"; "below is better than average" → "below is fewer than its share predicts". The Data Quality section now says how many AI commits carry a tool signal but no autonomy level: coverage counts them as evidence, the autonomy sections count them as `unknown`, and 100% coverage was reading as 100% known. + + **Windowed runs.** With `--since`, a file's clock starts at its first touch inside the window, so the population differs from a full-history run (68% vs 90% on the same repository). The report now says so next to the table. + + **Codex.** `codex` joins the default tool names: "generated by Codex" was returning no evidence while the same sentence with Claude was inferred AI. The hook does not auto-detect Codex, because Codex documents no environment variable for spawned commands and a guess that could be wrong is worse than an honest `unknown`; the README says to declare with `EVIDTRAIL_MODE`. + +- Updated dependencies [bf37d7c] +- Updated dependencies [b02ad4a] +- Updated dependencies [0987339] +- Updated dependencies [46bd263] + - @evidtrail/core@1.2.0 + ## 1.1.0 ### Minor Changes diff --git a/packages/metrics/package.json b/packages/metrics/package.json index 086aa02..d9882cf 100644 --- a/packages/metrics/package.json +++ b/packages/metrics/package.json @@ -1,6 +1,6 @@ { "name": "@evidtrail/metrics", - "version": "1.1.0", + "version": "1.1.1", "description": "Deterministic rapid-retouch, trend, cohort, and outcome metrics for evidtrail. An auditable ledger of AI provenance and change signals for your git repositories — honest about what git can and cannot prove.", "type": "module", "main": "dist/index.js",