chore(ci): add edited trigger to check-sprint and auto-add workflows

[lml2468]

This PR adds the edited event to the pull_request_target.types trigger in both check-sprint.yml and auto-add-to-project.yml, enabling the Issue-first Sprint check flow to work correctly when a developer adds a Closes #<issue> reference to a PR description after opening.

[lml2468]

[COMMENT] Correct and safe — adding edited trigger to metadata-only workflows.

✅ Both workflows use pull_request_target without checking out PR code — no security concern with the edited trigger.
✅ actionlint passes — trigger syntax is valid.
✅ Logic is sound: re-running sprint check and auto-add when PR description is edited enables the issue-first workflow (adding Closes #N after initial open).

💬 CI notes (not blocking):

• check-sprint fails because Sprint is not set on the project board (unrelated to code).
• welcome fails due to the permissions bug fixed in PR #55 (pending merge).

⚠️ Cannot approve: PR author and review account are the same (lml2468). Needs another maintainer's approval.

[yujiawei]

Code Review — PR #57 (octo-admin)

1. Verdict Summary

This PR adds the edited event type to pull_request_target triggers in two CI workflows so that the Issue-first Sprint check re-evaluates when a developer fills in Closes #<issue> after opening a PR. The change is small (2 additions / 2 deletions), well-scoped, and addresses a real gap in the existing trigger set.

Item	Status	Note
Correctness — solves stated problem	✅	edited fires on PR title/body changes, which is exactly when a Closes #N reference would be added post-open
Security under pull_request_target	✅	Top-level permissions: {}; no PR-head checkout; delegates to org reusable workflow with explicit secret
Branch / scope filters preserved	✅	branches: [main] in check-sprint.yml retained; only base-branch=main PRs are affected
YAML syntax / formatting	✅	Valid; only the types: array expanded
Doc consistency with new trigger	⚠️	The KNOWN LIMITATION comment in check-sprint.yml still lists (opened, synchronize, reopened) as the trigger set; now stale post-merge

2. Findings

P0 / P1 — none

No correctness, security, or data-loss issues identified.

P2 — Stale documentation comment in check-sprint.yml

.github/workflows/check-sprint.yml:9 contains a multi-line KNOWN LIMITATION block that explicitly enumerates the old trigger set:

This check re-evaluates only on pull_request_target events (opened, synchronize, reopened).

After this PR, the trigger list at line 36 is [opened, synchronize, reopened, edited], so the comment is no longer accurate. Worth updating in the same PR (or a quick follow-up) to mention edited and to note that PR-body edits (e.g. adding Closes #N) now also re-trigger the check. Not a merge blocker — purely a documentation drift nit.

Suggested edit (illustrative):

# This check re-evaluates on pull_request_target events
# (opened, synchronize, reopened, edited). The `edited` trigger
# covers post-open PR description changes such as adding a
# `Closes #<issue>` reference.

Maintainability / suggestion (non-blocking)

• auto-add-to-project.yml adds edited alongside opened. The PR description focuses on the Closes #N flow for the sprint check; for the auto-add workflow, edited typically only matters if the reusable workflow does additional work beyond initial project membership (e.g. re-syncing fields based on body content). If it just adds-to-project once and is a no-op on subsequent calls, the trigger is harmless but adds noise. A one-liner in the PR description clarifying the intent for auto-add-to-project would be helpful for future readers.

3. Notes

• pull_request_target semantics are correct here: it runs with base-branch workflow definitions and base-branch secrets, no PR-fork code is checked out, so adding event types does not widen the attack surface.
• Increased fire frequency from edited is bounded — PR title/body edits are infrequent compared to pushes — and the downstream reusable workflows are short.
• Head SHA verified: 72b094df253e4604e4928009fa8c6eba2cd4634e. Files at this SHA match the diff posted on the PR.

4. Recommendation

Approving. The doc-comment drift in check-sprint.yml is worth fixing but does not need to block merge; it can be done in this PR or a trivial follow-up.

[Jerry-Xin]

Summary: This PR is relevant to the repository and the trigger change correctly supports re-running the sprint/project automation when a PR body is edited.

💬 Non-blocking

• 🔵 Suggestion: .github/workflows/check-sprint.yml:8 The header comment still says the workflow re-evaluates only on opened, synchronize, reopened; it should include edited to stay accurate after this change.

✅ Highlights

• 🔵 The PR is in scope: it updates repo-owned CI automation for PR/project workflow behavior.
• 🔵 The pull_request_target usage remains consistent with the existing security posture: no PR code is checked out or executed in these wrapper workflows.
• 🔵 No tests are necessary for this small workflow trigger-only change.