specs/004-dashboard-filtering/research.md

Ref: main   Size: 2.1 KiB

# Research: Dashboard Filtering

## R1: `/` Key Availability

**Decision**: `/` is available and unbound in the TUI event loop.
**Rationale**: Verified by reading `run_loop` in `src/tui.rs` — the match statement handles `q`, `c` (ctrl), `1`, `2`, `j`/`k`, `d`, `a`, `g`, `o`, `r`, and arrow/page keys. No `/` handler exists.
**Alternatives considered**: None needed.

## R2: Input Mode Pattern in ratatui

**Decision**: Use a boolean `search_active` flag on `App` to switch between normal and search input handling.
**Rationale**: The TUI already uses a simple match-based event loop. Adding a lightweight mode flag at the top of the key handler is the simplest approach. Full state machine (enum with multiple modes) is overkill since there are only two modes.
**Alternatives considered**: Separate `InputMode` enum — rejected as unnecessary complexity for two states.

## R3: Status Filter Cycling

**Decision**: Replace `show_all: bool` with `StatusFilter` enum cycling Open → All → Closed → Open on `a` key.
**Rationale**: The existing `a` key already toggles between open-only and all. Extending to a three-state cycle is natural. The order Open → All → Closed matches frequency of use (most users want open or all).
**Alternatives considered**: Separate keys for each status — rejected; too many keybindings for a simple filter.

## R4: Case-Insensitive Matching

**Decision**: Use `str::to_lowercase()` for both query and title before calling `contains()`.
**Rationale**: Standard Rust approach, no external dependencies needed. Unicode edge cases (Turkish İ, etc.) are acceptable to ignore for a developer tool.
**Alternatives considered**: Regex — overkill. Fuzzy matching — out of scope per spec.

## R5: Existing `follow_link` and `show_all` Interactions

**Decision**: The `follow_link` method currently sets `self.show_all = true` to reveal linked items across status boundaries. This will be updated to set `self.status_filter = StatusFilter::All` instead.
**Rationale**: Direct mechanical replacement. Same behavior, new type.
**Alternatives considered**: None — straightforward refactor.