Ratified Design Philosophy

Problem

Rules alone are applied to the letter and miss the intent. An agent told to use no hardcoded colours will still give one screen its own card, its own spacing and its own selected state, because nothing told it that two looks for one meaning is a defect. Left to its own taste, the model regresses to an average, safe look and narrows a deliberately wide range of styles toward a tasteful middle. Each local fix adds code instead of retiring it, so agent-written interface code grows while consistency falls. Letting the agent rewrite its own guidance fixes the staleness but not the drift, because its unreviewed choices quietly become the direction.

Solution

Write the design direction as a single document the agent loads for any design work, not only for reviews. It opens with the philosophy: why the product exists and a short ordered list of principles, each with its reason, so a conflict between two good options is settled by rank rather than by taste. A section of decided direction holds the owner's rulings, each dated and quoting the owner's own words, and the agent applies them without asking again. Where neither the principles nor the rulings answer a question, the agent asks the owner with options and a recommendation before rating anything a defect. Every choice the agent makes on its own goes into a choices log as proposed, and the owner either accepts it, which moves its rule into the decided direction, or rejects it, which reverts it. The document learns on every use within a narrow, owner-granted scope: a correction becomes a dated rule, a mistake that cost a round becomes a check in the protocol, and a superseded rule is rewritten or deleted so two rules never disagree. Each finding names the rule it breaks and the one shared component where the fix belongs, so a fix improves every screen and removes local code instead of adding it. A static sweep counts the textual deviations, such as colour literals and local touchables, and a test fails any count that rises above a committed baseline; a batch that removes deviations lowers the baseline in the same commit.

When to use

• Agents write or change most of a product's interface and the owner has a design direction that is only partly written down.
• The product spans many themes, platforms or display modes, so local fixes multiply into inconsistent variants.
• A shared component layer exists or can exist, so a fix has one place to land.
• The owner is available to answer questions and ratify proposed choices on a regular basis.