Send the PR title with the verify request

[rodchalski]

What

The PP approval page shows a request's title from the request row when PP cannot read the pull request itself (no GitHub App access to the repository in that workspace). POST /api/v1/receipts/verify has accepted an optional prTitle for a while (normalizePrTitle, schema z.string().max(300).optional()); this action never sent one, so those pages fell back to "Authorize production deploy" with no description, even for a PR with a full title and body (seen on this repo's #69).

One env entry and one jq argument:

• PP_PR_TITLE: ${{ github.event.pull_request.title }} in the step's env, never interpolated into the run: script, since a PR title is attacker-controlled text.
• --arg prTitle "${PP_PR_TITLE:-}", and the body gains prTitle, or no key at all when the title is empty (the schema rejects null). PP accepts at most 300 UTF-16 units, so the title is cut to 300 code points when each is a single unit, else 150 (an emoji is two units). An over-long title must not fail the gate closed.

No behaviour change for the gate decision; the verify route ignores the field for anything but the request row.

Checked

test/run-tests.sh (the harness that landed with #69, merged into this branch) runs the action's real script with stubbed gh and curl and inspects the exact body sent to PP. New cases:

• a title with quotes, a newline and a $(...) round-trips as a JSON string and is never executed;
• an empty title omits the key; a push-mode deploy sends no title;
• a 400-character title is cut to 300; a 200-emoji title is cut to 150 code points, 300 UTF-16 units.

77 passed locally (bash 3.2, jq 1.7.1). Reverting to a plain 300-code-point cut fails the emoji case. The repo's own gate on this PR fails closed until the request is signed, as intended.

🤖 Generated with Claude Code

[permission-protocol]

🔒 Permission Protocol

✅ Approved — human authorization recorded. View receipt
Request: cmun6xl6r000qi4ok1k048x5s · Commit: 01b89e9

---

Approval brief

Affected flow: Permission Protocol approval page display for pull requests.

Why this change: The approval page shows a generic title when Permission Protocol lacks GitHub App access to read the pull request directly.

What changes for users/operators: The PR title is now sent during verification, allowing the approval page to display the actual PR title instead of a generic fallback.

Blast radius:

• Affected: Limited to changed files shown in this PR
• Not indicated: auth, database, billing, secrets

⚠️ What this change risks

This change modifies the GitHub Action infrastructure and shell scripts to pass additional metadata. It includes safeguards against shell injection.

• Risk: 🔴 High — Infra
• Impact: If incorrect, the approval page may continue to show generic titles or fail to display the request if the title payload is malformed.
• Files: action.yml, test/run-tests.sh
• Status: ✅ Approved — receipt

---

✅ View authorization receipt →

_{Authorization recorded; use the checks below as merge/deploy verification evidence.}

---

✅ Verify before authorizing

• Confirm PP_PR_TITLE is passed via environment variables and not interpolated directly into the shell script.
• Verify the jq argument --arg prTitle handles empty titles by defaulting to an empty string.
• Check that the test suite confirms the prTitle field is absent during non-PR events like workflow_dispatch.

📋 Why was this flagged?

• The PR title is passed to the verification request via a new environment variable and jq argument.
• The change addresses a fallback issue where the approval page displayed 'Authorize production deploy' without a description.
• The PR title is handled as attacker-controlled text and passed through env to avoid shell interpolation.
• Tests were updated to ensure the title field is not present outside of PR events.

---

_{🔒 Permission Protocol · Decision: approved with human authorization}

[github-actions]

✅ Permission Protocol: Approved
View receipt →