3.8 KiB
3.8 KiB
.kiro/steering/memoria.md
---
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.