Repository navigation
ci(repo): run this repository on the one-repo topology - #65
Conversation
The generator will push here directly, so the four workflows that moved commits between a staging repository and this one have nothing left to move: promote, back-sync, the trunk lock and the release trigger go. The seal-dispatch now routes on this repository's name and mints its token from the GitHub App, with the old dispatch token as fallback. CI, release-please and the publish workflow stay. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Findings marked 🟡 are optional suggestions and need no follow-up push.
Additional findings (outside the current diff — GitHub can't attach inline comments there):
-
🔴
.github/workflows/stlc-promote.yml— This hand-written commit deletes four sync workflows, which CLAUDE.md lists as generator-owned. The next regeneration may restore them or conflict with the deletion. CLAUDE.md lists "the publish, release and sync workflows" as generator-owned and says custom code here is "none". REVIEW.md flags generator-owned file changes made outside a generated commit. Fix: remove the files through the pipeline or SDK configuration in a generated commit. If they really are custom code, update CLAUDE.md's ownership list in this PR. Same pattern at 4 sites (stlc-promote.yml, stlc-sync-from-production.yml, trigger-back-sync-on-release.yml, trunk-sync-lock.yml).Why this was flagged
The commit b27172f has no Stainless-Generated-From trailer. It deletes stlc-promote.yml, stlc-sync-from-production.yml, trigger-back-sync-on-release.yml and trunk-sync-lock.yml. CLAUDE.md's "Who owns which files" names "the publish, release and sync workflows" as generator-owned ("The next generated commit rewrites them, and an edit conflicts"). It also says "Custom code in this repository today: none." The PR description says these are sealed custom code, but nothing in the repo backs that up, and CLAUDE.md is not updated. If the generator does own them, the next generated commit restores or conflicts with them. If they are custom code, CLAUDE.md is now wrong.
Verification: Trigger: this hand-written commit is merged as is. b27172f has no Stainless-Generated-From trailer. The commit deletes four workflows. CLAUDE.md classifies these as generator-owned. It also says "Custom code in this repository today: none". None of the four deleted files says in its header that it is custom code.
| CONFIG_REPO: sentdm/sent-dm-sdk-pipeline | ||
| HAS_APP: ${{ secrets.SDK_APP_ID != '' && secrets.SDK_APP_PRIVATE_KEY != '' }} | ||
| steps: | ||
| - name: Mint a pipeline token from the GitHub App | ||
| id: app | ||
| if: env.HAS_APP == 'true' | ||
| uses: actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v3.3.0 | ||
| with: | ||
| app-id: ${{ secrets.SDK_APP_ID }} | ||
| private-key: ${{ secrets.SDK_APP_PRIVATE_KEY }} | ||
| owner: sentdm | ||
| repositories: sent-dm-sdk-pipeline |
There was a problem hiding this comment.
🔴 This public repository now names Sent's SDK pipeline repo in two places, and the PR adds the second one. CLAUDE.md forbids naming private repositories. The new repositories: sent-dm-sdk-pipeline at :48 sits alongside CONFIG_REPO: sentdm/sent-dm-sdk-pipeline at :37. The PR text also calls it the SDK pipeline. Fix: read the target from a repository variable or secret (for example vars.CONFIG_REPO) and use it for both the env and the token's repositories input, so no private repo name stays in the file.
Why this was flagged
CLAUDE.md says: "This repository is public. Nothing in it ... links to or names Sent's private repositories, internal systems or providers." REVIEW.md lists "A link to, or the name of, a private Sent repository ... anywhere in the diff" as Important. The added line 48 (repositories: sent-dm-sdk-pipeline) and the context line 37 (CONFIG_REPO: sentdm/sent-dm-sdk-pipeline) both name the config/pipeline repo, which the PR description describes as Sent's internal SDK pipeline. The header comments also still mention staging and production repos (line 6). Before this PR the job only ran on the staging repo. Now the file is active in the public repo, and the PR adds another mention of the name.
Verification: The PR adds repositories: sent-dm-sdk-pipeline at .github/workflows/seal-dispatch.yml:48 as a + line of the diff. CLAUDE.md says: "This repository is public. Nothing in it ... links to or names Sent's private repositories, internal systems or providers." The same name already appears in the base at line 37 (CONFIG_REPO: sentdm/sent-dm-sdk-pipeline), so the leak itself predates this PR.
| jobs: | ||
| dispatch: | ||
| runs-on: ubuntu-latest | ||
| if: github.repository == 'sentdm/sent-dm-python-staging' | ||
| if: github.repository == 'sentdm/sent-dm-python' | ||
| env: | ||
| CONFIG_REPO: sentdm/sent-dm-sdk-pipeline | ||
| HAS_APP: ${{ secrets.SDK_APP_ID != '' && secrets.SDK_APP_PRIVATE_KEY != '' }} | ||
| steps: | ||
| - name: Mint a pipeline token from the GitHub App | ||
| id: app | ||
| if: env.HAS_APP == 'true' | ||
| uses: actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v3.3.0 | ||
| with: | ||
| app-id: ${{ secrets.SDK_APP_ID }} | ||
| private-key: ${{ secrets.SDK_APP_PRIVATE_KEY }} | ||
| owner: sentdm | ||
| repositories: sent-dm-sdk-pipeline | ||
|
|
||
| - name: Loop-guard and send reseal dispatch | ||
| env: | ||
| DISPATCH_TOKEN: ${{ secrets.CONFIG_DISPATCH_TOKEN }} | ||
| DISPATCH_TOKEN: ${{ steps.app.outputs.token || secrets.CONFIG_DISPATCH_TOKEN }} | ||
| HEAD_MSG: ${{ github.event.head_commit.message }} | ||
| HEAD_AUTHOR_NAME: ${{ github.event.head_commit.author.name }} | ||
| SHA: ${{ github.sha }} | ||
| REPO: ${{ github.repository }} | ||
| run: | | ||
| set -euo pipefail | ||
|
|
||
| # Loop guard 1: skip the stlc "Build SDK" squash commit (it carries | ||
| # Loop guard 1: skip the generator's "Build SDK" squash commit (it carries | ||
| # the Stainless-Generated-From trailer in its message). | ||
| if printf '%s' "$HEAD_MSG" | grep -q 'Stainless-Generated-From'; then | ||
| echo "Head commit is an stlc build — skipping reseal dispatch." |
There was a problem hiding this comment.
🟡 (optional) Comments edited in this PR still name the generator, which breaks the CLAUDE.md rule "No provenance comments". That rule says to remove such comments from a block you are already editing. The rewording swapped "stlc" for "the generator" but did not drop the references. Fix: remove every comment and message in this file that names the generator or its tooling, which covers the 6 sites listed. Same pattern at 6 sites (seal-dispatch.yml:8, seal-dispatch.yml:13, seal-dispatch.yml:22, seal-dispatch.yml:60, seal-dispatch.yml:63, seal-dispatch.yml:67).
Why this was flagged
CLAUDE.md says: "Don't add a comment that marks code as hand-written or names the generator, and remove one from a block you are already editing." REVIEW.md reports "A comment that ... names the generator" as Important. The diff rewrites lines 8, 13, 22 and 60 to "generator-authored commits", "the generator's commit step", "the generator's preview, integrated and codegen branches" and "the generator's "Build SDK" squash commit". All of them still name the generator. Line 63 still echoes "Head commit is an stlc build", and lines 67-69 still mention stlc-bot. These sit in hunks the PR edits, so the rule's remove-while-editing clause applies, and this public repo keeps carrying the provenance text.
Verification: The diff rewrites comments at .github/workflows/seal-dispatch.yml lines 8, 13, 22 and 60, and each one still refers to the generator. The PR edits the run: block at line 60, but that same block keeps references to the generator's own tooling name. So the rule to remove such comments from a block you are already editing was not followed. Nothing breaks at runtime.
| - name: Mint a pipeline token from the GitHub App | ||
| id: app | ||
| if: env.HAS_APP == 'true' | ||
| uses: actions/create-github-app-token@fee1f7d63c2ff003460e3d139729b119787bc349 # v3.3.0 | ||
| with: | ||
| app-id: ${{ secrets.SDK_APP_ID }} | ||
| private-key: ${{ secrets.SDK_APP_PRIVATE_KEY }} | ||
| owner: sentdm | ||
| repositories: sent-dm-sdk-pipeline | ||
|
|
||
| - name: Loop-guard and send reseal dispatch | ||
| env: | ||
| DISPATCH_TOKEN: ${{ secrets.CONFIG_DISPATCH_TOKEN }} | ||
| DISPATCH_TOKEN: ${{ steps.app.outputs.token || secrets.CONFIG_DISPATCH_TOKEN }} |
There was a problem hiding this comment.
🟡 (optional) If minting the App token fails, the reseal dispatch is never sent, even when CONFIG_DISPATCH_TOKEN is set as the documented fallback. The mint step at :40-48 runs whenever both App secrets are non-empty. When it errors (App not installed on the target repo, bad key), the job stops before the fallback at :52 is tried. Fix: add continue-on-error: true to the mint step so steps.app.outputs.token is empty and the || at :52 uses CONFIG_DISPATCH_TOKEN. Also update the "CONFIG_DISPATCH_TOKEN not set" message at :73 to name both credentials.
Why this was flagged
Trigger: SDK_APP_ID and SDK_APP_PRIVATE_KEY are set, so HAS_APP at :38 is 'true', but actions/create-github-app-token fails. For example, the App is not installed on the target repository or lacks access. The step at .github/workflows/seal-dispatch.yml:40 has no continue-on-error, so the job fails there. The dispatch step with DISPATCH_TOKEN: ${{ steps.app.outputs.token || secrets.CONFIG_DISPATCH_TOKEN }} at :52 never runs. The header comment at :17-19 promises CONFIG_DISPATCH_TOKEN as a fallback, and the PR description says the token is minted from the App "falling back to the old dispatch token". The fallback only covers missing secrets, not a failed mint. On the base, the job used CONFIG_DISPATCH_TOKEN directly and had no step that could fail this way.
Verification: SDK_APP_ID and SDK_APP_PRIVATE_KEY are both set and CONFIG_DISPATCH_TOKEN is also set, but the App token mint fails. In .github/workflows/seal-dispatch.yml:40-48 the mint step has no continue-on-error, so the job stops and the || fallback at :52 never gets used. No seal-custom-code dispatch reaches the config repo.
This SDK moves to the one-repo topology: the generator pushes into this repository directly, so the four workflows that moved commits between a staging repository and this one are removed (
stlc-promote.yml,stlc-sync-from-production.yml,trigger-back-sync-on-release.yml,trunk-sync-lock.yml).seal-dispatch.ymlroutes on this repository's name and mints its token from the GitHub App, falling back to the old dispatch token. CI, release-please and the publish workflow stay. These four files are sealed custom code, not generator output, as the Go and PHP switches confirmed.Merge after the SDK pipeline PR that switches this language.
STAGING_DISPATCH_TOKENon this repository becomes unused once this merges.🤖 Generated with Claude Code