[mendezr]

Summary: Bluefin’s update-size reports could silently change older measurements when a published release was replaced. This change keeps published measurements unchanged and adds measurements only for newer releases, so readers can trust the history they have already seen.

---

Changes

• Preserve published release records and their original tag/previousTag pairs, including history outside the discovery window.
• Fetch manifests only for new comparisons and their predecessors. Missing manifests leave gaps instead of creating false baselines or comparisons across missing releases.
• Add offline regression tests for unchanged history, new points, repeated runs, initial baselines, and registry failures.
• Document the append-only policy in the update-churn skill.

Fixes #1516. The unrelated bot-list finding folded into that issue is tracked separately in #1603; #1602 only changes the contributor metrics tracker.

Validation

• node --test scripts/fetch-update-churn.test.js: 31 passed.
• npm test: 1,358 passed.
• npm run lint: passed with 269 existing warnings, no errors.
• Prettier on all three changed files and git diff --check: passed.
• just check: blocked at typecheck because this fresh checkout lacks six generated JSON imports: image-releases, playlist-metadata, file-contributors, github-repos, portal-contributors, and blog-posts. Lint and tests were then run separately.

No generated data was edited. Existing published values are frozen as found; this does not attempt to reconstruct values overwritten by earlier runs.

— hive: backend=pi model=openai-codex/gpt-6.1-sol

---

🐝 Hive Agent: contributor | SHA: b6b55b00

[hivecommons-hive]

Summary: This change stops the update-size report from silently rewriting measurements it has already published, which is what the linked issue asked for. It works for the images that publish one dated tag per release. It does not fit Dakota, whose only tracked tag is a floating name that always points at today's build: after this change Dakota's single size figure is frozen at the day it was first measured and will never move again. One sentence in the pipeline guide is also now out of date.

What I need from you: Recompute floating-tag points (Dakota) instead of freezing them, and fix the stale guide sentence.

---

correctness

• Dakota's floating stable point is frozen permanently (scripts/fetch-update-churn.js:860-872, :448-476). Dakota has defaultTags: ["stable"] and no tagSeries (scripts/fetch-update-churn.js:118-126). Its published record is {tag:"stable", previousTag:null, isBaseline:true, totalMB:3507.4, date:"2026-10-22"} (static/data/update-churn.json). On the next run appendTags is ["stable"], lastTag is "stable", start becomes 1 === tags.length, so appendReleaseChurn returns published untouched and getPlatformLayers is never called. The guide itself says a floating name "point[s] at the newest manifest" (docs/skills/update-churn-pipeline.md:75-76), so this record is a snapshot, not history; the issue's decision was about re-pushed dated tags. Before this PR the point was recomputed each run (main at merge-base, old releaseManifests loop). Suggested fix — only freeze images that have a dated series:

--- a/scripts/fetch-update-churn.js
+++ b/scripts/fetch-update-churn.js
@@ -828,10 +828,13 @@ async function main() {
       .slice(tagSeries && seriesListed ? -tagSeries.limit : undefined);
 
-    if (
-      tagsToInspect.length === 0 &&
-      !existingData?.images?.[id]?.releases?.length
-    ) {
+    // A floating tag (`stable` on Dakota) names the newest manifest, so its
+    // published point is a snapshot, not history: recompute it every run.
+    // Only dated series are append-only.
+    const published = tagSeries
+      ? existingData?.images?.[id]?.releases || []
+      : [];
+
+    if (tagsToInspect.length === 0 && published.length === 0) {
       imagesOutput[id] = {
@@ -847,7 +850,6 @@ async function main() {
       continue;
     }
 
-    const published = existingData?.images?.[id]?.releases || [];
     // Keep the published tail in the sequence even after it leaves the discovery

Plus one test: appendReleaseChurn(["stable"], [], load) must call load("stable"), and a main-level check that a tagSeries-less image passes [] as published.

• Series now grows without bound (scripts/fetch-update-churn.js:449, :860-872). results = [...published, ...new] is never trimmed, so UTAH_TAG_LIMIT = 14 / BLUEFIN_TAG_LIMIT = 30 (:83, :93) now only bound how many new tags are inspected. Utah ships up to ~20 builds a day (docs/skills/update-churn-pipeline.md:70-71); the committed JSON will add that many points per day indefinitely, with no /analytics consumer today (docs/skills/update-churn-pipeline.md:21-23). Not blocking — retaining history is the PR's stated choice — but worth a deliberate cap or a note that the file is expected to grow.

docs-currency

• Step 1 still says "limit then trims the merged list, so a seed older than the discovered window cannot push the series past the limit" (docs/skills/update-churn-pipeline.md:98-100), which the new step 2 ("Retain published history outside the discovery window", :107) contradicts: the written series can and will exceed limit.

     is never trimmed against the order used for diffing. `limit` then trims the
     list of tags inspected this run, so a seed older than the discovered window
     cannot add new points past the limit; published history retained by step 2
     is not subject to it.

No findings from: security, intent-alignment, style.

Confidence: 3/5 (needs attention) — 1 medium finding; 2 perspectives requested changes

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[Danathar]

Reviewed at b6b55b0: makes the update-churn data append-only. Published release points are kept as-is, and only releases after the last published tag are measured, each against its actual predecessor; missing manifests leave gaps instead of fabricated baselines. It reuses the existing getPlatformLayers registry lookup (no new access), adds offline regression tests, and documents the policy in the skill. CI is green. Adding it to the merge queue (fixes #1516).