Repair SDK tracking generation

[sjmiller609]

Summary

• re-anchor Go and TypeScript custom-code tracking to the current published SDK histories
• regenerate after hand-authored tracking-only changes so partial tracking updates cannot leave other targets stale
• skip regeneration only when a merged change came from the generated stlc/seal-tracking branch

Why

A target-specific tracking update can legitimately change only one SDK. Treating every tracking-only merge as an automatic seal-back skips the all-target regeneration that consolidates the remaining tracking state.

Testing

• stlc repair --dry-run --force --targets go,typescript --branch main
• stlc repair --dry-run --force --targets go,typescript --branch main reports both targets clean after repair
• generated Go and TypeScript SDKs in a disposable checkout with the CI-pinned stlc toolchain
• stlc exec --targets go,typescript -- ./scripts/bootstrap
• stlc lint --targets go,typescript
• stlc test --targets go,typescript
• validated both merged-PR classifications against the GitHub API
• parsed .github/workflows/stlc-generate.yml as YAML
• git diff --check

Full Python SDK validation was not run locally; this change does not modify its tracking state, and CI validates all targets.

---

Note

Medium Risk
Changes CI skip logic for SDK generation on main, which can cause extra full regenerations or missed skips if the GitHub PR lookup is wrong. Tracking file updates affect how custom code is sealed into Go and TypeScript SDKs.

Overview
Stops treating every custom-code-only merge as a no-op. The generate workflow now skips a follow-on build only when the push is the merged stlc/seal-tracking PR; other tracking-only changes still regenerate every SDK so a one-target update cannot leave the rest stale.

Adds pull-requests: read so the guard can look up that closed seal-back PR. Also re-anchors Go and TypeScript custom-code tracking files to current published SDK histories.

^{Reviewed by Cursor Bugbot for commit dd458d3. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

-->

✱ stlc build

✅ go code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

116 files generated at fbdfeb7 (pushed)

go get github.com/kernel/hypeman-go-staging@fbdfeb709a461fd4760cf82a06ab8f3f16f78168

✅ python code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

230 files generated at 5a0e6d4 (pushed)

✅ typescript code · compare

Your SDK build was successful.

generate ✅ → bootstrap ✅ → format ✅

138 files generated at c447b4d (pushed)

Diagnostics: ❗ 0 new / 1 total error, 💡 0 new / 5 total note

Level	Code	Message	Targets

Build metadata

Build	bd_76BbnmFQ-jubilant-cedar
Timestamp	2026-08-21T20:01:52.086Z
stlc	8413509
Spec hash	0f15511e31a6
Config hash	55e15f6f4434

---

This comment is auto-generated by stlc and is kept up to date as you push.
If you push new commits, re-run this workflow to update this comment.
Last updated: 2026-08-21 20:02:15 UTC

[masnwilliams]

lgtm

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5a2e6dc. Configure here.}

[rgarcia]

reviewed incrementally — looks good. the stricter skip check is the right shape: only a merged generated seal-back PR (stlc/seal-tracking) can now skip regeneration, and every other custom-code-only push fails open into a full rebuild of all targets, which is the safe direction for stale-tracking custom-code loss.

verified the new tracking snapshots point at real commits: go/ts base shas resolve as "seal" commits in hypeman-go-staging / hypeman-ts-staging (aug 17), and integrated shas resolve in hypeman-go / hypeman-ts (aug 19 release-please merges). workflow-level pull-requests: read correctly covers the guard job's new commits/$AFTER/pulls call while the generate job keeps its own overrides.

Questions

• stainless/custom-code/ — no python tracking file in this repair; confirm python has no sealed custom code (or was already in sync)

Nits

• .github/workflows/stlc-generate.yml:138 — nit: merged_at != null is likely redundant since only merged PRs associate with a main commit, but it's cheap and defensive — fine either way