Fix red CI: install the dev extra, and let package doctests run

[thorwhalen]

CI has been red on main since the Phase 1 backend commit (run 27911312182). This makes it green.

Root cause

Failing job ci / Validation (3.12), failing step Run Tests, exit code 2 — a collection error, not a test failure:

Running: .venv/bin/python -m pytest --doctest-modules -o doctest_optionflags=... -v --tb=short
collecting ... collected 5 items / 2 errors

ERROR collecting tests/test_ingest.py
tests/test_ingest.py:4: in <module>
    from fastapi.testclient import TestClient
fastapi/testclient.py:1: in <module>
    from starlette.testclient import TestClient as TestClient
starlette/testclient.py:41: in <module>
E   RuntimeError: The starlette.testclient module requires the httpx2 package
E   to be installed.

Two steps earlier in the same log, the install step shows why:

if [ -n "" ]; then
  uv pip install -e ".[]"
else
  uv pip install -e .          <-- this branch ran
fi

The wads reusable workflow installs -e . plus only the extras named in [tool.wads.ci.install].extras. That key was unset (it defaults to none), so the dev extra — which is where the HTTP client the FastAPI TestClient needs is declared — was never installed. Every test module importing fastapi.testclient then failed at import, and pytest aborted collection.

Nothing about the package code was wrong. It was green months ago because the repo had no test touching fastapi.testclient yet.

What changed (pyproject.toml only — no package code)

1. [tool.wads.ci.install] extras = "dev" — the actual fix. CI now runs uv pip install -e ".[dev]" instead of bare uv pip install -e ..
2. httpx2 added beside httpx in the dev extra. starlette >= 1.0 imports httpx2 first and only falls back to httpx with a StarletteDeprecationWarning; starlette < 1.0 knows httpx alone. CI resolves starlette 1.3.1, the shared local dev environment has starlette 0.49.3. Declaring both makes the suite collect on either resolution — they are distinct top-level modules and coexist cleanly.
3. testpaths widened from ["tests"] to ["tests", "heed"]. wads CI runs pytest --doctest-modules with no path argument, so collection is driven entirely by testpaths. With ["tests"] the package's own doctests never ran and CI still reported on them as if they had. The usage doctest in heed/__init__.py now actually executes (and passes). All package modules import cleanly with only core deps — ghapi is already lazy-imported inside GitHubIssuesSink, so --doctest-modules does not drag in the optional [github] extra.
4. Corrected a stale comment that claimed the PyPI name heed was reserved for this repo. It is not — see Decision needed: the PyPI name heed is taken — pick a distribution name before first release #11. Publishing remains disabled either way.

Verification

Reproduced and fixed locally in clean uv venvs before pushing, using the exact CI command:

environment	before	after
clean venv, -e . only, py3.12	2 collection errors, exit 2	—
clean venv, -e .[dev], py3.10	—	10 passed
clean venv, -e .[dev], py3.12	—	10 passed

uvx ruff check --output-format=github heed exits 0; ruff format reports no Python file needing reformatting.

Local dependents gate (priv test-dependents heed): baseline 1 suites: 1 pass, 0 fail, 0 no-tests → final 1 suites: 1 pass, 0 fail, 0 no-tests. No regression.

Branch CI: run 30858780626 — success.

ci / Read Configuration     :: success
ci / Validation (3.10)      :: success
ci / Validation (3.12)      :: success
ci / Windows Tests          :: skipped   (test_on_windows = false)
ci / Publish                :: skipped   (publish disabled + not default branch)
ci / Publish GitHub Pages   :: skipped   (not default branch)

The branch log confirms the fix took effect end to end: uv pip install -e ".[dev]", + httpx2==2.9.1, collected 10 items, 10 passed.

Merging this does NOT publish a release

[tool.wads.ci.publish] enabled = false in this repo, so the Publish job stays skipped on main. Nothing goes to PyPI. (It could not anyway — see #11.)

One thing to expect on the first main run: the Publish GitHub Pages job runs only on the default branch, so it has not been exercised by this branch. It should self-configure — the epythet action POSTs the Pages config itself and is idempotent — but it is unverified here.

Left undone (deliberately)

• The repo-audit HIGH finding "PyPI version (0.1.0) is AHEAD of pyproject (0.0.1)" is a false positive: PyPI heed is an unrelated project, and this repo has never published. Recorded in Decision needed: the PyPI name heed is taken — pick a distribution name before first release #11 rather than "fixed".
• Remaining audit findings are separate dimensions, untouched by this PR: no LICENSE file (the project declares Apache-2.0 in metadata), license still in the deprecated table form, no classifiers, no .editorconfig, and GitHub description/homepage/topics drifted from pyproject.toml.
• ruff format wants to reformat Python code blocks inside one misc/docs/ markdown file. Harmless — the CI format step runs in place and does not fail — but left alone so this PR stays one dimension.

Opened as part of a fleet-wide CI modernization pass and left for you to review and merge.