Query System

The query system is split across both apps.

• In global-app, it shows up as the find-data area with a query builder.
• In local-app, it shows up as reusable query detail cards and query log dialogs used inside patient, training, and log views.

Where it lives

• global query flow: projects/global-app/src/app/modules/find-data
• local reusable query UI: projects/local-app/src/app/modules/query
• log and patient integrations: projects/local-app/src/app/modules/logs and projects/local-app/src/app/modules/patient

System boundary

Start here when the change is about building queries, showing query details, or reusing query UI inside local workflows.

Do not start here for schema semantics or cohort ownership. Those often belong to Data modeling system or Local operations system.

System shape

What this means for contributors

This is not a single route-owned feature. Part of it is a top-level page, and part of it is embedded UI reused inside other systems.

That has two consequences:

• route work starts in find-data
• query presentation work often starts in local-app/modules/query

What to edit for common tasks

Task	Start here
change the query builder flow	projects/global-app/src/app/modules/find-data/components
change query cards used in local screens	projects/local-app/src/app/modules/query/components
change how query logs are shown in patient or log views	the consuming component in patient or logs, plus the shared query component if needed

Adjacent systems

• schema or datatype changes that affect query behavior often require Data modeling system
• local query consumers in patient, training, or logs often require checks in Local operations system

Practical rule

If you are changing query composition, start global.

If you are changing query display inside local workflows, start local.