go-authcrunch: Skill for Codex

Plugin Development

Select the extension boundary

Production AuthCrunch plugins normally live in separate repositories as independently versioned Go modules. In-repository category references use plugins/<category>/<name>, including synthetic/mock implementations that prove the integration contract. This directory convention is not runtime registration. The two working secrets plugins are ordinary importable packages with explicit constructors. Neither uses Go's plugin.Open, RPC, side-effect registration, or an AuthCrunch plugin SDK. Neither imports go-authcrunch or Caddy. Both declare package secrets, so consumers importing both need distinct aliases.

Keep three responsibilities distinct:

1. Backend library: retrieve or operate on backend data through a focused Go API; own backend configuration, validation, transport, and data conversion.
2. Consumer adapter: select and construct the library, bind backend-specific arguments, satisfy the consumer's interface, and own host registration, placeholder resolution, provisioning, and disposal.
3. AuthCrunch runtime: consume validated configuration and enforce identity, authentication, authorization, and credential semantics in the owning package.

The reusable dependency direction is consumer → adapter → backend library. A consumer can also call a library directly. Importing a module only makes its API available; it does not add a kind to AuthCrunch's configuration dispatch.

The separate static host adapter and AWS host adapter provide concrete evidence of that boundary. Their registration and provisioning are host-framework behavior, not capabilities exported by the backend modules.

Use sqlite-ticket-provider to maintain trusted ticket issuance, browser binding, the optional portal HTTP login hook, and caller-owned root injection with preserved attachment capabilities.