[jddunn]

master is protected since 21 October: Unit Tests, Vocabulary & NLP Tests, Cache Tests, Integration Tests and guard must pass, administrators included. That refuses the index publish. auto-index.yml's publish-artifacts job commits the four index files and runs git push to master with GITHUB_TOKEN, as github-actions[bot] (the last one is d19e45b, 04:01 UTC on 21 October, from run 39541416722), and a commit made in a job has none of the required checks. GitHub's rule ("About protected branches", Require status checks before merging, https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging):

After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch. After all required status checks pass, any commits must either be pushed to another branch and then merged or pushed directly to the protected branch.

So the next push to master that changes weaves/, scripts/ or schema/ would end in a red publish job and no index. This moves the publish to a pull request, in the pattern of #7 for the weekly bump.

The change

.github/workflows/auto-index.yml:

• publish-artifacts opens or updates one pull request into master from ci/codex-index, with peter-evans/create-pull-request at the commit the bump pins (22a9089, v7.0.11), carrying codex-index.json, codex-search.json, codex-report.json and codex-blocks.json. No step runs git push or git commit.
• It checks out master's head (ref: master), whichever commit the run built. create-pull-request starts the pull request from the branch checked out (src/create-or-update-branch.ts at v7.0.11), so the pull request carries the index alone and merges without a conflict even after master took an earlier index pull request; from the run's own commit, both sides would have changed the index files since their merge base.
• The branch push and the pull request go through FRAMERS_BUMP_TOKEN, so the pull request's own events start Test Suite and rename-guard. Opened with GITHUB_TOKEN, its pull_request runs would wait for an approval with no job, and its required checks would never report (ci: open the bump pull request with FRAMERS_BUMP_TOKEN so its Test Suite and rename-guard jobs run #7 quotes GitHub's rule).
• The commit message drops [skip ci]. GitHub skips the pull_request workflows of a pull request whose head commit carries it, and then "checks associated with that workflow will remain in a 'Pending' state. A pull request that requires those checks to be successful will be blocked from merging" ("Skipping workflow runs", https://docs.github.com/en/actions/how-tos/manage-workflow-runs/skip-workflow-runs).
• A first step stops the run with an ::error:: annotation when FRAMERS_BUMP_TOKEN is empty. The workflow's GITHUB_TOKEN drops to contents: read (it had the repository default, write), and the publish job installs and runs none of the repository's code, since it holds a token that reaches past this repository.
• It publishes from master only (the old condition also named main, a branch this repository does not have), one run at a time: concurrency with cancel-in-progress: false, so two runs never push the branch at once, and queue: max, which keeps every waiting run in the order each began to wait. GitHub's default keeps one waiting run and replaces it with the next one that begins waiting, whichever commit is newer ("Control the concurrency of workflows and jobs", https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency).
• Each run waits for its own build, so a run of an earlier commit can reach the publish job after a later commit's run. A new step fetches the run's commit by its id and compares it with master's head under weaves, scripts, schema and the workflow file, the paths whose change starts the workflow. When they differ, a later push changed them and its run publishes, so this run skips the download and the pull request instead of putting an older index on it. When they match, no later run publishes, so this one does. A comparison that cannot be made, a failed fetch or a failed diff, fails the step, and nothing is published.
• The artifact steps move to upload-artifact@v7 and download-artifact@v8, as ci: upload-artifact v7 and download-artifact v8, the current majors, which run on Node.js 24 #12 moved the other workflows'.
• It labels nothing.

.github/workflows/landing-follows-the-bump-checks.yml follows ci/codex-index beside chore/bump-framers-deps: its workflow_run branches and its job's if name both, and its script takes the branch from the run and returns at once for any other. The rest of the script is unchanged, so the index pull request gets the landing label once its Test Suite and rename-guard pass on its head, and loses it as the bump's does. Its name becomes "Landing follows the bump and index checks".

Docs: .github/WORKFLOWS.md describes the index publish, the label workflow's second branch and master's protection; README.md and the secret table name the index beside the bump for FRAMERS_BUMP_TOKEN; docs/DEVELOPMENT.md, docs/RECATALOG_GUIDE.md and docs/BLOCK_TAGGING_TUTORIAL.md commit a manual re-index or a tutorial change on a branch and open a pull request, since master refuses a direct push.

Tests, first

• tests/index-pull-request.test.js (new, 24 cases) reads auto-index.yml: no git push or git commit; the pull request step's token, base, branch, delete-branch, no label input, and the commit the bump pins; the read-only GITHUB_TOKEN; the first step run with bash -e with the secret empty and set; master only; the checkout of master's head; no skip marker in the commit message or the title; add-paths equal to the files the build archives, each tracked here; one run at a time with every waiting run kept; and the ordering step, run in scratch repositories against master's head cloned at depth 1 as actions/checkout leaves it, after master changes a strand, a script, a schema or the workflow (it leaves the pull request), or only the README, or takes an index pull request, or changes a strand and changes it back (it publishes), and with a run commit the remote does not have (it fails, writing no decision). It also runs the step for three runs, the first commit, an older change and a newer one, in three turn orders: only the newer change's run publishes in each.
• tests/bump-framers-deps.test.js reads the label workflow's second branch from auto-index.yml and runs its script for the index branch: both guards passed, one failed, the bump branch's runs on the same commit, and a run from another branch, which makes no API call.
• On 686e1b2, Test Suite run 39564460553 failed 23 of 298 tests against the old workflows; on 9f7ea45, run 39564620857 passed all 298.
• On 442ebed, run 39565567802 failed the 5 new cases for the checkout of master's head and the comparison by the run commit's id; on c37deae, run 39565614635 passed all 300.
• On aeceb70, run 39567330557 failed 1 of 303, the case for queue: max; on 254f551, run 39567352802 passed all 303.

After the merge

The merge changes .github/workflows/auto-index.yml, so it starts the workflow on master. When the built index differs from master's, the publish job opens the first pull request from ci/codex-index, its Test Suite and rename-guard run, and the label workflow labels it. That run, the pull request and its label go in a comment here.

Reviews

• Codex on c37deae: one P1, "Preserve the newest publish run in the concurrency queue": with GitHub's default of one waiting job, an older commit's run that began waiting later replaced the newer commit's waiting publish, then skipped, and nothing published the newer index. Fixed in 9c1aac2 with queue: max, test first in aeceb70; answered in its thread and resolved. Its review of the head, 254f551, requested by comment: "Didn't find any major issues."
• Qodo on c37deae: two findings. "The newest index can be dropped and never published" is the same case as Codex's; Qodo marked it resolved after 254f551. "An older index pull request can merge" is answered in its thread with reasons and not changed: that pull request never holds an index built from older inputs than master's, a later build replaces it, and holding it when a later build fails would leave master on an older index still; the behaviour is under Risks. Resolved.
• CodeRabbit: the app skipped the draft, then stopped at its review limit on c37deae ("Review limit reached", status "Review rate limited" on 254f551), so it left no review of its own. The CodeRabbit CLI reviewed the committed changes from d19e45b to the head, 254f551, all nine files: 0 findings.
• Sourcery: it wrote its reviewer's guide; its review stopped at its weekly review budget, so it left no review of the changes: missing.
• Every review thread (three) is answered and resolved.

Risks

• The token is a person's, so index pull requests are opened in that account's name. When it expires or is revoked, the publish job fails at its first step or at the push, instead of opening a pull request that gets no job.
• The index reaches master once its pull request's checks and comment pass are done, later than the direct push did.
• When a later push's build fails, the open index pull request keeps the earlier build's index, whose inputs are never older than those of master's index, until a run succeeds; the failed build is a red run on master.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 9 billable files and costs up to $2.25.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 27 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available. Your 92 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Team
• Run ID: 8c47545e-ad93-4222-b8e2-2a65301c2430

📥 Commits

Reviewing files that changed from the base of the PR and between d19e45b and 254f551.

📒 Files selected for processing: 9

• .github/WORKFLOWS.md
• .github/workflows/auto-index.yml
• .github/workflows/landing-follows-the-bump-checks.yml
• README.md
• docs/BLOCK_TAGGING_TUTORIAL.md
• docs/DEVELOPMENT.md
• docs/RECATALOG_GUIDE.md
• tests/bump-framers-deps.test.js
• tests/index-pull-request.test.js

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's Guide

This PR expands CI coverage for moving search-index publication into a protected-branch pull request: it validates the workflow’s FRAMERS_BUMP_TOKEN-based creation, artifact and change-ordering behavior, and ensures the landing-label automation independently follows both the dependency-bump and index pull requests.

File-Level Changes

Change	Details	Files
Add comprehensive tests for routing the generated search index through a protected-branch pull request.	Parse and validate the publish workflow’s pull-request configuration, token usage, permissions, commit contents, concurrency, and ordering logic. Exercise the workflow’s shell scripts and change-detection behavior in temporary Git repositories. Verify the index pull request is opened from the expected branch and targets master without directly pushing or self-labeling.	tests/index-pull-request.test.js
Extend landing-label workflow tests to cover both dependency-bump and search-index pull requests.	Make workflow fixtures branch-aware and require both supported branches in trigger and job guards. Test labeling and unlabeling based on Test Suite and rename-guard results for the index branch. Ensure unrelated branches and runs from the bump branch cannot affect the index pull request.	tests/bump-framers-deps.test.js

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Sorry @jddunn, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 3 days and 19 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-21T08:15:32.026982Z	254f551	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Publish the search index through a PR to protected master

🐞 Bug fix ⚙️ Configuration changes 🧪 Tests 📝 Documentation 🕐 40+ Minutes

AI Description

• Replace the blocked direct push with an index pull request whose required checks can run.
• Prevent older builds from replacing newer index results, and label index PRs only after guards
 pass.
• Test the publishing and labeling workflows, and document branch-based contribution steps.

Diagram

graph TD
  Build["Build index"] --> Artifacts["Four artifacts"] --> Freshness{"Inputs current?"} -->|yes| PR["Index PR"] --> Checks["Required checks"] --> Landing["Landing label"] -->|reviewed merge| Master["Protected master"]
  Freshness -->|no| Skip["Skip publish"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use a GitHub App installation token

• ➕ Avoids dependence on a person's token and permits narrowly scoped, short-lived credentials.
• ➖ Requires an App, installation management, and additional workflow setup.

Recommendation: The PR-based publication is necessary for protected master, and reusing the bump workflow's token is pragmatic now. Consider an App token if credential ownership or rotation becomes a recurring operational risk.

Files changed (9) +486 / -60

Enhancement (1) +25 / -15

landing-follows-the-bump-checks.ymlFollow index PR checks as well as bump PR checks +25/-15

Follow index PR checks as well as bump PR checks

• Extends workflow-run filtering and branch selection to ci/codex-index. The existing guard evaluation now manages its landing label and comment too.

.github/workflows/landing-follows-the-bump-checks.yml

Bug fix (1) +93 / -15

auto-index.ymlPublish index artifacts through a guarded pull request +93/-15

Publish index artifacts through a guarded pull request

• Replaces direct commits and pushes to master with a token-authenticated PR containing the four index files. Restricts permissions, serializes publication, skips stale builds, checks for the secret early, and upgrades artifact actions.

.github/workflows/auto-index.yml

Tests (2) +331 / -12

bump-framers-deps.test.jsTest landing-label behavior for index PRs +73/-12

Test landing-label behavior for index PRs

• Extends the GitHub API test double to model either followed branch. Verifies index PR labeling on passing guards, label removal on failure, branch-specific run selection, and rejection of unrelated branches.

tests/bump-framers-deps.test.js

index-pull-request.test.jsExercise index PR publishing and stale-run decisions +258/-0

Exercise index PR publishing and stale-run decisions

• Adds workflow assertions for PR configuration, token safety, permissions, checkout, artifact paths, and serialization. Runs shell steps and scratch-repository comparisons to check publication, skipping, and failure behavior.

tests/index-pull-request.test.js

Documentation (5) +37 / -18

WORKFLOWS.mdDocument protected-master index publication +21/-9

Document protected-master index publication

• Explains the index PR, stale-run handling, token requirements, and guard-driven landing label. Adds the relevant master protection rules and expands the secret table.

.github/WORKFLOWS.md

README.mdDescribe index PR publishing and shared token use +3/-3

Describe index PR publishing and shared token use

• Updates the workflow overview and secret guidance to explain protected-master publication and check-driven index PR labeling.

README.md

BLOCK_TAGGING_TUTORIAL.mdSubmit tutorial changes through a branch and PR +4/-2

Submit tutorial changes through a branch and PR

• Replaces the direct-push example with branch creation, branch push, and PR creation for protected master.

docs/BLOCK_TAGGING_TUTORIAL.md

DEVELOPMENT.mdRoute manual re-indexing through a PR +5/-2

Route manual re-indexing through a PR

• Changes the manual index commit instructions to create and push a branch, then open a PR.

docs/DEVELOPMENT.md

RECATALOG_GUIDE.mdUse a PR for manual recatalog deployment +4/-2

Use a PR for manual recatalog deployment

• Explains protected-master checks and replaces the direct-push deployment example with a branch and PR.

docs/RECATALOG_GUIDE.md

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c37deae641

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. An older index pull request can merge 🐞 Bug ≡ Correctness

Description

The ordering step skips publication when master has newer index inputs, but it does not invalidate
an index pull request already opened for the older inputs. After another source change lands on
master, that pull request can still merge with its existing passing checks; if the newer build
fails, its publish job never runs and the merged index remains stale until another trigger.

Code

.github/workflows/auto-index.yml[R121-123]

+            1)
+              echo "::notice::master changed weaves/, scripts/, schema/ or this workflow after ${GITHUB_SHA::7}; the run of that change publishes the index."
+              echo "later=true" >> "$GITHUB_OUTPUT"

Evidence

The new PR is opened at lines 137–152, but subsequent runs only decide whether to download and
update it; they do not gate its merge. The documented protection does not require PRs to be up to
date with master, and publication depends on the build job succeeding. Thus a newer source push does
not itself remove an older PR's passing checks or produce a replacement when its build fails.

.github/workflows/auto-index.yml[17-23]
.github/workflows/auto-index.yml[59-78]
.github/workflows/auto-index.yml[111-152]
.github/WORKFLOWS.md[194-196]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A previously approved index pull request remains mergeable after master changes its source inputs. The publish-time comparison cannot protect that existing pull request, particularly when the replacement build fails.
## Fix Focus Areas
- .github/workflows/auto-index.yml[106-138]
- .github/WORKFLOWS.md[194-196]
## Recommended Fix
Add a merge-time freshness requirement for the index pull request, or otherwise invalidate it when watched inputs change on master. Ensure a failed replacement build does not leave the older index pull request eligible to merge.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. The newest index can be dropped and never published ✓ Resolved

Description

The publish job’s concurrency group keeps only the most recently queued waiting run, not the run
for the newest master commit, while runs queue in build-completion order. If an older build finishes
after a newer one while another publish job occupies the group, it cancels the newer commit’s
waiting job and then skips because its inputs differ from master’s head (later=true); the
occupying job can skip for the same reason, leaving the latest index unpublished until another
qualifying push and a cancelled job visible on a master commit.

Code

.github/workflows/auto-index.yml[R81-84]

+    # One run at a time, so two runs never push the pull request branch at once; GitHub keeps the newest waiting run.
+    concurrency:
+      group: codex-index-pull-request
+      cancel-in-progress: false

Evidence

With commits A, B, and C pushed in that order, B can be publishing when C’s build finishes and C
waits. If A’s build finishes next, A takes the group’s single pending slot and C is cancelled. The
ordering comparison then finds that both B and A differ from master’s head, C, so they skip the
steps that could publish C’s index. The comment’s “newest waiting run” means the most recently
queued run, not the newest commit; the ordering step assumes the run for master’s head will reach
publication, but the job-level group can cancel it. landing-follows-the-bump-checks.yml avoids
concurrency groups to prevent cancelled jobs on master commits.

.github/workflows/auto-index.yml[77-129]
.github/workflows/landing-follows-the-bump-checks.yml[18-21]
.github/workflows/auto-index.yml[34-35]
.github/workflows/auto-index.yml[77-84]
.github/workflows/auto-index.yml[111-138]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The publish job’s concurrency group can replace a newer commit’s waiting job with an older commit’s job whose build finished later. The older job then skips because master’s head differs, potentially leaving the latest index unpublished.
## Fix Focus Areas
- .github/workflows/auto-index.yml[77-84]
- .github/workflows/auto-index.yml[111-138]
## Recommended Fix
Ensure the run for master’s head can publish even when builds finish out of push order. Serialize the build-and-publish lifecycle in source-push order—for example, consider workflow-level concurrency for master pushes using `group: codex-index-${{ github.ref }}` and `cancel-in-progress: true`—or use coordination that, when `later=true`, checks whether a run for master’s head is still active or succeeded and publishes or re-dispatches if it was cancelled. Correct the comment that implies the newest commit’s run is kept, and add a regression case where a newer build finishes before an older one while publication is occupied.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[jddunn]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Delightful!

Reviewed commit: 254f551cbc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jddunn]

After the merge: merged at 08:22:33 UTC as 54c66d9 under master's protection, the five required checks green on 254f551.

• Build and Publish Codex Index run 39568789160 on 54c66d9 passed. publish-artifacts ran every step: the token check, the checkout of master's head, the ordering step (later=false, master's head is the run's commit), the download with v8, and create-pull-request: "Working base is branch 'master'", "Pull request branch 'ci/codex-index' does not exist yet.", "Created branch 'ci/codex-index'", "Created pull request ci(codex): update search index and block tags #14 (framerslab:ci/codex-index => master)". Besides the runner image notice, the job carries one warning: create-pull-request v7.0.11 targets Node.js 20.
• ci(codex): update search index and block tags #14 (head 3167841, codex-index.json, codex-report.json and codex-search.json) got its own runs, opened with the token: Test Suite run 39569068795 and rename-guard run 39569068657 passed, and the pull request went from blocked to mergeable.
• The label workflow, run 39569479864 from master, added landing at 08:28:15 with the guards comment naming both runs.
• Test Suite run 39568789018 (run number 114) on 54c66d9 passed all five jobs; Update Badges moved the badges branch to 1b7a85f, "badges for 54c66d9 from run 114", tests "303 passed". rename-guard on 54c66d9 passed.