Add plugin mcode-docs: evidence-graded factual baseline for mcode

[weekbin]

What changes

Adds a new Plugin, plugins/weekbin/mcode-docs — an evidence-graded factual baseline for MiniMax Code (mcode). 38 files, all new; nothing outside the Plugin directory is touched.

The problem it solves. Material describing mcode is scattered across the packaged README, the official open-source repository, runtime configuration files, and minified build artifacts. Retrieval difficulty is low; the real risk is adopting a plausible but incorrect assertion. Three failure modes recur, and this Plugin corrects all three:

Widely assumed	Reality
mcode mcp add, mcode skill list and similar subcommands exist	None of them are present. Those capabilities are reached through configuration files and TUI slash commands.
The absence of PreToolUse in minified artifacts means no hook system exists	The opposite: eleven events are defined, and they are compatible with the Claude Code event model.
Filesystem snapshot rollback, Gist sharing, code formatters, and model warming are mcode features	None of these are implemented.

What it ships.

• skills/mcode-docs/ — a reusable Skill plus nine reference documents: the complete TUI slash command table, the CLI / headless / ACP surface, configuration structure and per-OS data directories, agents and skills, the Plugin and MiniApp authoring contracts, the full Hook contract (events, registration document, stdin contract, process environment allow-list, control output fields, permission updates, time budgets, diagnostic codes), MCP and built-in tools, permission modes and Plan Mode, sessions, and a capability-boundary crosswalk.
• site/ — a bilingual (zh default, en) purely static HTML site. No build step, no package manager, no CDN, no network request of any kind; it runs under file://. Full-text search, per-block copy, scroll-tracking outline, mobile drawer, opt-in dark theme, and three architecture diagrams.
• VERIFICATION.md — the evidence ledger. Every claim is graded A (live run on a local install) / B (first-party files shipped in the package) / C (authoritative definitions in the official source) / D (real runtime configuration), and carries its counter-examples and correction records. Baseline version 0.5.8.
• verify/ — a documentation-proof harness: 49 claims across five domains, three check kinds (doc / source / exec), bidirectional set assertions with a reviewable exemption table.
• test/ — presentation-discipline and harness-logic regression tests.

Note on symbol names. Minified build artifacts retain string literals, not symbol names, so a claim that cites a symbol name cannot be re-verified against the shipped bundle. The harness therefore asserts against literals. An earlier revision of the manual cited a symbol that no longer exists after minification; that correction is recorded in VERIFICATION.md and is now permanently re-checked by the cli.side-session-commands claim.

User value

An mcode user or Plugin author can ask "does mcode support X?" and get a verdict plus a citation instead of a plausible guess. Capabilities that were checked and found absent are stated as absent together with a supported substitute, rather than being omitted or guessed.

Example prompt

Does mcode have filesystem snapshots with point-in-time rollback?
I need to restore a file to how it looked 20 minutes ago.

Expected result

The agent answers that mcode has no global filesystem snapshot facility, and does not stop at the denial. It states that /history, /fork and /rewind act on sessions and conversation history rather than on the filesystem, so they are not a substitute; it gives git as the supported alternative; and it cites both the ledger entry in VERIFICATION.md and the manual section that settles the question.

Dependencies and platforms

• Required executables: none at runtime. The Plugin ships a Skill and static files, registers no MCP server, and starts no process.
• Accounts / paid services: none.
• Platforms: any platform with a browser. The site was measured on macOS and uses no platform-specific API. The verify/ harness that maintains the manual needs Node.js ≥ 22 and mcode 0.5.8; it is run by the maintainer, not by end users.
• Third-party dependencies: none. package.json declares no dependency.

Network and data behavior

• The Plugin performs no network request at any point, at install or at runtime.
• The site loads no external font, image, script, or stylesheet. It runs under file://; the clipboard fallback path was verified explicitly.
• The Plugin collects, transmits, and stores no data and contains no telemetry.
• verify/ reads the local mcode installation and the local source tree, writes a report under verify/evidence/ (git-ignored), and sends nothing anywhere.

Plugin submission checklist

• Plugin lives at plugins/<github-owner>/<plugin-name> — plugins/weekbin/mcode-docs
• plugin.json name matches the Plugin directory — mcode-docs
• README.md includes a real example prompt and expected result
• LICENSE and plugin.json declare an open-source license — Apache-2.0 in both
• Required executables, accounts, paid services, and supported platforms are disclosed
• Network destinations and data handled by the plugin are disclosed
• No credentials, private endpoints, hidden telemetry, installers, symlinks, or native binaries are included
• Every scaffold TODO has been replaced — 0 matches for TODO|FIXME|XXX|PLACEHOLDER
• npm run check passes

Evidence

Automated — repository gate

$ npm run validate
OK   plugin weekbin/mcode-docs
Validated 29 hosted Plugins and all examples.

$ npm run check
# tests 389
# pass 388
# fail 0
# skipped 1

npm run check was re-run in an environment where mcode is not on PATH, to demonstrate the Plugin adds no hidden dependency on the author's machine. The single skipped test (workspace-lock Git operations disable repository transaction hooks) is a pre-existing skip in another Plugin and is unrelated to this change.

Automated — documentation proof harness

$ node plugins/weekbin/mcode-docs/verify/run.mjs
mcode-docs 文档校对
  mcode 0.5.8 · 2208ms

  域            总    pass    fail    skip    uncovered
  architecture  13    13      0       0       0
  cli           15    15      0       0       0
  config        5     5       0       0       0
  hooks         11    11      0       0       0
  permissions   5     5       0       0       0
  总计          49    49      0       0       0
PASS  全部 claim 已验证

This harness is deliberately not part of npm run check: it needs mcode and its packaged source, so it runs when the maintainer re-verifies against a new version. The test/ suite that is part of npm run check covers presentation discipline and harness logic, and requires no mcode.

Manual — site, both themes

Measured with headless Chrome via getBoundingClientRect (layout read from the live DOM, not inferred from the CSS):

Page	Theme	Horizontal overflow	Diagrams
index.html (zh)	light	none (scrollWidth 756 = innerWidth 756)	3
index.html (zh)	dark	none	3
index.en.html (en)	light	none	3
index.en.html (en)	dark	none	3

Each figure measures 720px, equal to the prose column width. Diagram styling goes entirely through dg-* classes bound to the existing semantic tokens, so dark mode follows the token override; there is no per-theme diagram rule, and the suite asserts that so a future hard-coded html[data-theme="dark"] .dg-* override fails the build. No figure contains a hex or rgb() fill or stroke — the only inline values are fill="none" and one currentColor arrowhead per figure.

Also checked by hand: light theme is the default on first visit (the system prefers-color-scheme query is deliberately not consulted), dark mode persists across reloads, and index.html is always Chinese while index.en.html is always English.

Security scan

Upstream CodeQL (js/bad-html-filtering-regexp) flagged one high-severity issue in verify/lib/doc.mjs: the visibleText helper stripped <script> and <style> blocks with a regex that required > to follow the tag name immediately, so it did not match </script > — a form a browser also treats as closing the block. A second round with a stricter sample (</script\t\n bar>, i.e. attributes before the >) confirmed that no single fixed suffix is sufficient.

The consequence is confined to the verification harness, but it was a real defect: had the site used such a form, script source would have leaked into the extracted visible text, and a doc claim could have anchored on JavaScript — which breaks the premise that doc checks read visible text rather than source markup. The pattern now accepts any run of non-> characters before the closing bracket, matching how the HTML tokenizer actually ends a script element, while staying non-greedy so it still stops at the first closing tag.

Regression tests cover all three closing forms and pin the non-greedy termination. They were validated in both directions and discriminate between the three implementations:

visibleText script-close pattern	test result
</script>	reports red
</script\s*>	reports red
</script[^>]*>	green

Disclosure review before opening this PR

All 38 files were scanned for API keys and tokens, absolute home-directory paths, e-mail addresses, and the author's real local proxy port: no hits. The single 127.0.0.1:7890 in the manual is a generic loopback proxy example in the network-proxy section, not the author's configuration.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}