Skip to main content
Version: 3.0 (Next)

Requirements Catalog — How to Read This Section

This is the single authority for Flude's functional and non-functional requirements. It replaces srs/functional.md, srs/non_functional.md, srs/quality_audit.md, srs/task_compliance.md, roadmap/future_v2.md, and roadmap/mvp_v1/requirements.md — all six are now redirect stubs pointing back here. Business requirements (REQ-BUS-*) keep their existing home in brd/requirements.md; this catalog is where every REQ-BUS-* gets its functional/non-functional breakdown and its delivery status.

This restructuring exists because the prior structure let the same fact drift into contradiction across five separate documents — see .antigravitycli/requirements_restructuring/opus_requirements_plan.md §1–§4 for the full diagnosis. The two rules below exist specifically to prevent that from recurring.

Anchor facts​

There is exactly one shipped release: v2.0.0, tagged 2026-08-11 — the project's first-ever GitHub Release. There was never a v1.0 tag or release. "V1.0 MVP" in this catalog names a retrospective architectural slice of the same continuous codebase, frozen by the 2026-06-28 requirements audit date — the pre-typed-IR, pre-mandatory-sidebar.toml, pre-CLI-subcommand architecture. It was never independently released; do not read it as a shipped predecessor.

The token vN.0+ is banned as a version bucket. Read next to a shipped v2.0.0, "Future Phase (v2.0+)" parses as "already delivered" — which is how several genuinely unimplemented requirements (translation, RAG export, LLM enrichment, XLIFF) ended up looking done in the old corpus. Every requirement in this catalog carries exactly one Target: v1.0, v2.0, v3.0, or v4.0+. A historical requirement may quote the old vN.0+ tag while explaining that it has been retired — that is not the same as using it as a bucket.

The four buckets​

BucketFileDefinition
V1.0 MVPv1.0-mvp.mdThe pre-typed-IR architecture as audited 2026-06-28. Historical; never separately released.
V2.0v2.0-shipped.mdEverything in tag v2.0.0 (2026-08-11). The only bucket with a checkable 100%-done claim (.antigravitycli/v20_todo.md: 492/492).
V3.0v3.0-next.mdThe immediate next milestone. Prerequisite: v2.0 stable.
V4.0+v4.0-backlog.mdLong-horizon: AI enrichment/translation, expanded output formats, a contingent server mode and its security envelope, advanced QA graduation.

Non-functional requirements (REQ-NFN-*) are cross-version by nature — a coverage threshold is tightened, not re-authored per release — so they live in one place, nfr.md, each entry tagged with the version it was introduced or last changed in. The four bucket files above never restate NFR text; they only reference the id.

traceability.md holds the REQ-BUS → REQ-FUN/REQ-V2/REQ-V3 → REQ-NFN map and the status roll-up. It replaces the old quality_audit.md (a self-scored audit that never revised its score down) and task_compliance.md (a 19-task ledger frozen at the MVP era while the real execution record grew to 492 items in v20_todo.md).

ID scheme and the GAP-alias rule​

Existing identifier namespaces are never renumbered and never deleted — .antigravitycli/v20_todo.md alone carries 158 [Source: …#ID] citations against them, plus bidirectional GAP-XX ↔ TASK-<p>.<g>.<s> mappings:

  • REQ-BUS-NN — business requirements, defined in brd/requirements.md.
  • REQ-FUN-NN — functional requirements dating from the V1.0 architecture; may carry an in-place version history (see below) rather than being superseded by a new id.
  • REQ-NFN-NN — non-functional requirements, sole authority nfr.md.
  • REQ-V2-NN / REQ-V3-NN — cluster requirements minted for the V2.0 and V3.0 catalogs respectively, promoted from .antigravitycli/requirements_v3_next.md's internal REQ-V2-01..10 numbering.
  • GAP-NN — the internal planning/execution tracking id. Every requirement descended from a GAP item displays it as a permanent Alias, so v20_todo.md citations and TASK-<p>.<g>.<s> mappings keep resolving regardless of which REQ-* id represents that GAP in the published catalog.
  • TEST-INT-NN / TSK-* — QA-suite and task-registry ids, referenced from here but owned by srs/integration_tests_specification.md and the historical ToDo//v20_todo.md ledgers respectively.

Revising a requirement never mints a new id. When a requirement's shape changes across versions (the historical example is REQ-FUN-50's v1.0 per-renderer-class TOC JSON files being replaced by sidebar.toml in v2.0), the same id carries a History bullet per version instead. This proved more durable than the alternative tried elsewhere in the old corpus (a roadmap table asserting a status that drifted out of sync with the requirement text it summarized).

Status enum​

IMPLEMENTED · PARTIAL · UNIMPLEMENTED · DEFERRED · SUPERSEDED

PARTIAL must name what is delivered and what remains, as separate statements. The worked example is REQ-FUN-51 (path/file glob include-exclude filtering): the old catalog recorded it as flatly UNIMPLEMENTED, when in fact three collector-config keys (exclude, exclude_patterns, file_patterns) were already wired into the Doxyfile assembly and used by shipping SDK configs (16 use exclude_patterns specifically; 78 use at least one of the three keys) — only the include allowlist, namespace-level scoping, and Doxygen-independent implementation were actually missing. An all-or-nothing status field is precisely what let a shipped capability be documented as absent.

Mandatory per-requirement template​

### `REQ-XXX-NN`

**Title**

* **Status**: `IMPLEMENTED` | `PARTIAL` | `UNIMPLEMENTED` | `DEFERRED` | `SUPERSEDED`
* **Target**: `v1.0` | `v2.0` | `v3.0` | `v4.0+`   (never `vN.0+` as a bucket)
* **Alias**: `GAP-NN` / `TEST-INT-NN` / — (permanent; never renumbered)
* **Traces to**: `REQ-BUS-NN`
* **Evidence**: `file:line`, a test name, or an explicit negative
  ("no equivalent in `engine/ude/<dir>/` as of 2026-08-14") for `UNIMPLEMENTED`
* **History**: one bullet per version when the requirement changed across versions

<body text>

The heading holds only the bare id, in backtick code style — the title is a bold line immediately below it, not part of the heading. This is a deliberate, verified constraint, not a style preference: this site's MDX toolchain (Docusaurus 3.10 / MDX v3) fails the build on Docusaurus's usual explicit {#custom-id} heading-anchor syntax — confirmed by an isolated build-time repro during this restructuring, where even a minimal ## Heading {#id} failed with "Could not parse expression with acorn" (the curly braces are read as a raw JS expression, not a heading id, in this project's MDX configuration). Keeping the heading to just `REQ-XXX-NN` instead means Docusaurus's automatic (GitHub-slugger-based) anchor generation produces a predictable, stable slug — lowercase, hyphens as written, e.g. `REQ-FUN-13` → #req-fun-13 — without depending on a syntax this toolchain rejects. A parenthetical qualifier is safe to add to the heading when a requirement id repeats with a version suffix (e.g. `REQ-FUN-50` (v1 form) → #req-fun-50-v1-form); do not add anything else, since any extra heading text changes the resulting anchor.

The Evidence field is the single largest process change this restructuring makes. Every drift defect found during this restructuring (see .antigravitycli/requirements_restructuring/opus_requirements_plan.md §4.1, §4.2) was resolvable in minutes by grepping the code; requiring the pointer at authoring time is far cheaper than discovering the drift later during an audit.