Generated package structure
A generated Graft package contains Caller-side code, not the Receiver implementation.
Responsibilities
- generated classes/models matching the exposed callable surface;
- generated method wrappers that invoke Hypertube;
GraftConfigand its generated defaults;- target package metadata;
- target runtime dependencies or references;
- declarations/types required by the Caller ecosystem.
Every generated Caller package includes a GraftConfig (or equivalent) type. Field naming follows
the target language—PascalCase static fields in .NET, lower-case fields in Node.js, class attributes in
Python, and analogous patterns elsewhere. Copy the exact shape from Vision.
GraftConfig.Host = "inmemory";GraftConfig.Stateless = false;
- package name and scope;
- registry/feed/repository URL;
- package version;
- generated namespace/import path;
- source-to-target method casing;
- exact file layout;
- whether runtime dependencies are transitive in the current Alpha.
Read these values from current Gateway/Vision output and the installed artifact. Do not edit generated files as the source of truth; change the Receiver contract and regenerate.
Normal runtime calls do not regenerate the package. They use installed wrappers and resolved configuration to invoke the Receiver.
This reference describes responsibilities shared by generated packages. It is not an ABI or file-layout guarantee across releases.