Registry i bindingi

urirun oddziela kontrakt pakietu od drzewa lookup runtime.

Dokument bindingów

Dokument bindingów to przenośny JSON. Opisuje trasy URI, schematy wejścia i konfigurację adaptera.

{
  "version": "urirun.bindings.v2",
  "bindings": {
    "report://local/render/pdf": {
      "kind": "command",
      "adapter": "argv-template",
      "inputSchema": {
        "type": "object",
        "required": ["input", "output"],
        "properties": {
          "input": { "type": "string" },
          "output": { "type": "string" }
        },
        "additionalProperties": false
      },
      "argv": ["python3", "render.py", "{input}", "{output}"]
    }
  }
}

Registry

Registry kompiluje się z jednego lub wielu dokumentów bindingów:

urirun compile bindings.v2.json --out registry.json

Runtime używa registry jako drzewa lookup: pełny URI wskazuje adapter, schemat wejścia, target i metadane źródła.

Tożsamość trasy

Liczy się pełny URI. Trasa taka jak:

device://device-01/led/command/set

może współistnieć z:

device://device-02/led/command/set

Jeżeli dwa źródła generują identyczny pełny URI, kompilacja powinna zatrzymać proces albo wymagać jawnego wyboru źródła.

Polityka konfliktów

Wygenerowane bindingi powinny być deterministyczne:

• jawne pliki urirun.bindings.v2.json mają pierwszeństwo przed trasami wywnioskowanymi ze skryptów lub paczek
• zduplikowane pełne URI powinny nie przejść walidacji, chyba że skaner oznaczy je jako to samo źródło
• pliki generowane zapisuj do generated/ lub .urirun/, nie edytuj jako źródła podstawowego
• każdy wygenerowany binding powinien wskazywać artefakt źródłowy: Dockerfile, package.json, pyproject.toml, Makefile lub skrypt

Taki układ pozwala odtwarzać registry w CI i porównywać zmiany przed wdrożeniem.