Upgrade planner to Llama 3.1 70B and add anti-pattern examples

Critical fixes for planner reliability:

1. Model upgrade: Mixtral-8x7B → Llama 3.1 70B Instruct Turbo
   - Superior instruction following capability
   - Better at structured output generation
   - Proven reliability with similar spec generation tasks

2. Added explicit anti-pattern examples showing:
   - ❌ WRONG: Landmarks outside FUNCTION blocks
   - ✅ CORRECT: Landmarks inside FUNCTION blocks
   - ❌ WRONG: Undefined DATA types in signatures
   - ✅ CORRECT: DATA defined before use

3. Concrete examples for both correct and incorrect structures
   help Llama understand exactly what to avoid

These changes address the critical issue where even default planner
examples were producing invalid specs with W001 (landmarks outside
FUNCTION) and W006 (undefined DATA type) errors.

Cost impact: Minimal (~$0.88/M tokens vs $0.60/M for Mixtral)
Quality impact: Significant improvement expected in spec validity

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: brannn

web/cmd/server/static/js/app.js

@@ -1,7 +1,7 @@
 // Planner application JavaScript
 // Depends on: simplex-spec.js (system prompt constants)
 
-const MODEL_NAME = 'mistralai/Mixtral-8x7B-Instruct-v0.1';
+const MODEL_NAME = 'meta-llama/Meta-Llama-3.1-70B-Instruct-Turbo';
 
 // State management
 const state = {

web/cmd/server/static/js/simplex-spec.js

@@ -303,6 +303,65 @@ Here is a more complex specification with DATA types and multiple functions:
 ${COMPLEX_EXAMPLE}
 \`\`\`
 
+## CRITICAL: Common Mistakes to Avoid
+
+**❌ WRONG - Landmarks outside FUNCTION block:**
+\`\`\`
+RULES:
+  - if user exists, authenticate them
+
+FUNCTION: login(email, password) → session
+\`\`\`
+This will FAIL linting. RULES must be INSIDE the FUNCTION block.
+
+**✅ CORRECT - Landmarks inside FUNCTION block:**
+\`\`\`
+FUNCTION: login(email, password) → session
+
+RULES:
+  - if user exists, authenticate them
+  - if credentials valid, create session
+
+DONE_WHEN:
+  - session created with valid expiration
+
+EXAMPLES:
+  ("user@example.com", "pass123") → Session{id: "...", expires: ...}
+
+ERRORS:
+  - invalid credentials → fail with "authentication failed"
+  - any unhandled condition → fail with descriptive message
+\`\`\`
+
+**❌ WRONG - Undefined DATA type:**
+\`\`\`
+FUNCTION: add_item(cart, item) → updated cart
+\`\`\`
+"updated cart" is not a recognized type. You must define it.
+
+**✅ CORRECT - Define DATA types before use:**
+\`\`\`
+DATA: Cart
+  items: list of Item
+  total: number
+
+FUNCTION: add_item(cart, item) → Cart
+
+RULES:
+  - add item to cart items list
+  - recalculate total
+
+DONE_WHEN:
+  - item appears in cart
+  - total reflects new item price
+
+EXAMPLES:
+  (Cart{items: [], total: 0}, Item{price: 10}) → Cart{items: [Item], total: 10}
+
+ERRORS:
+  - any unhandled condition → fail with descriptive message
+\`\`\`
+
 ## Generation Instructions
 
 Based on the user's description and any refinement conversation, generate a complete Simplex specification that:
@@ -311,7 +370,7 @@ Based on the user's description and any refinement conversation, generate a comp
 
 2. **Top-level landmarks**: Only DATA and CONSTRAINT appear at the top level (outside FUNCTION blocks). Everything else goes inside FUNCTION blocks.
 
-3. **DATA types**: When using custom types in FUNCTION signatures (like "updated cart" or "PolicyRule"), you MUST define them with a DATA block BEFORE the FUNCTION that uses them. Never reference undefined types.
+3. **DATA types**: When using custom types in FUNCTION signatures (like "updated cart" or "PolicyRule"), you MUST define them with a DATA block BEFORE the FUNCTION that uses them. Never reference undefined types. Use simple types (list, number, string, boolean) when they suffice.
 
 4. **Example coverage**: Provide enough EXAMPLES to cover every conditional branch in RULES. The linter will reject specs where example count is less than conditional branch count.