# Package-generated Go adapters v1

Packages may generate typed adapters for a game's engine bindings through an
explicit build processor. The package owns its implementation and templates;
the CLI supplies generic confined output handling. No engine-specific package
knowledge is required.

The existing bounded KPR1 request/response envelope remains unchanged. A
selected processor can read authored inputs such as the project's `go.mod`
and return files with paths beginning `go/`. These are Go source outputs:
`go/controller/player.go` from `controllers-3d.sdk` is published at
`.karty/processed/code/controllers-3d.sdk/controller/player.go`. The game's
module can import that package alongside its generated `.karty/engine` bindings.

The CLI parses and formats source, requires ordinary non-test `.go` files and
consistent package declarations within each directory, and adds a generated
ownership header. Module/workspace files and paths escaping the processor's
namespace are rejected. Existing response size/file bounds and output ownership
checks apply. Other paths retain their existing embedded-resource semantics.

All processor code, resources and generated assets are staged together. Invalid
source or any failed processor leaves the previous complete generated output
intact. Removing a processor removes its old generated source during the same
owned publication. User-owned `src/` files and immutable package archives are
never modified by adapter generation.

Import, export and restore do not execute processors. A game opts in through
`[[build.processors]]`; normal builds and development previews then regenerate
the adapter. The package version and archive SHA-256 pin the generator and its
templates. Changes to controller policy therefore require a package release,
while generic engine lifecycle, input, camera and physics contracts remain
independent.