Repository navigation
docs(fullsend): define pin-and-bump process and supported fullsend commit - #343
Conversation
…mmit Record fullsend main commit 9f188578 (2026-10-14, untagged) as the supported commit for both the GitHub verify-pr and GitLab triage-security deployments: it is the first reviewed main commit with the GitLab project lease (#8258), role service-account lifecycle (#8313) and webhook Poller hand-off (#8397); v0.47.1 predates the latter two. Document the update path from v0.43.0 / d5f36921 with the breaking changes that affect this repo (runner-owned credential model, Vertex credential preflight, host_files dest rules, Jira secret inheritance, post-comment author verification), and replace "Bumping the fullsend version" and "Pinning reusable-dispatch" with a single choose -> review -> pin -> re-lock -> verify process covering every pin point in both deployments, plus the decoupled-timing guard rule. No workflow, harness or lock file changes. Implements TC-6930 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assisted-by: Claude Code
Reviewer's GuideDocumentation-only update to fullsend.md establishing 9f188578 as the supported fullsend commit and consolidating the procedures, compatibility review, pin locations, lockfile requirements, and deployment guardrails for future independent GitHub and GitLab bumps. Flow diagram for the fullsend pin-and-bump processflowchart LR
choose[Choose reviewed fullsend commit] --> review[Review release range and breaking changes]
review --> adapt[Adapt harness or workflow content]
adapt --> pin[Pin deployment references]
pin --> relock[Re-lock affected agents]
relock --> verify[Verify end to end]
verify --> merge[Merge the bump]
Flow diagram for the fullsend pin guard ruleflowchart LR
adapt[Adapt plugin content for newer fullsend] --> pins{GitHub CLI and reusable-dispatch pins bumped?}
pins -->|No| wait[Wait before moving verify-pr base]
pins -->|Yes| repin[Re-pin verify-pr base]
gitlab[GitLab CLI pin] --> independent[GitLab may adopt adapted content independently]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 3 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="fullsend.md" line_range="431" />
<code_context>
+2. **Review** the range from the current pin to the chosen commit — the release
+ notes of every tag in between and the untagged tail:
+ ```bash
+ gh api repos/fullsend-ai/fullsend/releases --jq '.[] | "\(.tag_name) \(.published_at)"'
+ gh api repos/fullsend-ai/fullsend/compare/<current-tag-or-sha>...<sha>
+ ```
</code_context>
<issue_to_address>
**Upgrade review silently truncates**
When an upgrade range contains more than 30 releases or commits, the `gh api` commands fetch only one API page by default, so ranges with more than 30 releases or commits leave changes unreviewed and can move a deployment pin past a breaking change.
Paginate both API calls and verify that the complete release list and commit range were reviewed.
Also at `fullsend.md:432`.
</issue_to_address>
### Comment 2
<location path="fullsend.md" line_range="421" />
<code_context>
+Each step names every pin point. A deployment that is not being bumped is left
+untouched — the GitHub and GitLab deployments bump independently.
+
+1. **Choose** a commit on fullsend `main` — never a floating ref (`main`, `v0`).
+ Prefer the commit of a release tag when that tag already contains the features
+ you need; otherwise pick a reviewed `main` SHA. Confirm it is on `main`:
</code_context>
<issue_to_address>
**Older bump regresses deployment**
When two maintainers prepare bumps from the same deployed pin, the newer bump merges first, and the older bump is then resolved and merged, the older update can merge after a newer one and overwrite the deployment pins with its stale commit, regressing the deployed version and potentially dropping features. The process does not require checking that the proposed pin is still newer than the deployed pin before merging.
Before merging a bump, compare its proposed commit with the deployment's current pin and reject or re-review any update that would regress it.
</issue_to_address>
### Comment 3
<location path="fullsend.md" line_range="348" />
<code_context>
+|---|---|
+| Commit | [`9f188578f0d8c94169287594b0c79cd4c4eeaa91`](https://github.com/fullsend-ai/fullsend/commit/9f188578f0d8c94169287594b0c79cd4c4eeaa91) on `fullsend-ai/fullsend` `main` (merge of #8394) |
+| Date | 2026-10-14 (09:26 UTC) |
+| Tag | none — the newest release, `v0.47.1` (`c68903c0`, 2026-10-11), predates #8313 and #8397 |
+
+**Why this commit:** it is the first reviewed `main` commit carrying all of the
</code_context>
<issue_to_address>
**Outdated release guidance**
When a maintainer consults the workflow's pin rationale while planning a future bump, the workflow comment still calls `v0.43.0` the latest release while this section identifies `v0.47.1` as the newest, so maintainers can miss later releases when reviewing what to bump.
Update the workflow comment to identify the current latest release.
</issue_to_address>Sourcery assessment
Approval pending. 3 findings to address first.
Blocking findings: fullsend.md:431, fullsend.md:421, fullsend.md:348
|
🤖 Finished Verify Pr · ✅ Success · Started 8:49 AM UTC · Completed 9:01 AM UTC Commit: Runtime: claude · Model: claude-opus-4-8 · Effort: high · Cost: $5.19 |
|
[sdlc-workflow/verify-pr] Re: @sourcery-ai[bot] review — the review summary restates the three inline findings, each classified as code change request and tracked by a sub-task:
No additional sub-tasks were created for the review body itself, since it duplicates the inline comments above. |
Verification Report for TC-6930 (commit 5db9834)
Overall: WARNAll substantive quality gates pass: the PR changes only fullsend.md, satisfies all 5 acceptance criteria, passes 7/7 CI checks, contains no secrets, and the commit traces to TC-6930. Overall is WARN only because sourcery-ai raised 3 code change requests (API pagination in the documented review step, a concurrent-bump regression guard, and a stale 'latest release' comment in the out-of-scope verify-pr workflow file). Each is tracked by a review-feedback sub-task blocking TC-6930. Root-cause investigation found all three are localized, review-caught documentation refinements — no systemic define/plan/implement-task or convention gap — so no root-cause tasks were created. This report is informational; a human reviewer decides whether to merge. Review-feedback sub-tasks created (each Blocks TC-6930, Target PR #343):
This comment was AI-generated by sdlc-workflow/verify-pr v0.13.10. |
The Review step's gh api calls returned only the first API page, so an upgrade range with more than 30 releases or commits was silently truncated. Add --paginate (per_page=100) to the releases and compare calls and require the reviewer to confirm full coverage: the release list reaches the current pin's tag and the listed commit count equals the compare response's total_commits. Implements TC-6956 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assisted-by: Claude Code
Require the proposed fullsend commit to be ahead of the deployment's currently deployed pin (gh api compare <deployed>...<proposed> must return "ahead"), checked at Choose and again right before merging, so an older bump prepared concurrently cannot merge after a newer one and regress the deployed pins. Implements TC-6957 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assisted-by: Claude Code
The fullsend_version comment still called v0.43.0 the current latest release. Note that v0.43.0 was latest when pinned, that v0.47.1 is the latest as of 2026-10-15, and point to fullsend.md's pin-and-bump section for the supported commit. Comment-only: the fullsend_version and reusable-dispatch pins are unchanged. Implements TC-6958 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assisted-by: Claude Code
|
🤖 Finished Verify Pr · ✅ Success · Started 9:33 AM UTC · Completed 9:42 AM UTC Commit: Runtime: claude · Model: claude-opus-4-8 · Effort: high · Cost: $4.90 |
Verification Report for TC-6930 (commit 67fe7e8)
Overall: WARNDocumentation-only PR that satisfies all 5 acceptance criteria; CI is green and no secrets were detected. The WARNs are contextual/informational, not blockers:
This is an idempotent re-run on commit This comment was AI-generated by sdlc-workflow/verify-pr v0.13.10. |
Summary
maincommit9f188578(2026-10-14, untagged) infullsend.mdas the supported commit for both deployments. It is the first reviewedmaincommit with the GitLab project lease (#8258), the role service-account lifecycle (#8313) and the webhook Poller hand-off (#8397). The newest release, v0.47.1, predates #8313 and #8397.v0.43.0/d5f36921, listing the breaking changes that affect this repo: the runner-owned credential model (GOOGLE_APPLICATION_CREDENTIALSis no longer exported), the Vertex credential preflight, thehost_filesdest rules, Jira secrets no longer inherited by host scripts, and theissues post-commentauthor check. It also lists the breaking changes that were checked and need no action here.uses:@sha+fullsend_version, the harnessbase:lines,fullsend lock, and the sdlc-fullsend.gitlab-ci.ymlCLI pin.base:must not move to fullsend-adapted plugin content until the GitHub CLI and reusable-dispatch pins have been bumped.gh apicalls now paginate, and the reviewer must confirm complete coverage (the listed commit count equalstotal_commits).aheadof the deployed pin, checked at Choose and again right before merging (covers concurrent bumps).fullsend-verify-pr.yml. No pin changed.Verification
fullsend-ai/fullsendand is an ancestor ofmain(compare/9f188578...main→ahead, behind 0).fullsend_versionfallback tojob.workflow_shawas checked againstreusable-dispatch.ymlat the supported commit.uvx skillsaw: 0 errors.claude plugin validate plugins/sdlc-workflow: passed.Implements TC-6930
🤖 Generated with Claude Code
Summary by Sourcery
Document the reviewed fullsend baseline and the coordinated process for safely pinning, reviewing, re-locking, and verifying future updates.
New Features:
Enhancements:
Documentation: