release: v0.3.0b2

.claude/commands/adr.md

@@ -0,0 +1,42 @@
+---
+allowed-tools: Bash(git status:*), Bash(git log:*), Bash(chainlink tree:*), Bash(chainlink comment:*), Bash(chainlink subissue:*), Bash(chainlink create:*), Bash(chainlink session:*), Bash(chainlink --help), Bash(chainlink close:*), Bash(uv run pytest:*), Bash(uv run ruff:*)
+description: Perform an adversarial review
+---
+
+## Context
+
+- Current issue tree: !`chainlink tree`
+- Current test outputs: !`uv run pytest -v`
+- Recent commits: !`git log --oneline -10`
+- Chainlink help: !`chainlink --help`
+
+## Your task
+
+1. Develop summary assessment of test suite
+    - Look through all of the unit tests currently in the project, and create a plan of how well these tests are implemented to test the functionality at the core of the project, how well these tests actually fully cover desired behavior and edge cases, whether the tests are formally correct, and whether there is any redundancy in the tests or documentation for them
+    - Develop a plan for how to address these concerns point by point
+2. Develop summary assessment of codebase
+    - Look through all of the source files currently in the project's main modules, and create a plan of how well-implemented, efficient, and generalizable the current implementation is, as well as whether there is adequate, too sparse, or too verbose documentation
+    - Develop a plan for improvements, tweaks, or refactors that could be applied to the current codebase and its documentation
+3. Create issue and subissues
+    - Create a base issue in chainlink for this adversarial review
+    - Create subissues for each of the plan items addressed in steps 1 and 2.
+4. Address all subissues for this adversarial review
+    - Ordered by priority, address and close each of the subissues identified
+    - Provide thorough documentation of each step you take in the chainlink comments
+
+## Constraints
+
+- **Adversarial**: You are engaging in this task from the perspective of a reviewer that is hyper-critical.
+- **Optimize code contraction**: You are operating as one half of a cyclical dyad, in which the other half is responsible for generating a lot of code, but has a propensity to write too much, and write implementations that are verbose, inefficient, or inaccurate at times. Your job is to be the critical eye, and to identify and implement revisions that make the code concise, efficient, and formally correct.
+- **Consider test correctness**: The tests you are presented with are not necessarily complete for covering the desired functionality. Think through ways in which you could make the test suite more accurate to the task at hand, and also of ways in which you could test the codebase's functionality that are not currently addressed. Be creative and leverage web search in this endeavor to see current best practices for the problem that could aid developing tests.
+- **Preserve documentation for API generation**: This project uses quartodoc to auto-generate API documentation from docstrings. Docstrings are a feature, not bloat. When reviewing documentation verbosity, apply these rules:
+    - **KEEP**: Module-level docstrings, class-level docstrings, `Args:`, `Returns:`, `Raises:`, `Examples:` sections on all public APIs
+    - **KEEP**: Docstrings that explain *why* something works a certain way, non-obvious behavior, or protocol/interface contracts
+    - **KEEP**: `Examples:` sections — these render as live code samples in the docs site
+    - **TRIM**: Docstrings that *only* restate the function signature with no added value (e.g. "`name: The name`" when the type hint already says `name: str`)
+    - **TRIM**: Multi-paragraph explanations on private/internal helpers where a one-liner suffices
+    - **NEVER REMOVE**: Docstrings from public API methods, protocol definitions, or decorated classes
+    - When in doubt, leave the docstring. A slightly verbose docstring that helps a user is better than a missing one that forces them to read source.
+- **Batch mechanical fixes**: Group similar changes (e.g. all weak assertion fixes) into a single commit rather than one subissue per file. Reserve individual subissues for changes that require design thought.
+- **Close low-value issues**: If a finding would add complexity, risk regressions, or save fewer than 10 lines, close it as "not worth the churn" with a comment explaining why.

.claude/commands/changelog.md

@@ -0,0 +1,61 @@
+---
+allowed-tools: Bash(git log:*), Bash(git tag:*), Bash(git diff:*), Bash(chainlink *)
+description: Generate a clean CHANGELOG entry from recent work
+---
+
+## Context
+
+- Current version: !`grep '^version' pyproject.toml`
+- Recent tags: !`git tag --sort=-creatordate | head -5`
+- CHANGELOG head: !`head -20 CHANGELOG.md`
+- Recent chainlink issues: !`chainlink list`
+
+## Your task
+
+Generate a properly structured CHANGELOG entry for the current release, following [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format.
+
+### 1. Gather changes
+
+Identify all changes since the last release by examining:
+- `git log --oneline <last-release-tag-or-branch>..HEAD` for commit messages
+- `chainlink list` for closed issues and their descriptions
+- `git diff --stat <last-release-tag-or-branch>..HEAD` for files changed
+
+### 2. Categorize changes
+
+Sort changes into Keep a Changelog sections:
+
+- **Added**: New features, new files, new public APIs, new test suites
+- **Changed**: Modifications to existing behavior, refactors, dependency updates, CI changes
+- **Fixed**: Bug fixes, lint fixes, CI fixes
+- **Deprecated**: Newly deprecated APIs (with migration path)
+- **Removed**: Removed features, deleted files, removed APIs
+
+### 3. Write the entry
+
+Follow these formatting rules:
+- Each item should be a concise, user-facing description — not a chainlink issue title
+- Group related changes under bold sub-headers (e.g. **`LocalDiskStore`**: description)
+- Use nested bullets for sub-items that belong to a feature group
+- Omit internal-only changes (individual subissue closes, review assessments, investigation tickets)
+- Include GitHub issue references where relevant (e.g. `(GH#42)`)
+- Do NOT include chainlink issue numbers — these are internal tracking
+
+### 4. Update CHANGELOG.md
+
+- Insert the new version section between `## [Unreleased]` and the previous release
+- Leave `## [Unreleased]` empty at the top
+- Do not modify any existing release sections below
+
+### 5. Verify
+
+- Confirm the CHANGELOG renders as valid markdown
+- Confirm no chainlink auto-appended entries leaked into existing release sections
+
+## Constraints
+
+- Follow Keep a Changelog format strictly
+- Write for the library's users, not for internal tracking
+- Consolidate — 5 well-written bullets are better than 30 issue titles
+- Preserve existing release sections exactly as they are
+- If chainlink has appended noise to existing sections, clean it up

.claude/commands/release.md

@@ -0,0 +1,61 @@
+---
+allowed-tools: Bash(git *), Bash(gh *), Bash(uv lock*), Bash(uv run ruff*), Bash(uv run pytest*), Bash(chainlink *)
+description: Prepare and submit a beta release
+---
+
+## Context
+
+- Current branch: !`git branch --show-current`
+- Recent commits: !`git log --oneline -15`
+- All branches: !`git branch --list 'release/*' | tail -5`
+- Current version: !`grep '^version' pyproject.toml`
+- Remotes: !`git remote -v`
+
+## Your task
+
+The user will provide a version string (e.g. `v0.3.0b2`). Perform the full release flow:
+
+### 1. Validate preconditions
+- Confirm all tests pass: `uv run pytest tests/ -x -q`
+- Confirm lint is clean: `uv run ruff check src/ tests/`
+- Confirm no uncommitted changes (other than `.chainlink/issues.db`)
+- Identify the previous release branch to branch from (e.g. `release/v0.3.0b1`)
+- Identify the feature branch to merge (current branch or ask user)
+
+### 2. Create release branch
+- Stash any uncommitted changes
+- `git checkout <previous-release-branch>`
+- `git checkout -b release/<version>`
+- `git merge <feature-branch> --no-ff --no-edit`
+- `git stash pop` (if anything was stashed)
+
+### 3. Prepare release
+- Bump version in `pyproject.toml`
+- Run `uv lock` to update the lockfile
+- Run `/changelog` skill to generate a clean CHANGELOG entry (or generate one manually following Keep a Changelog format with Added/Changed/Fixed sections)
+- Run `uv run ruff check src/ tests/` and fix any lint errors
+- Run `uv run pytest tests/ -x -q` to confirm tests pass
+
+### 4. Commit and push
+- `git add pyproject.toml uv.lock CHANGELOG.md .chainlink/issues.db`
+- `git commit -m "release: prepare <version>"`
+- `git push -u origin release/<version>`
+
+### 5. Create PR
+- Create PR to `upstream/main` using `gh pr create`:
+  - `--repo forecast-bio/atdata`
+  - `--base main`
+  - `--head release/<version>`
+  - Title: `release: <version>`
+  - Body: summary of changes from CHANGELOG, test plan with pass counts
+
+### 6. Track in chainlink
+- Create a chainlink issue for the release, close when PR is submitted
+
+## Constraints
+
+- Always use `--no-ff` for merges to preserve branch topology
+- Always run `uv lock` after version bumps — stale lockfiles break CI
+- Always run lint check before committing — ruff errors break CI
+- Never force-push to release branches
+- The CHANGELOG should follow Keep a Changelog format with proper Added/Changed/Fixed sections, not a flat list of chainlink issues

.github/workflows/uv-test.yml

@@ -17,7 +17,7 @@ concurrency:
 jobs:
   lint:
     name: Lint
-    runs-on: ubuntu-latest
+    runs-on: forecast-ci-linux-x64
     steps:
       - uses: actions/checkout@v5
 
@@ -37,7 +37,7 @@ jobs:
 
   test:
     name: Test (py${{ matrix.python-version }}, redis${{ matrix.redis-version }})
-    runs-on: ubuntu-latest
+    runs-on: forecast-ci-linux-x64
     environment:
       name: test
     strategy:
@@ -78,7 +78,7 @@ jobs:
 
   benchmark:
     name: Benchmarks
-    runs-on: ubuntu-latest
+    runs-on: forecast-ci-linux-x64
     needs: [lint]
     permissions:
       contents: write