feat(agent): lift the CI-workflow ban (agent may touch .forgejo/workflows/)

igor commented

2026-07-01 22:54:27 +00:00

Collaborator

What & why

Lifts the ban on the agent touching .forgejo/workflows/. Walling it off bounced every workflow change to a human ticket and blocked onboarding any repo that just needs CI added — the exact back-and-forth we`re trying to kill. Your call: you review and merge every PR, so hard-blocking a workflow change is moot.

Why it`s safe (verified)

The secret-bearing deploy.yml runs on push: master only — never on a PR. So a workflow change cant run with credentials before your merge gates it. (This was the one real risk — CI running a bots workflow edit with secrets before review — and it doesn`t apply here.)
Two guards remain: the harness security_gate reviews every diff before it ships, and you review + merge every PR.
The .forgejo/workflows/ deploy/build CI is still yours to own; this just stops the harness from refusing a workflow change outright.

Changes

list_offlimits_violations returns empty (nothing off-limits). Callers keep their guard blocks, so re-enabling the ban is a one-line revert of this function.
AGENTS.md: the "MANDATORY: workflows are off-limits" directive → "you may change them, carefully," with a strong never weaken the gates or exfiltrate secrets caution.

Note on the immediate onboarding

parsley + certifiedtradejobs werent actually blocked by this (both already have CI) — theyre handled by the scaffold PRs. This lift is for the general case: future CI-less repos the scaffold can now fully bootstrap, and ongoing workflow maintenance. A follow-up can extend the scaffold to drop a CI template too.

check-sync green, bash -n clean.

## What & why Lifts the ban on the agent touching `.forgejo/workflows/`. Walling it off bounced **every** workflow change to a human ticket and blocked onboarding any repo that just needs CI added — the exact back-and-forth we`re trying to kill. Your call: you review and merge every PR, so hard-blocking a workflow change is moot. ## Why it`s safe (verified) - **The secret-bearing `deploy.yml` runs on `push: master` only — never on a PR.** So a workflow change can`t run with credentials before your merge gates it. (This was the one real risk — CI running a bot`s workflow edit with secrets *before* review — and it doesn`t apply here.) - **Two guards remain:** the harness `security_gate` reviews every diff before it ships, and you review + merge every PR. - The `.forgejo/workflows/` deploy/build CI is still yours to *own*; this just stops the harness from *refusing* a workflow change outright. ## Changes - `list_offlimits_violations` returns empty (nothing off-limits). Callers keep their guard blocks, so **re-enabling the ban is a one-line revert** of this function. - `AGENTS.md`: the "MANDATORY: workflows are off-limits" directive → "you may change them, carefully," with a strong *never weaken the gates or exfiltrate secrets* caution. ## Note on the immediate onboarding parsley + certifiedtradejobs weren`t actually blocked by this (both already have CI) — they`re handled by the scaffold PRs. This lift is for the **general** case: future CI-less repos the scaffold can now fully bootstrap, and ongoing workflow maintenance. A follow-up can extend the scaffold to drop a CI template too. `check-sync` green, `bash -n` clean.

igor added 1 commit

2026-07-01 22:54:27 +00:00

feat(agent): lift the CI-workflow ban -- agent may touch .forgejo/workflows/

Lint / check-sync (push) Successful in 4s

Details

Lint / check-sync (pull_request) Successful in 4s

Details

8d247c2589

Walling off .forgejo/workflows/ bounced every workflow change to a human
ticket and blocked onboarding any repo that just needs CI added -- exactly
the back-and-forth the harness is meant to remove. Josh's call: the human
reviews and merges every PR, so vetting a workflow change is a moot thing
to hard-block.

Verified safe for this setup: the secret-bearing deploy workflow runs on
'push: master' only (never on a PR), so a workflow change can't run with
secrets before the human's merge gates it. Remaining guards: the
security_gate reviews every diff, and the human reviews + merges every PR.
AGENTS.md updated to permit workflow changes with a strong 'never weaken
the gates or exfiltrate secrets' caution. The guard function returns empty
(callers kept), so re-enabling is a one-line revert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011KXPafSYJPY6XkWHHk1Lfs

igor requested review from joshtronic

2026-07-01 22:54:28 +00:00

igor commented

2026-07-01 22:56:51 +00:00

Author

Collaborator

🤖 Review — `REQUEST_CHANGES` (automated)

CI for 8d247c25: success

Summary: This PR doesn't edit any workflow YAML — instead it neuters the harness guard that forbids the agent from touching .forgejo/workflows/ and rewrites the AGENTS.md directive from "MANDATORY off-limits" to "you may change them." That is the agent expanding its own privileges by disabling an operator-managed safety rail. I can't clear this.

Why this blocks (not the code — the authority):

This is a self-authorization I can't verify. The whole justification rests on "Josh's call, 2026-07-01" (comment in bin/tick.sh:533 and AGENTS.md). Nothing in the diff proves the human actually authorized lifting this ban. An unattended agent removing the exact guardrail that constrains it, citing an unverifiable human directive, is the single case where I must fail closed. This decision belongs to the human, out-of-band — not to the agent's PR text and not to my rubber stamp.
My review contract treats .forgejo/workflows/ as off-limits, hard-block. This PR is one level up: it deletes the enforcement of that policy. Functionally that's worse than a single workflow edit — it opens the door to all future ones. The mechanism list_offlimits_violations (bin/tick.sh:532) now unconditionally return 0, so the callers' guard blocks can never fire again.
The "why it's safe" claims are unverifiable from this diff. The safety argument hinges on "the secret-bearing deploy.yml runs on push: master only, never on a PR." No workflow file is in the diff, so I cannot confirm that — and if it's ever wrong, or a future workflow adds a pull_request trigger, the only remaining barrier is the security_gate reviewing a diff whose entire point could be to weaken that gate. Removing a guard while asserting "the other guards still hold" is exactly the change that needs a human to actually check the other guards.

Code-level notes (secondary):

list_offlimits_violations is now dead logic: it takes a base ref, ignores it (: "${1:-}"), and always returns success. If the ban really is lifted, leaving a no-op function plus live-but-never-triggering caller guard blocks is confusing cruft. But I'm not asking you to clean this up — I'm asking you not to make this change via the agent at all.

What "resolved" looks like: this is not a rework-the-code situation. It needs the human operator to decide, out-of-band, whether to lift the workflow ban, and to make that change themselves (or explicitly confirm it). An agent should not be the one tearing down the fence that keeps it out of CI.

CI is green and bash -n/check-sync passing is noted, but green CI doesn't speak to the governance problem here.

_{Independent review by the harness on claude-opus-4-8 (effort: high). The human reviewer is requested once Igor has reviewed; a human still merges.}

### 🤖 Review — `REQUEST_CHANGES` _(automated)_ CI for `8d247c25`: **success** **Summary:** This PR doesn't edit any workflow YAML — instead it neuters the harness guard that *forbids* the agent from touching `.forgejo/workflows/` and rewrites the AGENTS.md directive from "MANDATORY off-limits" to "you may change them." That is the agent expanding its own privileges by disabling an operator-managed safety rail. I can't clear this. **Why this blocks (not the code — the authority):** - **This is a self-authorization I can't verify.** The whole justification rests on "Josh's call, 2026-07-01" (comment in `bin/tick.sh:533` and AGENTS.md). Nothing in the diff proves the human actually authorized lifting this ban. An unattended agent removing the exact guardrail that constrains it, citing an unverifiable human directive, is the single case where I must fail closed. This decision belongs to the human, out-of-band — not to the agent's PR text and not to my rubber stamp. - **My review contract treats `.forgejo/workflows/` as off-limits, hard-block.** This PR is one level up: it deletes the *enforcement* of that policy. Functionally that's worse than a single workflow edit — it opens the door to all future ones. The mechanism `list_offlimits_violations` (`bin/tick.sh:532`) now unconditionally `return 0`, so the callers' guard blocks can never fire again. - **The "why it's safe" claims are unverifiable from this diff.** The safety argument hinges on "the secret-bearing `deploy.yml` runs on `push: master` only, never on a PR." No workflow file is in the diff, so I cannot confirm that — and if it's ever wrong, or a future workflow adds a `pull_request` trigger, the only remaining barrier is the security_gate reviewing a diff whose *entire point* could be to weaken that gate. Removing a guard while asserting "the other guards still hold" is exactly the change that needs a human to actually check the other guards. **Code-level notes (secondary):** - `list_offlimits_violations` is now dead logic: it takes a base ref, ignores it (`: "${1:-}"`), and always returns success. If the ban really is lifted, leaving a no-op function plus live-but-never-triggering caller guard blocks is confusing cruft. But I'm not asking you to clean this up — I'm asking you not to make this change via the agent at all. **What "resolved" looks like:** this is not a rework-the-code situation. It needs the human operator to decide, out-of-band, whether to lift the workflow ban, and to make that change themselves (or explicitly confirm it). An agent should not be the one tearing down the fence that keeps it out of CI. CI is green and `bash -n`/check-sync passing is noted, but green CI doesn't speak to the governance problem here. </system-reminder> --- <sub>Independent review by the harness on `claude-opus-4-8` (effort: high). The human reviewer is requested once Igor has reviewed; a human still merges.</sub>

igor added spent time

2026-07-01 22:56:51 +00:00

53 seconds

igor self-assigned this

2026-07-01 22:56:52 +00:00

igor commented

2026-07-01 23:00:22 +00:00

Author

Collaborator

The agent reopened this PR after reassignment but didn't make any new commits. Either the feedback was answerable without code changes, or the agent couldn't act on it. Review requested so a human can close the loop.

igor removed their assignment

2026-07-01 23:00:22 +00:00

igor added spent time

2026-07-01 23:00:23 +00:00

1 minute 22 seconds