12‑Week MVP Tasks

[ElianThorne]

Build the foundation first: execution core and essential builtins, then make scripts work (globs, expansions, redirections, job control), then polish the interactive experience and add safe extensibility. Do the hard compatibility work early, UX and plugins don’t matter if real scripts don’t run.

Tasks:

1. Basic command parser + executor

   • Minimal parsing for commands, arguments, pipelines, simple redirections; fork/exec to run external commands.
   • Why: core that everything else depends on.

2. Core builtins: cd, pwd, exit, export, unset, echo, test

   • Implement builtin semantics that affect environment and child processes.
   • Why: essential for script compatibility.

3. REPL integration with line editor (reedline/rustyline) and history

   • Interactive prompt, history persistence.
   • Why: usable shell for humans and testers.

4. GitHub Actions CI + benchmark harness

   • Run tests and record startup/script benchmarks.
   • Why: detect regressions and measure progress.

5. Pathname expansion (globset)

   • Wildcards, ?, character classes; match common bash patterns.
   • Why: many scripts break on incorrect globbing.

6. Quoting and basic parameter expansion

   • Single/double quote semantics, $VAR expansion, word splitting.
   • Why: correct expansion order is critical.

7. Microbench: cold/warm startup, script runtime, memory

   • Criterion or custom harness; CI reporting.
   • Why: performance goals need measurement.

8. Command substitution and arithmetic expansion

   • $(...), backticks, $((...)).
   • Why: common scripting idioms.

9. Here-docs and file-descriptor redirections

   • <<, <<-, 2>, &>, >& etc.
   • Why: widely used in real scripts/installers.

10. Process groups, job control, signal handling; jobs/fg/bg

    • setpgid, tcsetpgrp, forward signals to foreground jobs.
    • Why: interactive job control must behave predictably.

11. POSIX sh test harness and curated scripts

    • Runner under tests/posix/ comparing outputs or against bash.
    • Why: objective compatibility metrics.

12. Async completion hooks + fuzzy ranking

    • Non-blocking completion API and ranked suggestions.
    • Why: makes the interactive experience responsive.

13. Syntax highlighting for input

    • Lightweight highlighting in the prompt.
    • Why: reduces typing errors and improves clarity.

14. WASM plugin host prototype (wasmtime)

    • Plugin API and example plugin (completions or small builtin).
    • Why: safe, portable extensibility.

15. Packaging, quickstart, and migration guide

    • Install instructions, Quickstart, compatibility notes vs bash/nushell.
    • Why: lowers friction for adopters.

16. Release checklist (MVP)

    • CI passing, compatibility target, packaging artifacts, release notes.
    • Why: coordinate and publish the MVP.

First make scripts run correctly and reliably. Then fix interactive niceties and plugins. Measure everything with CI and benchmarks so changes are verifiable. Assign tasks, open the issues, and stop polishing UI before the compatibility work is done.

Do not reimplement functionality that mature crates already provide. Adopt reedline for the REPL (history, keybindings, vi/emacs modes, async completion hooks), globset for pathname expansion, nix for POSIX process/group control and signal handling, and a WASM runtime (wasmtime/wasmer) for sandboxed plugins. Reusing these components reduces bugs, speeds development, and leads to focus on POSIX compatibility, reliable job control, and performance

[exlier]

Extra tasks:

• Replace the REPL with reedline (low risk, high payoff: history, completion, unicode). PR Feat/reedline repl #102
• Swap in shlex/shell-words for tokenization (reduces parser complexity quickly). PR Swap tokenization to shlex; add globset and shellexpand #103
• Add globset and shellexpand for globbing/expansion. PR Swap tokenization to shlex; add globset and shellexpand #103
• Introduce portable-pty for PTY-backed jobs and wire job_control.rs to it (important for interactive programs). PR Feat/pty ppk #104
• Harden wasm_host (you already use wasmtime) and define binary plugin API + examples.
• Add assert_cmd + predicates tests to tests/ for CI.

Also, Consider using nom/pest to refactor the remaining parser pieces, or gradually port features from parser.rs into smaller, tested parser modules.