Distillation

Date: Aug 5, 2026

• 🔴 [requested-plan] (17:30) User stated they already have a Loops account and wants a plan for a Loops-based mailing list; atproto integration is optional.
• 🔴 (17:30) User proposed tying newsletter delivery to GitHub Actions so that detecting a new post during the build triggers an email.
• 🟡 (17:30) Assistant proposed inspecting the current GitHub Actions build and Standard.site publication flow, then using a server-side Loops integration that sends only after a successful build and publication.
• 🟡 (17:30) Assistant identified duplicate-send safeguards as required because GitHub Actions may retry or rebuild.
• 🟡 (17:31) Assistant-created task list: 1. inspect the current GitHub Actions build and publication workflow (in progress, high priority); 2. define the Loops newsletter flow and duplicate-send safeguards (pending, high priority); 3. write the implementation plan with configuration and rollout steps (pending, high priority).
• 🟡 (17:34) The repository workflow is .github/workflows/deploy.yml, named Deploy to GitHub Pages; it triggers on pushes to master and workflow_dispatch.
• 🟡 (17:34) .github/workflows/deploy.yml grants contents: read, pages: write, and id-token: write; the build job runs on ubuntu-latest with BSKY_APP_PASSWORD: ${{ secrets.BSKY_APP_PASSWORD }}.
• 🟡 (17:34) The build job checks out the repository with actions/checkout@v7, builds/uploads the site with withastro/action@v6, then runs node scripts/publish-standard-site.mjs.
• 🟡 (17:34) The workflow explicitly publishes Standard.site records before GitHub Pages deployment so document links never point at missing records.
• 🔴 (17:34) User's publication workflow requirement is that document links must never point at missing records.
• 🟡 (17:34) The deploy job depends on build via needs: build, runs on ubuntu-latest, uses the github-pages environment, and deploys with actions/deploy-pages@v5; its environment URL is ${{ steps.deployment.outputs.page_url }}.
• 🟡 (17:34) scripts/publish-standard-site.mjs uses FETCH_ATTEMPTS = 3 and includes retry-based fetching, AT Protocol blob uploads, PLC DID resolution, record listing with a cursor, manifest loading, authentication, publication/document upserts, orphan computation, and orphan deletion.
• 🔴 (17:34) User's publication logic requirement is that it must never spin forever; the record-listing cursor logic specifically guards against an always-present cursor causing an infinite loop.
• 🔴 (17:34) User's publication logic requirement is that a mid-run failure must never strand the blog; the publication record is upserted before later cleanup operations.
• 🔴 (17:34) User's safety requirement is that a broken or empty build must never be able to wipe the whole collection; deletion of orphaned records is skipped or guarded when manifest.documents.length === 0.
• 🟡 (17:34) The publication script computes orphan record keys with computeOrphanRkeys(existing, keep) and deletes each orphan using its collection and record key, logging ✓ deleted orphan at://${session.did}/${collection}/${rkey}.
• 🟡 (17:34) The publication script reports completion as Done — published 1 publication + ${manifest.documents.length} ....