Goal
Evaluate and design export UX for Gira reports, tickets, workspace status, and future hosted/dashboard consumers.
Context
The PyPI gira package exposes export-oriented UX such as JSON, CSV, and Markdown output. Gira already has --json paths and Closure Funnel report direction, but export should be designed as a product surface rather than only a flag-by-flag convenience.
Sources:
Candidate Commands
gira export repo --format json|md
gira export workspace --format json|md
gira stats repo --format csv|json|md
gira ticket export TICKET --format json|md
gira finish receipt export --format json|md
Design Questions
- Which exports are stable contracts vs human convenience output?
- Should export commands write files by default, print to stdout, or support both?
- Where should default output live when writing files?
- Should exported artifacts include source timestamps and freshness metadata?
- Should exports be grouped under
gira export or remain attached to existing commands?
Non-goals
- Do not introduce a separate planning database.
- Do not make export output the source of truth.
- Do not start with a hosted dashboard requirement.
Acceptance Criteria
Goal
Evaluate and design export UX for Gira reports, tickets, workspace status, and future hosted/dashboard consumers.
Context
The PyPI
girapackage exposes export-oriented UX such as JSON, CSV, and Markdown output. Gira already has--jsonpaths and Closure Funnel report direction, but export should be designed as a product surface rather than only a flag-by-flag convenience.Sources:
Candidate Commands
gira export repo --format json|mdgira export workspace --format json|mdgira stats repo --format csv|json|mdgira ticket export TICKET --format json|mdgira finish receipt export --format json|mdDesign Questions
gira exportor remain attached to existing commands?Non-goals
Acceptance Criteria