ontology-bootstrap

# Bootstrap a trustworthy ontology Create a shared meaning model, not a labeled file tree. Treat repository structure as implementation evidence. Never promote a folder, package, README heading, or model-generated phrase into a business concept without a definition and source-backed justification. Use only ontology-atlas MCP tools for the core workflow. Do not depend on CodeGraph, another skill, shell search, or an AST index. Those may exist, but a plain agent connected only to Atlas must still succeed at the meaning model. The optional, bounded task-navigation enrichment below is the sole exception: after meaning selects a stable element, a source-aware builder may use an available local source reader to verify exact coordinates that Atlas then checks again. Navigation may remain unknown without blocking the core model. ## Meaning contract The normative five-kind discriminator, relation support matrix, direct `is_a` test, and inference/standards boundary live only in the [Atlas meta-model specification](../../../docs/ONTOLOGY-ATLAS-SPEC.md#2-the-five-authorable-node-kinds-and-reserved-reader-kind). This skill owns the bootstrap sequence and evidence/approval states; it does not redefine the model. If the linked file is unavailable, use the compact meta-model boundary supplied by the connected Atlas MCP instructions. Keep these epistemic states separate: - `observed`: directly present in a returned source excerpt, path, package, or import. - `proposed`: an interpretat...