chat-recall 0.6.9 → 0.7.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "chat-recall",
-  "version": "0.6.9",
+  "version": "0.7.0",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/munhq/chat-recall.git"

package/skills/chat-recall/SKILL.md

@@ -30,6 +30,7 @@ All tools are MCP tools on the `chat-recall` server, named
 read except these, which change stored memory or state — treat each as an edit
 and apply the test in `chat-recall-memory` before calling one:
 `recall_kg_add`, `recall_kg_invalidate`, `recall_decision_record`, `recall_decisions`,
+`recall_decision_scan` (only with `record: true`),
 `recall_diary_write`, `recall_set`, `recall_task_create`, `recall_task_update`,
 `recall_task_comment`,
 `recall_task_policy`,
@@ -88,7 +89,7 @@ CLAUDE.md rule is additive and reversible, so take it; ask first before setting
 **Findings, ranked** — `recall_claude_suggestions` (every finding that becomes an agent-instruction change — the CLAUDE.md rules and skill installs — merged across account scope and every indexed project) and `recall_improvements` (everything else, most urgent first; `create_tasks: true` opens one team task per item). They split the same engines, so an item never appears in both. Neither needs the codeindex binary: without it you still get the account-level half.
 **What changed** — `recall_edits_timeline` (cross-tool edits), `recall_diff` (per-session diffs), `recall_commits` (did it actually land), `recall_markers` (where a session went sideways).
 **Durable memory / KG** — `recall_kg_query` / `recall_kg_add` / `recall_kg_invalidate` / `recall_kg_timeline` / `recall_kg_stats`, `recall_decision_record`, `recall_diary_write` / `recall_diary_read`, `recall_set` / `recall_get`.
-**Decisions** — `recall_decisions` (what is already settled per area, cascade resolved; call it before choosing a library or a datastore).
+**Decisions** — `recall_decisions` (what is already settled per area, cascade resolved; call it before choosing a library or a datastore) and `recall_decision_scan` (what THIS repository's manifests say it uses, beside what the register answers — the register never reads a repo, so a project that never had the conversation inherits someone else's stack; `record: true` writes the areas the manifests answer, at project scope, citing the file and line).
 **Team** — `recall_tasks` (the shared task board), `recall_task_create`, `recall_task_update` (status, assignee, linked session; task ids look like `t_…`; when you start work on a task, set it `in_progress` and pass your session id as `linked_session_id` so the board can verify the work shipped), `recall_task_comment` (leave a progress note on a card), `recall_task_policy` (read or change WHAT the board files — severity floor, open-card ceiling, cards per run, categories, and the projects that never file at all via `exclude_project` — reach for that one when the user says "do not put work on my board for this repo", e.g. a client's codebase they keep separate; call it with no arguments to read, and reach for it when the user says "only security", "high and critical for now", or asks why a full board has stopped filing), `recall_team_activity` (per-teammate × per-project rollup), `recall_shares` (which projects are shared — private by default, nothing is visible to teammates until shared).
 **Toolkit sync across tools and devices** — `recall_toolkit_status` (which MCP servers, skills, commands and agents exist, on which tool, on which device — and which of them can be installed elsewhere at all), `recall_toolkit_sync` (queue an install: everything or one type, every device or one machine, or fan a machine's own artifacts across its own tools). Reach for these on "set up my other laptop", "get my MCPs everywhere", "why does this tool not have my skill".
 

package/skills/chat-recall-memory/SKILL.md

@@ -39,6 +39,21 @@ future sessions inherit them.
   Project overrides beat account-wide decisions. A personal preference is
   returned marked `advisory` and never overrides a team decision.
 
+- `mcp__chat-recall__recall_decision_scan` — what THIS repository's manifests
+  say its stack is, beside what the register currently answers. The register is
+  push-only and never reads a repository, so a project that never had the
+  conversation inherits an answer from a broader scope — which is how an app
+  whose store is `rusqlite` came to be told its database decision was Postgres.
+  Run it when a decision card asks you to record an area, and before recording
+  one yourself. It names the product that answers each area with the file and
+  line it read: that is EVIDENCE, not a decision — it says what is there, never
+  what was ruled out or why.
+
+  `record: true` writes the areas the manifests answer, at project scope, with
+  that file and line as the reason. It never writes an area with more than one
+  candidate, and it never writes one the manifests are silent about. For those,
+  ask the user and record their answer in their words.
+
 ## Record new knowledge (do this when something non-obvious is decided)
 
 - `mcp__chat-recall__recall_decision_record` — an explicit decision (subject,