cybermem

name	cybermem
description	Use Cybermem to persist and retrieve reusable cyber research system knowledge as a lightweight SQLite-backed graph. Use when researching assets, threat models, bug history, vulnerability hypotheses, sources, sinks, mitigations, primitives, chains, or reusable trajectories.

Cybermem

Cybermem is a local memory substrate for cyber research. It stores durable system knowledge as typed graph nodes with lightweight evidence references. It does not store transcripts, task goals, bulk file content, or generated artifacts.

When To Use

• Search Cybermem before researching an asset, subsystem, vulnerability class, bug history, source, sink, mitigation, primitive, chain, or reusable trajectory that may already have prior knowledge.
• Save new memory only when it is reusable beyond the current conversation or command run.
• Prefer refining an existing node over creating a near-duplicate.
• Link related nodes when the relationship will help future research.
• Use the local viewer's Transfer controls when memory should travel to another workspace or machine.

Memory Boundary

Store claims, relationships, and evidence pointers. Keep artifacts on disk.

Good Cybermem content:

• Stable asset descriptions and boundaries.
• Historical bugs, CVEs, patch-diff findings, and security-relevant comments.
• Security invariants expected to hold.
• Custom mitigations and defense assumptions.
• Attacker-controlled sources and sensitive sinks.
• Suspected or confirmed primitives.
• Suspected or confirmed exploit chains.
• Reusable research trajectories.

Do not store:

• Chat transcripts or session narration.
• Current task goals or planning notes.
• Full source files, command output dumps, reports, PoVs, screenshots, or traces.
• Absolute local file paths unless they are intentionally external references.

Evidence references should use paths relative to the workspace, repo, or asset root whenever possible.

Node Types

• asset: An application, system, program, equipment, service, organization, or person in scope.
• bug: A historical bug, CVE, patch-diff finding, security-relevant code comment, or prior defect note.
• invariant: A security fact that is expected to remain true.
• mitigation: A known exploit prevention or hardening measure.
• source: An attacker-controlled entrypoint into a system.
• sink: A sensitive operation, function, boundary, or code area.
• primitive: A suspected or confirmed individual security flaw.
• chain: A suspected or confirmed composition of primitives from source to sink.
• trajectory: Reusable research steps, heuristics, or analysis routes.

Tool Use

Use the MCP tools directly and pass the current workspace root when available:

• cybermem_search: Search memory by query, type, asset ids, or tags.
• cybermem_artifacts: Search reports, PoCs, logs, READMEs, traces, commands, and URLs that support memory nodes.
• cybermem_get: Retrieve a node by id with evidence and links.
• cybermem_save: Create a node or additively merge durable knowledge into one.
• cybermem_correct: Exactly replace supplied fields on an existing node using its current revision.
• cybermem_link: Add a directed relationship between nodes.
• cybermem_unlink: Remove one exact directed relationship.
• cybermem_delete: Delete one node using its current revision after referenced assets are detached.
• cybermem_dream: Back up memory first, then actively curate the graph by adding, editing, and removing memory nodes where deterministic maintenance is safe.

Common relations include belongs_to, relates_to, violates, mitigated_by, reachable_from, flows_to, composes, supports, and supersedes. Use another short identifier when the relationship is clearer.

Use Dreaming when the user asks for memory consolidation, during scheduled quiet maintenance, or after noticing inconsistent/stale claims. Dreaming is active, not review-only: after backing up memory, it performs deterministic curation and returns an action log. Current curation can add missing placeholder assets, edit legacy chains to make required impact/reachability fields explicit, remove rejected isolated nodes that have no evidence, refresh FTS, and optimize SQLite.

Use cybermem_artifacts when re-entering a prior research session through its reports, PoCs, logs, READMEs, or traces. The artifact index is derived from evidence refs; Cybermem still stores only references, not artifact contents.

Correction Guidance

Use cybermem_save for creation and additive refinement. Use cybermem_correct when a stored claim or collection is wrong, stale, or must be cleared.

Before correcting, call cybermem_get and pass the returned revision as expectedRevision. Every supplied correction field is an exact replacement. In particular, typeData replaces the complete object, and assetIds, tags, and evidence replace their complete collections. Pass an empty array to clear a collection. If the revision changed, retrieve the node again and reconcile rather than overwriting the newer memory.

Node types are immutable. Use cybermem_unlink to remove an exact relation. Use cybermem_delete only for a node that should no longer exist; an asset must first be removed from every referencing node's assetIds.

Save Guidance

Keep nodes concise. Put the durable claim in summary; use body only for details future research will need. Use typeData for structured reusable state, such as affected versions, reachable functions, threat assumptions, or validation details.

For chain nodes, typeData must include non-empty string fields:

• impact: the concrete security consequence. If the current consequence is only a crash, denial of service, or non-security bug, say that explicitly.
• reachability: the attacker path, source, preconditions, gates, privileges, target assumptions, and why the chain is or is not realistically reachable.

Use additional typeData fields for durable preconditions, observed behavior, weak links, affected versions, or other reusable details.

Use statuses conservatively:

• draft: Incomplete or newly captured.
• suspected: Plausible but not confirmed.
• confirmed: Supported by strong evidence.
• rejected: Investigated and found false or irrelevant.
• stale: Previously useful but likely outdated.

Use confidence from 0 to 1. A high confidence value should usually have evidence.

Evidence Guidance

Evidence references are lightweight. They should make future research able to find the artifact or code location again without copying the artifact into memory.

Useful evidence examples:

{
  "kind": "code",
  "pathBase": "workspace",
  "path": "src/auth/session.ts",
  "locator": {"lineStart": 42, "lineEnd": 60, "symbol": "validateSession"},
  "summary": "Session validation rejects expired tokens before privilege checks."
}

{
  "kind": "artifact",
  "pathBase": "workspace",
  "path": "povs/admin-bypass/README.md",
  "summary": "PoV notes for the suspected admin bypass chain."
}

Workflow Boundary

Cybermem does not plan or track recon, threat-modeling, analysis, proofing, or reporting phases. Use Cyberflow when research needs workflow orchestration, phase gates, specialist agents, or proof/report tracking. Cybermem's role is limited to making durable knowledge searchable, correctable, linkable, and portable over time.