.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.


```