[aw-compat] Restore GitHub toolset mapping parity with declared default tools

[Copilot]

Bug Fix

What was the bug?

pkg/constants/tool_constants.go and pkg/workflow/data/github_tool_to_toolset.json drifted: 17 tools declared as valid defaults had no toolset mapping, causing compile-time Unknown GitHub tool(s) failures when those tools were used in tools.github.allowed.

How did you fix it?

• Mapping parity restoration
  • Added the 17 missing entries to pkg/workflow/data/github_tool_to_toolset.json with toolsets aligned to existing conventions/upstream categories:
    • pull_requests: get_pull_request_comments, get_pull_request_diff, get_pull_request_files, get_pull_request_review_comments, get_pull_request_reviews, get_pull_request_status
    • dependabot: get_dependabot_alert, list_dependabot_alerts
    • discussions: get_discussion, get_discussion_comments, list_discussion_categories
    • notifications: get_notification_details
    • actions: get_workflow_run_logs
    • issues: list_issue_types, list_label
    • repos: list_starred_repositories
    • orgs: search_orgs
• Regression guard
  • Added TestGitHubToolToToolsetMap_IncludesDefaultGitHubTools in pkg/workflow/github_tool_to_toolset_test.go to assert every tool in constants.DefaultReadOnlyGitHubTools resolves in GitHubToolToToolsetMap.

Testing

• Added invariant coverage so future additions to default GitHub tools fail fast if mapping parity is broken.

{
  "get_pull_request_files": "pull_requests",
  "get_workflow_run_logs": "actions",
  "list_issue_types": "issues",
  "search_orgs": "orgs"
}

[Copilot]

Pull request overview

Restores parity between the default GitHub tool allowlist and the GitHub-tool-to-toolset mapping to prevent “Unknown GitHub tool(s)” validation failures, and adds a regression test to keep them from drifting again.

Changes:

• Added missing default-tool entries to pkg/workflow/data/github_tool_to_toolset.json.
• Added a unit test asserting every tool in constants.DefaultReadOnlyGitHubTools exists in GitHubToolToToolsetMap.
• Minor comment-only tweak in the Issue Monster workflow lock file.

Show a summary per file

File	Description
pkg/workflow/github_tool_to_toolset_test.go	Adds a regression test ensuring all default GitHub tools resolve in the mapping.
pkg/workflow/data/github_tool_to_toolset.json	Adds mappings for previously-unmapped default GitHub tools (tool → toolset).
.github/workflows/issue-monster.lock.yml	Comment-only adjustment in an embedded example snippet.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (2)

pkg/workflow/data/github_tool_to_toolset.json:68

• list_label is mapped to the issues toolset, but it is documented/defined as part of the labels toolset (see .github/aw/github-mcp-server.md ### labels, and pkg/workflow/data/github_toolsets_permissions.json where labels.tools includes list_label). This mapping should be "labels" to keep toolset selection consistent.

  "get_label": "labels",
  "list_label": "issues",
  "list_labels": "labels",
  "create_label": "labels",

pkg/workflow/data/github_tool_to_toolset.json:79

• search_orgs is mapped to the orgs toolset, but it is documented/defined under the search toolset (see .github/aw/github-mcp-server.md ### search, and pkg/workflow/data/github_toolsets_permissions.json where search.tools includes search_orgs). Mapping it to orgs makes toolset-based allowlisting misleading.

  "get_organization": "orgs",
  "list_organizations": "orgs",
  "search_orgs": "orgs",

• Files reviewed: 3/3 changed files
• Comments generated: 1