원클릭으로 Manus에서 모든 스킬 실행

skill-carton-memory-ontology-design

스타1

포크0

업데이트2026년 7월 8일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

sancovp

sancovp/carton-mcp

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.)

이 저장소의 다른 Skills

같은 저장소

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.)