sdd-execute cannot add a covering CI check — .github/ is barred by protect_top_level_dot_folders, so proof-artifact gaps that need CI are an unbreakable needs-human

[norrietaylor]

Summary

When a task's proof artifact can only be covered by a CI/workflow change, sdd-execute cannot satisfy it: the agent's create_pull_request / push_to_pull_request_branch safe-outputs run with protect_top_level_dot_folders: true, which strips any change under a top-level dot-folder — including .github/workflows/. So the one remediation sdd-validate itself offers ("a human must verify the proof or add a covering check") is structurally impossible for the agent. The result is a guaranteed needs-human with no autonomous path, even via /revise.

Evidence (E2E tracker gominimal/minimal#311, task #326 / PR #339)

• sdd-validate flagged the R2.4 boot proof as a Blocker: "a proof artifact blocked by an infrastructure limit and covered by no consumer required status check is a Blocker — a human must verify the proof or add a covering check." → applied needs-human.
• A /revise was posted instructing the agent to add a ci-macos.yml step that fetches the kernel and runs boot_e2e (i.e., add the covering check sdd-validate asked for).
• The agent ran (agent:success) but could not touch .github/. Its safe-output config (from the run log):

  "push_to_pull_request_branch": { ... "protect_top_level_dot_folders": true ... },
  "create_pull_request":        { ... "protect_top_level_dot_folders": true ... }

  It instead made an unrelated in-scope source edit (crates/minvmd/src/cmd/boot.rs) and pushed that. The CI coverage was never added.

Root cause

protect_top_level_dot_folders: true is a blanket guard that blocks all .github/ edits. CI-coverage remediation lives in .github/workflows/. So sdd-validate can demand a covering check, and /revise can instruct one, but sdd-execute can never produce one. Unbreakable loop.

Fix (options)

• Allow sdd-execute to modify .github/workflows/ under a scoped exception (e.g., when the task is explicitly a CI-coverage task), instead of the blanket dot-folder block; or
• Have sdd-validate recognize that "add a covering check" is not an agent-actionable remediation and route such proof-artifact gaps to an explicit human-CI lane (distinct label/instruction) rather than a needs-human the agent will silently fail to clear; or
• Provide a dedicated safe-output for workflow edits with its own review/guard, so CI coverage can be added without lifting the general dot-folder protection.

Acceptance

• A task whose only remediation is a CI/workflow change either (a) is completed by the agent editing .github/workflows/ under a scoped allowance, or (b) is routed to a clearly-labeled human-CI task — never left as a needs-human the agent provably cannot clear.

References

• gominimal/minimal#311, task #326, PR #339; sdd-validate Blocker + /revise that the agent could not honor.
• Compounding: sdd-execute: impl PRs fail repo CI (fmt/build/lint) — sandbox firewall blocks the crate registry, and there is no pre-PR CI gate #205 (firewall prevents the agent from building/verifying), sdd-execute/review: post-approval CI failure has no remediation path #203 (post-approval CI failure), sdd-execute: green impl run with no mergeable artifact (no PR, or empty 0-diff PR) reports success #204 (no-artifact runs).

[norrietaylor]

Can a configured, no-wildcard allowlist open a covering-CI lane?

Mechanically yes — via the same protected-files.exclude knob sdd-execute already uses for pyproject.toml / package.json — but two gh-aw limits make a clean single-file allow impossible.

Mechanism (already in the repo)

.github/workflows/sdd-execute-*.md already path-excludes files from gh-aw's protected set:

create-pull-request:
  protected-files:
    policy: fallback-to-issue
    exclude:
      - pyproject.toml
      - package.json

Per gh-aw docs, a dot-folder path-prefix in exclude also opts that directory out of the blanket protect_top_level_dot_folders rule. Adding .github/workflows/ to exclude makes that directory writable, closing this dead end. Entries are literal paths — no wildcards.

Caveat 1 — granularity is directory-prefix, not single-file

The repo's own code notes gh-aw "cannot scope to a single TOML table"; the same applies here — the dot-folder opt-out unit is the directory (.github/workflows/), not one file. gh-aw's true positive allowlist (allowed-files, exclusive: every patched file must match a pattern) exists but is global to the safe-output, so it cannot add one path on top of otherwise-unrestricted edits.

Caveat 2 — that directory also holds files that must stay locked

Excluding .github/workflows/ also exposes the generated *.lock.yml and recompile-locks.yml (which guards the ADR-0019 commit-to-main bypass). gh-aw's protected-files supports only policy + exclude (subtract from defaults) — there is no additive include to re-protect the locks. So a directory-prefix exclude over-exposes the very files that must never be agent-writable.

Options

1. Per-consumer opt-in allowlist (default off): protected-files.exclude: ['.github/workflows/']. Bounded to repos that want full self-CI autonomy; relies on human review of every agent PR (recompile-locks drift gate also reds any lock edit). Footgun: needs a way to keep locks/recompile-locks.yml off-limits, which protected-files alone cannot express.
2. Human-CI lane (simpler default): route a proof-artifact gap whose only remediation is a CI/workflow change to an explicitly-labeled human task, instead of a needs-human the agent provably cannot clear. No protected-set change; matches the current trust model.
3. Dedicated safe-output for workflow edits with its own guard — most work, cleanest separation.

Recommendation: ship (2) as the default (it removes the unbreakable-loop), and offer (1) as an opt-in for repos that accept the footgun. Prototyping (1) on a branch to confirm gh aw compile accepts a .github/ exclude and how the compiled lock represents the dot-folder opt-out.