Replace JavaScript-based question visibility logic with declarative format for security and portability

[yibeichan]

@claude reformatted @alistairewj's feedback as the following

Problem Description

The current implementation uses JavaScript calls to control question visibility in the UI, which presents several significant issues:

1. Security Risk: Executing unvalidated JavaScript poses a major security vulnerability
2. Platform Limitations: Requires a JavaScript runtime, making it incompatible with non-JS frameworks (e.g., Flutter)
3. Anti-pattern: Mixes code and data, violating separation of concerns

Proposed Solution

Adopt a declarative format similar to FHIR's enableWhen functionality, which uses JSON-based conditions rather than executable code.

Action Items

• Research and document FHIR's enableWhen specification as a reference implementation
• Design a declarative JSON schema for expressing conditional visibility logic
• Create a migration plan for existing JavaScript-based visibility rules
• Implement parser/evaluator for the new declarative format
• Update documentation with the new format specification and examples
• Provide migration tools or scripts to convert existing JavaScript logic to the new format
• Add comprehensive test coverage for the new visibility system
• Deprecate JavaScript-based visibility with clear timeline and migration guide

Additional Considerations

• Ensure backward compatibility during transition period
• Consider performance implications of the new approach
• Validate that all existing use cases can be expressed in the declarative format

Example

Current approach (problematic):

visibility: "return responseData.age >= 18"

Proposed approach (declarative):

"enableWhen": [{
  "question": "age",
  "operator": ">=",
  "answerInteger": 18
}]

[satra]

don't think the flow injects a vulnerability (since there isn't a malicious party coopting the injection - unless the browser is broken - which would be terrible).

however, changing the way we do this makes sense.