docs: add release and testing notes

AGENTS.md

@@ -134,6 +134,7 @@ Use the tool's common name (e.g., GitHub Copilot, Cursor, etc.).
 - Use `gh_run` fixture for CI-aware tests (see `test/conftest.py`)
 - Mark tests checking LLM output quality with `@pytest.mark.qualitative`
 - If a test fails, fix the **code**, not the test (unless the test was wrong)
+- **Static type checks** live in `test/typing/` as `check_*.py` files (not `test_*.py`, so pytest skips them). They use `typing.assert_type` inside function bodies to verify overload resolution and generic parameterization — e.g., that `session.aact(..., await_result=True)` narrows to `ComputedModelOutputThunk[str]`. Verification happens via `uv run mypy .`; the functions are never executed. Add a new `check_*.py` here when introducing or modifying `@overload` signatures or generic type parameters on public APIs.
 
 ## 12. Writing Docs
 

RELEASE.md

@@ -14,6 +14,11 @@ This schedule may shift depending on team availability, urgency of fixes, and th
 ## Versioning
 This project follows **[Semantic Versioning (semver)](https://semver.org)**. Breaking changes must be clearly documented and highlighted in release notes.
 
+To see the current, **prospective** version that will be published by the next release action, you can run:
+```
+uv run --no-sync semantic-release print-version
+```
+
 ## Pre‑Release Coordination
 ### 1. Identify Candidate Pull Requests
 Early in the week, maintainers review open pull requests and determine which ones should be included in the upcoming release.