docs(adr): add ADR for dispatch version-skew resolution

[rh-hemartin]

Summary

• Adds ADR documenting the per-repo dispatch version-skew problem
  (hardcoded @v0 in uses: lines that GHA cannot template with expressions)
• Evaluates four options: re-introduce dispatch to user repo (rejected),
  composite action (rejected), release branches (rejected), merge stage
  workflows into dispatch (accepted)
• Adds implementation plan (docs/plans/merge-stage-workflows.md) and links
  it from the ADR
• Updates the automatic-updates plan to reference the new ADR instead of
  inlining the options and release-branch details
• Amends ADR 48 with a cross-reference for migration approach
  revisions discovered during implementation
• Adds architecture.md Decided entry for dispatch version-skew resolution
• Sets relates_to: [agent-infrastructure] in ADR frontmatter

Test plan

• ADR frontmatter passes lint (status, relates_to, topics)
• Markdown links between plan and ADR resolve correctly
• Plan doc reads coherently with the implementation section
• architecture.md entry links to correct ADR file

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Amend ADR 48 with dispatch version-skew notes and migration strategy
📝 Documentation 🕐 10-20 Minutes

Description

• Annotate ADR 48 to reflect a real transition period before breaking workflow changes.
• Document the per-repo reusable-dispatch.yml@v0 hardcoding issue and accepted release-branch fix.
• Describe a backwards-compatible input-alias approach for migrating to new input names.

Diagram

graph TD
  A["ADR 48"] --> B["Automatic Updates plan"] --> C["Per-repo mode"] --> D["reusable-dispatch.yml"] --> E["reusable-<stage>.yml"]
  B --> F(["Release branch tagging"])
  F --> D
  B --> G["Input alias fallback"]
  G --> E

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Create a new ADR to supersede ADR 48

• ➕ Keeps ADR 48 as a strict point-in-time record
• ➕ Captures the migration/transition decision more formally
• ➕ Avoids strikethrough edits in Consequences
• ➖ More process overhead for what is mostly an implementation-discovered constraint
• ➖ Splits context across ADRs unless carefully cross-referenced

2. Keep all updates only in the design doc (no ADR annotation)

• ➕ Minimizes churn in the accepted ADR
• ➕ Keeps evolving narrative in the plan where details belong
• ➖ Reviewers may miss that ADR 48’s consequence assumptions changed in practice
• ➖ Less discoverable for decision tracking

Recommendation: The current approach (minor annotation to ADR 48 plus detailed plan amendments) is appropriate given the ADR’s explicit allowance for clarifying notes and cross-references. If the transition period becomes a materially new decision (e.g., formal policy/timeline for breaking changes), follow up with a superseding ADR and keep this annotation as the pointer.

Files changed (2) +80 / -2

Documentation (2) +80 / -2

0048-automatic-updates.mdAnnotate ADR 48 consequences with transition-period reality +6/-2

Annotate ADR 48 consequences with transition-period reality

• Replaces the prior assumption of automatic migration with an explicit transition period before breaking workflow changes. Adds a dated note pointing readers to the amended Automatic Updates plan for dispatch version-skew and the release-branch solution.

docs/ADRs/0048-automatic-updates.md

automatic-updates.mdAdd 2026-06-19 amendments: dispatch version-skew, release stamping, migration aliases +74/-0

Add 2026-06-19 amendments: dispatch version-skew, release stamping, migration aliases

• Documents the per-repo 'reusable-dispatch.yml' hardcoded '@v0' limitation and evaluates options, selecting a release-branch/tagging approach that stamps version refs into dispatch at release time. Adds guidance for 'main' to use '@main' and describes a backwards-compatible input-alias strategy for migrating from 'fullsend_ai_ref'/'fullsend_version' to the new input names during a transition window.

docs/plans/automatic-updates.md

[github-actions]

Site preview

Preview: https://d096240b-site.fullsend-ai.workers.dev

Commit: 3581422855d3cba43ab252793317c8c13bb406b2

[qodo-code-review]

Code Review by Qodo

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

Context used

✅ Compliance rules (platform): 51 rules

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

1. ADR 0048 Consequences rewritten ✓ Resolved 📜 Skill insight § Compliance

Description

docs/ADRs/0048-automatic-updates.md is an already Accepted ADR, but the PR changes the meaning
of a Consequences bullet (replacing the original outcome with a new transition/breaking-changes
statement). Accepted ADR sections should only receive minor annotations/cross-references, not
substantive content rewrites.

Code

docs/ADRs/0048-automatic-updates.md[R58-61]

* `v0` should be migrated to the new moving tag and deleted.
-* Current users track the new floating tag automatically to keep behavior consistent.
+* ~~Current users track the new floating tag automatically to keep behavior consistent.~~
+* Current users have a period of transition in which version to track, after a while we introduce
+breaking changes to the workflows.

Evidence

PR Compliance IDs 1062057 and 1062103 require that accepted ADRs are not substantively rewritten.
The changed Consequences bullets in docs/ADRs/0048-automatic-updates.md strike the original
consequence and introduce new behavior/impact language (transition period + breaking workflow
changes), which alters the recorded consequences rather than adding a brief note/cross-reference.

Rule 1062057: Restrict modifications to accepted ADRs on main
docs/ADRs/0048-automatic-updates.md[58-61]
Skill: writing-adrs

Agent prompt

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

## Issue description
ADR 0048 is `Accepted`, but the PR substantively changes the Consequences section by striking the original consequence and adding a new one that changes the historical record.

## Issue Context
The ADR file explicitly states that accepted ADRs should not have their Context/Decision/Consequences substantially rewritten; only minor annotations (cross-references, short notes, clarifications) are allowed.

## Fix Focus Areas
- docs/ADRs/0048-automatic-updates.md[58-66]

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

---

2. Broken bullet continuations ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

In the 2026-06-19 amendments section, multiple list items have unindented continuation lines (e.g.,
the rationale lines after 'rejected/accepted'), which breaks list structure in Markdown. This makes
the options/migration sections render inconsistently and reduces readability.

Code

docs/plans/automatic-updates.md[R123-128]

+* **Re-introduce `reusable-dispatch.yml` to the user repository** - rejected
+as we already extracted it to reduce update noise in the user's repository
+* **Convert dispatch to a composite action** - rejected because actions
+can't spawn jobs naturally, and can't use `workflow_call`.
+* **Commit changes to reusable-dispatch.yml on release** - accepted, more details
+below.

Evidence

The newly added bullets show continuation lines starting at column 0 (e.g., 'as we already…', 'can't
spawn…', 'below.', and wrapped migration-solution lines), which breaks list formatting.

docs/plans/automatic-updates.md[121-128]
docs/plans/automatic-updates.md[159-163]

Agent prompt

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

## Issue description
Several bullets in the amendments section wrap onto subsequent lines without indentation. In Markdown, unindented wrapped lines are not reliably treated as part of the list item, causing broken list rendering.

## Issue Context
This affects the newly added amendments content (options list and migration solutions list).

## Fix Focus Areas
- docs/plans/automatic-updates.md[121-128]
- docs/plans/automatic-updates.md[159-163]

## Suggested fix
For each multi-line bullet, indent the continuation lines by at least two spaces (or rewrite each bullet as a single line). For example:
- Keep the rationale lines ("as we already...", "can't spawn jobs...", "below.") indented under their bullet.
- Do the same for the migration solutions bullets so wrapped lines stay inside the list item.

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

---

3. Broken consequences list ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

In ADR 48, the new transition bullet wraps onto an unindented line, which breaks Markdown list
continuation and renders the second line as a separate paragraph. This makes the Consequences
section display incorrectly and is easy to misread.

Code

docs/ADRs/0048-automatic-updates.md[R60-61]

+* Current users have a period of transition in which version to track, after a while we introduce
+breaking changes to the workflows.

Evidence

The Consequences bullet at line 60 is immediately followed by an unindented line 61, which
CommonMark treats as outside the list item, breaking list formatting.

docs/ADRs/0048-automatic-updates.md[56-62]

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 Consequences list item is split across two lines, but the continuation line is not indented, so Markdown parsers will terminate the list item and render the continuation as a standalone paragraph.

## Issue Context
This is in the ADR Consequences section, which is expected to be readable and well-structured.

## Fix Focus Areas
- docs/ADRs/0048-automatic-updates.md[58-62]

## Suggested fix
Indent the continuation line by at least two spaces (or rewrite the bullet onto a single line) so it remains part of the list item.

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

---

4. YAML filename extension mismatch 🐞 Bug ⚙ Maintainability

Description

The YAML snippet comment references reusable-dispatch.yaml/dispatch.yaml, but the repository
workflows use the .yml extension (e.g., reusable-dispatch.yml). This inconsistency can confuse
readers trying to locate the referenced file(s).

Code

docs/plans/automatic-updates.md[R171-173]

+```yaml
+# reusable-dispatch.yaml/dispatch.yaml
+triage:

Evidence

The docs snippet uses .yaml in the comment, while the actual workflow file in this repo is named
reusable-dispatch.yml, demonstrating the mismatch.

docs/plans/automatic-updates.md[171-173]
.github/workflows/reusable-dispatch.yml[1-12]

Agent prompt

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

## Issue description
A code-block comment references workflow filenames with a `.yaml` extension even though the repo uses `.yml` for these workflows.

## Issue Context
This is in an example snippet within the 2026-06-19 amendments section.

## Fix Focus Areas
- docs/plans/automatic-updates.md[171-173]

## Suggested fix
Update the comment to match actual repo filenames, e.g. `# reusable-dispatch.yml/dispatch.yml` (or name the specific real file path(s) being discussed).

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

---

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:25 AM UTC · Completed 9:47 AM UTC
Commit: f2810f1 · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Looks good to me

Previous run

Review

Findings

Medium

• [internal-consistency] docs/plans/merge-stage-workflows.md:1 — The plan title says "ADR 60" but the ADR it implements is numbered 61 (0061-dispatch-version-skew.md). ADR 0060 is the unrelated "Cross-org mint authorization via org variables". The same mismatch appears on line 7 ("ADR 60 decides to inline all stage logic"). This is a recurring issue — prior reviews flagged the same class of error when the ADR was numbered 55 and 58.
  Remediation: Change both occurrences of "ADR 60" in merge-stage-workflows.md to "ADR 61".

Previous run (2)

Review

Findings

Medium

• [internal-consistency] docs/ADRs/0058-dispatch-version-skew.md:83 — The Decision section states that during the deprecation period reusable-<stage>.yml files need to be "in sync with the merged reusable-triage.yml", but the decision is to merge stages into reusable-dispatch.yml. reusable-triage.yml is one of the stage files being merged, not the target.
  Remediation: Change reusable-triage.yml to reusable-dispatch.yml.

• [internal-consistency] docs/ADRs/0058-dispatch-version-skew.md:85 — The first Consequences bullet says reusable-<stage>.yml workflows are "merged (and deleted)" into reusable-dispatch.yml, but the Decision section (lines 78–83) explicitly states reusable-<stage>.yml will be kept during the per-org deprecation period. The parenthetical "(and deleted)" contradicts the stated plan.
  Remediation: Remove "(and deleted)" from the first Consequences bullet, or reword to clarify that stage logic is inlined but the standalone files are retained for per-org mode.

• [internal-consistency] docs/plans/merge-stage-workflows.md:1 — The plan title says "ADR 55" (# ADR 55: Inline stages into reusable-dispatch.yml) but the ADR was renumbered to 58. The ADR file itself is 0058-dispatch-version-skew.md and the plan body at line 7 correctly references "ADR 58". The title is stale.
  Remediation: Change the title to # ADR 58: Inline stages into reusable-dispatch.yml (per-repo only).

• [incomplete-adr-adoption] docs/architecture.md — ADR 58 is marked as Accepted but docs/architecture.md has not been updated. Per AGENTS.md: "When status is Accepted, update docs/architecture.md and related problem docs in the same PR per the writing-adrs skill."
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 58.

Previous run (3)

Review

Findings

Medium

• [internal-consistency] docs/ADRs/0055-dispatch-version-skew.md:83 — The Decision section says reusable-<stage>.yml files need to be "in sync with the merged reusable-triage.yml" but the decision is to merge stages into reusable-dispatch.yml. The reference should be to reusable-dispatch.yml, not reusable-triage.yml.
  Remediation: Change reusable-triage.yml to reusable-dispatch.yml.

• [internal-consistency] docs/ADRs/0055-dispatch-version-skew.md:63 — Option labels are misnumbered: Option D is labeled with a confusing C. Release branches with ref rewriting -> D. Merge stage workflows into dispatch heading, using arrow notation instead of a clean D. label.
  Remediation: Rename the heading to ### D. Merge stage workflows into dispatch.

• [internal-consistency] docs/ADRs/0055-dispatch-version-skew.md:90 — Typo: "per-ord mode" should be "per-org mode".
  Remediation: Change per-ord to per-org.

• [internal-consistency] docs/plans/automatic-updates.md:149 — The YAML snippet comment says reusable-dispatch.yaml/dispatch.yaml but the actual workflow files in the repository use the .yml extension. This file-extension mismatch could mislead implementers.
  Remediation: Change the comment to reusable-dispatch.yml/dispatch.yml to match the actual file extensions used in the repository.

• [ADR-frontmatter-consistency] docs/ADRs/0055-dispatch-version-skew.md:5 — The relates_to field is empty ([]) but this ADR explicitly relates to ADR 48, which is referenced in the Context section.
  Remediation: Set relates_to to include 0048-automatic-updates.

• [incomplete-adr-adoption] docs/architecture.md — ADR 55 is marked as Accepted but docs/architecture.md has not been updated. Per AGENTS.md: "When status is Accepted, update docs/architecture.md and related problem docs in the same PR per the writing-adrs skill."
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 55.

Previous run

Review

Findings

Medium

• [internal-consistency] docs/plans/automatic-updates.md:149 — The YAML snippet comment says reusable-dispatch.yaml/dispatch.yaml but the actual workflow files in the repository use the .yml extension (e.g., .github/workflows/reusable-dispatch.yml). This file-extension mismatch could mislead implementers into creating or looking for files with the wrong extension.
  Remediation: Change the comment to reusable-dispatch.yml/dispatch.yml to match the actual file extensions used in the repository.

• [incomplete-implementation] docs/architecture.md — ADR 55 is marked as Accepted but docs/architecture.md has not been updated. Per the writing-adrs skill, accepted ADRs must update architecture.md with a "Decided:" line in the same PR.
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 55.

---

Labels: PR adds an ADR and plan amendments about dispatch version-skew resolution.

Previous run (4)

Review

Findings

Medium

• [internal-consistency] docs/plans/automatic-updates.md:149 — The YAML snippet comment says reusable-dispatch.yaml/dispatch.yaml but the actual workflow files in the repository use the .yml extension (e.g., .github/workflows/reusable-dispatch.yml). This file-extension mismatch could mislead implementers into creating or looking for files with the wrong extension.
  Remediation: Change the comment to reusable-dispatch.yml/dispatch.yml to match the actual file extensions used in the repository.

• [incomplete-implementation] docs/architecture.md — ADR 55 is marked as Accepted but docs/architecture.md has not been updated. Per the writing-adrs skill, accepted ADRs must update architecture.md with a "Decided:" line in the same PR.
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 55.

---

Labels: PR adds an ADR and plan amendments about dispatch version-skew resolution.

Previous run (5)

Review

Findings

High

• [missing-authorization] docs/ADRs/0048-automatic-updates.md — No linked issue authorizes this work. This PR adds ~80 lines of amendments to accepted architectural documentation (ADR 48 and its companion plan document) without traceable authorization. Non-trivial diffs require explicit authorization via a linked issue.
  Remediation: Link the PR to an issue that authorizes amending ADR 48, or create an issue documenting the discovered implementation gap (hardcoded @v0 in reusable-dispatch.yml) and the decision to document it via amendment rather than implementation fix.

Medium

• [stale-doc] skills/cutting-releases/SKILL.md — The PR amendments describe a new release-branch strategy (tags created on release branches instead of main), but the cutting-releases skill documentation still describes the current main-branch release process. While the current runbook is not wrong today (the plan documents a future process), this is a forward-looking concern: once the release-branch process is implemented, the cutting-releases skill will be stale.
  Remediation: Update skills/cutting-releases/SKILL.md to reflect the new release-branch process when it is implemented, or add a note cross-referencing the planned changes.

• [internal-consistency] docs/plans/automatic-updates.md:164 — The fallback snippet shows fullsend_cli_ref falling back to fullsend_version, but downstream stage workflows (reusable-triage.yml, reusable-code.yml, etc.) currently only accept fullsend_version and fullsend_ai_ref as input names — not fullsend_cli_ref or fullsend_actions_ref. The plan's release procedure (steps 4–5) only mentions updating reusable-dispatch.yml, not the stage workflows. If the release-branch process is followed before stage workflows are updated, the new input names will be silently ignored.
  Remediation: Add an explicit step or prerequisite noting that all reusable-{stage}.yml workflow input declarations must be updated to accept fullsend_actions_ref and fullsend_cli_ref (in addition to or replacing the old names) before the release-branch process is executed.

Low

• [edge-case-correctness] docs/plans/automatic-updates.md:143 — The release procedure (step 7) says to tag the branch with ${VERSION} and latest, but does not mention force-pushing the latest tag. On subsequent releases, latest already exists remotely and a plain push will be rejected. The existing cutting-releases SKILL.md already handles this for v0 with git tag -f and --force.

• [internal-consistency] docs/ADRs/0048-automatic-updates.md:59 — The original ADR consequence is struck through and replaced with materially different text. The ADR policy comment (lines 19–24) says "do not substantially rewrite the Context, Decision, or Consequences sections." This is a borderline case.

• [amendment-annotation-style] docs/ADRs/0048-automatic-updates.md:59 — The (added 2026-06-19) annotation format and strikethrough markdown are novel in this codebase's ADR corpus. No other ADR uses either pattern.

• [adr-amendment-scope] docs/plans/automatic-updates.md:110 — 74 lines of new content with design decisions and rejected alternatives. While plan documents have no immutability policy, the volume and ADR-style language ("rejected"/"accepted") suggest these decisions could warrant a separate ADR.

• [design-coherence] docs/plans/automatic-updates.md:110 — The amendments use ADR-style rejected/accepted language for options, which is stylistically unusual for a plan document.

Previous run (6)

Review

Findings

Medium

• [internal-consistency] docs/ADRs/0055-dispatch-version-skew.md:83 — The Decision section says reusable-<stage>.yml files need to be "in sync with the merged reusable-triage.yml" but the decision is to merge stages into reusable-dispatch.yml. The reference should be to reusable-dispatch.yml, not reusable-triage.yml.
  Remediation: Change reusable-triage.yml to reusable-dispatch.yml.

• [internal-consistency] docs/ADRs/0055-dispatch-version-skew.md:63 — Option labels are misnumbered: Option D is labeled with a confusing C. Release branches with ref rewriting -> D. Merge stage workflows into dispatch heading, using arrow notation instead of a clean D. label. This duplicates the C letter.
  Remediation: Rename the heading to ### D. Merge stage workflows into dispatch.

• [internal-consistency] docs/ADRs/0055-dispatch-version-skew.md:90 — Typo: "per-ord mode" should be "per-org mode".
  Remediation: Change per-ord to per-org.

• [internal-consistency] docs/plans/automatic-updates.md:149 — The YAML snippet comment says reusable-dispatch.yaml/dispatch.yaml but the actual workflow files in the repository use the .yml extension. This file-extension mismatch could mislead implementers.
  Remediation: Change the comment to reusable-dispatch.yml/dispatch.yml to match the actual file extensions used in the repository.

• [ADR-frontmatter-consistency] docs/ADRs/0055-dispatch-version-skew.md:5 — The relates_to field is empty ([]) but this ADR explicitly relates to ADR 48, which is referenced in the Context section.
  Remediation: Set relates_to to include 0048-automatic-updates.

• [incomplete-adr-adoption] docs/architecture.md — ADR 55 is marked as Accepted but docs/architecture.md has not been updated. Per AGENTS.md: "When status is Accepted, update docs/architecture.md and related problem docs in the same PR per the writing-adrs skill."
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 55.

Previous run (7)

Review

Findings

Medium

• [internal-consistency] docs/plans/automatic-updates.md:149 — The YAML snippet comment says reusable-dispatch.yaml/dispatch.yaml but the actual workflow files in the repository use the .yml extension (e.g., .github/workflows/reusable-dispatch.yml). This file-extension mismatch could mislead implementers into creating or looking for files with the wrong extension.
  Remediation: Change the comment to reusable-dispatch.yml/dispatch.yml to match the actual file extensions used in the repository.

• [incomplete-implementation] docs/architecture.md — ADR 55 is marked as Accepted but docs/architecture.md has not been updated. Per the writing-adrs skill, accepted ADRs must update architecture.md with a "Decided:" line in the same PR.
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 55.

---

Labels: PR adds an ADR and plan amendments about dispatch version-skew resolution.

Previous run (8)

Review

Findings

Medium

• [internal-consistency] docs/plans/automatic-updates.md:149 — The YAML snippet comment says reusable-dispatch.yaml/dispatch.yaml but the actual workflow files in the repository use the .yml extension (e.g., .github/workflows/reusable-dispatch.yml). This file-extension mismatch could mislead implementers into creating or looking for files with the wrong extension.
  Remediation: Change the comment to reusable-dispatch.yml/dispatch.yml to match the actual file extensions used in the repository.

• [incomplete-implementation] docs/architecture.md — ADR 55 is marked as Accepted but docs/architecture.md has not been updated. Per the writing-adrs skill, accepted ADRs must update architecture.md with a "Decided:" line in the same PR.
  Remediation: Add a Decided bullet under the relevant section of docs/architecture.md documenting the dispatch version-skew resolution, with a link to ADR 55.

---

Labels: PR adds an ADR and plan amendments about dispatch version-skew resolution.

Previous run (9)

Review

Findings

High

• [missing-authorization] docs/ADRs/0048-automatic-updates.md — No linked issue authorizes this work. This PR adds ~80 lines of amendments to accepted architectural documentation (ADR 48 and its companion plan document) without traceable authorization. Non-trivial diffs require explicit authorization via a linked issue.
  Remediation: Link the PR to an issue that authorizes amending ADR 48, or create an issue documenting the discovered implementation gap (hardcoded @v0 in reusable-dispatch.yml) and the decision to document it via amendment rather than implementation fix.

Medium

• [stale-doc] skills/cutting-releases/SKILL.md — The PR amendments describe a new release-branch strategy (tags created on release branches instead of main), but the cutting-releases skill documentation still describes the current main-branch release process. While the current runbook is not wrong today (the plan documents a future process), this is a forward-looking concern: once the release-branch process is implemented, the cutting-releases skill will be stale.
  Remediation: Update skills/cutting-releases/SKILL.md to reflect the new release-branch process when it is implemented, or add a note cross-referencing the planned changes.

• [internal-consistency] docs/plans/automatic-updates.md:164 — The fallback snippet shows fullsend_cli_ref falling back to fullsend_version, but downstream stage workflows (reusable-triage.yml, reusable-code.yml, etc.) currently only accept fullsend_version and fullsend_ai_ref as input names — not fullsend_cli_ref or fullsend_actions_ref. The plan's release procedure (steps 4–5) only mentions updating reusable-dispatch.yml, not the stage workflows. If the release-branch process is followed before stage workflows are updated, the new input names will be silently ignored.
  Remediation: Add an explicit step or prerequisite noting that all reusable-{stage}.yml workflow input declarations must be updated to accept fullsend_actions_ref and fullsend_cli_ref (in addition to or replacing the old names) before the release-branch process is executed.

Low

• [edge-case-correctness] docs/plans/automatic-updates.md:143 — The release procedure (step 7) says to tag the branch with ${VERSION} and latest, but does not mention force-pushing the latest tag. On subsequent releases, latest already exists remotely and a plain push will be rejected. The existing cutting-releases SKILL.md already handles this for v0 with git tag -f and --force.

• [internal-consistency] docs/ADRs/0048-automatic-updates.md:59 — The original ADR consequence is struck through and replaced with materially different text. The ADR policy comment (lines 19–24) says "do not substantially rewrite the Context, Decision, or Consequences sections." This is a borderline case.

• [amendment-annotation-style] docs/ADRs/0048-automatic-updates.md:59 — The (added 2026-06-19) annotation format and strikethrough markdown are novel in this codebase's ADR corpus. No other ADR uses either pattern.

• [adr-amendment-scope] docs/plans/automatic-updates.md:110 — 74 lines of new content with design decisions and rejected alternatives. While plan documents have no immutability policy, the volume and ADR-style language ("rejected"/"accepted") suggest these decisions could warrant a separate ADR.

• [design-coherence] docs/plans/automatic-updates.md:110 — The amendments use ADR-style rejected/accepted language for options, which is stylistically unusual for a plan document.

[fullsend-ai-review]

🤖 Review · ❌ Terminated · Started 8:27 AM UTC · Ended 8:43 AM UTC
Commit: ff8ec85 · View workflow run →

[rh-hemartin]

@ifireball I added a new ADR to solve the version skew which has the merge of workflows as decision. I did the changes locally and tested them in my rh-hemartin-fullsend/standalone-fullsend and they did work great in vendored mode. I need to address per-org changes, as this also impacts it, but I think we will manage. I can add an implementation plan here for ADR55 if you want.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:27 AM UTC · Completed 8:43 AM UTC
Commit: 7baeeb4 · View workflow run →

[rh-hemartin]

New changes: per-org mode does not change and since it is pending deprecation reusable-<stage>.yml are kept. When per-org mode is removed, then reusable-<stage>.yml files get removed. This is because the cost of having per-org mode change behavior is high and it does not make sense if it will be deprecated.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:45 AM UTC · Completed 9:59 AM UTC
Commit: 56d8695 · View workflow run →

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 7:27 AM UTC · Ended 7:28 AM UTC
Commit: 104508d · View workflow run →

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 7:31 AM UTC · Completed 7:45 AM UTC
Commit: 453504c · View workflow run →

[waynesun09]

ADR Re-Review (Round 2) — PR #2453

8-agent squad re-review after author updates.

Prior Round Resolution

#	Prior Finding	Status
1	ADR 0058 number collision	FIXED (renumbered to 0061 — but see below)
2	Typo reusable-triage.yml → reusable-dispatch.yml	FIXED
3	Contradiction "kept" vs "(and deleted)"	FIXED
4	Substantial rewrite of accepted ADR 0048	FIXED (now a compliant cross-ref annotation)
5	Plan title "ADR 55" mismatch	PARTIAL (now says "ADR 60" — still wrong)
6	Empty relates_to	FIXED (agent-infrastructure)
7	Misleading "release-branch solution" link text	FIXED
8	Missing architecture.md update	FIXED

6 of 8 fully fixed. Nice work.

Remaining / New Findings

Severity	File	Finding
HIGH	0061-dispatch-version-skew.md	ADR number collision persists. 0061-harness-cel-dispatch.md already exists on main. Rebase + /renumber-adr needed — next available is likely 0062. All 5 files reference 0061.
MEDIUM	merge-stage-workflows.md:1,7	Plan title/body says "ADR 60" — stale from prior renumbering round. Two occurrences.
MEDIUM	0061-dispatch-version-skew.md:80	Grammar unfixed from prior round: "allow per-org mode continue" → "to continue". Also missing comma on line 78.
MEDIUM	0061-dispatch-version-skew.md:89-90	Consequence #2 near-duplicates #1. Only 2 bullets (target 3-5). Missing: dispatch file grows large, sync requirement during deprecation.

Convention Checks (Updated)

Check	Status
Template compliance	PASS
Conciseness	WARN — 80 lines (exactly at threshold); filler sentence removable
One decision	PASS — "However" paragraph is a constraint, not a second decision
Link, don't repeat	PASS
Cross-references	PASS — all 6 link paths verified correct
Living doc updates	PASS — architecture.md entry well-placed and formatted
ADR 0048 annotation	PASS — compliant cross-reference, original preserved

Suggested Fix Order

1. Rebase onto main, /renumber-adr to 0062, update all 5 files
2. Fix plan title + body to match final number
3. Grammar: "to continue", "However,"
4. Deduplicate consequences, add missing bullets, drop filler sentence

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 7:22 AM UTC · Completed 7:36 AM UTC
Commit: 3581422 · View workflow run →

Superseded by updated review

[waynesun09]

ADR Review — Round 3 (final)

All 12 findings from rounds 1 and 2 are resolved:

• ADR renumbered to 0062 (no collision on main)
• Grammar fixed ("to continue", "However, as")
• Consequences expanded to 3 distinct bullets
• Plan title and body updated to "ADR 62"
• ADR 0048 annotation is convention-compliant
• architecture.md entry added
• All cross-reference links verified correct

Remaining nits (non-blocking)

#	Sev	Finding
1	LOW	ADR 44 referenced as plain text (see ADR 44) — consider hyperlinking to [ADR 44](0044-deprecate-per-org-installation-mode.md) for consistency with the ADR 48 link
2	LOW	Plan amendments YAML comment uses .yaml extension (reusable-dispatch.yaml) — actual files use .yml
3	INFO	ADR 0062 number is also claimed by open PRs #2791, #2743, #2409, and #1413 — whichever merges first claims it; losers renumber. Not a defect in this PR, just a heads-up. Consider using /renumber-adr if a collision occurs before merge.

Convention Checks

Check	Result
Template compliance	PASS
Conciseness (~80 lines, 2 context paras, 3 consequence bullets)	PASS
One decision per ADR	PASS
Link, don't repeat	PASS
Cross-references	PASS (1 LOW nit)
Living doc updates (architecture.md)	PASS
ADR 0048 immutability	PASS — annotations are convention-compliant

LGTM. All prior issues addressed, no new blockers.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 4:44 PM UTC · Completed 4:53 PM UTC
Commit: 3581422 · View workflow run →

[fullsend-ai-retro]

Retro: PR #2453 — ADR for dispatch version-skew resolution

Timeline: Human-authored docs PR by rh-hemartin, open Jun 19 – merged Jul 1 (12 days). Added ADR 0062 with implementation plan, cross-references to ADR 0048, and architecture.md entry. Three rounds of human review (ifireball, waynesun09). The review bot ran 4 cycles (3 dismissed, 1 final approval).

What went well:

• The bot caught 4 genuine findings humans didn't flag: input-name mismatch in fallback snippet, per-ord typo, option label misnumbering, and a missing force-push step. These are real consistency/correctness catches.
• Human reviewers provided high-quality architectural feedback (ifireball suggested a 4th design option and prompted the ADR split; waynesun09 did 3 structured rounds catching ADR number collisions and convention violations).

Key gaps:

• ADR number collision — the most critical finding in the entire review — was caught by waynesun09 twice (HIGH) but never by the bot despite 4 review cycles. However, this is already tracked by Add CI lint check for ADR number collisions against target branch #992 (CI lint check for ADR number collisions) and Code agent should auto-invoke renumber-adr when creating ADR files #1570 (auto-invoke renumber-adr). Skipping proposal.
• Redundant workflow triggers — 39 workflow runs for a 5-file docs PR. Extensively covered by existing issues (Reduce redundant review dispatches triggered by non-code events #893, Filter pull_request_review trigger to only fire on changes_requested #1125, dispatch: filter bot-triggered pull_request_review events to prevent review self-triggering loop #1271, Suppress review dispatch when human CHANGES_REQUESTED is active #1791, Add per-PR review budget to cap runaway review dispatches #2599). Skipping proposal.
• Bot severity miscalibration — the bot consistently under-rated ADR convention violations compared to human reviewers. See proposal below.

Existing issues that would have helped this PR:

• Add CI lint check for ADR number collisions against target branch #992: CI lint for ADR number collisions (would have caught the collision on first push)
• Filter pull_request_review trigger to only fire on changes_requested #1125: Filter pull_request_review to changes_requested only (would have eliminated ~20 of the 30 review-triggered workflow runs)
• Suppress review dispatch when human CHANGES_REQUESTED is active #1791: Suppress review dispatch when human CHANGES_REQUESTED is active (would have skipped 2-3 bot re-reviews)

Proposals filed

• Review agent should rate ADR convention violations at medium+ severity (in fullsend-ai/fullsend)