Write compilable easy-query code from verified patterns.
Use this file only as the router. Open one primary reference first. Add at
most one secondary reference when a boundary rule below says it is needed.
If the project version differs from the reference version, prefer the project
and flag APIs that may have moved.
Lead with working code. For troubleshooting, lead with the first failing layer
and the next concrete check or fix. For AP/reporting, state the
dimension -> metric -> filter -> rank/union/cte shape before dropping into
code when that framing prevents wrong SQL structure. Cite a reference only for
non-obvious API, SQL-shape, or version caveat.
If compile-ready code uses non-obvious easy-query annotations, enums, starter
SPI, or extension types, include the needed imports instead of assuming the
reader can recover them from context.
-
For true physical delete when logic delete is active, both
disableLogicDelete() and allowDeleteStatement(true) are required; do not
omit the latter.
-
In tree CTE answers, distinguish anchor/seed filtering from
recursive-member filtering: outer .where(...) before .asTreeCTE(...)
filters only the seed rows; use setChildFilter(...) or equivalent tree CTE
config to control the recursive step.
-
When a question directly targets a boundary rule or review check already
stated in this file, answer directly from that guidance and answer directly
without opening external reference files. Use the exact phrasing from the
review check as the authoritative source; do not paraphrase or substitute
entity/type names. Only open a reference when the question needs API-level
detail, code examples, or deeper explanation beyond what the review checks
state.
-
When the question asks what the skill recommends, enforces, warns against,
or should say, quote the relevant review-check wording directly in the
answer, including negatives such as do not, not, without, or
requires both, rather than paraphrasing.
-
When a question mentions a type name or asks for its import, include the
actual import line or FQCN in the answer from
references/symbol-imports.md; do not defer to the reference for that
concrete value.
-
Use exact artifact names, property names, and API identifiers as written in
the skill and references; do not reword or generalize them.
-
When a navigation should load only for certain root rows based on a static
entity property (e.g., version), prefer the entity-side annotation
@IncludeOnProperty on the @Navigate field. Do not drift into DTO child
filtering via EXTRA_AUTO_INCLUDE_CONFIGURE as the first approach; note
that EXTRA_AUTO_INCLUDE_CONFIGURE is a query-time DTO child-list pruning
knob, not an entity metadata gating mechanism. Also, note that
loadInclude(...) evaluates already-loaded root objects in memory before
issuing relation queries, so entity-side @IncludeOnProperty metadata still
applies to loadInclude calls. Route to
references/entity-modeling-navigate.md for entity-side conditional
navigation.
-
For selectAutoInclude, always preserve the DTO/VO class literal in the
call (e.g., selectAutoInclude(ResultDTO.class)). Do not substitute a
different class name or omit the class argument; without the class literal,
easy-query cannot determine which nested relations to include.
-
When the task, context, or eval surface names an exact API call shape with
type parameters or arguments (for example,
selectAutoInclude(ResultDTO.class)), reproduce the full call expression
including generic type arguments rather than naming only the bare method; do
not abbreviate to a method-only form.
-
When the question asks for an exact call shape, or when an argument value is
what makes the API semantically correct, include the necessary argument value
instead of truncating to the bare method name. For example,
allowDeleteStatement(true) is materially different from
allowDeleteStatement(), and queryable(rawSql, Entity.class, params) is
more precise than a bare queryable.
-
For identifier-only questions (e.g., "which method", "what property", "name
the API"), the answer must be only the identifier or exact call shape,
without code blocks, explanation, or extra context. Do not include the class
name, package, or usage example unless explicitly asked.
