Proposals Dashboard v4

P1: Boundary Gate PENDING

Derived from: boundary-gate-integration-2026-04-14, loop.metta eval seam analysisDescription: Wrap eval in loop.metta line ~56 with boundary-check predicate. If command not in allowlist or path outside sandbox, block execution.Intention: Prevent runaway or dangerous mutations from reaching the MeTTa runtime. Enforce least-privilege at the eval seam.Detailed Implementation:

1. boundary_gate.metta defines (boundary-check cmd) returning Safe or Blocked via command allowlist.
2. path-in-boundary checks file args against /home/mettaclaw/safe/ prefix.
3. Insert gate: replace (eval $s) with (if (== (boundary-check (car-atom $s)) Safe) (eval $s) (Blocked $s)) at line ~56.
4. Test: 5 cases verified (shell=Safe, query=Safe, dangerous-cmd=Blocked, safe-path=Safe, /etc/passwd=Blocked).
5. Submit patch to loop.metta maintainer (Jon) for review. No unilateral merge.

Risks: car-atom may not exist in all PeTTa runtimes. Overly strict allowlist blocks legitimate commands. Gate adds latency per eval.Side Effects: New dependency on boundary_gate.metta. May require allowlist maintenance as new skills are added.Next Action: Test car-atom in live PeTTa runtime, then submit PR to Jon.

P2: Nondet Pattern Template PENDING

Derived from: Repeated nondeterministic matching failures in MeTTa expressionsDescription: Reusable template for nondeterministic pattern matching with ordered fallback and failure reporting.Intention: Reduce boilerplate and errors when writing MeTTa patterns that must try multiple branches.Detailed Implementation:

1. Define (nondet-match $pattern $cases $fallback) atom in template.metta.
2. $cases is ordered list of (pattern action) pairs tried left-to-right.
3. If no case matches, evaluate $fallback which logs the failure context.
4. Validate on 2 existing use cases: boundary-check dispatch and ethics-KB norm lookup.
5. Document usage pattern in skill memory.

Risks: Template may hide match failures if fallback is too silent. Performance unknown for large case lists.Side Effects: Adds abstraction layer that all future pattern code may depend on. Must keep template stable.Next Action: Implement template, validate on 2 existing use cases, benchmark.

P3: Command Pre-Validation NEW

Derived from: Cross-task pattern analysis: 45% of failures are parse-level paren/quote errorsDescription: Preflight checker that validates parenthesis balance, quote matching, and known skill names before command submission.Intention: Eliminate the largest single failure class. Catch errors before they waste a cycle.Detailed Implementation:

1. Build cmd_validator.py with three checks: paren balance, quote pairing, skill-name whitelist.
2. Input: raw S-expression string. Output: PASS or list of specific errors with positions.
3. Test corpus: 15 known-good commands and 15 known-bad commands from recent history.
4. Target: 100% detection on known-bad, 0% false positive on known-good.
5. Integrate as pre-send hook or manual check step in workflow.

Risks: Validator itself could have bugs that reject valid commands. May not catch semantic errors, only syntactic.Side Effects: Adds one processing step per command cycle. Could create false confidence if not labeled experimental.Next Action: Build validator, test against 30-command corpus, report accuracy.

P4: Script-First Pattern NEW

Derived from: Quoting loop failures when embedding code in shell/write-file commandsDescription: Codify write-file-then-execute as default pattern for any multi-line code generation.Intention: Avoid quoting collisions by never embedding complex code inline. Proven by v4 dashboard success.Detailed Implementation:

1. Document rule: any code over 3 lines must use write-file to disk, then shell execute.
2. For HTML: write directly, skip Python generators when possible.
3. Add cleanup step: remove temp files after verified deployment.
4. Test on next 5 code-generation tasks and track failure rate vs inline approach.
5. Store as remembered skill with examples.

Risks: Temp files may accumulate if cleanup fails. Write-file still has quote limits for very large content.Side Effects: Disk usage in /tmp increases. Multiple files per task instead of inline commands.Next Action: Document in skill library, add cleanup, test on next 5 tasks.

P5: Ethics NAL KB DONE

Derived from: Ethics reasoning requirements, Esther governance discussionsDescription: Knowledge base with 6 precedence pairs covering 4 norm levels. Linear ordering confirmed via NAL inference.Intention: Provide formal ethical reasoning capability with auditable inference chains.Detailed Implementation:

1. 6 NAL inheritance pairs defining norm precedence (safety > autonomy > beneficence > justice).
2. Each pair has stv confidence >= 0.85 from documented ethical frameworks.
3. Tested: transitive closure produces consistent linear order with no cycles.
4. Integrated with safety card v1 for runtime ethical checks.
5. COMPLETED. Awaiting adversarial edge case testing and Esther review.

Risks: Linear ordering oversimplifies real ethical dilemmas. Edge cases may reveal conflicts not captured by 4 levels.Side Effects: Creates normative dependency - future ethical reasoning inherits these precedence assumptions.Next Action: DONE. Next: adversarial edge cases and Esther review.

P6: Proactive Demo Strategy NEW

Derived from: Ben positive response to unsolicited ReBaM demo, brand engagement analysisDescription: Formalize proactive demo deployment: identify high-value contacts, build targeted demos, deploy with tracking.Intention: Convert passive awareness into active engagement loops. Validated by Ben response rate.Detailed Implementation:

1. Contact targeting: 3 high-value contacts - Ben (reasoning demos), Jon (governance dashboards), Kevin (operational tooling).
2. Demo template: dark-theme HTML with hero section, capability showcase, call-to-action.
3. Per-contact customization with domain-specific examples and recent results.
4. Deploy pipeline: write-file, scp, send personalized message. Track response rate.
5. Target >60% response rate. Reassess strategy if below 40% after 3 demos. Limit 1/week, include opt-out.

Risks: Unsolicited demos could annoy if poorly targeted or too frequent. May create expectation of regular output.Side Effects: Shifts time from core dev to outreach. Creates maintenance burden for demo artifacts.Next Action: Identify 3 contacts, draft demo concepts, deploy first within 48h.