Standardized config_schema for Process Methods

[Sendipad]

Standardized config_schema for Process Methods

Currently, Process Methods in FlexiRule can define their configuration structure inconsistently. This makes validation, UI generation, documentation, and long-term compatibility harder.

This discussion proposes introducing a standardized config_schema contract for all Process Methods, enforced by the engine at registration and execution time.

We've tried to align as closely as possible with Frappe's existing standards for field types and schemas. However, to meet FlexiRule's specific needs—such as dynamic autocompletion—we'll need to introduce new field types like DocField (an autocomplete field where options are fetched from a DocType or context), among others. This will extend Frappe's capabilities while maintaining compatibility where feasible.

Problem

• No single, enforced schema format for Process Method configuration
• Validation logic is duplicated or implicit
• Rule Builder cannot reliably render or validate method configs
• Breaking changes in Process Methods are hard to detect

Proposed Solution

1. Require every Process Method to expose a config_schema attribute
2. Use JSON Schema (draft-07 or later) as the canonical format
3. Enforce schema validation:
   • When syncing methods from code
   • Before execution at runtime
4. Store schema hash/version to detect incompatible changes

Acceptance Criteria

• Engine rejects Process Methods without config_schema
• Invalid rule configuration fails fast with clear error
• Rule Builder can consume schema to render inputs
• Schema changes are detectable (version or hash)
• Backward compatibility strategy is defined

Impact

• Stronger contracts between rule authors and method authors
• Safer runtime execution
• Better UX for Rule Builder
• Clear upgrade path for Process Methods

Notes

This aligns with FlexiRule’s contract-first and fail-fast design principles.