domain-context-graph 0.4.0__tar.gz

domain_context_graph-0.4.0/.github/workflows/publish.yaml

@@ -0,0 +1,74 @@
+name: Publish to PyPI
+
+on:
+  release:
+    types: [published]
+
+permissions:
+  id-token: write
+  contents: read
+
+jobs:
+  test:
+    name: Run tests
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python-version: ["3.10", "3.12"]
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install package with dev dependencies
+        run: pip install -e ".[dev]"
+
+      - name: Run tests
+        run: pytest --tb=short -q
+
+  build:
+    name: Build package
+    needs: test
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Install build tools
+        run: pip install --upgrade build
+
+      - name: Build sdist and wheel
+        run: python -m build
+
+      - name: Verify package version matches release tag
+        run: |
+          PKG_VERSION=$(python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])")
+          TAG_VERSION="${GITHUB_REF_NAME#v}"
+          if [ "$PKG_VERSION" != "$TAG_VERSION" ]; then
+            echo "::error::Version mismatch: pyproject.toml=$PKG_VERSION tag=$TAG_VERSION"
+            exit 1
+          fi
+          echo "Version $PKG_VERSION matches tag"
+
+      - uses: actions/upload-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+  publish:
+    name: Publish to PyPI
+    needs: build
+    runs-on: ubuntu-latest
+    environment: pypi
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+
+      - uses: pypa/gh-action-pypi-publish@release/v1

domain_context_graph-0.4.0/.gitignore

@@ -0,0 +1,13 @@
+__pycache__/
+*.pyc
+*.pyo
+.venv/
+*.egg-info/
+dist/
+build/
+.pytest_cache/
+.coverage
+
+# React/Node
+node_modules/
+*.tsbuildinfo

domain_context_graph-0.4.0/AGENTS.md

@@ -0,0 +1,92 @@
+# DCG Development Guide
+
+## Project
+
+`domain-context-graph` (import as `dcg`) — a Wikibase-compatible knowledge graph protocol for grounding AI in verified domain knowledge. Python >=3.10, built with hatchling.
+
+## Setup
+
+```bash
+python -m venv .venv
+.venv/bin/pip install -e ".[dev,ui,ingest]"
+```
+
+## Data Sources
+
+DCG operates in two modes. Always use the right one:
+
+- **Single project** (`--project <path>`) — a directory containing `graph_card.json` (metadata) and `graphs/default.json` (graph data). Use for isolated domain graphs.
+- **Stack manifest** (`--stack <path/to/dcg-stack.yml>`) — composes multiple project directories as layers with cross-layer resolution. Manifests support multi-parent `extends` (list) and a `joins` section for cross-layer join rules. Use when working with multi-layer graphs (e.g., security + product + code).
+
+The `--stack` path is relative to the manifest file's parent directory for layer `source` fields.
+
+## CLI Commands
+
+```
+dcg init <name> [--path .] [--description ""]    # Create a new domain project
+dcg compose <manifest>                            # Validate/inspect a stack manifest
+dcg compact <path>                                # Compact layers in a project
+dcg query <path> [--type Function] [--domain X]   # Query entities (single project)
+dcg ui [<path>] [--stack <manifest>] [--port 8080] # Launch graph explorer web UI
+```
+
+`dcg ui` accepts either a positional project path or `--stack` (mutually exclusive). At least one is required.
+
+## MCP Server
+
+```
+dcg-mcp --project <path>                    # Single project
+dcg-mcp --stack <manifest> [--layer <name>] # Stack mode
+dcg-mcp --stack <manifest> --no-strict      # Skip strict ontology validation
+```
+
+`--project` and `--stack` are mutually exclusive and required. The `--no-strict` flag disables strict ontology validation — use it for read-only access to data that may not meet current strict rules. The UI passes this automatically for stack mode.
+
+## Architecture
+
+```
+src/dcg/
+  core/         # GraphStore, ontology, compose (DcgStack, JoinRule), merge, UID generation
+  mcp/          # MCP server (FastMCP), tools (query, ingest, stack, project)
+  ops/          # Higher-level operations: ingest pipelines, lifecycle, ontology mgmt
+  ui/           # NiceGUI web explorer — app, MCP client, transform, components
+  cli.py        # CLI entry point
+  project.py    # DomainProject — file-based persistence (graph_card.json + graphs/)
+```
+
+### Key classes
+
+- `GraphStore` — in-memory graph with entities, relations, layered history
+- `DomainProject` — manages a project directory (`graph_card.json` for metadata + `graphs/` for graph data)
+- `DcgStack` — composes multiple projects as layers; `from_project()` wraps a single project as a 1-layer stack
+- `JoinRule` — declarative cross-layer join rule; cross-layer relations are materialized at stack level, not stored in layer data
+- `McpClient` (ui) — async stdio MCP client wrapper; uses `_call()` for single values, `_call_list()` for lists (FastMCP splits list returns into one TextContent per element)
+
+### Entity/relation format
+
+- Entity UID: `dcg:sha256:<hash>` (content-addressed) or `dcg:meta:<Name>` (type definitions)
+- Relation UID: `dcg:rel:sha256:<hash>`
+- Entity: `{"id": str, "label": str, "description": str, "attributes": [{"property": str, "ref"|"string"|"quantity": value}]}`
+- Relation: `{"dcg:type": "relation", "uid": str, "source": str, "target": str, "property": str}`
+
+## Testing
+
+```bash
+.venv/bin/pytest                    # Run all tests
+.venv/bin/pytest tests/unit/ -v     # Verbose
+.venv/bin/pytest -k test_compose    # Filter by name
+```
+
+Tests live in `tests/unit/`. No conftest.py — fixtures are defined per-file. Async tests use `pytest-asyncio` with `mode=strict`.
+
+## Rules
+
+- **`graph_card.json` is metadata-only.** It holds project name, description, and ontology declarations. Entities and relations live in `graphs/default.json` (and other named graphs). Never store graph data in `graph_card.json`.
+- **No `ontology.yaml`.** Ontology definitions are inlined in `graph_card.json` under the `ontology` key. The separate `ontology.yaml` file has been removed.
+- **Stack ontology loads before project data.** `DcgStack.load()` injects the manifest's ontology declarations into each project's store before calling `project.load()`. This is load-order sensitive — do not move ontology injection after project loading.
+- **Cross-layer relations are read-only.** They are materialized at stack level from `JoinRule` definitions in the manifest's `joins` section. Do not store cross-layer relations in individual layer data.
+- **Stack manifests support multi-parent `extends`.** The `extends` field in a layer entry accepts either a single string or a list of layer names. Resolution follows BFS topological order; DAG cycles are rejected at load time.
+- **FastMCP list serialization quirk.** MCP tools returning `list[dict]` are split into one TextContent per element, not a single JSON array. The `McpClient._call_list()` method handles this. Use `_call()` for single-value returns, `_call_list()` for list returns.
+- **`DomainProject.load()` does not restore layers.** Only entities and relations are loaded from `graphs/default.json`. Layer history is not persisted through load/save cycles.
+- **No backward compatibility before v1.0.** Breaking changes are expected. No deprecation shims or re-exports for removed code.
+- **Internal docs go in the workspace.** Specs, plans, and design docs belong in `projects/dcg/` at the workspace root — not in this repo. Only public-facing documentation goes here.

domain_context_graph-0.4.0/PKG-INFO

@@ -0,0 +1,186 @@
+Metadata-Version: 2.4
+Name: domain-context-graph
+Version: 0.4.0
+Summary: Domain Context Graph protocol for grounding AI in verified domain knowledge.
+License-Expression: Apache-2.0
+Keywords: ai-grounding,domain-graph,domain-model,graph-protocol,llm-context
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: Apache Software License
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Database :: Database Engines/Servers
+Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
+Requires-Python: >=3.10
+Requires-Dist: mcp>=1.27
+Requires-Dist: pyyaml>=6.0
+Provides-Extra: dev
+Requires-Dist: pytest-cov>=4.0; extra == 'dev'
+Requires-Dist: pytest>=7.0; extra == 'dev'
+Provides-Extra: ingest
+Requires-Dist: requests>=2.28; extra == 'ingest'
+Provides-Extra: ui
+Description-Content-Type: text/markdown
+
+# Domain Context Graph (DCG)
+
+**An open protocol for structuring domain knowledge so AI systems reason about your product — not just your code.**
+
+---
+
+## The Problem
+
+AI coding assistants write confident code that violates business rules nobody documented. Security scanners flag vulnerabilities without knowing which domain owns the affected service. Incident responders trace call graphs without understanding blast radius across business capabilities.
+
+- **LLM training data is generic.** Models know what "payments" means in general — not what *your* Payments domain is, who owns it, or what depends on it.
+- **Code graphs capture structure, not semantics.** They see imports and call chains — not that two modules serve the same bounded context.
+- **Documentation decays instantly.** Wikis are stale, unstructured, and not machine-queryable.
+- **Knowledge is tool-siloed.** Your security scanner's vulnerability data can't connect to your code graph's ownership data because there's no shared schema.
+
+DCG fills this gap: a **standard, machine-readable protocol** for domain knowledge that any AI system can consume — versioned, git-backed, and federated across teams and repos.
+
+## Core Concepts
+
+- **Wikibase-compatible entities** — same JSON format used by Wikidata's 100M+ items. Labels, descriptions, aliases, and attributes with full snak structure.
+- **Content-addressed identity** — entity UIDs are deterministic hashes (`dcg:sha256:...`). Same entity always gets the same ID, regardless of who creates it or when.
+- **Two-axis classification** — every entity has a structural type (`instance of` Function/Class/Endpoint) and domain membership (`part of` Payments/Security). These are orthogonal.
+- **Retraction and purge** — entities can be retracted (soft-deleted) and later permanently purged from the graph.
+- **Composition** — stack multiple domain graphs via `dcg-stack.yml` manifests with `extends` chains. Query across layers; entities resolve upward through the chain.
+- **Federation** — multiple graphs reference each other's entities via cross-graph resolution. Each team owns their graph independently.
+
+## Install
+
+```bash
+pip install domain-context-graph
+```
+
+With git-backed persistence:
+
+```bash
+pip install domain-context-graph[git]
+```
+
+## Quick Start
+
+```python
+from dcg.core import GraphStore, entity_uid, builders as kb
+
+store = GraphStore()
+
+# Define a domain
+payments_uid = entity_uid(name="Payments")
+store.add_entity(kb.entity(
+    uid=payments_uid,
+    label="Payments",
+    description="Payment processing domain",
+    attributes=[kb.attribute("instance of", kb.ref_value("dcg:meta:Domain"))],
+))
+
+# Place a code entity in that domain
+fn_uid = entity_uid(name="charge_card", path="src/payments/charge.py")
+store.add_entity(kb.entity(
+    uid=fn_uid,
+    label="charge_card",
+    attributes=[
+        kb.attribute("instance of", kb.ref_value("dcg:meta:Function")),
+        kb.attribute("part of", kb.ref_value(payments_uid)),
+        kb.attribute("file path", kb.string_value("src/payments/charge.py")),
+    ],
+))
+
+# Query
+functions = store.query(instance_of="dcg:meta:Function")
+```
+
+## CLI
+
+```bash
+dcg init <name> [--path .] [--description "..."]   # Create a new domain graph project
+dcg serve --project <path>                          # Start MCP server (single project)
+dcg serve --stack <manifest>                        # Start MCP server (multi-layer stack)
+dcg compose <manifest>                              # Validate a dcg-stack.yml manifest
+dcg purge <path>                                    # Remove retracted entities and relations
+dcg query <path> [--type Function] [--domain Pay]   # Query entities
+```
+
+## MCP Server
+
+DCG includes a built-in [Model Context Protocol](https://modelcontextprotocol.io) server with 28 tools for reading, writing, and querying domain graphs.
+
+```bash
+# Single project
+dcg serve --project ./my-graph
+
+# Multi-layer stack (cross-layer queries)
+dcg serve --stack ./dcg-stack.yml
+```
+
+Tools include `dcg_create_entity`, `dcg_create_domain`, `dcg_connect`, `dcg_query`, `dcg_snapshot`, `dcg_bulk_add`, and more. Stack-mode adds `dcg_stack_info`, `dcg_query_stack`, and `dcg_resolve_cross_layer`.
+
+## Composition
+
+Stack multiple domain graphs with a `dcg-stack.yml` manifest:
+
+```yaml
+stack: my-appsec-stack
+layers:
+  - name: security
+    source: ./graphs/security-domain
+
+  - name: product
+    source: ./graphs/product-domain
+    extends: security
+
+  - name: code
+    source: ./graphs/code
+    extends: product
+```
+
+The `extends` chain defines resolution order. When querying the `code` layer for an entity, DCG walks `code` → `product` → `security` until found. Cross-layer queries deduplicate by UID (nearest layer wins).
+
+## Package Structure
+
+```
+src/dcg/
+  __init__.py              # Public API re-exports
+  cli.py                   # CLI entry point (dcg command)
+  project.py               # DomainProject — manifest-based project manager
+  core/
+    uid.py                 # Content-addressed entity/relation IDs
+    model.py               # Entity, Relation, Attribute dataclasses
+    ontology.py            # Type and property registries
+    builders.py            # Wikibase JSON entity/attribute construction
+    store.py               # GraphStore — in-memory implementation
+    compose.py             # DcgStack — multi-project composition
+    federation.py          # Cross-graph registry and resolution
+    purge.py               # Retraction purge
+    git_store.py           # GitGraphStore — dulwich-backed persistence
+  mcp/
+    server.py              # FastMCP server (28 tools)
+    helpers.py             # Shared MCP utilities
+```
+
+## Specification
+
+| Document | Description |
+|----------|-------------|
+| [RFC DCG-002](spec/rfc.md) | Formal protocol specification (IETF RFC 2119). Defines Core, Persistent, and Federated conformance levels. |
+| [Design Spec](spec/design.md) | Full architecture, entity model, ontology, and integration patterns. |
+
+The RFC is the authoritative source. This Python package is one implementation — others can implement the same spec in any language.
+
+## Extensibility
+
+- **Custom domains** — `register_global_type()` to add domain-specific types
+- **Custom properties** — `register_property()` with Wikidata P-ID aliases
+- **Custom backends** — implement `GraphStoreProtocol` for any storage
+- **Federation** — implement `GraphRegistry` and `BoundaryResolver` for cross-graph resolution
+
+## Related Projects
+
+| Project | Description |
+|---------|-------------|
+| [appsec-ctx-graph](https://github.me/atishio/appsec-ctx-graph) | 3-layer security + product + code domain graph built on DCG |
+
+## License
+
+Apache-2.0

domain_context_graph-0.4.0/README.md

@@ -0,0 +1,163 @@
+# Domain Context Graph (DCG)
+
+**An open protocol for structuring domain knowledge so AI systems reason about your product — not just your code.**
+
+---
+
+## The Problem
+
+AI coding assistants write confident code that violates business rules nobody documented. Security scanners flag vulnerabilities without knowing which domain owns the affected service. Incident responders trace call graphs without understanding blast radius across business capabilities.
+
+- **LLM training data is generic.** Models know what "payments" means in general — not what *your* Payments domain is, who owns it, or what depends on it.
+- **Code graphs capture structure, not semantics.** They see imports and call chains — not that two modules serve the same bounded context.
+- **Documentation decays instantly.** Wikis are stale, unstructured, and not machine-queryable.
+- **Knowledge is tool-siloed.** Your security scanner's vulnerability data can't connect to your code graph's ownership data because there's no shared schema.
+
+DCG fills this gap: a **standard, machine-readable protocol** for domain knowledge that any AI system can consume — versioned, git-backed, and federated across teams and repos.
+
+## Core Concepts
+
+- **Wikibase-compatible entities** — same JSON format used by Wikidata's 100M+ items. Labels, descriptions, aliases, and attributes with full snak structure.
+- **Content-addressed identity** — entity UIDs are deterministic hashes (`dcg:sha256:...`). Same entity always gets the same ID, regardless of who creates it or when.
+- **Two-axis classification** — every entity has a structural type (`instance of` Function/Class/Endpoint) and domain membership (`part of` Payments/Security). These are orthogonal.
+- **Retraction and purge** — entities can be retracted (soft-deleted) and later permanently purged from the graph.
+- **Composition** — stack multiple domain graphs via `dcg-stack.yml` manifests with `extends` chains. Query across layers; entities resolve upward through the chain.
+- **Federation** — multiple graphs reference each other's entities via cross-graph resolution. Each team owns their graph independently.
+
+## Install
+
+```bash
+pip install domain-context-graph
+```
+
+With git-backed persistence:
+
+```bash
+pip install domain-context-graph[git]
+```
+
+## Quick Start
+
+```python
+from dcg.core import GraphStore, entity_uid, builders as kb
+
+store = GraphStore()
+
+# Define a domain
+payments_uid = entity_uid(name="Payments")
+store.add_entity(kb.entity(
+    uid=payments_uid,
+    label="Payments",
+    description="Payment processing domain",
+    attributes=[kb.attribute("instance of", kb.ref_value("dcg:meta:Domain"))],
+))
+
+# Place a code entity in that domain
+fn_uid = entity_uid(name="charge_card", path="src/payments/charge.py")
+store.add_entity(kb.entity(
+    uid=fn_uid,
+    label="charge_card",
+    attributes=[
+        kb.attribute("instance of", kb.ref_value("dcg:meta:Function")),
+        kb.attribute("part of", kb.ref_value(payments_uid)),
+        kb.attribute("file path", kb.string_value("src/payments/charge.py")),
+    ],
+))
+
+# Query
+functions = store.query(instance_of="dcg:meta:Function")
+```
+
+## CLI
+
+```bash
+dcg init <name> [--path .] [--description "..."]   # Create a new domain graph project
+dcg serve --project <path>                          # Start MCP server (single project)
+dcg serve --stack <manifest>                        # Start MCP server (multi-layer stack)
+dcg compose <manifest>                              # Validate a dcg-stack.yml manifest
+dcg purge <path>                                    # Remove retracted entities and relations
+dcg query <path> [--type Function] [--domain Pay]   # Query entities
+```
+
+## MCP Server
+
+DCG includes a built-in [Model Context Protocol](https://modelcontextprotocol.io) server with 28 tools for reading, writing, and querying domain graphs.
+
+```bash
+# Single project
+dcg serve --project ./my-graph
+
+# Multi-layer stack (cross-layer queries)
+dcg serve --stack ./dcg-stack.yml
+```
+
+Tools include `dcg_create_entity`, `dcg_create_domain`, `dcg_connect`, `dcg_query`, `dcg_snapshot`, `dcg_bulk_add`, and more. Stack-mode adds `dcg_stack_info`, `dcg_query_stack`, and `dcg_resolve_cross_layer`.
+
+## Composition
+
+Stack multiple domain graphs with a `dcg-stack.yml` manifest:
+
+```yaml
+stack: my-appsec-stack
+layers:
+  - name: security
+    source: ./graphs/security-domain
+
+  - name: product
+    source: ./graphs/product-domain
+    extends: security
+
+  - name: code
+    source: ./graphs/code
+    extends: product
+```
+
+The `extends` chain defines resolution order. When querying the `code` layer for an entity, DCG walks `code` → `product` → `security` until found. Cross-layer queries deduplicate by UID (nearest layer wins).
+
+## Package Structure
+
+```
+src/dcg/
+  __init__.py              # Public API re-exports
+  cli.py                   # CLI entry point (dcg command)
+  project.py               # DomainProject — manifest-based project manager
+  core/
+    uid.py                 # Content-addressed entity/relation IDs
+    model.py               # Entity, Relation, Attribute dataclasses
+    ontology.py            # Type and property registries
+    builders.py            # Wikibase JSON entity/attribute construction
+    store.py               # GraphStore — in-memory implementation
+    compose.py             # DcgStack — multi-project composition
+    federation.py          # Cross-graph registry and resolution
+    purge.py               # Retraction purge
+    git_store.py           # GitGraphStore — dulwich-backed persistence
+  mcp/
+    server.py              # FastMCP server (28 tools)
+    helpers.py             # Shared MCP utilities
+```
+
+## Specification
+
+| Document | Description |
+|----------|-------------|
+| [RFC DCG-002](spec/rfc.md) | Formal protocol specification (IETF RFC 2119). Defines Core, Persistent, and Federated conformance levels. |
+| [Design Spec](spec/design.md) | Full architecture, entity model, ontology, and integration patterns. |
+
+The RFC is the authoritative source. This Python package is one implementation — others can implement the same spec in any language.
+
+## Extensibility
+
+- **Custom domains** — `register_global_type()` to add domain-specific types
+- **Custom properties** — `register_property()` with Wikidata P-ID aliases
+- **Custom backends** — implement `GraphStoreProtocol` for any storage
+- **Federation** — implement `GraphRegistry` and `BoundaryResolver` for cross-graph resolution
+
+## Related Projects
+
+| Project | Description |
+|---------|-------------|
+| [appsec-ctx-graph](https://github.me/atishio/appsec-ctx-graph) | 3-layer security + product + code domain graph built on DCG |
+
+## License
+
+Apache-2.0

domain_context_graph-0.4.0/TODO.md

@@ -0,0 +1,17 @@
+# DCG — TODO
+
+## dcg CLI (`~/Documents/kit/dcg`)
+
+### Remove hardcoded `dcg ingest`
+
+**Why:** `dcg ingest` is not generic — it has Wikidata SPARQL queries and the entire Gartner WAAP taxonomy hardcoded in `src/dcg/ingest.py`. It only produces a security domain graph and cannot be configured for other domains.
+
+**What to do:**
+
+- [ ] Remove `ingest.py` from `src/dcg/`
+- [ ] Remove the `ingest` subcommand from the CLI entrypoint
+- [ ] Remove the `requests` optional dependency (`domain-context-graph[ingest]`)
+- [ ] Move Wikidata+WAAP import logic into `dcg-security-domain` repo as a standalone bootstrap script (e.g., `scripts/bootstrap.py`) — that's where domain-specific seeding belongs
+- [ ] Update `dcg --help` / README to reflect removal
+
+**Principle:** `dcg` CLI should be domain-agnostic. Domain-specific data sources belong in the domain project repos, not in the core tool.

domain_context_graph-0.4.0/pyproject.toml

@@ -0,0 +1,43 @@
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[project]
+name = "domain-context-graph"
+version = "0.4.0"
+description = "Domain Context Graph protocol for grounding AI in verified domain knowledge."
+readme = "README.md"
+license = "Apache-2.0"
+requires-python = ">=3.10"
+dependencies = [
+    "pyyaml>=6.0",
+    "mcp>=1.27",
+]
+keywords = ["domain-graph", "ai-grounding", "llm-context", "graph-protocol", "domain-model"]
+classifiers = [
+    "Development Status :: 3 - Alpha",
+    "Intended Audience :: Developers",
+    "License :: OSI Approved :: Apache Software License",
+    "Programming Language :: Python :: 3",
+    "Topic :: Scientific/Engineering :: Artificial Intelligence",
+    "Topic :: Database :: Database Engines/Servers",
+]
+
+[project.optional-dependencies]
+ingest = ["requests>=2.28"]
+ui = []
+dev = [
+    "pytest>=7.0",
+    "pytest-cov>=4.0",
+]
+
+[project.scripts]
+dcg = "dcg.cli:main"
+dcg-mcp = "dcg.mcp:main"
+dcg-ingest-mcp = "dcg.mcp.dcg_ingest_mcp:main"
+
+[tool.hatch.build.targets.wheel]
+packages = ["src/dcg"]
+
+[tool.pytest.ini_options]
+testpaths = ["tests"]

domain_context_graph-0.4.0/src/dcg/__init__.py

@@ -0,0 +1,41 @@
+"""DCG — Domain Context Graph."""
+
+from dcg.core import (
+    entity_uid,
+    relation_uid,
+    Entity,
+    Relation,
+    SCHEMA_VERSION,
+    TYPE_REGISTRY,
+    PROPERTY_REGISTRY,
+    register_global_type,
+    register_property,
+    register_alias,
+    resolve_property,
+    GraphStore,
+    GraphStoreProtocol,
+    StackLoader,
+    DomainProject,
+    purge_retracted,
+    builders,
+)
+
+__all__ = [
+    "entity_uid",
+    "relation_uid",
+    "Entity",
+    "Relation",
+    "SCHEMA_VERSION",
+    "TYPE_REGISTRY",
+    "PROPERTY_REGISTRY",
+    "register_global_type",
+    "register_property",
+    "register_alias",
+    "resolve_property",
+    "GraphStore",
+    "GraphStoreProtocol",
+    "StackLoader",
+    "DomainProject",
+    "purge_retracted",
+    "builders",
+]

domain_context_graph-0.4.0/src/dcg/adapters/__init__.py

@@ -0,0 +1,8 @@
+"""DCG adapters — pluggable backends for loading layers from external sources."""
+from .base import AdapterProxy, LayerAdapterProtocol
+from .graphify import GraphifyAdapter
+from .registry import register
+
+register("graphify", GraphifyAdapter)
+
+__all__ = ["AdapterProxy", "GraphifyAdapter", "LayerAdapterProtocol"]