Authoring Bake Product Registry
Purpose
The authoring bake product registry is the contract between editable source content and generated runtime-ready products. Product descriptors say who owns an output, which input lanes invalidate it, which consumers need it, and how diagnostics and fingerprints prove it is current.
Registry Contract
src/authoring_bake/products.rs is the source of truth. src/authoring_bake/products_manifest.json is generated from that source and is read by pack/export tooling. Do not hand-edit the generated manifest.
Each AuthoringBakeProductDescriptor declares:
output_id: stable product ID used in bake manifests and tooling.label: human-readable name for UI and reports.output_path: runtime-cache-relative output path.baker_id: implementation owner for the bake.schema_version: output schema owned by the product.baker_fingerprint: semantic implementation fingerprint.input_domains: input lanes that the product reads.consumers:cli,editor_reload, and/orpack_export.invalidation_keys: source path patterns that trigger rebake.validation_report_label: diagnostics label for bake reports.default_baker_factory: the baker constructor used by the default registry.
Output paths must be normalized, relative paths inside authored asset domains. Descriptor validation rejects empty IDs, duplicate IDs, duplicate output paths, missing input domains, missing consumers, invalid invalidation keys, and keys that do not match an input lane.
Products
| Output ID | Owner | Inputs | Consumers | Output |
|---|---|---|---|---|
quest.catalog.projection |
QuestCatalogProjectionBaker |
quest_catalog |
cli, editor_reload, pack_export |
runtime/quests/quest_catalog_projection.json |
ui.layout.runtime_cache |
UiLayoutRuntimeCacheBaker |
ui_layout_documents |
cli, editor_reload, pack_export |
runtime/ui/ui_layout_runtime_cache.json |
localization.extraction |
LocalizationExtractionBaker |
scene_cutscenes, ui_layout_documents, dialogue_catalog, quest_catalog, game_data_catalog |
cli, pack_export |
runtime/localization/localization_entries.json |
When adding a product, update the descriptor and baker together, then regenerate products_manifest.json. Pack/export reads the manifest, not Rust source, so a descriptor change without a regenerated manifest can make local bakes pass while pack planning still sees old product metadata.
Input Lanes
Input lanes are AuthoringBakeInputLaneDescriptor values. A lane owns three things:
- snapshot loading for the source domain;
- dependency signature loading for cache and rebuild checks;
- invalidation-key matching for source changes.
Current lanes are:
quest_catalog: quest catalog source andquests/*.jsonchanges.ui_layout_documents:.aetheruilayout documents under the UI layout asset domain.dialogue_catalog: dialogue JSON underdialogue/*.json.game_data_catalog: the game-data composition manifest, shards, item-family manifest, and relevant gameplay assets.scene_cutscenes: cutscene data embedded inscenes/*.scene.
Every product input domain should have at least one invalidation key, and every invalidation key should be covered by one of the declared input domains.
Fingerprints And Dependencies
An output rebuilds when its baker fingerprint changes, when its dependency signatures change, or when the previous manifest is missing the output. Bake output records include output ID/path, baker ID, schema version, baker fingerprint, content hash, dependency graph hash, validation hash, source provenance, dependencies, and validation issues.
Use the baker fingerprint for semantic implementation changes that may keep source inputs identical but change output meaning. Use source dependencies and lane signatures for authored content changes. Localization extraction also includes dependency-path information in its runtime fingerprint because its source set spans several domains.
Diagnostics Policy
Bakers attach validation summaries and issues to their output records. The CLI also merges shared authoring diagnostics. Diagnostics are reportable by default and become a hard gate when running with --fail-on-diagnostics.
Use product-specific validation_report_label values so authors can identify the failing output without knowing the baker module name. Diagnostics should point back to source assets, not generated cache files, whenever the source path is known.
Generated Manifests
There are two generated manifest layers:
src/authoring_bake/products_manifest.json: registry metadata generated from product descriptors.authoring_bake_manifest.json: bake-run output metadata generated beside runtime cache outputs.
The products manifest is checked or repaired with:
cargo run -p aether --bin aether-generated-artifact -- --check authoring_bake_products_manifest
cargo run -p aether --bin aether-generated-artifact -- --write authoring_bake_products_manifest
The bake-run manifest is produced by the bake CLI and records the actual outputs, hashes, dependencies, and validation payloads for that run.
Pack And Export Discovery
Pack/export planning reads src/authoring_bake/products_manifest.json, filters products whose consumers include pack_export, prefixes their output paths with the runtime cache root, and includes authoring_bake_manifest.json. Tests in xtask/tests/pack_export_gate.rs verify that pack/export uses the generated manifest, ignores CLI-only products, and rejects missing or malformed manifests.
Run a diagnostic bake before export:
cargo run --bin aether-bake -- --fail-on-diagnostics
Use the pack/export gate when changing products or consumers:
cargo test -p xtask --test pack_export_gate
Steps
- Create or update the baker implementation.
- Register a product descriptor with a stable output ID, output path, schema version, and baker fingerprint.
- Choose the input lanes the baker actually reads.
- Add invalidation keys covered by those lanes.
- Choose consumers; include
pack_exportonly when the product must ship in exported packs. - Regenerate
products_manifest.json. - Run the generated-artifact check, bake diagnostics, and pack/export gate tests.
Expected Outputs
A successful bake-product change produces an updated Rust descriptor, a matching generated src/authoring_bake/products_manifest.json, the product runtime cache output when the baker runs, and an authoring_bake_manifest.json entry that records hashes, dependencies, validation issues, and source provenance for the bake run.
Pack/export should be able to discover every product whose consumers include pack_export, and editor reload should only see products whose consumer list includes editor_reload.
Common Mistakes
- Hand-editing
products_manifest.jsoninstead of regenerating it from descriptors. - Adding a product without an input lane or without invalidation keys covered by that lane.
- Forgetting
pack_exporton a product that must ship in exported content. - Changing output semantics without changing the baker fingerprint.
- Emitting diagnostics against generated output paths instead of authored source paths.
Recovery Paths
If product metadata drifts, run:
cargo run -p aether --bin aether-generated-artifact -- --write authoring_bake_products_manifest
Then run cargo run --bin aether-bake -- --fail-on-diagnostics to confirm the product can bake and cargo test -p xtask --test pack_export_gate when the product is pack/export visible.