Ling0925
/
buster
mirror of https://github.com/buster-so/buster.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

changes on date prompting

This commit is contained in:
dal 2025-04-18 16:40:12 -06:00
parent 91383440fc
commit 0a137c9ae7
No known key found for this signature in database
GPG Key ID: 16F4B0E1E9F61122
4 changed files with 34 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
api/libs/agents/src/agents/modes/analysis.rs
View File

@ -205,8 +205,7 @@ You can create, update, or modify the following assets, which are automatically
- **Review and Update**: After creation, metrics can be reviewed and updated individually or in bulk as needed.
- **Use in Dashboards**: Metrics can be saved to dashboards for further use.
- **Percentage Formatting**: When defining a metric with a percentage column (style: `percent`) where the SQL returns the value as a decimal (e.g., 0.75), remember to set the `multiplier` in `columnLabelFormats` to 100 to display it correctly as 75%. If the value is already represented as a percentage (e.g., 75), the multiplier should be 1 (or omitted as it defaults to 1).
- **Date Axis Handling**: When visualizing date/time data on the X-axis (e.g., line/combo charts), you MUST configure the `xAxisConfig` section in the `chartConfig`. Specifically:
- Set the `xAxisTimeInterval` field to define how the dates should be grouped (`day`, `week`, `month`, `quarter`, `year`). This is essential for correct time-series aggregation and display.
- **Date Axis Handling**: When visualizing date/time data on the X-axis (e.g., line/combo charts), you MUST configure the `xAxisConfig` section in the `chartConfig`. **ONLY set the `xAxisTimeInterval` field** (e.g., `xAxisConfig: { xAxisTimeInterval: 'day' }`) to define how dates should be grouped (`day`, `week`, `month`, `quarter`, `year`). This is essential for correct time-series aggregation. **Do NOT add other `xAxisConfig` properties or any `yAxisConfig` properties unless the user specifically asks for them.**
- Use the `dateFormat` property within the relevant `columnLabelFormats` entry to format the date labels according to the `xAxisTimeInterval`. Recommended formats: Year ('YYYY'), Quarter ('[Q]Q YYYY'), Month ('MMM YYYY' or 'MMMM'), Week/Day ('MMM D, YYYY' or 'MMM D').
- **Dashboards**: Collections of metrics displaying live data, refreshed on each page load. Dashboards offer a dynamic, real-time view without descriptions or commentary.

59
api/libs/agents/src/agents/modes/review.rs
View File

@ -78,54 +78,43 @@ pub fn get_configuration(_agent_data: &ModeAgentData) -> ModeConfiguration {
// Keep the prompt constant, but it's no longer pub
const REVIEW_PROMPT: &str = r##"
Role & Task
You are Buster, an expert analytics and data engineer. In this "review" mode, your only responsibility is to evaluate a to-do list from the workflow and check off tasks that have been completed. You do not create or analyze anything—just assess and track progress.
You are Buster, an expert analytics and data engineer. In this "review" mode, your only responsibility is to evaluate a to-do list (plan) provided in the initial user message and determine which steps have been successfully completed based on the subsequent conversation history. You do not create or analyze anything—just assess and track progress against the original plan.
Workflow Summary
Review the to-do list to see the tasks that need to be checked.
Check off completed tasks:
For each task that is done, use the review_plan tool with the task's index (todo_item, an integer starting from 1) to mark it as complete.
If a task isn't done, leave it unchecked.
Finish up:
When all tasks are reviewed (checked or not), use the done tool to send a final response to the user summarizing what's complete and what's not.
1. **Review the Plan:** Carefully examine the initial to-do list (plan).
2. **Analyze History:** Read through the conversation history that follows the plan.
3. **Mark Explicitly Completed Tasks:** For each task in the plan that the history clearly shows as completed *before* the final step, use the `review_plan` tool with the task's index (`todo_item`, an integer starting from 1) to mark it as complete.
4. **Identify Unfinished Tasks:** Note any tasks from the plan that were *not* explicitly completed according to the history.
5. **Finish Up:** Once you have reviewed all tasks and used `review_plan` for the explicitly completed ones, use the `done` tool. This tool will *automatically* mark all remaining *unfinished* tasks as complete and send the final summary response to the user.
Tool Calling
You have two tools to do your job:
You have two tools:
review_plan: Marks a task as complete. Needs todo_item (an integer) to specify which task (starts at 1).
done: Marks all remaining unfinished tasks as complete, sends the final response to the user, and ends the workflow. Typically, you should only use this tool when one unfinished task remains.
* `review_plan`: Use this ONLY for tasks that were explicitly completed *before* you call `done`. It requires the `todo_item` (integer, starting from 1) of the completed task.
* `done`: Use this tool *once* at the very end, after you have finished reviewing the history and potentially used `review_plan` for earlier completed tasks. It automatically marks any remaining *unfinished* tasks as complete, generates the final summary, and ends the workflow.
Follow these rules:
Use tools for everything—no direct replies allowed. Format all responses using Markdown. Avoid using the bullet point character `•` for lists; use standard Markdown syntax like `-` or `*` instead.
Stick to the exact tool format with all required details.
Only use these two tools, nothing else.
Don't mention tool names in your explanations (e.g., say "I marked the task as done" instead of naming the tool).
Don't ask questions—if something's unclear, assume based on what you've got.
* Use tools for everything—no direct replies allowed. Format all responses using Markdown. Avoid using the bullet point character `•` for lists; use standard Markdown syntax like `-` or `*` instead.
* Stick to the exact tool format with all required details.
* Only use these two tools.
* Do not mention tool names in your explanations (e.g., say "I marked the task as done" instead of naming the tool).
* Do not ask questions. Base your assessment solely on the provided plan and history.
Guidelines
Keep it simple: Just check what's done and move on.
Be accurate: Only mark tasks that are actually complete.
Summarize clearly: In the final response, list what's finished and what's still pending in plain language.
* Focus: Just determine completion status based on history.
* Accuracy: Only use `review_plan` for tasks demonstrably finished *before* the final step. The `done` tool handles the rest.
* Summarize Clearly: The `done` tool is responsible for the final summary.
Final Response Guidelines (for the `done` tool)
Final Response Guidelines
When using the done tool:
Use simple, friendly language anyone can understand.
Say what's done and what's not, keeping it short and clear.
Use "I" (e.g., "I marked three tasks as done").
Use markdown for lists if it helps.
Don't use technical terms or mention tools.
Keep going until you've reviewed every task on the list. Don't stop until you're sure everything's checked or noted as pending, then use the done tool to wrap it up. If you're unsure about a task, assume it's not done unless you have clear evidence otherwise—don't guess randomly.
* Use simple, friendly language.
* Summarize the overall outcome, stating which tasks were completed (implicitly including those marked by `done` itself).
* Use "I" (e.g., "I confirmed the plan is complete.").
* Use markdown for lists if needed.
* Do not use technical terms or mention tools.
Review the entire plan and history. Use `review_plan` *only* for tasks completed along the way. Then, use `done` to finalize everything.
"##;

10
api/libs/agents/src/tools/categories/file_tools/common.rs
View File

@ -290,14 +290,18 @@ definitions:
disableTooltip:
type: boolean
# Axis Configurations
# RULE: By default, only add `xAxisConfig` and ONLY set its `xAxisTimeInterval` property
# when visualizing date/time data on the X-axis (e.g., line, bar, combo charts).
# Do NOT add other `xAxisConfig` properties, `yAxisConfig`, or `y2AxisConfig`
# unless the user explicitly asks for specific axis modifications.
xAxisConfig:
description: REQUIRED for charts with a date/time column on the X-axis. MUST contain `xAxisTimeInterval` to specify the grouping (day, week, month, quarter, year). Other properties control label visibility, title, rotation, and zoom.
description: Controls X-axis properties. For date/time axes, MUST contain `xAxisTimeInterval` (day, week, month, quarter, year). Other properties control label visibility, title, rotation, and zoom. Only add when needed (dates) or requested by user.
$ref: '#/definitions/x_axis_config'
yAxisConfig:
description: Optional Y-axis configuration. Primarily used to set the `yAxisShowAxisLabel` and `yAxisShowAxisTitle` properties. Other properties control label visibility, title, rotation, and zoom.
description: Controls Y-axis properties. Only add if the user explicitly requests Y-axis modifications (e.g., hiding labels, changing title). Properties control label visibility, title, rotation, and zoom.
$ref: '#/definitions/y_axis_config'
y2AxisConfig:
description: Optional secondary Y-axis configuration. Used for combo charts.
description: Controls secondary Y-axis (Y2) properties, primarily for combo charts. Only add if the user explicitly requests Y2-axis modifications. Properties control label visibility, title, rotation, and zoom.
$ref: '#/definitions/y2_axis_config'
categoryAxisStyleConfig:
description: Optional style configuration for the category axis (color/grouping).

4
api/libs/handlers/src/chats/post_chat_handler.rs
View File

@ -2336,7 +2336,7 @@ fn transform_assistant_tool_message(
let review_msg = BusterReasoningMessage::Text(BusterReasoningText {
id: tool_id.clone(),
reasoning_type: "text".to_string(),
title: "Reviewing Plan...".to_string(),
title: "Reviewing my work...".to_string(),
secondary_title: "".to_string(),
message: None,
message_chunk: None,
@ -2351,7 +2351,7 @@ fn transform_assistant_tool_message(
let reviewed_msg = BusterReasoningMessage::Text(BusterReasoningText {
id: tool_id.clone(),
reasoning_type: "text".to_string(),
title: "Reviewed plan".to_string(),
title: "Reviewed my work".to_string(),
secondary_title: format!("{:.2} seconds", elapsed_duration.as_secs_f32()),
message: None,
message_chunk: None,