🏗️✨：land a pull request as one good commit

[DerekNonGeneric]

The half-step: the message building, under test and in version control, still driven by hand. No credential, no workflow, no label — those wait until the org's commit styles settle.

What it does

nps land <number> squashes a pull request into one commit whose message it composes itself, rather than letting the GitHub interface take the pull request body or nothing at all:

• one commit lands as itself;
• several land as one, every message kept whole, each subject a heading in the body — the first included, since a title describes the whole and need not be any single commit's subject;
• trailers are lifted out of wherever they were written and gathered into the single paragraph at the end that git actually reads, in the documented order;
• PR-URL is added, and a Refs: duplicating a Fixes: for the same issue is dropped.

Then it validates that message and refuses to merge if it fails. nps "land <number> --dry-run" prints it without landing.

It has already earned its keep

This is the script that landed the last nine pull requests, and it refused twice while doing it: once for a 73-character body line, once for a Fixes: left stranded mid-body where git would not have read it. Both were real, and both would have landed otherwise.

Built for an organization that has not decided yet

You said you are unsure what the commit style across the repos will be, so the seam is explicit. build/shared/landing.mts knows nothing about what a subject looks like — composing a landed message is the same job whether a repository writes feat: or 🏗️🔧：. Only the caller supplies the rules.

That matters because the styles genuinely differ today. Running this repository's validator over real subjects from five OpenINF repos:

.github              3 problems: “🐞” is not a category emoji
docker-fisher        1 problem:  needs an emoji prefix and “：”
inf.is               2 problems: needs an emoji prefix and “：”
openinf-util-text    1 problem:  needs an emoji prefix and “：”
this repo            passes

So when this is extracted, the composing goes as-is and the subject rule becomes configuration. Nothing here has to be rewritten to make that true.

Verification

• 11 tests on the composing, including that the message it produces passes the commit rules, and that git interpret-trailers --parse reads exactly the trailers intended
• nps test — 16/16 tasks, 56/56 tests
• Every refusal path exercised by hand: a merged pull request, a closed one, a non-numeric argument, and no argument at all. Each reports in one line rather than throwing.

Two defects found while writing this, both by the pipeline rather than by me: tsc caught a comparison against draft typed as a string when it is a boolean, and a closed pull request used to spin for twenty seconds before throwing, because it reports mergeable_state: unknown for ever.

Note

Not included, deliberately: the credential, the commit-queue label, and the workflow. Those are Phase 3, and the multi-repo requirement changes their shape — an App rather than a personal token, a reusable workflow in OpenINF/.github, and the rules published as a package. None of it is worth building until the subject style question is settled, and none of it is blocked by this landing here first.

[netlify]

✅ Deploy Preview for gh-pages-openinf ready!

Name	Link
🔨 Latest commit	ce3b2e0
🔍 Latest deploy log	https://app.netlify.com/projects/gh-pages-openinf/deploys/6a7fc6df1b7d69000808049d
😎 Deploy Preview	https://deploy-preview-1814--gh-pages-openinf.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.