Fix: Workers search filesystem instead of reading target file directly#2
Merged
Conversation
added 4 commits
May 21, 2026 13:38
The decomposer only knew about code-review agent types (static_analysis, quality_scan, synthesis). Goals referencing specific file paths got decomposed into project-discovery tasks because no catalog entry matched. Added 'file_analysis' agent type with tools (cat, head, tail, wc, grep, file, stat) and a description that says 'first step is to read the target file directly.' Updated the decompose prompt to detect file-path goals vs codebase goals.
When context.source_path points to a file (not a directory), the worker prompt now directs the worker to read the target file directly in the first turn. File-goal prompts drop find/ls/language toolchains from available tools and cap at 10 turns instead of 20. Added looksLikeFilePath detector that checks file extensions (.md, .go, .py, etc.) to distinguish file goals from codebase goals.
When the goal contains a file path (ending in a known extension like .md, .go, .py), the Decomposer pipeline now extracts the path and returns a single file_analysis task — bypassing the LLM strategy entirely. The prompt-based approach was fragile: the LLM still defaulted to code-review patterns. extractFilePathFromGoal scans goals for known file extensions and extracts the full path. fileGoalTask produces the single-task spec with source_path set to the discovered file.
Without this, workers polled only for static_analysis and quality_scan tasks. A file_analysis task from the decomposer short-circuit had no matching worker — the orchestrator sat waiting until timeout. Updated defaults in both parseRunFlags and parseResumeFlags to include file_analysis. Updated help text, flag descriptions, and test assertions to match.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1.
When Gaap's decomposer receives a goal referencing a specific file path (e.g.
summarize /tmp/release_review.md), workers spent 16 turns runningfindacross directories instead of reading the target file directly. All workers timed out, orchestration failed.Root cause: The agent catalog only had code-review types (static_analysis, quality_scan, synthesis). The decompose prompt had no notion of file goals. Workers defaulted to project-discovery patterns.
Fix (4 commits):
file_analysisagent type to the catalog and decompose promptextractFilePathFromGoal()scans for known extensions before the LLM call, returning a single file_analysis task immediately. The LLM was ignoring prompt instructions and still producing code-review DAGs; deterministic detection is more reliable.file_analysisto default CLI agent types so workers can claim the taskTested: Live run of
gaap run "summarize /tmp/test_goal.md"completed in 15 seconds with correct synthesis (file had no valuable content). Previously: 16 turns of find, 3 workers timed out.