Skip to content

git-permission wiring conflict #13

Description

@kyau

The build primary agent denies git add *, git stage *, git commit *, and git push *. That's a defensible human-in-the-loop posture. But large parts of the harness instruct agents running in build context to do exactly those things:

  • /release (frontmatter agent: build) — Step 3: git add CHANGELOG.md && git commit -S -m "chore(release): vX.Y.Z", Step 4: git tag -s. The stage and commit are denied at runtime.
  • /build-assets (agent: build) — Step 3: git add cdn/css/ cdn/javascript/. Denied.
  • brainstorming skill — "Save the validated design … and commit the design document to git." Loaded by the build agent. Denied.
  • @code-review is documented as "reviewing staged changes before push" — but nothing in the harness is permitted to stage; the human must, and that's never stated.

Meanwhile @tdd — the agent that per writing-plans executes the per-task "Step 5: Commit" — has no permission block at all, so it inherits full defaults and can stage, commit, and push freely. The net effect: the tightly-gated primary can't commit, but the subagent it dispatches can do anything. If that's intentional (commits only happen inside disciplined @tdd cycles), it's undocumented and porous (@tdd could also git push). If it's not intentional, /release and /build-assets are simply broken as shipped.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Fields

No fields configured for Security.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions