Green was the thing forcing the safe path (revert T-1503, harden the handoff)

[MongLong0214]

Reverts 532c30f4 and hardens the handoff it was built on top of.

Why T-1503 is rejected rather than fixed

It made a source-only pull request green. Green is mergeable, and the button then lands src/ with no rebuilt dist/ — main carrying a bundle that does not match its source until the next push run goes red, after the fact rather than before it.

#761 was red, and that redness is why it went through canonical-merge instead of through its own merge button. The friction was the mechanism.

What T-1503 was written to fix is already fixed by T-1502, without the risk: a contributor opens the source-only pull request and never rebuilds anything. Its checks being red is a statement about the artifact, not a demand on them.

The measurement T-1503 produced is kept in the ticket, because it is the part worth having: "drop the diff line" was wrong, since CI rebuilds before it verifies and a source-only pull request dies at artifact:verify without ever reaching the diff.

The handoff was proven against a pull request the owner wrote

publish carried a comment saying it "only moves bytes it verifies", and it verified none of them.

what	before	now
bundle contents	force-pushed as received	merge recomputed here from main + the PR ref; both parents pinned; a difference allowed only inside dist/ and the manifest
PR head race	unchecked	refused if #N's head moved since the rebuild fetched it, and if the ref no longer resolves to it
push result	git push exit code	ref read back by sha; refused if the server holds anything else
App token	body-less mint — every permission on every repository the installation holds	scoped to this repository, contents: write + pull_requests: write

The rebuild job runs a contributor's package.json and every lifecycle script npm ci pulls in. Anything there could add a commit touching src/, scripts/ or .github/, and this job would have force-pushed it under the App's identity for a reviewer to read as a rebuild.

T-1504 and the PRD

T-1504's acceptance moves from a person-observation — "a non-Linux contributor completing a source change unaided" — to the system properties it was standing in for. That gate cannot be satisfied from inside the repository, so it left the work permanently unfinished for a reason unrelated to the work. It was also indifferent to what it named: the canonical build never runs on a contributor's machine, so "non-Linux" was a proxy for "cannot run the canonical build" and the mechanism does not distinguish the two.

Field experience is recorded as a Limit instead: adoption evidence, not a correctness gate. A real-world failure reopens #719 or opens a defect issue.

The PRD's success criteria are fixed against the runs that show them. The old first criterion — "no pull request carries dist/" — is contradicted by the thing that was built: the canonical pull request carries exactly that, and carrying it is how the required contexts run on the tree that lands.

Verified

Reverting the hardening fails all three new workflow assertions; restoring it passes nineteen.

The ordering assertion for the credential step was matching the other job's identically-named step after a rename — both jobs check that main stood still — so it was asserting nothing about the publishing job. Re-anchored on the renamed step and extended to cover the new verification.

ci.yml's locked digest is back to 473b1fc0… and matches the file.

Still open, and it needs the owner

Merge-commit-only is not enforced. It is a sentence in a pull request body, which is a check somebody has to read — the exact shape that cost #752 its merged label during the 1.1.3 release. The repository still allows squash and rebase, and the merge button remembers the last method used.

gh api -X PUT repos/MongLong0214/commitlore -F allow_squash_merge=false -F allow_rebase_merge=false

Recorded as the Limit on this commit until it is done.

[github-actions]

CommitLore — record lint

Trailers: clean — 3 commits in origin/main..b1c0e2907a17042cd5693336caa37a5ac35af695
Active constraints: not read — commitlore: git log --follow accepts exactly one pathspec, so renames are not followed for 11 paths; query one path at a time to follow its rename chain (11 changed paths)

_{Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR.}

[MongLong0214]

Merge-commit-only is now enforced. The owner directed it and it landed; I read it back from the API rather than taking it on report:

merge=true  squash=false  rebase=false

So the Limit on the first commit here is out of date, and c5287b2 corrects it rather than amending — the branch is pushed, and the record's Record-Id cannot appear twice.

The ticket said the method "is not enforceable from here" and handed the choice to the owner. That was wrong in a specific way: it was enforceable, it just was not enforced.

before   the body asks for a merge commit        the seat where the name is written
after    squash does not exist on this repo      the seat where it is enforced

The canonical pull request's body still says it, for a reader who wants to know why the branch is shaped that way. It is no longer what holds the property.

What moved rather than disappeared, recorded as the new Limit: the guarantee now lives in a repository setting that nothing in this repository reads. A future owner can re-enable squash and no test, workflow or gate here will notice — only a canonical pull request quietly failing to close its source. Smaller surface than a sentence in a body, and not zero.