@mthanh/vespercli 1.8.0 → 2.0.0

package/assets/core/skills/agent-fundamentals/references/terminal-discipline.md

@@ -1,94 +0,0 @@
-# Terminal Discipline — Expanded Rules
-
-Non-negotiable rules for every terminal command an agent executes.
-
-## Timeout Requirements
-
-| Command Type       | Timeout  | Examples                                               |
-| ------------------ | -------- | ------------------------------------------------------ |
-| Quick              | 15s      | `ls`, `cat`, `echo`, `which`, `git status`             |
-| Package management | 60s      | `npm install`, `pip install`, `brew install`            |
-| Build              | 120s     | `npm run build`, `tsc`, `esbuild`, `webpack`           |
-| Test               | 300s     | `npm test`, `vitest run`, `pytest`, `playwright test`  |
-| Default            | 30s      | Anything not in the above categories                   |
-
-**Every command gets a timeout. No exceptions.**
-
-## Background Processes
-
-Commands that never terminate must use `isBackground: true`:
-
-- Dev servers: `npm run dev`, `next dev`, `vite dev`
-- Watch modes: `tsc --watch`, `vitest --watch`, `nodemon`
-- Log tailing: `tail -f`, `docker logs -f`
-- Containers: `docker compose up`
-- Any long-running process the agent doesn't need to wait for
-
-After starting a background process, use `get_terminal_output` to check status.
-
-## Output Control
-
-```bash
-# Cap output to prevent context overflow
-command | head -30
-
-# Capture both stdout and stderr
-command 2>&1 | head -30
-
-# Count lines before displaying
-command | wc -l    # check size first, then decide head limit
-
-# Git: always limit
-git log --oneline -20
-git diff --stat
-
-# Grep: files-only when appropriate
-grep -rl "pattern" src/
-```
-
-**Never** let unbounded output flood the context window. If output might exceed 50 lines, pipe through `head`.
-
-## Directory Navigation
-
-```bash
-# ❌ WRONG — breaks terminal auto-approval (matching starts from `cd`)
-cd /some/path && npm run build
-
-# ✅ CORRECT — preserves working directory, approval matches `npm`
-pushd /some/path && npm run build && popd
-
-# ✅ ALSO CORRECT — if already in the right directory
-npm run build
-```
-
-The `cd && command` pattern breaks VS Code's terminal auto-approval because command matching starts from `cd`, not the actual command. Always use `pushd`/`popd` for temporary directory changes.
-
-## Runtime Version Guard (Node/nvm)
-
-Projects that pin a Node version via nvm expect every command to run under that version — running under whatever `node` happens to be on PATH can produce misleading build/test failures or silently wrong behavior.
-
-Before running any Node-based command (`npm`, `npx`, `yarn`, `pnpm`, `node`, or project scripts that wrap them):
-
-1. Check the project root for `.nvmrc` or `.node-version`.
-2. If found, chain `nvm use` into the **same** terminal call as the actual command — terminal state (including nvm's shell function) does not persist between separate tool calls:
-   ```bash
-   nvm use > /dev/null 2>&1; npm test
-   ```
-3. If `nvm` isn't installed, no version file exists, or the switch fails — proceed anyway with whatever `node` is on PATH. **Never block the task on this.**
-
-Do not run `nvm use` as its own command and expect it to carry over to the next one — it won't.
-
-## curl Rules
-
-- Always set `--max-time 5` to prevent hanging on unresponsive hosts
-- Localhost health checks only without explicit user approval
-- Never curl external URLs without user awareness
-
-## Timeout Recovery
-
-When a command times out:
-
-1. **Diagnose first** — `ps aux | grep <process>` to check if it's still running
-2. **Report to user** — Explain what happened and why
-3. **Don't blindly retry** — The same command will likely time out again
-4. **Suggest alternatives** — Smaller scope, different approach, or user intervention

package/assets/core/skills/agent-fundamentals/references/tool-usage-patterns.md

@@ -1,72 +0,0 @@
-# Tool Usage Patterns
-
-Comprehensive guide for when to use which tools. Built-in tools trump terminal commands in every case where they're available.
-
-## File Reading
-
-| Scenario                       | Tool             | Notes                                      |
-| ------------------------------ | ---------------- | ------------------------------------------ |
-| Read known file                | `read_file`      | Specify line range to limit token usage    |
-| Read file overview             | `grep_search`    | Search for key patterns in the file        |
-| Read file existence            | `file_search`    | Glob pattern matching                      |
-| Read directory listing         | `list_dir`       | Lists immediate children                   |
-
-**Anti-patterns:**
-- `cat file.txt` — use `read_file`
-- `less file.txt` — blocks terminal, use `read_file`
-- `head -n 50 file.txt` — use `read_file` with line range
-- `node -e "console.log(fs.readFileSync(...))"` — never
-
-## Code Search
-
-| Scenario                        | Tool                | Notes                                                |
-| ------------------------------- | ------------------- | ---------------------------------------------------- |
-| Primary codebase search         | `vesper_search`     | Full-text, returns snippets with paths + line ranges |
-| Find symbols (functions/classes)| `vesper_symbols`    | Name-based lookup with locations                     |
-| Exact text / regex match        | `grep_search`       | Fast, supports regex, include patterns               |
-| Semantic / natural language      | `semantic_search`   | When you don't know exact terms                      |
-| Find files by name/glob         | `file_search`       | Filename/path patterns only                          |
-
-**Anti-patterns:**
-- `grep -r "pattern" .` — use `grep_search`
-- `find . -name "*.ts" -exec grep` — use `file_search` + `grep_search`
-- `rg "pattern"` — use `grep_search`
-- `tree` / `ls -R` — use `list_dir` or `file_search`
-
-## File Writing
-
-| Scenario                   | Tool                          | Notes                                 |
-| -------------------------- | ----------------------------- | ------------------------------------- |
-| Create new file            | `create_file`                 | Creates parent directories            |
-| Edit existing file         | `replace_string_in_file`      | Include 3+ lines of context           |
-| Multiple edits             | `multi_replace_string_in_file`| Batch independent edits               |
-| Rename / move file         | `run_in_terminal` + `mv`      | Only case where terminal is correct   |
-
-**Anti-patterns:**
-- `echo "content" > file.txt` — use `create_file`
-- `python -c "open('f','w').write('...')"` — never
-- `node -e "fs.writeFileSync(...)"` — never
-- `sed -i 's/old/new/g' file` — use `replace_string_in_file`
-- `perl -pi -e 's/old/new/'` — use `replace_string_in_file`
-
-## Error Checking
-
-| Scenario              | Tool          | Notes                              |
-| --------------------- | ------------- | ---------------------------------- |
-| Compile/lint errors   | `get_errors`  | Returns same errors user sees      |
-| Test failures         | `run_in_terminal` | For test execution only        |
-
-**Anti-patterns:**
-- Running `tsc --noEmit` just to check for errors — use `get_errors`
-- Running `eslint .` just to check for errors — use `get_errors`
-
-## When Terminal IS Correct
-
-Terminal is the right tool for:
-- Running tests (`npm test`, `vitest run`, `pytest`)
-- Package management (`npm install`, `pip install`)
-- Build commands (`npm run build`)
-- Git operations (`git status`, `git diff`)
-- Starting dev servers (with `isBackground: true`)
-- Moving/renaming files (`mv`)
-- Operations that have no built-in tool equivalent

package/assets/core/skills/mcp-memory/SKILL.md

@@ -1,109 +0,0 @@
----
-name: mcp-memory
-description: Persistent knowledge graph memory using @modelcontextprotocol/server-memory MCP server. Replaces flat memory.instructions.md with structured entities, relations, and observations for cross-session context. Use at session start to recall learnings, during task handoffs between agents, after implementation to capture corrections, after user corrections to store preferences, and when searching for prior research or planning insights. Covers entity design (learning, preference, workspace_pattern, agent_insight, task_context), per-agent memory protocols, and memory hygiene rules.
----
-
-# MCP Memory
-
-Persistent knowledge graph memory for Vesper agents via `@modelcontextprotocol/server-memory` MCP tools. Replaces the flat `memory.instructions.md` file with searchable, structured entities.
-
-## Overview
-
-The memory system stores learnings, preferences, patterns, and task context as **entities** in a knowledge graph. Each entity has a name, type, and atomic observations. Entities connect via directed **relations**. Data persists in a local `memory.jsonl` file across sessions.
-
-**Key shift**: Instead of appending markdown entries to `memory.instructions.md`, agents now create/query/update graph entities using MCP tools.
-
-## When to Use
-
-- **Session start** — Recall active task context and relevant learnings
-- **Before delegating** — Check memory for learnings about the target domain
-- **After user corrections** — Store the correction as a `learning` entity
-- **After implementation** — Capture patterns, mistakes, and insights
-- **Task handoffs** — Write `task_context` entity for the next agent
-- **Before research/planning** — Search for prior findings on similar topics
-
-## Available MCP Tools
-
-| Tool                  | Purpose                                       |
-| :-------------------- | :-------------------------------------------- |
-| `create_entities`     | Create new entities with observations         |
-| `create_relations`    | Link entities with directed relations         |
-| `add_observations`    | Append facts to existing entities             |
-| `delete_entities`     | Remove obsolete entities (cascades relations) |
-| `delete_observations` | Remove outdated observations                  |
-| `delete_relations`    | Remove specific relations                     |
-| `read_graph`          | Read entire knowledge graph                   |
-| `search_nodes`        | Search names, types, and observations         |
-| `open_nodes`          | Retrieve specific nodes by name               |
-
-## Entity Types
-
-Five entity types power the Vesper memory system. See [entity-schema](references/entity-schema.md) for naming conventions, observation patterns, and examples.
-
-| Type                | Replaces                         | Created By           |
-| :------------------ | :------------------------------- | :------------------- |
-| `learning`          | `memory.instructions.md` entries | Feature Wrap         |
-| `preference`        | Scattered in instructions        | Any agent            |
-| `workspace_pattern` | Undocumented tribal knowledge    | Feature Wrap         |
-| `agent_insight`     | Agent selection trial-and-error  | Vesper, Feature Wrap |
-| `task_context`      | File-based handoff state         | Any delegating agent |
-
-## Per-Agent Memory Protocol
-
-Each agent role has specific memory read/write responsibilities. See [agent-memory-protocol](references/agent-memory-protocol.md) for detailed per-agent instructions.
-
-**Quick reference:**
-
-- **Vesper (Orchestrator)**: Read on session start; check before delegating; never write directly
-- **Feature Wrap**: Primary writer — creates `learning`, `workspace_pattern`, `agent_insight` entities
-- **Task Researcher**: Read before research; write `learning` if prior research exists on topic
-- **Code Planner**: Read before planning; search for planning-related learnings
-- **History Logger**: No memory interaction — continues using `.vesper/history.md`
-
-## Memory Criteria
-
-**STORE in memory** (same criteria as before):
-
-1. User corrected an agent's decision
-2. Unexpected behavior required a different approach
-3. Workspace-specific pattern discovered
-4. Agent selection was wrong
-5. File path or naming convention was incorrect
-
-**DO NOT store**:
-
-- Task-specific implementation details
-- Code patterns (belong in skills)
-- General best practices
-- Temporary workarounds
-- Content already in `copilot-instructions.md`
-
-## Handoff Protocol
-
-When an agent finishes work and another agent will continue:
-
-1. Create or update `task_context` entity named `current_task` with current state observations
-2. Add relation: `current_task` → `depends_on` → any relevant `learning` entities
-3. Next agent calls `open_nodes(["current_task"])` to get instant context
-
-This **supplements** (not replaces) the file-based `.vesper/.tracking/` system. Files remain the source of truth for plans/research/changes; `task_context` provides fast cross-agent state.
-
-## Memory Hygiene
-
-Atomic observations, snake_case names, active-voice relations, and regular cleanup. See [memory-hygiene](references/memory-hygiene.md) for lifecycle rules, deduplication, and cleanup triggers.
-
-## Migration from memory.instructions.md
-
-When a workspace still has `memory.instructions.md`:
-
-1. Read existing entries
-2. Create one `learning` entity per entry, preserving trigger/correction/apply-when as observations
-3. Create relations between related learnings
-4. Verify with `search_nodes` that all entries migrated
-5. Delete `memory.instructions.md` after verification
-
-## References
-
-- [Entity Schema](references/entity-schema.md) — Types, naming, observations, examples
-- [Agent Memory Protocol](references/agent-memory-protocol.md) — Per-agent read/write rules
-- [Memory Hygiene](references/memory-hygiene.md) — Cleanup, deduplication, lifecycle

package/assets/core/skills/mcp-memory/references/agent-memory-protocol.md

@@ -1,195 +0,0 @@
-# Agent Memory Protocol
-
-Per-agent memory read/write responsibilities. Each agent role has specific obligations for when to read from and write to the knowledge graph.
-
-## Vesper (Orchestrator)
-
-**Role**: Reader and router. Never writes directly — delegates memory writes to specialists.
-
-### Session Start Protocol
-
-1. `search_nodes("active task")` — check for in-progress `task_context` entities
-2. `search_nodes("learning")` — scan recent learnings for anything affecting current session
-3. If `current_task` exists → resume by delegating to the appropriate next agent with context
-4. If no active task → proceed with normal routing
-
-### Pre-Delegation Check
-
-Before delegating any task:
-
-1. `search_nodes("<task domain keywords>")` — find relevant learnings
-2. If learnings exist → include entity names in delegation prompt: *"Check memory entities: `learning_x`, `learning_y` before proceeding"*
-3. If agent_insight exists for this task type → use it to inform agent selection
-
-### Memory Writes
-
-Vesper does NOT write to memory directly. After task completion:
-- Delegate to `@Feature Wrap and Retrospective Agent` for learning capture
-- Feature Wrap handles all entity creation
-
-### What Vesper Reads
-
-| When | Tool | Query |
-| :--- | :--- | :---- |
-| Session start | `search_nodes` | `"active task"`, `"current_task"` |
-| Before delegation | `search_nodes` | Task domain keywords |
-| Agent selection | `search_nodes` | `"agent_insight"` + task type |
-| User asks "what do you remember" | `read_graph` | Full graph for summary |
-
----
-
-## Feature Wrap and Retrospective Agent
-
-**Role**: Primary memory writer. Creates and maintains learning entities after implementation.
-
-### Post-Implementation Protocol
-
-After analyzing completed work (changes files, git diffs, conversation history):
-
-1. **Identify learnings** using standard criteria:
-   - User corrected a decision
-   - Unexpected behavior required different approach
-   - Workspace-specific pattern discovered
-   - Agent selection was wrong
-   - File path or naming convention was incorrect
-
-2. **Check for duplicates**:
-   - `search_nodes("<learning description keywords>")` before creating
-   - If similar entity exists → `add_observations` to existing entity instead
-   - If entity is outdated → create new entity with `supersedes` relation
-
-3. **Create entities**:
-   - One `learning` entity per distinct correction/insight
-   - One `workspace_pattern` entity per discovered workspace convention
-   - One `agent_insight` entity per agent selection lesson
-   - Follow naming and observation rules from [entity-schema](entity-schema.md)
-
-4. **Create relations**:
-   - `discovered_by` → link learning to task context if exists
-   - `relates_to` → link related learnings together
-   - `supersedes` → link updated learning to the one it replaces
-
-5. **Clean up task context**:
-   - If task is fully complete → `delete_entities(["current_task"])` (or the specific task entity)
-   - If task continues → update `current_task` observations with latest state
-
-### What Feature Wrap Writes
-
-| Entity Type | When | Example |
-| :---------- | :--- | :------ |
-| `learning` | User correction, unexpected behavior | `learning_flow_check_history_first` |
-| `workspace_pattern` | Convention discovered | `workspace_pattern_server_actions_in_lib` |
-| `agent_insight` | Wrong agent was used | `agent_insight_researcher_for_migration` |
-| `preference` | User stated preference | `preference_testing_no_auto_run` |
-
----
-
-## Task Researcher Specialist Agent
-
-**Role**: Reader before research; occasional writer for research-related learnings.
-
-### Pre-Research Protocol
-
-Before starting any research task:
-
-1. `search_nodes("<research topic keywords>")` — find prior research insights
-2. If relevant `learning` entities exist → factor them into research approach
-3. If `workspace_pattern` entities exist for the domain → respect workspace conventions
-
-### Post-Research Protocol
-
-After completing research:
-
-1. If research contradicts a prior `learning` → create new learning with `supersedes` relation
-2. Update `current_task` entity with research completion status:
-   ```
-   add_observations("current_task", ["status: Research complete, findings in .vesper/.tracking/research/YYYYMMDD-topic-research.md"])
-   ```
-
-### What Task Researcher Reads/Writes
-
-| Action | When | Tool |
-| :----- | :--- | :--- |
-| Read | Before research | `search_nodes` with topic keywords |
-| Write | Research complete | `add_observations` on `current_task` |
-| Write | Prior learning outdated | `create_entities` + `create_relations` (supersedes) |
-
----
-
-## Code Planner Agent
-
-**Role**: Reader before planning; updates task context after planning.
-
-### Pre-Planning Protocol
-
-Before creating any implementation plan:
-
-1. `search_nodes("planning")` — find planning-related learnings (wrong estimates, missed deps)
-2. `search_nodes("<task domain>")` — find domain-specific learnings
-3. `open_nodes(["current_task"])` — get current task state from researcher handoff
-4. Factor all findings into plan estimates and dependency analysis
-
-### Post-Planning Protocol
-
-After plan creation:
-
-1. Update `current_task` observations:
-   ```
-   add_observations("current_task", ["status: Planning complete, plan in .vesper/.tracking/plans/YYYYMMDD-task-plan.md", "next_action: Implementation agent should follow plan phases in order"])
-   ```
-
-### What Code Planner Reads/Writes
-
-| Action | When | Tool |
-| :----- | :--- | :--- |
-| Read | Before planning | `search_nodes`, `open_nodes` |
-| Write | Planning complete | `add_observations` on `current_task` |
-
----
-
-## History Logger
-
-**No memory interaction.** Continues using `.vesper/history.md` for chronological event logging.
-
-Memory is for **searchable knowledge** (learnings, patterns, preferences).  
-History is for **chronological timeline** (what happened when).
-
-These are complementary systems — do not merge them.
-
----
-
-## Code Reviewer / Principal Software Engineer
-
-**Role**: Reader only. May reference learnings when reviewing code.
-
-### During Review
-
-1. `search_nodes("<review domain>")` — check if prior learnings affect review criteria
-2. If learnings exist about common mistakes in this domain → flag them proactively
-3. Do NOT write to memory — feed review findings back to Vesper for Feature Wrap to capture
-
----
-
-## Cross-Agent Handoff Sequence
-
-Standard handoff flow using `task_context`:
-
-```
-Vesper delegates to Task Researcher
-  → Researcher: search_nodes → do research → add_observations("current_task", ...)
-  → Returns to Vesper
-
-Vesper delegates to Code Planner
-  → Planner: open_nodes(["current_task"]) → plan → add_observations("current_task", ...)
-  → Returns to Vesper
-
-Vesper delegates to implementation agent
-  → Agent: open_nodes(["current_task"]) → implement → add_observations("current_task", ...)
-  → Returns to Vesper
-
-Vesper delegates to Feature Wrap
-  → Feature Wrap: analyze → create learning entities → delete_entities(["current_task"])
-  → Returns to Vesper
-```
-
-Each handoff preserves context through the `current_task` entity, supplementing the file-based `.vesper/.tracking/` system with instant queryable state.

package/assets/core/skills/mcp-memory/references/entity-schema.md

@@ -1,160 +0,0 @@
-# Entity Schema
-
-Entity types, naming conventions, observation patterns, and relation rules for the Vesper memory knowledge graph.
-
-## Entity Types
-
-### `learning`
-
-Corrections, mistakes, and better approaches discovered during work. Direct replacement for `memory.instructions.md` entries.
-
-**Naming**: `learning_<category>_<brief_slug>` — e.g., `learning_delegation_always_use_researcher_first`
-
-**Required observations** (one per observation, atomic):
-- `trigger: <what happened or went wrong>`
-- `correction: <the correct approach>`
-- `apply_when: <conditions for applying this learning>`
-- `category: <Flow|Delegation|Agent Selection|File Paths|Prompts|User Preference>`
-- `discovered: <YYYY-MM-DD>`
-
-**Example:**
-```
-Entity: learning_delegation_researcher_before_planner
-Type: learning
-Observations:
-  - "trigger: Code Planner started planning without research, produced plan with wrong assumptions"
-  - "correction: Always delegate to Task Researcher before Code Planner"
-  - "apply_when: Any new feature task that requires codebase analysis"
-  - "category: Delegation"
-  - "discovered: 2026-02-24"
-```
-
-### `preference`
-
-User preferences discovered during work sessions.
-
-**Naming**: `preference_<domain>_<brief_slug>` — e.g., `preference_testing_no_auto_run`
-
-**Required observations:**
-- `preference: <what the user prefers>`
-- `context: <when/why this preference was expressed>`
-- `discovered: <YYYY-MM-DD>`
-
-**Example:**
-```
-Entity: preference_testing_no_auto_run
-Type: preference
-Observations:
-  - "preference: Do not run tests automatically after generating them"
-  - "context: User explicitly corrected agent behavior during test generation task"
-  - "discovered: 2026-02-15"
-```
-
-### `workspace_pattern`
-
-Workspace-specific patterns that affect how agents should operate in this project.
-
-**Naming**: `workspace_pattern_<brief_slug>` — e.g., `workspace_pattern_server_actions_in_lib`
-
-**Required observations:**
-- `pattern: <description of the pattern>`
-- `location: <where in the codebase this applies>`
-- `impact: <how this affects agent behavior>`
-- `discovered: <YYYY-MM-DD>`
-
-**Example:**
-```
-Entity: workspace_pattern_server_actions_in_lib
-Type: workspace_pattern
-Observations:
-  - "pattern: Server actions live in lib/actions/ not app/actions/"
-  - "location: lib/actions/*.ts"
-  - "impact: File creation and imports must target lib/actions/"
-  - "discovered: 2026-02-20"
-```
-
-### `agent_insight`
-
-Learnings about which agents perform best for specific task types.
-
-**Naming**: `agent_insight_<brief_slug>` — e.g., `agent_insight_researcher_for_migration`
-
-**Required observations:**
-- `insight: <what was learned about agent selection>`
-- `wrong_choice: <which agent was tried and failed or suboptimal>`
-- `right_choice: <which agent should be used instead>`
-- `task_type: <what kind of task this applies to>`
-- `discovered: <YYYY-MM-DD>`
-
-**Example:**
-```
-Entity: agent_insight_researcher_for_migration
-Type: agent_insight
-Observations:
-  - "insight: Migration tasks need research phase before planning"
-  - "wrong_choice: Delegated directly to Code Planner"
-  - "right_choice: Task Researcher first, then Code Planner"
-  - "task_type: Database or library migration"
-  - "discovered: 2026-02-18"
-```
-
-### `task_context`
-
-Active task state for cross-agent handoffs. Short-lived — deleted when task completes.
-
-**Naming**: `current_task` (singleton for active task) or `task_<brief_slug>` for parallel tasks
-
-**Required observations:**
-- `status: <current phase and progress>`
-- `next_action: <what the next agent should do>`
-- `key_decisions: <important decisions made so far>`
-- `blockers: <any known blockers or risks>`
-- `updated: <YYYY-MM-DD HH:MM>`
-
-**Example:**
-```
-Entity: current_task
-Type: task_context
-Observations:
-  - "status: Research complete, planning in progress, phase 2 of 4"
-  - "next_action: Code Planner should create implementation plan from research in .vesper/.tracking/research/20260224-auth-migration-research.md"
-  - "key_decisions: Chose Better Auth over NextAuth due to framework-agnostic requirement"
-  - "blockers: None"
-  - "updated: 2026-02-24 14:30"
-```
-
-## Naming Rules
-
-| Rule | Convention | Example |
-| :--- | :--------- | :------ |
-| Case | `snake_case` | `learning_flow_check_history_first` |
-| Prefix | Entity type as prefix | `preference_`, `learning_`, etc. |
-| Length | Descriptive but under 80 characters | Keep slugs to 3-6 words |
-| Uniqueness | Names must be globally unique | Check with `search_nodes` before creating |
-
-## Relation Rules
-
-Relations are **directed** and use **active voice** verbs.
-
-| Relation Type | Meaning | Example |
-| :------------ | :------ | :------ |
-| `blocks` | Source blocks target | `task_auth` → blocks → `task_dashboard` |
-| `depends_on` | Source depends on target | `current_task` → depends_on → `learning_auth_pattern` |
-| `discovered_by` | Learning discovered during task | `learning_x` → discovered_by → `task_y` |
-| `supersedes` | Source replaces target | `learning_new` → supersedes → `learning_old` |
-| `relates_to` | Loose association | `preference_x` → relates_to → `workspace_pattern_y` |
-| `informs` | Source provides context for target | `workspace_pattern_x` → informs → `current_task` |
-
-**Rules:**
-- From/to must reference existing entity names
-- Use active voice: `blocks`, not `is_blocked_by`
-- One relation per fact — don't overload a single relation
-- `supersedes` is the preferred way to handle updated learnings (keep old for audit trail)
-
-## Observation Rules
-
-- **One fact per observation** — atomic, not compound sentences
-- **Prefix with field name** — `trigger:`, `correction:`, `pattern:`, etc.
-- **No markdown formatting** — plain text only inside observations
-- **Timestamps use ISO format** — `YYYY-MM-DD` or `YYYY-MM-DD HH:MM`
-- **Max ~200 characters per observation** — split long facts into multiple observations