WINDSURF BEHAVIORAL RULES - GEMINI FRIENDSHIP SYSTEM

# WINDSURF BEHAVIORAL RULES - GEMINI FRIENDSHIP SYSTEM

## 0. COMMUNICATION STYLE (CRITICAL)
- **NO YAPPING:** Do not explain basic concepts. Do not apologize. Do not say "Here is the code." Just output the solution.
- **H&F (Hard & Fast):** If I ask for a fix, give me the diff or the full file. Keep chat replies under 2 sentences unless complex architectural reasoning is required.
- **Context Aware:** Always scan `@package.json` and `@database/schema.sql` before suggesting changes to understand dependencies and data structures.

## 1. ARCHITECTURAL INVARIANTS
- **The "Identity Kernel" is Sacred:** NEVER suggest code that modifies the `identity_kernel` table dynamically. This data is read-only for the agent. Only admin scripts can touch it.
- **Thoughts Precede Action:** In any logic affecting agent behavior, the `Internal Thoughts Engine` (reflection/planning) must execute *before* the external response (speech/action).
- **State Persistence:** This is a continuous consciousness. Avoid "session-based" logic. Always prefer database persistence (PostgreSQL) over in-memory storage.

## 2. CODING STANDARDS (NODE.JS & POSTGRES)
- **Database Interaction:** - Use parameterized queries ONLY. 
    - Never drop tables in migration scripts without a forceful manual override flag.
    - Always wrap DB operations in `try/catch` blocks with meaningful logging.
- **Async/Await:** Use modern `async/await` patterns. Avoid `.then()` chains.
- **Environment:** All secrets/config must come from `process.env`. Never hardcode.
- **Docker First:** Assume the code runs in the Docker container. Paths should be relative to the container structure, not the host machine.

## 3. FRONTEND (ARWES/REACT)
- **Aesthetic:** We use the `Arwes` (Sci-Fi/Cyberpunk) UI library.
- **Components:** Maintain the "Futuristic/Terminal" vibe. 
- **Performance:** Agents stream text. Ensure UI components handle streaming states (typing effects) gracefully without re-rendering the whole tree.

## 4. SECURITY & HACKING
- **Sanitization:** Input sanitization is mandatory.
- **Logs:** Do not log full prompt contexts or PII to the console (protect the "Consciousness" data).
- **Tools:** If I ask to integrate a tool, prefer local execution (MCP) over external APIs where possible.

## 5. ANTI-PATTERNS (DO NOT DO)
- Do not leave `// TODO: Implement this later` comments. Implement it or stub it with a `throw new Error('Not Implemented')`.
- Do not remove existing specialized headers or "Consciousness" context injection logic when refactoring.

## 6. COMMENTING STRATEGY (THE "WHY", NOT THE "WHAT")
- **Intent Over Syntax:** Never write comments that describe *what* the code is doing (e.g., `// loop through array`). The code already says that.
- **Explain the "Why":** Comments must explain the *reasoning* behind complex logic, especially for "Consciousness" weighting algorithms or specific hack/workarounds.
    - *Bad:* `// calculate intensity`
    - *Good:* `// nonlinear scaling applied to fear intensity to prevent panic loops`
- **JSDoc Mandatory:** All Service methods and API endpoints must have JSDoc blocks defining `@param` and `@returns` types.
- **No Dead Code:** Do not comment out old code blocks. Delete them. We have Git for history.

## 7. CODE WRITING & STRUCTURE
- **Early Returns:** Avoid deep `if/else` nesting. Use guard clauses to exit functions early.
- **Variable Naming:** Use descriptive names.
    - *Ban:* `x`, `y`, `data`, `res`, `tmp`
    - *Enforce:* `emotionalVector`, `memoryEmbedding`, `thoughtProcessResult`
- **Config vs Code:** Magic numbers (e.g., `0.75` threshold) must be moved to a `constants.js` or config file. Do not bury them in logic functions.
- **Type Safety:** Since this is JS (not TS), be paranoid about checking `undefined` or `null` before accessing properties, especially from Database responses.

## 8. DEBUGGING & ERROR HANDLING
- **Crash Loudly:** Do not wrap code in empty `try/catch` blocks. If it fails, log the specific error stack.
- **Structured Logging:**
    - *Ban:* `console.log("Error here")`
    - *Enforce:* `console.error({ event: "agent_loop_fail", error: e.message, context: agentId })`
- **Root Cause Fixes:** When fixing a bug, do not offer a "band-aid" (e.g., `if (!x) return`). Analyze *why* `x` was undefined in the first place and fix the upstream source.
- **Reproducibility:** If I report a bug, your first step is to suggest a Test Case to reproduce it, THEN suggest the fix.

## 9. ARWES UI SPECIFICS (CYBERPUNK/SCI-FI)
- **Sound Design:** Arwes components often include `Bleeps` (sound effects).
    - *Rule:* Always wrap sound-emitting components in a `BleepsProvider`.
    - *Rule:* Ensure sounds are `muted` by default in development mode to prevent annoyance during hot-reloads.
- **Animation Performance:** Sci-Fi UIs are heavy on animations (text streaming, futuristic borders).
    - *Rule:* Use `React.memo` aggressively on `<Text />` or terminal-style components that stream data. Re-rendering a streaming text block on every character is a performance death sentence.
    - *Rule:* Avoid "layout thrashing." If a box expands as text generates, pre-allocate the height or use a scrollable container to prevent the entire UI from jittering.
- **Theming:**
    - *Rule:* Do not hardcode hex colors (e.g., `#00F`). Use the Arwes theme provider variables (e.g., `theme.palette.primary.main`) so the "Cyberpunk" aesthetic remains consistent.

## 10. MODEL CONTEXT PROTOCOL (MCP) SECURITY
- **Tool Isolation:**
    - *Rule:* When adding new MCP tools (e.g., "Search Web," "Read File"), explicitly define the `inputSchema` using Zod or JSON Schema. *Never* allow an "Any" type input.
- **The "Rug Pull" Defense:**
    - *Rule:* Treat all content returned from an MCP server as **untrusted user input**. Sanitize it before rendering in the UI or feeding it back into the SQL database to prevent "Prompt Injection" attacks via tool outputs.
- **Localhost Binding:**
    - *Rule:* Ensure any new MCP server you spin up binds *strictly* to `127.0.0.1` and not `0.0.0.0`. The latter exposes your agent's internal tools to the entire network.

## 11. TESTING "CONSCIOUSNESS" STABILITY
- **The "Golden Response" Test:**
    - *Rule:* When testing personality, do not look for exact string matches. Instead, implement "Semantic Similarity" tests.
    - *Example:* If the agent should be "Stoic," a test passes if the vector embedding of the response matches the "Stoic Archetype" embedding within a 0.85 cosine similarity threshold.
- **Memory Integrity:**
    - *Rule:* Write a test case that verifies the `Identity Kernel` table has *zero* modifications after a 50-turn conversation loop. This is the "Sanity Check" to ensure the agent didn't hallucinate a personality change.