[Research] Backlog locality: repo issue, local packet, or dedicated backlog repo

[StatPan]

Goal

Decide where Gira backlog items should live before they become executable repo-bound tickets.

Context

Current practice can use a dedicated backlog repository such as StatPan/backlog. Gira also has repo-local .gira/config.yaml and workspace config. The PyPI gira project takes a local-first approach where backlog and board state live inside .gira files.

This issue should compare those models and define when each is appropriate.

Reference:

• https://pypi.org/project/gira/
• .gira/config.yaml

Candidate Models

1. Dedicated backlog repository

Backlog ideas live as GitHub issues in a central repo, then get routed to execution repos.

Pros:

• GitHub-native visibility.
• Easy comments, labels, search, and links.
• Good for cross-repo planning.

Cons:

• Extra routing step.
• Backlog can drift from execution repo context.
• May be heavier for quick local notes.

2. Repo-local backlog

Backlog items live in the target repo as GitHub issues or repo-local packet files.

Pros:

• Close to execution context.
• Easier to turn into branch/PR work.

Cons:

• Weak for cross-repo ideas.
• Can clutter execution repos with untriaged ideas.

3. Local .gira backlog packet

Backlog lives in local .gira files until promoted.

Pros:

• Fast capture.
• Works offline.
• Easy for AI/local tools to draft and reorganize.

Cons:

• Weak collaboration unless committed.
• Merge/conflict and source-of-truth questions.
• Not visible in GitHub until promoted.

4. Hybrid

Use StatPan/backlog for durable cross-repo ideas, repo issues for executable work, and .gira packets for temporary local capture/export.

Questions

• What qualifies as backlog vs executable ticket?
• Should Gira support local backlog files at all?
• Should gira ticket new support promotion from backlog repo or local packet?
• Should workspace config define inbox_repo and local inbox paths separately?
• Should backlog routing be part of Gira 2.0 or later?

Acceptance Criteria

• Define backlog, inbox, ticket, and packet terms.
• Decide the recommended default model.
• Decide whether local .gira backlog should exist as a first-class feature.
• Define promotion flows from backlog repo and/or local packet to repo-bound ticket.
• Create follow-up implementation issues if a model is accepted.