v0.6.1 — polish cache key normalization + __version__ sync
Why this exists
The 0.6.0 polish cache shipped functional but never actually hit in practice — the Jinja-rendered template embeds a fresh generated_at: <ISO-8601> timestamp on every render, so the SHA-256 cache key changed every run and the LLM was always called.
Measured impact
Smoke test against attune-author itself, regenerating the template-generation feature (3 templates):
| Run | Wall time | LLM calls |
|---|---|---|
| Cold (cache empty) | 12.9s | 3 |
| Warm (pre-fix, 0.6.0) | 12.5s | 3 (unchanged) |
| Warm (post-fix, 0.6.1) | 0.13s | 0 |
99% wall-clock reduction on the warm path. This is the speedup the cache was supposed to deliver in 0.6.0.
Fix
polish.py now normalizes the cache key by stripping known volatile frontmatter fields before hashing — currently just generated_at, but structured as a tuple so future fields can be added in one place. The LLM still sees the real content with the live timestamp; only the key is normalized.
Also fixed
attune_author/__init__.py had __version__ = "0.5.0" baked in even though pyproject had moved through 0.5.1 and 0.6.0. Now synced to 0.6.1.
Tests
Two new tests in test_polish_cache.py lock the contract:
test_volatile_generated_at_does_not_invalidate_cache(end-to-end viapolish_template+ mocked LLM)test_normalize_for_key_strips_generated_at(unit-level, confirmssource_hashis preserved)
Full suite: 526 passed, 31 skipped. All 12 CI matrix combinations green.