ci: track gadfly's v1 release tag instead of a pinned sha #15

Merged

steve merged 1 commits from ci/gadfly-v1 into main 2026-06-28 04:08:31 +00:00

Conversation 7 Commits 1 Files Changed 1

+4 -3

steve commented 2026-06-28 04:04:52 +00:00

Owner

Copy Link

Copy Source

Switch uses: …review-reusable.yml@b02b11d → @v1 (gadfly's moving release tag).

Central swarm tuning in gadfly now propagates here automatically on each release — no more re-pinning this file every time the default changes. v1 is re-pointed deliberately on releases (unlike @main, which moves on every push); the tradeoff vs a sha pin is that v1 is mutable.

Currently v1 = the 3-cloud + Claude Code swarm with claude-code 3 models × 5 lenses. Advisory only.

🤖 Generated with Claude Code

Switch `uses: …review-reusable.yml@b02b11d` → **`@v1`** (gadfly's moving release tag). Central swarm tuning in gadfly now propagates here automatically on each release — no more re-pinning this file every time the default changes. `v1` is re-pointed deliberately on releases (unlike `@main`, which moves on every push); the tradeoff vs a sha pin is that `v1` is mutable. Currently `v1` = the 3-cloud + Claude Code swarm with claude-code 3 models × 5 lenses. Advisory only. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

steve added 1 commit 2026-06-28 04:04:52 +00:00

ci: track gadfly's v1 release tag instead of a pinned sha ... 1332286757

Switch uses: steve/gadfly/.gitea/workflows/review-reusable.yml from a sha pin
(@b02b11d) to the moving @v1 release tag, so central swarm tuning propagates
without re-pinning this file each time. Tradeoff: v1 is mutable (re-moved on
deliberate releases), vs a sha which is immutable — accepted to cut re-pin churn.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

gitea-actions bot commented 2026-06-28 04:04:54 +00:00

Copy Link

Copy Source

🪰 Gadfly — live review status

6/6 reviewers finished · updated 2026-06-28 04:06:46Z

claude-code/opus · claude-code — ✅ done

• ✅ security — Minor issues
• ✅ correctness — No material issues found
• ✅ maintainability — No material issues found
• ✅ performance — No material issues found
• ✅ error-handling — No material issues found

claude-code/opus:max · claude-code — ✅ done

• ✅ security — Blocking issues found
• ✅ correctness — No material issues found
• ✅ maintainability — No material issues found
• ✅ performance — No material issues found
• ✅ error-handling — No material issues found

claude-code/sonnet · claude-code — ✅ done

• ✅ security — Blocking issues found
• ✅ correctness — No material issues found
• ✅ maintainability — No material issues found
• ✅ performance — No material issues found
• ✅ error-handling — No material issues found

deepseek-v4-pro:cloud · ollama-cloud — ✅ done

• ✅ security — Minor issues
• ✅ correctness — No material issues found
• ✅ maintainability — Minor issues
• ✅ performance — No material issues found
• ✅ error-handling — Minor issues

glm-5.2:cloud · ollama-cloud — ✅ done

• ✅ security — Blocking issues found
• ✅ correctness — No material issues found
• ✅ maintainability — Minor issues
• ✅ performance — No material issues found
• ✅ error-handling — No material issues found

minimax-m3:cloud · ollama-cloud — ✅ done

• ✅ security — Blocking issues found
• ✅ correctness — No material issues found
• ✅ maintainability — No material issues found
• ✅ performance — No material issues found
• ✅ error-handling — No material issues found

_{Live status board. Findings are posted in each model's own comment. Advisory only — does not block merge.}

<!-- gadfly-status-board --> ## 🪰 Gadfly — live review status 6/6 reviewers finished · updated 2026-06-28 04:06:46Z #### `claude-code/opus` · claude-code — ✅ done - ✅ **security** — Minor issues - ✅ **correctness** — No material issues found - ✅ **maintainability** — No material issues found - ✅ **performance** — No material issues found - ✅ **error-handling** — No material issues found #### `claude-code/opus:max` · claude-code — ✅ done - ✅ **security** — Blocking issues found - ✅ **correctness** — No material issues found - ✅ **maintainability** — No material issues found - ✅ **performance** — No material issues found - ✅ **error-handling** — No material issues found #### `claude-code/sonnet` · claude-code — ✅ done - ✅ **security** — Blocking issues found - ✅ **correctness** — No material issues found - ✅ **maintainability** — No material issues found - ✅ **performance** — No material issues found - ✅ **error-handling** — No material issues found #### `deepseek-v4-pro:cloud` · ollama-cloud — ✅ done - ✅ **security** — Minor issues - ✅ **correctness** — No material issues found - ✅ **maintainability** — Minor issues - ✅ **performance** — No material issues found - ✅ **error-handling** — Minor issues #### `glm-5.2:cloud` · ollama-cloud — ✅ done - ✅ **security** — Blocking issues found - ✅ **correctness** — No material issues found - ✅ **maintainability** — Minor issues - ✅ **performance** — No material issues found - ✅ **error-handling** — No material issues found #### `minimax-m3:cloud` · ollama-cloud — ✅ done - ✅ **security** — Blocking issues found - ✅ **correctness** — No material issues found - ✅ **maintainability** — No material issues found - ✅ **performance** — No material issues found - ✅ **error-handling** — No material issues found _{Live status board. Findings are posted in each model's own comment. Advisory only — does not block merge.}

gitea-actions bot commented 2026-06-28 04:04:55 +00:00

Copy Link

Copy Source

🪰 Gadfly review — claude-code/sonnet (claude-code)

Verdict: Blocking issues found — 5 reviewers: security, correctness, maintainability, performance, error-handling

🔒 Security — Blocking issues found

The file confirms every factual claim in the draft. The @v1 tag is at line 44, all four secrets are forwarded (lines 48–51), the actor gate is present (lines 35–40), and secrets: inherit was explicitly avoided. The new comment on lines 41–43 even self-documents the mutable tradeoff, matching the draft's characterization precisely.

The finding is confirmed. No corrections needed.

---

Blocking issues found

• Supply-chain secret exposure via mutable tag — .gitea/workflows/adversarial-review.yml:44

  The old SHA pin (b02b11d…) was there for an explicit reason stated in the removed comment: "a push to gadfly can't silently change the code that runs with our forwarded secrets." Replacing it with @v1 removes that guarantee. The v1 tag is lightweight and mutable — anyone with write access to steve/gadfly can git tag -f v1 <any-commit> and force-push, redirecting the workflow to arbitrary code. The next time an actor from the allowlist triggers this workflow, the new code runs with all four forwarded secrets:

  • CLAUDE_CODE_OAUTH_TOKEN
  • OLLAMA_CLOUD_API_KEY
  • GADFLY_FINDINGS_URL / GADFLY_FINDINGS_TOKEN

  This is the textbook supply-chain attack against CI secret forwarding. The actor gate (lines 35–40) only limits who triggers the run — it does nothing to constrain what code runs once triggered. If steve/gadfly is compromised (or a maintainer makes an inadvertent tag move), those credentials are exfiltrated silently on the next legitimate /review comment.

  Mitigating context (verified by reading the file): least-privilege forwarding (secrets: inherit was explicitly avoided), actor gate is tight (three named users), and both repos appear same-owner. Whether that risk tolerance is acceptable is a policy call — but the security property the SHA pin was providing (immutable code for secret-bearing runs) is gone.

  Suggested fix: If convenience is the goal, keep @v1 but add a note that the tag must be verified (e.g. periodically audit v1 resolves to an expected SHA, or document the incident-response path if the tag is moved maliciously). If the secret forwarding is the concern, the correct mitigation is to re-pin to the SHA of the v1 commit after each deliberate gadfly release — giving you the propagation control of a named tag with the immutability of a SHA. Gitea also supports tag signatures; requiring a signed tag and verifying in CI would be a stronger control.

🎯 Correctness — No material issues found

No material issues found

• Reference syntax: uses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1 is syntactically correct for a Gitea reusable-workflow reference. Verified against the full file at .gitea/workflows/adversarial-review.yml:44.

• Actor list consistency: The if: guard (lines 38–40) and the allowed_users input (line 54) still both enumerate steve, fizi, dazed — the sync requirement called out in the comment at line 32 remains satisfied. This PR did not touch either list.

• Comment accuracy: The replacement comment correctly describes the semantics — v1 is a curated moving tag (re-pointed on releases) rather than a commit SHA or @main. The tradeoff (mutability) is disclosed. No logical contradiction between the comment and the behavior.

• No formula, threshold, or conversion factor is involved; nothing to re-derive.

The change is a deliberate, documented shift from an immutable pin to a curated mutable tag. Correctness of the reference itself (i.e., whether v1 actually exists in the upstream gadfly repo) can't be verified from this repo, but the PR description and the recent commit message both assert it does.

🧹 Code cleanliness & maintainability — No material issues found

Verdict: No material issues found

The diff is a one-line functional change (@b02b11d… → @v1) plus a three-line comment replacement.

• The old comment explained a sha pin as an immutability guarantee; the new comment accurately replaces that explanation with the v1 tag's semantics (curated pointer, mutable, propagates tuning). The language is clear and matches the PR description.
• There is a pre-existing duplicate line-number in the file (lines 33 and 33, 41 and 41 in the raw output) — that is a display artifact of the file already in the repo, not introduced by this diff.
• No dead code, no structural issues, no naming problems, no copy-paste drift. The change is the minimal edit needed.

Nothing in the cleanliness/maintainability lane warrants a finding here.

⚡ Performance — No material issues found

No material issues found

This change swaps one string reference in a YAML uses: field. There is nothing here in the performance lane: no code paths, no loops, no allocations, no queries. Tag resolution vs SHA resolution at CI trigger time is not a meaningful performance distinction. Nothing to report.

🧯 Error handling & edge cases — No material issues found

Verdict: No material issues found

Through the error-handling & edge-cases lens, this change is a one-line ref swap in a CI uses: directive. There is nothing new in terms of code paths, error handling logic, nil checks, rollback, or unhappy-path behavior — the workflow structure is unchanged.

The one relevant edge case for this lens is what happens when v1 doesn't resolve (tag deleted, typo, Gitea outage). In that scenario the CI job simply fails to start and the PR is left without a gadfly run — there is no silent success or data-loss risk. The workflow is already declared advisory-only (line 5), so a resolution failure has no worse consequence than the sha-pin failing the same way. No error-swallowing, no missing defer/cleanup, no panic path introduced.

_{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 37s}

<!-- gadfly-review:ollama:claude-code/sonnet --> ### 🪰 Gadfly review — `claude-code/sonnet` (claude-code) **Verdict: Blocking issues found** — 5 reviewers: security, correctness, maintainability, performance, error-handling <details><summary><b>🔒 Security</b> — Blocking issues found</summary> The file confirms every factual claim in the draft. The `@v1` tag is at line 44, all four secrets are forwarded (lines 48–51), the actor gate is present (lines 35–40), and `secrets: inherit` was explicitly avoided. The new comment on lines 41–43 even self-documents the mutable tradeoff, matching the draft's characterization precisely. The finding is confirmed. No corrections needed. --- **Blocking issues found** - **Supply-chain secret exposure via mutable tag** — `.gitea/workflows/adversarial-review.yml:44` The old SHA pin (`b02b11d…`) was there for an explicit reason stated in the removed comment: *"a push to gadfly can't silently change the code that runs with our forwarded secrets."* Replacing it with `@v1` removes that guarantee. The `v1` tag is lightweight and mutable — anyone with write access to `steve/gadfly` can `git tag -f v1 <any-commit>` and force-push, redirecting the workflow to arbitrary code. The next time an actor from the allowlist triggers this workflow, the new code runs with all four forwarded secrets: - `CLAUDE_CODE_OAUTH_TOKEN` - `OLLAMA_CLOUD_API_KEY` - `GADFLY_FINDINGS_URL` / `GADFLY_FINDINGS_TOKEN` This is the textbook supply-chain attack against CI secret forwarding. The actor gate (lines 35–40) only limits *who triggers* the run — it does nothing to constrain *what code* runs once triggered. If `steve/gadfly` is compromised (or a maintainer makes an inadvertent tag move), those credentials are exfiltrated silently on the next legitimate `/review` comment. **Mitigating context** (verified by reading the file): least-privilege forwarding (`secrets: inherit` was explicitly avoided), actor gate is tight (three named users), and both repos appear same-owner. Whether that risk tolerance is acceptable is a policy call — but the security property the SHA pin was providing (immutable code for secret-bearing runs) is gone. **Suggested fix**: If convenience is the goal, keep `@v1` but add a note that the tag must be verified (e.g. periodically audit `v1` resolves to an expected SHA, or document the incident-response path if the tag is moved maliciously). If the secret forwarding is the concern, the correct mitigation is to re-pin to the SHA of the `v1` commit after each deliberate gadfly release — giving you the propagation control of a named tag with the immutability of a SHA. Gitea also supports tag signatures; requiring a signed tag and verifying in CI would be a stronger control. </details> <details><summary><b>🎯 Correctness</b> — No material issues found</summary> **No material issues found** - **Reference syntax**: `uses: steve/gadfly/.gitea/workflows/review-reusable.yml@v1` is syntactically correct for a Gitea reusable-workflow reference. Verified against the full file at `.gitea/workflows/adversarial-review.yml:44`. - **Actor list consistency**: The `if:` guard (lines 38–40) and the `allowed_users` input (line 54) still both enumerate `steve`, `fizi`, `dazed` — the sync requirement called out in the comment at line 32 remains satisfied. This PR did not touch either list. - **Comment accuracy**: The replacement comment correctly describes the semantics — `v1` is a curated moving tag (re-pointed on releases) rather than a commit SHA or `@main`. The tradeoff (mutability) is disclosed. No logical contradiction between the comment and the behavior. - **No formula, threshold, or conversion factor** is involved; nothing to re-derive. The change is a deliberate, documented shift from an immutable pin to a curated mutable tag. Correctness of the reference itself (i.e., whether `v1` actually exists in the upstream gadfly repo) can't be verified from this repo, but the PR description and the recent commit message both assert it does. </details> <details><summary><b>🧹 Code cleanliness & maintainability</b> — No material issues found</summary> **Verdict: No material issues found** The diff is a one-line functional change (`@b02b11d…` → `@v1`) plus a three-line comment replacement. - The old comment explained a sha pin as an immutability guarantee; the new comment accurately replaces that explanation with the `v1` tag's semantics (curated pointer, mutable, propagates tuning). The language is clear and matches the PR description. - There is a pre-existing duplicate line-number in the file (lines 33 and 33, 41 and 41 in the raw output) — that is a display artifact of the file already in the repo, not introduced by this diff. - No dead code, no structural issues, no naming problems, no copy-paste drift. The change is the minimal edit needed. Nothing in the cleanliness/maintainability lane warrants a finding here. </details> <details><summary><b>⚡ Performance</b> — No material issues found</summary> **No material issues found** This change swaps one string reference in a YAML `uses:` field. There is nothing here in the performance lane: no code paths, no loops, no allocations, no queries. Tag resolution vs SHA resolution at CI trigger time is not a meaningful performance distinction. Nothing to report. </details> <details><summary><b>🧯 Error handling & edge cases</b> — No material issues found</summary> **Verdict: No material issues found** Through the error-handling & edge-cases lens, this change is a one-line ref swap in a CI `uses:` directive. There is nothing new in terms of code paths, error handling logic, nil checks, rollback, or unhappy-path behavior — the workflow structure is unchanged. The one relevant edge case for this lens is *what happens when `v1` doesn't resolve* (tag deleted, typo, Gitea outage). In that scenario the CI job simply fails to start and the PR is left without a gadfly run — there is no silent success or data-loss risk. The workflow is already declared advisory-only (line 5), so a resolution failure has no worse consequence than the sha-pin failing the same way. No error-swallowing, no missing `defer`/cleanup, no panic path introduced. </details> _{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 37s}

gitea-actions bot commented 2026-06-28 04:04:55 +00:00

Copy Link

Copy Source

🪰 Gadfly review — claude-code/opus:max (claude-code)

Verdict: Blocking issues found — 5 reviewers: security, correctness, maintainability, performance, error-handling

🔒 Security — Blocking issues found

The finding is fully confirmed against the actual file: line 44 replaces the immutable SHA pin with @v1, the forwarded secrets (lines 48–51), the issues: write / pull-requests: write permissions (lines 20–23), the deleted security comment, and the cross-repo trust boundary (steve/gadfly) all match the draft's claims.

VERDICT: Blocking issues found

• .gitea/workflows/adversarial-review.yml:44 — Mutable tag pin for a secret-bearing reusable workflow. The PR swaps an immutable commit pin (@b02b11d…) for a mutable release tag (@v1). The surrounding job (lines 44–54) forwards live credentials to gadfly — OLLAMA_CLOUD_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, GADFLY_FINDINGS_URL, GADFLY_FINDINGS_TOKEN — and runs with issues: write + pull-requests: write (lines 20–23) plus the automatic GITEA_TOKEN. A tag is a movable ref: anyone who can push/move v1 in steve/gadfly (a compromised maintainer account, a misconfigured tag-protection rule, or a malicious force-move) silently changes the exact code that executes with these forwarded secrets — no diff, no re-pin, no review on this side. This is the precise threat the deleted comment called out: "a push to gadfly can't silently change the code that runs with our forwarded secrets." The trust boundary is cross-repository (steve/gadfly is a separate repo), so this is third-party-action pinning, where SHA pinning is the established hardening control.

  Impact: full disclosure/abuse of the four review secrets and the write-scoped token, achievable by mutating a ref outside this repo's control.

  Suggested fix: keep the SHA pin (@<sha>) and accept periodic re-pinning as the cost of the security property — that bump is a one-line, reviewable PR. If automation is required, gate it behind a process that still lands a reviewable SHA change here (e.g. a bot PR that bumps the pinned SHA), rather than dereferencing a mutable tag at run time. At minimum the mitigation depends on v1 being a strictly protected, non-movable-except-forward tag in gadfly and on this repo trusting every future gadfly release unconditionally — neither is enforced by anything in this diff.

🎯 Correctness — No material issues found

VERDICT: No material issues found

This change swaps a single workflow ref (@<sha> → @v1) in .gitea/workflows/adversarial-review.yml:44. Through the correctness lens there is no logic, formula, constant, or unit to re-derive, and I verified the surrounding contract is internally consistent:

• The uses: path is well-formed (steve/gadfly/.gitea/workflows/review-reusable.yml@v1) and the secrets:/with: blocks passed to the reusable workflow are unchanged, so the call shape is unaffected by the ref swap.
• The actor gate (adversarial-review.yml:38-40, steve/fizi/dazed) and the allowed_users: "steve,fizi,dazed" input (:54) still match each other — the "both lists must stay in sync" invariant in the comment holds. Neither was touched by this diff.

One thing I could not verify (external repo, out of reach of these tools): whether review-reusable.yml@v1 declares the same required inputs/secrets as the old pinned SHA. If v1's contract drifted, this caller would break — but the PR description asserts v1 currently is the intended swarm, and unverifiable cross-repo drift is the practical cost of a moving tag.

Outside my lens: the security/supply-chain tradeoff of replacing an immutable SHA pin with a mutable v1 tag for a secret-forwarding workflow is real and deliberate per the PR description — flagging only so it's not mistaken for an oversight; it belongs to the security reviewer.

🧹 Code cleanliness & maintainability — No material issues found

VERDICT: No material issues found

Reviewed through the code cleanliness & maintainability lens. The change is a single uses: line edit plus the comment above it.

• .gitea/workflows/adversarial-review.yml:41-44 — The stale comment was correctly replaced, not left behind. The old text ("Pinned to an immutable gadfly commit (not @main)") would have been misleading after switching to @v1; the new comment accurately describes the tag-tracking behavior and its tradeoff. Verified by reading the full file — no leftover references to the old SHA, and grep across .gitea/ confirms b02b11d appears nowhere else, so there's no second pin to keep in sync.
• The rest of the file (actor gate, secret forwarding, allow-list) is untouched and the surrounding comment style/density is matched. No dead code, duplication, or naming issues introduced.

Note: the mutability/supply-chain implication of moving from a SHA pin to a movable v1 tag is a security-lens concern and is deliberately left to that reviewer.

(This was a read-only review task, so no plan file was needed — the diff is a clean one-line CI change.)

⚡ Performance — No material issues found

VERDICT: No material issues found

This change swaps the reusable-workflow ref from a pinned SHA (@b02b11d…) to a moving release tag (@v1) in .gitea/workflows/adversarial-review.yml. Through the ⚡ Performance lens there is nothing to flag:

• No code paths, queries, loops, allocations, or data structures are touched — it's a single CI workflow-reference string change plus a comment rewrite.
• It has no effect on runtime efficiency of the executus codebase; it only changes which version of an external CI reviewer workflow Gitea resolves at trigger time.

Nothing material in my lane.

Outside my lens: the security tradeoff the diff itself calls out — a mutable @v1 tag runs with forwarded secrets and can be re-pointed without a PR here, unlike the immutable SHA it replaces — is the substantive question this change raises, but that belongs to the security reviewer, not performance.

🧯 Error handling & edge cases — No material issues found

VERDICT: No material issues found

This change is a single-line CI workflow ref bump (@b02b11d… → @v1) in .gitea/workflows/adversarial-review.yml:44. Through the error-handling & edge-cases lens there is nothing to flag:

• No code paths, error returns, cleanup/defer, or input handling are introduced or altered — it's a YAML uses: pointer plus a comment rewrite.
• The actor gate (adversarial-review.yml:35-40), secret forwarding, and allowed_users allow-list are untouched, so no unhappy-path or boundary behavior changes. I confirmed this by reading the full file at the checked-out state.
• There are no collections, numeric bounds, nil/empty conditions, or swallowed errors anywhere in the diff.

Outside my lens: the comment itself notes the real tradeoff — @v1 is a mutable tag, so a re-pointed v1 could change the code running with forwarded secrets without a corresponding change here. That's a supply-chain/security consideration for the security lens, not error handling.

_{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 2s}

<!-- gadfly-review:ollama:claude-code/opus:max --> ### 🪰 Gadfly review — `claude-code/opus:max` (claude-code) **Verdict: Blocking issues found** — 5 reviewers: security, correctness, maintainability, performance, error-handling <details><summary><b>🔒 Security</b> — Blocking issues found</summary> The finding is fully confirmed against the actual file: line 44 replaces the immutable SHA pin with `@v1`, the forwarded secrets (lines 48–51), the `issues: write` / `pull-requests: write` permissions (lines 20–23), the deleted security comment, and the cross-repo trust boundary (`steve/gadfly`) all match the draft's claims. ## VERDICT: Blocking issues found - **`.gitea/workflows/adversarial-review.yml:44` — Mutable tag pin for a secret-bearing reusable workflow.** The PR swaps an immutable commit pin (`@b02b11d…`) for a mutable release tag (`@v1`). The surrounding job (lines 44–54) forwards live credentials to gadfly — `OLLAMA_CLOUD_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, `GADFLY_FINDINGS_URL`, `GADFLY_FINDINGS_TOKEN` — and runs with `issues: write` + `pull-requests: write` (lines 20–23) plus the automatic `GITEA_TOKEN`. A tag is a movable ref: anyone who can push/move `v1` in `steve/gadfly` (a compromised maintainer account, a misconfigured tag-protection rule, or a malicious force-move) silently changes the exact code that executes with these forwarded secrets — no diff, no re-pin, no review on this side. This is the precise threat the deleted comment called out: *"a push to gadfly can't silently change the code that runs with our forwarded secrets."* The trust boundary is **cross-repository** (`steve/gadfly` is a separate repo), so this is third-party-action pinning, where SHA pinning is the established hardening control. Impact: full disclosure/abuse of the four review secrets and the write-scoped token, achievable by mutating a ref outside this repo's control. Suggested fix: keep the SHA pin (`@<sha>`) and accept periodic re-pinning as the cost of the security property — that bump is a one-line, reviewable PR. If automation is required, gate it behind a process that still lands a reviewable SHA change here (e.g. a bot PR that bumps the pinned SHA), rather than dereferencing a mutable tag at run time. At minimum the mitigation depends on `v1` being a strictly protected, non-movable-except-forward tag in gadfly **and** on this repo trusting every future gadfly release unconditionally — neither is enforced by anything in this diff. </details> <details><summary><b>🎯 Correctness</b> — No material issues found</summary> ## VERDICT: No material issues found This change swaps a single workflow ref (`@<sha>` → `@v1`) in `.gitea/workflows/adversarial-review.yml:44`. Through the correctness lens there is no logic, formula, constant, or unit to re-derive, and I verified the surrounding contract is internally consistent: - The `uses:` path is well-formed (`steve/gadfly/.gitea/workflows/review-reusable.yml@v1`) and the `secrets:`/`with:` blocks passed to the reusable workflow are unchanged, so the call shape is unaffected by the ref swap. - The actor gate (`adversarial-review.yml:38-40`, `steve`/`fizi`/`dazed`) and the `allowed_users: "steve,fizi,dazed"` input (`:54`) still match each other — the "both lists must stay in sync" invariant in the comment holds. Neither was touched by this diff. One thing I could not verify (external repo, out of reach of these tools): whether `review-reusable.yml@v1` declares the same required `inputs`/`secrets` as the old pinned SHA. If v1's contract drifted, this caller would break — but the PR description asserts v1 currently *is* the intended swarm, and unverifiable cross-repo drift is the practical cost of a moving tag. Outside my lens: the security/supply-chain tradeoff of replacing an immutable SHA pin with a mutable `v1` tag for a secret-forwarding workflow is real and deliberate per the PR description — flagging only so it's not mistaken for an oversight; it belongs to the security reviewer. </details> <details><summary><b>🧹 Code cleanliness & maintainability</b> — No material issues found</summary> ## VERDICT: No material issues found Reviewed through the **code cleanliness & maintainability** lens. The change is a single `uses:` line edit plus the comment above it. - `.gitea/workflows/adversarial-review.yml:41-44` — The stale comment was correctly replaced, not left behind. The old text ("Pinned to an immutable gadfly commit (not @main)") would have been misleading after switching to `@v1`; the new comment accurately describes the tag-tracking behavior and its tradeoff. Verified by reading the full file — no leftover references to the old SHA, and `grep` across `.gitea/` confirms `b02b11d` appears nowhere else, so there's no second pin to keep in sync. - The rest of the file (actor gate, secret forwarding, allow-list) is untouched and the surrounding comment style/density is matched. No dead code, duplication, or naming issues introduced. Note: the mutability/supply-chain implication of moving from a SHA pin to a movable `v1` tag is a security-lens concern and is deliberately left to that reviewer. (This was a read-only review task, so no plan file was needed — the diff is a clean one-line CI change.) </details> <details><summary><b>⚡ Performance</b> — No material issues found</summary> **VERDICT: No material issues found** This change swaps the reusable-workflow ref from a pinned SHA (`@b02b11d…`) to a moving release tag (`@v1`) in `.gitea/workflows/adversarial-review.yml`. Through the ⚡ Performance lens there is nothing to flag: - No code paths, queries, loops, allocations, or data structures are touched — it's a single CI workflow-reference string change plus a comment rewrite. - It has no effect on runtime efficiency of the executus codebase; it only changes which version of an external CI reviewer workflow Gitea resolves at trigger time. Nothing material in my lane. *Outside my lens:* the security tradeoff the diff itself calls out — a mutable `@v1` tag runs with forwarded secrets and can be re-pointed without a PR here, unlike the immutable SHA it replaces — is the substantive question this change raises, but that belongs to the security reviewer, not performance. </details> <details><summary><b>🧯 Error handling & edge cases</b> — No material issues found</summary> VERDICT: No material issues found This change is a single-line CI workflow ref bump (`@b02b11d…` → `@v1`) in `.gitea/workflows/adversarial-review.yml:44`. Through the error-handling & edge-cases lens there is nothing to flag: - No code paths, error returns, cleanup/`defer`, or input handling are introduced or altered — it's a YAML `uses:` pointer plus a comment rewrite. - The actor gate (`adversarial-review.yml:35-40`), secret forwarding, and `allowed_users` allow-list are untouched, so no unhappy-path or boundary behavior changes. I confirmed this by reading the full file at the checked-out state. - There are no collections, numeric bounds, nil/empty conditions, or swallowed errors anywhere in the diff. Outside my lens: the comment itself notes the real tradeoff — `@v1` is a mutable tag, so a re-pointed `v1` could change the code running with forwarded secrets without a corresponding change here. That's a supply-chain/security consideration for the security lens, not error handling. </details> _{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 2s}

gitea-actions bot commented 2026-06-28 04:04:55 +00:00

Copy Link

Copy Source

🪰 Gadfly review — minimax-m3:cloud (ollama-cloud)

Verdict: Blocking issues found — 5 reviewers: security, correctness, maintainability, performance, error-handling

🔒 Security — Blocking issues found

VERDICT: Blocking issues found

• .gitea/workflows/adversarial-review.yml:44 — Mutable upstream tag re-introduces the exact supply-chain risk the previous pin existed to prevent. The old comment was explicit: "Pinned to an immutable gadfly commit (not @main): a push to gadfly can't silently change the code that runs with our forwarded secrets." This workflow forwards four high-value secrets (OLLAMA_CLOUD_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, GADFLY_FINDINGS_TOKEN, GADFLY_FINDINGS_URL) into the reusable workflow. Switching @b02b11d6... → @v1 means whoever can push the v1 tag in steve/gadfly can, on every "release," substitute the workflow code that executes with those secrets in scope. The new comment acknowledges "v1 is mutable" — it is not a defense, it is a confession of the regression. The convenience of central tuning does not outweigh the stated threat model. Suggested fix: keep a sha pin (even if you add a Dependabot/Renovate-style bump workflow that opens a PR when v1 moves), or pin to a signed tag and verify the signature in CI before use. If you genuinely want to track a moving pointer, the action must run inside a job with permissions: contents: read only, no token-bearing secrets:, or it must be run on a PR build with reduced secret scope and the real run triggered manually after the new SHA is reviewed.

🎯 Correctness — No material issues found

VERDICT: No material issues found

This change is a one-line swap of a uses: reference from a pinned sha to the @v1 release tag, with no other logic touched. Through the correctness lens:

• The if: actor gate, secrets: forwarding block, with: inputs, permissions:, concurrency:, and triggers (.gitea/workflows/adversarial-review.yml:9-54) are byte-identical to before, so no logic bug is introduced there.
• uses: accepts a tag reference syntactically; there is no in-repo formula, constant, conversion, unit, or threshold involved for me to re-derive.
• The semantic distinction stated in the new comment (curated, deliberately re-pointed tag vs. an immutable sha) is an accurate description of release-tag semantics, and the trade-off is openly called out by the author.

I have nothing within my correctness lens to flag. Whether the v1 tag exists and points where the PR claims is a registry question that can't be answered from this checked-out repo, and (importantly) whether mutating a tag that pulls in forwarded secrets is acceptable is a security/trust-boundary concern that belongs to a different lens, not this one.

🧹 Code cleanliness & maintainability — No material issues found

VERDICT: No material issues found

Checked .gitea/workflows/adversarial-review.yml end-to-end and grepped the whole .gitea/ tree for any other references to steve/gadfly or review-reusable — this is the sole consumer of the reusable workflow, so the swap is self-contained.

Through the cleanliness lens:

• Comment quality: The new comment block (lines 41-43) cleanly replaces the old "pinned to immutable sha" rationale and honestly states the v1 tradeoff (mutable, but curated vs @main's every-push movement). It matches the file's existing comment style (descriptive, multi-line, explains "why" not just "what").
• Header comment consistency: The top-of-file header (lines 1-5) still accurately describes the "central swarm tuning lives in gadfly" pattern; the change doesn't contradict it. The two comments overlap slightly but serve different scopes (architecture vs. pinning rationale), which is fine.
• No dead/duplicated code, no orphaned references: The old sha comment was removed cleanly with the pin it explained; no leftover stale text. No sibling workflows need updating — grep confirms this is the only call site.
• Structure/naming: Unchanged. Single uses: line in a small, focused file. No leaky abstractions introduced.

Nothing in the cleanliness lens rises above noise. Reporting "No material issues found" per the rules.

⚡ Performance — No material issues found

VERDICT: No material issues found

Through the ⚡ Performance lens, this change is neutral — it's a single-line swap from a SHA-pinned reference to a tag-pinned reference on a reusable workflow invocation. Nothing in the diff touches a hot path, a loop, an allocation, a query, or any concurrency/timeout setting.

Quick check of the surrounding context to be sure nothing else got perturbed:

• permissions, concurrency.group, cancel-in-progress: true (line 27), and the with/secrets forwarding are all unchanged at .gitea/workflows/adversarial-review.yml:20-54.
• Reference resolution cost: @v1 is dereferenced once at workflow dispatch; the per-run overhead vs @sha is negligible compared to the downstream swarm work (3 clouds × 3 models × 5 lenses) that this PR explicitly does not change.
• No new caching, scheduling, or matrix dimensions introduced.

Nothing performance-relevant to flag.

🧯 Error handling & edge cases — No material issues found

VERDICT: No material issues found

This diff is a one-line ref change (@b02b11d… → @v1) in a workflow's uses: clause plus a comment update. Through the error-handling lens:

• No new code paths, branches, or input handling are introduced.
• No new resources are opened that would need cleanup/defer/rollback.
• No new error or boundary conditions are created (no nil/empty/zero checks to add; no overflow surface to worry about; no integer or string parsing introduced).
• The surrounding context (lines 35–54) is unchanged: the if: actor gate, secrets: forwarding, and with: allowed_users are all pre-existing and untouched.

The mutability tradeoff of tracking @v1 (a moved tag could deliver a buggy reusable workflow to this consumer) is a supply-chain/trust concern, not an error-handling one — out of my lane. If a broken @v1 ever ships and the reusable workflow errors mid-run, Gitea Actions' default behavior on a called job is to fail the caller, so there's no silent error-swallowing introduced here either.

_{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 37s}

<!-- gadfly-review:ollama:minimax-m3:cloud --> ### 🪰 Gadfly review — `minimax-m3:cloud` (ollama-cloud) **Verdict: Blocking issues found** — 5 reviewers: security, correctness, maintainability, performance, error-handling <details><summary><b>🔒 Security</b> — Blocking issues found</summary> ## VERDICT: Blocking issues found - **`.gitea/workflows/adversarial-review.yml:44` — Mutable upstream tag re-introduces the exact supply-chain risk the previous pin existed to prevent.** The old comment was explicit: "Pinned to an immutable gadfly commit (not @main): a push to gadfly can't silently change the code that runs with our forwarded secrets." This workflow forwards four high-value secrets (`OLLAMA_CLOUD_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, `GADFLY_FINDINGS_TOKEN`, `GADFLY_FINDINGS_URL`) into the reusable workflow. Switching `@b02b11d6...` → `@v1` means whoever can push the `v1` tag in `steve/gadfly` can, on every "release," substitute the workflow code that executes with those secrets in scope. The new comment acknowledges "v1 is mutable" — it is not a defense, it is a confession of the regression. The convenience of central tuning does not outweigh the stated threat model. Suggested fix: keep a sha pin (even if you add a Dependabot/Renovate-style bump workflow that opens a PR when `v1` moves), or pin to a *signed* tag and verify the signature in CI before use. If you genuinely want to track a moving pointer, the action must run inside a job with `permissions: contents: read` only, no token-bearing `secrets:`, or it must be run on a PR build with reduced secret scope and the real run triggered manually after the new SHA is reviewed. </details> <details><summary><b>🎯 Correctness</b> — No material issues found</summary> VERDICT: No material issues found This change is a one-line swap of a `uses:` reference from a pinned sha to the `@v1` release tag, with no other logic touched. Through the correctness lens: - The `if:` actor gate, `secrets:` forwarding block, `with:` inputs, `permissions:`, `concurrency:`, and triggers (`.gitea/workflows/adversarial-review.yml:9-54`) are byte-identical to before, so no logic bug is introduced there. - `uses:` accepts a tag reference syntactically; there is no in-repo formula, constant, conversion, unit, or threshold involved for me to re-derive. - The semantic distinction stated in the new comment (curated, deliberately re-pointed tag vs. an immutable sha) is an accurate description of release-tag semantics, and the trade-off is openly called out by the author. I have nothing within my correctness lens to flag. Whether the `v1` tag exists and points where the PR claims is a registry question that can't be answered from this checked-out repo, and (importantly) whether mutating a tag that pulls in forwarded secrets is acceptable is a security/trust-boundary concern that belongs to a different lens, not this one. </details> <details><summary><b>🧹 Code cleanliness & maintainability</b> — No material issues found</summary> VERDICT: No material issues found Checked `.gitea/workflows/adversarial-review.yml` end-to-end and grepped the whole `.gitea/` tree for any other references to `steve/gadfly` or `review-reusable` — this is the sole consumer of the reusable workflow, so the swap is self-contained. Through the cleanliness lens: - **Comment quality:** The new comment block (lines 41-43) cleanly replaces the old "pinned to immutable sha" rationale and honestly states the `v1` tradeoff (mutable, but curated vs `@main`'s every-push movement). It matches the file's existing comment style (descriptive, multi-line, explains "why" not just "what"). - **Header comment consistency:** The top-of-file header (lines 1-5) still accurately describes the "central swarm tuning lives in gadfly" pattern; the change doesn't contradict it. The two comments overlap slightly but serve different scopes (architecture vs. pinning rationale), which is fine. - **No dead/duplicated code, no orphaned references:** The old sha comment was removed cleanly with the pin it explained; no leftover stale text. No sibling workflows need updating — `grep` confirms this is the only call site. - **Structure/naming:** Unchanged. Single `uses:` line in a small, focused file. No leaky abstractions introduced. Nothing in the cleanliness lens rises above noise. Reporting "No material issues found" per the rules. </details> <details><summary><b>⚡ Performance</b> — No material issues found</summary> **VERDICT: No material issues found** Through the ⚡ Performance lens, this change is neutral — it's a single-line swap from a SHA-pinned reference to a tag-pinned reference on a reusable workflow invocation. Nothing in the diff touches a hot path, a loop, an allocation, a query, or any concurrency/timeout setting. Quick check of the surrounding context to be sure nothing else got perturbed: - `permissions`, `concurrency.group`, `cancel-in-progress: true` (line 27), and the `with`/`secrets` forwarding are all unchanged at `.gitea/workflows/adversarial-review.yml:20-54`. - Reference resolution cost: `@v1` is dereferenced once at workflow dispatch; the per-run overhead vs `@sha` is negligible compared to the downstream swarm work (3 clouds × 3 models × 5 lenses) that this PR explicitly does not change. - No new caching, scheduling, or matrix dimensions introduced. Nothing performance-relevant to flag. </details> <details><summary><b>🧯 Error handling & edge cases</b> — No material issues found</summary> **VERDICT: No material issues found** This diff is a one-line ref change (`@b02b11d…` → `@v1`) in a workflow's `uses:` clause plus a comment update. Through the error-handling lens: - No new code paths, branches, or input handling are introduced. - No new resources are opened that would need cleanup/`defer`/rollback. - No new error or boundary conditions are created (no nil/empty/zero checks to add; no overflow surface to worry about; no integer or string parsing introduced). - The surrounding context (lines 35–54) is unchanged: the `if:` actor gate, `secrets:` forwarding, and `with: allowed_users` are all pre-existing and untouched. The mutability tradeoff of tracking `@v1` (a moved tag could deliver a buggy reusable workflow to this consumer) is a supply-chain/trust concern, not an error-handling one — out of my lane. If a broken `@v1` ever ships and the reusable workflow errors mid-run, Gitea Actions' default behavior on a called job is to fail the caller, so there's no silent error-swallowing introduced here either. </details> _{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 37s}

gitea-actions bot commented 2026-06-28 04:04:55 +00:00

Copy Link

Copy Source

🪰 Gadfly review — claude-code/opus (claude-code)

Verdict: Minor issues — 5 reviewers: security, correctness, maintainability, performance, error-handling

🔒 Security — Minor issues

The draft's finding checks out exactly against the actual file: line 44 uses the mutable @v1 ref, the four secrets are forwarded at lines 47–51, the actor gate is at lines 35–40, and the deleted SHA-pin comment is replaced by the new tracking comment. The finding is confirmed.

---

VERDICT: Minor issues

The diff does exactly one thing — swaps an immutable commit-SHA pin (@b02b11d…) for a mutable release tag (@v1) on a reusable workflow that runs with forwarded credentials. Through the security lens this is a deliberate but real supply-chain downgrade.

Finding — mutable ref on a secret-bearing reusable workflow (.gitea/workflows/adversarial-review.yml:44)

• Verified by reading the full file: the uses: target receives four real secrets — OLLAMA_CLOUD_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, GADFLY_FINDINGS_URL, GADFLY_FINDINGS_TOKEN (lines 47–51). The code behind @v1 therefore executes with an OAuth token and API keys in scope.
• The line this PR deletes stated the exact protection being removed: "Pinned to an immutable gadfly commit (not @main): a push to gadfly can't silently change the code that runs with our forwarded secrets." A SHA is content-addressed and cannot be re-pointed; @v1 is a movable pointer. Anyone who can move the v1 tag in steve/gadfly (a repo compromise, a stolen maintainer token, or a careless release) can change the code that runs here with these credentials — with no review or approval in this repo. The classic risk is a malicious release that exfiltrates the forwarded secrets.
• This runs against standard CI hardening guidance (pin third-party/reusable workflows to a full commit SHA precisely because tags are mutable). The actor gate (lines 35–40) and least-privilege secret forwarding (no secrets: inherit) are good and unchanged — but they gate who triggers the run, not what code runs with the secrets once triggered. This change widens only the latter.
• Mitigating context (why "Minor", not "Blocking"): steve/gadfly and this repo appear to share a single owner/trust domain, so the practical attacker is "whoever compromises gadfly," and the PR author explicitly accepts the tradeoff. But the security posture is still strictly weaker than before.
• Suggested fix: keep the SHA pin and bump it as part of each gadfly release (a one-line, reviewable change), rather than tracking a mutable tag. If the auto-propagation convenience is worth keeping, at minimum require that v1 be a signed/protected tag that cannot be force-moved, and document who holds that authority.

Unverified note: in some Gitea/git ref-resolution setups, @v1 can be ambiguous if a branch named v1 is later created, which could shadow the intended tag — another reason a SHA is safer. I could not confirm Gitea's resolution order from this repo, so treat this as a flag, not a confirmed defect.

No other security-relevant changes in this diff.

🎯 Correctness — No material issues found

VERDICT: No material issues found

I reviewed the single changed line (adversarial-review.yml:44) through the Correctness lens, reading the full file to confirm context.

• The change is a pure reference swap: …review-reusable.yml@b02b11d… → …@v1. No logic, formula, constant, unit, threshold, or behavioral code is touched. The secrets: and with: blocks (lines 47–54) and the actor gate (lines 35–40) are unchanged and still well-formed.
• YAML is syntactically valid; the uses: target path is unchanged, only the git ref changes. Nothing in this repo can verify that @v1 resolves correctly in the external steve/gadfly repo — that's outside this checkout and not a logic error in the diff.
• The updated comment (lines 41–43) accurately describes the behavior of the change (curated mutable tag vs. immutable sha). No misleading claim.

The mutability-vs-pinned-sha tradeoff (a moving tag can silently change the code that runs with forwarded secrets) is a real concern, but it is a supply-chain/security matter, not a correctness logic bug — so I leave it to that lens.

Nothing materially wrong in my area.

🧹 Code cleanliness & maintainability — No material issues found

VERDICT: No material issues found

Through the code-cleanliness & maintainability lens, this change is clean:

• The only substantive edit is @b02b11d… → @v1 on .gitea/workflows/adversarial-review.yml:44, with an updated 3-line comment (:41-43). I read the full file to confirm context.
• The replacement comment is accurate and self-consistent: it explains the curated-pointer semantics and honestly names the mutability tradeoff, matching the file's header comment (:1-5) that already states swarm config lives centrally in gadfly. No stale or contradictory comments left behind.
• No dead code, duplication, naming, or structure regressions are introduced.

One thing I checked and am deliberately not flagging: the actor list steve,fizi,dazed is duplicated between the if: gate (:38-40) and allowed_users (:54). It's pre-existing, untouched by this diff, and already documented with a rationale at :32-34 ("both lists must stay in sync; a workflow if: can't read a workflow_call input"). Not a finding for this PR.

Nothing in my lane to fix here.

⚡ Performance — No material issues found

VERDICT: No material issues found

This PR changes a single line in a Gitea Actions workflow — swapping the uses: reference for the reusable review workflow from a pinned SHA (@b02b11d…) to a mutable release tag (@v1). Through the Performance lens there is nothing to evaluate: no code paths, queries, loops, allocations, or runtime behavior in this repo are affected. The change only alters which revision of an external reusable workflow is resolved at CI dispatch time.

• The one conceivable performance angle — tag resolution adding indirection vs. a direct SHA — is negligible (a single ref lookup per CI run) and not a regression worth flagging.

The real tradeoff in this PR (immutable SHA pin vs. mutable v1 tag for supply-chain safety) is a security/correctness concern, not a performance one, so it belongs to another lens.

Nothing in my area.

🧯 Error handling & edge cases — No material issues found

VERDICT: No material issues found

This diff changes a single line: the reusable-workflow uses: ref from a pinned SHA (@b02b11d…) to a mutable tag (@v1), plus its explanatory comment. I verified the full file (.gitea/workflows/adversarial-review.yml:44) — the change is purely a workflow reference, introducing no new code paths, no error-handling logic, and no edge-case surface (nil/empty/zero/overflow/boundary). There is nothing in the error-handling & edge-cases lane to flag here.

• The only substantive concern in this change — that @v1 is mutable, so a re-pointed tag could run different code with forwarded secrets — is a supply-chain/security tradeoff, explicitly outside my lens and acknowledged by the PR's own comment. I'm noting it only to be clear I considered and deliberately deferred it to the security reviewer.

_{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 14s}

<!-- gadfly-review:ollama:claude-code/opus --> ### 🪰 Gadfly review — `claude-code/opus` (claude-code) **Verdict: Minor issues** — 5 reviewers: security, correctness, maintainability, performance, error-handling <details><summary><b>🔒 Security</b> — Minor issues</summary> The draft's finding checks out exactly against the actual file: line 44 uses the mutable `@v1` ref, the four secrets are forwarded at lines 47–51, the actor gate is at lines 35–40, and the deleted SHA-pin comment is replaced by the new tracking comment. The finding is confirmed. --- ## VERDICT: Minor issues The diff does exactly one thing — swaps an immutable commit-SHA pin (`@b02b11d…`) for a mutable release tag (`@v1`) on a reusable workflow that runs **with forwarded credentials**. Through the security lens this is a deliberate but real supply-chain downgrade. **Finding — mutable ref on a secret-bearing reusable workflow** (`.gitea/workflows/adversarial-review.yml:44`) - Verified by reading the full file: the `uses:` target receives four real secrets — `OLLAMA_CLOUD_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, `GADFLY_FINDINGS_URL`, `GADFLY_FINDINGS_TOKEN` (lines 47–51). The code behind `@v1` therefore executes with an OAuth token and API keys in scope. - The line this PR *deletes* stated the exact protection being removed: *"Pinned to an immutable gadfly commit (not @main): a push to gadfly can't silently change the code that runs with our forwarded secrets."* A SHA is content-addressed and cannot be re-pointed; `@v1` is a movable pointer. Anyone who can move the `v1` tag in `steve/gadfly` (a repo compromise, a stolen maintainer token, or a careless release) can change the code that runs here with these credentials — **with no review or approval in this repo**. The classic risk is a malicious release that exfiltrates the forwarded secrets. - This runs against standard CI hardening guidance (pin third-party/reusable workflows to a full commit SHA precisely because tags are mutable). The actor gate (lines 35–40) and least-privilege secret forwarding (no `secrets: inherit`) are good and unchanged — but they gate *who triggers* the run, not *what code* runs with the secrets once triggered. This change widens only the latter. - Mitigating context (why "Minor", not "Blocking"): `steve/gadfly` and this repo appear to share a single owner/trust domain, so the practical attacker is "whoever compromises gadfly," and the PR author explicitly accepts the tradeoff. But the security posture is still strictly weaker than before. - Suggested fix: keep the SHA pin and bump it as part of each gadfly release (a one-line, reviewable change), rather than tracking a mutable tag. If the auto-propagation convenience is worth keeping, at minimum require that `v1` be a signed/protected tag that cannot be force-moved, and document who holds that authority. **Unverified note:** in some Gitea/git ref-resolution setups, `@v1` can be ambiguous if a *branch* named `v1` is later created, which could shadow the intended tag — another reason a SHA is safer. I could not confirm Gitea's resolution order from this repo, so treat this as a flag, not a confirmed defect. No other security-relevant changes in this diff. </details> <details><summary><b>🎯 Correctness</b> — No material issues found</summary> **VERDICT: No material issues found** I reviewed the single changed line (`adversarial-review.yml:44`) through the Correctness lens, reading the full file to confirm context. - The change is a pure reference swap: `…review-reusable.yml@b02b11d…` → `…@v1`. No logic, formula, constant, unit, threshold, or behavioral code is touched. The `secrets:` and `with:` blocks (lines 47–54) and the actor gate (lines 35–40) are unchanged and still well-formed. - YAML is syntactically valid; the `uses:` target path is unchanged, only the git ref changes. Nothing in this repo can verify that `@v1` resolves correctly in the external `steve/gadfly` repo — that's outside this checkout and not a logic error in the diff. - The updated comment (lines 41–43) accurately describes the behavior of the change (curated mutable tag vs. immutable sha). No misleading claim. The mutability-vs-pinned-sha tradeoff (a moving tag can silently change the code that runs with forwarded secrets) is a real concern, but it is a **supply-chain/security** matter, not a correctness logic bug — so I leave it to that lens. Nothing materially wrong in my area. </details> <details><summary><b>🧹 Code cleanliness & maintainability</b> — No material issues found</summary> **VERDICT: No material issues found** Through the code-cleanliness & maintainability lens, this change is clean: - The only substantive edit is `@b02b11d…` → `@v1` on `.gitea/workflows/adversarial-review.yml:44`, with an updated 3-line comment (`:41-43`). I read the full file to confirm context. - The replacement comment is accurate and self-consistent: it explains the curated-pointer semantics and honestly names the mutability tradeoff, matching the file's header comment (`:1-5`) that already states swarm config lives centrally in gadfly. No stale or contradictory comments left behind. - No dead code, duplication, naming, or structure regressions are introduced. One thing I checked and am deliberately **not** flagging: the actor list `steve,fizi,dazed` is duplicated between the `if:` gate (`:38-40`) and `allowed_users` (`:54`). It's pre-existing, untouched by this diff, and already documented with a rationale at `:32-34` ("both lists must stay in sync; a workflow `if:` can't read a workflow_call input"). Not a finding for this PR. Nothing in my lane to fix here. </details> <details><summary><b>⚡ Performance</b> — No material issues found</summary> **VERDICT: No material issues found** This PR changes a single line in a Gitea Actions workflow — swapping the `uses:` reference for the reusable review workflow from a pinned SHA (`@b02b11d…`) to a mutable release tag (`@v1`). Through the **Performance** lens there is nothing to evaluate: no code paths, queries, loops, allocations, or runtime behavior in this repo are affected. The change only alters which revision of an *external* reusable workflow is resolved at CI dispatch time. - The one conceivable performance angle — tag resolution adding indirection vs. a direct SHA — is negligible (a single ref lookup per CI run) and not a regression worth flagging. The real tradeoff in this PR (immutable SHA pin vs. mutable `v1` tag for supply-chain safety) is a security/correctness concern, not a performance one, so it belongs to another lens. Nothing in my area. </details> <details><summary><b>🧯 Error handling & edge cases</b> — No material issues found</summary> **VERDICT: No material issues found** This diff changes a single line: the reusable-workflow `uses:` ref from a pinned SHA (`@b02b11d…`) to a mutable tag (`@v1`), plus its explanatory comment. I verified the full file (`.gitea/workflows/adversarial-review.yml:44`) — the change is purely a workflow reference, introducing no new code paths, no error-handling logic, and no edge-case surface (nil/empty/zero/overflow/boundary). There is nothing in the error-handling & edge-cases lane to flag here. - The only substantive concern in this change — that `@v1` is *mutable*, so a re-pointed tag could run different code with forwarded secrets — is a supply-chain/security tradeoff, explicitly outside my lens and acknowledged by the PR's own comment. I'm noting it only to be clear I considered and deliberately deferred it to the security reviewer. </details> _{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 14s}

gitea-actions bot commented 2026-06-28 04:04:55 +00:00

Copy Link

Copy Source

🪰 Gadfly review — glm-5.2:cloud (ollama-cloud)

Verdict: Blocking issues found — 5 reviewers: security, correctness, maintainability, performance, error-handling

🔒 Security — Blocking issues found

VERDICT: Blocking issues found

• .gitea/workflows/adversarial-review.yml:44 — Replacing an immutable SHA pin with a mutable moving tag (@v1) for a secret-bearing reusable workflow is a supply-chain / secret-exposure regression. This workflow forwards live credentials to the called workflow (OLLAMA_CLOUD_API_KEY:48, CLAUDE_CODE_OAUTH_TOKEN:49, GADFLY_FINDINGS_TOKEN:51). The removed comment explicitly documented the threat: "a push to gadfly can't silently change the code that runs with our forwarded secrets." With @v1, anyone who can move the v1 git ref in steve/gadfly (or compromise that ref) can cause arbitrary code to execute with this repo's forwarded secrets on the next review run, with no review in this repo. A SHA pin guarantees the code run with secrets is the code you audited; a moving tag does not. I confirmed there is no tag-protection rule, branch-protection config, or any other file under .gitea/ (only this single workflow exists) that constrains who can move v1. The trusted-actor gate (35–40) and least-privilege secret forwarding (no secrets: inherit) are preserved and do not mitigate this — they bound who triggers the run, not what code runs once triggered. The PR comment acknowledging v1 is mutable states the problem, not a mitigation. Suggested fix: keep an immutable SHA pin (or use a tag-protection rule on steve/gadfly requiring signed/admin-only releases and document it here); if auto-propagation of swarm tuning is required, at minimum pin the resolved SHA of each v1 release and bump it deliberately.

No other security-relevant changes in this diff: the least-privilege secret forwarding (no secrets: inherit) and the trusted-actor gate are preserved.

🎯 Correctness — No material issues found

VERDICT: No material issues found

• The change is a single ref swap (@b02b11d… → @v1) on a reusable workflow uses: line. The YAML syntax is unchanged and valid; the referenced workflow path (steve/gadfly/.gitea/workflows/review-reusable.yml) is unmodified. The surrounding secrets:/with: blocks, actor gate, and concurrency group are untouched, so no behavioral logic in this repo changes.
• The updated comment accurately describes the semantic tradeoff (mutable v1 tag vs immutable SHA). Verified by reading the full file at .gitea/workflows/adversarial-review.yml:41-44.
• Whether v1 points to a valid published workflow tag in the upstream steve/gadfly repo is an external concern not verifiable from this checked-out code, and is not a logic/correctness bug in this repository.

🧹 Code cleanliness & maintainability — Minor issues

VERDICT: Minor issues

• .gitea/workflows/adversarial-review.yml:41 — the hyphenated word "re-moved" in the new comment ("a curated pointer re-moved on each release") is awkward and risks being misread as "removed" (taken away). The intended meaning is "moved again." Consider "moved" or "re-pointed" for clarity. Confirmed against the actual file content.

⚡ Performance — No material issues found

VERDICT: No material issues found

This is a one-line CI workflow reference change (@<sha> → @v1). There is no application code, no query/allocation/hot-path behavior, and no runtime performance surface to evaluate. The change affects only which revision of an external reusable workflow is fetched, which is outside the performance lens.

🧯 Error handling & edge cases — No material issues found

No material issues found

• The diff is a one-line ref change (@b02b11d… → @v1) in a reusable-workflow invocation, plus comment text. No new error-handling logic, cleanup paths, or input handling is introduced by this change.
• The only edge case relevant to error handling is run-resolution failure if the v1 tag were missing/deleted. But (a) this is the explicitly-acknowledged tradeoff of a moving tag, and (b) failure to resolve a reusable-workflow ref surfaces as a hard workflow error, not a silently-swallowed problem — so nothing is masked.
• The surrounding file (.gitea/workflows/adversarial-review.yml, read in full) has no nil/empty/boundary handling introduced by this hunk; the if: actor gate, concurrency group, and secret forwarding are all pre-existing and untouched.

Nothing in the error-handling/edge-case lens is materially wrong with this change.

_{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 53s}

<!-- gadfly-review:ollama:glm-5.2:cloud --> ### 🪰 Gadfly review — `glm-5.2:cloud` (ollama-cloud) **Verdict: Blocking issues found** — 5 reviewers: security, correctness, maintainability, performance, error-handling <details><summary><b>🔒 Security</b> — Blocking issues found</summary> VERDICT: Blocking issues found - **`.gitea/workflows/adversarial-review.yml:44` — Replacing an immutable SHA pin with a mutable moving tag (`@v1`) for a secret-bearing reusable workflow is a supply-chain / secret-exposure regression.** This workflow forwards live credentials to the called workflow (`OLLAMA_CLOUD_API_KEY:48`, `CLAUDE_CODE_OAUTH_TOKEN:49`, `GADFLY_FINDINGS_TOKEN:51`). The removed comment explicitly documented the threat: "a push to gadfly can't silently change the code that runs with our forwarded secrets." With `@v1`, anyone who can move the `v1` git ref in `steve/gadfly` (or compromise that ref) can cause arbitrary code to execute with this repo's forwarded secrets on the next review run, with no review in *this* repo. A SHA pin guarantees the code run with secrets is the code you audited; a moving tag does not. I confirmed there is no tag-protection rule, branch-protection config, or any other file under `.gitea/` (only this single workflow exists) that constrains who can move `v1`. The trusted-actor gate (`35–40`) and least-privilege secret forwarding (no `secrets: inherit`) are preserved and do not mitigate this — they bound *who triggers* the run, not *what code runs* once triggered. The PR comment acknowledging `v1` is mutable states the problem, not a mitigation. Suggested fix: keep an immutable SHA pin (or use a tag-protection rule on `steve/gadfly` requiring signed/admin-only releases and document it here); if auto-propagation of swarm tuning is required, at minimum pin the resolved SHA of each `v1` release and bump it deliberately. No other security-relevant changes in this diff: the least-privilege secret forwarding (no `secrets: inherit`) and the trusted-actor gate are preserved. </details> <details><summary><b>🎯 Correctness</b> — No material issues found</summary> VERDICT: No material issues found - The change is a single ref swap (`@b02b11d…` → `@v1`) on a reusable workflow `uses:` line. The YAML syntax is unchanged and valid; the referenced workflow path (`steve/gadfly/.gitea/workflows/review-reusable.yml`) is unmodified. The surrounding `secrets:`/`with:` blocks, actor gate, and concurrency group are untouched, so no behavioral logic in this repo changes. - The updated comment accurately describes the semantic tradeoff (mutable `v1` tag vs immutable SHA). Verified by reading the full file at `.gitea/workflows/adversarial-review.yml:41-44`. - Whether `v1` points to a valid published workflow tag in the upstream `steve/gadfly` repo is an external concern not verifiable from this checked-out code, and is not a logic/correctness bug in this repository. </details> <details><summary><b>🧹 Code cleanliness & maintainability</b> — Minor issues</summary> VERDICT: Minor issues - `.gitea/workflows/adversarial-review.yml:41` — the hyphenated word "re-moved" in the new comment ("a curated pointer re-moved on each release") is awkward and risks being misread as "removed" (taken away). The intended meaning is "moved again." Consider "moved" or "re-pointed" for clarity. Confirmed against the actual file content. </details> <details><summary><b>⚡ Performance</b> — No material issues found</summary> VERDICT: No material issues found This is a one-line CI workflow reference change (`@<sha>` → `@v1`). There is no application code, no query/allocation/hot-path behavior, and no runtime performance surface to evaluate. The change affects only which revision of an external reusable workflow is fetched, which is outside the performance lens. </details> <details><summary><b>🧯 Error handling & edge cases</b> — No material issues found</summary> No material issues found - The diff is a one-line ref change (`@b02b11d…` → `@v1`) in a reusable-workflow invocation, plus comment text. No new error-handling logic, cleanup paths, or input handling is introduced by this change. - The only edge case relevant to error handling is run-resolution failure if the `v1` tag were missing/deleted. But (a) this is the explicitly-acknowledged tradeoff of a moving tag, and (b) failure to resolve a reusable-workflow ref surfaces as a hard workflow error, not a silently-swallowed problem — so nothing is masked. - The surrounding file (`.gitea/workflows/adversarial-review.yml`, read in full) has no nil/empty/boundary handling introduced by this hunk; the `if:` actor gate, concurrency group, and secret forwarding are all pre-existing and untouched. Nothing in the error-handling/edge-case lens is materially wrong with this change. </details> _{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 53s}

gitea-actions bot commented 2026-06-28 04:04:55 +00:00

Copy Link

Copy Source

🪰 Gadfly review — deepseek-v4-pro:cloud (ollama-cloud)

Verdict: Minor issues — 5 reviewers: security, correctness, maintainability, performance, error-handling

🔒 Security — Minor issues

Verdict: Minor issues

• Supply-chain regression: mutable @v1 tag vs. immutable SHA pin (adversarial-review.yml:44). The previous uses: reference (@b02b11d…) was an immutable commit SHA — the code that runs with the forwarded secrets could not change without a commit to this repo. The new @v1 tag is mutable: anyone with write access to steve/gadfly (or an attacker who compromises that repo) can re-point v1 to a malicious commit, and the next workflow run will execute attacker-controlled code holding OLLAMA_CLOUD_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, GADFLY_FINDINGS_URL, and GADFLY_FINDINGS_TOKEN. The if: actor gate on lines 35–40 only restricts who can trigger the run, not what code runs. Given that both repos share the same owner and the workflow is advisory-only, this is a conscious risk acceptance — but it remains a real security downgrade worth flagging.

🎯 Correctness — No material issues found

Verdict: No material issues found

The change is a straightforward substitution of a pinned commit SHA for a moving tag (v1) in a uses: reference. After reading the full workflow file, I find no logic errors, semantic mistakes, or domain-level correctness problems introduced by this change.

• The @v1 syntax is valid for Gitea Actions reusable workflow references.
• The tag resolves to the same workflow path (.gitea/workflows/review-reusable.yml) in the same repository (steve/gadfly).
• No other part of the workflow depends on the specific SHA value — the secrets and with blocks are unchanged and remain compatible.
• The comment accurately describes the tradeoff (mutable tag vs. immutable SHA), which is a deliberate operational choice, not a correctness defect.

The typo "re-moved" in the comment (should be "re-pointed" or "moved") is cosmetic and does not affect correctness.

🧹 Code cleanliness & maintainability — Minor issues

Verdict: Minor issues

• .gitea/workflows/adversarial-review.yml:41 — confusing hyphenation in comment: The word "re-moved" in the comment # Tracks gadfly's v1 release tag — a curated pointer re-moved on each release reads like a typo for "removed" (i.e., deleted), which is the opposite of the intended meaning (the tag is moved to a new commit on each release). Consider rewording to something unambiguous like re-pointed or advanced:

  # Tracks gadfly's v1 release tag — a curated pointer re-pointed on each release
  

⚡ Performance — No material issues found

Verdict: No material issues found

This change is a one-line reference swap in a Gitea Actions workflow file — from a pinned SHA to a @v1 tag. From a performance lens:

• No runtime impact on the application. This is a CI configuration file; it doesn't affect the code that ships or runs in production.
• No meaningful CI execution overhead. The tag-to-commit resolution happens once at workflow dispatch, not in any hot loop. The difference between resolving @b02b11d... and @v1 is a single git ref lookup — negligible.
• The actual review workload (model inference, concurrency, etc.) is entirely determined by the reusable workflow in the gadfly repository, not by how it's referenced. The PR description explicitly states this is about allowing central swarm tuning to propagate automatically — a design choice, not a performance regression.
• Concurrency group and cancellation remain unchanged (line 25-27), so there's no new risk of resource contention or duplicate runs.

No performance issues to flag.

🧯 Error handling & edge cases — Minor issues

Verdict: Minor issues

• Mutable @v1 tag forwards secrets with no failure detection (.gitea/workflows/adversarial-review.yml:44): The switch from a pinned SHA to the mutable @v1 tag means the reusable workflow — and the code that receives OLLAMA_CLOUD_API_KEY, CLAUDE_CODE_OAUTH_TOKEN, GADFLY_FINDINGS_URL, and GADFLY_FINDINGS_TOKEN — can change silently on any re-point of the tag. If the tag is moved to a broken or malicious commit, the job will either fail (no alerting) or, worse, succeed while running unintended code with live secrets. The PR description acknowledges the mutability tradeoff, but there is no compensating safeguard: no continue-on-error, no fallback SHA, no separate integrity check on the resolved workflow. Since the workflow is advisory-only (never blocks merge), a silent failure could go unnoticed indefinitely. Consider adding a separate periodic integrity job (e.g., a scheduled workflow that verifies the resolved v1 commit against a known-good hash) or at minimum a comment noting that tag repoints require manual verification of this consumer.

_{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 44s}

<!-- gadfly-review:ollama:deepseek-v4-pro:cloud --> ### 🪰 Gadfly review — `deepseek-v4-pro:cloud` (ollama-cloud) **Verdict: Minor issues** — 5 reviewers: security, correctness, maintainability, performance, error-handling <details><summary><b>🔒 Security</b> — Minor issues</summary> ## Verdict: Minor issues - **Supply-chain regression: mutable `@v1` tag vs. immutable SHA pin** (`adversarial-review.yml:44`). The previous `uses:` reference (`@b02b11d…`) was an immutable commit SHA — the code that runs with the forwarded secrets could not change without a commit to *this* repo. The new `@v1` tag is mutable: anyone with write access to `steve/gadfly` (or an attacker who compromises that repo) can re-point `v1` to a malicious commit, and the next workflow run will execute attacker-controlled code holding `OLLAMA_CLOUD_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, `GADFLY_FINDINGS_URL`, and `GADFLY_FINDINGS_TOKEN`. The `if:` actor gate on lines 35–40 only restricts *who can trigger* the run, not *what code runs*. Given that both repos share the same owner and the workflow is advisory-only, this is a conscious risk acceptance — but it remains a real security downgrade worth flagging. </details> <details><summary><b>🎯 Correctness</b> — No material issues found</summary> ## Verdict: No material issues found The change is a straightforward substitution of a pinned commit SHA for a moving tag (`v1`) in a `uses:` reference. After reading the full workflow file, I find no logic errors, semantic mistakes, or domain-level correctness problems introduced by this change. - The `@v1` syntax is valid for Gitea Actions reusable workflow references. - The tag resolves to the same workflow path (`.gitea/workflows/review-reusable.yml`) in the same repository (`steve/gadfly`). - No other part of the workflow depends on the specific SHA value — the `secrets` and `with` blocks are unchanged and remain compatible. - The comment accurately describes the tradeoff (mutable tag vs. immutable SHA), which is a deliberate operational choice, not a correctness defect. The typo "re-moved" in the comment (should be "re-pointed" or "moved") is cosmetic and does not affect correctness. </details> <details><summary><b>🧹 Code cleanliness & maintainability</b> — Minor issues</summary> ## Verdict: Minor issues - **`.gitea/workflows/adversarial-review.yml:41` — confusing hyphenation in comment**: The word "re-moved" in the comment `# Tracks gadfly's v1 release tag — a curated pointer re-moved on each release` reads like a typo for "removed" (i.e., deleted), which is the opposite of the intended meaning (the tag is *moved* to a new commit on each release). Consider rewording to something unambiguous like `re-pointed` or `advanced`: ```yaml # Tracks gadfly's v1 release tag — a curated pointer re-pointed on each release ``` </details> <details><summary><b>⚡ Performance</b> — No material issues found</summary> ## Verdict: No material issues found This change is a one-line reference swap in a Gitea Actions workflow file — from a pinned SHA to a `@v1` tag. From a **performance** lens: - **No runtime impact on the application.** This is a CI configuration file; it doesn't affect the code that ships or runs in production. - **No meaningful CI execution overhead.** The tag-to-commit resolution happens once at workflow dispatch, not in any hot loop. The difference between resolving `@b02b11d...` and `@v1` is a single git ref lookup — negligible. - **The actual review workload** (model inference, concurrency, etc.) is entirely determined by the reusable workflow in the gadfly repository, not by how it's referenced. The PR description explicitly states this is about allowing central swarm tuning to propagate automatically — a design choice, not a performance regression. - **Concurrency group and cancellation** remain unchanged (line 25-27), so there's no new risk of resource contention or duplicate runs. No performance issues to flag. </details> <details><summary><b>🧯 Error handling & edge cases</b> — Minor issues</summary> ## Verdict: Minor issues - **Mutable `@v1` tag forwards secrets with no failure detection** (`.gitea/workflows/adversarial-review.yml:44`): The switch from a pinned SHA to the mutable `@v1` tag means the reusable workflow — and the code that receives `OLLAMA_CLOUD_API_KEY`, `CLAUDE_CODE_OAUTH_TOKEN`, `GADFLY_FINDINGS_URL`, and `GADFLY_FINDINGS_TOKEN` — can change silently on any re-point of the tag. If the tag is moved to a broken or malicious commit, the job will either fail (no alerting) or, worse, succeed while running unintended code with live secrets. The PR description acknowledges the mutability tradeoff, but there is no compensating safeguard: no `continue-on-error`, no fallback SHA, no separate integrity check on the resolved workflow. Since the workflow is advisory-only (never blocks merge), a silent failure could go unnoticed indefinitely. Consider adding a separate periodic integrity job (e.g., a scheduled workflow that verifies the resolved `v1` commit against a known-good hash) or at minimum a comment noting that tag repoints require manual verification of this consumer. </details> _{Automated adversarial review by Gadfly. Advisory only — does not block merge. · ⏱️ reviewed in 1m 44s}

steve merged commit 1cf46c9954 into main 2026-06-28 04:08:31 +00:00

steve deleted branch ci/gadfly-v1 2026-06-28 04:08:31 +00:00

steve referenced this pull request 2026-06-28 17:03:13 +00:00

feat(run): InputFileStager seam — stage non-image attachments into the prompt #18

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

steve

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: steve/executus#15