goga-cookbook

Goga Cookbook

Purpose

Provides principles for applying DSL specification constructs when designing cells and CODEMANIFEST files. Defines how and when to apply DSL constructs.

This skill is called from other skills to obtain DSL design context.

Behavior

Apply principles within the context of the calling skill. Do not reproduce or summarize the content — use it to make design decisions for CODEMANIFEST files and cells.

---

Principles for Applying DSL Specification in Cell and CODEMANIFEST Design

The DSL specification defines what may or must appear in a cell and a CODEMANIFEST file. This document defines how and when to apply those constructs.

Cell

When to create a cell

Create a cell when you identify a distinct responsibility domain with a well-defined API boundary. Enforce the principle: one responsibility zone — one cell.

A separate cell is warranted when at least one of the following holds:

• The logic can be decoupled from other system components
• The logic owns a data model distinct from other system components
• The functionality must be reused across multiple areas of the project
• The purpose can be stated in a single phrase without "and"

Design order

Design cells bottom-up — from leaves to root. If cell A depends on cell B (via Imports), design B first. A cell with no dependencies is designed first.

Rationale: The CODEMANIFEST of a dependency cell defines the types and practices that dependent cells import. You cannot correctly describe Imports without knowing exactly what the dependency provides.

Granularity

A cell must be large enough to function as an independent unit, yet small enough to describe its contract without losing focus.

Too fine — one cell per function. When multiple types are always used together and have no independent meaning, they belong in the same cell.

Too coarse — a cell covers heterogeneous functionality. If describing the cell's purpose requires "and", consider splitting it into multiple cells.