refactor(scaffold)!: delete agent files from scaffold embed - #5588
Conversation
|
🤖 Finished Review · ✅ Success · Started 1:15 AM UTC · Completed 1:35 AM UTC |
PR Summary by QodoRemove embedded agent assets from scaffold; resolve from fullsend-ai/agents at runtime
AI Description
Diagram
High-Level Assessment
Files changed (15)
|
Site previewPreview: https://862fe0fc-site.fullsend-ai.workers.dev Commit: |
Code Review by Qodo
1.
|
ReviewFindingsMedium
Low
Previous runReviewFindingsMedium
Low
Previous run (2)ReviewFindingsMedium
Low
Previous run (3)ReviewFindingsMedium
Low
Previous run (4)ReviewFindingsHigh
Medium
Low
Previous run (5)ReviewFindingsMedium
Low
Previous run (6)ReviewFindingsMedium
Low
Previous run (7)ReviewFindingsMedium
Low
Previous run (8)ReviewFindingsMedium
Low
Previous run (9)ReviewFindingsMedium
Low
Previous run (10)ReviewFindingsMedium
Low
Previous run (11)ReviewFindingsHigh
Medium
Low
Labels: PR removes harness/agent files from scaffold embed and updates installation infrastructure |
a1c3c45 to
99bd1e7
Compare
|
🤖 Review · ❌ Terminated · Started 2:02 AM UTC · Ended 2:22 AM UTC |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Superseded by updated review
|
🤖 Finished Review · ✅ Success · Started 2:02 AM UTC · Completed 2:22 AM UTC |
99bd1e7 to
3e2a7af
Compare
|
🤖 Review · |
3e2a7af to
ce7595e
Compare
|
🤖 Finished Review · ✅ Success · Started 2:35 AM UTC · Completed 2:55 AM UTC |
ce7595e to
04402bf
Compare
|
🤖 Finished Review · ✅ Success · Started 3:01 AM UTC · Completed 3:22 AM UTC |
|
🤖 Finished Retro · ✅ Success · Started 3:43 PM UTC · Completed 3:59 PM UTC |
Retro: PR #5588 —
|
…ock config-aware Remove HarnessNames(), HarnessContentHash(), and HarnessBaseURLWithHash() from internal/scaffold/baseurl.go — these functions have no production callers after PR fullsend-ai#5588 removed the migrateModified code path. Their corresponding tests are also removed. Update fullsend lock to resolve agents from config when no local harness file exists. The new resolveHarnessForLock function tries the local harness directory first, then falls back to config-driven resolution via harness.ResolveRegisteredPath. This supports both local-path and URL-sourced agent entries. The --all flag now also discovers agents registered in config.yaml, not just local harness files. Closes fullsend-ai#5668
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
pull_request_target.synchronize fires when the fix agent pushes, but its actor-identity authorization check is gated on the PR's original author, which for agent-authored PRs is the code agent's bot account regardless of who triggered this fix run. GitHub App bots have no collaborator role, so that check always fails closed and review is never re-dispatched after a fix-agent push (fullsend-ai/fullsend#5188). post-fix.src.sh now calls a new shared library, relabel-retrigger.lib.sh, which removes then re-adds the ready-for-review label after a successful push, forcing a fresh labeled webhook event. That path has no actor-authorization gate at all — label application itself already requires write access, so it needs no separate identity check — mirroring post-code.src.sh's existing handling of the PR-open case. GitHub does not fire a new labeled event when a label already present is simply re-added, hence the remove-then-add sequence. Verified live on a disposable PR in a personal fork: remove-then-add fires a second, genuinely distinct pull_request.labeled run; a plain re-add of an already-present label does not. Extracted as a library (retrigger_via_label) rather than inline script logic, per review feedback that this kind of dispatch-retrigger functionality should be reusable across agent post-scripts, not duplicated per-agent. The GitHub token is taken as an explicit argument and scoped to each gh invocation individually (GH_TOKEN="${token}" gh ...) rather than relying on the caller having exported GH_TOKEN into the shell environment at the right point in script execution — the library's parameter-passing design makes that class of ordering bug structurally impossible. retrigger_via_label checks whether the label was actually present before attempting removal, so a genuine --remove-label failure (while the label was present) escalates to a warning instead of being masked by the idempotent --add-label call silently no-op'ing as if the retrigger had succeeded. Added a bundled-script-has-relabel-retrigger presence check and a real NO_PUSH=false integration test (a genuine feature-branch commit pushed against a local bare repo standing in for GitHub) to post-fix-test.sh, so a transposed argument, wrong token, flipped NO_PUSH guard, or a deleted call site would fail CI instead of passing silently. This fix was originally attempted in fullsend-ai/fullsend#5551 against internal/scaffold/fullsend-repo/scripts/post-fix.sh, but that copy is being deleted from that repo (fullsend-ai/fullsend#5588) since agent scripts are now served from this repo via resolveAgentSource() — this repo's post-fix.sh is the actual production script, and it still had the original bug, unaffected by anything in #5551. Signed-off-by: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Greg Allen <gallen@redhat.com>
givenCustomHarness and givenDisabledCustomHarness commit the harness YAML and register it in config.yaml but never create the agent (or policy) MD file referenced by the harness's agent: field. After scaffold agent files were removed (#5552 / #5588), clean pool repos fail at harness validation with "no such file or directory" for .fullsend/agents/triage.md. Add commitLocalHarnessResources that parses the harness YAML for relative agent and policy paths and commits minimal stub files under .fullsend/ on the config repo. This mirrors commitRelativeResources in url_dispatch.go (used by URL-sourced harnesses) but writes to the config repo with the .fullsend/ prefix. Closes #5715 Signed-off-by: Barak Korren <bkorren@redhat.com>
givenCustomHarness and givenDisabledCustomHarness commit the harness YAML and register it in config.yaml but never create the agent (or policy) MD file referenced by the harness's agent: field. After scaffold agent files were removed (#5552 / #5588), clean pool repos fail at harness validation with "no such file or directory" for .fullsend/agents/triage.md. Add commitLocalHarnessResources that parses the harness YAML for relative agent and policy paths and commits minimal stub files under .fullsend/ on the config repo. This mirrors commitRelativeResources in url_dispatch.go (used by URL-sourced harnesses) but writes to the config repo with the .fullsend/ prefix. Closes #5715 Signed-off-by: Barak Korren <bkorren@redhat.com>
Summary
fullsend-ai/agentsat runtime viaresolveAgentSource()pre-code.sh+ test,pre-fix.sh— also duplicated infullsend-ai/agentswhere they run via harnesspre_script:inside the sandbox (two independent invocation paths per agent run)pre-fetch-prior-review.sh+ test — workflow-only, no counterpart infullsend-ai/agentssetup-prioritize.sh— one-time setup script referenced by an error message in the scaffoldedprioritize-scheduler.ymltemplatemigrateModifiedcode path frommigrate-customizationscommand (depended on deleted harness files)hack/lint-agent-docslinter (validated harnessdoc:fields that no longer exist)executableFilesmap, tests, Makefilescript-testtarget,.pre-commit-config.yaml, agent docs, and broken symlinksHarnessNames()return an empty list instead of erroring when the harness directory is absent (deferred removal per Step 7: Remove scaffold agent fallback infrastructure #5552 Item 5 — the removal precondition is now met by this PR'smigrate.gochanges, but kept as a deliberate scope choice for this already-large PR)Note:
fullsend lockhas its own independentresolveHarnessPathinlock.go— updating it to be config/agents-repo-aware is tracked separately (see follow-up issues below).Addresses #5552
Follow-up work
pre-code.sh/pre-fix.shcross-repo drift: this repo's copies andfullsend-ai/agents's copies have already diverged — add cross-reference comments and establish a sync protocolfullsend lockconfig/agents-repo-awareness (former Step 7: Remove scaffold agent fallback infrastructure #5552 Item 6 — issue was closed before this work landed)HarnessNames()/HarnessBaseURLWithHash()dead code (former Step 7: Remove scaffold agent fallback infrastructure #5552 Item 5 — precondition now met)Test plan
go build ./...passesgo test ./internal/scaffold/... ./internal/cli/ ./internal/layers/— all tests passTestFileModeMatchesFilesystemverifiesexecutableFilesmatches disk🤖 Generated with Claude Code