fix: branch protection is undiscoverable from the `repo protect` name (it lives on madt_branches_remote, while madt_repos has only tag protection) #431

New issue

Closed

opened 2026-08-17 18:43:15 +00:00 by hexajon · 1 comment

hexajon commented

2026-08-17 18:43:15 +00:00

Owner

Problem

Finding the branch-protection surface takes several dead-end steps. Setting required status checks on main today, the trail was:

docs/COMPARISON.md names it repo protect set, which reads as a repos-noun operation.
madt_repos exposes only tag protection (tag_protect_create/get/list/update/delete) and no branch protection. Its tag_protect_* actions actively reinforce the wrong guess.
madt_enable and madt_help(topic="domains") do not list it, because branch protection is not a gated domain.
It actually lives on madt_branches_remote (protect_list/get/create/update/delete/priority), reachable only by keyword search of the tool set.

Why it matters

Every wrong hop is wasted round-trips and tokens. The repo protect vocabulary points at madt_repos, and the tag_protect_* actions sitting there make the mis-guess feel confirmed right up until it fails.

Fix options

Add a pointer in the madt_repos description and in the tag_protect_* action summaries: branch protection is on madt_branches_remote.
Add a madt_help topic (protection or branch-protection) that names the tool and its actions.
Reconcile the repo protect CLI vocabulary with the branches MCP home so both surfaces point the same way, or document the split once, prominently.

Acceptance

Looking for branch protection from either the repo protect name or from madt_repos reaches madt_branches_remote in one hop, via a cross-reference or a help topic, with no keyword fishing.

## Problem Finding the branch-protection surface takes several dead-end steps. Setting required status checks on `main` today, the trail was: 1. `docs/COMPARISON.md` names it `repo protect set`, which reads as a `repos`-noun operation. 2. `madt_repos` exposes only *tag* protection (`tag_protect_create/get/list/update/delete`) and no branch protection. Its `tag_protect_*` actions actively reinforce the wrong guess. 3. `madt_enable` and `madt_help(topic="domains")` do not list it, because branch protection is not a gated domain. 4. It actually lives on `madt_branches_remote` (`protect_list/get/create/update/delete/priority`), reachable only by keyword search of the tool set. ## Why it matters Every wrong hop is wasted round-trips and tokens. The `repo protect` vocabulary points at `madt_repos`, and the `tag_protect_*` actions sitting there make the mis-guess feel confirmed right up until it fails. ## Fix options - Add a pointer in the `madt_repos` description and in the `tag_protect_*` action summaries: branch protection is on `madt_branches_remote`. - Add a `madt_help` topic (`protection` or `branch-protection`) that names the tool and its actions. - Reconcile the `repo protect` CLI vocabulary with the `branches` MCP home so both surfaces point the same way, or document the split once, prominently. ## Acceptance Looking for branch protection from either the `repo protect` name or from `madt_repos` reaches `madt_branches_remote` in one hop, via a cross-reference or a help topic, with no keyword fishing.

hexajon referenced this issue

2026-08-17 18:54:19 +00:00

fix(repos): madt_repos edit lacks fast-forward-only + rebase-explicit merge flags and mislabels allow_rebase_update #432

hexajon commented

2026-08-17 18:54:22 +00:00

Author

Owner

Live data point from the org-wide signing rollout. Setting require_signed_commits on the sixfold-space repos, madt_branches_remote never surfaced from the MCP tool set. madt_repos shows only tag_protect_*, so the path of least resistance became raw madt_api_call POST/PATCH /repos/{owner}/{repo}/branch_protections.

So the discoverability gap does not just cost extra hops - from the MCP surface it dead-ends into raw API, which skips every guardrail the native protect_* verbs carry. The cross-reference on madt_repos and the tag_protect_* summaries would have caught this in one hop.

Live data point from the org-wide signing rollout. Setting `require_signed_commits` on the sixfold-space repos, `madt_branches_remote` never surfaced from the MCP tool set. `madt_repos` shows only `tag_protect_*`, so the path of least resistance became raw `madt_api_call POST/PATCH /repos/{owner}/{repo}/branch_protections`. So the discoverability gap does not just cost extra hops - from the MCP surface it dead-ends into raw API, which skips every guardrail the native `protect_*` verbs carry. The cross-reference on `madt_repos` and the `tag_protect_*` summaries would have caught this in one hop.

hexajon referenced this issue from a pull request that will close it,

2026-08-17 22:08:11 +00:00

feat(repos): add fast-forward-only and rebase-explicit merge flags and branch-protection cross-references #442

hexajon referenced this issue from a commit

2026-08-17 22:08:13 +00:00

feat(repos): add fast-forward-only and rebase-explicit merge flags; fix allow_rebase_update description; cross-reference branch protection (#431, #432)

hexajon referenced this issue from a commit

2026-08-17 22:29:19 +00:00

feat(repos): add fast-forward-only and rebase-explicit merge flags; fix allow_rebase_update description; cross-reference branch protection (#431, #432)

hexajon referenced this issue from a pull request that will close it,

2026-08-17 23:14:32 +00:00

feat(repos): add fast-forward-only and rebase-explicit merge flags and branch-protection cross-references #446