Documentation
¶
Overview ¶
Package catalog loads and validates the usecase catalog embedded in the binary (catalog.yml): the server's well-known bundles, grouped into usecases a client sets up with one call, dependencies included.
A usecase is a set of bundles installed together plus the usecases it requires; every bundle is one created root under a permanent `system:<name>/v<n>` id, declaring a type objects carry, a miniapp the client opens, records on the root, or several of those. Client contract: docs/28-well-known-bundles.md.
Validation here is structural and pure — ids, handles, the dependency graph, relation links, module rules — and collects every problem rather than the first, with its yaml path. What needs the server's descriptor gate (slug against kind, option shapes, miniapp values) is layered on top by the server package; both run at boot, in `make test` and in `make catalog-validate`.
Index ¶
Constants ¶
const ( CodeBadYAML = "catalog.bad_yaml" CodeUnknownField = "catalog.unknown_field" CodeBadId = "catalog.bad_id" CodeDuplicate = "catalog.duplicate" CodeMissing = "catalog.missing" CodeBadField = "catalog.bad_field" CodeUnknownUsecase = "catalog.unknown_usecase" CodeCycle = "catalog.cycle" CodeBrokenLink = "catalog.broken_link" CodeBadMiniapp = "catalog.bad_miniapp" )
Problem codes.
const BundleIdPattern = "system:<name>/v<n>"
BundleIdPattern is the grammar of a catalog bundle id, for messages.
Variables ¶
This section is empty.
Functions ¶
func Load ¶
Load decodes a catalog and runs the pure validation, returning every finding. The catalog is nil only when the source did not decode; with structural problems it is still returned, so a caller layering more checks on top can report everything in one pass — but Get and Order are trustworthy only when Problems is empty.
Types ¶
type Catalog ¶
type Catalog struct {
Usecases []api.CatalogUsecase
// contains filtered or unexported fields
}
Catalog is a loaded, structurally valid catalog.
type Options ¶
type Options struct {
// KnownTypeIds are the registered (built-in) type and collection
// ids of the server: reserved against catalog xKeys, and valid
// relation targets. `any`, `type` and `collection` are always
// included.
KnownTypeIds []string
// RootTypeIds are the registered type ids a bare bundle root may
// name as its `rootType`.
RootTypeIds []string
}
Options tune the pure validation with what only the server knows.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
cmd
|
|
|
catalog-validate
command
catalog-validate checks the usecase catalog embedded in the binary and any candidate files given as arguments, printing one line per problem (`<source>: <path>: <code>: <message>`) and exiting 1 on any.
|
catalog-validate checks the usecase catalog embedded in the binary and any candidate files given as arguments, printing one line per problem (`<source>: <path>: <code>: <message>`) and exiting 1 on any. |