feat: add release workflow for version tag sync

[ggallen]

Summary

• Adds release.yml workflow triggered on semver tag pushes (v*.*.*)
• Creates a GitHub Release linking back to the corresponding fullsend release
• Moves the v0 floating tag for non-prerelease versions (same logic as fullsend)

Closes #26

Context

Tags are pushed to this repo by fullsend's release workflow after GoReleaser succeeds. This workflow handles the agents-side response: creating the GitHub Release and moving v0.

Companion PR: fullsend-ai/fullsend#3079

Test plan

• Merge companion PR in fullsend-ai/fullsend
• Cut a release and verify this workflow triggers and creates the GitHub Release
• Verify v0 floating tag is moved for non-prerelease versions

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Add GitHub Actions release workflow to sync GitHub Releases and v0 tag

✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Trigger a workflow on version tag pushes to create a GitHub Release.
• Link the release notes back to the corresponding fullsend release.
• Move the floating v0 tag forward for non-prerelease versions.

Diagram

graph TD
  A("Push semver tag") --> B["Workflow: release.yml"] --> C["Checkout (fetch-depth 0)"] --> D["Create GitHub Release (gh)"] --> E["Move v0 tag (stable only)"] --> F["Push v0 to origin"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Fix tag filter to valid GitHub Actions glob pattern

• ➕ Ensures the workflow actually triggers on intended tags
• ➕ Avoids accidental non-matching due to regex-like syntax (e.g., '+' literals)
• ➖ Minor change, but requires agreeing on supported tag formats (prereleases, build metadata)

2. Use a dedicated release action (e.g., softprops/action-gh-release)

• ➕ Less custom shell, standardized behavior for release creation
• ➕ Built-in handling for prerelease/draft flags and idempotency patterns
• ➖ Adds/depends on third-party action semantics and updates
• ➖ May still need custom logic for v0 floating tag movement

3. Move v0 tag via GitHub API instead of git push

• ➕ Avoids force-pushing tags from CI with git credentials
• ➕ Can centralize permissions/logic via API calls
• ➖ More complex implementation (API calls, refs endpoints, error handling)
• ➖ Still needs careful non-regression checks equivalent to merge-base logic

Recommendation: Keep the overall approach (tag-triggered workflow that creates a GitHub Release and advances v0) since it mirrors the upstream process and is operationally simple. However, adjust the on.push.tags pattern: GitHub Actions uses glob matching, not regex, so the current v[0-9]+.[0-9]+.[0-9]+* is likely to treat + as a literal and may not trigger. Prefer v*.*.* (as described in the PR summary) or a stricter glob like v[0-9]*.[0-9]*.[0-9]*. The v0 movement logic (merge-base guard + force-with-lease) is a good safety measure to prevent regressions.

Files changed (1) +58 / -0

Other (1) +58 / -0

release.ymlAdd tag-triggered release sync workflow (GitHub Release + v0 floating tag) +58/-0

Add tag-triggered release sync workflow (GitHub Release + v0 floating tag)

• Introduces a new GitHub Actions workflow that runs on version tag pushes, creates a GitHub Release (skipping if it already exists), and links notes back to the corresponding fullsend release. For non-prerelease tags, it advances the 'v0' floating tag while preventing regressions and pushes the tag using '--force-with-lease' when appropriate.

.github/workflows/release.yml

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:16 PM UTC · Completed 2:29 PM UTC
Commit: 10d6edb · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 55 rules

✅ Skills: 4 invoked

  code-review

  code-implementation

  pr-review

  docs-review

1. contents: write lacks justification ✗ Dismissed 📜 Skill insight ⛨ Security

Description

The new workflow grants contents: write without an explicit linked issue/ADR justification for
this permission scope. Permission expansions in workflow files must be least-privilege and
explicitly authorized.

Code

.github/workflows/release.yml[R8-9]

+permissions:
+  contents: write

Evidence

PR Compliance ID 1538383 requires least-privilege review and explicit authorization for
permission-declaring changes. The workflow adds permissions: contents: write at the workflow
level, but the PR description does not include a linked issue/ADR authorizing this permission
expansion.

.github/workflows/release.yml[8-9]
Skill: pr-review

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow introduces a permission grant (`contents: write`) without explicit authorization/justification (linked issue/ADR) and without demonstrating least-privilege scoping.

## Issue Context
This workflow creates GitHub Releases and force-moves the `v0` tag, which may require write access, but the compliance requirement still expects explicit justification and least-privilege scoping (e.g., job-level permissions and documentation).

## Fix Focus Areas
- .github/workflows/release.yml[8-10]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Tag trigger glob malformed ✗ Dismissed 📜 Skill insight ≡ Correctness

Description

The workflow on.push.tags filter is written with regex-like + quantifiers (e.g., v[0-9]+...),
but GitHub Actions tag filters are glob-based, so typical semver tags like v1.2.3 may not match
and the workflow may not run when intended. This breaks the PR’s described trigger conditions and
can prevent GitHub Release creation and the v0 floating-tag update from executing on normal
releases.

Code

.github/workflows/release.yml[R3-6]

+on:
+  push:
+    tags:
+      - "v[0-9]+.[0-9]+.[0-9]+*"

Evidence

PR Compliance ID 1538315 requires that runtime mechanisms actually trigger under the described
conditions, but the workflow is only triggered by on.push.tags and the configured tag pattern is
set to "v[0-9]+.[0-9]+.[0-9]+*", which includes + quantifiers (e.g., [0-9]+) that are regex
concepts and not operators in GitHub Actions’ glob matching. Because + is treated literally in
glob patterns, standard tags like v1.2.3 are unlikely to match, meaning the workflow will not
trigger as intended.

.github/workflows/release.yml[3-6]
.github/workflows/release.yml[3-7]
Skill: code-review

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow trigger under `on.push.tags` uses a regex-like pattern (including `+` quantifiers such as `[0-9]+`), but GitHub Actions tag filters are evaluated as glob patterns, not regex. As a result, typical semver tags (e.g., `v1.2.3`) may not trigger the workflow, preventing the release workflow from running.

## Issue Context
The PR description indicates the workflow should run on semver tag pushes (e.g., `vMAJOR.MINOR.PATCH`) to create a GitHub Release and, for non-prereleases, move/update the `v0` floating tag. The current tag filter pattern is unlikely to match standard semver tags due to the misuse of regex syntax in a glob context; a glob such as `v*.*.*` (broad) or `v[0-9]*.[0-9]*.[0-9]*` (narrower but still glob-based) would align with GitHub Actions behavior. If strict semver validation is required (including prereleases), keep the tag glob broad and add a validation step in the workflow before performing release actions.

## Fix Focus Areas
- .github/workflows/release.yml[3-7]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. No linked issue authorization ✓ Resolved 📜 Skill insight § Compliance

Description

This PR introduces a new release automation workflow (non-trivial change) but does not include a
linked issue authorizing the work. Non-trivial changes must be explicitly authorized via an issue
link.

Code

.github/workflows/release.yml[R1-58]

+name: Release
+
+on:
+  push:
+    tags:
+      - "v[0-9]+.[0-9]+.[0-9]+*"
+
+permissions:
+  contents: write
+
+jobs:
+  release:
+    runs-on: ubuntu-24.04
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          fetch-depth: 0
+
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          set -euo pipefail
+          TAG="${GITHUB_REF_NAME}"
+
+          if gh release view "${TAG}" >/dev/null 2>&1; then
+            echo "Release ${TAG} already exists, skipping"
+            exit 0
+          fi
+
+          PRERELEASE=""
+          if [[ "${TAG}" == *-* ]]; then
+            PRERELEASE="--prerelease"
+          fi
+
+          gh release create "${TAG}" \
+            --title "${TAG}" \
+            --notes "Synced with [fullsend ${TAG}](https://github.com/fullsend-ai/fullsend/releases/tag/${TAG})" \
+            ${PRERELEASE}
+
+      - name: Move v0 floating tag
+        if: "!contains(github.ref_name, '-')"
+        run: |
+          set -euo pipefail
+          CURRENT=""
+          if git rev-parse v0 >/dev/null 2>&1; then
+            CURRENT=$(git rev-parse v0)
+            if ! git merge-base --is-ancestor "${CURRENT}" "${GITHUB_SHA}"; then
+              echo "::warning::v0 already points at a newer commit, skipping"
+              exit 0
+            fi
+          fi
+          git tag -f v0 "${GITHUB_SHA}"
+          if [[ -n "${CURRENT}" ]]; then
+            git push --force-with-lease="v0:${CURRENT}" origin v0
+          else
+            git push origin v0
+          fi

Evidence

PR Compliance ID 1538390 requires a linked issue for non-trivial changes. The PR adds an entire new
workflow file (58 lines) under .github/workflows/, but the PR description does not include a
linked issue authorizing this work.

.github/workflows/release.yml[1-58]
Skill: pr-review

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR appears to be a non-trivial feature/infrastructure change but lacks an explicit linked issue authorizing it.

## Issue Context
Compliance requires that non-trivial changes have explicit authorization via a linked issue (e.g., `Fixes #123` / `Refs #123`) so reviewers can validate scope and approval.

## Fix Focus Areas
- .github/workflows/release.yml[1-58]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Protected path workflow modified ✓ Resolved 📜 Skill insight § Compliance

Description

This PR adds a new file under .github/workflows/, which is a protected governance/infrastructure
path requiring human approval and must not be auto-approved. The change should be explicitly
justified/authorized per the protected-path policy.

Code

.github/workflows/release.yml[R1-58]

+name: Release
+
+on:
+  push:
+    tags:
+      - "v[0-9]+.[0-9]+.[0-9]+*"
+
+permissions:
+  contents: write
+
+jobs:
+  release:
+    runs-on: ubuntu-24.04
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          fetch-depth: 0
+
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          set -euo pipefail
+          TAG="${GITHUB_REF_NAME}"
+
+          if gh release view "${TAG}" >/dev/null 2>&1; then
+            echo "Release ${TAG} already exists, skipping"
+            exit 0
+          fi
+
+          PRERELEASE=""
+          if [[ "${TAG}" == *-* ]]; then
+            PRERELEASE="--prerelease"
+          fi
+
+          gh release create "${TAG}" \
+            --title "${TAG}" \
+            --notes "Synced with [fullsend ${TAG}](https://github.com/fullsend-ai/fullsend/releases/tag/${TAG})" \
+            ${PRERELEASE}
+
+      - name: Move v0 floating tag
+        if: "!contains(github.ref_name, '-')"
+        run: |
+          set -euo pipefail
+          CURRENT=""
+          if git rev-parse v0 >/dev/null 2>&1; then
+            CURRENT=$(git rev-parse v0)
+            if ! git merge-base --is-ancestor "${CURRENT}" "${GITHUB_SHA}"; then
+              echo "::warning::v0 already points at a newer commit, skipping"
+              exit 0
+            fi
+          fi
+          git tag -f v0 "${GITHUB_SHA}"
+          if [[ -n "${CURRENT}" ]]; then
+            git push --force-with-lease="v0:${CURRENT}" origin v0
+          else
+            git push origin v0
+          fi

Evidence

PR Compliance ID 1538392 requires a finding whenever protected governance/infrastructure paths are
modified. This PR adds .github/workflows/release.yml, which falls under the protected .github/
path.

.github/workflows/release.yml[1-58]
Skill: pr-review

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR modifies a protected governance/infrastructure path (`.github/workflows/`). This requires explicit justification/authorization and human review.

## Issue Context
Protected paths changes should not be treated as routine feature code and must never be auto-approved.

## Fix Focus Areas
- .github/workflows/release.yml[1-58]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[fullsend-ai-review]

Review

Since the prior review (bec2e76), one commit was added (24eef7eb fix(docs): correct workflow filename in AGENTS.md) resolving the prior [doc-accuracy] finding. No workflow or permission changes. One finding remains from the prior review; one new orchestrator finding is added.

Findings

Medium

• [protected-path] .github/workflows/release.yml, AGENTS.md — This PR modifies files under protected paths (.github/ and AGENTS.md). Issue feat: add release workflow for version tag sync with fullsend #26 explicitly authorizes the release workflow addition and protected-path modification. Human approval is always required for protected-path changes, regardless of authorization context.

Low

• [file-extension-consistency] .github/workflows/release.yml — Uses .yml extension while all 13 existing YAML files in the repository use .yaml. The sibling workflow .github/workflows/fullsend.yaml follows the .yaml convention.
  Remediation: Rename to release.yaml and update references in AGENTS.md §6 and README.md accordingly.

Previous run

Review

Verdict: Approve

This PR adds a well-constructed release workflow triggered by semver tag pushes, along with comprehensive documentation in AGENTS.md and a new README.md. The workflow logic is correct: idempotent release creation, safe v0 floating tag movement with --force-with-lease CAS, proper ancestry guard against tag regression, and appropriate prerelease detection. The contents: write permission is least-privilege for the stated purpose and authorized by issue #26.

All prior review findings from the first pass have been addressed:

• Protected-path authorization (was High) — resolved by linking issue feat: add release workflow for version tag sync with fullsend #26
• Missing documentation (was Medium) — resolved by AGENTS.md §6 and README.md
• Concurrency (was Low) — resolved by adding concurrency: group: release

Two low-severity consistency issues remain.

Findings

Low

• [doc-accuracy] AGENTS.md — §6 references the workflow as release.yaml, but the actual file is .github/workflows/release.yml. The README.md correctly uses release.yml. This is a factual inaccuracy in the newly added documentation.
  Remediation: Rename the workflow file to release.yaml (preferred — aligns with all 13 existing .yaml files in the repo, and the AGENTS.md reference is already correct) or update the AGENTS.md reference to release.yml.

• [file-extension-consistency] .github/workflows/release.yml — Uses .yml extension while every existing YAML file in the repository (13 files across policies/, harness/, and .github/workflows/) uses .yaml.
  Remediation: Rename to release.yaml to match the established convention. This also resolves the doc-accuracy finding above.

---

Protected paths detected — this PR modifies files under one or more
protected paths. The review agent cannot approve PRs that touch these paths.
A human reviewer must approve this PR.

Protected files in this PR:

• .github/workflows/release.yml
• AGENTS.md

---

Labels: PR adds CI release workflow and repository documentation

Previous run

Review

Findings

High

• [protected-path] .github/workflows/release.yml — This PR adds a file under .github/, which is a protected path requiring human approval. The PR has no linked issue providing formal authorization for modifying governance/infrastructure files. The PR description and companion PR link (ci(release): sync version tags to fullsend-ai/agents fullsend#3079) provide context about the change's purpose, but protected-path changes require a linked issue for traceability.
  Remediation: Create a GitHub issue in this repository describing the need for release workflow sync and link it to this PR, or have a maintainer explicitly approve the protected-path change.

Medium

• [missing-doc] .github/workflows/release.yml:37 — The release workflow creates GitHub Releases with notes stating "Synced with fullsend ${TAG}", but there is no documentation explaining what this synchronization means, how it works, or how users should interpret version tags in this repository vs the fullsend repository. The repo has no README.md and AGENTS.md contains no information about the release process.

Low

• [missing-authorization] — Non-trivial feature addition (58-line workflow introducing new release automation) has no linked issue. The companion PR (ci(release): sync version tags to fullsend-ai/agents fullsend#3079) provides context, and AGENTS.md §3 is agent-facing guidance rather than a governance rule for human MEMBER contributors, but linking an issue remains good practice for traceability.

• [architectural-coherence] .github/workflows/release.yml:1 — The existing fullsend.yaml workflow is centrally managed by fullsend. This new independent workflow serves a different purpose (release automation vs event dispatch), but the distinction between centrally-managed and repo-specific workflows is not documented.

• [missing-doc] .github/workflows/release.yml:41 — The v0 floating tag follows the well-established GitHub Actions major-version tag convention, but its purpose and stability guarantees are not documented in this repository.

• [file-extension-consistency] .github/workflows/release.yml — Uses .yml extension while the existing workflow (fullsend.yaml) uses .yaml.

• [edge-case] .github/workflows/release.yml:47 — No concurrency group on this job. If two non-prerelease tags are pushed in rapid succession, the --force-with-lease CAS mechanism safely prevents data loss, but the second workflow run will be marked as failed. Consider adding a concurrency group to serialize runs.

---

Labels: PR adds README.md and updates AGENTS.md with versioning/release documentation alongside the workflow

Previous run

Review

Verdict: Approve

This PR adds a well-constructed release workflow triggered by semver tag pushes, along with comprehensive documentation in AGENTS.md and a new README.md. The workflow logic is correct: idempotent release creation, safe v0 floating tag movement with --force-with-lease CAS, proper ancestry guard against tag regression, and appropriate prerelease detection. The contents: write permission is least-privilege for the stated purpose and authorized by issue #26.

All prior review findings from the first pass have been addressed:

• Protected-path authorization (was High) — resolved by linking issue feat: add release workflow for version tag sync with fullsend #26
• Missing documentation (was Medium) — resolved by AGENTS.md §6 and README.md
• Concurrency (was Low) — resolved by adding concurrency: group: release

Two low-severity consistency issues remain.

Findings

Low

• [doc-accuracy] AGENTS.md — §6 references the workflow as release.yaml, but the actual file is .github/workflows/release.yml. The README.md correctly uses release.yml. This is a factual inaccuracy in the newly added documentation.
  Remediation: Rename the workflow file to release.yaml (preferred — aligns with all 13 existing .yaml files in the repo, and the AGENTS.md reference is already correct) or update the AGENTS.md reference to release.yml.

• [file-extension-consistency] .github/workflows/release.yml — Uses .yml extension while every existing YAML file in the repository (13 files across policies/, harness/, and .github/workflows/) uses .yaml.
  Remediation: Rename to release.yaml to match the established convention. This also resolves the doc-accuracy finding above.

---

Protected paths detected — this PR modifies files under one or more
protected paths. The review agent cannot approve PRs that touch these paths.
A human reviewer must approve this PR.

Protected files in this PR:

• .github/workflows/release.yml
• AGENTS.md

---

Labels: PR adds CI release workflow and repository documentation

Previous run (2)

Review

Findings

High

• [protected-path] .github/workflows/release.yml — This PR adds a file under .github/, which is a protected path requiring human approval. The PR has no linked issue providing formal authorization for modifying governance/infrastructure files. The PR description and companion PR link (ci(release): sync version tags to fullsend-ai/agents fullsend#3079) provide context about the change's purpose, but protected-path changes require a linked issue for traceability.
  Remediation: Create a GitHub issue in this repository describing the need for release workflow sync and link it to this PR, or have a maintainer explicitly approve the protected-path change.

Medium

• [missing-doc] .github/workflows/release.yml:37 — The release workflow creates GitHub Releases with notes stating "Synced with fullsend ${TAG}", but there is no documentation explaining what this synchronization means, how it works, or how users should interpret version tags in this repository vs the fullsend repository. The repo has no README.md and AGENTS.md contains no information about the release process.

Low

• [missing-authorization] — Non-trivial feature addition (58-line workflow introducing new release automation) has no linked issue. The companion PR (ci(release): sync version tags to fullsend-ai/agents fullsend#3079) provides context, and AGENTS.md §3 is agent-facing guidance rather than a governance rule for human MEMBER contributors, but linking an issue remains good practice for traceability.

• [architectural-coherence] .github/workflows/release.yml:1 — The existing fullsend.yaml workflow is centrally managed by fullsend. This new independent workflow serves a different purpose (release automation vs event dispatch), but the distinction between centrally-managed and repo-specific workflows is not documented.

• [missing-doc] .github/workflows/release.yml:41 — The v0 floating tag follows the well-established GitHub Actions major-version tag convention, but its purpose and stability guarantees are not documented in this repository.

• [file-extension-consistency] .github/workflows/release.yml — Uses .yml extension while the existing workflow (fullsend.yaml) uses .yaml.

• [edge-case] .github/workflows/release.yml:47 — No concurrency group on this job. If two non-prerelease tags are pushed in rapid succession, the --force-with-lease CAS mechanism safely prevents data loss, but the second workflow run will be marked as failed. Consider adding a concurrency group to serialize runs.

[ggallen]

Addressing all findings from the review:

High: protected-path — Linked to #26 which authorizes this change.

Medium: missing-doc — Added §6 "Versioning and releases" to AGENTS.md documenting the release sync, what version tags mean in this repo, and the v0 floating tag.

Low: missing-authorization — Linked to #26.

Low: architectural-coherence — AGENTS.md §6 now documents the distinction: fullsend.yaml is centrally managed for agent dispatch, release.yaml is repo-specific release automation.

Low: missing-doc (v0 tag) — Documented in AGENTS.md §6.

Low: file-extension-consistency — Renamed release.yml to release.yaml for consistency with fullsend.yaml.

Low: edge-case (concurrency) — Added concurrency: { group: release, cancel-in-progress: false } to serialize runs.

All fixes in f08f6a9.

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 2:39 PM UTC · Ended 2:41 PM UTC
Commit: 0a95cac · View workflow run →

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 2:42 PM UTC · Ended 2:44 PM UTC
Commit: 0a95cac · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:45 PM UTC · Completed 2:55 PM UTC
Commit: bec2e76 · View workflow run →

Superseded by updated review

[ggallen]

Addressing the two remaining low findings:

doc-accuracy — Fixed in 24eef7e: updated AGENTS.md §6 to reference release.yml (was incorrectly release.yaml).

file-extension-consistency — Won't fix. Keeping release.yml to match fullsend's release.yml — cross-repo consistency for the release workflow pair is more important than intra-repo extension uniformity.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:26 PM UTC · Completed 3:40 PM UTC
Commit: 24eef7e · View workflow run →

[ralphbean]

LGTM.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 5:08 PM UTC · Completed 5:18 PM UTC
Commit: 24eef7e · View workflow run →

[fullsend-ai-retro]

PR #25 added a release workflow for version tag sync to fullsend-ai/agents. The review agent ran 5 times (3 completed, 2 cancelled) and produced well-targeted findings that drove real improvements: protected-path authorization, missing documentation, missing issue link, and missing concurrency group. The human reviewer approved with only "LGTM", adding no findings beyond what the agents caught. However, a low-severity file-extension-consistency finding caused a rename → revert → doc-fix cascade that consumed 3 of 4 remediation commits, introduced a documentation accuracy bug, and triggered 2 cancelled review runs. The root cause: the style sub-agent lacked cross-repo context — the author chose .yml for consistency with fullsend's release.yml, but the review agent only considered intra-repo convention. Qodo also produced a false positive on the tag filter pattern (claiming GitHub Actions doesn't support + in filter globs), which the fullsend review agent correctly avoided.

Proposals filed

• Evidence for #2959 and #2816: file-extension finding repeated 3x, caused rename-revert-docfix cascade on agents PR #25 (in fullsend-ai/fullsend)
• Review agent style-conventions sub-agent should consider cross-repo context before flagging naming conventions (in fullsend-ai/fullsend)