build(deps): update dependency @fro.bot/systematic to v2.24.0

[fro-bot]

This PR contains the following updates:

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

---

Release Notes

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

v2.24.0

Compare Source

What's new

Features

Adds a docs:verify script that runs the exact three-command sequence the CI Docs Build job runs — bun install --frozen-lockfile, bun run --cwd docs playwright install --with-deps chromium, and bun run docs:build — so a docs-framework Renovate PR (Starlight, Astro, expressive-code, etc.) can be locally pre-verified before approval.

The motivation is concrete: PR #​444 (Starlight 0.38→0.39) cleared every local gate — typecheck, lint, content-integrity, registry-drift, unit tests — and only failed at CI's Docs Build step, because Starlight's astro:config:setup hook runs exclusively under a real Astro build. The fix was straightforward, but the round-trip to CI cost time that docs:verify eliminates. This was the second such incident in two weeks.

The script is a single chained shell command rather than a separate shell file: zero new files, zero new dependencies, zero new documentation surface beyond the AGENTS.md line that names it. On a hot cache the whole run takes ~5 seconds; on a cold cache the Playwright Chromium download dominates (~30–60 s).

Compare

v2.23.6...v2.24.0

v2.23.6

Compare Source

What's new

Bug Fixes

Starlight 0.39.0 removed the { label, autogenerate } shorthand syntax for sidebar groups. Without a corresponding migration, the docs site would fail to build with a config-validation error.

This release updates @astrojs/starlight to ^0.39.0 and migrates the four affected sidebar entries — Getting Started, Guides, Skills, and Agents — to the new { label, items: [{ autogenerate: { directory } }] } shape that Starlight 0.39 requires. The Reference > Configuration entry and the top-level Reference group were already using compatible forms and needed no changes.

The updated docs build emits 110 pages, pagefind indexes 112 HTML files, and the sitemap is generated cleanly with no config-validation warnings.

Compare

v2.23.5...v2.23.6

v2.23.5

Compare Source

What's new

Security hygiene and documentation completeness — a defense-in-depth fix for a long-standing static analysis warning, companion documentation for the May sprint arc, and a set of plan records updated to reflect what actually shipped.

Bug Fixes

A CodeQL js/incomplete-multi-character-sanitization alert (#​31) on docs/scripts/transform-content.ts had been stable in the weekly maintenance report for over five weeks. The cleanDescription helper was using a single-pass replace(/<[^>]+>/g, '') strip — the textbook shape the analyzer flags, because adversarial input like <<tag> survives one pass with the leading < intact.

The trust boundary here is real: this helper only runs against committed SKILL.md and agent frontmatter description fields, never against runtime user input. The fix iterates the strip to a fixed point so any residue from the first pass is caught on the next, and a comment above the loop documents the constraint explicitly for future contributors who might reach for the helper in a higher-trust context. No build output changed; docs:build still emits the same 110 pages.

Documentation

Two documentation efforts closed out the May 22–23 sprint arc:

Plan status reconciliation (#​438): Three plan docs from the sprint were still marked status: active despite all their work shipping in merged PRs. The fix sets each to status: completed with a shipped: block carrying the PR number, release tag, and date. The CI automation plan doc also enumerates the four hotfix PRs (#​431–#​434) that followed the initial merge, giving future readers a complete picture of the delivery sequence.

Solutions compound (#​437): Two solution docs were refreshed with verified-in-production content from the five-PR chain (PRs #​430–#​434) that landed end-to-end CI release-notes-narrative automation. Key updates include:

• The architecture doc's trigger-chain block now reflects the final scripts/dispatch-release-notes.sh + timestamp-based identification design, replacing the original inline successCmd + log-scan approach.
• The "Correlation-token-based polling" decision was replaced with "Timestamp-based polling with correlation as audit anchor," documenting the v2.23.3 production failure (Fro Bot bootstrap time exceeding the 90s log-scan budget) and the v2.23.4 fix (DISPATCH_EPOCH + gh run list createdAt filtering).
• A new "Production Verification" section captures the four-failure-mode table and the structural lesson: mock-based integration tests cannot model real-world Lodash rendering, GitHub API contract validation, or agent runtime characteristics.
• The semantic-release-body-ingestion-myth doc was updated with a pointer to the v2 CI architecture and a clarification that the underlying myth remains true.

Also in this release

• build(dev): Update OpenCode through v1.15.6 → v1.15.7 → v1.15.8 → v1.15.10 (#​436, #​439, #​441, #​442)
• build(dev): Pin @semantic-release/exec to 7.1.0 (#​435)
• deps: Update all non-major dependencies (#​440)

Compare

v2.23.4...v2.23.5

v2.23.4

Compare Source

What's new

Bug Fixes

The release-notes-narrative automation chain gains its fourth consecutive hotfix, this time replacing the log-scanning strategy for identifying dispatched Fro Bot runs with a timestamp-based approach.

v2.23.3 (#​433) had resolved the HTTP 422 input-validation problem and Fro Bot's dispatch was actually firing. But the polling loop in dispatch-release-notes.sh timed out after 90 seconds trying to match the dispatched run by scanning its early log lines for the correlation token. The token never appeared within that window because the Fro Bot OpenCode agent has a substantial bootstrap sequence — runner spin-up, full checkout, bun install, model/auth setup, and MCP server startup all happen before any prompt-derived content reaches the run's logs.

The fix captures a DISPATCH_EPOCH timestamp immediately before gh workflow run, then polls gh run list --event=workflow_dispatch for the newest run whose createdAt is strictly greater than that epoch. Because gh run list reflects run-creation time rather than first-log time, the dispatched run is visible to the API as soon as it's registered — long before the agent boots — so identification is reliable regardless of how long startup takes.

The correlation-id field is preserved as a secondary audit anchor. It's still passed to gh workflow run and still declared in fro-bot.yaml, so it appears in the run's inputs metadata for any future debugging session, but it is no longer the primary identification mechanism.

Test coverage was updated alongside the fix: makeRunListJson now accepts an optional createdAt argument and defaults to a far-future ISO timestamp so the default run is always selected by the timestamp filter; the scenario for correlation-via-log-scan was replaced with a "no run created after dispatch epoch" scenario (exit 1); and a new scenario was added for the newest-wins case when two runs have different future createdAt values. The suite grew from 19 to 20 passing tests.

A follow-up commit refreshed the block comment in dispatch-release-notes.sh (which still described the old log-scan strategy), updated the prompt body to drop the now-obsolete instruction to echo the correlation token, and renamed a stale test fixture suffix (scenario-18) to a scenario-agnostic name.

Compare

v2.23.3...v2.23.4

v2.23.3

Compare Source

What's new

Bug Fixes

The third hotfix in the release-notes-narrative v2 automation chain resolves the final blocker preventing fully automated post-release narrative generation.

After v2.23.2 published (which fixed the missing dispatch-release-notes.sh script), the Release CI job was still failing with HTTP 422: Unexpected inputs provided: ["correlation-id"]. The root cause: dispatch-release-notes.sh passes a UUID correlation token as a structured -f correlation-id=... workflow dispatch field so that the polling loop can identify the correct Fro Bot run, but fro-bot.yaml had never declared correlation-id as a known input. GitHub's Actions runtime validates every field in a workflow_dispatch or workflow_call invocation against the workflow's declared inputs: block and rejects any unrecognized name.

This fix adds correlation-id as an optional string input to both the workflow_dispatch and workflow_call entry points in fro-bot.yaml. The field is purely a polling correlation primitive — Fro Bot echoes it as its first log line so the dispatching script can scan early job output and match the run unambiguously, eliminating same-second collision risk. No existing entry point (PR comments, issue events, scheduled maintenance) is affected; they simply omit the field, which is valid for an optional input.

With this declaration in place, the end-to-end acceptance gate for v2 — where a published release automatically triggers Fro Bot to rewrite its notes — can proceed without operator intervention.

Compare

v2.23.2...v2.23.3

v2.23.2

Compare Source

What's new

The release-notes-narrative v2 automation no longer crashes the Release job on bash parameter expansion. v2.23.0 and v2.23.1 both shipped to npm successfully but failed their Release job with SyntaxError: Unexpected token ':', because @semantic-release/exec renders the entire successCmd YAML block through lodash-es template() with no escape support — every ${...} in the bash script (including ${VAR:-default} parameter expansion and even ${...} inside comments) was being evaluated as a JavaScript expression.

The fix moves the dispatch logic out of the YAML scalar entirely. The successCmd: is now a one-line invocation of an external script:

successCmd: 'scripts/dispatch-release-notes.sh "${nextRelease.gitTag}"'

scripts/dispatch-release-notes.sh receives the target tag as $1 and is otherwise a normal shell script — no Lodash collision surface. The only template interpolation Lodash sees is the one we want: the target version from semantic-release context.

This is the third hotfix in the v2 automation sequence. The two earlier attempts (#​430 introduced the inline successCmd; #​431 tried to fix it with backslash escapes) failed because Lodash's default template settings have no backslash-escape semantics — \${VAR} still evaluates VAR as JavaScript and just leaves the backslash as a literal character in the output. Verified empirically by running template('\\${VAR}')({}) locally and observing the same is not defined error.

The 19 integration tests in tests/integration/release-notes-ci.test.ts continue to cover the full dispatch chain: tag validation, correlation-token generation, polling fallback, conclusion-taxonomy classification (success, neutral, failure, cancelled, timed_out, action_required, skipped), security signals (HTTP 401/403, off-target release edits, body-integrity check post-write), and unexpected gh run watch exit codes.

The fourth hotfix in this chain (still in flight at PR #​433) addresses a separate production failure surfaced by this release: gh workflow run rejected the dispatch with HTTP 422: Unexpected inputs provided: ["correlation-id"] because the fro-bot.yaml workflow did not declare correlation-id as a valid workflow_call/workflow_dispatch input. That fix adds the input declaration. v2.23.2's release notes you are reading right now were rewritten manually using the v1 skill procedure.

v2.23.1...v2.23.2

v2.23.1

Compare Source

Bug Fixes

• release: escape bash ${VAR} for Lodash render in successCmd (#​431) (d07b090)

v2.23.0

Compare Source

Features

• release: automate release-notes-narrative skill via @​semantic-release/exec (#​430) (cbe4c33)

v2.22.0

Compare Source

What's new

Features

A new project-scoped skill at .agents/skills/release-notes-narrative/ that turns sparse semantic-release output into useful changelog narrative. The skill is loaded on demand by any agent to patch a published GitHub release body via gh release edit --notes-file, defending against two known release-notes-generator failure modes already observed on this repo: bare bucket bullets (semantic-release ingests only commit subject lines, never commit bodies or PR descriptions) and spurious closes [URL-fragment] autolinks (the generator misparses path#fragment substrings in commit bodies as Closes #N footers).

The skill ships as a 13-step procedure with a hardcoded bucket map mirrored from .releaserc.yaml, a calibrated thin-commit-body threshold for triggering PR-body enrichment, and a 4-condition AST-based autolink-strip allowlist with documented positive and negative examples. Three-layer defense for the live gh release edit step (pre-edit snapshot, preflight check, post-edit rollback) keeps blast radius bounded. Structural idempotence — same buckets, same Compare link, same referenced PRs across reruns — is the explicit guarantee; LLM-generated narrative prose is allowed to vary by run (#​429).

This release is itself the first dogfood: the skill was applied to v2.20.5, v2.20.6, and v2.21.0 retroactively as acceptance evidence before merge, and the v2.22.0 release notes you're reading now are the skill's output.

Compare

v2.21.0...v2.22.0

v2.21.0

Compare Source

What's new

Launch-surface cleanup — the first ~30 seconds a developer spends with this project. README, home page, Quick Start, config docs, and contributor docs now tell a coherent story instead of repeating each other.

Top-level docs split

AGENTS.md was carrying three audiences in 188 lines. Split into:

• ARCHITECTURE.md — bird's eye overview, codemap, invariants, data flow, cross-cutting concerns
• STRUCTURE.md — directory layout, per-directory purposes, naming conventions, where to add new code
• AGENTS.md — slimmed to 68 lines of contributor conventions plus a routing table that points at the other two

README rewritten

400 lines of tables + Mermaid diagram + CLI reference → 75 lines of problem-first prose. The detail moved to the docs site where it belongs.

Home page and Quick Start

• Home page rewritten as a real product landing page — concrete capability cards, the actual workflow as Steps, Quick Start snippet, and a "What Systematic Is Not" honesty section.
• New getting-started/quick-start.mdx — 5-minute walkthrough from opencode.json install to a first completed workflow (brainstorm → plan → work → review). Uses a canonical example task across every surface so the story stays consistent.

Config docs merged

Two overlapping pages (getting-started/configuration + reference/systematic-config) → one human-owned reference/configuration page with auto-generated regions injected between sentinel markers. Legacy URLs redirect to the new location.

New project-scoped skill

.agents/skills/generating-project-docs/SKILL.md replaces the old .opencode/commands/generate-readme.md slash command. Picked up automatically by OpenCode via agentskills.io discovery. Broader scope: README + ARCHITECTURE + STRUCTURE, plus scoped section updates.

SEO pass

Every page under docs/src/content/docs/ now has a real frontmatter description (120–160 chars, action-oriented).

Bug catches

• MDX {#anchor} heading syntax crashes the Astro/MDX 3 build — drop the explicit anchor; Starlight auto-slugs to the same fragment.
• Astro redirects destinations don't get base-prefixed — production-404 class. Source keys resolve against base, but destinations write verbatim. Include base manually in every destination.

Three solution docs added under docs/solutions/ capturing the learnings.

Verification

• bun test — 950 pass, 0 fail (+11 new tests)
• bun run docs:build — green
• bun run docs:dev + live-server navigation — visual rendering and redirect behavior confirmed
• ce:review (7 reviewers) — 5 non-blocking findings, all resolved before merge

Compare

v2.20.6...v2.21.0

---

Also in this release

• deps: update github/codeql-action action to v4.36.0 (#​427)

v2.20.6

Compare Source

What's new

Bug Fixes

Cleaned stale cross-references across 8 bundled skill files. Eight different broken references were corrected: three /ce-setup placeholders replaced with direct npm install -g agent-browser instructions; the self-referential ce-pr-description removed and its PR-description logic inlined into git-commit-push-pr; two ce-demo-reel references updated to feature-video; an obsolete /doc-fix removed and /compound corrected to /ce:compound; and three /todo-* references corrected to their /systematic:todo-* form (#​426).

Documentation

Two new institutional knowledge docs capturing the docs refresh arc that produced PRs #​418–#​422. The first documents the third-party design-law import pattern — merge protocol, attribution chain handling, content normalization, and GREEN verification discipline. The second documents the OKLCH color-system migration for Starlight docs — CSS custom properties, the Mermaid hex-approximation gotcha that broke the build during migration, heading-font specificity issues, and a deployment-pipeline lesson (#​423).

Compare

v2.20.5...v2.20.6

v2.20.5

Compare Source

What's new

Bug Fixes

Renovate now correctly groups @opencode-ai/* package updates under a unified "OpenCode" heading. Previously these dependency PRs were lumped into the generic "non-major dependencies" group, which made it harder to spot upstream OpenCode releases in the queue. The fix adds groupName: 'OpenCode' to the relevant Renovate package rule (#​425).

Build System

Updated @opencode-ai/plugin and @opencode-ai/sdk from 1.15.4 to 1.15.5 (#​424).

Compare

v2.20.4...v2.20.5

v2.20.4

Compare Source

Bug Fixes

• docs: modernize architecture guide (#​422) (3b1515e)

v2.20.3

Compare Source

Bug Fixes

• docs: modernize main-loop and philosophy guides (#​421) (1425dd6)

Documentation

• fix audit findings and remove stale guides (#​420) (e8a981e)

v2.20.2

Compare Source

Build System

• design: align design-iterator and docs site with Impeccable design laws (#​419) (9551607)

v2.20.1

Compare Source

Build System

• dev: update all non-major dependencies (#​414) (f2eea2d)
• dev: update all non-major dependencies to v1.15.1 (#​407) (2411e5d)
• dev: update all non-major dependencies to v1.15.2 (#​410) (c4ede66)
• dev: update all non-major dependencies to v1.15.3 (#​411) (79ab6db)
• skills: upgrade frontend-design with Impeccable design laws (#​418) (350a637)

Documentation

• plans: mark 5 shipped plans as completed with provenance (#​415) (b1ffda6)
• solutions: capture OpenCode plugin hook silent-defect-swallow pattern (#​413) (2fb32a1)
• solutions: capture v2.20.0 cycle learnings on plan-spec rigor and gh CI polling (#​406) (0e03d52), closes #​405
• solutions: compound SUBAGENT-STOP probe null result (#​417) (c100d83)

Tests

• probe: harden subagent-stop probe infrastructure + add sanity gate (#​408) (f8c22b0)

Miscellaneous Chores

• deps: update bfra-me/.github to v4.16.19 (#​416) (27ca9b3)
• deps: update fro-bot/agent to v0.44.1 (#​409) (5886459)
• deps: update fro-bot/agent to v0.44.2 (#​412) (92bbe2e)

---

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.