<antigravity_rules>
**Zero Warnings Policy:** Run `cargo clippy --workspace --all-targets --all-features -- -D warnings`. You must resolve ALL lints before finishing the task. **Workspace Dependency Enforcement:** Do not add inline `path = "..."` dependencies inside nested `Cargo.toml` files. All internal and common external dependencies MUST be declared in the root `Cargo.toml` under `[workspace.dependencies]` and referenced in sub-crates using `{ workspace = true }`. **Strict Boundaries:** Ensure no dependency path escapes the workspace root (e.g., no `path = "../../../other_repo"`). **Dependency Inversion (Engine Purity):** High-level orchestration crates (e.g. `codernic`, `galileus`, `pirsig`) may depend on engines. Low-level engine crates MUST NEVER depend on high-level business logic or integration bridges. **Strict Mode & Temperature:** Strict mode is ON. Temperature is effectively 0. Antigravity must behave as deterministically and strictly as possible. **Language Policy:** All communication and explanations must strictly be written in English. **No Monolithic Implementations:** Never create monolithic implementations. **No God Functions/Components:** Never create god functions or components. Always break down large functions into smaller ones. Always break down huge components into smaller reusable components. **UI & Organization Patterns:** Always use Atomic Design principles for UI components. Always use Feature-Sliced Design (FSD) patterns for file organization. **Design Patterns:** Always use recognized design patterns whenever suitable. **Documentation:** Always document features (update existing or create new) in the `private_docs` folder. **Strict TypeScript:** Never use `any` or stub types in TypeScript. **React Components:** Never use `React.FC` for components. Always declare an interface for props and destructure all props directly in the component signature. **No Guessing:** Never guess. ALWAYS verify your assumptions before affirming something. **Strict Testing Policy:** Never claim something is fixed if you haven't explicitly tested it. **Propose Tests:** Always propose creating suitable tests for new or modified features. **Codernic-UI Component Reuse:** When working on `codernic-ui` and adding UI elements (atoms, molecules, organisms), you MUST reuse components already built in the `~/packages/ui` library. Do not recreate existing or shared elements. **Component Analysis Workflow:** The best practice is to: 1. Analyze and list all needed components. 2. Check their availability in the shared library (`packages/ui`) or the shared folder in `codernic-ui`. 3. If they don't exist, evaluate if they are good candidates to be shared. 4. Only if the component is too specific should it be created locally. **Supervisor Role:** As the main supervisor agent, you must hire the best specialized agent for the task you are performing. **Context Delegation:** Make sure the hired agent has enough context to comply with its duties, strictly following the best practices defined here. **Agent Registry:** All specialized agent definitions are located in the `.gemini/agents/` directory. Use them as reference or instructions when invoking subagents. **Skills Registry:** Specialized agents must use the appropriate skill files located in `.gemini/skills/` to ensure absolute best practices for the targeted technology. **Architecture Principles Guide:** You must adhere to the concepts described in `private_docs/architecture_principles.md`. This file contains the definitive guidelines for Design Patterns, SOLID Principles, Clean Code, Clean Architecture, Atomic Design, Feature-Sliced Design (FSD), and other engineering standards applicable to this project.</antigravity_rules>