ci: dual-trigger pr-title + label workflows for fork-PR coverage

[EricAndrechek]

Summary

Adds pull_request_target alongside pull_request on pr-title.yml and label.yml. Extends fork-PR coverage (sticky comment on title failures, auto-labeling) without hitting the chicken-and-egg that blocked a straight trigger swap in #64.

How it works:

• pull_request runs from the PR head branch — works on internal PRs with full permissions.
• pull_request_target runs from the default branch with base-repo permissions — catches fork PRs where GITHUB_TOKEN is otherwise read-only.
• Both fire on internal PRs. The duplicate run is harmless: the pr-title sticky comment is marker-based (idempotent update) and actions/labeler with sync-labels: true is idempotent (same label set applied twice is effectively one write).

A future follow-up PR can drop the pull_request trigger once we've confirmed pull_request_target is firing correctly in production.

First live test of project-orchestrator

Worth flagging: this is the first post-merge PR that should exercise project-orchestrator.yml end-to-end. Expected behavior:

• PR gets added to Task Board (project docs: add initial Astro-based documentation site #7) with Status=Ready once bot-clean
• Eric (author) → Taite assigned automatically as the non-author admin
• Admin approval check fails until Taite approves
• On merge: card transitions to Done, issue ci: switch pr-title.yml + label.yml back to pull_request_target #56 auto-closes via Closes #56

If anything in that sequence doesn't fire, it's useful signal for orchestrator fixes.

Test plan

• Validate check passes (both pull_request and pull_request_target runs)
• Apply labels runs and applies area/infra, github_actions
• project-orchestrator fires on pull_request_target, assigns Taite, adds PR to board, sets Status=Ready
• No conflicting sticky comment behavior (just one pr-title-lint-comment marker managed)
• Admin approval check fails until Taite approves, then succeeds
• On merge, issue ci: switch pr-title.yml + label.yml back to pull_request_target #56 auto-closes

Related Issues

Closes #56

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[claude]

Claude finished @EricAndrechek's task in 5m 56s —— View job

---

PR Review — ci: dual-trigger pr-title + label workflows for fork-PR coverage

• Gather context (AGENTS.md, changed files, diff)
• Review workflow correctness and security
• Check doc-sync requirements
• Post final review

---

Summary

The mechanics are correct and the prior Copilot concerns are all addressed in the current commits. Two minor issues worth noting before merge, neither a blocker.

---

Correctness

Concurrency group fix (label.yml:32, pr-title.yml:44): Including ${{ github.event_name }} in the group is the right fix. The original single-key group (label-${{ github.event.pull_request.number }}) would have let the pull_request run cancel the pull_request_target run (or vice versa) on the same PR event. On fork PRs, the pull_request_target run is the only one with write access, so cancelling it would have silently skipped labeling and the sticky comment — exactly the failure mode this PR exists to prevent.

issues: write permission (pr-title.yml:34): Correct and necessary. PR comments go through POST /repos/{owner}/{repo}/issues/{issue_number}/comments — PRs are issues at the REST layer. pull-requests: write does not cover that endpoint. This was Copilot's correct catch.

Orchestrator cleanup (project-orchestrator.yml): Removing pull_request_review_thread from the triggers was necessary — the Actions parser rejects it, which would have suppressed all triggers silently. The cleanup of the dead pull_request branch from the case statement and the elif chains is correct; the workflow never fires on pull_request events.

actions/labeler with pull_request_target (label.yml:40): Safe pattern. The action reads changed file paths from the GitHub API (not by checking out code), uses the labeler config from the base branch (correct), and is pinned to a full SHA (634933edcd8...) per the repo's supply-chain hardening requirement. No security concerns here.

---

Security — NONE

Both pr-title.yml and label.yml follow the safe pull_request_target pattern: no actions/checkout, no execution of fork-contributed code. The GITHUB_TOKEN scopes (issues: write, pull-requests: write, contents: read) are minimal. The PR title is reflected into the sticky comment body via a heredoc $PR_TITLE expansion, which is safe — bash does not recursively evaluate command substitutions in the results of parameter expansion, so a crafted title like $(id) stays as a literal string in the comment body.

---

Minor Issues

1. Duplicate sticky comment race (LOW, cosmetic)

When both pull_request and pull_request_target fire simultaneously on an internal PR (which happens for every push after this change), both runs hit the sticky-comment step in parallel. If the title fails and both runs query for an existing marker comment at the same moment (before either has created one), both will find EXISTING empty and both will POST a new comment — leaving two comments with the same `` marker. The next event only updates the first one found by head -n1, leaving an orphan. The PR description says the duplicate run is "harmless," but this specific race isn't addressed there.

Not a blocker — it's cosmetic and self-correcting on the next push. But worth tracking: if the orphaned-comment problem shows up in practice, the fix is to serialize the comment-step between the two runs (e.g., add a short sleep + retry-on-conflict, or check for duplicates and delete extras on the cleanup pass).

2. CHANGELOG.md entry inaccuracy (LOW, pre-existing)

CHANGELOG.md line 45 (present on main, not added by this PR's diff) says "Moved from pull_request to pull_request_target so fork PRs also get the helpful comment." The actual implementation is a dual-trigger (both kept), with pull_request dropped in a follow-up PR. The entry describes the end state, not the current intermediate state. Pre-existing, not introduced here, and will become accurate once the follow-up lands — but someone reading the changelog today will think the transition is complete when it isn't.

---

Copilot's Open Second-Review Comments — All Addressed

Copilot comment	Status
pr-title.yml: issues: write required for sticky comment endpoint	Fixed: line 34
Orchestrator: thread-resolution gap with pull_request_review_thread removed	Documented in workflow comment + AGENTS.md. Copilot's suggested workaround (pull_request_review_comment: [edited]) wouldn't help — thread resolution doesn't emit that event. Current "wait for next push/check_suite" is the right pragmatic choice.
AGENTS.md: stale trigger list	Fixed: AGENTS.md updated to remove pull_request_review_thread and document the gap.
Orchestrator: dead pull_request case in case statement and elif chain	Fixed: both removed.

---

Ship it — the two issues flagged above don't warrant holding this. The CHANGELOG entry will self-correct after the follow-up PR, and the duplicate-comment race is cosmetic. Copilot's second-review concerns are fully addressed.

[Copilot]

Pull request overview

Extends CI coverage to fork PRs by adding pull_request_target alongside pull_request for PR title linting and auto-labeling workflows, while aiming to preserve internal PR behavior.

Changes:

• Add dual triggers (pull_request + pull_request_target) to PR title lint workflow to enable sticky comments on fork PRs.
• Add dual triggers (pull_request + pull_request_target) to labeler workflow to enable auto-labeling on fork PRs.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/pr-title.yml	Adds pull_request_target trigger to allow base-repo permissions for fork PR sticky comments.
.github/workflows/label.yml	Adds pull_request_target trigger to allow base-repo permissions for labeling fork PRs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[taitelee]

Before this PR, we'd receive notifications on every PR opening, sending reviewers and managers tons of notifications. The issue with this, besides the fact that there are hundreds of emails being sent, is that the PR might be fully ready yet. Github instead now waits for PRs to fully pass checks via the Project Orchestrator. It watches the PR. Once the bots (Lint, Build, Test) are all green and all conversation threads are resolved, then changes can be reviewed by developers.

Because we removed the standard CODEOWNERS protection, we needed a new way to make sure no one merges "bad" code without an admin's eyes on it.

• A new Required Check called "Admin Approval" has been created.
• Even if every other test passes, the "Merge" button stays locked until a reviewer or admin submits an official "Approve" review.

Technical Highlights:

• Fork Coverage: By adding pull_request_target, we ensure that bots have the necessary "Write" permissions to post sticky comments and apply labels on external contributions which are actions that were previously blocked by GitHub's pull_request security sandbox.
• Internal Stability: Keeping the standard pull_request trigger alongside the new one prevents a "chicken-and-egg" failure during the transition.
• Idempotency: The duplicate runs on internal PRs are harmless as the labeler and comment-marker logic are idempotent (one write replaces or confirms the other without duplication).