Receipts-first: the raw git changelog Angi will never publish

The /changelog page at askbaily.com publishes the raw git log of our public codebase. Not a marketing-edited "what's new" list. Not a curated roadmap. The actual commits: 40-character SHA, committer, committer date, commit message, and a link to the file manifest. Wave 223 seeded the page with roughly 40 entries and every subsequent ship has appended the new commits automatically as part of the deploy pipeline.

This post is about the strategic choice to publish the raw log and the engineering discipline required to make the log publishable without exposing internal-only context.

What the page shows

Each entry in /changelog is a commit row. The row renders the 8-character short SHA (with the full 40-char SHA revealed on hover), the commit message (typically "Wave N — <description>" following our commit convention), the committer name, the committer date in ISO format, and a link to a file manifest showing which files the commit touched. The manifest lives at /changelog/{short-sha}/files and lists file paths with insertion/deletion line counts. Content of files is not linked; this is a manifest of what changed, not a public-source-code view.

The page is newest-first, grouped by date. Deploys that contain multiple commits are shown as a deploy cluster with the individual commit rows nested. The newest entries as of this post include Wave 223 itself (commit 47ebea02), Wave 221 (commit b8afe842), Wave 219 (commit f7ed00e9), and dozens more going back to Wave 175 when the transparency cluster shipped.

How the pipeline works

The deploy pipeline's final step, after a successful Cloudflare Pages deploy, runs a post-deploy hook that queries git log for commits new since the previous deploy, strips private/internal-only metadata (reviewer signoffs, internal ticket references, sensitive path fragments), and appends the cleaned entries to the /changelog registry. The registry is a JSON file checked into the public repo; the append is itself a commit, which shows up in the next deploy's changelog.

The stripping step is small but important. A raw git log contains references to private repositories, internal Jira tickets, and occasionally paths that reveal nothing sensitive but are not meant for public discussion. The strip rules are documented in scripts/changelog-clean.ts and reviewed quarterly by the ops team. Any commit whose message would leak secrets or reveal a private integration gets a redacted summary instead of the raw message.

Why publish the raw log

Three reasons. First, it is the single strongest receipts-first artifact we can produce. Anyone questioning whether AskBaily actually ships what we claim — whether the license verifier is real, whether the agent fleet is live, whether the /roadmap entries match actual code — can open /changelog, read the commits, and cross-check against the file-manifest hashes.

Second, it raises the cost of marketing-blog-style claims. If I write a post that says "we shipped Wave N" and the changelog does not contain the commit, readers will notice. The log is a public accountability mechanism. Every claim in this blog, including this post, is cross-referenceable against commits in the log.

Third, it changes the ops culture internally. When you know the commit is going to be published, you write cleaner commit messages. Internal noise — "fix typo in test description," "retry CI" — gets squashed before the deploy rather than after because the engineer knows the noise is about to be visible.

The CC-BY-4.0 choice

The changelog dataset is CC-BY-4.0. Any researcher, journalist, or competitor can reuse it with attribution. The reuse case we care about is external scrutiny: someone analyzing the category can point at /changelog and compare our ship rate, our commit discipline, and our feature trajectory to any other platform that publishes similar data. (So far, none do, which is the point of the post.)

The discipline required to publish it

Three commitments are required to keep the pipeline working. First, commit messages have to follow the "Wave N — <description>" convention. Messages that violate the convention break the /changelog grouping and force manual cleanup. Every engineer on the project knows the convention and enforces it at code review.

Second, sensitive data cannot leak into commits. API keys, credentials, internal URLs, and customer-identifying information are scrubbed at pre-commit by a .git hook that greps the diff for patterns before the commit lands. A violation blocks the commit. The hook is in the public repo at .githooks/pre-commit so other teams can adopt the pattern.

Third, the /changelog entries cannot be edited after publication. If an entry is wrong, the correction is a new commit, visible in the changelog with its own entry. The append-only property is load-bearing; a changelog that can be rewritten is not a changelog.

What Angi and Thumbtack cannot copy

They cannot publish their raw commit log. Not because they lack the engineering — every modern platform runs git and could technically pipe the log to a public page — but because their commit log would reveal three things their business model depends on hiding.

First, the relative investment allocation between customer-facing features and ad-inventory optimization. Angi's commit log is almost certainly dominated by advertiser-side features, lead-scoring tweaks, and attribution-pipeline updates. Publishing it would force them to explain the ratio of homeowner-trust investment to lead-volume investment.

Second, the existence of private-integration work that, if named, would invite regulator attention. A platform routing leads to contractors has integration points with data brokers, skip-trace providers, and signal-buyers that are not the kind of thing a public changelog would render in a flattering light.

Third, the deploy cadence itself. A platform that deploys rarely but claims constant innovation has a problem when the commit log shows the rarity. A platform that deploys constantly but changes nothing user-facing has a different problem when the commits show the churn. We ship often, we ship visibly, and we ship with commit messages that map to public waves. The log proves it.

The log is the artifact. The discipline to produce a publishable log is the moat. We invest in the discipline because the artifact is worth it.