Child of the solver boundary umbrella. Closing step. Must land after the
other children, not before: run today against the full module list it produces
roughly 160 hits, which is unusable as a gate.
What the test does today
tests/unit/test_solver_boundary.py reads 6 modules and greps them for 5
tokens:
SOLVER_TOKENS = ("code_saturne", "setup.xml", "run.cfg", "RESU", "MESH")
GENERIC_MODULES = [registry.py, doe.py, cli.py, control.py, web_services.py, fastapi_routes/*]
Two weaknesses
The module list covers 6 files out of 20. Not scanned: runner.py,
execution.py, docker.py, logs.py, probes.py, residuals.py,
template.py, web_support.py, maintenance.py, config.py — precisely the
modules holding the most code_saturne conventions.
The token list is too narrow, which makes the test green on files that
leak. Missing at least: listing, monitoring, profiles, run_solver.log,
performance.log, run_status, saturne, POST, residuals.csv.
Concretely, today: cli.py is in the scanned list, passes, and contains 10
code_saturne literals; fastapi_routes/case_data.py is in the scanned list,
passes, and declares file: str = "listing" and scope: str = "monitoring" as
API defaults.
What to do
- Extend
SOLVER_TOKENS with the words above.
- Extend
GENERIC_MODULES to every module outside csauto/solvers/, ideally
by globbing so a new module is covered automatically instead of being
forgotten.
- Add an explicit allowlist for the residue
docs/architecture.md already
records as deliberate: saturne_bin, --saturne-bin, the TOML keys, and the
historical HTTP names (/api/resu_dirs, resu_removed). The allowlist
should be a named constant with a comment pointing at that doc section, so
the test and the documentation state the same thing.
- Update
docs/architecture.md and docs/adding-a-solver.md: today they say
all solver knowledge sits behind the adapter, which is not true. After this
work it will be, and the wording should describe the mechanism/vocabulary
split explicitly.
Definition of done
- The test scans every generic module, with tokens broad enough to catch the
leaks listed above.
- The allowlist is short, named, commented, and matches the documentation.
- Adding a module to
csauto/ puts it under the gate without anyone
remembering to register it.
Child of the solver boundary umbrella. Closing step. Must land after the
other children, not before: run today against the full module list it produces
roughly 160 hits, which is unusable as a gate.
What the test does today
tests/unit/test_solver_boundary.pyreads 6 modules and greps them for 5tokens:
Two weaknesses
The module list covers 6 files out of 20. Not scanned:
runner.py,execution.py,docker.py,logs.py,probes.py,residuals.py,template.py,web_support.py,maintenance.py,config.py— precisely themodules holding the most code_saturne conventions.
The token list is too narrow, which makes the test green on files that
leak. Missing at least:
listing,monitoring,profiles,run_solver.log,performance.log,run_status,saturne,POST,residuals.csv.Concretely, today:
cli.pyis in the scanned list, passes, and contains 10code_saturne literals;
fastapi_routes/case_data.pyis in the scanned list,passes, and declares
file: str = "listing"andscope: str = "monitoring"asAPI defaults.
What to do
SOLVER_TOKENSwith the words above.GENERIC_MODULESto every module outsidecsauto/solvers/, ideallyby globbing so a new module is covered automatically instead of being
forgotten.
docs/architecture.mdalreadyrecords as deliberate:
saturne_bin,--saturne-bin, the TOML keys, and thehistorical HTTP names (
/api/resu_dirs,resu_removed). The allowlistshould be a named constant with a comment pointing at that doc section, so
the test and the documentation state the same thing.
docs/architecture.mdanddocs/adding-a-solver.md: today they sayall solver knowledge sits behind the adapter, which is not true. After this
work it will be, and the wording should describe the mechanism/vocabulary
split explicitly.
Definition of done
leaks listed above.
csauto/puts it under the gate without anyoneremembering to register it.