fix: reusable workflow startup failures (ci-status + pr-feed)

[lml2468]

问题

两个 reusable workflow 存在缺陷，导致所有 caller 仓库的 workflow 持续失败。

1. ci-status 全面失败（5个仓库，自 2026-05-16 起所有 run 均 failure）

根因：workflow_id input 的 description 字段中使用了 ${{ github.event.workflow_run.workflow_id }} expression。description 是静态元数据字段，不支持 expression，GitHub 在 parse reusable workflow 时报 Unrecognized named-value: 'github'，导致 workflow 无法启动（0 jobs）。

受影响仓库：octo-server, octo-adapters, octo-matter, octo-smart-summary, octo-admin

2. pr-feed startup_failure（7个仓库，每次 PR 事件均 startup_failure）

根因：feed_group_id 参数设为 required: true 但没有 default 值，而7个 caller 仓库均未传此参数，导致 GitHub workflow 校验失败。

受影响仓库：octo-web, octo-server, octo-matter, octo-smart-summary, octo-admin, octo-lib, octo-deployment（只有 octo-adapters 正确传了参数）

修改

octo-ci-status.yml

• 将 workflow_id description 中的 ${{ ... }} expression 改为纯文本

octo-pr-feed.yml

• feed_group_id：required: true → required: false，并加 default: '1c303c142e9840f2a9b46c10b0972e8d'（所有仓库共用同一个 pr-feed 群）

合并后操作

合并后需要将 v1 tag 更新到新 commit，callers 引用的是 @v1：

git tag -f v1 main
git push origin v1 --force

[yujiawei]

Code Review — PR #24 (.github)

Summary

Two targeted fixes to reusable workflows that were causing production breakages across caller repos. The diff is small (+4/-3, two files) and both fixes address documented, verified root causes. No blocking issues found.

1. Verification

Item	Result	Evidence
octo-ci-status.yml startup failure fixed	✅	.github/workflows/octo-ci-status.yml:24 — ${{ ... }} removed from description; field is now plain text. GitHub's expression parser does evaluate metadata strings, which is why the original produced Unrecognized named-value: 'github' (the github context is not available at workflow_call definition time).
octo-pr-feed.yml startup failure fixed	✅	.github/workflows/octo-pr-feed.yml:46-50 — required: true → required: false with default: '1c303c142e9840f2a9b46c10b0972e8d'. Callers that omit the input will now resolve to the default instead of failing the workflow validation.
Backwards compatibility for callers that already pass the value	✅	octo-pr-feed.yml:46-50 — explicit with: feed_group_id: ... still overrides the default (e.g. octo-adapters keeps working).
Runtime validation still enforced	✅	octo-pr-feed.yml:192 — require_group_id('FEED_GROUP_ID') continues to enforce the 32-char hex format; the default 1c303c14…972e8d satisfies it.
No unrelated changes	✅	git diff main..HEAD touches only the two workflow files.

2. Findings

None at P0 or P1.

3. Observations / Suggestions (non-blocking)

O1. The default re-introduces a value that PR #18 intentionally removed (architectural)

PR #18 ("fix(pr-feed): wire feed_group_id as required input, remove hardcoded group ID") was Phase 1 of a planned migration explicitly aimed at decoupling the reusable workflow from a specific runtime group ID. Phase 2 (update all 8 callers) was only partially completed — octo-adapters was migrated, the other 7 were not — and the missing Phase 2 is what caused the current breakage.

This PR is the pragmatic response (unblock 7 repos immediately), but it does effectively roll back the architectural intent of PR #18. Two options to consider as follow-up, neither blocking this merge:

• Keep the default as a transitional shim and finish Phase 2 (update remaining callers to pass the ID explicitly), then a future PR can re-tighten to required: true + remove the default.
• Or accept the default as the new long-term design and update PR #18's stated intent in a follow-up commit message / PR.

Either choice is defensible; the current PR just shouldn't be the implicit decision point — worth a one-line comment in the workflow or a follow-up issue so the intent is recorded.

O2. Group ID exposure in a public repo (informational only)

This repository is public (isPrivate: false). The group ID 1c303c14…972e8d is now visible in the workflow source. This is not a new exposure — the same value was already in git history via the pre-PR-#18 commits, and PR #16's octo-ci-status.yml:265 similarly hardcodes 4ade985d…118a. Group IDs without the bot token confer no abuse capability (sending requires OCTO_BOT_TOKEN, a secret), so the practical risk is null. Flagging it only because if a future policy says "no IM identifiers in public repos," this PR is one of the touchpoints to revisit.

O3. Description rewording is clearer than the original

The new description in octo-ci-status.yml:24 ("Pass github.event.workflow_run.workflow_id from the calling workflow (workflow_run event context)") is actually more informative than the original, because it explicitly tells the caller author which event context provides the value. Good incidental improvement.

4. Post-merge operation

The PR description correctly notes that callers reference @v1, so the v1 tag needs to be force-updated after merge:

git tag -f v1 main
git push origin v1 --force

This is outside the diff but is the actual unlock for the broken caller repos. Worth confirming whoever lands this also runs the tag update (or that there's automation for it).

Verdict

APPROVED. Both fixes target verified root causes with the minimum viable change. No correctness, security, or build-break risks. The only architectural note (O1) is a follow-up item, not a merge blocker — production is currently broken across 12 caller workflow runs, and this PR is the right shape to fix it now.