import type { JSONSchema } from '@wrongstack/core/types';
export declare const KANBAN_TOOL_DESCRIPTION = "Durable project task boards: create and move cards, record checks, notes, links and assignments. The board is a record of the work, not a permit for it \u2014 nothing here gates other tools. Managed boards additionally enforce ordered Backlog \u2192 Todo \u2192 Running \u2192 Review \u2192 Done transitions; release_managed_lifecycle turns that off.";
export declare const KANBAN_TOOL_USAGE_HINT = "Track substantial or multi-step work so it survives the session; a trivial edit or a question needs no card. Work stays on ONE board: call list_boards first and add_task to the board this project already uses. create_board is for a genuinely separate line of work, not for each new piece of it \u2014 a second board splits the same effort in two, and a board holding a single card is the usual sign. Common flow: list_boards or search_tasks to orient, add_task to record work, start_task when you begin, update_check with checkStatus \"passed\" to tick acceptance criteria (read their ids from get_task), then transition_task. On a managed board a refused transition names the field it wants \u2014 supply it and retry. When the acceptance criterion is something a machine can run, say so: set checkType (\"command\", \"test\", \"file_exists\", \"file_matches\", \"git_diff\", \"metric\") and put the command, pattern or path in checkNotes, then verify_completion executes it and the result is real evidence. Leave checkType off (or \"manual\") only for criteria that genuinely need a human eye \u2014 a manual check records your assertion, it does not test anything. Goal metrics pass when current >= target by default; when lower is better (error rate, cost ceiling, latency, open-bug count), pass metricDirection \"at_most\" with add_goal_metric / update_goal_metric so verification compares current <= target instead.";
export declare const KANBAN_INPUT_SCHEMA: JSONSchema;
//# sourceMappingURL=kanban-tool-schema.d.ts.map