[kriszyp]

⊙ Problem

harper and harper-pro now send a docs preview only while a PR has the docs-preview label (harper#4044, harper-pro#1275). This receiver still treats every open PR as wanting one. Removing the label leaves the preview up until the PR closes. A build started just before label removal can still deploy after cleanup ran.

💡 Solution

A preview is wanted only while the PR is open and labeled docs-preview. Cleanup of an open, unlabeled PR now removes the preview. A deploy for an unwanted PR is skipped. Apply re-reads the PR when it runs, so a late build sees the label removal. The removal comment says whether the label was removed or the PR closed.

🔧 Changes

• wantsPreview and DOCS_PREVIEW_LABEL define the rule. resolveSource and decide both use it; decide checks it before checking the head and build result, so a stale build cannot deploy. Look hardest at that ordering.
• removedBody(reason) and the ready comment name the label. The workflow passes the reason from the Decide step to the report step as an output, with no second PR read.
• CONTRIBUTING.md describes the label opt-in. Tests cover both repos, missing or malformed labels, relabeling and unlabel-then-close.

✅ Verification

• npm run test:workflows: 30/30. The five required cases (unlabeled cleanup removes, labeled cleanup skips, unlabeled deploy skips, labeled deploy at the current head deploys, closed with a comment removes) are covered. Against origin/main's script, the new tests fail (6 of 30).
• npm run lint and npm run typecheck are clean. actionlint is not installed here; the npm actionlint build reports only the existing cache-mode key, which it does not know.
• Not run end to end: a live label, unlabel and push on a draft PR in each source repo. Do that after merge. Both senders are merged and send the cleanup dispatch on unlabel (harper docs-preview.yaml).
• Runs dispatched before this merges keep the old receiver. Let them finish, then send a cleanup for any unlabeled PR that still has a preview.

⚖️ Alternatives

🤔 Cleanup is sent only on unlabel, or on close with the label

The senders skip cleanup when an unlabeled PR closes. A preview deployed before the label gate, on a PR that never got the label, would then stay up. No such preview exists: this receiver has never run (0 workflow runs). Cleanup on every close would be a harper and harper-pro change.

🤔 Eligibility is read once, at Decide

Deploy and Drop act on what Decide read. A label change after Decide is handled by the dispatch that change sends: its apply job queues behind this one in the same concurrency group and re-reads the PR. Re-reading before each step would shorten that window but add two API calls per run.

🤔 Neutral removal text

Planning review suggested one fixed sentence ("The preview has been removed") to avoid the reason output. I kept the reason because the task asked for it, and the output comes from the same PR read that chose removal.

_{🤖 Generated by Claude Code (Claude Opus 5.5); posted via @kriszyp.}

Related PRs: none found (partial scan: one PR sharing a changed path could not be fetched; the trigger side is HarperFast/harper#4044 and HarperFast/harper-pro#1275, both merged)
Complexity: easy

Origin — the dispatch brief this PR was written from

Make the source-PR docs preview receiver (scripts/source-pr-preview.mjs and its workflow) treat a harper or harper-pro PR as wanting a preview only while it is open AND carries the 'docs-preview' label. Removing the label must take the preview down, and a late build for a PR without the label must not deploy.

Acceptance

• Unit tests (npm run test:workflows) covering:
  • an open, unlabeled PR + cleanup → remove;
  • an open, labeled PR + cleanup → skip;
  • an open, unlabeled PR + deploy → skip;
  • an open, labeled PR + deploy at the current head → deploy;
  • a closed PR with a live comment → remove.
    Watch the first case fail on origin/main first.
• Lint, typecheck and actionlint clean.
• Draft PR, cross-linked to harper#4044 and harper-pro#1275 on a typed Related PRs line. Do not mark it ready or merge it.

_{Dispatch: task documentation-preview-label-cleanup · queued by kris-session · ran by claude/sonnet/high · worker kris-mac-m3-fleet-18b9c6}

_{Review-Coverage: authored=claude; ran=gemini,cursor-composer,codex; adjudicated=domain; declined=cursor-grok,muse; rounds=1; full=1 @ cb35631}

_{Review-Attention: read ~3m (decisions: remove-on-unlabel, producer-cleanup-scope, decide-time-snapshot) @ cb35631}

[dawsontoth]

Is that... me?

[kriszyp]

HEG re-run on cb35631. The earlier run worked without the harper-engineering-guidelines skill loaded. This run loaded it and went through the applicable steps. No code changed, so the scheduled merge of cb35631 still applies.

HEG step	Missing before	Done now
9, 12: gates	—	npm run test:workflows 30/30; lint, typecheck and prettier clean
10: pre-push review record	Recorded only on the earlier worker, so the footer check could not run here	Full round on this worker: codex, gemini and cursor-composer, adjudicated by the domain pass. 0 blockers or majors; 1 minor and 4 nits, all declined with reasons (below)
10: deferred finding	e1b7c1551c2fc3ca (unlabel teardown depends on the senders) was NOT FILED	Checked against the senders: harper#4044 and harper-pro#1275 are merged, and both send docs-source-pr-preview-cleanup on unlabel. Nothing is left to track
14: description	No AI attribution footer, no tour decision, Related PRs: written in prose	Added the attribution and <!-- tour: none … -->. Related PRs: is now in the typed form, and the footers were rebuilt by the helper
14: 🤔 decisions	The review's decisions had no 🤔 entry in the body	Added 🤔 entries for "cleanup only on unlabel or labeled close" and "eligibility read once at Decide"
21: Ready gate	—	Not applicable: a person already marked the PR Ready, so no Ready-For-Promotion: line was written

What happened to the review's findings:

• Minor, declined: a preview deployed before the label gate on a never-labeled PR is never removed. The receiver has 0 workflow runs, so no such preview exists.
• Nits, declined: deploy after unlabel and drop after relabel. A queued dispatch in the same concurrency group re-reads the PR and corrects either one.
• Nits, declined: the removal reason is fixed at Decide (both reasons are true when they are computed), and the "Deploying…" text does not mention the label (it is temporary).

_{🤖 Generated by Claude Code (Claude Opus 5.5); posted via @kriszyp.}