[Suggestion]: Adjust repository structure

[wpenistone]

Which fff frontend(s)?

Core or Rust crate

What problem are you trying to solve?

Right now fff has several useful entry points and packages, but the repo structure does not yet make the larger shape obvious or usable enough.

This is mostly about structure, atomicity, maintainability, distribution, and discoverability, a clearer monorepo shape would make those features and sub-crates easier to reuse as fff adds richer features, document, package, and find.

Proposed solution

Suggested shape:

crates/
  fff-core/
  fff-query-parser/
  fff-grep/
  fff-mcp/
  fff-nvim/
  fff-c/

packages/
  fff-node/
  pi-fff/
  fff-bin-*/           platform binary packages

lua/
  fff/

docs/
  agent/
  neovim/
  sdk/
  distribution/
  query-language/
  capabilities/

examples/              (optional, but good for SDK inspirations)
  node-agent-tool/
  rust-cli/
  c-ffi-minimal/
  mcp-client/
  neovim-programmatic-search/
  ....

schemas/ (later on...)
  capabilities.json
  query.schema.json
  result.schema.json

distribution/
  homebrew/
  winget/
  nix/
  install-scripts/
  checksums/

[gustav-fff]

[triage-bot] FEATURE REQUEST:

Out of scope for automated triage. Repo restructure (moving crates, packages, lua, docs into a new monorepo layout) is a cross-cutting change with broad implications for build, CI, release workflows, downstream consumers (pi-fff, neovim plugin paths, MCP server), and Cargo.toml/package.json references. Not a small config exposure or bug fix.

Deferring to @dmtrKovalenko for direction on whether the proposed shape is desirable and which pieces (if any) should land first.

Honk-Honk 🪿

[dmtrKovalenko]

I do repository structure for myself as I am working with it.

What do you want from it/what is missing?