Follow-up: add an MCP negative control for secret:false
Origin: glm:initialMCP.F2 from the PR1397 MCP review.
The MCP regression tests currently prove that a secret-shaped name such as Authorization becomes secret:true even when the registry declares secret:false, but they do not prove the inverse response behavior. Add a plainly named non-secret input such as PORT with secret:false to the explicit-registry and/or omitted-registry fixture and assert that the MCP response does not contain secret:true for that input.
Existing lower-level controls are present in internal/secretlike/secretlike_test.go (PORT, WORKDIR, PATH, and REGION are negative cases), and internal/registries/catalog_test.go exercises PORT only with an explicit Secret:true. Neither is an end-to-end MCP response negative control, so this follow-up would protect against a regression that forces every MCP input to secret-like.
Do not treat this as a PR1397 production defect; it is test strengthening for a future change.
Follow-up: add an MCP negative control for
secret:falseOrigin:
glm:initialMCP.F2from the PR1397 MCP review.The MCP regression tests currently prove that a secret-shaped name such as
Authorizationbecomessecret:trueeven when the registry declaressecret:false, but they do not prove the inverse response behavior. Add a plainly named non-secret input such asPORTwithsecret:falseto the explicit-registry and/or omitted-registry fixture and assert that the MCP response does not containsecret:truefor that input.Existing lower-level controls are present in
internal/secretlike/secretlike_test.go(PORT,WORKDIR,PATH, andREGIONare negative cases), andinternal/registries/catalog_test.goexercisesPORTonly with an explicitSecret:true. Neither is an end-to-end MCP response negative control, so this follow-up would protect against a regression that forces every MCP input to secret-like.Do not treat this as a PR1397 production defect; it is test strengthening for a future change.