Repository navigation
Trust repo-memory ledgers in the daily AIC guardrail - #65879
Conversation
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Clone failures can produce an empty directory that is incorrectly marked trusted, allowing the guardrail to fail open.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Allows daily AIC guardrails to trust repo-memory ledgers cloned during activation while retaining the insecure opt-in fallback.
Changes:
- Adds compiler-generated ledger trust provenance.
- Updates guardrail trust handling.
- Adds regression and workflow-generation coverage.
| File | Description |
|---|---|
pkg/workflow/compiler_activation_daily_aic.go |
Emits the trust signal. |
pkg/workflow/daily_aic_workflow_guardrail_test.go |
Verifies trust signal and step ordering. |
actions/setup/js/check_daily_aic_workflow_guardrail.cjs |
Accepts trusted ledgers. |
actions/setup/js/check_daily_aic_workflow_guardrail.test.cjs |
Tests writer-produced trusted ledgers. |
.github/workflows/daily-community-attribution.lock.yml |
Regenerates workflow with trust signal. |
.github/workflows/daily-code-metrics.lock.yml |
Regenerates workflow with trust signal. |
.github/workflows/daily-cli-performance.lock.yml |
Regenerates workflow with trust signal. |
| } | ||
| if data.MaxDailyAICBackend == maxDailyAICBackendRepoMemory { | ||
| steps = append(steps, " GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC: ${{ vars.GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC || 'false' }}\n") | ||
| steps = append(steps, " GH_AW_DAILY_AIC_REPO_MEMORY_TRUSTED: \"true\"\n GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC: ${{ vars.GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC || 'false' }}\n") |
There was a problem hiding this comment.
Fixed in f48f8b3: the clone step verifies branch existence with authenticated git ls-remote; only a confirmed missing branch falls back to an orphan, while transport, authentication, and clone failures exit nonzero. The guardrail trusts only a reported successful clone.
|
✅ PR Code Quality Reviewer completed the code quality review.
|
|
✅ Ponytail Reviewer completed successfully! Lean already. Ship.
|
|
🔍 Design Decision Gate 🏗️ is checking for design decision records on this pull request... |
|
✅ Test Quality Sentinel completed test quality analysis. Test Quality Sentinel skipped because pre-fetch PR data was unavailable: unable to fetch test file diff
|
|
🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅
|
Comment MemoryPeek at saved memory (pr-code-quality-reviewer)Note This comment is managed by comment memory.Expand the saved memory block to view or edit the persistent context for this thread.
|
There was a problem hiding this comment.
Request changes
The repo-memory trust bit is still disconnected from actual clone success, so a token/network/server failure can leave an empty or orphan ledger while the guardrail accepts it as trusted and undercounts prior runs.
Why this is still blocking
buildActivationDailyAICGuardrailStep sets GH_AW_DAILY_AIC_REPO_MEMORY_TRUSTED: "true" for every repo-memory workflow up front, but clone_repo_memory_branch.sh intentionally treats any git clone failure as recoverable and falls back to creating an orphan repo or empty directory. That means check_daily_aic_workflow_guardrail.cjs cannot distinguish verified branch clone success from local empty-state fallback, so the workflow can proceed under budget even when the historical ledger was never authenticated.
I am not adding another inline comment because there is already an open thread on the exact changed line, but that issue remains merge-blocking until trust is derived from a positive clone-success signal instead of compile-time configuration.
🔎 Code quality review by PR Code Quality Reviewer · copilot · gpt54 · 40.7 AIC · ⌖ 5.28 AIC · ⊞ 19.6K
Comment /review to run again
There was a problem hiding this comment.
Skills-Based Review 🧠
Applied /diagnosing-bugs — requesting changes on an unguarded trust signal.
📋 Key Themes & Highlights
Key Themes
- Root cause only partially addressed: the PR's goal is "trust the ledger only after a verified clone," but the generated
GH_AW_DAILY_AIC_REPO_MEMORY_TRUSTED: "true"is unconditional — it does not actually check that the clone step succeeded with real data vs. silently falling back to an orphan branch on any clone failure (network, token, server errors). This is the same concern already raised by the existing automated review comment onpkg/workflow/compiler_activation_daily_aic.go:144; my inline comment extends it with a concrete implementation path (step output +if:gate, following the existing pattern incache_memory.go:274). - Regression test asymmetry: the new JS test (
check_daily_aic_workflow_guardrail.test.cjs) and Go test (daily_aic_workflow_guardrail_test.go) both verify the happy path (trusted ledger accepted, clone precedes guardrail) but neither exercises the failure path (clone fails → ledger should remain untrusted). Given this PR's entire purpose is correcting trust semantics, a negative test is the most valuable missing coverage.
Positive Highlights
- ✅ Compile-time coupling is solid:
maxDailyAICBackendRepoMemoryalways requirestools.repo-memory(daily_aic_workflow.go:284), so the clone step and the trust env var can never be emitted independently of each other. - ✅ Step ordering is correctly verified by the new Go test (clone step index precedes guardrail check index in the generated lock file).
- ✅ The opt-in
GH_AW_ALLOW_INSECURE_REPO_MEMORY_AICfallback is preserved for operators who need it, keeping the fail-closed default intact for untrusted paths.
@copilot please address the review comments above.
🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · copilot · sonnet50 · 86.6 AIC · ⌖ 13.6 AIC · ⊞ 10.1K
Comment /matt to run again
| } | ||
| if data.MaxDailyAICBackend == maxDailyAICBackendRepoMemory { | ||
| steps = append(steps, " GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC: ${{ vars.GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC || 'false' }}\n") | ||
| steps = append(steps, " GH_AW_DAILY_AIC_REPO_MEMORY_TRUSTED: \"true\"\n GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC: ${{ vars.GH_AW_ALLOW_INSECURE_REPO_MEMORY_AIC || 'false' }}\n") |
There was a problem hiding this comment.
[/diagnosing-bugs] Building on the existing review comment: the real root cause is that the clone step has no id: and no output distinguishing "real clone succeeded" from "clone failed, orphan created." Trust is set unconditionally here with no gate on the clone's result.
💡 Suggested fix
In clone_repo_memory_branch.sh, emit a step output (e.g. echo "cloned=true" >> "$GITHUB_OUTPUT" on the success branch, cloned=false otherwise), give the clone step an id: in buildDailyAICRepoMemoryCloneStep, and gate this line with if: steps.<clone-id>.outputs.cloned == 'true' (mirroring the steps.<id>.outcome == 'success' pattern already used in cache_memory.go:274). Also add a regression test asserting the guardrail stays untrusted/fails-closed when the clone step fails or falls back to orphan creation — today's new test only covers the already-trusted happy path.
@copilot please address this.
There was a problem hiding this comment.
Implemented in f48f8b3: the clone step now has an ID and emits a cloned output, and guardrail trust is conditioned on that output. Regression tests cover verified missing branches, successful clones, clone failures, and remote verification failures.
|
@copilot address the following outstanding work in one pass:
Push the necessary fixes, reply to each listed review thread and resolve it when addressed. Ignore feedback already answered or resolved. Use the pr-finisher skill and stop when only human review or CI remains; do not trigger CI. Sous-chef head: 261f0d1
|
…olve-untrusted-aic-ledger Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
Co-authored-by: gh-aw-bot <259018956+gh-aw-bot@users.noreply.github.com>
…olve-untrusted-aic-ledger Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Merged the latest
Fixed in |
Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Fixed in |
|
@copilot resolve the merge conflicts in this pull request |
|
@copilot resolve the merge conflicts in this pull request |
1 similar comment
|
@copilot resolve the merge conflicts in this pull request |
…olve-untrusted-aic-ledger # Conflicts: # pkg/workflow/notify_comment_test.go Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Resolved the merge conflict with latest |
|
🎉 This pull request is included in a new release. Release: |

Daily AIC guardrails blocked both affected scheduled workflows because they treated repo-memory ledgers as untrusted, despite the ledger being cloned before activation.
false.