@researai/deepscientist 1.5.16 → 1.6.0

package/src/skills/science/references/packages/jobflow.md

@@ -0,0 +1,80 @@
+# Jobflow Computational Workflow Library
+
+## Catalog
+
+- Package id: `jobflow`
+- Domains: `materials_science`, `workflow_provenance`
+- Tags: `workflow`, `computational-workflows`, `materials-science`, `high-throughput`, `job-orchestration`, `scientific-automation`
+- Knowledge URL: https://github.com/skilled-scipkg/jobflow
+- Source archive URL: https://github.com/skilled-scipkg/jobflow/archive/refs/heads/main.zip
+- Upstream project URL: https://github.com/materialsproject/jobflow
+- Homepage: https://materialsproject.github.io/jobflow
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+Jobflow is a Python library for defining, composing, and executing dynamic computational workflows as connected jobs and flows, with remote execution options and persistent scientific output storage.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `jobflow`.
+
+## Package Check
+
+For CLI/HPC-oriented environments, check the executable or loaded module before
+running any expensive job:
+
+```bash
+command -v jobflow || true
+jobflow --version || true
+```
+
+If the package is available only through environment modules, record the module
+state and the exact executable path in `validation/environment/jobflow_doctor.json`.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `jobflow` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/kadanoffbaym-jl.md

@@ -0,0 +1,73 @@
+# KadanoffBaym.jl
+
+## Catalog
+
+- Package id: `kadanoffbaym-jl`
+- Domains: `computational_science`
+- Tags: `julia`, `nonequilibrium`, `many-body`, `quantum-dynamics`, `green-functions`, `kadanoff-baym`
+- Knowledge URL: https://github.com/skilled-scipkg/KadanoffBaym.jl
+- Source archive URL: https://github.com/skilled-scipkg/KadanoffBaym.jl/archive/refs/heads/master.zip
+- Upstream project URL: https://github.com/NonequilibriumDynamics/KadanoffBaym.jl
+- Homepage: https://github.com/NonequilibriumDynamics/KadanoffBaym.jl
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+Julia package for adaptive numerical integration of nonequilibrium Kadanoff-Baym equations and real-time Green function dynamics in many-body quantum systems.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `kadanoffbaym-jl`.
+
+## Package Check
+
+Use a package-specific import, executable, or module check and save the result
+under `validation/environment/kadanoffbaym-jl_doctor.json` before treating the
+runtime as usable.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `kadanoffbaym-jl` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/kite.md

@@ -0,0 +1,80 @@
+# KITE Quantum Transport Suite
+
+## Catalog
+
+- Package id: `kite`
+- Domains: `quantum_chemistry`, `workflow_provenance`
+- Tags: `quantum-transport`, `tight-binding`, `electronic-structure`, `condensed-matter`, `hpc`, `disorder`
+- Knowledge URL: https://github.com/skilled-scipkg/kite
+- Source archive URL: https://github.com/skilled-scipkg/kite/archive/refs/heads/master.zip
+- Upstream project URL: https://github.com/quantum-kite/kite
+- Homepage: https://quantum-kite.com
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+KITE is a Python/C++ package for large-scale real-space tight-binding simulations of electronic structure and bulk quantum transport in disordered materials, including DC/AC conductivity, DoS, and wave-packet dynamics.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `kite`.
+
+## Package Check
+
+For CLI/HPC-oriented environments, check the executable or loaded module before
+running any expensive job:
+
+```bash
+command -v kite || true
+kite --version || true
+```
+
+If the package is available only through environment modules, record the module
+state and the exact executable path in `validation/environment/kite_doctor.json`.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `kite` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/kratos.md

@@ -0,0 +1,80 @@
+# Kratos Multiphysics
+
+## Catalog
+
+- Package id: `kratos`
+- Domains: `computational_fluid_dynamics`, `finite_element_engineering`, `workflow_provenance`
+- Tags: `multiphysics`, `finite-element`, `cfd`, `structural-mechanics`, `fsi`, `hpc`
+- Knowledge URL: https://github.com/skilled-scipkg/Kratos
+- Source archive URL: https://github.com/skilled-scipkg/Kratos/archive/refs/heads/master.zip
+- Upstream project URL: https://github.com/KratosMultiphysics/Kratos
+- Homepage: https://kratosmultiphysics.github.io/Kratos/
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+Kratos Multiphysics is a modular, parallel framework for coupled finite-element simulations across fluid dynamics, structural mechanics, contact, DEM, and fluid-structure interaction domains.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `kratos`.
+
+## Package Check
+
+For CLI/HPC-oriented environments, check the executable or loaded module before
+running any expensive job:
+
+```bash
+command -v kratos || true
+kratos --version || true
+```
+
+If the package is available only through environment modules, record the module
+state and the exact executable path in `validation/environment/kratos_doctor.json`.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `kratos` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/kwant.md

@@ -0,0 +1,73 @@
+# Kwant Quantum Transport Toolkit
+
+## Catalog
+
+- Package id: `kwant`
+- Domains: `quantum_chemistry`, `plasma_particle_simulation`
+- Tags: `quantum-transport`, `tight-binding`, `mesoscopic-physics`, `condensed-matter`, `nanodevices`, `quantum-simulation`
+- Knowledge URL: https://github.com/skilled-scipkg/kwant
+- Source archive URL: https://github.com/skilled-scipkg/kwant/archive/refs/heads/main.zip
+- Upstream project URL: https://github.com/kwant-project/kwant
+- Homepage: https://kwant-project.org/
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+Kwant is an open-source Python package for numerical calculations on tight-binding models with a strong focus on quantum transport in mesoscopic systems.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `kwant`.
+
+## Package Check
+
+Use a package-specific import, executable, or module check and save the result
+under `validation/environment/kwant_doctor.json` before treating the
+runtime as usable.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `kwant` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/lammps.md

@@ -0,0 +1,80 @@
+# LAMMPS Molecular Dynamics
+
+## Catalog
+
+- Package id: `lammps`
+- Domains: `molecular_dynamics`, `materials_science`, `workflow_provenance`
+- Tags: `molecular-dynamics`, `atomistic-simulation`, `materials-science`, `hpc`, `classical-md`
+- Knowledge URL: https://github.com/skilled-scipkg/lammps
+- Source archive URL: https://github.com/skilled-scipkg/lammps/archive/refs/heads/develop.zip
+- Upstream project URL: https://github.com/lammps/lammps
+- Homepage: https://www.lammps.org
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+LAMMPS is a high-performance molecular dynamics package for atomistic and coarse-grained simulations of materials, soft matter, and related many-particle systems.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `lammps`.
+
+## Package Check
+
+For CLI/HPC-oriented environments, check the executable or loaded module before
+running any expensive job:
+
+```bash
+command -v lammps || true
+lammps --version || true
+```
+
+If the package is available only through environment modules, record the module
+state and the exact executable path in `validation/environment/lammps_doctor.json`.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `lammps` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/lightkurve.md

@@ -0,0 +1,88 @@
+# Lightkurve Kepler and TESS Light-Curve Analysis
+
+## Catalog
+
+- Package id: `lightkurve`
+- Domains: `astronomy_astrophysics`
+- Tags: `astronomy`, `photometry`, `time-series`, `exoplanets`, `kepler`, `tess`
+- Knowledge URL: https://github.com/skilled-scipkg/lightkurve
+- Source archive URL: https://github.com/skilled-scipkg/lightkurve/archive/refs/heads/main.zip
+- Upstream project URL: https://github.com/lightkurve/lightkurve
+- Homepage: https://lightkurve.github.io/lightkurve/
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+Lightkurve offers user-friendly tools to retrieve, clean, visualize, and analyze Kepler and TESS astronomical flux time series, including light curves and target pixel files for exoplanet and stellar variability studies.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `lightkurve`.
+
+## Package Check
+
+For Python-facing environments, start with an import/version check and then a
+minimal package-specific smoke test:
+
+```bash
+python - <<'PY'
+import importlib, json, pathlib
+package_id = 'lightkurve'
+result = {"package_id": package_id, "import": "failed", "version": None, "smoke": "not_run"}
+try:
+    module = importlib.import_module(package_id.replace('-', '_').split('_jl')[0])
+    result["import"] = "passed"
+    result["version"] = getattr(module, "__version__", None)
+except Exception as exc:
+    result["error"] = repr(exc)
+pathlib.Path("validation/environment").mkdir(parents=True, exist_ok=True)
+pathlib.Path(f"validation/environment/{package_id}_doctor.json").write_text(json.dumps(result, indent=2), encoding="utf-8")
+PY
+```
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `lightkurve` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.

package/src/skills/science/references/packages/limix.md

@@ -0,0 +1,73 @@
+# LIMIX Genomic Linear Mixed Models
+
+## Catalog
+
+- Package id: `limix`
+- Domains: `bioinformatics`, `workflow_provenance`
+- Tags: `genomics`, `statistical-genetics`, `linear-mixed-models`, `gwas`, `eqtl`, `association-testing`
+- Knowledge URL: https://github.com/skilled-scipkg/limix
+- Source archive URL: https://github.com/skilled-scipkg/limix/archive/refs/heads/master.zip
+- Upstream project URL: https://github.com/limix/limix
+- Homepage: https://github.com/limix/limix
+- Catalog source: FermiLink skilled-scipkg, commit `93f089a333a43089fb1a08a73c37d05fd6683214`
+
+## When To Consider
+
+LIMIX provides efficient linear mixed model methods for genomic association, interaction, and variance decomposition analyses, supporting workflows such as single-variant tests, set tests, and eQTL-style statistical genetics studies.
+
+## DeepScientist Runtime Rule
+
+This card is package knowledge and routing context only. It does not mean the
+solver, Python module, CLI binary, compiled backend, license server, dataset, or
+HPC module is installed in the active environment. Before computed work, use
+`bash_exec(...)` to perform an import, executable, version, and smoke-test check
+appropriate for `limix`.
+
+## Package Check
+
+Use a package-specific import, executable, or module check and save the result
+under `validation/environment/limix_doctor.json` before treating the
+runtime as usable.
+
+Record the result with `artifact.science(...)` as `science.package_check`. Use
+`status="passed"` only when the environment can run at least a minimal smoke
+path. Use `status="failed"` or `status="blocked"` when the check explains why
+execution cannot proceed.
+
+Generated import or executable names are starting points. If `limix` uses
+a different Python module, CLI binary, environment module, container, or wrapper
+script, adjust the check before concluding the solver is unavailable.
+
+## Expected Science Nodes
+
+- `science.package_check` for import/executable/version/smoke-test evidence
+- `science.computational_run` for solver execution, simulation, fitting, or numerical computation
+- `science.dataset_analysis` when the task primarily analyzes existing data
+- `science.parameter_sweep` when varying parameters, inputs, models, or solver settings
+- `science.validation_result` for convergence, units, schema, controls, or correctness checks
+- `science.claim` only after evidence paths or related nodes support the claim
+
+## Evidence Path Conventions
+
+- `simulations/inputs/` for generated or selected solver inputs
+- `simulations/logs/` for stdout, stderr, scheduler logs, or solver logs
+- `simulations/outputs/` for structured run outputs
+- `analyses/scripts/`, `analyses/logs/`, and `analyses/outputs/` for dataset analysis
+- `validation/environment/` for package checks
+- `validation/runs/` for convergence, unit, schema, or correctness sidecars
+- `figures/` for derived visualizations
+
+## Validation Checklist
+
+- Record package version, executable path, backend, module state, or container image when relevant.
+- Preserve input files and parameters that define the scientific state.
+- Capture units, coordinate conventions, timestep/mesh/basis/model settings, seeds, and convergence criteria when applicable.
+- Validate output schema and important physical or statistical invariants before recording a computed claim.
+- Link claims to run, analysis, sweep, and validation nodes rather than relying on prose.
+
+## Common Pitfalls
+
+- Do not treat the package card or knowledge URL as runtime availability.
+- Do not weaken solver tolerances, physical models, dataset filters, or convergence criteria to make a run pass unless the change is explicitly part of the scientific question.
+- Do not call a value `computed` unless the corresponding run or analysis happened in the current quest and evidence paths are recorded.
+- Do not copy package knowledge-base material into the quest without preserving its source and license context.