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.…
sancovp/carton-mcp
SkillsMP has collected 23 skills from sancovp/carton-mcp. Open a skill to review its source and details.
- Latest recorded source activity
- SkillsMP catalog refreshed
- skills collected
- 23
- GitHub stars
- 1
- GitHub forks
- 0
Skills in this repository
Showing 23 of 23 collected skills.
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)…
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…
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…
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:…
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…
WHAT: Precision editing of CartON concept descriptions WHEN: When you need to update a concept description with surgical edits
WHAT: capture architectural design insights from a conversation into CartON as Design_-prefixed concepts in an architecture collection, with full descriptions and cross-reference relationships to other design concepts. WHEN: when an architecture discussion…
WHAT: how to diagnose and restart the CartON observation worker daemon when it dies — check the worker log for the crash reason and relaunch the daemon with the required Neo4j env vars. WHEN: when ps aux shows no observation_worker process, carton_management…
WHAT: how CartON indexes concepts into ChromaDB directly from the daemon's memory, with no wiki filesystem intermediary — SmartChromaRAG.ingest_concepts takes concept dicts and makes them semantically searchable. WHEN: when working on how concepts get…
WHAT: the fix that makes only HAS_OPTION relationships become TreeShell children — replace the hardcoded GIINT child_types in _jit_node_from_carton with the HAS_OPTION relationship, so TreeShell options are explicitly programmed via CartON instead of inferred…
WHAT: how to diagnose and fix CartON MCP broken pipe errors where reads work but writes fail — recovering the CartON write path after an MCP process failure. WHEN: when add_concept returns Errno 32 Broken pipe but get_concept still works, CartON writes fail…
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…
WHAT: the actual CartON Neo4j graph schema — the single :Wiki node label, its node properties (name, description, timestamp, etc.), and the relationship types CartON uses to connect concepts. WHEN: when you need to understand how CartON stores and relates…
WHAT: how to program TreeShell navigation options via CartON HAS_OPTION relationships — each HAS_OPTION target becomes a navigable, just-in-time-resolvable child node, so the CartON graph is the surface where you program a TreeShell menu's children. WHEN:…
WHAT: why CartON relationships are NOT immediately queryable right after add_concept — the node is created instantly but its relationships go through the daemon unwind, so Neo4j traversal queries against the just-created concept come back empty; query from…
WHAT: the implementation pattern for making CartON the source of truth for TreeShell node definitions — embed the raw node dict as a JSON marker in the concept description during sync (node_sync.py), so TreeShell nodes persist to and load from the CartON…
WHAT: which CartON relationship types map to TreeShell navigable children — how to structure a concept with HAS_PART / HAS_COMPONENT / HAS_FEATURE / HAS_DELIVERABLE / HAS_TASK relationships so it renders as a navigable TreeShell node with children via…
WHAT: the architecture where persistent agent memory files (MEMORY.md and other memory artifacts) are auto-generated VIEWS projected from the CartON knowledge graph, with CartON as the single source of truth — you never hand-edit the memory file, you change…
WHAT: the existing TreeShell-to-CartON integration in heaven-tree-repl — how node_sync.py, learnings.py, and renderer.py form the bridge between TreeShell navigation and the CartON knowledge graph (fire-and-forget sync to CartON on render). WHEN: when…
WHAT: the three CartON observation queue file formats and when to use each one (raw_concept flat format, observation format, batch format) for files written to the carton_queue directory that the observation worker daemon processes. WHEN: when writing or…
WHAT: CartON's server-side payload stashing — on a failed/exception add_concept the partial payload is stashed so a retry merges new fields without re-typing everything. WHEN: an add_concept errors and you want to re-send only the missing fields, or you're…
WHAT: the bidirectional population pattern between the CartON knowledge graph and TreeShell navigation nodes — how a NODE_DEF embedded in a CartON concept description and the family JSON configs resolve into a TreeShell node, in both directions. WHEN: when…