Skip to content

Wire BOT_PAT into mythos.yml so daily PRs trigger CI and auto-merge unattended #136

Description

@schmug

Task

Replace GITHUB_TOKEN with a user- or app-scoped token when the Mythos tracker workflow opens its daily PR, so the resulting PR is recognized as user-authored and triggers ci.yml automatically. After this change, every Mythos delta PR should self-merge once CI is green, with zero human nudging. Today, bot-authored PRs never trigger CI (per GitHub's security model), branch protection blocks auto-merge, and the "fully automated daily" goal silently degrades into "PR sits open until I push an empty commit."

Context

PR #132 added the Mythos tracker. PR #135 was the first bootstrap run. The cron generated the PR successfully, but no CI ever fired on it because github-actions[bot] opened it via GITHUB_TOKEN. I unblocked it manually with git commit --allow-empty from my user account — that triggered CI and auto-merge landed. That manual nudge is unsustainable for a daily cron, which is the whole point of the workflow.

Motivation

  • User story: As the maintainer of cortech.online, I want the daily Mythos cron to write, open, and merge its own delta PRs without human input, so my role is reduced to reviewing the resulting content (not babysitting CI).
  • What triggered the ask now: First production run of mythos.yml exposed the gap. Tomorrow's 19:00 UTC scheduled run will hit the same wall.

Pointers

  • .github/workflows/mythos.yml — the workflow to modify. The gh pr create + gh pr merge --auto --squash steps currently use ${{ secrets.GITHUB_TOKEN }} via GH_TOKEN env.
  • .github/workflows/ci.yml:3-6 — the CI workflow that needs to trigger; uses on: pull_request: with no branch filter, but skips bot-authored PRs.
  • docs/superpowers/specs/2026-05-24-mythos-tracker-design.md — original spec; update if scope is changed.
  • PR feat(mythos): daily vulnerability tracker for Anthropic's CVD feed #132 — implementation of the tracker; references for surrounding code.
  • PR feat(mythos): tracker update #135 — first bootstrap run; the manual empty-commit nudge is the workaround being eliminated.

Constraints

  • Must not change the workflow's existing permissions surface beyond what's needed to issue + use the token.
  • The token must not be a long-lived classic PAT; prefer a fine-grained PAT (with explicit expiration) or, better, a GitHub App installation token.
  • If GitHub App is chosen, the App must be installed only on this repo (not org-wide) and have only the permissions the workflow needs: contents:write, pull-requests:write, issues:write.
  • The secret name should be BOT_PAT (PAT path) or BOT_APP_ID + BOT_APP_PRIVATE_KEY (App path) — document which.
  • Must not bypass branch protection — the goal is to trigger CI, not to skip it.

Acceptance criteria

  • A manually-triggered gh workflow run mythos.yml opens a PR whose checks tab shows Verify (lint, typecheck, unit, build) and E2E (Playwright) running automatically (without any user-authored commit on the branch).
  • The same PR auto-merges to main within a few minutes of CI completing green, with no human intervention.
  • docs/architecture.md's Mythos tracker section documents the chosen token mechanism + the secret(s) the workflow expects.
  • PR description references this issue and includes step-by-step setup instructions for the secret(s) so the next maintainer can rotate them.

Out of scope

  • Refactoring how the tracker itself generates posts (scripts/mythos/*.ts).
  • Adding a pull_request_target trigger to ci.yml — explicitly rejected because it runs the head commit's workflow in the base branch's secret context, which is a real security pitfall for any cron that fetches external data.
  • Changing branch protection rules on main.

Reasoning guidance

Compare the PAT path and the GitHub App path before picking one. The PAT path is faster to ship (one secret, one workflow line change) but creates a rotation burden. The App path is cleaner long-term but requires creating + installing an App, which is more setup. Pick whichever has the better cost/benefit for a single-maintainer side project and explain the choice in the PR description.

Cross-references

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestmythosMythos vulnerability tracker

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions