packages

func (*Packages) AppendGoLanguage ¶

func (p *Packages) AppendGoLanguage() error

func (*Packages) Init ¶

func (p *Packages) Init() error

func (*Packages) WriteLibs ¶

func (p *Packages) WriteLibs(names []string) error

WriteLibs delivers the named capability libraries into common/go. It's how a preset apply seeds a reusable building block (jwtx, …) the preset depends on, so the lib is then importable by hand from any service in the project — not locked inside the preset's overlay. Unknown names are an error; existing files are left untouched (user-owned once written).

func (*Packages) WriteStarterPackages ¶

func (p *Packages) WriteStarterPackages() error

WriteStarterPackages drops the seed packages under common/go and runs `go mod tidy` so the module's go.mod/go.sum reflect their imports. The seed source lives at internal/scaffold/commongo/ — real Go files so gopls validates them in maestro's author-mode and so future presets can `import "<usermodule>/common/go/<pkg>"` and have the import resolve under the maestro repo too. The writer copies the embedded tree into the user's project on init.

Two flavours of package ship there:

• Domain primitives — logger, ids, errs. The smallest set of cross-service concepts every project ends up writing. Keeping them in common/go from day one means no service has to reinvent them and no team has to debate where they live.
• Runtime helpers — httpx, grpcx, envx. They wrap the boilerplate each service main.go would otherwise duplicate (ListenAndServe
• graceful shutdown, the equivalent for gRPC, the envOr helper). With them in common/go a typical service main is ~15 lines, not ~50.

All of these are deliberately small. They are starting points, not frameworks: once they ship into a project they are user-owned and the team is expected to evolve them. Existing files in the target tree are left alone on re-runs of init.