Run any Skill in Manus with one click

skill-carton-memory-ontology-design

Stars1

Forks0

UpdatedJuly 8, 2026 at 23:37

WHAT: where the memory-tier ontology (Memory_Tier, Memory_Tier_0..3, UltraMap, Hypercluster) lives now — it MOVED to SOMA's OWL; do NOT design it in CartON. WHEN: you need to find/edit the memory-tier ontology types, or you're tempted to re-add a CartON memory-ontology bootstrap.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

sancovp

sancovp/carton-mcp

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name	skill-carton-memory-ontology-design
description	WHAT: where the memory-tier ontology (Memory_Tier, Memory_Tier_0..3, UltraMap, Hypercluster) lives now — it MOVED to SOMA's OWL; do NOT design it in CartON. WHEN: you need to find/edit the memory-tier ontology types, or you're tempted to re-add a CartON memory-ontology bootstrap.

skill-carton-memory-ontology-design

STATUS: the carton-side how-to is REMOVED — the intent lives in SOMA now (2026-06-17)

This skill used to instruct authoring HyperCluster / Memory_Tier / UltraMap / Carton_Ontology_Entity types via CartON's bootstrap_memory_ontology_types. That path is DEAD: bootstrap_memory_ontology_types (and bootstrap_ontology_types) in carton_utils.py are commented out / DISABLED, and the memory-tier ontology was MOVED to SOMA's OWL (base/soma-prolog/soma_prolog/ starsystem.owl: Memory_Tier + Memory_Tier_0..3 + UltraMap + an enriched Hypercluster, commit dc9abc6). This is the carton->SOMA unification: ontology/type definitions live in SOMA, not in a carton bootstrap.

What to do now (the preserved intent)

To find or edit the memory-tier ontology → it is OWL classes/restrictions in base/soma-prolog/soma_prolog/starsystem.owl. Edit it there; SOMA reflects vaulted/declared types back into CartON.
Do NOT re-add bootstrap_memory_ontology_types or any carton-side ontology-type creation — that is exactly the removed machinery.
Memory_Tier instances (the actual tier files / MEMORY.md) are still a CartON projection — see skill-memory-as-carton-projection.

(The original how-to is preserved in git history + /tmp/heaven_data/_deprecated_skills if needed.)

More from this repository

same repository

dev-flow-split-content

sancovp/carton-mcp

WHAT: the development-flow for the split-content capability — separating a concept whose description (n.d) holds raw CONTENT (a data dump / pasted document) from a real DESCRIPTION, by splitting the raw content into its own `{concept_name}_Desc_Content` node. Covers `carton_split_content.py` (both `build_split_spec`, the pure spec function, and `split_content_concept`, the thin neo4j-writing wrapper — self-contained, ONE module, per the one-capability-one-module law), the `Desc_Content` universal type, the `has_desc_content` relationship, and the `split_content_concept` MCP tool. WHEN: when editing `carton_split_content.py`, `split_content_concept`, the `Desc_Content` type, or the `has_desc_content` relationship; or adding a new capability that also needs the content-vs-description split (any of).

2026-07-081

edit-add-concept-optional-fields

sancovp/carton-mcp

WHAT: the dev-flow for the OPTIONAL domain/subdomain/personal_domain/produces params on add_concept_tool_func — the internal chokepoint function every CartON concept-creation caller (Dragonbones, sm_gate.py, split_content_concept, the migration scripts) passes through, whether or not they use the add_concept MCP tool. WHEN: when editing add_concept_tool_func's domain/subdomain/personal_domain/produces params, merge_optional_domain_fields, or PERSONAL_DOMAINS in add_concept_tool.py (any of).

2026-07-081

edit-carton-kv

sancovp/carton-mcp

WHAT: the development-flow for changing the CartON KV / CartonObj capability — the embedded-structured-KV-in-concept-descriptions feature (a <CartonObj name=..>{ JSON-with-bare-refs }</CartonObj> fence in n.d): the carton_kv parser/normalizer, edit_carton_obj (surgical single-leaf body edits + remove_fence), validate_carton_obj (schema + did-you-mean refs), the auto_link_description fence-opacity, fence-preservation (carry_forward_fences), ref-expansion, and the is_schema schema registry. It is the COMPLETE distributed edit-set (lib ↔ utils wrappers ↔ MCP tools ↔ the linker ↔ the daemon's live parse path ↔ the schema graph) + deploy + the only valid E2E test. WHEN: when editing carton_kv.py, the edit_carton_obj / validate_carton_obj / get_concept-expand MCP tools, the auto_link_description fence-opacity masking, the daemon fence/desc-mode parse path (parse_queue_file_to_concepts / batch_create_concepts_neo4j), or the is_schema schema-registry; or adding ANY new CartonObj capability (any of).

2026-07-081

edit-the-webbing-agent

sancovp/carton-mcp

WHAT: the dev-flow for editing the WEBBING AGENT — carton's standing CONCEPT-ATOMIZATION daemon, CLONED from the proven Sophia (docmirror-cohere) architecture: CODE detects a batch of under-structured, autolinker-processed, main-agent-authored concepts (linked=true, source in CHAT_SOURCES, webbed IS NULL), serves them to a fresh SDNAC run each tick, the agent ADDS real is_a/part_of/instantiates/produces structure + child concepts, and CODE verifies + marks webbed=true. Covers webbing_agent.py, webbing_agent_worker.py, and the one-line SYSTEM_SOURCES coupling in observation_worker_daemon.py. WHEN: when editing webbing_agent.py, webbing_agent_worker.py, the eligibility predicate (_is_underdeveloped), the batch-goal builder (_build_batch_goal), the WEBBER_SYSTEM_PROMPT, the webbed/source recursion-guard, or CHAT_SOURCES/SYSTEM_SOURCES in observation_worker_daemon.py (any of).

2026-07-081

jit-carton-node-resolver

sancovp/carton-mcp

WHAT: just-in-time building of TreeShell nodes from CartON graph relationships — when a jump targets a coordinate not found in any family JSON config, resolve the CartON concept into a cached Menu node whose options come from its HAS_PART relationships. WHEN: when a TreeShell jump target is not found in any loaded family JSON config, you need a node built on the fly from a CartON concept, or working on JIT node resolution for SANCREV game navigation.

2026-07-081

mcp-skill-carton

sancovp/carton-mcp

WHAT: the CartON MCP — a persistent knowledge graph (Neo4j + ChromaDB) you add concepts to, query, edit, and project. WHEN: persisting knowledge, creating observations/concepts, querying concept networks, semantic search, or editing a concept's description/structured data.

2026-07-081

name	skill-carton-memory-ontology-design
description	WHAT: where the memory-tier ontology (Memory_Tier, Memory_Tier_0..3, UltraMap, Hypercluster) lives now — it MOVED to SOMA's OWL; do NOT design it in CartON. WHEN: you need to find/edit the memory-tier ontology types, or you're tempted to re-add a CartON memory-ontology bootstrap.

skill-carton-memory-ontology-design

STATUS: the carton-side how-to is REMOVED — the intent lives in SOMA now (2026-06-17)

What to do now (the preserved intent)

To find or edit the memory-tier ontology → it is OWL classes/restrictions in base/soma-prolog/soma_prolog/starsystem.owl. Edit it there; SOMA reflects vaulted/declared types back into CartON.
Do NOT re-add bootstrap_memory_ontology_types or any carton-side ontology-type creation — that is exactly the removed machinery.
Memory_Tier instances (the actual tier files / MEMORY.md) are still a CartON projection — see skill-memory-as-carton-projection.

(The original how-to is preserved in git history + /tmp/heaven_data/_deprecated_skills if needed.)