build(deps): update dependency @fro.bot/systematic to v3.15.0

[fro-bot]

This PR contains the following updates:

Package	Change	Age	Confidence	OpenSSF	Code Search
@fro.bot/systematic (source)	3.12.4 → 3.15.0

---

Release Notes

marcusrbrown/systematic (@​fro.bot/systematic)

v3.15.0

Compare Source

What's new

This release closes the loop on the Claude Code review-artifact validator: it now ships as a real, executable command inside the plugin bundle instead of prose describing one that couldn't run, and the contract that names it has been corrected to describe how the parent actually reaches it.

Features

The Claude Code bundle had shipped prose naming a validate-review-artifact command with nothing able to run it, so validation there recorded an absence rather than a result (#​871). It now carries a real executable — bin/systematic-validate-review-artifact, built in memory at bundle time and reachable as a bare command. Containment helpers moved out of the CLI into their own module: the CLI's import graph reaches the JSONC config loader, and a bundle that pulls that in builds cleanly but dies at runtime looking for a module its own wrapper requires by name. Exporting from the CLI would have reintroduced exactly that defect. The entry imports only the schema and the extracted helpers, keeping it at 0.28 MB with nothing resolved at runtime, and reproduces the subcommand's behavior exactly — including the projection that reports only field paths and error codes so artifact contents never reach the output. A companion refactor consolidated three functions and a type that had been duplicated byte-for-byte between the CLI and the bundled validator, closing the risk that one copy could quietly regain a legacy-artifact classification bug already caught once in review. Verified by running the built artifact from outside the repository against valid, invalid, legacy, malformed, and missing inputs, and confirming a planted marker in every string field of an invalid artifact never leaked into the output.

The bundle writer had been creating every file with a default mode, so the validator shipped without an executable bit and could only run via an interpreter named in front of it — defeating the point of living in a bin directory (#​872). Entries under bin are now written executable; nothing else changes mode, since restoring source modes across the whole bundle would be a broader change with no demand behind it. The pre-publish guard also gained this check, now asserting the entry is executable rather than merely present — presence alone wouldn't catch a file that exists, passes every other check, and still can't run. Verified by copying the built entry outside the repository with its mode preserved and running it directly with no interpreter: valid, invalid, legacy, malformed, and missing inputs all returned their documented codes, and removing then restoring the bit confirmed the guard catches both directions.

Documentation

skills/ce-review/references/synthesis-artifact-contract.md told the parent to look for one command on PATH and warned that a harness installing only bundled markdown wouldn't have it — true when written, false now that the Claude Code bundle ships its own validator beside the prose naming it (#​873). The revised passage states the resolution order explicitly: the bundled command first, then the packaged subcommand. It also directs callers to run the command rather than test for its presence, since a name on PATH can be a shim that fails on every invocation — a documented failure elsewhere in this repository — so resolving a name proves nothing that running it doesn't prove better. Absent and present-but-broken stay distinct: both record the run as unavailable, but neither is ever a failed validation, since that value means an artifact was read and did not conform. Two learnings that had asserted the bundle carries no executable were corrected; the recommendations they made survive untouched. A companion change marked the bundled-validator plan complete, since all five units had shipped across three pull requests but the plan still read as though none had.

Compare

v3.14.5...v3.15.0

v3.14.5

Compare Source

What's new

A small documentation-heavy release: one scoring fix in the compound workflow's related-docs step, plus four docs that trace a costly false assumption from discovery to correction.

Bug Fixes

skills: derive the overlap score from the dimension count (#​870)

The compound workflow's related-docs step scores how similar a proposed learning is to an existing one across five named dimensions, and that score decides whether a session writes a new document or updates an existing one. The scoring logic got this decision wrong four times in one session, in two distinct ways: the score was judged as a holistic read of "how related do these feel" rather than a literal count of matched dimensions, letting a report score two documents as near-duplicates while recommending a new document be written in the same breath; and the document search couldn't find work clustered under a shared module, because it took its search term from keywords in the problem description rather than from the actual curated module identifiers in use. Both are fixed: the dimension count now reads directly into the score, with the count stated in the returned assessment -- when the two disagree, the count wins -- and the module search now enumerates the real module values in use and picks the closest match. A companion fix also separates the score-follows-count and recommendation-follows-score checks, which a prior read had collapsed into a single rule, obscuring which one had actually failed.

Documentation

Four documentation changes landed, spanning solution captures and plan corrections that all trace back to one costly false premise.

Two solution docs record the lesson from a session where a plan was designed around an assumption that was never tested. The Claude Code plugin bundle was assumed unable to carry an executable, so an MCP server, a runtime version floor bump, a launch pin, and a new dependency were designed, reviewed by six personas, and merged as a plan -- all before a single local install proved the premise false. A marketplace install actually copies the entire plugin directory, including files the manifest never declares, with the executable bit intact and bin/ already on the Bash tool's PATH; no transport is needed to reach a bundled executable (#​869). That doc captures the general lesson -- a working capability that has never had its cause isolated hasn't proven anything; remove the suspected cause and re-run to confirm -- and links it to an existing five-week-old rule about probing unproven runtime channels before designing around them. A second doc records the specific anchor convention now required in every fenced script block: skills that invoked helper scripts with bare relative paths resolved against the consumer's working directory rather than the skill's install directory, breaking on every harness. The fix is three rules: every block (not just the file) must (re)set the anchor, the assignment must use a form that terminates correctly even when a host flattens a fenced block to one line, and the anchor stays model-filled rather than sourced from a host variable, since a substitution offered by one harness silently expands to nothing on the others (#​866).

The two plan documents in this release close out that same story. The MCP server plan is marked superseded, since its central assumption -- that a Claude Code bundle can't carry an executable -- was never measured and turned out to be false; the real constraint is entry-point scope, since the full CLI can't be bundled (a jsonc-parser UMD branch requires runtime resolution the bundler can't do statically), but a narrower entry importing only the review-artifact schema builds to a self-contained file. The plan stays in place behind a status banner rather than being deleted, pointing at the measurements that replaced it (#​867). In its place, a new plan describes building a review-artifact validator that ships as an in-bundle executable, with every claim it depends on -- the install copies undeclared directories, the executable bit survives, the entry is reachable as a bare shell command, confirmed via negative control -- measured against a real install rather than assumed from documentation (#​868). A follow-up correction to that plan notes that the claimed containment helper imports don't actually exist yet as exports; extracting resolveReviewArtifactPath, hasParentDirectoryTraversal, and pathContainsSymlink from src/cli.ts is a prerequisite the file list should call out rather than assume.

Compare

v3.14.4...v3.14.5

v3.14.4

Compare Source

What's new

Bug Fixes

Five bundled skills invoked helper scripts with bare relative paths — things like bash references/resolve-base.sh — which a shell resolves against the working directory (the user's project) rather than the directory the skill was actually installed into. These invocations could never work, in any repository, including this one. Each call now resolves through a SKILL_DIR variable set from the directory the harness reports when the skill loads, with every fenced block setting the variable itself since blocks are copied and run independently. A follow-up fix closed a related gap where some hosts flatten a fenced block into a single line: an unterminated SKILL_DIR="..." assignment then collapses into the env-var-prefix form, causing the shell to expand the variable from the outer scope before the assignment takes effect and reproducing the same broken path by a different route. All twenty anchors now terminate correctly, and a new test covers the four properties these invocations depend on (#​862).

A persona that omits the tools frontmatter field is not equally restricted across harnesses: on Pi it resolves to a read-only set (read, grep, find, ls), but on OpenCode the same omission means no restriction at all, because the comma-separated string form isn't the map shape OpenCode expects and is silently ignored. Two personas were caught by this divergence with their capabilities backwards relative to their jobs — the PR comment resolver (which is supposed to implement fixes) and the bug reproduction validator (whose entire purpose is running reproductions) both effectively had no working tools declared. Both personas now explicitly declare the tools their instructions already assume. Granting shell access to the validator also required a new untrusted-input rule, since its input is a bug report — text that routinely arrives pasted from an issue tracker or a stranger's terminal — and instructions embedded in that text must never be treated as instructions to the agent (#​861).

Documentation

A proposal to add an MCP server to the Claude Code bundle, premised on the bundle having no way to execute anything, was disproven by a local install: the install copies the whole plugin tree rather than only the manifest-declared components, preserves the executable bit, and bin/ reaches the Bash tool's PATH. The real constraint turned out to be packaging, not execution — shipping the existing CLI failed three separate ways (a sibling-chunk import, externalized runtime dependencies with no node_modules to resolve them, and a UMD module with an AMD branch that no bundler can follow). An entry point that imports only the single module the surface needs avoids all three failure modes. The learning captured here: an unshippable dependency may have arrived through entry-point scope rather than through the feature being shipped, and is worth checking before being written off as fatal (#​865).

Adding a module under src/lib/ has always carried two registration obligations, but only the ARCHITECTURE.md codemap was documented — the src/lib/AGENTS.md module table is equally required and equally gate-enforced (checkCodemapCompleteness and checkLibModuleTableCompleteness in scripts/content-integrity.ts). The guidance now names both obligations and the verification command, and points the intentional-omission escape hatch at whichever document the exclusion actually belongs to, rather than assuming the codemap (#​863).

Also in this release

• deps: update dependency @biomejs/biome to v2.5.10 (#​864)

Compare

v3.14.3...v3.14.4

v3.14.3

Compare Source

What's new

Bug Fixes

ce-plan's plan template records an origin field pointing at the brainstorm requirements document a plan was built from. Some repositories deliberately don't track that directory, treating requirements as local planning input the plan itself supersedes — which meant every plan generated from such a repo carried a link that resolved to nothing once cloned elsewhere. The field itself is correct to keep: it preserves real provenance for whoever wrote the plan, and dropping it in favor of a second, equally-authoritative document just creates staleness the moment the plan lands. What was missing was a way for a reader to distinguish context they're missing from context that was never shared in the first place. The Sources entry now states explicitly when the origin path is untracked, and the field contract documents why that's a legitimate state rather than a broken link. The deepening pass previously assumed the origin file would always be readable; it now falls back to continuing from the plan alone and records that the fidelity check couldn't run, instead of reporting a missing file (#​860).

Documentation

A new solutions note captures a diagnostic lesson from an incident where three dependency upgrades failed simultaneously and two were initially misdiagnosed from version numbers alone. The tree-sitter runtime failure looked like a grammar/ABI mismatch — the grammar trails the runtime by a minor version, peers pin the older range, and both were locked to the same line — but it was actually a renamed WASM asset; loading the pinned grammar under the new runtime confirmed the ABI was never involved. What obscured the real cause is that the command classifier fails closed: every shell classification came back unavailable, so forty-four assertions reported a classification result rather than surfacing a missing file, meaning the component was accurately describing its own state while saying nothing about the underlying cause. The third failure, a YAML dependency bump, looked like an ESM-only migration but the package still ships both formats — only the default export was removed — and because the importing module is the most depended-on file in the tree, the breakage fanned out across packaging, module resolution, and codegen in a way that reflected centrality rather than severity (#​858).

Compare

v3.14.2...v3.14.3

v3.14.2

Compare Source

What's new

Build System

This release lands two dependency-maintenance changes that both required real verification work rather than a rubber-stamped version bump.

OpenCode was updated to v1.18.21 (#​856). Renovate had proposed v1.18.19, but moving the OpenCode pin invalidates the evidence gathered at the old version and costs a seventeen-minute suite run against the real host — landing one patch behind current would mean paying that cost twice to catch up, so this bump goes straight to the latest published version instead. Four places have to agree or a guard fails: both OpenCode devDependencies, the expected version in the eval runner, and the exact version in the receipt workflow fixture. The version-dependent suite was re-run at 1.18.21 rather than assumed — fifty-one tests pass across the eval runner, artifact, and fixture files.

The tree-sitter runtime and grammar dependencies were grouped into a single change (#​857). web-tree-sitter is the WASM runtime and tree-sitter-bash is the grammar it loads; a grammar is compiled against an ABI version and the runtime accepts a range, so moving one without the other can land the pair outside that range. Both are pinned exactly rather than with a caret for that reason, but nothing had previously stopped them from being proposed separately. The risk became concrete when the 0.26 bump renamed the runtime's exported WASM file, breaking every call site that resolved the old name — the command classifier fails closed, so forty-four tests failed without a single parse having been attempted, and the fix belonged in the same change as the bump. Grouping these dependencies means that class of change now arrives as one reviewable PR instead of a half that cannot pass on its own.

Compare

v3.14.1...v3.14.2

v3.14.1

Compare Source

What's new

Bug Fixes

Updated the web-tree-sitter dependency to v0.26.12, which surfaced a real regression rather than being a routine bump. The new runtime renamed the WASM asset it exports, from tree-sitter.wasm to web-tree-sitter.wasm, and three places in the codebase still asked for the old filename — so grammar resolution failed before the parser was ever initialized. Because the command classifier fails closed, every shell operation it needed to classify came back unavailable and minted no evidence, and forty-four tests failed without a single parse having been attempted. The grammar itself was never the problem: tree-sitter-bash 0.25.1 declares ABI 15, and the 0.26.12 runtime accepts ABI 13 through 15, so the pinned grammar continues to parse real commands correctly once the asset reference points at the renamed file. (#​727)

Documentation

Drafted a plan for an MCP server in the Claude Code bundle. Systematic reaches Claude Code as markdown only, so bundled prose that names the command line tool can't be satisfied there — Anthropic documents two ways a plugin can reach executable capability, and the current bundle uses neither, making the gap a build choice rather than a limit of the harness. The plan adds a stdio server declared in the bundle and launched on enable, exposing review artifact validation as a callable tool, sequenced across six units so the server exists before anything references it. Two findings reshaped the plan along the way: the validation path anchors its containment root to the process working directory, and a server started by the harness doesn't have the project as its working directory, so every validation would have failed silently without adjustment; and the published package version at rest is a placeholder, so the launch reference has to come from the release job rather than the manifest. A companion claim about symlinked ancestors did not survive checking and is recorded with the scope it was actually measured in. (#​855)

Compare

v3.14.0...v3.14.1

v3.14.0

Compare Source

What's new

Small, focused release: the review artifact contract can now say exactly why a validation didn't run, and a solutions doc that quoted the old, unconditional version of that instruction has been corrected.

Features

ce-review: Unrun validations in the review artifact now record exactly where and why. Previously the contract told the parent to note that a validation didn't run, without saying where that note should live — neighboring rules in the same file name their fields, so this one read as an instruction with nowhere to land (#​853).

The run artifact now carries a validation object with an explicit status: passed, failed, unavailable, or not_attempted. A reason is required for the three non-passing states and rejected for passed, since a check that succeeded has nothing to explain and the field shouldn't invite narration. The object deliberately does not reuse the existing coverage object — a validator_failures list already lives there and refers to the per-finding validation pass, a different mechanism that happens to share the word "validation." Keeping them apart is the point of the change.

The status is self-reported: an agent can claim passed without having run anything, so this is not evidence that validation happened. What it buys is that four outcomes which previously produced one identical silence can now be told apart.

A follow-up commit tightened the documentation itself: the paragraph wiring the unavailable status to its trigger left the not_attempted case to inference, using the word "skipped" twice without ever pairing it with the status name. Both trigger conditions now name their status explicitly where the distinction is drawn.

Documentation

A learning captured in docs/solutions/ describing the review artifact contract had gone stale the day after it was written. The note quoted the unconditional form of the validator instruction as the shipped design — but that instruction was corrected a day later, after it reached a harness with no executable to run (#​852).

Two passages were wrong. The worked example told a reader to run the validator command outright, and the honest-limitation passage repeated the claim that an agent producing no evidence is an acceptable outcome, without the distinction the contract now draws between an agent choosing not to run a check and being unable to. The packaging section also gains the half the incident exposed: getting the validator into a reachable location is not the same as every reader of the contract being able to invoke it — bundled prose is copied into all three harness packages, while the bin entry only reaches installs of the npm package. An instruction naming a command has a wider reach than the command itself.

Compare

v3.13.7...v3.14.0

v3.13.7

Compare Source

What's new

Bug Fixes

The ce-review synthesis contract told the parent agent to run a validator after writing the run artifact, with no condition attached to whether that validator existed. That instruction shipped verbatim into the Claude Code bundle, which is built without npm coupling and carries no executable at all — so an operator there was told to run something that cannot exist. The failure mode was silent in the worst available way: the same section said an agent that never runs the command produces no evidence either way, making an impossible command and a skipped one indistinguishable in the record. The instruction now states the condition under which the validator is reachable and says what to record when it is not, so unavailable and skipped are no longer conflated (#​851).

Documentation

A learning written on 16 August had already named the exact reason the review dedup fingerprint cannot match two reviewers describing one defect. An issue was filed against that same fingerprint on 20 August with the wrong cause, and the right cause was worked out again from scratch on 23 August — the answer had been sitting in docs/solutions the whole time. It was unfindable: its frontmatter read module: measurement with tags about evidence and instrument validation, naming neither the skill it came from nor the algorithm it described. Someone debugging deduplication searches for deduplication, not for an epistemics lesson they haven't learned yet. The fix splits the two jobs — the title and body carry the general lesson, the frontmatter carries the particulars someone would actually search for — adding three tags to the older note was enough to make it reachable without disturbing its framing. It also fixes the knowledge-track template, which still listed four problem types after four more were added, and syncs the copy the refresh skill keeps (#​850).

Also in this release

• deps: Renovate bumps and minor dependency updates (fro-bot/agent to v0.105.0, bfra-me/.github to v4.20.0).

Compare

v3.13.6...v3.13.7

v3.13.6

Compare Source

What's new

Bug Fixes

ce-review: The risk-aware degraded verdict in code review dispatch used to block unless another persona "covered the same surface" — a judgement call with no formal definition, so identical diffs and identical review findings could pass or block depending on who read them. Four independent reviewers of the change that introduced the rule ran into exactly this ambiguity.

The fix keeps signal that was already being computed and discarded: Stage 3 dispatch selection already determines and announces why each conditional persona was chosen, naming the endpoint or migration that triggered it. That reasoning is now recorded on the dispatch alongside the changed files, and "coverage" becomes a mechanical test — a validated finding covers a lost surface when its file is one of the recorded paths. A blocked verdict now states what would clear it (re-run the lost persona, or supply a validated finding on one of the recorded paths), and the verdict cites the specific finding that satisfied coverage so the decision can be reproduced from the artifact instead of taken on trust (#​847).

A follow-up refactor in the same change widened the risk-critical persona-name tuple from an asserted cast to readonly string[], removing a type assertion that claimed an arbitrary string was one of five literals without anything actually checking it. Behavior is unchanged — all five risk-critical personas still require a selection surface, and always-on personas still do not.

Compare

v3.13.5...v3.13.6

v3.13.5

Compare Source

What's new

Bug Fixes

ce-review: Finding deduplication was keyed on a fingerprint that included each finding's normalized title. Because two reviewers rarely phrase the same finding the same way, the fingerprint almost never matched, so near-duplicate findings from independent reviewers passed through as separate results instead of being merged.

Measuring stored review runs quantified the problem: across twenty runs there were 375 cross-reviewer pairs of findings on the same file — 55 of them within three lines of each other and 39 on the exact same line — and none of them ever merged. That means the confidence boost meant to fire when independent reviewers converge on the same issue had never actually fired.

Line proximity was never the real signal, and prose files weren't a special case either. Grouping is now mechanical and file-only, and the decision about whether two findings describe the same underlying defect is left to judgement — the one thing the model running this stage is actually good at. Declining to merge two findings is now recorded along with a reason: a wrong merge is obvious to a reader, but a missed merge just looks like two separate findings, so recording the decision either way leaves a trace.

A follow-up commit clarified how a partially-merged candidate group is recorded: when a group of three findings has two that merge and a third that doesn't, one entry is written per declined separation, naming the IDs on both sides of it — so a three-finding group with a partial merge produces a single entry listing all three. A group that merges completely produces no declined-separation entries at all.

Compare

v3.13.4...v3.13.5

v3.13.4

Compare Source

What's new

Bug Fixes

Planning previously could name a new file and its test but omit the registration obligations elsewhere — a codemap entry, a module table row, a manifest listing, or a generated artifact — until a gate failed or, worse, never caught the gap at all. ce-plan now carries registration obligations into the unit that actually creates the file, using the contributor guidance it already reads to name both the surfaces that must list the new file and the command that regenerates them (#​845).

The src/lib module tables in src/lib/AGENTS.md had drifted from the codemap in ARCHITECTURE.md, documenting only 19 of 34 modules despite both being intended to cover the same set. This is now gated the same way the codemap already is: a content-integrity check fails when a module exists without a table row, or a row names a module that doesn't exist — including a visible exclusions escape hatch for intentional omissions. The fix also adds the fifteen missing modules (including the previously undocumented receipt-guard subsystem), corrects two false export claims caught during an audit of all 155 export claims across the 34 rows, and hardens the gate to fail loudly rather than silently collapsing two modules that share a basename in different subdirectories (#​844).

Documentation

The architecture overview and structure tree still described a CLI with three subcommands, but it has grown to six — including two that ship user-facing behavior, capabilities and validate-review-artifact. Docs now cover the full CLI surface and document the review artifact contract as the real enforcement mechanism it has become: a Zod source, a generated schema committed under the skill, a drift gate, and a CLI validator shipped in dist. Every count in the three root documents was re-enumerated against the actual tree rather than searched for by expected value, which caught four stale test counts across four different phrasings (#​843).

Compare

v3.13.3...v3.13.4

v3.13.3

Compare Source

What's new

Bug Fixes

The ce:review contract specified writing a metadata.json file alongside the review summary, capturing the run ID, branch, HEAD, harness, verdict, and completion time — but no run had ever written it, and nothing in the repository read it. The instructions even described downstream skills falling back to file mtime when the file was absent, documentation for a consumer that was never built.

Investigation found that half of the contract had already collapsed on its own: the run artifact's schema already carries run_id, harness, and verdict, and every real artifact on disk includes a verdict despite the (unwritten) contract placing that field elsewhere. Only branch, HEAD, and the completion timestamp were still homeless, so this fix moves those three fields into the artifact that is actually produced and validated (#​842, 476a3b6).

The distinction the original design was reaching for still holds: branch and HEAD are captured at dispatch time, before any autofix lands, while the run artifact is written after the verdict is final — so a reader can tell whether the recorded state describes the checkout in front of them. Only the destination changed, not the semantics.

An earlier attempt to delete the dead metadata.json contract outright was dropped because the supporting evidence was flawed: a claim of zero writes across twenty-six runs counted twenty runs that predated the field's existence. This fix instead rests on two facts that don't depend on that count — there is no reader for the file, and three of its six fields already live elsewhere.

Compare

v3.13.2...v3.13.3

v3.13.2

Compare Source

What's new

Bug Fixes

ce:compound-refresh carried its own copy of the solution-document contract that ce:compound writes against, and that copy had drifted. It recognized four fewer knowledge-track problem types than the canonical contract, so documents filed as architecture_pattern or convention — three of which already exist in the repo — read as invalid to the very skill responsible for judging whether they're correct.

The bigger issue was two missing YAML quoting rules. Without them, a value containing a space followed by a hash ( #) is silently truncated by the YAML parser with no error raised. Because ce:compound-refresh's entire job is rewriting documents, it was exactly the surface where losing that rule would reintroduce the bug it exists to prevent.

Both files are now byte-identical to their ce:compound counterparts — matching the resolution template the two skills already shared. A new test asserts all three shared files stay identical and that the two knowledge-track enums parse to the same set, so this drift can't recur silently. The duplication itself stays intentional: the Claude Code build flattens each skill into a self-contained bundle, so having one skill point at another's file isn't safe across harnesses. The compound-docs copy of the contract is untouched — it has no track sections and predates this contract, so aligning it is a separate decision. (#​841)

Compare

v3.13.1...v3.13.2

v3.13.1

Compare Source

What's new

A small maintenance release: a fix to the knowledge-doc categorization schema and two new solution-doc learnings drawn from the review artifact contract work.

Bug Fixes

• ce-compound: The knowledge-track schema accepted architecture_pattern, design_pattern, tooling_decision, and convention as valid track values, but the reference guide's track table listed none of them and gave none of them a category directory — an author choosing one of these four had a valid problem_type and nowhere to file the document. All four now map to best-practices/, the directory where documents already using these tracks were already being filed, rather than splintering into four directories that would each hold a single document. The guide also now states that the narrowest applicable value is preferred, gives a one-line description of what each of the four tracks means, and clarifies that the knowledge-track field rules apply to every type in the table, not just the original four.

Documentation

• Adds a learning on why an artifact contract with no validated write path ends up with no conforming producers, drawn from measuring review-run artifacts before scoping issue #​793: seven artifacts across 26 runs, no two sharing a shape, every documented ledger field absent, and an undocumented field present in all of them.
• Extends the existing input-set learning with a third contaminant beyond gitignored build output and ambient user config: standing on the wrong branch, which defeats the usual "check for untracked/dirty files" recommendation because another branch's tracked files are clean and so never show up as ignored or dirty.
• Documents a verification method: correcting a repeated fact by searching for one phrasing leaves other occurrences worded differently, so enumerate the individual claims instead — doing so turned up an error nobody was looking for. The learning's title was broadened from counts to repository claims generally, since it now covers whether a documented path exists at all.

Compare

v3.13.0...v3.13.1

v3.13.0

Compare Source

What's new

Features

The review pipeline now validates its own run-level artifact instead of trusting it by convention. ce:review writes two kinds of artifact — per-persona records, which the parent has always validated before persisting, and the run-level review-summary.json, which nothing checked. An audit of 26 runs found 138 per-persona files sharing 21 shapes (111 identical), against 7 run-level artifacts with 7 distinct shapes written under two different filenames.

The run artifact now has a Zod source of truth, with the input ledger modeled as a discriminated union on record_type so admitted rows and rejected-payload summaries are machine-separable without inferring state from which keys happen to be present. A generated JSON Schema is committed and gated against drift, and validation ships as a new CLI command, systematic validate-review-artifact <path>, distinguishing four outcomes — valid, schema violation, operational failure (missing file, malformed JSON), and pre-contract legacy artifacts with no schema_version. Error output is projected through an explicit allowlist so validation failures never echo review content back into logs. The ce:review skill now requires the parent to stamp schema_version and run the validator immediately after writing, with a stated failure path: repair and re-run, never report a verdict over a failing artifact, and never delete it to dodge the check (#​830).

Documentation

Project docs had drifted from the tree they describe: skills were listed as 45 against 31 on disk, agents as 51 against 37, unit tests as 20 against 59 (later corrected again to 56 to match this branch), and integration tests as 2 against 11. Two script roles were also swapped in a way that could mislead a reader following them — build-registry.ts was documented as the drift checker, when drift is actually checked by generate-registry.ts (which regenerates registry.jsonc from skill and agent frontmatter), while build-registry.ts builds the OCX packument from the already-synced file. Undocumented parts of the tree — the Pi extension entry point, the evals harness and runner, and the codegen/drift-check scripts for Pi personas, the agent-browser skill, and the review artifact schema — are now described, and a script that only exists on an unmerged branch was removed from the list. Every backticked repository path in both files was checked for existence against this branch rather than spot-checked (#​831).

Continuous Integration

Renovate's package rules now give release-pipeline packages a minimum release age of three days before they're picked up, and group semantic-release and conventional-changelog-conventionalcommits major updates under a single rule so they land together rather than piecemeal. A follow-up fix adjusted the package matching to include semantic-release-export-data for more accurate dependency management (#​835).

Also in this release

• build(dev): Bump conventional-changelog-conventionalcommits to v10.4.0.
• deps: Add a conventional-changelog-writer override; bump bfra-me/.github, fro-bot/agent (three releases), and github/codeql-action.
• dev: Bump @biomejs/biome, agent-browser, and typebox (twice).

Compare

v3.12.4...v3.13.0

---

Configuration

📅 Schedule: (in timezone America/Phoenix)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.