# 🤔 Questions

Open design questions and uncertainties. Questions graduate to features once they have an answer — set status to `shipped` with a note pointing to the new feature entry.

| Status | Meaning |
|--------|---------|
| `open` | Still thinking |
| `planned` | Being addressed in active feature |
| `shipped` | Resolved (see linked feature) |
| `wont-fix` | No longer relevant |

---

### Q-001 — What are the correct accessibility conventions for keyboard navigation?
**Status:** open
**Relates to:** —

During review, arrow keys were requested for navigation, but tabs were never checked. Need to determine: what do users who rely on keyboards/assistive tech actually expect? The app should follow standard conventions, not assumptions about how navigation "should" work.

**Action:** Research standard TUI accessibility patterns (tab order, focus indicators, screen reader considerations).

---

### Q-002 — How can we improve gamification beyond V1.1 requirements?
**Status:** open
**Relates to:** —

V1.1 requirements include writing tests and comments as gamification elements. Looking for more options to enhance engagement and progression.

Even adding checkboxes to "read this file" would be better than what's there now. Though checkboxes by themselves aren't enough either.

**Brainstorm needed:** What other gamification mechanics would be possible and re-themable?

---

### Q-003 — What is the utility of title_plain?
**Status:** open
**Relates to:** B-002

The `title_plain` field exists alongside themed `title`. Is this necessary?

**Potential use case:** Re-theming mid-quest while retaining missions — but is this needed?

**Question:** Does backend logic rely on `title_plain` for anything? If it relies on a title, should it rely on mission ID instead?

---

### Q-005 — How should LLM provider metadata be maintained?
**Status:** open
**Relates to:** —

Hardcoded LLM provider info (defaults, token budgets, tool-calling support) in `llm/providers/factory.py` and elsewhere could become stale.

**Questions:**
- Should this be user-configurable (e.g., token budget)?
- Should it be fetched from a public API at runtime rather than hardcoded?
- Need a deep dive on the entire LLM integration system for vestigial code from repeated pipeline fixes.

---

### Q-006 — Should we add token usage profiling?
**Status:** open
**Relates to:** —

Is there a way to profile how many tokens are used in app runs? Useful to know for different repo sizes, even if not shipped. Could help evaluate token tradeoffs during development and test efficiency of new features.

**Initial thoughts:**
- Would help answer "is this feature worth the token cost?"
- Useful development metric for progress tracking
