Add GLM inline review workflow

[frankbria]

Adds the reusable GLM-5.2 inline PR reviewer (frankbria/glm-review): CodeRabbit-style inline comments on defective lines with committable suggestions, bugs-only scope. ZHIPU_API_KEY secret is set. Verified on hai-sh#75.

[github-actions]

Claude finished @frankbria's task in 3m 26s —— View job

---

GLM inline review complete.

• Gather context (gh pr view / gh pr diff / existing comments)
• Read the changed file and compare against the repo's other workflows
• Hunt for concrete defects (logic, security, data-loss, runtime contract)
• Post finding as an inline comment + summary

1 finding (major): .github/workflows/glm-review.yml:16 — reusable workflow pinned to the mutable @main branch instead of a commit SHA (supply-chain risk given id-token: write + ZHIPU_API_KEY are passed). The repo's own claude-code-review.yml and opencode.yml both SHA-pin their external references.

Posted as an inline comment on the diff line and summarized in the thread. No critical or runtime defects found — the threshold condition, paths-ignore, and secrets:/permissions: caller-job keys are all valid.

[github-actions]

GLM Review — PR #836

Severity	Location	Finding
major	.github/workflows/glm-review.yml:16	Reusable workflow pinned to the mutable @main branch instead of a commit SHA — supply-chain risk given id-token: write + ZHIPU_API_KEY are passed. Pin to a SHA like this repo's other workflows (claude-code-review.yml, opencode.yml).

1 finding (1 major). No critical or runtime defects found: the review-threshold condition (glm-review.yml:12-15) matches its comment, the paths-ignore / secrets: / permissions: keys are valid caller-job syntax, and the explicit named-secret mapping is the safer form over secrets: inherit.

[github-actions]

Claude finished @frankbria's task in 3m 1s —— View job

---

GLM Review — PR #836 (synchronize re-review)

Re-ran precision bug-hunt after commit b4f4232. Scope: concrete defects only — logic, security, data-loss, runtime contract. (Style, naming, coverage are out of scope.)

• Gather PR context (gh pr view / gh pr diff / existing comments)
• Read the changed workflow file and compare against repo's other workflows
• Confirm prior finding (@main pin) is resolved; hunt for new concrete defects
• Post findings (inline) + summary

Prior finding — resolved, not re-reported. .github/workflows/glm-review.yml:16 is now SHA-pinned to b877d15a0f8c0855d0d2ebdcce32ae09cec1bb2d, matching claude-code-review.yml / opencode.yml. The mutable-pin supply-chain risk is gone.

Severity	Location	Finding
—	—	—

✅ GLM review: no defects found.

Verified specifically:

• Threshold if: (lines 12–15) — changed_files >= 5 || additions >= 20 || deletions >= 20 matches its comment; OR-semantics and >= are correct, no off-by-one or inversion. This PR itself (1 file / +23) correctly passes on additions >= 20.
• Caller-job syntax — reusable-workflow caller (uses:) only allows if/uses/permissions/secrets/with/needs/concurrency; every key present is valid. Job-level permissions: and explicit named secrets: mapping are the correct, safer forms.
• Context refs — github.event.pull_request.{changed_files,additions,deletions} are all populated for the pull_request trigger (the only trigger here); no null/error path.
• Permission surface — id-token: write was only a concern alongside a mutable pin; with the SHA pin it is no longer a concrete vulnerability.

[github-actions]

Claude finished @frankbria's task in 2m 28s —— View job

---

GLM Review — PR #836 (synchronize re-review)

Re-ran precision bug-hunt after the merge of main into this branch (355aebe). Scope: concrete defects only — logic, security, data-loss, runtime contract. (Style, naming, coverage are out of scope.)

• Gather PR context (gh pr view / gh pr diff / existing comments)
• Read the changed workflow file and compare against the repo's other workflows
• Confirm prior finding (@main pin) is still resolved; hunt for new concrete defects
• Post findings (inline) + summary

No new findings, no findings to re-report. The merge (355aebe) brought in only security/perf commits (7a8fba7, 519338b, …) — none touch this file. .github/workflows/glm-review.yml is unchanged (same blob d71ec70d) and is still the only file differing from origin/main.

Prior finding — still resolved, not re-reported. .github/workflows/glm-review.yml:16 remains SHA-pinned to b877d15a0f8c0855d0d2ebdcce32ae09cec1bb2d (40 hex chars — a valid full SHA for a reusable-workflow uses:, which requires a full SHA or branch ref). This matches the convention in claude-code-review.yml:36,46 and opencode.yml:23,26, all of which pin their 40-char SHAs. The mutable-pin supply-chain risk is gone and stayed gone.

Severity	Location	Finding
—	—	—

✅ GLM review: no defects found.

Verified specifically against the checked-out file:

• Threshold if: (lines 12–15) — changed_files >= 5 || additions >= 20 || deletions >= 20 matches its comment; OR-semantics and >= are correct, no off-by-one or inversion. This PR (1 file / +23) correctly passes on additions >= 20.
• paths-ignore interaction — docs/.gitignore-only PRs skip the workflow at the trigger level (workflow doesn't run); mixed PRs run and are gated by the threshold. No silent-skip or always-run bug.
• Caller-job syntax — reusable-workflow caller (uses:) only allows if/uses/permissions/secrets/with/needs/concurrency; every key present is valid. Job-level permissions: and explicit named secrets: mapping are the correct, safer forms (no secrets: inherit).
• Context refs — github.event.pull_request.{changed_files,additions,deletions} are all populated for the pull_request trigger (the only trigger here); no null/error path.
• Permission surface — id-token: write was only a concern alongside a mutable pin; with the SHA pin it is no longer a concrete vulnerability.

[github-actions]

GLM Review — PR #836 (synchronize re-review)

Re-running precision bug-hunt after commit 660100d. Scope: concrete defects only — logic, security, data-loss, runtime contract. (Style, naming, coverage are out of scope.)

• Gather PR context (gh pr view / gh pr diff / existing comments)
• Read the changed files and compare against repo's other workflows/config
• Confirm prior findings resolved; hunt for new concrete defects
• Post findings (inline) + summary

View job run

[github-actions]

Claude finished @frankbria's task in 2m 58s —— View job

---

GLM Review — PR #836 (synchronize re-review)

Re-ran precision bug-hunt after commit dc37c63. Scope: concrete defects only — logic, security, data-loss, runtime contract. (Style, naming, coverage are out of scope.)

• Gather PR context (gh pr view / gh pr diff / existing comments)
• Read the changed files and compare against repo's other workflows/config
• Confirm prior findings resolved; hunt for new concrete defects
• Post findings (inline) + summary

New this run: dc37c63 adds the .github/dependabot.yml hunk (this is the first GLM run covering it — prior runs only saw glm-review.yml). Both differing files reviewed.

Prior finding — still resolved, not re-reported. .github/workflows/glm-review.yml:16 remains SHA-pinned to b877d15a0f8c0855d0d2ebdcce32ae09cec1bb2d (40 hex chars — valid full SHA for a reusable-workflow uses:), matching the convention in claude-code-review.yml / opencode.yml. The mutable-pin supply-chain risk is gone and stayed gone.

Severity	Location	Finding
—	—	—

✅ GLM review: no defects found.

Verified specifically against the checked-out files:

• .github/dependabot.yml (new hunk, lines 5–8) — removed semver-major-days/semver-minor-days/semver-patch-days from the github-actions ecosystem, kept cooldown.default-days: 14. This is correct: the semver-*-days cooldown options are unsupported for github-actions (Dependabot can't determine the semver level there), so only default-days is valid. The resulting YAML is well-formed and the config is now valid where it previously carried unsupported keys. The npm entry (lines 30–35) legitimately retains its semver-*-days keys since npm does support them — the per-ecosystem distinction is correct, not an inconsistency. No regression: cooldown still applies a 14-day delay; no logic, security, or data-loss path.
• Threshold if: (glm-review.yml:12–15) — changed_files >= 5 || additions >= 20 || deletions >= 20 matches its comment; OR-semantics and >= are correct, no off-by-one or inversion. This PR (2 files / +25) correctly passes on additions >= 20.
• paths-ignore interaction — docs/.gitignore-only PRs skip the workflow at the trigger level; mixed PRs run and are gated by the threshold. No silent-skip or always-run bug.
• Caller-job syntax — reusable-workflow caller (uses:) only allows if/uses/permissions/secrets/with/needs/concurrency; every key present is valid. Job-level permissions: and explicit named secrets: mapping are the correct, safer forms (no secrets: inherit).
• Context refs — github.event.pull_request.{changed_files,additions,deletions} are all populated for the pull_request trigger (the only trigger here); no null/error path.
• Permission surface — id-token: write was only a concern alongside a mutable pin; with the SHA pin it is no longer a concrete vulnerability.