The 9 Laws of Sirpi
These nine laws are the non-negotiable structural constraints of the Sirpi framework. They are designed to force architectural integrity, eliminate technical debt, and ensure that every “Sculpture” is perfectly legible to both humans and AI agents.
The Rule: You cannot nest control structures (if, for, while) within each other.
The Rationale: Deep nesting hides complexity and indicates that a method is doing too much. Forcing flatness ensures methods are atomic and single-purpose.
The Rule: The else keyword is a syntax error in the Sculpt language.
The Rationale: Else indicates poorly modeled branching. Use Early Returns or Polymorphism (The Strategy Pattern) to define clear, deterministic execution paths.
The Rule: Raw types (string, number, boolean) are forbidden as instance variables or method arguments. They must be wrapped in a Domain.
The Rationale: A string is not a Name; a number is not a Price. Domain-wrapping prevents Primitive Obsession and ensures validation happens at the boundary.
The Rule: Any class that contains a collection (Array, Map, Set) must not contain any other member variables.
The Rationale: Collections are distinct domain concepts. Wrapping them in their own class allows you to own the logic for filtering, mapping, and protecting that data.
The Rule: You cannot chain method calls (The Law of Demeter). No a.b().c().
The Rationale: Chaining creates tight coupling across the system. Talk to your neighbors, not their grandchildren. This ensures the "Lattice" remains decoupled.
The Rule: Method and variable names must be descriptive and full-length.
The Rationale: If a name is too long to write, the object is likely doing too much. Clarity is the antidote to the "knowledge loss" that occurs in traditional codebases.
The Rule: No class may exceed 50 lines of code. No file may exceed 100 lines.
The Rationale: Large files are "God Objects" in disguise. Small entities ensure that the whole logic of a component can be grasped in a single glance by a human or an AI context window.
The Rule: High cohesion is mandatory. A class can have a maximum of TWO instance variables.
The Rationale: If an object needs three or more variables, it is likely representing two separate concepts that should be split into distinct sculptures.
The Rule: You cannot "pull" data from an object. Objects must be encapsulated.
The Rationale: "Tell, Don't Ask." Your business logic emits Intents (messages). The framework handles the "dirty" work of updating the UI. This keeps your objects pure and testable.
The Rule: The build system will refuse to compile a production binary if total test coverage is below 95%.
The Rationale: Structural integrity is meaningless without empirical proof. Because Sirpi logic is composed of tiny, pure objects, testing is trivial. This gate ensures that a Sirpi asset is not just clean, but guaranteed to be correct.