feat(gates): MaxImpact cap, --allow-major, and dogfood the API surface gate - #1
Merged
Merged
Conversation
…e gate - SemverPolicy.MaxImpact (default major = cap off): fragments/releases that would force a Major bump are refused at new and release unless --allow-major is passed. Interactive menu marks blocked categories and re-prompts. - MCP tools expose the gates: validate_fragments apiMinLevel, perform_release allowMajor/apiMinLevel. - Dogfood the API Surface Gate on ChangeSharp itself: committed baselines (tests/public-api: cli-help, mcp-tools, public-api via PublicApiGenerator), scripts/update-public-api.sh, api-surface CI job, PublicApiBaselineTests. - Demo workspace samples/maximpact-gate with self-verifying run-demo.sh. - Docs updated (SemVer Rules, ApiSurfaceGate, McpIntegration, Roadmap).
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. Thanks for integrating Codecov - We've got you covered ☂️ |
- MCP create_fragment now enforces SemverPolicy.MaxImpact with an allowMajor opt-in, matching the CLI new command (review finding). - Regenerate mcp-tools.json baseline (create_fragment schema). - Document that prerelease create/promote bypass the gates (pre-existing behavior, shared with --api-min-level), that cli-help rewording is treated conservatively as major by the api-surface heuristic, and that scripts/update-public-api.sh requires jq (now checked up front).
…-major - Add WorkspaceManager.GetCreateFragmentError and GetReleaseGateResult so the CLI and MCP share the exact same gate sequence (floor then cap), removing the CLI/MCP orchestration drift (create_fragment had been missed initially; gate vs security precedence differed). - Add NextVersionComputer.ImpactName; drop the duplicated CLI/MCP helpers. - Record the explicit --allow-major decision in release output (CLI warning + JSON warnings; MCP response text) as an audit trail. - Extend samples/maximpact-gate/run-demo.sh with MCP e2e gate scenarios (11/11). - Note the MaxImpact/Mappings interaction (Changed->Major + minor cap blocks Changed) in SemVer Rules. - Regenerate public-api.txt baseline (+ImpactName, +GetCreateFragmentError, +GetReleaseGateResult).
- Extract RenderCategoryMenu and ApplyCategoryKey out of PromptForCategory. - Extract BumpForImpact out of ComputeVersionWithWarning (behavior preserved, covered by the existing SemVer tests).
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ChangeSharp documented API-impact detection gates (
--api-min-levelfloor and the newMaxImpactcap) without ever applying them to itself. This PR implements and dogfoods both gates on the real public surfaces: CLI, MCP, and the library.What changed
1. MaxImpact cap (new symmetric guard)
SemverPolicy.MaxImpact(patch|minor|major, defaultmajor= cap disabled) — single source of truth inChangeSharpConfig.csnew, interactive + flags) and release (release), both requiring the explicit--allow-majorflag⚠ blocked (MaxImpact)) and re-promptssamples/maximpact-gate/run-demo.sh(11/11, CLI + MCP)2. Dogfood the API Surface Gate on ChangeSharp itself
tests/public-api/:cli-help.txt(CLI),mcp-tools.json(MCP),public-api.txt(library via PublicApiGenerator)scripts/update-public-api.shto regenerateapi-surface: regenerates → verifies the committed baselines → derives impact (additions = minor, removals = major) → runschangesharp validate --api-min-level <impact>PublicApiBaselineTestsalso enforces the library baseline atdotnet testtime3. MCP aligned with the CLI
create_fragment:allowMajorvalidate_fragments:apiMinLevelperform_release:allowMajor+apiMinLevel4. Single gate orchestration in the library
WorkspaceManager.GetCreateFragmentErrorandGetReleaseGateResultcentralize the gate sequence (floor then cap) so the CLI and MCP cannot drift--allow-majordecisions are recorded in the release output (audit trail)5. Tests & docs
WorkspaceManagerTests) + 1 baseline test → 114 tests greenVerification
dotnet build ChangeSharp.sln -c Release: 0 errorsdotnet test: 114/114samples/maximpact-gate/run-demo.sh: 11/11 (CLI + MCP gate scenarios)Known limits
prereleasecreate/promote path bypasses the gates (pre-existing, shared with--api-min-level); documented in SemVer Rules.MaxImpact: major(cap not enabled here), as agreed; the mechanism is exercised on the sample workspace.