Research proposal usage and design KingMode HTML mockups

Designing high-stakes proposals with ironclad guardrails (firewall, polarity, ADR-18 floor) and domain-agnostic, a11y-compliant mockups that operator must confirm before code.

• · proposals array [{key, num, file, title}] (default batch-1 if omitted)
• · outDir (default reports/proposals/mockups/)
• · target (default dashboard/ui-next/)

• · design-brief + end-user usage + persona-walk + mock-data spec + KingMode design direction
• · self-contained KingMode .html mockup file (stops at mockup gate; code phase is separate)
• · adversarial 2-refuter verify verdict (firewall/polarity/ADR-18/feasibility)

• · proposal files readable at path
• · docs/2026-06-11-beta-proposals-initiative.md present
• · dashboard/ui-next/ structure accessible for component/token reuse
• · firewall/polarity/ADR-18/FROZEN surface definitions known

• · breaches FIREWALL (G1): reads certPortal or creates coupling (high-severity gate violation)
• · POLARITY (G2) violation: feature allows SM to monitor itself (CRITICAL block)
• · ADR-18 violations: missing 3-frame presence, HITL gate, or a11y axe failure
• · domain contamination: hardcoded monitored-project vocab, JOB-IDs, agent-role names
• · FROZEN surface modification: changes governance.py, message_bus, cli_pool, etc. (BLOCKED)

• · named safety constraints: FIREWALL (G1), POLARITY (G2), ADR-18 inviolable, FROZEN surfaces
• · KingMode persona + intentional minimalism (every element earns its place)
• · 2-refuter adversarial verify (firewall/polarity/ADR-18/feasibility) before gate
• · explicit STOPS at mockup gate (no code until operator approval)