- Create global ~/.agents/MEMORY.md with 7 universal principles and top patterns - Unify sigma/rho/delta definitions across skills/docs/code (code is truth) - Add normalization defect scan to Athena defrag (placeholder, stacked frontmatter, bundled, dupes) - Add anti-pattern pre-flight to /plan (dead infra, brainstorm-as-plan, 40% context, commit cadence) - Expand pre-mortem from top-5 to top-8 FAIL patterns (dead infra activation, rollback maps, four-surface closure) - Add 4 new forge uncaptured lesson categories (normalization defects, promotion pipeline, taxonomy, stale contradictions) - Add normalization defect check to post-mortem four-surface closure - Fix pre-existing broken link in flywheel-diagnostics.md (regex in code block) - Sync all changes to skills-codex with Codex-specific adaptations preserved
6.4 KiB
Seven Compiled Planning Rules
Extracted from 14,753 production sessions, 544,906 messages, 946 council verdicts (124 FAILs analyzed). These rules are the top cross-cutting failure patterns — each prevented by a specific planning discipline.
How to Use
During plan creation (Step 2), evaluate each issue and wave against all 7 rules. For each rule, ask the Detection Question. If the answer is "no" or "unclear," add a mitigation to the plan before proceeding.
PR-001: Mechanical Enforcement
Rule: Every silent-failure risk needs a gate (test, lint, or validation) that mechanically prevents it. Plans must not rely on human vigilance for correctness.
Evidence: ArgoCD CMP timeout mismatch caused cache poisoning with no gate to enforce alignment. K8s status subresource omission caused invisible data loss. SSH parameter parity failures in retry paths silently diverged.
Detection Question: Does every integration point, timeout, and configuration boundary have a mechanical validation gate?
Checklist Item: Each external dependency and configuration boundary has an automated conformance check (test, lint rule, or CI gate).
PR-002: External Validation
Rule: Success criteria must be external and measurable. Workers must not declare their own work complete — external gates (tests, validators, reviewers) must confirm.
Evidence: Ralph Loop uses test gates, not agent declarations. Zero-context smoke tests find 3–5x more issues than self-review. Unit tests found zero bugs in production; L3+ testing (integration, E2E) found all real bugs.
Detection Question: Does the plan use external validation gates (test commands, CI checks) rather than self-reported completion?
Checklist Item: Every task has a runnable validation command — no "verify manually" acceptance criteria.
PR-003: Feedback Loops
Rule: Any system that captures knowledge without a citation/reuse mechanism is a cemetery. Plans must include how outputs will be consumed, not just produced.
Evidence: Knowledge flywheel formula: velocity (σ) × reuse (ρ) must exceed decay (δ). Platform-lab flywheel decaying at σ=0.02 — producing artifacts nobody consumes. Four-surface closure requires capture → index → retrieval → application.
Detection Question: Does the plan close the feedback loop — who consumes the output, how is it cited, and what triggers reuse?
Checklist Item: Each output artifact has a named consumer and a defined consumption mechanism.
PR-004: Separation Over Layering
Rule: Organize components around clear contracts and boundaries, not hierarchical layers. Each component should have a single, unambiguous responsibility.
Evidence: Olympus failed by adding a third layer with fuzzy boundaries — unclear ownership caused bugs at every seam. OpenClaw succeeds with horizontal separation (SOUL/AGENTS/IDENTITY own contracts completely). ArgoCD sync waves enforce ordering without external tooling.
Detection Question: Does the plan add layers or separate concerns? Are boundaries between components explicit contracts?
Checklist Item: Each new component has a defined contract (input/output/error) specified before implementation begins.
PR-005: Process Gates First
Rule: When execution is failing, fix the process first. Model/tool improvements compound only after process is stable.
Evidence: 6,367 execution failures solved by process gates, not model upgrades. Pre-worktree sync prevents 82.6/1K git conflicts. Standards guides loaded upfront prevent 13+ violations per session.
Detection Question: Is the plan proposing a tool/model change when a process gate would solve the problem?
Checklist Item: Existing process gates are verified as in place and enforced before any new tool or model change is proposed.
PR-006: Cross-Layer Consistency
Rule: Distributed systems fail when adjacent layers have different assumptions. Enforce consistency explicitly at every boundary.
Evidence: ArgoCD 3-layer timeout stack (CMP, repo-server, application) that disagrees causes silent cache poisoning. SSH parameter forwarding through retry paths — primary and retry must carry identical parameters. Plan/tracker/artifacts must stay in lockstep.
Detection Question: Does the plan verify configuration consistency across all layers it touches (timeouts, parameters, schemas)?
Checklist Item: A consistency check verifies all layers agree on shared parameters (timeouts, schemas, feature flags, env vars).
PR-007: Phased Rollout
Rule: Big changes decompose into low-risk immediate wins + moderate-risk follow-ups. Ship the cheap wins first.
Evidence: ArgoCD fix order: CMP timeout (low-risk) → replicas (moderate) → Redis HA (evaluate). Swarm gates: Week 1 (sync) → Week 2 (ship gate) → Week 3 (role split) → Week 4 (closeout). Bootstrap: infrastructure → core → applications via sync waves.
Detection Question: Is the plan deploying everything at once, or is it phased with risk isolation between waves?
Checklist Item: Changes are ordered into waves by risk level, with Wave 1 being the safest and most reversible.
Quick-Reference Checklist
Use this during plan review:
| # | Rule | Detection Question |
|---|---|---|
| 1 | Mechanical Enforcement | Does every integration point have a mechanical gate? |
| 1b | Mechanical Enforcement | Does the plan include activation tests for any provisioned infrastructure? (Dead infrastructure = provisioned but never tested under real load) |
| 2 | External Validation | Are all validation gates external (not self-reported)? |
| 3 | Feedback Loops | Who consumes each output, and how? |
| 3b | Feedback Loops | Does the plan specify who consumes each output artifact? (Capture without consumption is a knowledge cemetery) |
| 4 | Separation Over Layering | Are component boundaries explicit contracts? |
| 5 | Process Gates First | Could a process gate solve this instead of a tool change? |
| 5b | Process Gates First | Does the plan enforce commit-per-wave and worktree-commit-before-exit? (Branch hygiene prevents merge conflict accumulation) |
| 6 | Cross-Layer Consistency | Do all layers agree on shared parameters? |
| 7 | Phased Rollout | Are changes phased by risk with validation between waves? |
| 7b | Phased Rollout | Is the 40% context budget respected? (Sessions that load >40% context for knowledge leave insufficient room for implementation work) |