Merge pull request #1011 from buster-so/jacob-bus-1750-hardcoding-values-in-metrics

First Attempt To Fix Hardcoded values

packages/ai/src/agents/analyst-agent/analyst-agent-prompt.txt

@@ -293,6 +293,12 @@ You operate in a loop to complete tasks:
 - Default Time Range: If the user does not specify a time range for analysis, default to the last 12 months from the current date. Clearly state this assumption if making it.
 - Avoid Bold Assumptions: Do not make complex or bold assumptions about the user's intent or the underlying data. If the request is highly ambiguous beyond a reasonable time frame assumption, indicate this limitation in your final response.
 - Prioritize Defined Metrics: Before constructing complex custom SQL, check if pre-defined metrics or columns exist in the provided data context that already represent the concept the user is asking for. Prefer using these established definitions.
+- Avoid Static Queries: Do not create static queries where you are hardcoding a value. Non-static queries are always preferred.
+    - Instead of doing:
+        - Select 55000 as revenue
+    - Do this instead:
+        - Select sum(sales) as revenue
+    - If you have to do static SQL, use date filters to make it static rather than adding hardcoded data
 - Grouping and Aggregation:
   - `GROUP BY` Clause: Include all non-aggregated `SELECT` columns. Using explicit names is clearer than ordinal positions (`GROUP BY 1, 2`).
   - `HAVING` Clause: Use `HAVING` to filter *after* aggregation (e.g., `HAVING COUNT(*) > 10`). Use `WHERE` to filter *before* aggregation for efficiency.

packages/ai/src/agents/think-and-prep-agent/think-and-prep-agent-investigation-prompt.txt

@@ -537,6 +537,12 @@ If all true → proceed to submit prep for Asset Creation with `submitThoughts`.
 - Default Time Range: If the user does not specify a time range for analysis, default to the last 12 months from the current date. Clearly state this assumption if making it.
 - Avoid Bold Assumptions: Do not make complex or bold assumptions about the user's intent or the underlying data. If the request is highly ambiguous beyond a reasonable time frame assumption, indicate this limitation in your final response.
 - Prioritize Defined Metrics: Before constructing complex custom SQL, check if pre-defined metrics or columns exist in the provided data context that already represent the concept the user is asking for. Prefer using these established definitions.
+- Avoid Static Queries: Do not create static queries where you are hardcoding a value. Non-static queries are always preferred.
+    - Instead of doing:
+        - Select 55000 as revenue
+    - Do this instead:
+        - Select sum(sales) as revenue
+    - If you have to do static SQL, use date filters to make it static rather than adding hardcoded data
 - Grouping and Aggregation:
     - `GROUP BY` Clause: Include all non-aggregated `SELECT` columns. Using explicit names is clearer than ordinal positions (`GROUP BY 1, 2`).
     - `HAVING` Clause: Use `HAVING` to filter *after* aggregation (e.g., `HAVING COUNT(*) > 10`). Use `WHERE` to filter *before* aggregation for efficiency.

packages/ai/src/agents/think-and-prep-agent/think-and-prep-agent-standard-prompt.txt

@@ -451,6 +451,12 @@ When in doubt, be more thorough rather than less. Reports are the default becaus
 - Default Time Range: If the user does not specify a time range for analysis, default to the last 12 months from the current date. Clearly state this assumption if making it.
 - Avoid Bold Assumptions: Do not make complex or bold assumptions about the user's intent or the underlying data. If the request is highly ambiguous beyond a reasonable time frame assumption, indicate this limitation in your final response.
 - Prioritize Defined Metrics: Before constructing complex custom SQL, check if pre-defined metrics or columns exist in the provided data context that already represent the concept the user is asking for. Prefer using these established definitions.
+- Avoid Static Queries: Do not create static queries where you are hardcoding a value. Non-static queries are always preferred.
+    - Instead of doing:
+        - Select 55000 as revenue
+    - Do this instead:
+        - Select sum(sales) as revenue
+    - If you have to do static SQL, use date filters to make it static rather than adding hardcoded data
 - Grouping and Aggregation:
     - `GROUP BY` Clause: Include all non-aggregated `SELECT` columns. Using explicit names is clearer than ordinal positions (`GROUP BY 1, 2`).
     - `HAVING` Clause: Use `HAVING` to filter *after* aggregation (e.g., `HAVING COUNT(*) > 10`). Use `WHERE` to filter *before* aggregation for efficiency.