Pipeline

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

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

v3.13.3 — 2026-06-09

  • Publish commit-subject bugfix in .github/workflows/publish-from-submission.yml. The "Get article info" step located the just-generated article with find src/content/articles -name "*.md" | xargs ls -t | head -1. On a fresh runner checkout every file shares the same mtime, so ls -t ordering is nondeterministic — the step frequently picked an unrelated already-published article. Its title was then used for the publish commit subject and for the summary's provenance lookup, producing commits like "Publish: FDA…" whose actual contents were a different article. Observed across the 2026-06-09 batch (e.g. a Persona 6 publish committed under a stale "Kotlin 2.4.0" subject)
  • Fix: the step now reads the authoritative article_path and slug that scripts/generate_article_from_submission.ts already appends to $GITHUB_OUTPUT (steps.generate.outputs.*), deriving the month folder from the slug and the title from the correct file. Fails loudly if the generate step emitted no path. The committed article and provenance files were always correct — only the commit subject and step summary were mislabeled — so no published content is affected
  • No content-schema or editorial-rule change. Patch-level fix to the publish pipeline only