Repository navigation
v3.12.0
What's new
Features
This release grounds ce:plan in existing code before it lets a plan proceed, closing a gap where an agent could plan a duplicate of a subsystem it never looked for. Planning now dispatches a prior-art scope alongside its existing research: the survey receives the concern as trigger, effect, state, and boundary rather than a proposed design, so it cannot inherit the planner's framing and can't quietly confirm a solution shape it was handed. It bounds itself to a workspace and a stated budget, collects every plausible candidate before dispositioning any of them, and describes what each one owns in the vocabulary the code itself uses — because a subsystem named in accounting terms is invisible to a search framed in enforcement terms, even when its files are in view.
The survey's result is a validated JSON contract, not prose: a missing or malformed block now gets a specific remediation instead of dissolving into unverifiable narrative. Five verdicts are available and the schema constrains what each may claim — building something new requires naming the candidates that were insufficient, an unpickable scope requires naming the scopes that were weighed, and running out of budget preserves whatever was already found rather than discarding it. A unscoped or unresolved verdict now stops planning until the scope narrows or a user explicitly accepts the uncertainty, and that acceptance is recorded so later stages can tell it apart from a verdict nobody handled. The survey also carries a freshness record — a version-control reference or a portable baseline — so work execution can refuse a plan whose surveyed scope has drifted since the survey ran, and plan review confirms each named candidate resolves to real code rather than taking the survey at its word. Plans written before this contract still run; a missing survey section is treated as pre-dating it, not as a failure.
Alongside the survey, the content-integrity gate gained two new checks against root documentation. One compares the hooks a document claims the plugin registers against the typed inventory the plugin entry point actually returns — closing a hole where a document could assert "all hooks" while enumerating only half of them and still pass. The other compares the modules named in the architecture codemap against the modules on disk in both directions, so an undocumented module and a stale codemap entry for a deleted one both fail the build. Together these catch the exact failure mode that motivated them: four contributor-facing documents claiming the plugin registers three hooks when it registers six, with the three unmentioned hooks being the ones the workflow guard runs on.
Documentation
The documentation gap the new content-integrity checks were built to catch is fixed in the same window: ARCHITECTURE.md, STRUCTURE.md, .github/copilot-instructions.md, and AGENTS.md all previously claimed the plugin registers three hooks, when src/index.ts registers six — including the three observation hooks (tool.execute.before, tool.execute.after, and event) that the workflow guard depends on. An agent orienting from any of those documents could reasonably conclude the plugin has no enforcement path. ARCHITECTURE.md now describes the workflow guard directly: what the observation hooks feed, how operations get classified, what a receipt proves, and that it's OpenCode-only. The project-local documentation-generation skill had also hardcoded "three hooks" into its own template, which meant regenerating ARCHITECTURE.md would have restored the error; the template now derives hooks from src/index.ts at generation time instead of carrying a frozen list.
A separate solutions entry records three verification boundaries discovered while shipping the dispatch-identifier gate. First, the release pipeline has two stages with opposite commit-body ingestion: release-notes-generator reads subject lines only, but the release-notes-narrative skill (the one producing this note) reads every commit body and, when thin, the originating PR description — so a commit body does reach the published notes, just through the second stage rather than the first. Second, releaseRules is scope-aware while presetConfig.types is not, so a non-releasing commit can still earn a notes section; v3.11.0's Documentation section opened by quoting an internal planning label for exactly this reason. Third, tsconfig.json scopes typecheck to src/**/* only, leaving the eight files under scripts/ — including content-integrity itself — untypechecked; a deliberately injected type error and a call to an undefined function both passed bun run typecheck silently.
Also in this release
- deps: Updated
bfra-me/.githubto v4.17.1.