Update to Exomem

{
  "description": "Preserve a durable conclusion or recurring entity from a conversation without dumping transcripts into compiled memory.",
  "included_files": [
    {
      "relative_path": "references/audit-checks.md",
      "size_in_bytes": 13831
    },
    {
      "relative_path": "references/before-writing.md",
      "size_in_bytes": 5923
    },
    {
      "relative_path": "references/engagement.md",
      "size_in_bytes": 21333
    },
    {
      "relative_path": "references/frontmatter.md",
      "size_in_bytes": 12579
    },
    {
      "relative_path": "references/governance.md",
      "size_in_bytes": 8806
    },
    {
      "relative_path": "references/mutation-results.md",
      "size_in_bytes": 7511
    },
    {
      "relative_path": "references/operation-routing.md",
      "size_in_bytes": 21424
    },
    {
      "relative_path": "references/operations.md",
      "size_in_bytes": 56563
    },
    {
      "relative_path": "references/page-types.md",
      "size_in_bytes": 20100
    },
    {
      "relative_path": "references/planning-records.md",
      "size_in_bytes": 15811
    },
    {
      "relative_path": "references/recall.md",
      "size_in_bytes": 19357
    },
    {
      "relative_path": "references/semantic-authoring.md",
      "size_in_bytes": 10041
    },
    {
      "relative_path": "references/supersession.md",
      "size_in_bytes": 5440
    },
    {
      "relative_path": "references/vault-care.md",
      "size_in_bytes": 13050
    },
    {
      "relative_path": "references/vocabulary.md",
      "size_in_bytes": 5660
    },
    {
      "relative_path": "references/write-scope.md",
      "size_in_bytes": 10880
    },
    {
      "relative_path": "references/writing.md",
      "size_in_bytes": 29475
    }
  ],
  "name": "exomem-capture",
  "skill_md_contents": "---\nname: exomem-capture\ndescription: Preserve a durable conclusion or recurring entity from a conversation without dumping transcripts into compiled memory.\nmetadata:\n  skill_contract: 0d23c50d8751e79c26e99bbe70bc7adfcdf460c8ba88dd7bde037f50d2190af0\n  version: \"0.1.0\"\n---\n\n# exomem-capture\n\n## Purpose\nSave durable conclusions and recurring entities at the right epistemic layer.\n\n## When to use\nUse when the user asks to save or the session lands on durable reusable knowledge, including stable context about a recurring entity.\n\n## Portable operating rules\n\nBefore the first operation, inspect the exposed bootstrap schema. If it lacks `skill_contract`, obtain `bootstrap(profile=\"compact\")` directly. Otherwise obtain `bootstrap(profile=\"session\", skill_contract=<metadata.skill_contract>)` if current policy or capabilities are missing; honor `engagement.envelope` and `available_product_tools`. Reuse returned state until policy, connection, adapter, or returned vault configuration/registry state changes. If the server rejects the session profile or argument, obtain `bootstrap(profile=\"compact\")` once. Use the harness's supported discovery mechanism and load only the tools needed now. If the applicable local procedure cannot be read, obtain the portable compact contract; do not improvise a write.\n\nDo not invoke tools absent from `available_product_tools`; use the live capability list even when a bundled workflow mentions a withheld operation.\n\nUse `configure_memory` set/clear only for an explicit user request to change saved engagement.\nRecall, capture, installation and missing hooks use the existing preference;\nnone authorizes changing it. Inspect first when the user requests a change.\n\nSources/Evidence are immutable, and content outside the managed Knowledge Base\nis read-only. Before a compiled write: reuse current relevant search/read results,\ncheck for duplicates, and include known source references and reviewed connections\nin the first write. Use `connect_memory(operation=\"suggest-links\")` when useful\nconnections are still unknown, not to recheck links already established in context.\nHonor the live confirmation ceiling;\na workflow or standing capture preference does not grant restructure authority.\n\nInspect mutation results before reporting success. On `success: false`, follow\nthe structured error. For warming, busy, pending, or\n`MUTATION_COMMITTED_ACKNOWLEDGEMENT_UNCERTAIN`, preserve the same mutation identity\nand unchanged payload; wait/reconcile/retry only as instructed, never with a new\nidentity after an uncertain commit.\n\n## Durable personal baselines\nA stable preference, recurring routine, historical baseline, or durable affiliation\nis eligible only when both stability or recurrence and reusable comparison,\ninterpretation, or decision value are clear. Attach a facet or affiliation to a\nuniquely resolved Entity; otherwise write one concise compiled observation. Use\nRecords only for an observed measurement accepted by a compatible existing\ncollection. Fleeting preferences, one-off activity, incidental associations, trivial\nmetrics, and tentative events stay quiet. Durable interpretations retain explicit\nattribution and uncertainty rather than becoming established facts. Eligibility never creates an Entity,\ncollection, or schema. Concise observations and narrow additive facts follow\n`proactive_capture`; a new Entity or your own affiliation edge follows `proactive_capture`;\naccepting a queued relation uses `link_acceptance`; merge or substantial curation uses\nconfirmed `restructure_execution`.\n\n## Workflow\nBefore choosing a destination, partition the exchange into independently reusable\nobjects by retrieval question, subject/domain, temporal episode, and epistemic\nrole. Reuse current relevant recall and resolve each meaningful cluster against\ncanonical homes. The open note has no priority; keep details within one coherent\nscope together. Preserve durable hypotheses as attributed, uncertain claims.\nPerform one completeness/destination review for the whole write plan, not a new\nreview after every write. During development, repository/specification artifacts\ncarry transient progress; capture reusable decisions and verified milestones.\n\n1. Decide whether the material is raw evidence or a compiled conclusion.\n2. Use `capture_source` for raw captured text or source material. Classify it on\n   two open axes: `source_kind` (what it is, required) and `domain` (what it is\n   about), plus `projects` for the work it serves. Name the closest known kind\n   or a new one; there is no catch-all.\n3. Pick the lane before the transport. Raw material stays with `capture_source`, which takes `files` for attachments as well as `content` for text. Proof-bearing material takes `preserve_evidence` for factual text, `preserve_artifacts` when file handles are available, and `transfer_artifact` only as the binary-upload fallback.\n4. Draft distilled conclusions as: `research-note`, `insight`, `failure`, or `pattern`. Pass any path captured in steps 2-3 as `sources:` so the conclusion links to its provenance and the source leaves the unprocessed queue.\n5. Reuse known meaningful connections; use `connect_memory(operation=\"suggest-links\")`\n   when candidates are still missing. Then write with\n   `remember`, carrying the sources and accepted links in the first write; prefer\n   `edit_memory` or `replace_memory` for near-duplicates.\n6. For an entity, consult the active entity registry and selected knowledge packs,\n   then call `connect_memory(operation=\"resolve-entity\", name=...)` before writing.\n7. When one active entity matches, use `edit_memory` for a small stable-fact\n   correction or the canonical relation workflow for a new connection.\n   A stable, uniquely attributable fact about a resolved person, including the\n   vault owner's own entity (role, affiliation, relationship), is an entity-level\n   fact: route it to that entity under `proactive_capture`, not just in the reply\n   that used it. Contact details (phone, address, email, identifiers) go on the\n   same entity page, in a dedicated `## Contact` section, each as its own\n   `- [contact] ...` unit. Never put them in the summary or in `fact` units:\n   activation serves `contact` units only when the turn asks to reach the person,\n   and a restricted audience that cannot see the entity cannot see the section.\n   Do not create a separate contact page or page type.\n8. Only when no entity matches and the identity is stable, and central or\n   recurring, and useful beyond this source, use `connect_memory(operation=\"create-entity\")`.\n   When the name you write is in another script than the user's own spelling\n   of it, add a native-script alias (`aliases=[...]` at create, or the\n   `aliases` field through `edit_memory` on an existing page); see\n   `references/writing.md` § Names in another script.\n\n## Lifecycle\nTwo more classes land here. A **stated intent or commitment** routes to Planning after resolving workflow posture and inspecting for an existing item to update before creating one. An **observed outcome or event** routes only to one compatible Records collection with `record_memory(action=\"append\")`; when collections compete ask one focused question, and when none fits propose one rather than creating it silently. Records never transition Planning: only explicit user intent may request a guarded transition, while a `propose-after-outcome` posture may only propose one. A tentative claim is never written as an event, and elapsed time is never an outcome.\n\n## Artifact role and current state\nRead the supporting units for `artifact_role_promotion` and\n`transient_state_review`; neither signal grants mutation authority. Choose a home\nby role even within one topic: a repeatable successful procedure belongs in a\nsuitable reusable note, and an attributed multi-source synthesis in a research\nnote. Search existing eligible homes first. Keep exact source-unit provenance:\nreference both the procedure and outcome units when extracting a method, or the\nsynthesis unit and its distinct sources when compiling a research note. Retain\nthe experiment history. A title match or parent backlink does not establish that\nthe identified material has a home; exact represented content does, while a\nparaphrase remains a review candidate for the reader to assess.\n\nFor example, a batch may contain two separately successful reusable methods and\na synthesis across two sources. Give each method its own evidence and check the\nsynthesis independently; extracting one does not settle the others. A protocol\nwithout reusable success or a list of citations alone needs no such promotion.\nFor a single batch, “No taste results yet” alongside an observed taste result\ninvites a current-wording correction; “Previously no taste results existed” is\nhistory, and taste results do not settle an awaited safety result or a new trial.\nPreserve that history through a governed edit or exact valid supersession.\n\nExtraction/restructuring uses confirmed `restructure_execution`; an\nalready-authorized local correction acquires no additional confirmation step.\nObserved transaction state still follows the existing Records claims handoff,\nnever an automatic append from a review signal. Item triage changes presentation,\nnot evidence coverage. Explicit review exposes complete/capped/unknown coverage;\ncompact omission is not proof of a clean page. Apply this role-first reasoning to\nvisible conversation transitions before writing too. An MCP-only server cannot\nguarantee detection or capture of a tool-free turn.\n\n## Vocabulary\n\nRead [vocabulary](references/vocabulary.md) before changing a registry.\nIf the vocabulary reference is missing, inspect the exposed bootstrap schema.\nUse `bootstrap(profile=\"compact\", section=\"vocabulary\")`, or\n`bootstrap(profile=\"full\")` when `section` is unavailable. Follow the returned\ninspect routes and `save` contract. Reuse or alias before proposing justified\nnew meaning; save with the current hash and `why`. Report saved versus queued\nand the returned restore route. Use only exposed operations.\n\n## Relation governance\nResolve typed meaning with `resolve-relation` before authoring. Reuse a specific\ntruthful match; otherwise choose honest `relates_to` or no edge. Durable recurring\nmeaning is proposal-first through `propose-relation` and hash-guarded\n`save-relations`; corrections use a new canonical key and deprecate the old one.\n\n## Output contract\nAfter writing, report exactly `Saved -> <path>` plus one short phrase if needed. If nothing durable was saved, say why. Report a lifecycle consequence in the user's own vocabulary and cite the collection the way recall cites a page; the words Planning, Records, collection, schema and natural key never lead the report.\n\n## Save rules\nKeep raw source verbatim when it matters. Keep compiled notes concise, attributed, linked, and written as conclusions, not transcripts.\n\n## Mistakes to avoid\nDo not save unresolved brainstorming as a conclusion. Do not bury raw evidence\ninside a compiled note. A single incidental mention, unresolved identity, or\ntransient participant stays in source/note context. Do not create a parallel\npage when an existing active note or entity should be edited, linked, or\nsuperseded.\n\n<!-- exomem-semantic-authoring:v8 sha256:4f1a876ac71d48ed55481e9083522afb38393521c8c64b37e73800bb3028ec7d -->\n## Semantic authoring contract\n\nEvery new, replaced, or activated compiled note in the live class needs at least one valid, non-empty semantic unit. Either compact or rich form satisfies the minimum; compact is preferred, and a valid rich unit does not need a duplicate compact restatement.\n\nSemantic roles:\n\n- Category: One primary open-vocabulary label describes what a unit is about; rich category defaults to its governed kind unless explicitly overridden.\n- Tag: Zero or more optional secondary retrieval labels refine lookup and never replace category or determine kind.\n- Kind: The governed semantic form: compact units always use `observation`; rich units use their recognized heading kind.\n\nCompact grammar: `- [category] content #tags (context) ^anchor`. Parse valid compact observations anywhere outside fenced code blocks. Exomem writers use `-` under the canonical `## Observations` section. Parser bullet markers are `-`, `*`, `+`; the canonical marker is `-`. Parse from the end by taking anchor, then context, then trailing tags; the authored display order remains tags, context, anchor. Category uses open vocabulary.\n\n- Compact category: the unit's one primary open-vocabulary subject or domain label. After trimming, use 1-64 Unicode code points; begin with a Unicode letter; then use only Unicode letters or digits, spaces, `_`, or `-`. Apply Unicode NFKC and casefold, then collapse runs of spaces, `_`, and `-` to one `_`. Registry alias resolution is separate from authored canonicalization; an unseen valid category needs no registry write.\n- Compact content: the unit's substantive observation. Use non-empty content that remains on one Markdown line. Escaped parentheses, embedded hashes, and non-trailing tag-like text remain content.\n- Compact tags: zero or more optional secondary retrieval labels; tags do not replace the primary category or governed kind. Write `#slug`. Use 1-64 Unicode letters or digits, `_`, `-`, or `/`; begin with a letter or digit; do not use empty path segments or a trailing `/`. Use one contiguous trailing run after content and before optional context and anchor.\n- Compact context: one optional authored qualifier for the observation. Write `(<context>)`. Use one balanced, unescaped parenthesized suffix preceded by whitespace.\n- Compact anchor: one optional stable authored unit identifier. Write `^anchor`. Use 1-64 ASCII letters, digits, or hyphens and begin and end alphanumeric. Place it at the end of the line.\n- Compact exclusions: observation-shaped rows inside fenced code blocks; task labels `[ ]`, `[x]`, `[X]`, and `[-]`; reserved or punctuation-bearing bracket labels outside category grammar. Compact units do not carry typed unit relations; use a canonical note-level relation or the rich form.\n- Rich: write `## <Governed Kind>` with optional leading metadata `- category: <open category>`, `- id: <stable-id>`, `- tags: <comma-separated tags>`, `- context: <context>`, `- relations: <relation-type>: [[Target]]`, `- verdict: <epistemic outcome>`, `- check_by: <ISO revisit date>`. Metadata rows are optional and leading; the canonical writer emits category, id, tags, context, relations, verdict and check_by; category defaults to the governed kind when omitted. Accepted metadata order is flexible while rows remain leading. After optional leading metadata, add a blank line and a substantive Markdown body. Typed unit relations require the rich form. A `#anchor` target addresses a unit.\n- Epistemic corrections: Inspect affected claims and evidence. Distinguish attributed accounts from established facts. Correct suitable existing units with guarded writers, justified verdicts and exact links; verify current state. Refutation alone changes neither lifecycle nor rank. Writers retain prior interpretations; request bootstrap with profile=full for history guidance. Keep an anchored unit's identity when its wording changes. Preserve a false historical proposition and author its verdict; add a distinct corrective unit when useful. Refutation and contradiction do not imply supersession or reduce rank. The semantic writer retains prior interpretations atomically. Read revision_history with read_memory(include_history=true), optionally for unit_ref, using history_limit and history_continuation. Existing history remains the page's operation log. Entities and legacy pages use their existing edit owner; Records use guarded row corrections and history. Corrections need no dated child, special user nudge, or confirmation beyond the active engagement policy.\n- Rich boundary: A heading at level N owns content until the next non-fenced heading at level N or shallower; deeper headings remain in its body. `empty_rich_unit` means a recognized rich heading has no substantive body; Add substantive body content or remove the empty recognized heading.\n- Exact applicability: obtain `bootstrap(profile=\"compact\", section=\"authoring\")` and read `semantic_authoring.minimum_semantic_unit` for current structural applicability and the status-class rule. If the exposed bootstrap schema lacks `section`, use `bootstrap(profile=\"full\")` instead; released profiles reject section arguments. Apply `compiled_intent(after_state) = canonical_compiled_destination(path) OR the normalized type's note-type role is compiled`. Shipped compiled types: `research-note` in `Notes/Research`, `insight` in `Notes/Insights`, `failure` in `Notes/Failures`, `pattern` in `Notes/Patterns`, `experiment` in `Notes/Experiments`, `production-log` in `Notes/Productions`. More may be registered; `schema_memory(subject=\"note-types\", operation=\"inspect\")` lists the live set. Reject missing, invalid, or mismatched compiled frontmatter before evaluating the minimum-unit predicate. The minimum predicate applies when the path and normalized compiled type structurally match; the result is writable managed Markdown in the governed subtree; the result is outside Sources, Evidence, and trash; no activation exclusion applies; the admitted effective status class is live. Check live creates, replacements and transitions to live; pending compiled notes may remain unit-free until activation.\n- Existing active pages: A post-activation compliant page cannot lose its final valid semantic unit.\n- Exempt content: arbitrary non-compiled Markdown, dataset cards, Evidence artifacts, hubs, indexes, logs, non-Markdown files, schema and admin artifacts, snapshots, Sources, templates, trash.\n- Routes: use `remember` for a new compiled note, `replace_memory` for a replacement, `observe_memory` for one unit, and `edit_memory` for a small edit or activation. Tier 2 manage_memory_file create, overwrite, and append receive the same semantic precommit contract on the complete resulting compiled Markdown; prefer remember or replace_memory when their typed route fits.\n- Findings: `missing_semantic_unit` means an applicable live-class compiled result has no valid non-empty unit; `empty_rich_unit` means a recognized rich heading has no substantive body. Add substantive body content or remove the empty recognized heading.\n- Compact remediation: Add `## Observations` and `- [operating constraint] Keep retries bounded #reliability`.\n- Rich remediation: Alternatively add `## Decision`, a blank line, and a substantive body.\n- Semantic-unit coverage and relation-review disposition are independent obligations.\n- Portable categories: Choose exactly one primary category: prefer a meaningful epistemic or operational role and put the domain in tags, but if the role would only be a generic fact, finding, or observation and the domain is the durable lens, use a domain category instead. The category vocabulary is open: these core keys are a shared starting point, not a closed list. When no core key is a good primary fit, author a new meaningful category rather than forcing an ill-fitting one. Use exactly one primary category; kind is the governed form, tags are secondary facets, and relations are typed edges. The rich form's category defaults to its kind, so `category: decision` is redundant when the kind is Decision. Create multiple distinct semantic observations and typed relations when the source genuinely supports them, but never multiply units or relations to satisfy a quota and never duplicate the same fact. Core keys are `action`, `assumption`, `code`, `config`, `constraint`, `decision`, `design`, `fact`, `finding`, `insight`, `preference`, `problem`, `question`, `requirement`, `risk`, `technique`. Core aliases are `actions` → `action`, `assumptions` → `assumption`, `configs` → `config`, `configuration` → `config`, `configurations` → `config`, `constraints` → `constraint`, `decisions` → `decision`, `designs` → `design`, `facts` → `fact`, `findings` → `finding`, `insights` → `insight`, `open_question` → `question`, `open_questions` → `question`, `preferences` → `preference`, `problems` → `problem`, `questions` → `question`, `requirements` → `requirement`, `risks` → `risk`, `techniques` → `technique`. Role example: `- [decision] Relocate to a coastal city next spring #life ^relocation`. Domain example: `- [nutrition] Evening protein improves adherence #experiment ^evening-protein`. Breadth example (life, finance, legal/travel, and career alongside one retained code line):\n\n```markdown\n- [constraint] Keep retry windows bounded #code ^retry-windows\n- [risk] Variable-rate mortgage payments could spike #finance ^mortgage-rate-risk\n- [question] Does the destination require a visa before travel #legal #travel ^visa-requirement\n- [career] Weigh a sabbatical before the next promotion cycle #growth ^sabbatical-timing\n```\n\nRich example:\n\n```markdown\n## Decision\n- id: commit-to-morning-training\n- tags: health\n- relations: supports: [[Knowledge Base/Notes/Health/Morning training]]\n\nCommit to a fixed 6am training block on weekdays so consistency compounds and health stays the durable lens for this decision.\n```\n"
}