Chore/cleanup (#46)

* added skills; updated gitignore and CHANGELOG

* docs update

Author: markleader

.codex/skills/docs-cleanup/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: docs-cleanup
+description: Audit repository documentation for stale, conflicting, or incomplete install/run guidance and outdated examples; report concrete file-level gaps and recommended fixes.
+---
+
+# Docs Cleanup
+
+Use this skill when the user asks for a documentation audit, cleanup pass, or stale-doc review.
+
+## Goals
+
+- Find conflicting or outdated install/run instructions.
+- Check whether examples still match current CLI/API behavior.
+- Flag missing guidance that blocks onboarding, testing, or release tasks.
+- Keep output focused on actionable findings with file references.
+
+## Workflow
+
+1. Collect candidate docs:
+   - `README.md`
+   - `docs/source/**/*.rst`
+   - `CONTRIBUTING.md`
+   - `.github/` templates/workflows when relevant to user instructions.
+2. Validate install/run instructions against current repo behavior:
+   - Build and test commands in docs vs commands in `CMakeLists.txt`, `pyproject.toml`, CI workflows, and `scripts/`.
+   - Confirm paths, filenames, and prerequisites are still valid.
+3. Validate examples:
+   - Compare documented examples with `samples/`, `test/`, and current interfaces.
+   - Check that command arguments and expected outputs are still plausible.
+4. Identify gaps:
+   - Missing prerequisites, platform caveats, troubleshooting notes, or release-process notes.
+5. Report findings first, ordered by severity:
+   - `High`: wrong instruction likely to fail.
+   - `Medium`: confusing/outdated but recoverable.
+   - `Low`: clarity/consistency improvements.
+
+## Output Format
+
+- Findings list with `severity`, `file`, and exact issue.
+- Proposed fix for each finding.
+- Open questions or assumptions.
+- If no findings: explicitly state that and note residual risk areas not fully validated.
+
+## Guardrails
+
+- Prefer small documentation edits over broad rewrites.
+- Avoid speculative claims; cite the source file/command that contradicts the docs.
+- Do not edit generated docs under `docs/_build/` or `docs/doxygen/`.

.codex/skills/pr-merge/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: pr-merge
+description: Review branch changes against main before merge, ensure docs and changelog updates are present, and report merge-readiness warnings.
+---
+
+# PR Merge Readiness
+
+Use this skill when the user wants a final pre-merge pass for a feature branch.
+
+## Goals
+
+- Compare branch diff against `main`.
+- Confirm user-visible changes have matching docs updates.
+- Add or refine `CHANGELOG.md` entries under `Unreleased`.
+- Surface warnings/risks before merge.
+
+## Workflow
+
+1. Gather diff scope:
+   - `git diff --name-status main...HEAD`
+   - `git diff --stat main...HEAD`
+2. Classify changed files:
+   - Core solver (`source/`), bindings, tests, docs, CI, packaging.
+3. Docs consistency check:
+   - If behavior/API changed, verify `README.md` and/or `docs/source/` updates exist.
+   - If docs are missing, flag as warning and propose exact files to update.
+4. Changelog update:
+   - Add concise user-visible bullets under `## [Unreleased]` in `CHANGELOG.md`.
+   - Use sections already present (`Changed`, `Fixed`, `Added`).
+5. Sanity checks:
+   - Confirm no accidental edits to generated docs/build outputs.
+   - Highlight risky areas: missing tests, interface changes, scientific/numerical behavior impacts.
+6. Produce merge recommendation:
+   - `Ready`, `Ready with warnings`, or `Not ready`.
+
+## Output Format
+
+- Findings first, ordered by severity, with file references.
+- Proposed `CHANGELOG.md` additions.
+- Final merge-readiness verdict and blockers.
+
+## Guardrails
+
+- Do not merge branches automatically.
+- Do not rewrite changelog history outside `Unreleased` unless user asks.
+- Keep warnings concrete and evidence-based.

.codex/skills/update-agents-md/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: update-agents-md
+description: Update AGENTS.md to reflect recent repository workflow, architecture, and policy changes while preserving existing project constraints.
+---
+
+# Update AGENTS.md
+
+Use this skill when AGENTS guidance has drifted from the codebase or team workflow.
+
+## Goals
+
+- Keep `AGENTS.md` current with architecture boundaries, testing expectations, and repo workflows.
+- Preserve critical existing constraints unless the user explicitly asks to change them.
+
+## Workflow
+
+1. Read current `AGENTS.md` fully.
+2. Scan recent project changes for process-impacting updates:
+   - `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`
+   - CI workflows in `.github/workflows/`
+   - Build/package entry points (`CMakeLists.txt`, `pyproject.toml`)
+   - Interface boundaries under `source/`.
+3. Propose targeted edits only where guidance is stale or missing.
+4. Apply minimal, focused wording changes:
+   - Keep rules concrete and enforceable.
+   - Avoid aspirational or ambiguous language.
+5. Validate consistency:
+   - No contradictions with docs or CI.
+   - Keep scientific correctness and compatibility priorities explicit.
+
+## Output Format
+
+- Summary of what changed in `AGENTS.md`.
+- Why each change was needed.
+- Any deferred items requiring user decision.
+
+## Guardrails
+
+- Do not remove existing hard constraints unless explicitly instructed.
+- Avoid adding style-only or noisy policy text.
+- Keep edits short and maintainable.

.codex/skills/version-increment/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: version-increment
+description: Prepare the repository for a new release tag by updating hard-coded version references, promoting CHANGELOG Unreleased entries, and running release-readiness checks.
+---
+
+# Version Increment
+
+Use this skill when the user provides a new version number and wants the repo prepared for tagging.
+
+## Inputs
+
+- `new_version` (required), semver-like string (example: `3.0.4`).
+- `release_date` (optional). If omitted, use local current date (`YYYY-MM-DD`).
+
+## Known Hard-Coded Version Locations (current repo)
+
+- `CMakeLists.txt` (`project(... VERSION x.y.z)`).
+- `source/bind/python/cea/__init__.py` (`__version__ = "x.y.z"`).
+- `docs/source/conf.py` (`release = '...'`).
+
+Update these locations and verify no additional hard-coded version literals remain outside generated docs.
+
+## Workflow
+
+1. Validate `new_version` format and ensure it is greater than the current version.
+2. Update the three known hard-coded version locations.
+3. Search for additional stale literals:
+   - Prefer `rg -n "<old_version>|release\s*=|__version__\s*=|VERSION\s+[0-9]+\.[0-9]+\.[0-9]+"`
+   - Exclude generated docs: `docs/_build/`, `docs/doxygen/`.
+4. Update `CHANGELOG.md`:
+   - Move current `## [Unreleased]` entries into a new release section `## [<new_version>] - <release_date>`.
+   - Recreate an empty `## [Unreleased]` section at the top with standard subsections used by this repo.
+5. Run sanity checks:
+   - Ensure changed files are limited to release metadata/docs unless user asked for more.
+   - Optionally run targeted tests/docs build if requested.
+6. Report exact files changed and any warnings before tagging.
+
+## Output Format
+
+- New version and date used.
+- List of updated files with one-line reason each.
+- Warnings/blockers before tag creation.
+- Suggested tag command: `git tag v<new_version>` (only if user asks to tag).
+
+## Guardrails
+
+- Do not create/push tags unless explicitly requested.
+- Do not edit generated docs under `docs/_build/` or `docs/doxygen/`.
+- Keep changelog wording user-visible and avoid implementation-only noise.

.github/workflows/basic_build.yml

@@ -360,7 +360,7 @@ jobs:
             fcompiler: gcc
             fversion: "11"
         include:
-          - os: ubuntu-22.04
+          - os: ubuntu-24.04
             toolchain:
               ccompiler: gcc
               cversion: "13"

.gitignore

@@ -37,4 +37,5 @@ __pycache__/
 source/bind/excel/~$*.xlsm
 source/bind/excel/*.lib
 source/bind/python/samples
-source/bind/python/cea/samples/*.tex
+source/bind/python/cea/samples/*.tex
+source/bind/python/cea/samples/intro.py

AGENTS.md

@@ -2,7 +2,7 @@
 
 This repository is a scientific computing library (CEA). Follow these rules:
 
-- Do NOT modify `thermo.inp` or `trans.inp` unless explicitly instructed.
+- Do NOT modify `data/thermo.inp` or `data/trans.inp` unless explicitly instructed.
 - Numerical correctness is paramount; preserve bitwise results and scientific behavior.
 - Avoid algorithmic changes unless explicitly requested.
 - Prefer clarity over cleverness or micro-optimizations.
@@ -11,3 +11,10 @@ This repository is a scientific computing library (CEA). Follow these rules:
 - If numerical behavior might change, call it out and add validation or tests when possible.
 - Respect layer boundaries: Fortran core in `source/`, C bindings in `source/bind/c/`,
   Python bindings in `source/bind/python/`.
+- Run minimal validation for touched areas:
+  - Core/CMake/Fortran/C changes: run relevant `ctest` targets from the build directory.
+  - Python binding changes: run `make py-rebuild` then `pytest source/bind/python/tests`.
+  - Documentation-only changes: check referenced commands/paths against `README.md` and `CONTRIBUTING.md`.
+- Prefer established workflows:
+  - Configure/build with `cmake --preset dev` and `cmake --build build-dev` when appropriate.
+  - Use focused tests first, then broader test runs when numerical behavior may be affected.

CHANGELOG.md

@@ -5,15 +5,18 @@ All notable user-visible changes to this project are documented here.
 ## [Unreleased]
 
 ### Changed
+- Command-line input parsing now accepts explicit `.inp` filenames (`#44`).
 
 ### Fixed
+- Fixed a crashing output case and restored missing output values (`#45`).
 
 ### Added
+- Added missing Python test dependencies to improve out-of-the-box test runs (`#41`).
 
 ## [3.0.3] - 2026-02-20
 
 ### Changed
-- Hardened PyPI publishing CI with OIDC preflight checks and manual `workflow_dispatch` target selection (`testpypi`/`pypi`); installation docs now lead with `python -m pip install cea` and mention GitHub Releases binary assets.
+- Hardened PyPI publishing CI with OIDC preflight checks and manual `workflow_dispatch` target selection (`testpypi`/`pypi`); installation docs now lead with `python -m pip install cea` and mention GitHub Releases binary assets. (`#39`, `#40`).
 
 ### Fixed
 

CMakeLists.txt

@@ -8,7 +8,7 @@ set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
 set(CMAKE_DISABLE_SOURCE_CHANGES ON)
 set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)
 project(CEA
-    VERSION 3.0.0
+    VERSION 3.0.3
     LANGUAGES Fortran
 )
 

README.md

@@ -133,7 +133,7 @@ Note that specifying the `.inp` extension for input files is optional.
 
 Python example (runs the H2/O2 case after installing the Python bindings):
 
-    python source/bind/python/cea/samples/h2_02.py
+    python source/bind/python/cea/samples/h2_o2.py
 
 
 ## Database Generation