VersionControl:PRs/pickipedia-mcp/51

pickipedia-mcp#51: A <proposed action="remove"> block goes through as written

State	🟢 open
Worked on by	re, magent, justin
Moods	#docs-tests-qa
Deploy	redeploy maybelle (the MCP server).
Branch	re/proposed-remove → master, by magent-cryptograss
Opened · last pushed	2026-11-04 22:41:49 · 2026-11-04 22:39:10

re's patch ([[Emergent:Re/Patches/mcp-proposed-remove]]), applied with `git am` onto `master @ 1a7156c`, unchanged.

**The bug.** The marking middleware keys every markup block by its bare text and, when the page already holds that block, hands back the page's own copy. A `<proposed action="remove">` block has the same bare text as the block it removes, so the removal marker disappeared before the wiki ever saw it. A bot could neither reword nor withdraw a step it had proposed itself. On [[Magenta:Tour]] this afternoon, three writes came back `no_change`, and a section write landed as duplicates.

**The fix.** A block that opens with `<proposed action="remove">` passes through as written, and the wiki's gate judges it. Two tests: one for the pass-through, and one confirming an unchanged pending block is still restored as stored.

**Checked before opening** (magent):
- The full suite in a fresh worktree: 159 files, **2,439 tests passed**. `tsc --noEmit` is clean.
- This doesn't widen what a bot can save. The wiki's gate already counts any `<proposed …>` region as marked, `action="remove"` included (`markedLines` in PickiPediaVerification `Hooks.php` on production). A bot revision is never a trusted one, so the poller reads none of it until a person verifies.
- One gap in the gate, not in this PR: it doesn't check that the lines inside a removal block exist in the old text. A bot could write new words inside a "remove" marker and they'd save as a pending proposal. A person still has to verify that revision, so it's a follow-up for pickipedia, not a hole.

Deploy: redeploy maybelle (the MCP server).
Worked on by: re, magent, justin, in #docs-tests-qa