fspec rules describe what should exist, not how to check it.
There is no execution model exposed to the user. The same specification should be interpretable by different tools.
An .fspec file should be understandable months or years later by
someone who did not write it.
Rules are line-based, ordered, and explicit.
Rules are evaluated top-to-bottom. If multiple rules match, the last rule wins.
This mirrors familiar patterns from tools like .gitignore, while
remaining deterministic.
Patterns are either:
- anchored at the
.fspecroot, or - unanchored and match anywhere
There is no implicit anchoring. This avoids subtle mismatches and makes intent clear.
fspec avoids:
- complex regex-driven semantics
- hidden backtracking behavior
- implicit directory creation rules
Directories implied by allowed files are considered structurally allowed, but nothing more.
Repeated placeholders must match the same value within a rule.
This encodes consistency constraints that humans routinely violate but rarely document.
fspec is developed in explicit conformance levels.
Each level adds capability without invalidating earlier specifications. This allows real-world use before the system is “complete”.
The core rule engine is designed to be reusable:
- CLI tools
- CI checks
- editors
- higher-level automation
The .fspec file is the stable interface.