Summary
The mcp-tools change rule in cli/src/internal/docsgate/changed.go:63-68 watches cli/src/internal/mcp/. That directory doesn't exist and never has, so the rule can't fire. The MCP tool surface has no docs enforcement, which is the thing PR #583 added the rule to guarantee.
Evidence
git log --all -- cli/src/internal/mcp returns nothing. The path has never been committed.
All MCP code lives in cli/src/cmd/app/commands/: mcp.go, mcp_tools.go, mcp_helpers.go, mcp_info.go, mcp_resources.go, mcp_sanitize.go, mcp_process_unix.go, mcp_process_windows.go.
mcp_tools.go registers all 12 tools: get_services, get_service_logs, get_service_errors, get_project_info, run_services, stop_services, start_service, restart_service, install_dependencies, check_requirements, get_environment_variables, set_environment_variable.
Why it matters
The docs it protects are real: web/src/pages/mcp/tools.astro documents the tool surface, so drift is possible and currently unguarded.
Editing an MCP tool does still trip the cli-commands rule, since mcp_tools.go sits under cli/src/cmd/app/commands/ and that rule watches the whole directory. But that rule's hint points at cli/docs/cli-reference.md, which is the wrong place for an MCP change, and satisfying it never requires touching the MCP docs.
Note also that CheckChangedFiles returns early when hasDocChange(changed) is true, so any unrelated doc edit in the same PR suppresses every change rule.
Suggested fix
Either point the rule at cli/src/cmd/app/commands/ with an mcp filename filter, or move the MCP code to cli/src/internal/mcp/ so it matches the rule as written. Moving the code is cleaner, since the rule table reads as though that layout was intended.
Either way, add a test that every rule prefix resolves to a real directory, so a dead rule can't ship again.
Acceptance criteria
Summary
The
mcp-toolschange rule incli/src/internal/docsgate/changed.go:63-68watchescli/src/internal/mcp/. That directory doesn't exist and never has, so the rule can't fire. The MCP tool surface has no docs enforcement, which is the thing PR #583 added the rule to guarantee.Evidence
git log --all -- cli/src/internal/mcpreturns nothing. The path has never been committed.All MCP code lives in
cli/src/cmd/app/commands/:mcp.go,mcp_tools.go,mcp_helpers.go,mcp_info.go,mcp_resources.go,mcp_sanitize.go,mcp_process_unix.go,mcp_process_windows.go.mcp_tools.goregisters all 12 tools:get_services,get_service_logs,get_service_errors,get_project_info,run_services,stop_services,start_service,restart_service,install_dependencies,check_requirements,get_environment_variables,set_environment_variable.Why it matters
The docs it protects are real:
web/src/pages/mcp/tools.astrodocuments the tool surface, so drift is possible and currently unguarded.Editing an MCP tool does still trip the
cli-commandsrule, sincemcp_tools.gosits undercli/src/cmd/app/commands/and that rule watches the whole directory. But that rule's hint points atcli/docs/cli-reference.md, which is the wrong place for an MCP change, and satisfying it never requires touching the MCP docs.Note also that
CheckChangedFilesreturns early whenhasDocChange(changed)is true, so any unrelated doc edit in the same PR suppresses every change rule.Suggested fix
Either point the rule at
cli/src/cmd/app/commands/with anmcpfilename filter, or move the MCP code tocli/src/internal/mcp/so it matches the rule as written. Moving the code is cleaner, since the rule table reads as though that layout was intended.Either way, add a test that every rule prefix resolves to a real directory, so a dead rule can't ship again.
Acceptance criteria
mcp-toolsrule matches the files that actually define MCP toolschangeRuleprefix doesn't exist in the repomcp_tools.gowithout touching MCP docs trips themcp-toolsrule