Draft: Add bt_tools — Business Template list/find_owner/dirty/commit/open_mr

Why Draft

The five new MCP tools all pass the existing 444-test unit suite, but they're exercised by a single hand-driven flow on one dev instance so far. Real-world validation still needed before un-WIP-ing:

• Run erp5_bt_find_owner against several distinct Installed BTs to shake out manifest mappings I haven't seen (e.g. ZSQL Methods, Tools, Catalog keys, Workflow scripts, Local Roles).
• Drive erp5_bt_dirty + erp5_bt_commit on BTs whose working copy is on a branch other than master and confirm the commit lands on that branch.
• Verify the helper-script auto-install path on a fresh ERP5 instance with no prior mcp_bt_* scripts in portal_skins/custom.
• Stress the ** glob matcher in _match_owner against template_path_list entries with multiple wildcards (current matcher treats ** as a single recursive wildcard).
• Confirm erp5_bt_open_mr URL works against a Gitea / GitHub-backed BT, not just GitLab (the merge_request[…]=… querystring shape is GitLab-specific; other forges need different param names).

Summary

Wraps ERP5's Business Template git workflow with five structured-JSON tools so callers never round-trip the rendered HTML page that git_commit_action returns. Token cost on the agent side drops by roughly two orders of magnitude per BT operation.

Tool	Purpose
erp5_bt_list	Sort portal_templates by NUMERIC id (catalog sorts strings) with title/state filters.
erp5_bt_find_owner	Given a live document URL, find the Installed BT whose manifest claims it, plus the highest-id Not Installed sibling as the natural commit target. No local bt5/ grep needed.
erp5_bt_dirty	Flat list of dirty files in a BT working copy ({status: A/M/D, path}), optionally fnmatch-filtered. Replaces the ~14k-token raw XML tree from getModifiedTree.
erp5_bt_commit	Commit a specific set of dirty files and push. Returns {revision, pushed} instead of the full re-rendered BT view HTML.
erp5_bt_open_mr	Build a GitLab "new MR" URL pre-filled with title, description, source/target branch. URL-only: the human clicks to submit, browser handles auth — no PAT in the MCP server, no glab dependency.

Tools are dev-mode only (erp5-mcp-portalmanager entry point) since they require Manage portal permission and combined with erp5_skin_write give arbitrary code execution on the ERP5 instance. Four short Python Script helpers (mcp_bt_getDirtyFiles, mcp_bt_doCommit, mcp_bt_getRemote, mcp_bt_getManifest) are auto-installed in portal_skins/custom on first use; a _HELPERS_VERSION constant forces re-deploy when their bodies change.

TODO — move this upstream into erp5_forge

These tools belong in ERP5 itself (specifically erp5_forge), not in an MCP-only shim. Two reasons:

1. Humans using the ERP5 UI deserve the same conveniences. Today erp5_forge only exposes commit / revert / update on Business Template via the VCS dialog. Anything else (creating an MR, switching branches, checking out a different ref, resetting, squashing) means SSH-ing to the Zope instance and running git by hand. That's a big gap for day-to-day BT maintenance.
2. It would shrink the MCP server. Most of this module is plumbing around the fact that the upstream BusinessTemplate_doVcs* scripts return rendered HTML and the manifest fields are scattered across two views. With proper upstream support, the MCP tools become thin wrappers over HATEOAS actions.

Concrete wishlist for erp5_forge:

• Create Merge Request action on Business Template that returns the pre-filled forge URL (the URL-mode trick erp5_bt_open_mr uses today). No PAT to manage server-side; the user's browser handles auth.
• Find Owning Business Template — given any document URL, jump to the BT whose manifest claims it. Same logic as erp5_bt_find_owner.
• Richer git-operation menu on a BT:
  • switch / checkout branch
  • create branch (from current HEAD or arbitrary ref)
  • reset --hard <ref>
  • squash last N commits (with editable message)
  • cherry-pick a commit by SHA
  • stash / pop
  • rebase onto remote
• Structured JSON responses from BusinessTemplate_doVcsCommit and siblings, so callers (this MCP server, future UIs, automation) stop having to scrape transition_message out of a re-rendered BT view page.

When that lands, erp5_mcp/bt_tools.py can be deleted and the MCP tools rewritten to call the upstream HATEOAS endpoints directly.

Test plan

• Existing 444 unit tests still pass.
• Live: end-to-end exercise on multiple BTs (different owning projects, different forges).
• Live: cold-start helper auto-install on an instance with no prior mcp_bt_* scripts.
• Live: forge other than GitLab (URL shape may differ).
• Add unit tests for _match_owner's URL → manifest-field mapping and _numeric_id / _normalise_state once we agree on the public shape.

🤖 Generated with Claude Code