What a Domain Pack is

PartialThe contract and loader work, with tests. No pack has been installed live yet.

A Domain Pack adapts the base platform to one vertical: a repair shop, a clinic, a retail store.

Why it exists

The platform has the machinery: ledger, verification, idempotency. But nobody buys “there is a ledger” — they buy “it works for my business out of the box”.

The Domain Pack is that “out of the box”.

What it contains

{
  "id": "texnik-servis",
  "version": "1.0.0",
  "display_name": "Technical service — intake, sales and payment",
  "domain": "texnik-servis",
  "connectors":   [ { "id": "bitrix24", "min_version": "2.1.0" } ],
  "capabilities": [ ],
  "read_tools":   [ ]
}

Section	What
`connectors`	Connectors the pack requires, with minimum versions
`capabilities`	Business write operations plus verification rules
`read_tools`	Read tools the agent may call

⚠ Capabilities are writes only

capabilities  →  write operations (REVERSIBLE | IRREVERSIBLE)
read_tools    →  read operations

A read needs no ledger entry and would only bloat the catalogue. That is why side_effect: NONE does not exist in the pack schema.

A capability entry

{
  "id": "service.order.create",
  "tools": ["connector.bitrix24.crm.create_lead"],
  "side_effect": "REVERSIBLE",
  "resource_param": "external_id",
  "verification": {
    "operation": "crm.get_lead",
    "business_key": "id",
    "expect": { "field": "status_id", "in": ["NEW", "IN_PROCESS"] },
    "max_wait_ms": 15000,
    "on_missing": "UNKNOWN"
  }
}

Three hard rules

Capability IDs are forever

⚡ The capability_id feeds the semantic key. Changing it breaks idempotency: old records point at the old id, a new request arrives under the new id and creates a duplicate effect.

Change	Version
Adding a capability	MINOR
Removing or renaming one	MAJOR

Writing a pack — step by step
The verification block