memtrace 0.8.62 → 1.0.0

package/skills/commands/memtrace-provenance.md

@@ -1,93 +0,0 @@
----
-name: memtrace-provenance
-description: "Retrieve the governing decision lineage (why is this here) and contracts that bind a symbol from Cortex decision memory through the normal Memtrace MCP server. Use before deleting, rewriting, refactoring, or 'cleaning up' existing code that looks unused, odd, redundant, legacy, or policy-sensitive, and when the user asks why a symbol exists or what rules constrain it. Symbol-scoped; for free-text decision search use memtrace-decision-recall first. Do not infer intent from the diff or assume unfamiliar code is safe to remove."
-allowed-tools:
-  - mcp__memtrace__why_is_this_here
-  - mcp__memtrace__governing_contracts
-  - mcp__memtrace__verify_intent
-  - mcp__memtrace__recall_decision
-metadata:
-  author: "Syncable <support@syncable.dev>"
-  version: "1.0.0"
-  category: development
----
-
-## Overview
-
-Provenance answers **"why is this code here, and what binds it?"** before you change
-it. `why_is_this_here` returns the decision/conversation lineage that governs a symbol
-(its Governs/Produced provenance); `governing_contracts` returns the contract nodes
-that constrain it. Together they stop you from deleting code that closes a past issue
-or violating an invariant nothing in the AST advertises.
-
-Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bundled at the memtrace-skills plugin root).
-
-## Quick Reference
-
-| Tool | Purpose | Returns / FactStatus |
-|------|---------|----------------------|
-| `why_is_this_here` | The governing decision/conversation lineage of a symbol | DeterministicallyDerived \| CannotProve |
-| `governing_contracts` | The contract nodes that constrain a symbol | Contract nodes \| CannotProve |
-| `verify_intent` | Given a returned governing `decision_id` — is that rationale still valid? | Held \| ViolatedAt \| CannotProve |
-
-> **`why_is_this_here` and `governing_contracts` each take a `symbol_id` (uint64 node
-> id), not a name. `verify_intent` takes a `decision_id` (uint64), not a `symbol_id`.**
-> If you only have a name or a question, start with `recall_decision` (free text) — see
-> `memtrace-decision-recall`. ids come from a prior recall/arc result or the Cortex
-> view. Do not invent ids.
-
-> **Honesty contract:** for a symbol no decision produced, `why_is_this_here` returns an
-> honest **CannotProve**; `governing_contracts` returns CannotProve rather than a false
-> "no contracts" verdict. **CannotProve ≠ safe to delete / unconstrained** — it means
-> *unknown*, so fall back to blast-radius and the user.
-
-## Steps
-
-### 1. Get the symbol_id
-
-If you have a name or a "why" question, run `recall_decision(...)` first and take the
-`symbol_id` from the result if present, or use the id returned by a graph/Cortex view.
-The id-based tools need a numeric id. If you cannot get a symbol id, do not skip
-decision memory entirely: use `recall_decision("<symbol/subsystem/behavior>")` and
-report any matching decision/bans before changing the code.
-
-### 2. Ask why it's here
-
-`why_is_this_here(symbol_id)` → the governing decision lineage. This is the *rationale*
-the git blame won't give you: the decision that produced this code and, often, the
-problem it was put there to solve.
-
-### 3. Ask what constrains it
-
-`governing_contracts(symbol_id)` → contracts that must survive any rewrite (invariants,
-interface promises, "must always …" rules). A refactor that breaks one of these is a
-regression even if every test passes.
-
-### 4. Check the rationale still holds
-
-If `why_is_this_here` returns a governing `decision_id`, run `verify_intent(decision_id)`
-(see `memtrace-intent-verification`) — a `ViolatedAt` verdict (or a decision you can see
-was superseded via `recall_decision`) changes whether the code should still look this way.
-
-## Decision Points
-
-| Situation | Action |
-|-----------|--------|
-| Code looks unused/dead and you want to delete it | `why_is_this_here` + `governing_contracts` BEFORE deleting; CannotProve is not a green light |
-| Code is written in a strange/non-obvious way | `why_is_this_here` if you have a symbol id; otherwise `recall_decision` for the symbol/subsystem |
-| About to refactor a symbol's internals | `why_is_this_here` + `governing_contracts` — preserve the rationale and every constraint, not just the test surface |
-| User asks "why is this here?" | `why_is_this_here(symbol_id)`; if you only have a name, `recall_decision` first |
-| All provenance returns CannotProve | Treat as unknown; combine with `memtrace-impact` (blast radius) and ask the user before removing |
-
-## Output
-
-```text
-why_is_this_here(symbol_id: 4821)
-→ DeterministicallyDerived — governing lineage:
-   decision_id 913 (Governs): "Keep retry shim until legacy clients migrate"
-governing_contracts(symbol_id: 4821)
-→ contract node: "writes must always be debounced" (must survive any rewrite)
-— no decision produced the symbol → CannotProve (unknown, NOT unconstrained)
-```
-
-`verify_intent(decision_id)` on a returned lineage id yields Held | ViolatedAt | CannotProve.

package/skills/workflows/memtrace-fleet-coordination.md

@@ -1,107 +0,0 @@
----
-name: memtrace-fleet-coordination
-description: "Resolve fleet conflicts between coordinated agents: what conflict class A/B/C means, how a Class C destructive overlap gets decided (by an agent judge or a human), how to be the judge (fleet_submit_verdict), how to read your directive after a decision, and how branch-scoping isolates fleets. Use when the user says 'two agents are changing the same thing', 'resolve this conflict', 'who should proceed', 'a decision is waiting', or asks you to act as a mediator between agents. This skill explains the conflict model and decision loop; for just the verdict/directive/resolution tool calls on a specific escalation, use memtrace-fleet-resolve."
-allowed-tools:
-  - mcp__memtrace__fleet_record_episode
-  - mcp__memtrace__fleet_submit_verdict
-  - mcp__memtrace__fleet_get_escalation
-  - mcp__memtrace__fleet_list_escalations
-  - mcp__memtrace__fleet_resolve_escalation
-  - mcp__memtrace__fleet_get_node_state
-metadata:
-  author: "Syncable <support@syncable.dev>"
-  version: "1.0.0"
-  category: development
----
-
-# Fleet Coordination
-
-How the fleet turns overlapping edits into a safe decision. Read
-`memtrace-fleet-first` for the publish→edit→record protocol; this skill is the
-*conflict resolution* half.
-
-## Conflict classes (what `fleet_record_episode` returns)
-
-| Class | Meaning | What to do |
-|---|---|---|
-| **A** | Additive, order-independent | Proceed. |
-| **B** | Non-destructive overlap with another agent's work | Re-read the shared symbols, then proceed. |
-| **C** | A **destructive** change (signature change / move / dead-code removal) overlaps another agent's work | A decision is needed — it does NOT auto-resolve. |
-
-Class is computed **only against agents on your branch** (`(repo, branch)`).
-Agents on other branches are never conflict peers.
-
-## The Class C decision loop
-
-When `fleet_record_episode` returns class C it also returns an `escalation_id` and
-(when mediation is on) a `mediation_request`. The decision is made by an **agent
-judge**, a **human**, or — only when provably safe — the **deterministic referee**.
-
-### Being the judge (the user's own agent does the judging — no API keys)
-
-The `mediation_request` bundles **every agent's `assignment`** plus the contested
-symbols. Read the *other* agent's task and decide on merit (including against your
-own change). Submit:
-
-```jsonc
-fleet_submit_verdict({
-  escalation_id: "01J…",
-  agent_id: "agent-a",
-  verdict: { "kind": "recommend", "winner": "agent-b",
-             "rationale": "the signature change is the wider contract; rebase the fix onto it",
-             "confidence": 0.8 }
-})
-```
-
-Verdict kinds: `reconcile {merge_plan}` · `recommend {winner, rationale, confidence}`
-· `defer_to_human {question}`.
-
-Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bundled at the memtrace-skills plugin root).
-
-The referee then decides the outcome:
-- **Auto-apply** only when safe: the clear machine case, or ≥2 independent agents
-  agree — and **never** for a destructive *removal* (delete/move), which always
-  needs a human.
-- **Human confirm** — a recommendation is surfaced for one-click confirmation.
-- **Human required** — both sides destructive, agents disagree, or an agent
-  deferred → a person decides.
-
-### Reading your directive
-
-Poll `fleet_get_escalation({escalation_id, agent_id})` until `your_directive` ≠
-`wait`: `proceed` (you continue), `defer` (stand down / rebase onto the winner),
-`review` (read `resolution`).
-
-### Resolving as a human (or on a human's behalf via the dashboard)
-
-`fleet_resolve_escalation({escalation_id, resolution, winner})` records a human
-decision and clears the queue. Prefer the agent-judge path; use this for the
-genuine human-decision cases. `fleet_list_escalations({repo_id})` shows the
-"needs human" queue.
-
-## Why branch-scoping matters here
-
-A "winner / defer" only makes sense on a shared surface. Across branches, the
-loser can't defer (its branch needs the change too), so the fleet never escalates
-cross-branch — that's a merge-time concern git already owns. Keep your fleet to
-one session branch and conflicts stay real and resolvable.
-
-## Inspecting state
-
-`fleet_get_node_state({repo_id, node})` — recent episodes, active intents, dominant
-intent, and conflict density for one symbol. Use it to understand pressure on a
-hot symbol before you pile on.
-
-## Output
-
-`fleet_record_episode` on a destructive overlap, then `fleet_get_escalation` once decided:
-
-```jsonc
-// fleet_record_episode
-{ "conflict_class": "C", "escalation_id": "01J…",
-  "mediation_request": { /* every agent's assignment + the contested symbols */ } }
-
-// fleet_get_escalation — poll until your_directive ≠ "wait"
-{ "your_directive": "defer",
-  "resolution": "recommend: agent-b — rebase the fix onto the signature change" }
-```