feat: clarify state-aware Ex completion scope and cache-backed fallback #314

New issue

Closed

opened 2026-04-18 19:58:59 +00:00 by barrettruth · 1 comment

barrettruth commented

2026-04-18 19:58:59 +00:00

Prerequisites

I have searched existing issues

Problem

State-aware Ex completion is part of the same conditional-action work, but its exact scope is still ambiguous.

The main unresolved points are:

whether the feature applies only to subject completion (for example :Forge pr merge <Tab>) or also to higher-level verb completion
how completion should consult cache-backed data before falling back to backend/CLI queries
how completion should stay aligned with picker action availability so the two surfaces do not drift

The cache-TTL policy itself is tracked separately in #311, but the completion behavior needs its own scope and fallback rules.

Proposed solution

Define the Ex-completion policy for conditional actions.

That should cover at least:

which completion positions are state-aware
which cache(s) are consulted first
when backend fallback is allowed or required
how stale/missing cache entries behave during completion
how the same availability rules are reused between picker actions and Ex completion

The goal is to make completion cache-backed with backend fallback, while keeping the surface predictable and consistent with the picker UI.

Alternatives considered

Leave Ex completion grammar-driven and static
Make completion always shell out to the backend on every request
Use cache-only completion and accept stale or incomplete results

## Prerequisites - [x] I have searched existing issues ## Problem State-aware Ex completion is part of the same conditional-action work, but its exact scope is still ambiguous. The main unresolved points are: - whether the feature applies only to subject completion (for example `:Forge pr merge <Tab>`) or also to higher-level verb completion - how completion should consult cache-backed data before falling back to backend/CLI queries - how completion should stay aligned with picker action availability so the two surfaces do not drift The cache-TTL policy itself is tracked separately in #311, but the completion behavior needs its own scope and fallback rules. ## Proposed solution Define the Ex-completion policy for conditional actions. That should cover at least: - which completion positions are state-aware - which cache(s) are consulted first - when backend fallback is allowed or required - how stale/missing cache entries behave during completion - how the same availability rules are reused between picker actions and Ex completion The goal is to make completion cache-backed with backend fallback, while keeping the surface predictable and consistent with the picker UI. ## Alternatives considered - Leave Ex completion grammar-driven and static - Make completion always shell out to the backend on every request - Use cache-only completion and accept stale or incomplete results

barrettruth commented

2026-04-19 16:42:09 +00:00

Closed by #330, which defines and implements the state-aware Ex completion scope as cache-backed dynamic subject completion with shared availability rules.