3 months ago
6e104ad
deleting a custom rule that a workflow references leaves the workflow pointing
at a rule that no longer exists. rather than handle that broken state, make it
unreachable.
- server guard (the correctness fix), at the lowest shared point so no caller
can bypass it: repoServices.deleteCustomRule refuses while ANY workflow —
enabled OR disabled — references the rule, returning { deleted, blockedBy }.
a disabled workflow blocks too: it breaks the moment it is re-enabled.
- workflowsReferencingRule scans every workflow definition for the repo (not
resolveRuleManagement, which is enabled-only). the match is a pure contracts
helper, definitionReferencesRule (version-agnostic), shared by the guard.
- the web fn names the blocking workflows: "this rule is active inside X and Y.
remove it from those workflows before deleting." flows through the existing
toast, no new pattern.
- the card keeps the delete control visible but DISABLED when referenced, with
the blocking workflows named as links (the shipped edit-in-workflow pattern).
a missing button reads as a bug; a disabled one with a reason reads intended.
- the escape hatch works: remove the last reference, deletion succeeds.
no pending/invalid-node/broken-workflow state — those become unreachable. the
workflow model, rule model, and evaluator are untouched.
tests: refused by an enabled workflow, refused by a DISABLED one, names every
workflow, allowed once the last reference is removed (integration, real pg);
plus a pure unit test for definitionReferencesRule.Parentf32fad5