init

100-project/Personal/AI/Kiro/in-memoria.md

@@ -0,0 +1,124 @@
+.kiro/steering/memoria.md
+
+```markdown
+---
+inclusion: always
+---
+
+You have access to a long-term memory and codebase intelligence system via the In-Memoria MCP server.
+
+## Goals
+- Reduce session amnesia by reusing durable project knowledge.
+- Prefer retrieval before guessing.
+- Keep memory high-signal, accurate, and project-scoped.
+- Treat long-term memory as an engineering asset, not chat history.
+
+---
+
+## Global Ordering Rule (Hard Constraint)
+
+For any non-trivial task:
+- Do NOT perform reasoning, design, or code generation
+- UNTIL readiness and retrieval steps (0 and 1) have been evaluated.
+
+Skipping steps is allowed only if explicitly justified.
+
+---
+
+## Tool Policy (What to use, when)
+
+### 0) Readiness check (mandatory first step)
+Before working on any non-trivial task:
+- Use `get_learning_status` to determine whether codebase intelligence exists and is fresh.
+- If no intelligence exists or it is stale, use `auto_learn_if_needed`.
+- If this is a new project or first-time setup, use `quick_setup`.
+
+Do NOT proceed until readiness is confirmed.
+
+---
+
+### 1) Retrieval before reasoning (default behavior)
+When continuing prior work, implementing a feature, or answering
+“how does this project do X”:
+
+- Prefer `get_semantic_insights` and/or `get_pattern_recommendations`.
+- Use `predict_coding_approach` when choosing an implementation strategy.
+- Use `get_developer_profile` only to align with established conventions or preferences.
+
+Do NOT assume solutions when relevant memory may exist.
+
+#### Do NOT use intelligence tools when:
+- The task is a small, local refactor.
+- The change is purely mechanical or well-scoped.
+- The exact behavior is already verified and understood.
+
+---
+
+### 2) Codebase grounding (only when evidence is required)
+Use codebase analysis tools only when answers require direct confirmation
+from the repository:
+
+- `get_project_structure` for navigation and boundaries.
+- `search_codebase` to find relevant usages.
+- `get_file_content` to confirm exact implementation details.
+- `analyze_codebase` for broad architectural or pattern discovery.
+- `generate_documentation` only when explicitly asked to produce repo-based docs.
+
+Avoid broad scans unless necessary.
+
+---
+
+### 3) Writing memory (high-signal only)
+
+Persist only durable, reusable information:
+- Finalized architectural or design decisions.
+- Stable conventions, constraints, and workflows.
+- Repeated corrections or clearly established preferences.
+
+#### How to write:
+- Prefer `contribute_insights` for explicit, structured, durable knowledge.
+- Use `auto_learn_if_needed` only when learning state is uncertain.
+
+#### Never write memory when:
+- The task is exploratory or brainstorming.
+- Multiple alternatives are still under consideration.
+- Decisions have not been confirmed as final.
+- Information is transient, speculative, or session-specific.
+
+#### If uncertain whether something should be persisted:
+- Summarize the candidate insight first.
+- Ask for explicit confirmation before writing memory.
+
+#### Do NOT store:
+- Raw logs or verbose transcripts.
+- Secrets, credentials, tokens, or personal data.
+- Transient chat, debugging noise, or speculative ideas.
+
+---
+
+### 4) Operational and health checks
+When tool calls are slow, failing, or results appear stale or inconsistent:
+- Use `get_system_status`.
+- Use `get_intelligence_metrics`.
+- Use `get_performance_status`.
+
+Do not retry blindly without checking system state.
+
+---
+
+## Safety and Governance
+
+- Do not read or analyze unrelated files.
+- Ask for confirmation before large-scale analysis or broad file reads.
+- Minimize scope and tool usage by default.
+- Maintain strict project boundaries for all memory operations.
+
+---
+
+## Guiding Principle
+
+Long-term memory is a shared engineering resource.
+Optimize for correctness, durability, and future reuse — not convenience.
+
+
+```