Modify start-pull-request.yml to pass label values through env instead of inline interpolation

[github-actions]

1. Target

• Closes Modify start-pull-request.yml to pass label values through env instead of inline interpolation #95

2. Specification / Test Plan

(Text here)

3. Additional Instructions / Notes for Shipping (optional)

N/A

4. Check before Review Request

• Self Review : I reviewed changes by myself and approved them.
  • Ensure there is no sensitive information, typos, unrelated changes, or debugging code.
• Evidence : I attached evidences to prove the changes.
  • Record and attach a demo video. For minor changes, attaching an image is also acceptable.
  • Evidences should be updated to the latest version when further changes are made.

5. Evidence

(Attach here before request review)

[VibratingKoala]

Code review (high effort) on 8841740 — no findings against this change.

Verified each substitution is shell-equivalent to what it replaced: LABELS, ASSIGNEES and NEW_BRANCH_NAME are all written to $GITHUB_ENV in earlier steps so they're real process env vars where they're used, and DEFAULT_BRANCH is valid at job level (the issues webhook payload carries repository). The sink is genuinely closed — values expanded from a shell variable aren't re-scanned for $()/backticks. No ${{ }} remains inside any run: block. The other workflows (prepare-release.yml, release.yml, run-tests.yml) were checked for the same anti-pattern; none present.

Two pre-existing defects sit on lines this PR touches. Neither is introduced by it and both are out of scope for #95 — recording them here so they're not lost, to be filed separately rather than expanding this PR:

1. --label "$LABELS" aborts PR creation for an unlabeled issue (:114). There's no config.yml in .github/ISSUE_TEMPLATE/, so blank issues are enabled and a zero-label issue is possible; gh then fails with could not add label: '' not found. Because git push (:109) already ran, this leaves an orphan timestamped branch with an empty commit and no PR — and re-assigning the issue creates a second orphan rather than recovering. ${LABELS:+--label "$LABELS"} would guard it.

2. The idea/epic guard can fail open (:55). The step shell is the default bash -e {0} with no pipefail, and labels=$(gh api … | tr … | sed …) takes its exit status from sed — so if gh api errors (rate limit, transient 5xx) LABELS is silently empty, the guard takes the else branch, and a PR is created for an epic/idea issue: exactly what the step exists to block. Separately, grep -q "idea\|epic" is an unanchored substring match over the comma-joined list, so a future label like epic-candidate would falsely terminate a valid issue.

[sn0wm1ku]

Code review on 8841740 — approve, no blocking findings.

Independently re-verified the diff against the file at head:

• Correctness of the substitution. Every ${{ }} removed from run: script text now reaches the shell as a real environment variable at its point of use: LABELS / ASSIGNEES / NEW_BRANCH_NAME / OPEN_LINKED_PR_LENGTH are written to $GITHUB_ENV by earlier steps, and REPO / ISSUE_NUM / ISSUE_TITLE / DEFAULT_BRANCH sit in the job-level env: block (with DEFAULT_BRANCH newly added there — github.event.repository.default_branch is available on the issues trigger). No ${{ }} remains inside any run: block in this workflow.
• The sink is closed. A value expanded from a shell variable is not re-scanned for $()/backticks, so a metacharacter-bearing label name can no longer execute in a job holding contents/issues/pull-requests/id-token: write. This is the handbook's required shape — data must cross into an interpreter as data, not be concatenated into script text (application-security.md §3-9 "encode/parameterize at the sink", §3-10 command/template injection defences).
• Scope is minimal and matches #95 exactly — the fix the issue proposed, nothing else (code-review.md §3-1: correct and minimal, KISS/YAGNI). CI (run-tests) is green on head.

The two pre-existing defects on touched lines (unlabeled issue aborts gh pr create after the push, leaving an orphan branch; the idea/epic guard failing open when gh api errors under default no-pipefail shell) are already recorded in the thread and are correctly kept out of this PR — they predate it and belong in their own issue.

---

_{🤖 auto-posted by sn0wm1ku/ghDuty · co-authored by Claude (claude-opus-4-8)}