Bug Description
Different stateful app implementations in pas/apps/ use inconsistent patterns for state transitions, argument extraction, class definitions, metadata access, and back navigation. This creates maintenance burden and makes it harder to implement new apps consistently.
Steps to Reproduce
- Compare dispatch patterns across apps: contacts uses match statements, email uses isinstance checks, cab uses if/elif chains, note uses dynamic method lookup, messaging uses inline logic
- Compare event args extraction: some apps use
action.resolved_args or action.args, others use action.args or {}, others use getattr(action, "args", {})
- Compare class definition styles: most use regular classes, note uses dataclass, shopping uses custom signature
Expected Behavior
All stateful apps should follow a consistent pattern for:
- State transition dispatch (suggest state-first isinstance for complex apps, match for simple apps)
- Event args extraction (always use
action.resolved_args or action.args)
- Class definition (regular classes, not dataclasses)
- Metadata null checks (always check
event.metadata before accessing return_value)
- Back navigation handling
Actual Behavior
5 different dispatch patterns, 6 different args extraction patterns, mixed class definition styles, and inconsistent null checking across the 9 stateful apps.
Component
Apps
Environment
- OS: macOS 26.3.1
- Python version: 3.12.0
- PAS version/commit: main branch
- Installed via: uv
Minimal Reproducible Example
Relevant Logs
Additional Context
Recommendations:
- Pick one dispatch pattern per complexity level
- Standardize args extraction to
action.resolved_args or action.args
- Standardize class definitions as regular classes
- Always null-check metadata before accessing return_value
- Document chosen patterns for future app implementations
Pre-submission Checklist
Bug Description
Different stateful app implementations in
pas/apps/use inconsistent patterns for state transitions, argument extraction, class definitions, metadata access, and back navigation. This creates maintenance burden and makes it harder to implement new apps consistently.Steps to Reproduce
action.resolved_args or action.args, others useaction.args or {}, others usegetattr(action, "args", {})Expected Behavior
All stateful apps should follow a consistent pattern for:
action.resolved_args or action.args)event.metadatabefore accessingreturn_value)Actual Behavior
Component
Apps
Environment
Minimal Reproducible Example
Relevant Logs
Additional Context
Recommendations:
action.resolved_args or action.argsPre-submission Checklist