Ground flag-release plans in matched release policies (EMSR-1930) - #151
Ground flag-release plans in matched release policies (EMSR-1930)#151bradsimantel wants to merge 1 commit into
Conversation
…d stop on gaps Close the gaps between the flag-release skill and match-release-policies so Factory (and any harness composing this skill) presents a release plan grounded in the configured release policies instead of an invented rollout: - flag-release SKILL: preview by flagKey when the flag exists OR by proposed flagTags before it does; take methods/stages/metrics only from the tool; on a missing_policy / incomplete_policy warning, surface it and STOP for clarification rather than fabricating a rollout or assuming a default; re-run matching after a refinement changes the flag, tags, or environment set. State the plan is a preview (policy re-resolves at merge). - flag-and-release-change: preview policy by flagTags in the plan phase (before the flag exists); surface warnings. - auto-release reference + READMEs updated; both skills bumped to 0.2.0; regenerated skills.json. - evals: assert match-release-policies is called per planned environment and via the flagTags path pre-creation; missing/incomplete policies produce a warning and no clean-release claim; a changed environment set re-runs matching. Added a match-release-policies mock hook (missing/incomplete/progressive scenarios) and the warnings contract to the tool definition. EMSR-1930
Skill eval results
Only suites whose source actually changed since their last recorded score were re-run. Soft-failing while we stabilise the baseline. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit df66d8b. Configure here.
| | User wants to hold, or set a `notBefore` date | Skip the releasing plan for those environments; report them as held with the reason. Never silently release against stated intent. | | ||
| | Change depends on a parent flag not yet live | Couple them with a prerequisite (set it if the MCP surface supports it); otherwise report the coupling as a required manual step. Don't let this flag release before its parent. | | ||
| | A `policy` env resolves to guarded but has no relevant metric | Say so — a guarded rollout with no meaningful metric guards nothing. Recommend `simple`, or point at metric setup. | | ||
| | A `policy` env resolves to guarded but has no relevant metric | The tool flags this as an `incomplete_policy` warning; say so — a guarded rollout with no meaningful metric guards nothing. Recommend `simple`, or point at metric setup. | |
There was a problem hiding this comment.
Relevance conflated with incomplete policy
Medium Severity
The edge-case row for a guarded env with no relevant metric now claims match-release-policies emits incomplete_policy. That warning covers missing stages or metrics structurally, not change-relevance. Plan phase still requires an agent-side relevance check when warnings is empty, so this row undercuts that and can let a guarded rollout pass as clean when attached metrics cannot compare the change.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit df66d8b. Configure here.


Summary
Closes the gaps between the
flag-releaseskill andmatch-release-policiesso a release plan is always grounded in the environment's configured release policy — never an invented rollout — and a missing/incomplete policy stops for clarification instead of a fabricated one.What changed
Skills
flag-release(0.1.0 → 0.2.0): preview policy byflagKeywhen the flag exists or by proposedflagTagsbefore it does; take methods/stages/metrics only from the tool; on amissing_policy/incomplete_policywarning, surface it and stop for clarification rather than fabricating a rollout or assuming a default; re-run matching after a refinement changes the flag, tags, or environment set; state the plan is a preview (policy re-resolves at merge).flag-and-release-change(0.1.0 → 0.2.0): plan-phase policy preview usesflagTags(the flag doesn't exist yet) and surfaces warnings.references/auto-release.md+ both READMEs; regeneratedskills.json; bumpedmarketplace.jsonversions.Evals (
evals/)flag-release: added missing-policy (warn-and-stop, no unbacked policy rollout) and incomplete-policy (no clean-guarded-rollout claim) cases.flag-and-release-change: added a pre-creationflagTagspreview assertingmatch-release-policiesis called per planned environment via the flagTags path, and a refinement case asserting a changed environment set re-runs matching for the added environment.match-release-policiesmock hook (_mock.js) driving missing/incomplete/progressive scenarios by project key,warnings: []on the default mock, and thewarningscontract in the tool definition.Testing
scripts/validate_skills.py✅ (50 skills),scripts/generate_catalog.py✅EMSR-1930
via LD Research 🤖
Note
Overview
Release planning is tied to
match-release-policiesinstead of invented rollouts.flag-releaseandflag-and-release-change(both 0.2.0) require previewing each environment via the tool—proposedflagTagsbefore the flag exists,flagKeyafter—and taking methods, stages, and metrics only from that preview.missing_policy/incomplete_policywarnings are stop signals: surface them and ask how to proceed; do not present a cleanpolicyrollout or assume project defaults.The orchestrator’s plan phase matches that contract (flagTags-only preview, no mutations). Policy matching must re-run when tags or the environment set change (e.g. adding
eu-production).Evals and mocks add promptfoo cases for flagTags preview, refinement re-match, and missing/incomplete policies;
_mock.jsdrives those scenarios by magicprojectKeyvalues; thematch-release-policiestool definition documents thewarningscontract.Reviewed by Cursor Bugbot for commit df66d8b. Bugbot is set up for automated code reviews on this repo. Configure here.