Design principles¶
CCB design decisions are constrained by observable behaviour, compatibility, maintainability, and the project's own direction. Historical design documents provide context; current CCB source, tests, governance, and maintainer decisions determine what applies now.
Evaluate a proposal¶
- State the player or contributor problem without prescribing an implementation.
- Define observable success, non-goals, affected audiences, and failure modes.
- Check whether JSON, EOC, or the supported Lua API can express the change before adding engine complexity.
- Identify ownership, lifecycle, invariants, serialization, performance hot paths, UI/accessibility, localization, and platform effects.
- Compare shared upstream behaviour with intentional CCB divergence.
- Prefer a reversible, testable increment with clear compatibility policy.
Data-driven without hiding semantics¶
Moving behaviour into data is useful only when the loader validates it, errors are actionable, and authors can understand the lifecycle. A flexible JSON or Lua surface still needs documented constraints and tests. Do not publish an unstable internal hook as a public extension point merely to avoid a C++ change.
Balance and content¶
Mechanics and balance proposals need examples, affected scenarios, and a way to measure the intended result. Avoid broad unrelated rebalance in a technical fix. Respect project lore and content policy, but flag historical upstream guidance that has not been confirmed for CCB rather than presenting it as current law.
The final decision belongs in an issue or reviewed pull request so rationale, trade-offs, and Responsible human remain auditable.