Tools
Tools help apply FEOD in a project, but they do not replace understanding the methodology. First the team fixes the structure, levels, public API, and import rules; then it connects tools to support these decisions in code and review.
What is included in the first stage
In the first stage, the documentation describes confirmed tooling directions and one ready CLI artifact.
| Tool | Why it is needed | Description status |
|---|---|---|
| FEOD Analyzer | Build a graph of FEOD entities, detect import and public API violations, and export an HTML/JSON report. | Ready CLI artifact, launch scenarios, configuration, and limitations. |
| ESLint plugin | Check architectural violations: bypassing public API, reverse dependencies, deep imports. | Adoption scenario, checks, and CI flow. |
| AI rules | Give AI assistants rules for project structure, review, and code generation. | Rule set, inputs, and result validation. |
| FEOD config | Capture configuration for levels, modules, and allowed deviations. | Contract for the linter, AI rules, and internal checks. |
How to write Tools pages
Every Tools page answers practical questions:
- When to connect the tool.
- Which inputs it needs.
- What it checks or generates.
- Which errors it does not cover.
- How the team validates the result.
What must not be promised
A future tool must not be described as a finished product. If the technical implementation is not confirmed, the page should say directly that it is a roadmap item or product scenario.
A tool is not the source of rules. The source of rules is the Reference, Structure, and Core Concepts sections.