2026-09-23·by Sijie Wang#standmeet#architecture#design

connector-diagram-coverage

Connector — diagram coverage (registry side vs caller side)

Parent: connector

The connector module is two designs sharing one package: the registry side (how a connector gets installed, credentialed, activated) and the caller side (how a consumer invokes a category verb without ever seeing a provider or a credential). One diagram would blur exactly the boundary the module exists to enforce — so, two.

1 · Registry side — install, credential, activate

The registry side is the ONLY place credentials are plaintext, and only transiently. Everything downstream of Hub.Resolve sees a Connector — name, kind, connected; nothing else.

2 · Caller side — category verbs, no provider, no creds

The caller's world contains no provider names and no credentials — the proxy interfaces are the whole vocabulary. AuthInjector is constructed inside the package at call time; the consumer cannot even name it.

Coverage checklist (anti-omission gate)

type / areadiagrammed atverified
Hub, Connector, Verifierthis page §1✓ code
connector.Service responsibilities (was connectorsvc until 2026-07-26, 1bc9ba8b0)this page §1✓ names, ☐ full signatures
cryptobox / owner_connectorsthis page §1✓ mechanism, ☐ column list
CalendarProxy / MailProxy + DTOsthis page §2, connector-plugins✓ code
openapi Runtime / AuthInjector / StatusErrorthis page §2✓ code
DepProvider / DepRegistry / RequiresDepsconnector-deps✓ code
ingest (spec parse, binding validate)☐ not yet diagrammed
egress guard typesconnector-egress-guard (prose)☐ no class diagram
about this entry

One of sijie's wiki entries. The AI on this site is grounded in the same corpus and answers in sijie's voice, with citations back to entries like this one — answering costs sijie money, so it waits behind a code: enter an access code →

connector-diagram-coverage