2 bake product registry
forgejo-actions edited this page 2026-07-11 10:33:50 +00:00

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/or pack_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 and quests/*.json changes.
  • ui_layout_documents: .aetherui layout documents under the UI layout asset domain.
  • dialogue_catalog: dialogue JSON under dialogue/*.json.
  • game_data_catalog: the game-data composition manifest, shards, item-family manifest, and relevant gameplay assets.
  • scene_cutscenes: cutscene data embedded in scenes/*.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

  1. Create or update the baker implementation.
  2. Register a product descriptor with a stable output ID, output path, schema version, and baker fingerprint.
  3. Choose the input lanes the baker actually reads.
  4. Add invalidation keys covered by those lanes.
  5. Choose consumers; include pack_export only when the product must ship in exported packs.
  6. Regenerate products_manifest.json.
  7. 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.json instead of regenerating it from descriptors.
  • Adding a product without an input lane or without invalidation keys covered by that lane.
  • Forgetting pack_export on 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.