From b74508e22512ab8cefe52a284ed415e83647f9aa Mon Sep 17 00:00:00 2001 From: Martin Galik Date: Tue, 25 Aug 2026 08:25:49 +0200 Subject: [PATCH] Prefer simple FileMaker implementations --- AGENTS.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 0b1e6ad..a859dc8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -58,6 +58,21 @@ Read only the skill that matches the work; do not load every shared reference by - Do not make production changes, send client messages, or modify project files unless explicitly asked. - Do not expose credentials or other sensitive values found in source material. +## Implementation simplicity + +- Prefer the simplest correct implementation that satisfies the confirmed requirement. +- 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. +- 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. +- 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. +- 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. +- Preserve the minimum necessary safeguards for destructive actions, imports, migrations, production changes, security, and data integrity. +- When a requirement is unclear, ask a focused question instead of implementing multiple hypothetical cases or defensive alternatives. +- Add comments only for non-obvious logic, business rules, and required dated change notes. +- Validate only the directly affected behavior with the smallest relevant checks. Do not create additional testing infrastructure unless it is necessary. +- Treat these rules as the default. Confirmed requirements, data safety, and verified existing behavior take priority. If additional complexity is necessary, explain the concrete reason briefly. + ## Response format - Do not hard-wrap Markdown prose. Use line breaks only where Markdown structure or meaning requires them.