DataTalksClub / DataTalksClub/website

Reconcile non-reproducible public projection after face8e4

Open
#253 20 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug content infra operations P0 seo testing
Dominant language
Python
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Product outcome

Restore a truthful, deterministic source-to-projection contract after the face8e4808d65afbf0374d1ced7a88079950d663 release candidate failed closed. The checked projection must be reproducible from clean immutable source checkouts with the supported generator before terminology hashes, manifest/tree digests, CI, or deployment can be accepted.

Current PM disposition: blocked and returned to grooming. Do not dispatch engineering while needs grooming remains. The prior PM contract and its face8e4 artifact/manifest/tree hash bindings are superseded by the independent regeneration evidence below.

Normative authority

  • _docs/PROCESS.md — role separation, blocked dependencies, full terminal release evidence.
  • _docs/specs/02-url-link-seo-compatibility.md — established editorial/course/asset URL compatibility.
  • _docs/specs/03-github-content-and-people.md — immutable editorial source ownership, source checksums, media provenance, and duplicate podcast-event relationship suppression.
  • _docs/specs/10-verification-strategy.md and _docs/ci/change-selective-ci.md — generated-artifact, render, screenshot, and full release gates.
  • #105 — deterministic baked public projection and complete manifest/tree provenance.
  • #216 — accepted S24E06 page outcome and explicit requirement that S24E06 use its own source-bound artwork.
  • #119 — podcast catalogue/transcript identity and the general .html detail contract.
  • scripts/build_public_projection.py — sole supported checked-projection producer; hand-edited generated JSON is never source authority.

Release incident

Run 33295699282 was the push from 9a491cd9baeb1e723bd05e8dacb20978fbaf9d33 to face8e4808d65afbf0374d1ced7a88079950d663 (16 commits). Quality failed on frozen terminology hashes for podcasts.json, wiki.json, and wiki_search.json; downstream Django, Playwright, container, publish, and deploy did not complete. The SHA has no green/deployed verdict and must not be rerun unchanged.

Fail-closed regeneration evidence

The engineer used clean checkouts at the exact pins previously named in this issue and ran the supported preferred generator twice into separate project-local scratch outputs. The two outputs are byte-identical to each other: 1,267 files, empty complete-tree diff, and unchanged aggregate counts of 55 articles, 205 podcasts, 203 transcripts, 98 books, 438 people, 421 events, 282 Wiki pages, 12 courses, and 1,253 media records.

They are not byte-identical to checked face8e4. The complete checked-versus-regenerated tree has nine path mismatches:

  • seven differing JSON files: articles.json, courses.json, editorial_route_migration.json, manifest.json, media.json, people.json, and podcasts.json;
  • checked asset media/podcast/s24e06-how-to-build-ai-that-actually-ships-in-production.jpg versus regenerated .../s24e07-...jpg (same 38,743 bytes and content SHA-256 f930cd185a60a6478695db674b38e90689aae68628df2aad554d8a5c2386c374).

wiki.json and wiki_search.json reproduce exactly. Their checked face8e4 bytes are therefore not implicated by source/generator drift, although their terminology allowlist entries still need the ordinary reviewed hash update caused by the 16-commit lane.

Exact leaf-delta census for the seven JSON mismatches:

Artifact Exact checked-versus-regenerated delta
articles.json 5 URL scalars in ai-dev-tools-zoomcamp: checked aishippingblog.com, pinned source/regeneration alexeyondata.substack.com
courses.json all 12 public_path scalars: checked family/year paths, current generator slug paths
people.json 1 extra regenerated relationship: Alexey Grigorev → podcast-type event “Roles in a Data Team”
podcasts.json S24E06 image_path is checked s24e06 versus source/regenerated s24e07; source checksum is checked 62554e... versus actual/regenerated 47c8d1...
media.json 6 identity/path/provenance scalars for the same artwork filename (s24e06 versus source s24e07)
editorial_route_migration.json 5 derived digest/provenance scalars caused by the article/people/podcast divergence
manifest.json 6 artifact digests plus the complete tree digest

Regenerated podcasts.json is 418456fb37fb88a9ff9aebd06e35bb18ec35f32122711ab318edac60177346c8, regenerated manifest is 80e1267d909e2fea854eea5bead37f8ec8d8171bde5ee9a58b721bfe6a07607a, and regenerated tree is dc1b91f1ea99fcede2c172f46731cacc6c102ffc3e456bc19d73439233f1933b. These values describe the current stale-source/current-generator output; they are evidence, not accepted forward bindings.

Provenance determination

This is not a legitimate case for blessing the checked face8e4 hashes:

  1. DataTalksClub/content@e29f56ce70bd997171a78a9f0facc9354797f421 contains S24E06 metadata pointing to images/podcast/s24e07-...jpg; the YAML really hashes to 47c8d1..., and the immutable source tree contains only the s24e07 filename. Replacing that one source scalar with s24e06 produces the previously claimed 62554e... checksum, but that repair is absent from the pinned commit.
  2. The same pinned source article contains the five alexeyondata.substack.com links. Target commit e40b98e changed the five checked projection links to aishippingblog.com without advancing the source or teaching the generator that transformation.
  3. Target commit 641d517 introduced the accepted family/year course paths and generator logic, but a later generator replacement lost that logic while the checked courses.json retained the accepted output.
  4. Event identity migration changed the podcast-event lineage lookup to use a source key while the lineage map remains keyed by projected event slug. That makes regeneration add one duplicate podcast-type event relationship contrary to specification 03’s suppression rule.
  5. #216 accepted S24E06-owned artwork and described it as a source correction, but the corresponding immutable content-source correction was not present at the pinned revision. Its generated podcast/media/provenance bytes therefore cannot be reproduced from that source.
  6. The later 16-commit lane edited generated artifacts and recomputed manifest bindings while inheriting these earlier source/generator divergences. It did not include a new immutable DataTalksClub/content pin containing the article/artwork repairs. This is a provenance/process discontinuity, not a blame finding.

A manifest can be internally self-consistent while still binding bytes that the supported generator cannot derive from its declared sources. face8e4 manifest/tree/artifact hashes therefore have no authority merely because they are checked.

Blocking prerequisite: content-source repair

The accepted #216 and AI Shipping Blog outcomes should not be silently rolled back to stale source bytes. Before this website issue can be made engineer-ready, the DataTalksClub/content owner must publish and validate one immutable source revision that:

  • renames images/podcast/s24e07-how-to-build-ai-that-actually-ships-in-production.jpg to the S24E06 filename without changing its bytes (f930cd...);
  • changes the S24E06 podcast YAML image scalar to that S24E06 source path, yielding the reviewed record checksum for those exact source bytes;
  • changes exactly the five AI Dev Tools article destinations from alexeyondata.substack.com to their already accepted aishippingblog.com destinations, without changing visible text or unrelated article bytes;
  • passes the source repository’s schema/media/link/provenance checks and supplies exact repository URL, commit SHA, tree SHA, CI run, and complete changed-path/digest evidence.

No website engineer may manufacture that source revision, edit an immutable checkout, follow a moving branch, or copy the desired checked JSON back over generated output. Once the source evidence exists, PM must re-groom #253 with its exact new SHA/tree and final semantic census. The source-revision advance will mechanically change provenance in more projection members than the seven currently differing JSON files, so the final affected-path list and hashes cannot be guessed in advance.

Forward website recovery after the prerequisite

The next grooming pass may make one bounded website lane engineer-ready only if it includes all of the following:

  • advance the preferred content source pin, tree, source-CI/evidence bindings, and authoritative spec/provenance records to the repaired immutable revision;
  • restore deterministic generation of the 12 already accepted family/year course paths, with collision and malformed-slug failure;
  • fix podcast-event lineage lookup so the exact duplicate “Roles in a Data Team” speaker relation remains suppressed while unrelated event speaker and podcast guest relationships remain ordered and intact;
  • regenerate the complete public projection twice from clean exact pins, never selected files, and replace checked generated members only from that output;
  • produce a machine-readable old-checked-versus-new-generated complete-tree census separating reviewed product deltas from mechanical source-revision/provenance changes; no unexpected scalar, record, order, cardinality, source, route, or asset delta may remain;
  • update editorial_route_migration.json, manifest.json, every affected artifact/tree/source binding, terminology allowlist entries, relevant compatibility/adoption records, and tests from the final generated bytes—not from the invalid hashes previously pinned here;
  • preserve wiki.json/wiki_search.json semantics and counts, and prove any byte change after the new source pin is provenance-only or return to PM;
  • retain the full 16-commit lane; recovery is a forward correction, not a history rewrite or selective omission.

Acceptance gates to pin in the next grooming pass

These are required boundaries, not yet an engineer handoff:

  • Exact repaired source SHA/tree/CI and complete source changed-path/digest evidence are recorded.
  • Two clean supported regenerations have identical complete trees and match the final checked projection byte-for-byte.
  • The complete semantic census accounts for every changed path and leaf, including source-revision fan-out; no hand-edited generated byte or unexplained digest remains.
  • S24E06 uses the S24E06 source path and unchanged artwork bytes; its episode identity, .html canonical/aliases, Wiki graph/search identity, media provenance, sitemap/feed/SEO, and no-JS rendering remain coherent.
  • The five accepted AI Shipping Blog links are source-derived, safe HTTPS destinations with visible text/order unchanged.
  • All 12 course projection paths remain the accepted family/year routes and match target runtime route ownership.
  • The duplicate podcast-type event relationship is suppressed; legitimate person author/guest/speaker/book-author relationships remain complete and ordered.
  • Manifest artifact/source/count/tree validation, terminology exact-count/hash/tamper checks, route/link/SEO validation, and dirty/wrong-origin/wrong-SHA/missing/oversized source failures pass.
  • Focused builder, source adapter, public-data, course-route, person-relation, podcast/media, terminology, manifest, link, and SEO tests pass, followed by the graph-selected full quality/Django/Playwright/container envelope and terminal release evidence.
  • Render/screenshots are applicable: the source-derived article links and representative podcast artwork path affect rendered pages. Independent tester captures and inspects the affected article and S24E06 episode at desktop/mobile plus required no-JS/mobile boundaries; no broken image, stale destination, debug page, overflow, or sensitive data is accepted.
  • After tester PASS and PM acceptance, only a new exact SHA may proceed through quality, Django, Playwright, screenshots, container, ci-gate, publish, deploy, and healthy/ready identity. Cancelled run 33295699282 evidence is not reusable success.

Strict non-goals

  • No approval of face8e4, current-regeneration, manifest, tree, or allowlist hashes without repaired immutable source and two complete reproductions.
  • No hand-editing generated JSON/assets/provenance, rewriting checksums, weakening terminology/count/tree/source checks, partial regeneration, ad-hoc retry, quarantine, test removal, or unchanged-red workflow rerun.
  • No silent rollback of the accepted S24E06 artwork, AI Shipping Blog links, family/year course routes, or duplicate podcast-event suppression.
  • No unrelated editorial rewrite, global podcast route redesign, source-runtime network access, database/model/migration change, provider mutation, production data, history rewrite, commit, push, merge, or deploy during grooming.
  • No blame assignment.

Lifecycle

needs grooming remains because the repaired immutable source identity and its source-revision fan-out do not yet exist. decision is not required: #216 and the checked target history already establish the intended artwork/link/course/relationship outcomes. When the external source prerequisite is complete, PM must replace this blocked contract with exact new pins, final affected paths/digests, and engineer-ready acceptance before implementation resumes.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with _docs/PROCESS.md, _docs/specs/10-verification-strategy.md, scripts/build_public_projection.py, and the evidence from run 33295699282. Do not begin implementation until the repaired immutable content source SHA, tree, CI evidence, and final grooming census exist. Done means two clean supported regenerations match the complete checked projection and all listed validation, focused, integration, and release gates pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github-actions, python
Domain
build-system, ci-cd, content, release, testing-qa
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.