VersionControl:PRs/pickipedia/163

pickipedia#163: Instructions: a namespace for what the runner acts on, where a removal is a proposal too

State	🟣 merged 2026-10-27 09:01:17
Worked on by	not said
Moods	not said
Deploy	not said
Branch	instructions-namespace → production, by magent-cryptograss
Opened · last pushed	2026-10-27 02:09:06 · 2026-10-27 04:19:49

From the emergence Mood, 26–27 Oct (Justin: "an 'instructions' namespace, editable only by SSH-tier users and emergents; edits by emergents go through the usual verification process; the last fully verified version is used").

## What changes

**LocalSettings.php**
- New namespace `Instructions:` (3014) and `Instructions_talk:` (3015), subpages on, searched by default.
- Edit right `instructions-edit`: the new `orders` group, `emergent`, and `sysop`. `orders` is given at Special:UserRights by a bureaucrat, like `emergent`; nothing in `emergent` can change groups. The right rides on the emergents' bot-password grants like `emergent-edit` does.
- Verification: bot groups now say `bot` and `emergent` explicitly; namespaces `[NS_MAIN, NS_INSTRUCTIONS]`; new `$wgPickiPediaVerificationStrictNamespaces = [NS_INSTRUCTIONS]`.

**PickiPediaVerification**
- **Strict namespaces** (`Hooks.php`): in one, a bot edit may not remove an existing line, or move it, unless the removal is proposed with `<proposed by="X" action="remove">…</proposed>` (block or inline). Additions are gated as before. The existing allowance (a bot may take back what it wrote, unmarked) stays everywhere else: it is right for an article and wrong for instructions, where "never push to main" taken away changes what an agent does as much as a new line would. Rejection message names the line.
- **Rendering** (`ParserHooks.php`, CSS): a proposed removal stays on the page, struck through, with a "proposed removal" badge and byline, `data-pv-action="remove"`. Light and dark.
- **Verifying** (`SpecialVerifyBotEdits.php`, verify gadget): a claim is unwrapped as before; a proposed removal is taken away, text and line.
- Config entry, messages, and checks: `check-gate.php` (13 strict cases), `check-proposed-tag.php` (removal rendering), new `check-verify-strip.php` (what verifying does to each marker), wired into Jenkins and GitHub checks.

## Why "last fully verified" works here

Additions and changes by a bot are marked by the hook already (server side, every added line). The only unmarked bot edit was a removal or a move. With that closed in this namespace, a revision with no proposal on it is one a person read whole and saved. The runner can take that revision with no list of trusted editors in its code.

## Checked

In my preview wiki's container (php 8.2): check-gate, check-proposed-tag, check-verify-strip, check-verify-brackets all pass; `php -l` clean on the three PHP files and LocalSettings; `node check-verify-js.mjs` passes; JSON valid.

Not checked against a live wiki: the namespace rights and a real save through the hook. Expect to try an emergent save that removes a line in `Instructions:` after deploy and see it refused.

## After merge, in order

1. Deploy. Add JMyles and SkymanJenkins to `orders` at Special:UserRights.
2. Move the runner-read pages into `Instructions:` (redirects left): `Cryptograss:Emergents/GeneralOrders`, `Cryptograss:Emergents/<Name>/Instructions`, `Cryptograss:Emergents/<Name>/Tasks/*`, `Cryptograss:Moods/Instructions`, `Cryptograss:Moods/<slug>/Instructions`, `Cryptograss:Moods/Dials`, `Cryptograss:Emergents/Greeting`.
3. magenta PR: bundler and task reader read `Instructions:` titles, take the newest revision with no proposal on it, drop `EDITORS`; an optional layer read before and missing now is reported as degraded (re, 26 Oct).
4. pickipedia-mcp PR: `markSource` emits `action="remove"` for lines it drops in `Instructions:`, or the emergents cannot delete there at all. Until then the hook refuses, which is the safe side.