fix(stlc): back-sync on SHA ancestry, not identical trees

[blainekasten]

SKIP_LINEAR_CHECK

Why

Python staging back-sync has been a green no-op while codegen is held.

stlc-sync.yml skipped whenever merge-tree of production into staging equaled staging's tree. After stlc/heal-promote-ancestry was merged on both trunks, production was ahead by empty merge commits (eee6f8ed vs 243c5a4b) with identical trees. Generate and trunk-sync-lock check ancestry, so they stayed red.

Direct FF of staging main is also blocked by the org PR ruleset; the old job exited 1 on push failure with no PR fallback for the FF-able case.

This PR

• Treat production as "behind" unless it is an ancestor of staging (not merely tree-equal).
• If a direct FF of main is rejected, open the existing heal PR (stlc/heal-promote-ancestry) and require a merge commit / FF merge, never squash.

This workflow only runs on together-py-staging. Landing it here is so promote copies the same file.

Merge order

1. Merge the SHA back-sync on staging first: https://github.com/togethercomputer/together-py-staging/pull/142 (unblocks codegen).
2. Then merge this. If you merge this first, production is ahead again on a real tree change and codegen holds until 142 (or a new back-sync PR) lands.

TypeScript and Go stlc-sync.yml have the same tree skip; they are not currently holding generate.

SKIP_LINEAR_CHECK: workflow-only fix, no SDK product change.

  

[broly-code-security-scanner]

Broly Security Scan

Note

✅ Clean scan
No vulnerabilities detected in this PR.

Note

Re-scan this PR anytime with /broly scan — useful after /broly undismiss, or to refresh findings without a new push.

Broly — SAST (zai-org/GLM-5.2) · Secrets · SCA · IaC · GH Actions · Base Images · Supply Chain Threats · Exploit Chains · Adversarial Verification

We're continuously improving Broly's accuracy and finding quality — your feedback is valuable. False positives, missed findings, bugs, and feature requests all welcome.