Add solution PRs to project 18 on open

[fryorcraken]

Adds .github/workflows/add-to-project.yaml. When someone opens a PR whose title starts with Solution:, the workflow adds it to the RFP & LPrize Tracking board (project 18). It then sets Category → LPrize and Status → Proposals & Submissions to review.

It's modelled on logos-co/rfp's add-to-project.yaml (logos-co/rfp#207): same actions/add-to-project@v1.0.2, same ADD_TO_PROJECT_PAT, and the same inline github-script GraphQL step. Only the Category option ID differs. I checked the field and option IDs against the live project today.

Related to logos-co/ecosystem content/rfp_lifecycle.md, Tier 1 item 2 (auto-add new Solution: LP-xxxx PRs to project 18).

Secret

ADD_TO_PROJECT_PAT is now configured as a repo secret here. gh secret list --repo logos-co/lambda-prize shows it, added 2026-10-06. It's the same fine-grained token as logos-co/rfp's secret, which was regenerated and updated at the same time. The token's resource owner is logos-co, it has org Projects: Read and write only, and it has no repository access. That's enough because both repos are public, and rfp#207 confirms it works.

Why pull_request_target and not pull_request

Solution PRs here come from forks: all 83 past Solution: PRs are cross-repository. GitHub doesn't pass repository secrets to pull_request runs from forks, so with a plain pull_request trigger the token would be empty and the workflow would fail on every real submission.

pull_request_target runs the workflow file from the default branch, with access to secrets. Its usual risk is checking out or running the fork's code with those secrets. This workflow does neither:

• No actions/checkout and no run: shell steps.
• The only PR-controlled value it reads is the title, and only inside the job-level if: expression. That expression is evaluated by Actions, never interpolated into a script, so there's no injection surface.
• The github-script step only uses hard-coded IDs and the item ID returned by add-to-project.
• GITHUB_TOKEN is limited to contents: read. The PAT is used only for the two project calls.

validate-submission.yml makes the same choice for the same reason. That file is untouched.

Title filter

The job runs when the title starts with Solution:. That's a prefix anchor, not "title contains an LP number". It runs in two cases:

• opened: the PR is opened with a Solution: title.
• edited: the title changes into Solution: from something else (github.event.changes.title.from doesn't start with Solution:).

validate-submission tells contributors with a wrong title to rename to Solution: LP-XXXX …, so renaming is a normal path, not an edge case. Body edits and other non-title edits don't run the job, so they can't reset Status.

I replayed this against the title history of all 157 PRs in the repo: the title each PR was opened with, plus every RENAMED_TITLE_EVENT.

• 79 PRs fire on opened, and 4 fire on a rename into the prefix (Solution: LP-0016 — Anonymous Forum with Threshold Moderation and Membership Revocation  #42, Solution: LP-0003 - Private Allowlist / Airdrop Distributor #44, Solution: LP-0019: AI-Powered Logos Ecosystem Onboarding Toolkit [Prize + Solution] #54, Solution: LP-0005 — Private Balance Attestation  #74). That's all 83 PRs that have ever had a Solution: title, and none fires twice.
• No false positives. Every match is followed by LP-, including the Solution: LP-0002: colon variant and the - / – dash variants.
• Open LP-…, Close LP-…, chore: add solution link… and Update LP-0016 status … solution link are correctly skipped.
• Missed: solutions: LP-0008 — Autonomous AI Agent Module #81 solutions: LP-0008 … and Solution LP-0012 #46 Solution LP-0012 (no colon). Both are expected with a strict Solution: anchor. They can be added to the board by hand.

Things to know:

• GitHub's startsWith() is case-insensitive (per the Actions expression docs), so solution: … also matches. That's looser than validate-submission's case-sensitive ^Solution: LP- regex. Such a PR lands on the board and gets flagged by the validator, which seems fine for triage.
• Expressions have no trim(), so a title with a leading space wouldn't match. No past title has one at open time.
• A retitle away from Solution: and back, or a manual "Re-run jobs", resets Status to Proposals & Submissions to review. Adding an item that's already on the board returns the existing item, so the field step runs again. Both are rare and acceptable.

Scope

• Only adds to the board and sets Category and Status. It never removes, closes, merges, or edits the PR.
• Doesn't set the λ-Prize field. Parsing the LP number out of the title is a separate, later automation.
• Doesn't remove closed-unmerged PRs from the board (Tier 1 item 3, separate).
• Not triggered on reopened, so reopening a PR doesn't reset its fields.
• Still on actions/add-to-project@v1.0.2 / github-script@v7 to match rfp. Both trigger a Node 20 deprecation notice. Moving to add-to-project@v2.0.0 (same inputs and outputs, node24) and github-script@v8 is best done in both repos together, in a later PR.
• No other files changed.

Manual test before merging

There's no way to dry-run a pull_request_target run without a real PR. pull_request_target always runs the workflow file from the default branch, so test PRs opened while this is still unmerged won't trigger it. The secret was regenerated on 2026-10-06 and no workflow run has used the new value yet, so this test is also the token's first real use. To test:

1. Merge this PR (or temporarily push this workflow to master).
2. From a fork, open a draft PR titled Solution: LP-0000 — workflow test with any trivial change. Check the run under Actions → "Add solutions to project". Confirm the PR shows up on project 18 with Category = LPrize and Status = Proposals & Submissions to review. validate-submission will also post a failing validation comment on it. That's expected for a dummy submission.
3. Rename path: from a fork, open a second PR titled LP-0000 workflow rename test. Confirm the job is skipped and nothing is added. Then edit the PR body and confirm it's skipped again. Then rename it to Solution: LP-0000 — rename test and confirm it's added with the same fields.
4. Open a third test PR titled Open LP-0000: workflow test and confirm the job is skipped and nothing is added to the board.
5. Close all test PRs and delete their items from project 18 by hand. Closing doesn't remove them, by design.
6. Troubleshooting:
   • "Input required and not supplied: github-token" means the secret is missing or empty.
   • A GraphQL error such as "Could not resolve to a ProjectV2" means the token is present but lacks Projects write on logos-co, or has expired.

🤖 Generated with Claude Code

[github-actions]

✅ Validation passed

A reviewer will assess against the prize criteria.
ℹ️ No prize-related changes; skipping submission checks.

---

Automated check. See solution template and TERMS.