You have removed the license file, this is a violation of copyright

.codex/skills/changelog-release/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: changelog-release
+description: Update CHANGELOG.md (Keep a Changelog) and bump pyproject.toml version consistently with repo policy.
+metadata:
+  short-description: Update changelog + version
+---
+
+## When to use
+
+Use this skill when a change is user-visible or release-relevant (features, fixes, behavior changes, deprecations, removals, security).
+
+## Files
+
+* `CHANGELOG.md`
+* `pyproject.toml`
+
+If `CHANGELOG.md` does not exist, create a stub file and note that it was missing.
+
+## Keep a Changelog rules (repo policy)
+
+* Use the heading format: `## [x.y.z] - YYYY-MM-DD`
+* Allowed sections: `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`
+* Historical entries are never modified.
+* Each bullet:
+  * begins with a lowercase imperative verb (e.g., “add”, “fix”, “remove”, “deprecate”)
+  * uses valid Markdown list syntax
+
+## Procedure
+
+1) Determine whether the change warrants a version bump.
+   * If uncertain, default to *not* bumping and explicitly state uncertainty; do not guess silently.
+2) If bumping:
+   * Update `pyproject.toml` version to the new `x.y.z`.
+3) Update `CHANGELOG.md`:
+   * Add a new topmost entry for the new version/date.
+   * Place changes under the correct section(s).
+   * Do not edit older entries.
+4) Ensure changelog content matches actual code changes:
+   * No speculative bullets.
+   * No missing bullets for significant user-visible changes.
+
+## Version selection guidance (pragmatic)
+
+Use semantic versioning heuristics unless the repository specifies otherwise:
+
+* PATCH: bug fix, internal refactor with no behavior change, test-only changes (often no release)
+* MINOR: additive feature, new CLI option, backwards-compatible behavior enhancement
+* MAJOR: breaking change, removal, incompatible behavior change
+
+If the repo already uses a different scheme, follow the existing precedent.
+
+## Output discipline
+
+When reporting the changelog update:
+
+* Show the exact new changelog entry you added.
+* Show the `pyproject.toml` version line that changed.
+* Keep paths POSIX-style and sort any lists deterministically.

.codex/skills/dependencies/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: dependencies
+description: Add/remove Python dependencies via uv while meeting repo policy (justification, tests, determinism).
+metadata:
+  short-description: Manage deps via uv
+---
+
+## Policy requirements (from AGENTS.md)
+
+* Use `uv` for all package management, including adding/removing dependencies.
+* Do not add new dependencies without an inline comment justifying the change.
+* Prefer existing, popular, well-supported libraries when appropriate.
+
+## When to use
+
+Use this skill whenever you consider introducing a new third-party library, or removing/upgrading one.
+
+## Decision procedure before adding a dependency
+
+1) Confirm the need:
+   * Is the functionality truly non-core to the project, or not highly customized?
+2) Prefer existing solutions:
+   * Standard library
+   * Existing project dependencies
+3) If adding a dependency is still justified:
+   * Choose a well-supported library with stable maintenance and good adoption.
+   * Minimize dependency surface area (avoid pulling in large stacks for small tasks).
+
+## Required in-code justification
+
+When introducing a new dependency, add an inline comment near the first usage explaining:
+
+* why a third-party dependency is necessary (vs stdlib / existing deps)
+* why this specific library was chosen
+* any constraints (performance, determinism, portability)
+
+Keep the comment brief but specific.
+
+## Commands
+
+Use `uv` for dependency changes. Prefer to run through `just setup` afterwards to refresh `.venv` if needed.
+
+Typical flows:
+
+* Add dependency: `uv add <package>`
+* Add dev dependency: `uv add --dev <package>` (if your project uses this convention)
+* Remove dependency: `uv remove <package>`
+* Sync environment: `uv sync` (or `just setup`)
+
+Do not add or remove dependencies in ways that bypass `uv` (e.g., editing lockfiles directly) unless explicitly instructed.
+
+## Validation requirements after dependency changes
+
+After modifying dependencies:
+
+1) Run the standard validation pipeline (use `quality-gates`).
+2) Add or update tests if the dependency supports new behavior or replaces custom logic.
+3) Ensure determinism:
+   * avoid time-dependent behavior introduced by the library
+   * avoid environment-dependent defaults
+
+## Reporting
+
+When presenting the change:
+
+* State the dependency added/removed and the reason (consistent with the inline comment).
+* Identify any files updated by `uv` (lockfile, `pyproject.toml`, etc.).
+* Confirm that `quality-gates` passed (or report failures precisely).

.codex/skills/patch-only-fallback/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: patch-only-fallback
+description: Required behavior when shell/tool execution is unavailable - produce a patch and expected command outcomes and halt.
+metadata:
+  short-description: Patch-only mode
+---
+
+## When to use
+
+Use this skill whenever:
+
+* shell access is unavailable, or
+* required tooling is missing/misconfigured (notably `.venv/bin/ty`), or
+* you cannot run validation commands required by `AGENTS.md`.
+
+## Required behavior
+
+1) Emit a Markdown-formatted patch containing the proposed edits.
+2) Describe what you would run (exact commands) to validate the change:
+   * `.venv/bin/ruff format src/ tests/`
+   * `.venv/bin/ruff check src/ tests/`
+   * `.venv/bin/ty check src/ tests/`
+   * `.venv/bin/pytest`
+3) Describe the *expected* outcomes at a high level (e.g., “ruff clean”, “tests pass”), but do not fabricate logs.
+4) Halt execution (do not proceed as if the checks ran).
+
+## Output constraints
+
+* Use POSIX-style paths.
+* Sort file paths deterministically in the patch and any enumerations.
+* Do not include ANSI styling.

.codex/skills/quality-gates/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: quality-gates
+description: Run the repository’s standard validation pipeline (ruff/ty/pytest) and report results deterministically.
+metadata:
+  short-description: Run lint/format/typecheck/tests
+---
+
+## Scope
+
+Use this skill after making any change under `src/` or `tests/` (including refactors), and before presenting a final diff.
+
+This skill operationalizes the requirements in `AGENTS.md`:
+
+* Linting: `.venv/bin/ruff check src/ tests/`
+* Formatting: `.venv/bin/ruff format src/ tests/`
+* Type checking: `.venv/bin/ty check src/ tests/` (with required fallback if missing)
+* Testing: `.venv/bin/pytest`
+
+Prefer running `just` recipes when available, because the `justfile` is the canonical automation entrypoint for this repo.
+
+## Allowed paths and determinism
+
+* Only edit files under `src/`, `tests/`, or `TODO.md` unless explicitly instructed otherwise.
+* Use POSIX-style paths (`/`) in output and JSON.
+* Sort file paths deterministically in reports (lexicographic).
+* Do not emit ANSI styling in machine-readable output.
+
+## Execution order
+
+Run steps in this order:
+
+1) Environment/bootstrap (only if needed)
+2) Formatting
+3) Linting
+4) Type checking
+5) Tests
+
+Rationale: formatting first reduces churn; type errors are usually faster to fix than test failures; tests last.
+
+## Commands
+
+### Preferred (via `just`)
+
+Run:
+
+* `just setup` (only if dependencies or `.venv` are missing/outdated)
+* `just format` (auto-format) or `just format-no-fix` (check only; do not modify)
+* `just lint` (auto-fix where possible) or `just lint-no-fix` (check only; do not modify)
+* `just typecheck`
+* `just test-strict`
+
+If you ran auto-fix steps (`just format` / `just lint`), rerun the corresponding “no-fix” check to confirm a clean state.
+
+### Direct (if `just` is unavailable)
+
+Run:
+
+* `.venv/bin/ruff format src/ tests/`
+* `.venv/bin/ruff check src/ tests/`
+* `.venv/bin/ty check src/ tests/`
+* `.venv/bin/pytest`
+
+## Required fallback: missing `ty`
+
+If `.venv/bin/ty` is not present or not executable:
+
+1) Record a failure notice: "`ty` not found at .venv/bin/ty; cannot complete required static typing gate."
+2) Do not attempt to “approximate” type checking with another tool unless explicitly instructed.
+3) Emit proposed changes as a Markdown patch and halt further execution.
+
+Reference: `patch-only-fallback` skill.
+
+## Failure handling and reporting
+
+If any step fails:
+
+* Identify the failing command and include its exit status.
+* Provide the smallest actionable summary of failures (first error lines, failing test names).
+* Fix issues if the failure is within scope and deterministic to resolve.
+* Re-run the failed step(s) and any downstream steps that depend on them.
+
+## Coverage policy hook
+
+If the workflow produces or updates a coverage XML report (e.g., `.coverage.xml` or `coverage.xml`) and you can compare it to the repository baseline:
+
+* If coverage decreases from the baseline, log a warning and request user confirmation before proceeding with submission.
+
+If you cannot determine the baseline, explicitly state that and do not claim coverage improvement.

.gitignore

@@ -1,4 +1,6 @@
 # Mutant files
+.import_linter_cache/
+.ropeproject/
 e2e_projects/**/mutants
 /mutants
 tests/data/**/*.py.meta
@@ -55,6 +57,7 @@ output/*/index.html
 # Sphinx
 docs/_build
 docs/tri*.rst
+site/
 
 # tests
 results/