dygo Code Quality

Deliver the required behavior with the least maintenance burden.

Before Editing

• State material assumptions.
• Inspect the current implementation and nearby conventions.
• Define an observable success condition in a real Business App or operator flow.
• Identify the canonical package, metadata contract, SDK boundary, or Studio component that owns the behavior.

Rules

• Keep every changed line tied to the task.
• Do not clean unrelated code or reformat unrelated files.
• Prefer direct code and standard-library operations over custom algorithms and speculative abstraction.
• Prefer existing framework and native platform capabilities before adding custom code or dependencies.
• Reduce duplicated rules, state, branches, queries, and abstractions. Do not compress readable code or omit required behavior to reduce line count.
• Add abstractions for demonstrated shared contracts, not hypothetical reuse. A small amount of duplication can be simpler than coupling unrelated behavior.
• Avoid unnecessary I/O, repeated queries, allocations, and unbounded work. Support performance claims with measurements appropriate to the affected path.
• For refactoring, identify the duplicated rule, state owner, branch, or concept that the change removes. Moving code into more files is not sufficient.
• Preserve error meaning. Treat only a confirmed not-found result as absence. Do not use a fallback to hide a persistence, permission, or decoding failure.
• Do not add a thin wrapper, flag, optional mode, or generic registry without a real repeated need.
• Keep business logic in Apps and reusable platform capability in the framework.
• Keep internals private until Business Apps need a stable public contract.
• Remove only dead code that the current change creates unless cleanup is in scope.
• Preserve reusable UI components and supported exports even without current callers unless their removal is explicitly requested.
• Add a concise TODO only when a real deferred improvement has a clear boundary and cannot be completed in the current scope.
• Verify behavior in proportion to risk.

If a solution becomes much larger than the behavior it provides, stop and simplify it before finalization.