V3 Approval Rules: Grouping & Draft Status

Server derives Product Discount / Terms / Custom buckets and per-rule draft state on read; writes stay generic.

1. Why this exists

The V3 Approval Rules page previously showed a flat list of workflowSpec.edges. As rule counts grow, admins need to answer "what kind of rule is this?" and "what did the draft change?" without opening each edge. This PR keeps the write model unchanged and pushes both concerns into the read endpoint.

2. Shape of the new response

Before this PR, getApprovalRules returned only workflowSpec, isDraft, and versionInfo. It now adds four fields derived from the same inputs.

{
  workflowSpec,
  isDraft,
  versionInfo
}

{
  workflowSpec,
  isDraft,
  versionInfo,

  // NEW: per-rule draft state
  ruleDraftStatuses,   // Record<id, status>
  deletedDraftRules,   // tombstones

  // NEW: classification
  ruleTypeById,        // Record<id, {type, reason?}>
  approvalRulesByType  // {productDiscount, terms, custom}
}

Data flow on read

3. Draft status derivation

Draft status is computed by comparing the draft edges[] to the published edges[] using a stable JSON canonicalization. There is no persisted status column on rules — it's always derived.

4. Rule classification

Each edge is classified into exactly one bucket. The classifier is deliberately conservative — anything that doesn't match a narrow, safe shape falls through to custom. A reason string explains why.

Term catalog source

5. Classification examples

These are drawn from the test file (getApprovalRules.test.ts) and show the exact shapes that qualify or disqualify a rule.

trigger: { type: 'product' }
routes[0].blocks[0].conditions = [
  { type: 'equals', entity: 'sku',
    key: 'productName',
    value: 'Enterprise SKU' },
  { type: 'gte', entity: 'sku',
    key: 'discountPercent',
    value: 20 },
]

routes[0].blocks[0].conditions = [
  { type: 'equals', entity: 'sku',
    key: 'productName', value: '...' },
  { type: 'gte', entity: 'sku',
    key: 'discountPercent', value: 20 },
  { type: 'between', entity: 'sku',
    key: 'volume', min: 100, max: 500 },
]

trigger: { type: 'term',
           termId: 'paymentTerms' }
conditions = [{
  type: 'in', entity: 'quote',
  key: 'paymentTerms',
  values: ['Net 30', 'Net 60']
}]

trigger: { type: 'term',
           termId: 'billingFrequency' }
conditions = [{
  type: 'equals', entity: 'quote',
  key: 'quoteBillingFrequency', // alias
  value: 'monthly'
}]

6. Client changes

Two files touch the UI. The bigger change is ApprovalRulesView.tsx: a rule-type tab bar sits above the existing Graph/List toggle, and the rules table now renders draft badges and disables interaction on tombstoned rows.

Predicted approval indicators

A one-line change in usePredictedApprovalIndicators.ts propagates isPreview: true into the predicted-approval query when the resolved quote is in preview mode. This lets preview approval evaluation use the draft workflow's rules rather than the published set.

...(resolvedQuote.input.isPreview && { isPreview: true }),

7. What it doesn't change

8. Testing

A new 430-line test file exercises both derivation functions in isolation. The two builders are exported specifically so they can be unit-tested without spinning up a full tRPC context.

9. Risks & open questions