Pipeline

Version history and changelog of the publishing pipeline. Current version: v3.16.0

v3.14.3 — 2026-06-22

  • Source allowlist: added official/primary and established-outlet domains surfaced as off-allowlist warnings during the 2026-06-22 batch review. Official/primary: splunk.com + advisory.splunk.com (vendor PSIRT advisories for Splunk CVEs), sandboxaq.com (company announcements), ccianet.org (CCIA litigation filings/quotes), mofo.com (Morrison Foerster case analyses), and endoflife.date (authoritative software end-of-life reference). Established trade press: gbhackers.com, socradar.io (security), texastribune.org (Texas policy news), rpgsite.net / tweaktown.com / pushsquare.com (games journalism), and medtechdive.com / medicaldevice-network.com (medical-device industry, surfaced in the 2026-06-23 CMR Surgical review). Marginal aggregators flagged in the same reviews (ts2.tech, quantumzeitgeist.com, universemagazine.com, executivegov.com, digitalapplied.com) were deliberately NOT added. Allowlist matching is exact-hostname, so vendor subdomains each need their own entry. No content-schema or editorial-rule change

v3.14.2 — 2026-06-21

  • Orphan-link false-positive bugfix in scripts/chief_editor_review.ts. The body-vs-article.sources provenance check (findOrphanBodyURLs) matched link destinations with /\]\((https?:\/\/[^)]+)\)/, whose [^)]+ stops at the first ). A Markdown link to a URL containing balanced parentheses — e.g. a Wikipedia disambiguation slug …/Star_Fox_(2026_video_game) — was therefore truncated to …/Star_Fox_(2026_video_game, which never matches the (untruncated) entry in article.sources and was reported as an orphan citation / provenance break. Under v3.9.0 an orphan URL is a blocking error, so a clean submission could be pushed toward REJECT purely by this regex (observed on the 2026-06-18 Star Fox submission, PR #1694, which was a confirmed false positive)
  • Fix: replace the truncating regex with extractMarkdownLinkDestinations(), a scanner that consumes each link destination while tracking parenthesis depth and ends at the ) that actually closes the link (or at whitespace, which in CommonMark begins an optional link title), mirroring CommonMark's balanced-parenthesis rule. Both helpers are now exported and covered by regression tests in tests/chief_editor_review.test.ts (parenthesized URL present in sources → not orphan; genuinely missing parenthesized URL → flagged with both parens intact; plain-URL dedup and link-title handling unchanged)
  • AI-self-reference false-positive bugfix in scripts/chief_editor_review.ts. The editorial-policy check /as an ai/i matched the bare substring, so innocent phrasing such as "selected as an air-taxi partner" or "as an aircraft maker" was flagged as a banned AI self-reference (observed on the 2026-06-19 Archer eVTOL submission, PR #1710). Fix: anchor the three "ai" self-reference patterns with a trailing word boundary (/\bas an ai\b/i, etc.) so they still catch "As an AI…" but not words that merely begin with those letters. PROBLEMATIC_PATTERNS is now exported and covered by regression tests
  • Source allowlist: added official/primary and established-trade domains surfaced as off-allowlist warnings across the 2026-06-18 and 2026-06-19 batch reviews. 06-18: alignment.openai.com, spring.io, nintendo.com, engie.cl, amsterdamumc.org, the pv magazine group (ess-news.com, pv-magazine.com, pv-magazine-latam.com), aikido.dev. 06-19: nginx.org (vendor CVE advisories), gsk.com / us.gsk.com (drug-approval releases), tensordyne.ai, ast-science.com, investors.archer.com, and trade press securityaffairs.com, satnews.com, airwaysmag.com, evtol.news. Allowlist matching is exact-hostname, so official subdomains and product/IR sites each need their own entry. No content-schema or editorial-rule change

v3.14.1 — 2026-06-21

  • Publish submission-detection bugfix in .github/workflows/publish-from-submission.yml. The "Determine submission file" step located the just-merged submission with git diff-tree -m --no-commit-id --name-only -r HEAD -- src/content/submissions/**/*.json | head -1. The -m flag walks the combined diff against both parents of the merge commit, so when a submission PR branch was cut from a stale main (e.g. several parallel write-article agents all branching from the same base, then merged in sequence), the diff accumulated every submission merged since that branch point. head -1 then picked an arbitrary entry — and on the runner's recomputed pull_request_target merge ref the list came back empty, so the step exited 1 and the approved article was never generated/published (observed on the 2026-06-21 batch, PR #1715, whose publish run failed with "No submission file found in commit" even though the submission was correctly on main)
  • Fix: detect the submission via the merge commit's first parent only — git diff-tree --no-commit-id --name-only -r --diff-filter=A "$MERGE_SHA^1" "$MERGE_SHA" using github.event.pull_request.merge_commit_sha — which yields exactly the submission file(s) the PR added to main, independent of how stale the branch base was. The checkout deliberately stays on the main branch (with fetch-depth: 0 for full history) rather than pinning ref to the merge SHA — a detached HEAD would later break the workflow's own git push origin main with "src refspec main does not match any". Verified locally against the #1713/#1714/#1715 merges (each resolves to its own single submission). No change to the article/provenance generation that follows

v3.14.0 — 2026-06-13

  • topic:check open-PR scan bugfix in scripts/check_topic.ts. fetchOpenPRs() called gh pr list --state open --search "submission/"; the --search flag routes through GitHub's search API, which returns HTTP 401 under some SSO/keyring token configurations even when the same token can list PRs and create refs. The whole Phase-A soft pre-check was effectively disabled — every parallel write-article agent across the 2026-06-09…06-13 batches hit it and fell back to manual verification (the atomic topic:claim still prevented duplicates, so no collisions slipped through, but the early-warning gate was dead). Fix: drop --search entirely and list open PRs via the plain REST endpoint (limit raised 100→200); parseOpenPRs() already filters to submission/ branches client-side, so the server-side search was redundant
  • New npm run slug -- <submission.json> helper (scripts/print_slug.ts) prints the exact canonical slug the publish pipeline will produce for a submission. The slug derivation (slugify/getMonthFolder/generateSlug) is extracted into a shared scripts/lib/slug.ts — a single source of truth now imported by both generate_article_from_submission.ts and the new CLI (behavior byte-identical; verified against the published archive)
  • Motivation: slugify strips punctuation (. $ ' : …) rather than replacing it, so "v1.38" → "v138" and "$3.5B" → "35b". Chief-Editor reviews create article-meta and corrections files before the article exists on disk, so reviewers had to predict that collapse by hand — and repeatedly mis-predicted it (the 2026-06-11 California "$3.5 Billion" and 2026-06-12 "Weaviate 1.38" reviews both produced orphaned meta/corrections files that had to be renamed in follow-up commits)
  • review-submission skill updated (Step 8.5 + the corrections-record step): reviewers now run npm run slug -- <submission file> to obtain the exact slug for naming article-meta and corrections files, instead of re-deriving DD-slugified-title by hand. No change to the slug format itself, so existing article URLs are unaffected

v3.13.4 — 2026-06-12

  • Source allowlist: added forums.swift.org to config/source_allowlist.txt. The Swift project's official community forum is the authoritative primary source for Swift release-process announcements — release managers, branch-cut dates, and the Swift Evolution proposal timeline are published there (e.g. the Swift 6.4 release thread naming Ben Cohen as release manager and the May 4, 2026 release/6.4.x branch cut). It belongs alongside developer.apple.com for Rule 9 primary-publication citations on Swift releases
  • No content-schema or editorial-rule change. Allowlist addition only