h

docs/result_table_selector.md

@@ -5,11 +5,11 @@ and cmdlets to interact via a simple, pipable API.
 
 Key ideas
 - `provider-table` renders a provider result set and *emits* pipeline-friendly dicts for each row. Each emitted item includes `_selection_args`, a list of args the provider suggests for selecting that row (e.g., `['-path', '/tmp/file']`).
-- `select` accepts piped items, displays a table (Rich-based), and supports selecting rows either via `-select` or `-interactive` prompt. Selected items are emitted for downstream cmdlets or you can use `-run-cmd` to invoke another cmdlet for each selected item.
+- Use the `@N` syntax to select an item from a table and chain it to the next cmdlet.
 
-Example (non-interactive):
+Example:
 
-    provider-table -provider example -sample | select -select 1 | add-file -store default
+    provider-table -provider example -sample | @1 | add-file -store default
 
 What providers must implement
 - An adapter that yields `ResultModel` objects (breaking API).
@@ -17,6 +17,6 @@ What providers must implement
 
 Implementation notes
 - `provider-table` emits dicts like `{ 'title': ..., 'path': ..., 'metadata': ..., '_selection_args': [...] }`.
-- `select` will prefer `_selection_args` if present; otherwise it will fall back to provider selection logic or sensible defaults (`-path` or `-title`).
+- Selection syntax (`@1`) will prefer `_selection_args` if present; otherwise it will fall back to provider selection logic or sensible defaults (`-path` or `-title`).
 
 This design keeps the selector-focused UX small and predictable while enabling full cmdlet interoperability via piping and `-run-cmd`.