Standards map integrity red on main: 5 unmapped top-level entries (2 ULTRAPLANs, arena-session-787, patches, ziz-drop)

[hyperpolymath]

What is red

Standards map integrity (Gate D, scripts/check-standards-map.sh) fails on standards main itself (5fb9ad19). Surfaced by #1088 (run 36737173709, job 109961819343); reproduced locally on a clean checkout of main, rc=1:

FAIL  unmapped top-level entry: ULTRAPLAN-2026-09-24.adoc
FAIL  unmapped top-level entry: ULTRAPLAN-2026-09-29.adoc
FAIL  unmapped top-level entry: arena-session-787
FAIL  unmapped top-level entry: patches
FAIL  unmapped top-level entry: ziz-drop
GATE D FAILED — 5 violation(s).

Where each entry came from (last-touch history on main)

entry	introduced / last touched by
ULTRAPLAN-2026-09-24.adoc	#1053, #1064
ULTRAPLAN-2026-09-29.adoc	#1064, #1067
arena-session-787/	#1051, #1052
patches/	#1047 (airborne-submarine-squadron remediation)
ziz-drop/	#1048 (Žiz design, JEG spec, tree-sitter skeleton)

The gate is path-filtered, so these landed without it running.

Acceptance criteria

• Each of the five entries is either mapped in standards-map.toml (with entry_count updated) or moved/removed from the repository root. Which one per entry is an owner decision: patches/ and ziz-drop/ look like payloads for other repos, the two ULTRAPLANs and arena-session-787/ look like dated working records.
• bash scripts/check-standards-map.sh exits 0 on main.
• Positive control: adding an unmapped top-level file makes it exit non-zero again.
• Follow-up decided: should Gate D run on every PR (or on push to main) so a new root entry is caught by the PR that adds it?

Per the standing stopping rule this is an issue, not a blocker for #1088.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QYY8Gp4v4x2J7iSNn1vZ57