ci(auto-add-to-project): make reusable via workflow_call, pin action version

[lml2468]

What

Converts auto-add-to-project.yml from a standalone workflow (that only fired for events in the .github repo itself) into a dual-mode workflow:

• Direct trigger (unchanged): issues.opened + pull_request_target.opened — still covers the .github repo
• Reusable (new): workflow_call accepting PROJECT_TOKEN secret — called by per-repo callers in all other org repos

Why

The original workflow only auto-added items from the .github repo to Project Board #2. All other repos (octo-web, octo-server, etc.) were silently uncovered. This is the org-layer fix; per-repo callers are deployed in separate PRs.

Changes

• Added workflow_call trigger with PROJECT_TOKEN secret declaration
• Added top-level permissions: {} (GITHUB_TOKEN needs no permissions here)
• Pinned actions/add-to-project from @v1 to @244f685b (v1.0.2)

Merge order

This PR should merge before the per-repo caller PRs. Callers reference @main, so the reusable must exist on main first.

[yujiawei]

Code Review — PR #4 (.github)

Verdict: Approve

Small, well-scoped change that converts the existing auto-add-to-project.yml into a dual-mode workflow (direct trigger + workflow_call). The diff is +12/-1 in a single file and does what the description claims.

What's good

• Dual-mode design is correct. Adding workflow_call alongside the existing issues / pull_request_target triggers preserves coverage of the .github repo itself and unlocks per-repo callers — no behavior regression for the existing path.
• Action pinned to a commit SHA. actions/add-to-project@244f685bbc3b7adfa8466e08b698b5577571133e matches the upstream v1.0.2 tag (verified against actions/add-to-project git refs). The trailing # v1.0.2 comment is the format Dependabot recognizes for SHA-pinned actions, so updates will continue to flow.
• permissions: {} at the top level is the right default. The job authenticates to the Projects v2 GraphQL API using the PROJECT_TOKEN PAT passed as the action's github-token input; the ambient GITHUB_TOKEN doesn't need any scopes, so locking it down is least-privilege done right. The inline comment makes the intent explicit.
• workflow_call.secrets.PROJECT_TOKEN is declared required: true, which gives callers a clean failure mode if they forget to forward the secret.
• PR description is aware of the merge ordering constraint (callers reference @main, so this must land first). Good operational hygiene.

Notes / non-blocking suggestions

1. Caller pinning (out of scope for this PR, but worth flagging for the caller PRs). The description mentions callers will reference this workflow as @main. For an org-internal reusable workflow that's defensible, but consider pinning callers to a tag or SHA of Mininglamp-OSS/.github once this stabilizes — @main means a future change here ships instantly to every caller with no review surface on the caller side.

2. pull_request_target security posture is fine here, but worth re-asserting. This workflow doesn't check out PR head code, doesn't execute untrusted scripts, and doesn't expose the PAT to forked-PR contexts beyond the action's own GraphQL call. If anyone later adds steps to this job, they should remember pull_request_target runs with the base-ref context and access to secrets — keep this job narrowly scoped to "add to project."

3. No concurrency group. Not needed — actions/add-to-project is idempotent on already-added items, so duplicate triggers won't cause issues. Mentioning only so the absence is intentional.

4. Top-of-file comment is helpful. Consider also adding a one-line "callers: see <pattern> in repo <X>" pointer once at least one caller PR has merged, so future maintainers can find the consumer side without grepping the org. Not required now.

Verification

• Confirmed action SHA 244f685bbc3b7adfa8466e08b698b5577571133e resolves to tag v1.0.2 upstream.
• Confirmed YAML structure parses (single-doc, top-level on/permissions/jobs shape is valid for both direct and reusable workflows).
• Confirmed the existing direct-trigger behavior is preserved (the issues.opened and pull_request_target.opened triggers are unchanged; only additive changes).

Nothing here blocks merge. Approve.