1 gameplay system slice scaffold
forgejo-actions edited this page 2026-07-15 12:43:13 +00:00

Gameplay System Slice Scaffold

Purpose

The gameplay-system slice scaffold turns a new gameplay domain into a repeatable implementation plan. Use it when a feature is large enough to need authored data, runtime rules, validation, editor references, preview projection, and tests instead of a single isolated module.

Steps

  1. Choose a stable lower-snake-case domain id and a human label.
  2. Run a dry run with cargo run --bin aether_gameplay_slice -- --domain <id> --label "<Label>".
  3. Review the generated surface list: types, catalog, runtime, validation, projection, editor contributor, and tests.
  4. Add --feature <name> for first-pilot capabilities that should be named in the manifest snippet.
  5. Rerun with --write only after the file plan and module root look correct.
  6. Paste the generated manifest snippet into the gameplay-system registry and implement the executable hooks.

Expected Outputs

The CLI produces a markdown plan, a domain module facade, surface starter files, a starter authored catalog asset, a contributor-facing checklist, executable hook registrations, and a manifest snippet. A valid plan has no request validation issues and declares every required gameplay-system surface.

Common Mistakes

Common mistakes include using a non-snake-case domain id, putting the module root outside src/<domain>, treating generated files as complete implementation, skipping the manifest registration, or leaving command descriptor and conformance-test hooks unowned.

Recovery Paths

If the dry run fails, fix the domain id, label, module root, or feature list before writing files. If manifest validation fails later, compare the domain manifest against new_gameplay_feature_template() and fill missing surfaces, executable hooks, paths, or symbols. If an existing system is being adopted, mark surfaces as existing only when the corresponding code and tests already own that surface.