ci: add dispatch workflow to trigger scaffold sync

[ggallen]

Closes #6381

Summary

• Adds a post-merge workflow that fires a repository_dispatch event to fullsend-ai/.fullsend whenever fullsend main is updated
• This triggers the sync-scaffold workflow (Replace renovate agent digest tracking with sync workflow .fullsend#174) to build the latest fullsend CLI and run repos install to converge scaffold files and variables across per-repo installs
• Uses the existing fullsend-ai-sync App (SYNC_APP_ID / SYNC_PRIVATE_KEY, already provisioned on this repo)
• Includes a failure notification job to Slack so silent drift is caught

Prerequisites

• Replace renovate agent digest tracking with sync workflow .fullsend#174 merged (the receiving workflow)

Test plan

• Merge a change to fullsend main
• Verify the dispatch fires and sync-scaffold runs in .fullsend
• Confirm per-repo scaffold files converge

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Trigger scaffold sync and document per-repo migration

✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 10-20 Minutes

AI Description

• Dispatch scaffold synchronization after pushes to fullsend's main branch.
• Authenticate cross-repository notifications with a scoped GitHub App token.
• Document the staged per-org to per-repo migration and cleanup plan.

Diagram

graph TD
  A["Main push"] --> B["Notify workflow"] --> C{"Fullsend owner?"}
  C -->|Yes| D["App token"] --> E["Repository dispatch"] --> F["Sync scaffold"] --> G["Per-repo installs"]
  C -->|No| H["Skip notification"]

Loading

High-Level Assessment

The GitHub App-backed repository_dispatch approach is appropriate because it provides immediate, short-lived, cross-repository authentication without a long-lived PAT. Scheduled polling would add latency and unnecessary API usage, while duplicating synchronization logic in this repository would create tighter coupling to scaffold implementation details.

Files changed (2) +162 / -0

Documentation (1) +133 / -0

fullsend-ai-per-repo-migration.mdDocument the fullsend-ai per-repo migration plan +133/-0

Document the fullsend-ai per-repo migration plan

• Defines the repository migration order, explains repos migrate behavior, and provides validation steps. It also documents mint unenrollment and the variables, secrets, workflows, files, and directories to retain or remove.

docs/plans/fullsend-ai-per-repo-migration.md

Other (1) +29 / -0

notify-scaffold-sync.ymlDispatch scaffold synchronization after main-branch updates +29/-0

Dispatch scaffold synchronization after main-branch updates

• Adds a main-branch workflow restricted to the fullsend-ai repository owner. It creates a GitHub App token and sends a fullsend-updated repository dispatch, including the triggering commit SHA, to fullsend-ai/.fullsend.

.github/workflows/notify-scaffold-sync.yml

[github-actions]

Site preview

Preview: https://681e6758-site.fullsend-ai.workers.dev

Commit: b24373f50fc9c9d384a4c7d291d3fdd47787357d

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 1:39 PM UTC · Completed 1:57 PM UTC

Commit: 19c8e5c · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[qodo-code-review]

Code Review by Qodo

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

1. Retained scheduler loses mint access ✓ Resolved 🐞 Bug ≡ Correctness

Description

The plan keeps prioritize-scheduler.yml and prioritize.yml after removing fullsend-ai from
ALLOWED_ORGS. The scheduler requests a mint token as the .fullsend repository, which is not
among the per-repo migrations, so authorization fails and the retained prioritization automation
stops.

Code

docs/plans/fullsend-ai-per-repo-migration.md[82]

+| Keep | `scribe.yml`, `prioritize-scheduler.yml`, `prioritize.yml` |

Relevance

●●● Strong

Accepted documentation correctness findings recently; retained scheduler authorization mismatch is a
concrete migration-blocking bug.

PR-#6329
PR-#5665

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The retained scheduler calls the mint-token action with repos: .fullsend, while mint authorization
only bypasses ALLOWED_ORGS when the calling repository is registered in PER_REPO_WIF_REPOS. The
plan migrates experiments, metrics, agents, and fullsend, but not .fullsend, before
explicitly removing fullsend-ai from ALLOWED_ORGS.

docs/plans/fullsend-ai-per-repo-migration.md[5-10]
docs/plans/fullsend-ai-per-repo-migration.md[61-82]
internal/scaffold/fullsend-repo/.github/workflows/prioritize-scheduler.yml[33-43]
internal/mintcore/claims.go[95-125]

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 migration plan retains the centralized prioritize workflows while removing the organization-level mint enrollment they use. Update the plan either to preserve org enrollment until these workflows are retired or to migrate `.fullsend` and its prioritize workflows to a supported per-repo authentication path before unenrollment.

## Issue Context
`prioritize-scheduler.yml` mints a token from the `.fullsend` repository. Mint authorization requires either the caller repository in `PER_REPO_WIF_REPOS` or its owner in `ALLOWED_ORGS`, but the migration inventory does not include `.fullsend` and Phase 2 removes the org authorization.

## Fix Focus Areas
- docs/plans/fullsend-ai-per-repo-migration.md[61-82]
- internal/scaffold/fullsend-repo/.github/workflows/prioritize-scheduler.yml[33-43]
- internal/scaffold/fullsend-repo/.github/workflows/prioritize.yml[28-43]
- internal/mintcore/claims.go[95-125]

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

---

2. gh api bypasses forge.Client 📘 Rule violation ⌂ Architecture

Description

The new workflow performs a repository dispatch directly through the GitHub CLI outside
internal/forge/github. This bypasses the required forge abstraction and places direct GitHub
CLI/API logic in a prohibited path.

Code

.github/workflows/notify-scaffold-sync.yml[R27-29]

+          gh api repos/fullsend-ai/.fullsend/dispatches \
+            -f event_type=fullsend-updated \
+            -f "client_payload[sha]=${{ github.sha }}"

Relevance

● Weak

Recent matching precedent rejected routing direct gh API calls through internal/forge/github in
workflows.

PR-#5578

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rules 1062052, 1062053, and 1062054 require forge operations to use forge.Client and restrict
direct gh CLI and GitHub API calls to internal/forge/github. The workflow directly executes `gh
api repos/fullsend-ai/.fullsend/dispatches`, while the repository's forge package explicitly states
that all forge-specific operations flow through Client.

Rule 1062052: Route all git forge operations through forge.Client
Rule 1062053: Restrict gh CLI exec.Command usage to internal/forge/github
Rule 1062054: Restrict direct GitHub API calls to internal/forge/github
.github/workflows/notify-scaffold-sync.yml[23-29]
internal/forge/forge.go[1-3]

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 scaffold-sync workflow directly invokes `gh api` to send a GitHub repository dispatch, bypassing `forge.Client` and placing GitHub-specific CLI/API behavior outside `internal/forge/github`.

## Issue Context
Add repository-dispatch support to the `forge.Client` interface and its GitHub adapter, expose it through a repository-owned command, and have the workflow invoke that abstraction instead of constructing the GitHub API request itself. Preserve the `fullsend-updated` event type and `sha` client payload.

## Fix Focus Areas
- .github/workflows/notify-scaffold-sync.yml[23-29]

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

---

Context sources

✅ Compliance rules (platform): 56 rules

✅ Skills: writing-user-docs, writing-adrs

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Low

• [missing-architecture-documentation] .github/workflows/notify-scaffold-sync.yml — This workflow introduces a cross-repo dispatch pattern (fullsend → .fullsend) for scaffold sync. While scaffold sync is referenced in ADR 0057, ADR 0074, and operations.md, the fullsend-ai-sync GitHub App and its credentials (SYNC_CLIENT_ID, SYNC_PRIVATE_KEY) used by this workflow are not documented in any architectural document or operations guide outside the workflow's own header comments.

• [undocumented-credentials] .github/workflows/notify-scaffold-sync.yml:36 — The workflow references SYNC_CLIENT_ID (line 36) and SYNC_PRIVATE_KEY (line 37) credentials with no documentation in docs/ and no references in existing workflows. The workflow is gated to github.repository == 'fullsend-ai/fullsend' (line 28), suggesting org-specific infrastructure, but this constraint is not documented for other adopters.

Previous run

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Previous run (2)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Previous run (3)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Low

• [naming-conventions] .github/workflows/notify-scaffold-sync.yml:58 — The notify-failure job uses SLACK_WEBHOOK as the environment variable name for the Slack webhook URL, but the established pattern in other notification workflows (notify-adr-slack.yml, notify-vouch-slack.yml) is to use SLACK_WEBHOOK_URL to match the secret name. This creates inconsistency in the notify-*.yml workflow family.
  Remediation: Rename the env var from SLACK_WEBHOOK to SLACK_WEBHOOK_URL to match the naming pattern in notify-adr-slack.yml and notify-vouch-slack.yml. Update the references on lines 59 and 64 accordingly.

Previous run (4)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Low

• [unnecessary-permissions] .github/workflows/notify-scaffold-sync.yml:53 — The notify-failure job declares permissions: contents: read but does not check out the repository or read any repository contents. It only runs jq and curl using GitHub environment variables and a secret. The permission is unnecessary, though this follows the same pattern as release.yml.
  Remediation: Change the job-level permissions to permissions: {} to match the principle of least privilege.

• [error-handling] .github/workflows/notify-scaffold-sync.yml:62 — The notify-failure job does not validate that SLACK_WEBHOOK is non-empty before passing it to curl. If the secret is not configured, curl will fail with a generic URL format error rather than a clear diagnostic message. This follows the release.yml pattern, but other notification workflows (notify-vouch-slack.yml, notify-adr-slack.yml) include a guard.
  Remediation: Add a guard before the curl call: if [ -z "$SLACK_WEBHOOK" ]; then echo "::error::SLACK_WEBHOOK_URL secret is not configured"; exit 1; fi

• [workflow-conventions] .github/workflows/notify-scaffold-sync.yml:19 — The concurrency group uses only github.workflow, which serializes all runs globally. For this push-to-main workflow, adding github.ref would not change behavior since the branch is always main. Serialization is arguably desirable for ordered dispatches, and this pattern has repo precedent (branch-cleanup.yml, vouch-command.yml).

Previous run (5)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Previous run (6)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Previous run (7)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Low

• [convention deviation] .github/workflows/notify-scaffold-sync.yml:16 — The workflow uses cancel-in-progress: true on a push: branches: [main] trigger, which deviates from the convention in docs/contributing/ci-workflows.md: "Never cancel in-progress runs on the default branch." The inline comment provides a sound justification — this is a fire-and-forget notification dispatch, not a CI check, so no test signal is lost by canceling stale runs. The convention was written for CI workflows where in-progress runs produce valuable signal; this workflow does not fit that category.
  Remediation: Either (1) update the convention in docs/contributing/ci-workflows.md to carve out an exception for non-CI notification/dispatch workflows, or (2) remove cancel-in-progress: true and let stale runs complete harmlessly.

---

Labels: PR adds a CI workflow file under .github/workflows/

Previous run (8)

Review

Findings

High

• [scope-creep] docs/plans/fullsend-ai-per-repo-migration.md — Introduces a new documentation category (docs/plans/) and a 134-line migration plan document not authorized by the linked issue ci: add post-merge dispatch workflow for scaffold sync #6381, which only authorizes adding the dispatch workflow. The docs/plans/ directory is gitignored (.gitignore line 24), and the .gitignore was not modified in this PR — the file was force-added, contradicting the repo's convention that docs/plans/ is for local/ephemeral planning documents. No ADR or AGENTS.md guidance establishes this category.
  Remediation: Remove the migration plan and docs/plans/ changes from this PR. If this content should be committed, file a separate issue to discuss whether docs/plans/ should be un-gitignored and established as a documentation category.

Medium

• [scope-creep] docs/.vitepress/config.ts — Adds VitePress sidebar entry (Plans section) and search scope prefix (/docs/plans/) for the unauthorized docs/plans/ category. These changes are a consequence of the docs/plans/ addition above.
  Remediation: Remove the VitePress config changes from this PR. Add them in the PR that establishes docs/plans/ as a committed category.

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

Previous run (9)

Review

Findings

Medium

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path. The PR links to issue ci: add post-merge dispatch workflow for scaffold sync #6381 which authorizes adding this dispatch workflow, and the description explains the rationale. Human approval is always required for protected-path changes regardless of context.

Low

• [pattern-inconsistency] .github/workflows/notify-scaffold-sync.yml:14 — The concurrency group uses a static string notify-scaffold-sync instead of the repo-standard ${{ github.workflow }} pattern from docs/contributing/ci-workflows.md. Additionally, cancel-in-progress: true on a main-only push trigger deviates from the documented convention to not cancel in-progress runs on the default branch. For this fire-and-forget dispatch, cancellation is semantically correct since only the latest SHA matters — multiple existing workflows in this repo also use hardcoded group names.
  Remediation: Consider using group: ${{ github.workflow }} and adding a comment explaining why cancel-in-progress: true is acceptable here.

Previous run (10)

Review

Findings

High

• [protected-path] .github/workflows/notify-scaffold-sync.yml — PR modifies a file under the .github/ protected path without a linked issue. Protected paths (governance and infrastructure files) require human approval. The PR description explains the workflow's purpose but does not link to a GitHub issue authorizing changes to governance paths.
  Remediation: Create and link a GitHub issue authorizing this infrastructure change, or obtain explicit human approval for the protected-path modification.

Medium

• [technical documentation correctness] docs/plans/fullsend-ai-per-repo-migration.md:18 — The migration plan describes the order of operations for repos migrate incorrectly. Steps 6-8 claim scaffold files are committed first (step 6), then variables (step 7), then secrets (step 8). The actual implementation writes variables first, then secrets, then scaffold files — this ordering eliminates a race window (fix(repos): write variables and secrets before committing scaffold #6122) where a workflow could trigger before its required secrets exist.
  Remediation: Reorder steps 6-8 to match the implementation and add a note explaining the ordering rationale.

• [technical documentation correctness] docs/plans/fullsend-ai-per-repo-migration.md:21 — Step 9 claims repos migrate registers per-repo WIF with mint, but this was removed in repos commands: add credential mode model (wif/oidc/token) for public mint compatibility #6222 (confirmed by TestMigrate_NoMintRegistration). Phase 2 reinforces this incorrect claim. An operator following this plan could end up with repos missing mint registration.
  Remediation: Remove step 9 or note that mint registration must be performed separately. Update Phase 2's parenthetical accordingly.

• [workflow-timeout-missing] .github/workflows/notify-scaffold-sync.yml:12 — Workflow job lacks timeout-minutes. Per docs/contributing/ci-workflows.md, every non-reusable workflow job must set timeout-minutes.
  Remediation: Add timeout-minutes: 5 to the notify job.

• [pattern-violation] PR title — PR title "Add dispatch workflow to trigger scaffold sync" is missing the conventional commit type prefix required by COMMITS.md. This is a CI/CD change; the title should use ci: or chore(ci): prefix.
  Remediation: Update the PR title to include the conventional commit type prefix (e.g., ci: add dispatch workflow to trigger scaffold sync).

Low

• [permission-expansion] .github/workflows/notify-scaffold-sync.yml:16 — GitHub App token created with owner: fullsend-ai but without repositories: restriction. Unlike release.yml which scopes its token, this token could access all repos where the SYNC App is installed.
  Remediation: Add repositories: ['.fullsend'] to scope the token to the target repository.

• [workflow-concurrency-missing] .github/workflows/notify-scaffold-sync.yml:5 — Workflow lacks a concurrency group. Existing notification workflows also lack them, so this is consistent with current practice, but a concurrency group would prevent redundant concurrent dispatches.
  Remediation: Consider adding a concurrency block.

• [undocumented-dependency] .github/workflows/notify-scaffold-sync.yml — Workflow depends on SYNC_APP_ID variable and SYNC_PRIVATE_KEY secret that are not documented. Similar to renovate.yml which documents its App variables in comments.
  Remediation: Add comments in the workflow file explaining these variables.

• [naming-conventions] .github/workflows/notify-scaffold-sync.yml:19 — Variable naming SYNC_APP_ID/SYNC_PRIVATE_KEY is less descriptive than existing patterns (RENOVATE_APP_ID, RELEASE_APP_ID). A prefix like SCAFFOLD_SYNC_ would be more specific.
  Remediation: Consider renaming to SCAFFOLD_SYNC_APP_ID/SCAFFOLD_SYNC_PRIVATE_KEY.

• [new-directory-convention] docs/plans/fullsend-ai-per-repo-migration.md — Creates a new docs/plans/ directory not documented in AGENTS.md. Existing doc directories include docs/ADRs/, docs/spikes/, docs/experiments/, docs/problems/.
  Remediation: Add docs/plans/ to the AGENTS.md guidance table or consider placing this document in an existing category.

---

Next steps:

• /fs-fix — agent addresses review findings automatically
• /fs-fix <your instruction> — agent fixes with your specific guidance
• Push commits directly — review re-runs automatically on push
• /fs-fix-stop — disable automatic fix runs for this PR

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:19 PM UTC · Completed 2:34 PM UTC

Commit: d27b520 · View workflow run →

Superseded by updated review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 2:40 PM UTC · Completed 2:55 PM UTC

Commit: b24373f · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:01 PM UTC · Completed 3:14 PM UTC

Commit: 2d3b5a9 · View workflow run →

Superseded by updated review

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:21 PM UTC · Completed 3:33 PM UTC

Commit: b5872f8 · View workflow run →

[waynesun09]

Review-squad pass at head b5872f81 — 3 agents (two Claude lenses: diff correctness and external-claim verification; plus an independent Grok pass). Review-only, 3 MEDIUM findings inline.

Everything raised earlier is confirmed fixed at this head (timeout-minutes, repositories: token scoping, concurrency block, cancel-in-progress removal), and the migration-plan doc findings are moot now that the file has left the PR.

Verified clean, for the record:

• event_type=fullsend-updated exactly matches on.repository_dispatch.types in .fullsend:sync-scaffold.yml, and #174 is merged to .fullsend main — so the receiver does exist on the default branch, as repository_dispatch requires.
• No sync loop: fullsend-ai/fullsend is not in .fullsend:repos.yaml (only experiments, metrics, agents), so no scaffold commit can re-fire this dispatcher. Worth stating explicitly since that invariant lives in another repo with nothing here recording the dependency.
• Action pin bcd2ba4 is genuinely the v3 tag target, and the leading dot in .fullsend needs no quoting at any layer (YAML scalar, action parser, Octokit path encoding).
• -f "client_payload[sha]=..." does produce correctly nested JSON (checked empirically with GH_DEBUG=api), and permissions: {} is correct — GITHUB_TOKEN is unused here.

LOW, not posted inline: client_payload.sha is sent but never read — sync-scaffold.yml clones --depth 1 with no --branch and builds default-branch HEAD, despite its own comment claiming it builds the triggering commit; ${{ github.sha }} is interpolated straight into the run: block instead of going through env: (not injectable, but it's the pattern actionlint/zizmor flag); and there's no workflow_dispatch: trigger, so the wiring can't be exercised without a push to main.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 4:10 PM UTC · Completed 4:20 PM UTC

Commit: 64c371d · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 4:49 PM UTC · Completed 5:04 PM UTC

Commit: 9753733 · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:12 PM UTC · Completed 5:22 PM UTC

Commit: bea137e · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:30 PM UTC · Completed 5:42 PM UTC

Commit: de333b5 · View workflow run →

[waynesun09]

Automated review sweep — 2 additional findings not covered by prior review rounds.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 5:46 PM UTC · Completed 5:58 PM UTC

Commit: 27044f5 · View workflow run →

[waynesun09]

Automated review sweep at head 27044f50 — 3 MEDIUM findings not covered by prior review rounds. Review-only; no approval or change request implied.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 11:10 PM UTC · Completed 11:23 PM UTC

Commit: 437e488 · View workflow run →

[fullsend-ai-review]

See the review comment for full details.