Repository navigation
Pins and recipes; queue conditions (manual approval step) #355
Copy link
Copy link
Open
Labels
area:executionCommand execution and lifecycleCommand execution and lifecycletype:featureNew feature or improvementNew feature or improvement
Description
Goal
Allow users to reuse explicit, reviewed commands and sequences, extending NMSh history, command blocks and the same-shell queue (#357) without introducing an independent workflow engine.
Pins
- From a completed command block or history selection, Pin command with optional human-written name/description and original cwd/project context.
- Distinguish session-only, project-specific and global scope only when useful. No automatic pinning, secret parameter extraction, or passive persistence of command output.
- A pin inserts/stages the original command for editing; never auto-runs it.
Recipes
- Users explicitly convert selected ordered command blocks or queue entries into a named, reviewable/editable recipe.
- Support explicit validated placeholders for path/device/other arguments; don't silently reuse environment credentials, unsafe shell interpolation or detected secrets.
- Display expanded commands and cwd/environment expectations before any run. Recipes are never triggered by opening a directory, restoring a session or observing clipboard content.
- Do not silently rewrite shell syntax or “fix” commands.
Queue conditions
- Preserve sequential persistent shell execution and once-only submission.
- Default: stop/pause queue on failure or interruption.
- Optional per-entry condition: after previous success, regardless of previous result, or require manual approval. Expose only when it adds value; a simple queue remains simple.
- Manual approval acts on the exact queued command, with explicit identity and lifetime. No program-driven or output-text-driven auto-approval; no intent inference for destructive commands.
- Work out how saved recipes share the queue model. Pueue (if later integrated under Workflow integrations: evaluate Atuin, fzf/Television, Pueue, Yazi, delta/bat and zoxide #366) handles separate/detached jobs and must not replace same-shell commands.
- Store pins/recipes only on explicit save; minimize scope and explain where data lives. Edited/deleted recipes must not silently change already-running queue entries.
Acceptance
- Clear keyboard-first Pins/Recipes entry points using existing Actions/History/Queue menus; no large permanent panel by default.
- Correct multi-session/project scope, atomic save/delete and migration.
- Placeholder quoting/validation, redaction/secret handling, explicit review and no automatic execution.
- Queue dependency/failure/interrupt/manual approval semantics tested through real zsh/Bash/Fish PTYs, including detach/reattach.
- Narrow/NO_COLOR/Safe/restore coverage; maintain UX documentation and ledger.
Parent: #359; dependencies #357, #358; related staging #354.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area:executionCommand execution and lifecycleCommand execution and lifecycletype:featureNew feature or improvementNew feature or improvement
Activity
raiseCatError commentedon Oct 10, 2026
Implemented in draft on
feature/output-references: queue conditions per entry (win /queue: default, runs even after a failure, asks first;aapproves that exact text; interrupt always stops; gated by a newqueue-conditionsservice feature so older services are never sent them),/pinswith pins and recipes (stored in pins.json, atomic, locked, secrets refused), Pin command block action, recipes saved from the queue with quoted{{placeholders}}, review before queueing. Live PTY tests for conditions (zsh/Bash/Fish) and pins. Not done: pin from history selection, session-only scope, Pueue interplay (#366).