guard: the forge client send functions call the guard #660
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
Depends on
#668 guard: the raw API passthrough keeps every limit
sixfold-space/madtea
#669 guard: a parity test fails when a write skips the guard
sixfold-space/madtea
#670 epic: one guard enforces the recorded limits on every surface
sixfold-space/madtea
#653 guard: add the guard package with its three effects
sixfold-space/madtea
#654 guard: declare the effects of every operation and every spec endpoint
sixfold-space/madtea
Reference
sixfold-space/madtea#660
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What to build
The forge client in
internal/giteareceives the guard as an interface when it is built. Each function that sends a request calls the guard before a write (any method other than GET), with the effects of the endpoint. A client with no guard refuses every write. The per-handler out-of-scope checks in the MCP layer go, because the client now runs that rule on every surface.Depends on
Acceptance
madt_filescreate, update, delete, and batch,madt_git_objectsapply patch,madt_repossync_fork and merge_upstream, andmadt_branchesrename refuse a write to the default branch on the CLI and MCP.The code for this landed on main, and the host tests pass: the forge client takes the write guard as an interface, the default-branch and out-of-scope writes are refused on both surfaces, and an omitted-class delete is refused at the client. This issue depends on #654, which stays open, so it is not closed yet. #654 has the effect-declaration mechanism in place, but its own dependency #538 (the vendored specs are stale against the live forge) is still open.
The v0.20.0 breaking set is complete and green on main. The code landed across the v0.20.0 branches, the full local gate passes, and the forge suite is green on both forges at both pinned versions on current main (
31693766). Closing as done.