centralize logic

This commit is contained in:
martin committed 2026-09-02 14:48:08 +02:00
1 parent b74508e225
commit 02d1e29db4
1 file changed
+1
+1
View File
@@ -64,6 +64,7 @@ Read only the skill that matches the work; do not load every shared reference by
- Implement only currently required behavior. Do not add speculative flexibility, optional features, configuration, extension points, frameworks, or future-proofing. - Implement only currently required behavior. Do not add speculative flexibility, optional features, configuration, extension points, frameworks, or future-proofing.
- Avoid new helper scripts, custom functions, abstractions, files, and layers unless they are immediately needed. - Avoid new helper scripts, custom functions, abstractions, files, and layers unless they are immediately needed.
- Keep each business rule in one place. When new or changed logic would otherwise be duplicated, centralize it using the smallest suitable existing structure. Do not refactor unrelated legacy duplication. - Keep each business rule in one place. When new or changed logic would otherwise be duplicated, centralize it using the smallest suitable existing structure. Do not refactor unrelated legacy duplication.
- When the same confirmed business rule is used in two or more FileMaker calculations or scripts, centralize it before adding another copy: prefer a calculation field for record-level logic that callers can reference; use a custom function only for genuinely parameterized or cross-context logic. Keep callers as references to that canonical logic. Do not create a shared object for single-use logic or where it would obscure behavior.
- Follow established project and FileMaker patterns unless a confirmed requirement requires a different approach. - Follow established project and FileMaker patterns unless a confirmed requirement requires a different approach.
- Make only the smallest necessary change. Avoid unrelated refactoring, cleanup, renaming, and formatting changes. - Make only the smallest necessary change. Avoid unrelated refactoring, cleanup, renaming, and formatting changes.
- Add error handling only for expected errors that affect the required workflow. Avoid generic catch-all handling, redundant `Get ( LastError )` checks, defensive branches, logging, status variables, and cleanup blocks that do not change the required result. - Add error handling only for expected errors that affect the required workflow. Avoid generic catch-all handling, redundant `Get ( LastError )` checks, defensive branches, logging, status variables, and cleanup blocks that do not change the required result.