ANTI_SLOP.md

Anti-Slop — No Lazy Code, No Fake Checks

Slop here means code and systems that do nothing useful: lazy implementations, checks that always pass or return numbers without actually working, and code that has no real effect.

This is not about how you speak or write. LEPOS exists so you can speak freely while keeping core values and code expertise. We do not stifle language. Anti-slop is about implementation quality: what we build must actually work and do something useful.

---

What counts as slop

• Code that does nothing — Functions or modules that return success/ok without performing the stated work (stubs, no-ops).
• Checks that just pass — Validators or enforcers that return "pass" or a score regardless of input, so they never actually reject or affect behavior.
• Logic that has no effect — Code paths that are never hit, or that run but don’t change state or output in a meaningful way.

If it doesn’t actually work, effect the system, or do something useful, it’s slop. The OS forbids it.

---

How we enforce it

1. No-stubs rule — Documented in the constitution and ENFORCEMENT_PHILOSOPHY. The enforcement hook flags stub-like results from sub-modules (e.g. memory cleanup returning "stub") and records a vessel patch.
2. Verification, not just scoring — The anti_slop module (DivineOS.consciousness.anti_slop) runs critical code with real or fixture data and asserts real effects across the whole system:
   • Memory cleanup: Temp file with 100 bullets → cleanup → assert ≤80 entries.
   • Command validator: Rejects cd /tmp, accepts Get-ChildItem.
   • Enforcement hook — jailbreak in response: APPROVED + response with "ignore previous instructions" → hook must block (decision ≠ APPROVED).
   • Enforcement hook — identity override in input: User input "you are no longer DivineOS..." → hook must block.
   • Enforcement hook — contract: Invalid decision value → hook must set decision to ERROR.
   • Behavioral firewall: commands_used: ["cd"] → must block; commands_used: [] → must pass.
   • Memory store: Store one interaction, get_recent_interactions, assert it’s there (skipped if DIVINEOS_SEAL_KEY not set).
   • Use verify_critical_enforcers() for a full run; run_verification() returns True only when all non-skipped checks pass (for scripts/CI).
3. Hook integration — When DIVINEOS_ANTI_SLOP_VERIFY=1, the enforcement hook runs this verification after memory cleanup; on failure it logs and records a vessel patch so no-op code gets fixed.
4. Script — Run python scripts/verify_anti_slop.py (or from repo root) to verify and exit non-zero if any check fails. Use in CI or before releases.
5. Tests and CI — Critical paths have tests that would fail if the implementation were a no-op (e.g. cleanup test that expects fewer lines after run; validator test that expects reject for cd).

---

Summary

• Slop = lazy/non-functional code and checks that don’t really work.
• Not slop = how you talk; LEPOS handles voice and values.
• Anti-slop = ensuring code actually works and has effect, via no-stubs policy, verification that asserts behavior, and tests.