Architectural Change Proposal: Notification Filter Expression System #118

in-op · 2025-11-20T21:14:11Z

in-op
Nov 20, 2025
Maintainer

Executive Summary

This proposal recommends overhauling Imbi's notification filtering system to support complex boolean logic using CEL (Common Expression Language) expressions. The current system uses simple equality checks with implicit OR logic, making it impossible to express common filtering requirements like "main branch AND completed status" or conditional fact routing.

Key Changes:

Add CEL expression support to notification_rules for per-fact filtering
Replace complex notification_filters table entirely
Remove action type system (process/ignore) and precedence rules
Enable single webhook URL to conditionally update multiple facts

Benefits:

Solves inability to express AND/OR boolean logic
Eliminates need for duplicate webhook registrations
Simplifies mental model with rule-level filtering only
Human-readable filter syntax
Industry-standard expression language

Problem Statement

Current Architecture Limitations

The existing notification filter system has fundamental design constraints that prevent common use cases:

1. Cannot Express Boolean AND Logic

Problem: Each filter is evaluated independently with implicit OR semantics. There's no way to require multiple conditions to be true simultaneously.

Example: "Only process workflow runs on main branch that are completed"

-- Current system: CANNOT express this correctly
INSERT INTO notification_filters VALUES
  ('main-branch', 'github', 'workflow-status', '/workflow_run/head_branch', '==', 'main', 'process'),
  ('completed', 'github', 'workflow-status', '/action', '==', 'completed', 'process');

-- Result with default='process': Processes if branch=main OR action=completed (not AND!)
-- Result with default='ignore': Still processes if branch=main OR action=completed (still OR!)

No workaround exists: The system always ORs filters of the same action type together. You cannot express AND logic.

2. Cannot Route Different Facts from Same Webhook

Problem: Filters apply at notification level, affecting ALL rules. To filter differently for different facts, you must register the webhook multiple times at different URLs.

Example: GitHub workflow status webhooks contain data for both build and deploy facts, but each should only update on specific workflows:

-- Current system: Must create TWO separate notifications
-- Notification 1: workflow-build
INSERT INTO notification_filters VALUES
  ('build-only', 'github', 'workflow-build', '/workflow_run/name', '==', 'build', 'process');
INSERT INTO notification_rules VALUES
  (build_status_id, 'github', 'workflow-build', '/workflow_run/conclusion');

-- Notification 2: workflow-deploy
INSERT INTO notification_filters VALUES
  ('deploy-only', 'github', 'workflow-deploy', '/workflow_run/name', '==', 'deploy', 'process');
INSERT INTO notification_rules VALUES
  (deploy_status_id, 'github', 'workflow-deploy', '/workflow_run/conclusion');

-- Result: GitHub sends webhook to BOTH URLs, duplicate processing!

Impact:

Double the webhook traffic
Double the database queries (project lookups)
Double the OpenSearch updates
More complex GitHub webhook configuration

3. Action Type Precedence Creates Confusion

Problem: The action field (process vs ignore) with implicit precedence rules (ignore always wins) creates counterintuitive behavior.

Example: With default_action='process':

INSERT INTO notification_filters VALUES
  ('main-branch', 'github', 'workflow-status', '/workflow_run/head_branch', '==', 'main', 'process'),
  ('not-draft', 'github', 'workflow-status', '/workflow_run/draft', '==', 'true', 'ignore');

Behavior:

Feature branch, not draft → PROCESSES (no filters match, uses default)
Main branch, draft → IGNORES (ignore wins over process)
Feature branch, draft → IGNORES (ignore matches)

Issue: The action='process' filter on main branch is effectively meaningless with default='process'—it would process anyway! Users expect it to mean "only process main" but it doesn't enforce that.

4. Limited Operations

Problem: Only supports == and != operations.

Cannot Express:

Numeric comparisons: "exit_code > 0"
String operations: "branch starts with 'release/'"
List membership: "workflow in ['build', 'deploy', 'test']"
Field existence: "has conclusion field"
Complex negation: "NOT (draft OR archived)"

5. No Complex Nested Logic

Problem: Cannot express "(A AND B) OR (C AND D)" type logic.

Example: "Process if (production deploy) OR (any release to staging)"

(environment == "production" AND workflow == "deploy")
  OR
(environment == "staging" AND branch startsWith "release/")

This is impossible with the current system.

Current System Architecture

Database Schema

-- notification_filters: Accept/reject filters at notification level
CREATE TABLE notification_filters (
  filter_name TEXT NOT NULL,
  integration_name TEXT NOT NULL,
  notification_name TEXT NOT NULL,
  pattern TEXT NOT NULL,              -- JSON pointer
  operation notification_filter_operation_type NOT NULL,  -- Only '==' or '!='
  value TEXT NOT NULL,
  action notification_action_type NOT NULL,  -- 'ignore' or 'process'
  PRIMARY KEY (filter_name, integration_name, notification_name)
);

-- notification_rules: Fact update rules at notification level
CREATE TABLE notification_rules (
  fact_type_id INTEGER NOT NULL,
  integration_name TEXT NOT NULL,
  notification_name TEXT NOT NULL,
  pattern TEXT NOT NULL,              -- JSON pointer for extraction
  PRIMARY KEY (fact_type_id, integration_name, notification_name)
);

Processing Flow

def _process_notification(self, integration_name, notification_name, body):
    # 1. Evaluate ALL notification-level filters
    if not self._evaluate_filters(self._notification, body):
        return  # Early exit - blocks ALL rules

    # 2. If passed, process ALL rules for this notification
    for project in await self._get_projects(self._notification, body):
        updates = {}
        for rule in notification.rules:  # No per-rule filtering!
            value = rule.pattern.resolve(body, unspecified)
            if value is not unspecified:
                updates[rule.fact_type_id] = value

        if updates:
            await self._update_facts(project, updates)

Filter Evaluation Logic

def _evaluate_filters(self, notification, body) -> bool:
    matches = []
    for filter in notification.filters:
        value = filter.pattern.resolve(body, unspecified)
        if value is not unspecified:
            if (value == filter.value and filter.operation == '==') or \
               (value != filter.value and filter.operation == '!='):
                matches.append((filter, value))

    # Separate by action type
    ignores = [f for f, v in matches if f.action == 'ignore']
    process = [f for f, v in matches if f.action == 'process']

    # Precedence: ignore always wins
    if ignores:
        return False
    elif process:
        return True
    else:
        # No matches - use default
        return notification.default_action == 'process'

Key Issues:

Filters are evaluated independently (implicit OR within same action type)
Ignore action beats process action (hard-coded precedence)
No AND logic possible
All-or-nothing: filters block entire notification or allow all rules

Proposed Solution

High-Level Design

Replace the multi-filter system with rule-level CEL (Common Expression Language) expressions:

Rule Filters (rule-level): Optional expression per rule determining if that specific fact should be updated

Key Principles:

Expressions are boolean: TRUE = pass, FALSE = skip
CEL provides human-readable syntax with full boolean logic
Each rule independently decides if it should fire
No action types, no precedence rules, no implicit OR behavior

Database Schema Changes

-- Drop old complex system
DROP TABLE notification_filters;
DROP TYPE notification_action_type;
DROP TYPE notification_filter_operation_type;

-- Add rule-level filtering
ALTER TABLE notification_rules
ADD COLUMN filter_expression TEXT;  -- Optional CEL expression

COMMENT ON COLUMN notification_rules.filter_expression IS
  'Optional CEL expression that must evaluate to true for this rule to apply.';

CEL Expression Examples

CEL (Common Expression Language) is an industry-standard expression language used by Google Cloud, Kubernetes, Firebase, and others. It provides familiar syntax similar to Python/JavaScript.

Basic comparisons:

// Equality
workflow_run.head_branch == "main"
action != "ping"

// Numeric
workflow_run.exit_code > 0
workflow_run.duration >= 300

// Boolean
workflow_run.draft == false
!workflow_run.archived

Boolean logic:

// AND
workflow_run.head_branch == "main" && action == "completed"

// OR
workflow_run.name == "deploy" || workflow_run.name == "release"

// Complex
workflow_run.head_branch == "main"
  && action == "completed"
  && !workflow_run.draft

List operations:

// Membership
workflow_run.name in ["build", "deploy", "test"]
action in ["completed", "success"]

// Any/All
workflow_run.labels.exists(l, l == "production")

String operations:

// Prefix/suffix
workflow_run.head_branch.startsWith("release/")
workflow_run.name.endsWith("-prod")

// Contains
workflow_run.message.contains("breaking change")

Field existence and conditionals:

// Check if field exists
has(workflow_run.conclusion)

// Null checking
workflow_run.error == null

// Ternary operator for optional fields
has(workflow_run.environment) ? workflow_run.environment == "production" : false

Complex nested logic:

// (A AND B) OR (C AND D)
(workflow_run.environment == "production" && action == "deploy")
  || (workflow_run.environment == "staging" && workflow_run.head_branch.startsWith("release/"))

Processing Flow (New)

async def _process_notification(self, integration_name, notification_name, body):
    # 1. Process each rule independently
    for project in await self._get_projects(self._notification, body):
        updates = {}

        for rule in self._notification.rules:
            # 2. Rule-level filter (optional) - routing logic
            if rule.filter_expression:
                if not evaluate_cel(rule.filter_expression, body):
                    self.logger.debug('rule %s filtered out', rule.fact_type_id)
                    continue  # Skip this specific rule

            # 3. Extract and transform value
            value = rule.pattern.resolve(body, unspecified)
            if value is not unspecified:
                transformed_value = value
                for transformation in rule.transformations:
                    if str(value) == transformation.input_value:
                        transformed_value = transformation.output_value
                        break
                updates[rule.fact_type_id] = transformed_value

        # 4. Apply updates
        if updates:
            await self._update_facts(project, updates)

Python Implementation

import celpy

def evaluate_cel(expression: str, data: dict) -> bool:
    """Evaluate CEL expression against webhook data."""
    try:
        env = celpy.Environment()
        ast = env.compile(expression)
        program = env.program(ast)
        result = program.evaluate(data)
        return bool(result)

    except celpy.CELEvalError as error:
        LOGGER.error('CEL evaluation error: %s in expression: %s',
                     error, expression)
        return False  # Fail safe - don't process on error

    except Exception as error:
        LOGGER.error('Unexpected error evaluating CEL: %s', error)
        return False

Dependencies:

pip install cel-python>=0.4.0,<0.5.0

Solution to Original Problems

1. Boolean AND Logic ✅

Before (impossible):

-- Cannot express "main AND completed"

After:

-- Rule filter: only update fact for main branch completed runs
INSERT INTO notification_rules VALUES
  (fact_type_id, 'github', 'workflow-status',
   '/workflow_run/conclusion',
   'workflow_run.head_branch == "main" && action == "completed"');

2. Conditional Fact Routing ✅

Before (requires 2 notifications):

-- Two separate notifications, two webhook URLs
notification: workflow-build  → updates build_status fact
notification: workflow-deploy → updates deploy_status fact

After (single notification):

-- One notification, one webhook URL
INSERT INTO integration_notifications VALUES
  ('github', 'workflow-status');

-- Rules with independent filters
INSERT INTO notification_rules VALUES
  (build_status_id, 'github', 'workflow-status',
   '/workflow_run/conclusion',
   'workflow_run.name == "build" && action == "completed" && workflow_run.head_branch == "main"'),

  (deploy_status_id, 'github', 'workflow-status',
   '/workflow_run/conclusion',
   'workflow_run.name == "deploy" && action == "completed" && workflow_run.head_branch == "main"');

-- Result: Single webhook processes both facts conditionally!

3. No More Action Precedence Confusion ✅

Before:

-- Complex interaction between action types and default_action
-- Confusing precedence rules (ignore beats process)

After:

-- Simple boolean expressions, no action types
-- If expression is TRUE, process; if FALSE, skip
-- Clear and predictable

4. Rich Operations ✅

Before (only == and !=):

operation: '==' or '!='

After (full CEL operators):

// Numeric
exit_code > 0
duration >= 300

// String
branch.startsWith("release/")
message.contains("BREAKING")

// Lists
name in ["build", "deploy", "test"]

// Existence
has(conclusion)

5. Complex Nested Logic ✅

Before (impossible):

-- Cannot express (A AND B) OR (C AND D)

After:

// Arbitrary boolean nesting
(environment == "production" && workflow == "deploy")
  || (environment == "staging" && branch.startsWith("release/"))

Alternative Approaches Considered

Alternative 1: JSONLogic Expression Trees

Description: Use JSONLogic specification for structured JSON boolean expressions.

Example:

{
  "and": [
    {"==": [{"var": "workflow_run.head_branch"}, "main"]},
    {"==": [{"var": "action"}, "completed"]}
  ]
}

Pros:

Structured (can validate schema)
Standard specification
Easy to build UI for

Cons:

Not human-readable in raw form
Verbose for simple cases
Requires JSON editor or UI builder
Less intuitive for developers

Verdict: REJECTED - Poor developer experience for hand-editing. CEL is more readable.

Alternative 2: Extended Filter Groups (Backward Compatible)

Description: Keep existing filter system, add grouping table with AND/OR operators.

Schema:

CREATE TABLE notification_filter_groups (
  group_id UUID PRIMARY KEY,
  integration_name TEXT,
  notification_name TEXT,
  operator TEXT CHECK (operator IN ('AND', 'OR')),
  action notification_action_type
);

ALTER TABLE notification_filters
ADD COLUMN group_id UUID REFERENCES notification_filter_groups;

Example:

-- Group 1: Main AND completed
INSERT INTO notification_filter_groups VALUES
  ('550e8400-...', 'github', 'workflow-status', 'AND', 'process');
INSERT INTO notification_filters VALUES
  ('main', 'github', 'workflow-status', '550e8400-...', '/branch', '==', 'main'),
  ('completed', 'github', 'workflow-status', '550e8400-...', '/action', '==', 'completed');

Pros:

Backward compatible (existing filters work)
Incremental migration
Reuses existing concepts

Cons:

Still limited to == and !=
Cannot express nested logic ((A AND B) OR (C AND D))
Complex data model (multiple tables)
Only one level of grouping
Still has action precedence issues
Doesn't solve per-rule filtering

Verdict: REJECTED - Adds complexity without fully solving problems. Half-measure.

Alternative 3: SQL WHERE Clause Syntax

Description: Use SQL-like WHERE clause syntax for filters.

Example:

WHERE workflow_run.head_branch = 'main'
  AND action = 'completed'
  AND workflow_run.name IN ('build', 'deploy')

Pros:

Familiar to SQL developers
Powerful query syntax
Rich operators

Cons:

Security risk (SQL injection concerns, even with parameterization)
Requires SQL parser
Not a standard for expression evaluation
Overkill (we're not querying tables)

Verdict: REJECTED - Security concerns, not designed for this use case.

Alternative 4: Python/JavaScript Expression Evaluation

Description: Allow arbitrary Python or JavaScript code execution.

Example:

data['workflow_run']['head_branch'] == 'main' and data['action'] == 'completed'

Pros:

Maximum flexibility
Familiar syntax

Cons:

CRITICAL SECURITY RISK - Code injection vulnerabilities
Difficult to sandbox safely
Performance overhead
Hard to validate
Error-prone (typos cause runtime errors)

Verdict: REJECTED - Unacceptable security risk.

Alternative 5: Keep Current System, Document Limitations

Description: Do nothing, document workarounds.

Workarounds:

For AND logic: use default_action='ignore' with multiple process filters
For routing: create multiple notifications
For complex logic: handle in webhook sender or use intermediary service

Pros:

No development effort
No migration needed
No breaking changes

Cons:

Problems remain unsolved
Poor developer experience
Inefficient (duplicate webhooks)
Confusion persists
Limits future integrations

Verdict: REJECTED - Doesn't address fundamental architectural limitations.

Why CEL is the Right Choice

Industry Adoption:

Google Cloud (IAM policies, Firestore rules, Cloud Armor)
Kubernetes (ValidatingAdmissionPolicy, CEL-based validation)
Firebase Security Rules
Istio (authorization policies)
Envoy proxy

Language Features:

Standard specification (well-documented)
Type-safe evaluation
Sandboxed execution (no code injection)
Cross-language (implementations in Go, Java, Python, Rust, C++)

Developer Experience:

Human-readable syntax
Familiar operators (like Python/JS/Java)
Clear error messages
Easy to test expressions independently
No special tooling required (just text editor)

Python Library:

# Installation
pip install cel-python>=0.4.0,<0.5.0

# Usage
import celpy
env = celpy.Environment()
ast = env.compile('name == "deploy" && status == "success"')
program = env.program(ast)
result = program.evaluate({"name": "deploy", "status": "success"})  # True

Migration Strategy

Phase 1: Add CEL Expression Support (Non-Breaking)

Goal: Add CEL expression support to rules while maintaining backward compatibility with existing filters.

Changes:

-- Add rule-level filtering
ALTER TABLE notification_rules
ADD COLUMN filter_expression TEXT;

COMMENT ON COLUMN notification_rules.filter_expression IS
  'Optional CEL expression that must evaluate to true for this rule to apply.';

-- Mark old table as deprecated (don't drop yet)
COMMENT ON TABLE notification_filters IS
  'DEPRECATED: Use filter_expression on notification_rules instead. Will be removed in future version.';

Processing logic:

async def _process_notification(self, integration_name, notification_name, body):
    # Check old filters for backward compatibility
    if self._notification.filters:  # Old system
        if not self._evaluate_filters(self._notification, body):
            return

    # Process rules with optional rule-level filters
    for project in await self._get_projects(self._notification, body):
        updates = {}
        for rule in self._notification.rules:
            # Check rule-level filter if present
            if rule.filter_expression:
                if not evaluate_cel(rule.filter_expression, body):
                    continue

            # ... existing extraction and transformation logic

Impact:

Existing notifications and rules work unchanged
New rules can use CEL expressions for conditional updates
Solves conditional fact routing immediately
Both systems run in parallel during transition

Manual Migration:
Convert existing notification filters to CEL expressions on rules.

Phase 2: Remove Old System (Breaking)

Goal: Remove deprecated notification_filters table after all filters migrated to CEL.

Prerequisites:

All existing filters converted to CEL expressions
Documentation updated

Changes:

-- Drop old table
DROP TABLE notification_filters;

-- Drop deprecated types
DROP TYPE notification_action_type;
DROP TYPE notification_filter_operation_type;

-- Remove default_action (no longer needed)
ALTER TABLE integration_notifications
DROP COLUMN default_action;

Concrete Examples

Example 1: GitHub Workflow Status

Scenario: Update build and deploy facts from single workflow_run webhook.

Webhook payload:

{
  "action": "completed",
  "workflow_run": {
    "name": "CI/CD Pipeline",
    "head_branch": "main",
    "conclusion": "success",
    "jobs": [
      {"name": "build", "conclusion": "success"},
      {"name": "deploy", "conclusion": "success"}
    ]
  }
}

Configuration:

-- Notification: single webhook endpoint
INSERT INTO integration_notifications VALUES
  ('github', 'workflow-status');

-- Rule 1: Update build_status only for build jobs on main
INSERT INTO notification_rules VALUES
  (build_status_id, 'github', 'workflow-status',
   '/workflow_run/jobs/0/conclusion',
   'workflow_run.jobs.exists(j, j.name == "build") && workflow_run.head_branch == "main" && action == "completed"');

-- Rule 2: Update deploy_status only for deploy jobs on main
INSERT INTO notification_rules VALUES
  (deploy_status_id, 'github', 'workflow-status',
   '/workflow_run/jobs/1/conclusion',
   'workflow_run.jobs.exists(j, j.name == "deploy") && workflow_run.head_branch == "main" && action == "completed"');

Result: Single webhook conditionally updates both facts based on job presence and branch.

Example 2: Ignore Non-Production Deploys

Scenario: Only update deploy facts for production deployments, ignore staging/dev.

Configuration:

-- Notification
INSERT INTO integration_notifications VALUES
  ('github', 'deployment');

-- Rule: extract deploy status only for production
INSERT INTO notification_rules VALUES
  (deploy_status_id, 'github', 'deployment',
   '/deployment/status',
   'deployment.environment == "production"');

Example 3: Complex Multi-Condition Routing

Scenario: Update different facts based on complex conditions:

test_coverage: Any test workflow on main, completed
deploy_status: Only deploy workflows to production, completed
build_time: Any build on any branch (for metrics)

Configuration:

-- Notification
INSERT INTO integration_notifications VALUES
  ('github', 'workflow-status');

-- Rule 1: Test coverage
INSERT INTO notification_rules VALUES
  (test_coverage_id, 'github', 'workflow-status',
   '/workflow_run/coverage_percent',
   'workflow_run.name.contains("test") && workflow_run.head_branch == "main" && action == "completed"');

-- Rule 2: Deploy status
INSERT INTO notification_rules VALUES
  (deploy_status_id, 'github', 'workflow-status',
   '/workflow_run/conclusion',
   'workflow_run.name == "deploy" && workflow_run.environment == "production" && action == "completed"');

-- Rule 3: Build time (any branch)
INSERT INTO notification_rules VALUES
  (build_time_id, 'github', 'workflow-status',
   '/workflow_run/duration_ms',
   'workflow_run.name.contains("build") && action == "completed"');

Example 4: Common Preconditions in Multiple Rules

Scenario: Common precondition (must be completed, not draft) + specific routing per fact.

Configuration:

-- Notification
INSERT INTO integration_notifications VALUES
  ('github', 'workflow-status');

-- Rule 1: Build status (only build workflow on main, completed, not draft)
INSERT INTO notification_rules VALUES
  (build_status_id, 'github', 'workflow-status',
   '/workflow_run/conclusion',
   'action == "completed" && !workflow_run.draft && workflow_run.name == "build" && workflow_run.head_branch == "main"');

-- Rule 2: Deploy status (only deploy workflow to production, completed, not draft)
INSERT INTO notification_rules VALUES
  (deploy_status_id, 'github', 'workflow-status',
   '/workflow_run/conclusion',
   'action == "completed" && !workflow_run.draft && workflow_run.name == "deploy" && workflow_run.environment == "production"');

Result: Each rule includes common preconditions (completed, not draft) combined with rule-specific routing logic.

Trade-offs and Risks

Trade-offs

Aspect	Current System	Proposed System
Simplicity	Very simple (equality checks only)	More complex (expression evaluation)
Expressiveness	Limited (only == and !=)	Unlimited (full boolean logic)
Performance	Fast (simple comparisons)	Slightly slower (expression parsing/eval)
Debuggability	Easy to trace	Requires testing expressions
Learning Curve	Minimal	Requires learning CEL syntax
Flexibility	Cannot handle complex cases	Handles any boolean logic

Risks

Risk 1: CEL Expression Errors

Impact: Filter fails to evaluate, webhook incorrectly processed/ignored
Mitigation:
- Strict validation on expression save (compile to check syntax)
- Fail-safe: On error, log and skip rule (don't block notification)
- Comprehensive error logging

Risk 2: Performance Degradation

Impact: CEL evaluation slower than simple equality checks
Mitigation:
- Rule filters allow skipping unnecessary fact updates
- CEL is sandboxed and efficient for expression evaluation

Risk 3: Security - Expression Injection

Impact: Malicious expressions could cause DoS or data leakage
Mitigation:
- CEL is sandboxed (cannot execute arbitrary code)
- Admin-only permission to create/modify filters
- Audit logging of filter changes

References

CEL Specification
CEL Python Library (celpy)
CEL Language Definition
Common Expression Language Guide
Imbi notification processing: api/imbi/endpoints/integrations/notifications/processing.py

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Architectural Change Proposal: Notification Filter Expression System #118

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Architectural Change Proposal: Notification Filter Expression System #118

Uh oh!

in-op Nov 20, 2025 Maintainer

Executive Summary

Problem Statement

Current Architecture Limitations

1. Cannot Express Boolean AND Logic

2. Cannot Route Different Facts from Same Webhook

3. Action Type Precedence Creates Confusion

4. Limited Operations

5. No Complex Nested Logic

Current System Architecture

Database Schema

Processing Flow

Filter Evaluation Logic

Proposed Solution

High-Level Design

Database Schema Changes

CEL Expression Examples

Processing Flow (New)

Python Implementation

Solution to Original Problems

1. Boolean AND Logic ✅

2. Conditional Fact Routing ✅

3. No More Action Precedence Confusion ✅

4. Rich Operations ✅

5. Complex Nested Logic ✅

Alternative Approaches Considered

Alternative 1: JSONLogic Expression Trees

Alternative 2: Extended Filter Groups (Backward Compatible)

Alternative 3: SQL WHERE Clause Syntax

Alternative 4: Python/JavaScript Expression Evaluation

Alternative 5: Keep Current System, Document Limitations

Why CEL is the Right Choice

Migration Strategy

Phase 1: Add CEL Expression Support (Non-Breaking)

Phase 2: Remove Old System (Breaking)

Concrete Examples

Example 1: GitHub Workflow Status

Example 2: Ignore Non-Production Deploys

Example 3: Complex Multi-Condition Routing

Example 4: Common Preconditions in Multiple Rules

Trade-offs and Risks

Trade-offs

Risks

References

Replies: 0 comments

in-op
Nov 20, 2025
Maintainer