[Polichinel]

What this release is for, stated before anything else

The wheel is code-identical to v1.14.0. Not one file under src/ changed:

$ git diff --name-only v1.14.0 origin/development -- src/
(empty)

[tool.hatch.build.targets.wheel] packages only the nine src/datafactory_* trees, so a consumer
installing views-datafactory==1.15.0 from PyPI gets exactly what 1.14.0 gave them, with different
version metadata.

That is the point, not a defect. The server deploys by git tag (ADR-022): refresh_pipeline.sh
reads ~/.views-deploy-tag and checks out that exact tag. The two things this release carries — a
script (scripts/export_zarr.py) and a set of guides — reach production no other way. There is no
path by which a PyPI publish deploys a script that the wheel does not contain.

Precedent, so this is not a new shape: v1.11.0 and v1.12.0 each changed zero files under
src/ and were each cut as a minor bump. v1.11.0's own commit subject says it — "a release whose
only shipped change is a dependency floor". Minor, not patch, follows the house convention twice
over rather than a judgement made here.

Why now, and why it is time-boxed

#502 merged the only instrument that can answer #501: the zarr export's wall time broken into four
phases. It is on development and therefore nowhere the server can see it.

The monthly cron fires 00:00 on the 21st — two days out. A tag before then gets the measurement
on a run that was happening anyway. Missing it means either a deliberate out-of-band run of a
six-hour pipeline or waiting until 21 November: five weeks with the instrument built, merged and
idle.

What is in the diff

File	Change
pyproject.toml	version = "1.14.0" → "1.15.0"
reports/product_development_plan12.md	title through v1.14 → v1.15, plus the v1.15 addendum

Nothing else. No code, no tests, no behaviour.

The two edits are coupled, and a drill proves it

TestF7ProductPlanCurrency asserts the product plan's title carries the current minor version. The
version bump alone turns it red, so the plan edit is not housekeeping tacked on — it is the other
half of one atomic change.

Confirmed by breaking it rather than by reading it:

Drill	Result
title reverted to through v1.14, version left at 1.15.0	TestF7ProductPlanCurrency FAILED — Current: 1.15.0, plan: '… through v1.14 …'
title restored	green

What the addendum says that a reader will not find elsewhere

It records the measurement that motivated the release — 21,007s total, 18,427s in the export, 88% of
the pipeline, against ADR-041's Context figure of ~57 minutes — and it carries the #501
falsification criterion into the plan rather than leaving it only in an issue comment: if scan
comes in under ~25% of the export, the strided-memmap explanation is refuted and abandoned.

Every figure in it was checked against the repo rather than carried over from chat. The one claim
worth naming because it is load-bearing for the "not fixed" paragraph: scripts/check_health.py has
26 references to freshness, staleness or age and zero to duration or elapsed time, so nothing
compares run durations across runs. That gap is flagged in the addendum, not fixed here.

Noticed, deliberately not fixed

## Version History in the same plan file stops at v1.6 and jumps to v2.0 — eight releases
happened without it. The per-release addenda at the top are the live record and have been since
v1.7. Repairing a section that has been stale for eight releases is not this PR's job, and doing it
inside a release bump would hide a documentation change inside a version change.

Verification

Check	Result
uv run ruff check .	All checks passed
uv run mypy src/	Success — 89 source files
bash docs/validate_docs.sh	PASSED
uv run pytest (full suite, exit code captured)	see the comment below — exit code reported, not inferred
test_falsification_deploy_v160, _v160_r2, merge_readiness	10 passed, 1 skipped (HEAD not on a tag — expected pre-release)
git merge-base --is-ancestor origin/main origin/development	true — release topology healthy
Remote branches	only development and main; no stale branches, no open PRs

What this PR explicitly does not do

No tag, no GitHub Release, no deploy. Each is separately gated and awaits explicit confirmation.
This PR moves a version number into development; it publishes nothing and changes nothing on the
server.

Refs #501.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EfeuULbPTqrx4qtNki5dy9

[Polichinel]

Full suite result

EXIT=0
FAILED count: 0
ERROR count: 0

Exit code captured rather than inferred from the absence of FAILED lines — 137 is SIGKILL/OOM and prints no failures at all (C-345), so a grep-only check reads an OOM kill as a clean run.

Every non-pass is an XFAIL or SKIP with a written reason: the C-164/C-44 WET-before-DRY deferrals, the four deploy-gate classes that cannot answer outside a release, config_queryset.py (no views_pipeline_core locally), and the staleness probes that need assembled data on disk. None is new to this branch.

The one skip worth naming, because it is the gate this PR is a step toward:

SKIPPED tests/test_falsification_deploy_v160.py:109: HEAD is not on a v* tag —
there is no tag to compare against, and guessing one would be worse than
saying so (C-320). The unskippable half of this check lives in
publish_package.yml, where the triggering tag is known.

test_version_equals_the_tag_head_is_on cannot run here by design. The half that cannot be skipped is in publish_package.yml, which compares github.ref_name against [project].version before the build — so if this bump and the tag ever disagree, the publish fails loudly instead of putting a mislabelled wheel on PyPI.