Saved views / smart filters — design choices to confirm before implementing

[hughdbrown]

Background

Add named, persisted queries so humans and agents can ask "what's on my plate" without re-deriving filters every session. The TUI eventually grows them as sidebar tabs; the CLI surfaces them as kata list --view <name>. It's cheap on top of search/list, and it's a natural triage primitive.

I'd like to implement this and file a PR, but several decisions are forward-facing enough that I'd rather get your call before locking them in.

Proposed surface

kata views save mine --status open --owner @me --label bug
kata views list
kata views show mine
kata views delete mine
kata list --view mine

@me resolves to the active actor (--as > KATA_AUTHOR > git > anonymous), so the same view works across humans/agents. --view simply hydrates the saved flags.

Choices that need a call

1. Storage shape

• (a) New saved_views table (proposed) with (project_id, name, filters_json, created_by, created_at) and a unique index on (project_id, name). One migration. Filters stored as JSON so adding a new filter dimension later doesn't need a schema change.
• (b) Reuse events (saved view = special event row). Avoids a migration but conflates audit log with config.

2. Filter language

• (a) No new DSL — bundle of structured flags (proposed). A view is JSON like {\"status\":\"open\",\"labels\":[\"bug\"],\"owner\":\"@me\"}. Easy to validate, easy to render, easy for agents to construct. No parser to maintain.
• (b) String mini-language like owner:me status:open label:bug. Friendlier to type, but adds a parser, escaping rules, and surface area for bugs (precedence, AND vs OR, etc.).

3. List filter dimensions for v1

kata list today only supports --status and --limit. Saved views are most useful when paired with richer filters, so the proposal extends list first.

Proposed v1 filters: status (open/closed/all), labels (repeatable, AND semantics), owner (string, with @me sentinel). Defer for follow-ups: full-text body search, created_after, has_parent, blocked, etc.

Open question: AND or OR semantics for --label foo --label bar? The proposal is AND because it matches GitHub's behavior and is what most people mean by "bugs that are also blocking".

4. Scope

• (a) Per-project (proposed). A view named mine in project A is independent of mine in project B. Matches how every other piece of kata state is scoped.
• (b) Per-user / cross-project. Friendlier for agents that work across projects, but kata doesn't have a user identity model yet (KATA_AUTHOR is advisory).

5. @me resolution

• (a) Resolve at query time (proposed). The view stores \"owner\":\"@me\" literally; kata list --view mine substitutes the current actor when issuing the request. Lets one view follow whoever runs it.
• (b) Resolve at save time. views save stores the actor's literal name. Simpler server-side, but breaks the "works for any agent" property.

6. TUI integration

• (a) Defer to a follow-up issue (proposed). Land the data layer + CLI now; add sidebar tabs / hotkeys later.
• (b) Ship together. More cohesive but doubles the PR size and mixes concerns.

Out of scope for this PR

• Permissions / ownership of saved views (relevant only when the future shared-server mode lands).
• Editing a view in place (kata views edit). For v1, views save is upsert.
• Views over events / search results — only over kata list filters.

What I'd like from you

A 👍/👎 on each numbered item, or just "go with the proposals" / "change X to Y." Once the design is settled I'll open the PR against main from a feat/smart_filters branch.

[mariusvniekerk]

1. a) new table certainly
2. I can go both ways here, json i obviously simple, but the filter language looks like github search filter so value either way. ultimately agents write them both fine. filter language is more human friendly
3. and semantics fits with general expectations here.
4. c) probably worthwhile to support both kinds?
5. a) query time
6. a) easy follow up.