docs: correct examples/reusable.yml pin guidance (prefer @sha; runners cache @v1) #15
Reference in New Issue
Block a user
Delete Branch "test/trigger-check"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Small doc fix — the
examples/reusable.ymlcomment said@v1"auto-updates on releases," but long-lived act_runners cache the reusable by ref, so a moved tag isn't re-fetched. Recommend an immutable@<sha>; routine swarm tuning rides owner variables instead.Also serving as a trigger smoke-test of the new runtime-variable reusable: this PR's own review should launch the full swarm assembled entirely from the
GADFLY_DEFAULT_*/GADFLY_ENDPOINT_*variables (includingragnaros).🤖 Generated with Claude Code
🪰 Gadfly — live review status
7/7 reviewers finished · updated 2026-06-28 06:13:55Z
claude-code/opus· claude-code — ✅ doneclaude-code/opus:max· claude-code — ✅ doneclaude-code/sonnet· claude-code — ✅ donedeepseek-v4-pro:cloud· ollama-cloud — ✅ doneglm-5.2:cloud· ollama-cloud — ✅ doneminimax-m3:cloud· ollama-cloud — ✅ doneragnaros/qwen3.6-27b· ragnaros — ✅ doneLive status board. Findings are posted in each model's own comment. Advisory only — does not block merge.
🪰 Gadfly review —
glm-5.2:cloud(ollama-cloud)Verdict: Minor issues — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — No material issues found
VERDICT: No material issues found
examples/reusable.ymlin full. This is a comment-only change; no workflow logic, secrets forwarding, permissions, triggers, oruses:ref were modified. The security-relevant guidance (least-privilegesecrets:forwarding, immutable@<sha>pinning to avoid stale-cache execution with forwarded credentials, avoiding@main) is sound and accurately describes the risk.examples/reusable.yml:53-54now tells users to "pin to an immutable@<sha>" because@v1/@maincan run stale, yet the actualuses:line atexamples/reusable.yml:55is still…review-reusable.yml@v1. As an example stub this is a placeholder, so it's not a vulnerability — but a reader copying the template verbatim keeps the ref the comment just warned against. Verified by reading the file; no code-level security impact.🎯 Correctness — Minor issues
Verdict: Minor issues
This is a documentation/comment-only change. Through the correctness lens, the substantive question is whether the new guidance is technically correct and internally consistent with the rest of the repo.
Internal contradiction with the reusable workflow's own header.
examples/reusable.yml:17-21now tells consumers to pin an immutable@<sha>and warns that@v1"is often not re-fetched and silently runs a stale copy." But the reusable workflow file itself,.gitea/workflows/review-reusable.yml:29-31, still asserts the opposite: "Consumers should pinuses: ...@v1— a curated release tag moved on deliberate releases, so central tuning here propagates without per-consumer edits." Its example snippet at line 9 also uses@v1. These two files now give directly conflicting pinning guidance for the sameuses:line. The example's premise ("runners cache the ref, so @v1 can run stale") refutes the reusable's stated rationale ("so central tuning propagates without per-consumer edits"). The PR fixes one doc surface and leaves the authoritative one self-contradictory.The
uses:line still pins@v1while the surrounding comment says pin@<sha>.examples/reusable.yml:53-55: the new comment (lines 53-54) says "Pin to an immutable @," but the unchangeduses:on line 55 is…review-reusable.yml@v1. The example as shipped — what a consumer copies — still demonstrates the@v1the comment now warns against. A copy-paste consumer gets stale-copy risk the comment exists to warn about, with nothing flagging the contradiction.Both are correctness-of-guidance issues (the file's job is to be copied as a working stub). Suggested fixes:
.gitea/workflows/review-reusable.yml:9,29-31to match the new@<sha>guidance, or reconcile the caching claim.examples/reusable.yml:55to an actual@<sha>placeholder (e.g.@<full-sha>with a note to substitute) so the shipped example matches its own advice, or add a one-line "replace @v1 below with a @" note so the contradiction isn't silent.No runtime/logic code is touched, so no execution-path bugs.
🧹 Code cleanliness & maintainability — Minor issues
Verdict: Minor issues
examples/reusable.yml:53-55— the example contradicts its own freshly-corrected advice. The new comment at lines 53-54 says "Pin to an immutable @ (runners cache the ref, so @v1/@main can run stale)," but line 55 still readsuses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1. The stub demonstrates exactly the pattern it now warns against. A user copy-pasting this consumer copies@v1, which the comment labels stale-prone. Either swap theuses:to a@<sha>placeholder (e.g.@<full-sha>with a note to replace) or add a one-line acknowledgement that the example keeps@v1only as a stand-in for the reader's pinned sha. Verified by reading the file (lines 50-55).examples/reusable.yml:18— "CACHE" in all-caps is a stylistic outlier. The surrounding comments use normal prose capitalization (e.g. "Forward ONLY the secrets" only emphasizes the key word). "CACHE" mid-sentence reads like a leftover emphasis marker; "cache" fits the tone better. Trivial, but it's the kind of noise that makes the comment feel copy-pasted. Verified by reading lines 14-21.No other cleanliness/maintainability issues: the README cross-reference ("Central config via variables") resolves correctly, and the rewritten comment block is coherent and no longer claims
@v1auto-updates.⚡ Performance — No material issues found
No material issues found.
The diff is documentation-only (comment text changes in
examples/reusable.yml), so there's no code-path, hot loop, allocation, query, or any runtime behavior change to scrutinize for performance regressions. Verified by reading the full file — lines 14–21 and 50–54 are pure prose; theuses:ref at line 55 is unchanged (@v1), so no call-frequency or work-per-run change results from this PR. Nothing in the performance lens applies.🧯 Error handling & edge cases — No material issues found
VERDICT: No material issues found
This is a comment-only documentation change in
examples/reusable.yml. From the error-handling / edge-case lens:uses:line itself is untouched (@v1still present at line 55); only the comment above it was rewritten. So the new guidance ("pin to an immutable@<sha>") is advisory and doesn't alter what the workflow actually resolves. Whether the runner-cache-staleness claim is factually accurate is a documentation-correctness concern, not an error-handling one.Nothing in my lane is materially wrong.
Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 58s
🪰 Gadfly review —
claude-code/opus(claude-code)Verdict: Minor issues — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — No material issues found
This is a documentation-only diff to comment text in
examples/reusable.yml. I've read the full file to evaluate it through the security lens.VERDICT: No material issues found
Through the security (supply-chain) lens, this change is sound and, if anything, improves security posture:
@v1for auto-updating stability" with "pin to an immutable@<sha>." Pinning a third-party reusable workflow to an immutable commit SHA is the standard supply-chain hardening recommendation — a mutable tag (@v1) or branch (@main) can be repointed at attacker-controlled code that then executes with the consumer's forwarded secrets. Recommending the immutable pin is the more secure guidance. Verified against the file: the surroundingsecrets:block (lines 59–63) practices least-privilege forwarding, consistent with the advice.Two honest observations, neither blocking:
examples/reusable.yml:18-21— The rewrite drops the explicit security rationale the old text carried ("a moved tag … would change what runs with your forwarded secrets") in favor of a staleness/caching rationale. The recommendation lands in the same (secure) place, but the threat-model justification for the SHA pin is now implicit. Re-adding a half-clause on the secrets-execution risk would keep the why security-grounded, not just operational. Minor.examples/reusable.yml:55— The prose now says "pin to an immutable@<sha>," but the example's actualuses:line still ships@v1. A copy-paster following the example verbatim inherits a mutable pin despite the advice. This is a pre-existing line untouched by the diff (and the file is a placeholder template, e.g.your-username), so it's a doc-consistency nit more than a security defect — and consistency belongs more to the docs lens than mine. Flagging only because it's the exact gap the diff is trying to close.Nothing in the security lane is materially wrong here.
🎯 Correctness — Minor issues
I've verified the finding against the actual file. Lines 17-21 and 53-54 mandate an immutable
@<sha>and explicitly warn that@v1/@maincan run stale, yet line 55 still usesuses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1. The inconsistency is real and confirmed.VERDICT: Minor issues
examples/reusable.yml:55— The prose now strongly mandates an immutable@<sha>and explicitly warns that@v1"can run stale" (lines 17-21 and 53-54), but the actualuses:line still pins@v1:uses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1. A consumer copy-pasting this stub gets exactly the stale-prone behavior the new comment warns against — the example contradicts its own corrected advice. This PR updated the guidance text but not the demonstrated pin it documents, so the fix is half-applied. Suggested fix: change line 55 to a placeholder consistent with the file's existing style (it already usesyour-username), e.g....review-reusable.yml@<full-40-char-sha>, so the demonstrated pin matches the recommendation.🧹 Code cleanliness & maintainability — Minor issues
VERDICT: Minor issues
examples/reusable.yml:55— the demonstrateduses:line contradicts the example's own rewritten advice. This PR flips the prose (lines 17–21 and 53–54) to "Pin to an immutable@<sha>… a moved tag (@v1) … is often not re-fetched and silently runs a stale copy," but the actual reference a consumer copies still readsuses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1. Before this change the@v1was consistent with the old guidance ("@v1 = curated release tag (auto-updates)"); now the comment immediately above line 55 tells the reader to avoid@v1while the line itself demonstrates exactly that anti-pattern. A consumer who copies the file verbatim inherits the stale-cache behavior the new docs warn against. Suggested fix: change line 55 to a placeholder@<sha>(with a "replace with a real commit sha" note) so the demonstrated value matches the guidance.⚡ Performance — No material issues found
VERDICT: No material issues found
This PR changes only documentation comments in
examples/reusable.yml(the pin-guidance text and the inlineuses:comment). There is no executable code, no query, loop, allocation, or hot path involved — nothing within the Performance lens to evaluate.examples/reusable.yml:14-21and:53-54); the actualuses:reference and job logic are unchanged, so there is no runtime or efficiency impact whatsoever.Nothing in my area. (No "Outside my lens" note either — a docs-only comment change carries no severe cross-cutting issue.)
🧯 Error handling & edge cases — No material issues found
VERDICT: No material issues found
This PR changes only comment text in
examples/reusable.yml(pin-guidance wording:@v1→ immutable@<sha>). There is no code, control flow, or runtime behavior in the diff — both hunks are YAML#comments.Through the error-handling & edge-cases lens there is nothing to evaluate: no error paths, cleanup, nil/empty/boundary conditions, or input handling are introduced or altered. The example's actual logic (the
if:gate,uses:,secrets:block) is untouched.Nothing in my lane here.
Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 44s
🪰 Gadfly review —
minimax-m3:cloud(ollama-cloud)Verdict: Minor issues · ⚠️ 3/5 lens(es) errored — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — Minor issues
VERDICT: Minor issues
Security findings (verified):
examples/reusable.yml:55— The new comment block (lines 17–21 and 53–54) now strongly recommends pinning to an immutable@<sha>and explicitly warns that@v1can be silently stale due to runner caching. But the actionableuses:line on line 55 still readssteve/gadfly/.gitea/workflows/review-reusable.yml@v1. A consumer who copy-pastes this canonical "shortest way to subscribe" stub gets the exact pattern the comment is warning against — a mutable moving tag executed against their forwarded secrets (OLLAMA_CLOUD_API_KEY, optionalCLAUDE_CODE_OAUTH_TOKEN,GADFLY_FINDINGS_TOKEN, etc.). From a supply-chain/integrity angle this defeats the new guidance: the doc now argues for SHA-pinning but the example demonstrates the tag-pin it just argued against. Fix: either change line 55 to@<sha>(a real full SHA) to model the recommended posture, or downgrade the comment to "prefer@<sha>; this example uses@v1for brevity" so the file is self-consistent. Verified by reading lines 17–21, 53–55 ofexamples/reusable.ymland grep-confirming there is no other@<sha>example inexamples/.🎯 Correctness — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ollama-cloud/minimax-m3☁️ ollama-cloud/minimax-m3☁️ HTTP 429: too many concurrent requests
🧹 Code cleanliness & maintainability — Minor issues
VERDICT: Minor issues
examples/reusable.yml:17–21andexamples/reusable.yml:53–54carry near-identical guidance about@<sha>pinning plus owner-variable tuning; the inlineuses:comment is largely a restatement of the header block. From a cleanliness angle the inline comment could be trimmed to just the actionable instruction (e.g. the pin syntax) and let the header carry the rationale. Verified by reading the whole file.examples/reusable.yml:53actively contradicts.gitea/workflows/review-reusable.yml:29–31, which still endorses@v1as a curated-pointer alternative ("Consumers should pinuses: ...@v1— a curated release tag moved on deliberate releases, so central tuning here propagates without per-consumer edits — or a full@<sha>for an immutable pin. Avoid@main"). The new stub now warns@v1/@main can run stalewhile the upstream reusable still tells consumers@v1is fine. Note: this drift is only withreview-reusable.yml—README.md:316–319andCLAUDE.md:53–54actually agree with the stub's new framing (they both already say caching makes moved tags stale and@<sha>is the reliable pin). The corrected claim is therefore narrower than the draft stated: one upstream file (review-reusable.yml) needs alignment, not three.⚡ Performance — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ollama-cloud/minimax-m3☁️ skipped (backed off until 06:10:59.202)
🧯 Error handling & edge cases — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ollama-cloud/minimax-m3☁️ skipped (backed off until 06:10:59.202)
Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 3m 0s
🪰 Gadfly review —
claude-code/sonnet(claude-code)Verdict: Minor issues — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — No material issues found
Verdict: No material issues found
This diff is purely a documentation/comment update. Through the security lens:
uses:pin unchanged (@v1on line 55): The diff correctly warns in comments that@v1and@maincan silently run stale copies due to act_runner caching — but notably, theuses:line itself still reads@v1, consistent with this being a consumer example that the adopter is expected to swap for a real SHA. The new comment text makes this guidance unambiguous. No security regression here.The change correctly strengthens supply-chain guidance (immutable SHA over mutable tag), which is a net security improvement in the documentation.
🎯 Correctness — Minor issues
The finding is confirmed. Line 55 reads
uses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1while lines 53–54 instruct the reader to "Pin to an immutable@<sha>" — a direct contradiction in copy-paste example code.Minor issues
examples/reusable.yml:53-55— The inline comment says "Pin to an immutable@<sha>" (imperative), but theuses:line immediately below it still reads@v1:The same inconsistency appears in the block comment at lines 17–21, which also instructs
@<sha>while the operativeuses:line stays at@v1. A consumer copying this stub verbatim will do exactly what the comment says not to do.Fix: Either update the
uses:line to a real immutable SHA (with a note to substitute the current one), or soften the comment to "prefer@<sha>; this example uses@v1as a readable placeholder — replace it with an immutable SHA before deploying."🧹 Code cleanliness & maintainability — Minor issues
The finding is confirmed. Line 55 reads
uses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1while the comment immediately above (lines 53-54) advises pinning to an immutable@<sha>.Minor issues
examples/reusable.yml:53-55— comment contradicts the example code it introducesThe updated comment says "Pin to an immutable
@<sha>" but the very next line still reads:This is the primary file users are told to copy verbatim ("Copy to
.gitea/workflows/adversarial-review.ymlin your repo"). After this PR, a reader who follows the comment advice will expect a sha, but will copy@v1anyway — the exact thing the comment just warned against. The old comment at least matched the code it sat above.Suggested fix: change the
uses:line to a sha-shaped placeholder so the example and the comment are consistent:(or document a real immutable sha and keep it updated). The inline comment on lines 14-21 has the same issue but is less acute because it isn't immediately adjacent to executable code.
⚡ Performance — No material issues found
All changes in this PR are pure comment edits inside a YAML example file. No executable code, no data structures, no algorithms, no runtime paths of any kind were touched.
No material issues found
This PR modifies only inline comments in
examples/reusable.yml— no logic, no data flow, no runtime behavior exists to evaluate. Performance lens has nothing to assess here.🧯 Error handling & edge cases — No material issues found
Verdict: No material issues found
This PR is a documentation-only change — both hunks modify only YAML comments explaining how to pin the reusable workflow reference. There is no code, logic, error handling, or control flow touched. My lens (error handling & edge cases) has nothing to evaluate here.
Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 14s
🪰 Gadfly review —
ragnaros/qwen3.6-27b(ragnaros)Review incomplete — all lenses errored — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ragnaros/qwen3.6-27b: ragnaros/qwen3.6-27b: HTTP 500: {"error":{"code":500,"message":"Context size has been exceeded.","type":"server_error"}}
🎯 Correctness — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ragnaros/qwen3.6-27b: skipped (backed off until 06:11:25.643)
🧹 Code cleanliness & maintainability — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ragnaros/qwen3.6-27b: skipped (backed off until 06:11:25.643)
⚡ Performance — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ragnaros/qwen3.6-27b: skipped (backed off until 06:11:25.643)
🧯 Error handling & edge cases — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ragnaros/qwen3.6-27b: skipped (backed off until 06:11:25.643)
Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 27s
🪰 Gadfly review —
deepseek-v4-pro:cloud(ollama-cloud)Verdict: Minor issues · ⚠️ 3/5 lens(es) errored — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — Minor issues
Verdict: Minor issues
examples/reusable.yml:55— Example still uses the now-discouraged@v1. The comment on lines 53–54 says "Pin to an immutable @<sha> (runners cache the ref, so @v1/@main can run stale)," but the actualuses:line right below it still readsuses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1. A user who copies this template and only substitutes the repo path — without reading the surrounding prose — will ship the very mutable-ref pattern the new comments warn against. The example should practice what it preaches: either swap@v1for a real@<sha>(and note that the user must update it), or at minimum add an inline# FIXME: replace @v1 with @<sha>on that line so the insecure default is impossible to miss. (Confirmed against the checked-out file.)No other security issues (injection, credential leakage, authz gaps, unsafe deserialization, SSRF) are present in this docs-only diff.
🎯 Correctness — Minor issues
The finding is confirmed. The comment on lines 53-54 explicitly advises pinning to an immutable
@<sha>, yet theuses:directive on line 55 still references@v1. This is a genuine self-contradiction in the example file.Verdict: Minor issues
examples/reusable.yml:53-55— Self-contradictory example: comment says "Pin to an immutable @" but theuses:line still references@v1. A user who copies this file as a template is told to do one thing while the actual line models the opposite. Theuses:reference should be updated to a real or placeholder@<sha>so the example is internally consistent with its own guidance.🧹 Code cleanliness & maintainability — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ollama-cloud/deepseek-v4-pro☁️ ollama-cloud/deepseek-v4-pro☁️ HTTP 429: too many concurrent requests
⚡ Performance — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ollama-cloud/deepseek-v4-pro☁️ skipped (backed off until 06:10:59.172)
🧯 Error handling & edge cases — ⚠️ could not complete
⚠️ This reviewer failed to complete: agent: step 0: all chain targets failed
ollama-cloud/deepseek-v4-pro☁️ skipped (backed off until 06:10:59.172)
Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 53s
🪰 Gadfly review —
claude-code/opus:max(claude-code)Verdict: Minor issues — 5 reviewers: security, correctness, maintainability, performance, error-handling
🔒 Security — No material issues found
This is a documentation-only change to an example workflow's comments. I've verified it against the actual file. Delivering my security-lens review.
VERDICT: No material issues found
Through the 🔒 Security lens, this change is net-positive and introduces nothing exploitable:
examples/reusable.yml:17-21— The diff replaces "prefer@v1for auto-updating stability" with a recommendation to pin to an immutable@<sha>. From a supply-chain/security standpoint this strengthens the guidance: pinning a third-party reusable workflow to an immutable commit is the secure posture, since a moved tag (@v1/@main) can silently change what executes with the consumer's forwarded secrets. No tainted-input, injection, authz, or secret-leakage surface is touched — it's comment text only. Verified by reading the full file.Minor observation (not blocking, and arguably outside this lens): the prose now justifies avoiding
@v1/@mainpurely as a caching/staleness concern and drops the old explicit security rationale ("would change what runs with your forwarded secrets"). The secret-exposure angle was the stronger reason to pin immutably; folding it entirely into a staleness argument slightly weakens the security framing even though the recommended action is correct. Optional: keep one clause noting that a moved ref also changes what runs against your forwarded secrets.Consistency note for another lens (docs/maintainability, not security): the
uses:line atexamples/reusable.yml:55still pins@v1while the surrounding comments now tell users to use@<sha>. Not a security defect — just a teach-by-example mismatch a docs reviewer should catch.No authn/authz gaps, injection, SSRF, deserialization, secret leakage, or input-validation issues are in scope for this diff — it changes only YAML comments.
🎯 Correctness — Minor issues
I've verified the draft's claims against the actual source. Both the diff and the surrounding files confirm the central finding.
VERDICT: Minor issues
This is a docs-only change to a copy-paste consumer stub. The new prose is factually accurate, but the change leaves the example internally inconsistent with its own new recommendation.
Findings
examples/reusable.yml:55— the example still ships@v1, the exact ref the new comment tells you not to use. Lines 17-21 and 53-54 now recommend "Pin to an immutable@<sha>" and warn that "a moved tag (@v1) or@mainis often not re-fetched and silently runs a stale copy" — yet the actualuses:line is stillsteve/gadfly/.gitea/workflows/review-reusable.yml@v1. A consumer who copies this stub verbatim (its stated purpose, line 2) gets exactly the cache-stale behavior the comment warns against. The prior version was self-consistent ("@v1 … or swap for a full @", matching the@v1in code); this PR updates the advice but not the demonstration. README confirms the intended guidance (README.md:316-318: reusable-workflow consumers "should pin the workflow ref to an immutablereview-reusable.yml@<sha>")....@<sha> # replace with the SHA from a Gadfly release, or keep@v1with an explicit# example only — pin a real @<sha>so the placeholder is clearly a placeholder.Outside the diff
The sibling reusable workflow
.gitea/workflows/review-reusable.yml:29-31still carries the older advice this PR deprecates ("Consumers should pinuses: ...@v1— a curated release tag … or a full@<sha>"). Not in this diff, but it now contradicts both the README and this corrected example — worth a follow-up so the pin guidance is consistent project-wide.🧹 Code cleanliness & maintainability — Minor issues
Both findings check out against the actual files. Line 55 of
examples/reusable.ymlstill reads@v1while the comment block (lines 17–19, 53–54) now explicitly warns against@v1and tells readers to pin to an immutable@<sha>. Andreview-reusable.ymllines 29–31 still recommend@v1for "auto-updating" propagation, which contradicts lines 42–43 of the same file (moved tag is NOT re-fetched; only a runtime value or fresh@<sha>bypasses the cache), and lines 9/55 of the skeleton carry@v1. Both are confirmed.VERDICT: Minor issues
examples/reusable.yml:55— the example contradicts its own freshly-corrected guidance. The updated comments now state "Pin to an immutable@<sha>" and explicitly flag@v1as a moved tag that "is often not re-fetched and silently runs a stale copy" (lines 17–19, 53–54), yet the actual directive on line 55 still reads...review-reusable.yml@v1. A consumer who copies this stub verbatim — the file's stated purpose (line 2) — gets exactly the stale-run behavior the comment warns against. Fix: change line 55 to a placeholder like...review-reusable.yml@<commit-sha>, keeping@v1only as the "bad example" in prose..gitea/workflows/review-reusable.yml:9, 29–31— sibling doc still carries the old, now-contradicted guidance. Lines 29–31 still say "Consumers should pinuses: ...@v1— a curated release tag moved on deliberate releases, so central tuning here propagates without per-consumer edits." That claim is the one this change corrects elsewhere, and it already contradicts lines 42–43 of the same file ("a moved tag is NOT re-fetched; only a runtime value or a fresh@<sha>bypasses the cache"). CLAUDE.md's maintenance rule treats stale docs as a bug and asks for doc updates "in the same change"; this header (and the@v1in the skeleton at line 9) was left behind. Fix: align lines 9 and 29–31 with the immutable-@<sha>recommendation now in the README and example.Net: the prose edits are correct, but the change updated the narrative text while leaving the two concrete
@v1references (the copy-pasted example directive and the reusable's own header) saying the opposite — readers following either literally land in the stale-cache trap.⚡ Performance — No material issues found
VERDICT: No material issues found
This is a documentation-only change — it rewrites two comment blocks in
examples/reusable.yml(the pin-guidance prose and the inlineuses:comment). There is no executable code, no query path, no loop, no allocation, and no runtime behavior altered by this diff.#-prefixed lines and the existinguses:line is unchanged in effect.Outside my lens: the substance of the guidance change (runners cache
@v1by ref → prefer@<sha>) is consistent with the documentedLessons/architecture notes inCLAUDE.md, so it reads as accurate, but correctness/docs is another reviewer's call.🧯 Error handling & edge cases — No material issues found
VERDICT: No material issues found
This diff changes only comment text in
examples/reusable.yml(the pin-guidance lines atexamples/reusable.yml:17-21and:53-54). I read the full file to confirm there is no accompanying code change — no scripts, no logic, no error paths, no input parsing.Through the error handling & edge cases lens there is nothing to evaluate: no swallowed errors, no cleanup/rollback, no nil/empty/zero/boundary conditions, and no unhappy paths are introduced or altered by a comment-only edit. Verified by reading
examples/reusable.ymlend to end.Outside my lens (one line, severe-ish only as doc accuracy, not error handling): the new comment at
examples/reusable.yml:53advises pinning to an immutable@<sha>, but the actualuses:on:55still resolves to@v1— a correctness/docs reviewer should confirm that's intended for an example stub rather than a copy that contradicts its own guidance.Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 2m 0s