# ✨ Features

Feature ideas and enhancements with stable IDs.

**Size guide** (optional — assign during planning, not triage):
- **small** — a few hours, limited scope
- **medium** — a day or two, new UI or backend logic
- **large** — multi-phase, needs full `/plan:interrogate`

| Status | Meaning |
|--------|---------|
| `open` | Not yet planned |
| `planned` | Pulled into an active feature |
| `shipped` | Completed and deployed |
| `wont-fix` | Intentionally declined |

---

### F-001 — Themed toast notification phrases with random selection
**Status:** open
**Size:** —
**Spec:** —

Create a full inventory of toast notification contexts and populate each with an array of thematic phrases. Toasts should randomly pick from the array for variety. This is foundational for multi-theme support.

Example: Canceling quit might say "Keep at it, gumshoe" or "Back on the case" randomly.

---

### F-002 — LLM theme generator
**Status:** open
**Size:** —
**Spec:** —

Tool to generate theme content (phrases, vocabulary, aliases) via LLM. Could feed into ad-hoc theming where the LLM produces arrays of contextual phrases for a given theme.

---

### F-003 — Mission chain visibility on investigation screen
**Status:** open
**Size:** —
**Spec:** —

Add mission chain title to the investigation/available leads screen so users can follow a chain if they're in the zone. Add a visual indicator (e.g., lock picked emoji or "unlocked" tag) to the most recently unlocked mission(s).

---

### F-004 — Workflow shortcuts and activation improvements
**Status:** open
**Size:** —
**Spec:** —

Multiple workflow friction points:
- From lead board: typing just the number should open that lead (in addition to `investigate 11`)
- From mission brief: add a command like "on the case" to activate the mission without returning to the board
- Consider end-to-end workflow review to reduce meaningless flavor churn
- Auto-activate newly unlocked missions (currently requires separate search and activation step)

---

### F-005 — Revisit mission generation call limits (potential enrichment + cleanup)
**Status:** open
**Size:** —
**Spec:** —

**Context:** The mission generator uses `_MISSIONS_PER_CALL = 3` and `_MAX_CALLS_PER_CATEGORY = 3` limits, capping each category at ~9 missions. These were designed to handle JSON truncation, but:

1. All providers now use `with_structured_output()` via tool calling (see `_NO_TOOL_CALLING_MODELS` is empty in `structured.py`)
2. Structured output enforces schema completion before returning — truncation is much less likely
3. Truncation detection (`detect_truncation`) is still called but primarily benefits the JSON fallback path, which is no longer used

**Potential upsides to removing/relaxing limits:**
- Categories with rich content could generate more missions (enriched experience)
- Currently-tossed missions would become available

**Potential upsides to cleanup:**
- Remove `detect_truncation` and related recovery code if no longer needed
- Simplify `generate_category_missions_multi` logic

**Investigation needed:**
- Check logs to see if truncation is actually being detected in production
- Test with limits removed to verify structured output reliability
- Measure mission count changes across different repo sizes

---

### F-006 — Format security assessment as lists in case file
**Status:** open
**Size:** —
**Spec:** —

The case file (repository briefing) security assessment section currently displays as a block of text, making it hard to pick out the lists within. Should be formatted similarly to the tech stack list in the same document — either markdown or whatever format works best for TUI display.

---

### F-007 — Redesign force-unlock command workflow
**Status:** open
**Size:** —
**Spec:** —

The `force-unlock` command requires the mission's DB ID, which users don't see (they only see the displayed ID on the mission screen). This makes the command unusable in practice.

**Options to consider:**
- List locked missions on the mission screen
- Create a separate screen showing all locked missions
- Accept the displayed mission ID and translate to DB ID internally

---

### F-008 — Skill-based mission scoping
**Status:** open
**Size:** —
**Spec:** —

Missions should be scoped to the user's skill level/familiarity with the language. Currently, senior developers get missions covering very basic conventions that would be appropriate for juniors.

**Ideas:**
- Character creation screen could capture skill level
- Foundation missions (how the pipeline works) should be available to everyone
- Convention-focused missions (import patterns, etc.) should be skill-filtered

---

### F-009 — First-run config file generation
**Status:** open
**Size:** —
**Spec:** —

The default provider and other settings are hardcoded in constants. Initial run should build out a config file, then the app should always read from config.

**Ideas:**
- First run = config file creation wizard
- Re-run config command to update values
- Include instructions for manual config editing

---

### F-010 — Standardize API key environment variable naming
**Status:** open
**Size:** —
**Spec:** —

Different files search for different env var names (e.g., `GLM_API_KEY` vs `ZHIPUAI_API_KEY`). This is confusing.

**Options:**
- Pick one canonical name per provider
- Use generic `LLM_API_KEY` and infer provider from other config
- Document the expected variable name clearly

---

### F-011 — Add `--skip-security` flag to investigate command
**Status:** open
**Size:** small
**Spec:** review_guide.md Section 6

Add a `--skip-security` flag to the `investigate` command that skips the secrets.py and vulnerabilities.py analysis steps.

**Impact:**
- Addresses security perception concern (why is this tool scanning for secrets?)
- Speeds up analysis for users who don't want security scanning
- Files: `cli.py`, `analysis/orchestrator.py`

---

### F-012 — Directory-based fallback clustering for sparse repos
**Status:** open
**Size:** medium
**Spec:** review_guide.md Section 6

For repos with few internal imports, clustering produces many singleton modules. Add a fallback that groups files by directory when import graph is sparse.

**Approach:**
- Files with no import edges get grouped by parent directory
- `backend/handlers/*.py` becomes one module even without imports between them
- Files: `analysis/graph/clustering.py`


---

### F-015 — Add progress bar during initial investigate
**Status:** open
**Size:** —
**Spec:** —

Show a progress bar during the initial investigation phase so users have visual feedback during the potentially long analysis step.

---

### F-016 — Consider pulling brief contents from README
**Status:** open
**Size:** —
**Spec:** —

Consider pulling brief contents more from the README rather than generating it fresh.

**Tradeoff:** Generation could surface an outdated README, which might actually be valuable information.

---

### F-017 — Codebuddy personas based on question type
**Status:** open
**Size:** —
**Spec:** —

Codebuddy personas could be based on what kind of questions you're asking:
- Informant persona for asking questions about the codebase
- Rookie persona for explaining the codebase to it

Gamification modes would be in settings or player configuration, or selectable from menus.

---

### F-018 — Notebook sections as living dossier + TODO
**Status:** open
**Size:** —
**Spec:** —

The gamification notebook sections could be part living dossier of the codebase and part TODO file.

---

### F-019 — Celebrations at mission chain and case completion
**Status:** open
**Size:** —
**Spec:** —

Add celebrations at mission chain completion and case completion. Consider a main outro screen for case completion.

---

### F-020 — Move hardcoded TUI strings to ThemeConfig for full theme isolation
**Status:** open
**Size:** medium
**Spec:** —

Two related gaps from MVP UA testing:

1. **Welcome/error messages use canonical command names** — `on_mount` welcome messages (app.py L150-173), error messages, and content.py hint text hardcode "next", "complete", "status" instead of using `self.router.theme.alias()`.

2. **Hardcoded narrative strings in app.py** — `_close_campaign` summary ("The investigation has concluded." / "Thank you for your service, Detective."), `_handle_notebook` placeholder, `_handle_unlock` error messages with command syntax.

**Fix:** Add `welcome_*`, `close_*`, and `error_*` message templates to `ThemeConfig` or a nested `MessageConfig` class. Pass themed messages from `on_mount` instead of hardcoding. This is foundational for multi-theme support.
