Agent Guardrails

Code Quality Standards

1. Strict Clippy & Format Checks:
   • Before finishing ANY task involving Rust code changes, you MUST run:
     • cargo fmt --all -- --check
     • cargo clippy --workspace
   • You are NOT ALLOWED to ignore these errors or bypass them.
   • If cargo fmt fails, apply the changes with cargo fmt --all.
   • IMPORTANT: Follow the /rust-clean-code workflow for coding patterns that prevent warnings.
2. Writing Clean Rust Code (See /rust-clean-code for full details):
   • Struct Initialization: Use ..Default::default() or constructors instead of verbose literals
   • Async: Only mark functions async when they contain .await (except Axum handlers)
   • Error Handling: Use ? operator, anyhow::Result, avoid unwrap() in production
   • Casts: Explicit casts like x as i32 are allowed and preferred for clarity
   • SQL: Use raw strings r"..." or r#"..."# for SQL queries
3. Regression History (Learn from past mistakes):
   • Regression: mut keyword in loh-game match arms.
     • Root Cause: Agent did not run cargo clippy on modified files.
     • Fix: Removed mut keyword; fixed match arms.
   • Regression: missing fields (E0063) in struct literals in tests.
     • Root Cause: Tests used verbose struct literals that broke when new fields were added.
     • Fix: Use ..Default::default() or constructors. See /rust-clean-code workflow.
4. No Unjustified #[allow]:
   • Do not add #[allow(...)] directives unless absolutely necessary.
   • If you must use #[allow], add a comment explaining WHY it is safe to ignore.
5. Test Verification:
   • Always run tests related to your changes (cargo test -p <crate>).
   • Ensure tests compile and pass before declaring a task complete.

Workflow Enforcements

• Turbo Mode: Some workflows allow auto-running commands. Use judgement but generally prefer efficiency.
• Task Boundaries: Use task_boundary to structure your work and keep the user informed.

World Building Guidelines

1. NO OSRS/RS3 References:
   • You are STRICTLY PROHIBITED from using location names, NPC names, or lore specific to Old School RuneScape (OSRS) or RuneScape 3 (RS3).
   • Examples of BANNED names: Varrock, Falador, Lumbridge, Al Kharid, Zanaris, Edgeville, Karamja, Draynor, Gnome Stronghold.
   • Use original, generic, or Vedic-themed names (e.g., "Capital City", "Forest Hub", "Hastinapur", "Dandaka Forest").

Data Engineering Guardrails

1. Naming Conventions:
   • IDs must be snake_case.
   • No spaces or special characters in IDs.
2. No OSRS/RS3 Content:
   • Do not use names like "Mithril", "Adamant", "Rune" in id, name, description, or note_id.
   • Use Vedic equivalents: "Soma", "Meteoric", "Divya".
3. JSON Validity:
   • Ensure the data column in CSVs contains valid JSON.
   • Use checksum tools if available to verify integrity.

Knowledge Base Standards

1. Frontmatter Required:
   • ALL KB markdown files must have YAML frontmatter with last_updated and status fields.
   • When editing any KB file, you MUST update last_updated to the current date.
2. Status Management:
   • active - Current, authoritative documentation.
   • superseded - Replaced by a newer document (must link to replacement).
   • deprecated - No longer relevant, pending removal.
3. Directory Structure:
   • Follow existing conventions. See /maintain-knowledge-base workflow for placement rules.
   • Do not create orphaned docs outside the established hierarchy.
4. MCP Integration:
   • Use MCP tools (search_kb, read_kb_file) to discover existing docs before creating new ones.
   • Avoid duplicating information already in the KB.