xff v0.3.7

xff - Implementation Plan

Companion to design.md. design.md is the source of truth for what / why (decisions); this plan owns how / in what order (build, modules, sequencing). Decisions are referenced here, not re-argued.
Status: Draft · 2026-06-07 · Org: MBO Works · License: Apache-2.0
Design review #1–#13 complete and incorporated (see design.md §Notes/Decisions); the module seams and phasing below reflect every resolved decision.

Toolchain

Repository layout (Bazel packages)

xff/
  MODULE.bazel  .bazelrc  .bazelversion  .github/workflows/
  docs/        design.md  implementation-plan.md  test-plan.md
  xff/
    registry/  # SoT: option/predicate/action descriptors + resolved Query/settings model
    parser/    # argv -> AST (left scanner + recursive-descent); parse-only
    config/    # config files + cascade -> settings (uses registry)
    vfs/       # source abstraction + local backend (archive/remote later)
    regex/     # engine abstraction (RE2/PCRE2 + literal prefilter)
    engine/    # AST + settings + VFS -> match stream + actions; parallel; cost-warning
    stats/     # aggregation over the match stream
    render/    # result/stat model -> output formats
    cli/       # the `xff` binary (thin wiring; owns exit codes)

Module contracts (the seams)

Dependency direction: registry ← {parser, config, engine}; engine ← {vfs, regex}; render ← result-model; cli ← all. No cycles.

Phases

Every phase carries the cross-cutting prime goals (design.md §Security & safety): security against untrusted input, safety with self-documenting refusals/warnings, find-fidelity on the drop-in surface.

Phase 0 - Foundations

Phase 1 - Drop-in find (the contract)

Phase 2 - Modern layer

Phase 3 - Differentiators

Phase 4 - Later / optional

Test strategy (detail in docs/test-plan.md)

Per the project rule (tests at every level; no one-shots):