windyboyandClaude Sonnet 4.5
9f6e62676e
Resolved 48 identified issues across 5 remediation batches: Critical Fixes (2/2 = 100%): - Removed duplicate "System Architec" directory with 4 archived files - Fixed broken PARA Notes wikilinks in 2 Outline.md files High Priority (14/15 = 93%): - Consolidated 10+ duplicate file pairs to canonical locations - Added frontmatter to 30 files in 200-area (now 100% coverage) - Relocated orphaned image with updated reference - Removed security-sensitive file duplicates Medium Priority (32/41 = 78%): - Deleted 4 empty files (0-15 bytes each) - Relocated misplaced files to proper PARA categories - Improved archive organization structure File Changes: - Modified: 33 files (frontmatter + wikilink fixes) - Moved: 16 files (to archive or new locations) - Deleted: 6 files (duplicates after archival) - Created: 25 files (archived copies + documentation) Vault Health Improvement: - Frontmatter coverage: 43% → 75% - Broken wikilinks: 2 → 0 - Duplicate files: 10+ → 0 - Empty files: 4 → 0 - Overall health score: 6.5/10 → 8.5/10 Documentation: - Created comprehensive remediation plan and batch reports in copilot/ - All changes tracked with detailed change reports - No data loss - duplicates archived, not deleted 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
124 lines
3.8 KiB
Markdown
124 lines
3.8 KiB
Markdown
.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.
|
|
|
|
|
|
``` |