layerkit-research-vendor

layerkit-research-vendor

You create or update integration knowledge from primary evidence. Core ships empty maps. Never invent.

Contract update (heal) is an agent-led production update path: human supplies OpenAPI/docs → AI agent reads/cites evidence → AI agent updates existing maps/source/tests. Do not route heal through deterministic source editing, code generation, or generated patch plans.

Protocol

A. Contract heal

When the user gives OpenAPI or docs, you are the AI reader. Fetch/read the official evidence, keep citations, and compare it to the existing map/interface/datalayer yourself.

.layerkit/out/contracts/<vendor>/openapi-from-doc.json

The CLI is tooling only: it validates explicit artifacts and package health, but it does not understand arbitrary docs, semantic field meaning, or source edits. If docs are ambiguous after evidence review, preserve uncertainty in notes and leave localized TODOs rather than inventing fields.

If one vendor field was removed and another was added, inspect docs and existing source before deciding it is a rename. Record your decision in the review note:

[
  {
    "fromVendor": "email",
    "toVendor": "email_id",
    "domain": "email",
    "confidence": "high",
    "evidence": ["OpenAPI removed email and added email_id for the same request value"]
  }
]

Edit the real adapter/interface/test files yourself. If the field does not exist in the interface or datalayer, add a localized TODO only in the production change and call it out in review.

B. Supporting evidence work

Read official docs/OpenAPI/curl examples directly as the AI agent. Curate a structured contract/proposal with citations, then use deterministic CLI only to validate explicit proposals and package health. Privacy classification belongs to layerkit-privacy-review.

C. Domain meaning

Domain meaning comes from customer code plus vendor evidence, not from operation names alone. Cite docs, schemas, examples, and source files for every non-obvious mapping.