Problem: GitHub and Linear APIs return rich metadata (reactions, locked status, estimate points, cycle info) that gets discarded when normalizing to the common Issue type. Users who need this data must bypass isq and call APIs directly, defeating the purpose of the abstraction.
Goal: Preserve raw forge data so consumers can access forge-specific fields when needed.
Success criteria:
- Raw API response stored alongside normalized data (SQLite column or separate table)
isq issue show --json includes optional _raw or forge_data field- Flag to include/exclude raw data (default: exclude for cleaner output)
- Normalized fields remain the primary interface; raw is escape hatch
Context (Rich Hickey's Open Maps): Maps should be open—you can always add keys. Rigid aggregates (closed structs) lose information. Preserve everything, let consumers choose what they need.
Trade-off: Storage size increases. Worth it for infrastructure-layer ambition.
Problem: GitHub and Linear APIs return rich metadata (reactions, locked status, estimate points, cycle info) that gets discarded when normalizing to the common Issue type. Users who need this data must bypass isq and call APIs directly, defeating the purpose of the abstraction.
Goal: Preserve raw forge data so consumers can access forge-specific fields when needed.
Success criteria:
isq issue show --jsonincludes optional_raworforge_datafieldContext (Rich Hickey's Open Maps): Maps should be open—you can always add keys. Rigid aggregates (closed structs) lose information. Preserve everything, let consumers choose what they need.
Trade-off: Storage size increases. Worth it for infrastructure-layer ambition.