Restores the research tool that was previously externalized as a skill: - Add pending_research.rs: PendingResearchManager with thread-safe task tracking - Add tools/research.rs: execute_research (async), execute_research_status - Add research/research_status tool definitions with exclude_research config - Integrate PendingResearchManager into Agent and ToolContext - Inject completed research results in streaming loop Remove research skill: - Clear EMBEDDED_SKILLS array in embedded.rs - Delete skills/research/ directory - Update all tests expecting embedded research skill - Update docs and memory to reflect the change The research tool now: - Spawns scout agent in background tokio task - Returns immediately with research_id - Automatically injects results into conversation when ready - Supports status checks via research_status tool
4.9 KiB
Breaker Report: 2025-02-05
Note
: Issue 1 below is now obsolete. The research skill was removed and replaced with a first-class
researchtool incrates/g3-core/src/tools/research.rs. The g3-research script no longer exists.
Focused on changes in commits b6d2582..9443f933 (past 10 commits).
Issue 1: JSON Escaping Bug in g3-research Script (OBSOLETE)
Title
g3-research produces invalid JSON when query contains actual newlines
Repro
# In skills/research/g3-research, the write_status function uses:
escaped_query=$(echo -n "$query" | sed 's/\\/\\\\/g; s/"/\\"/g; s/\n/\\n/g')
# Test with actual newlines:
QUERY=$'What is\nthe best\nRust library?'
escaped=$(echo -n "$QUERY" | sed 's/\\/\\\\/g; s/"/\\"/g; s/\n/\\n/g')
echo "{\"query\": \"$escaped\"}" | python3 -m json.tool
# Output: Invalid control character at: line 1 column 19 (char 18)
Expected: Valid JSON with \n escape sequences
Actual: Invalid JSON with literal newline characters
Diagnosis
- File:
skills/research/g3-research:66 - Root cause: The sed pattern
s/\n/\\n/gmatches the literal two-character string\n, not actual newline characters. Sed processes line-by-line by default and doesn't see newlines in the pattern space. - Triggering condition: User query contains actual newline characters (e.g., from multi-line input or programmatic construction)
- Deterministic: Yes
Impact
- Severity: Incorrect behavior -
status.jsonbecomes unparseable - Likelihood: Uncommon but possible - queries are typically single-line, but multi-line queries from programmatic sources or copy-paste could trigger this
Fix
Replace sed with perl which handles newlines correctly:
escaped_query=$(echo -n "$query" | perl -pe 's/\\/\\\\/g; s/"/\\"/g; s/\n/\\n/g')
Issue 2: Embedded Skill Path Not Readable
Title
Embedded skills have non-existent file paths that agents are instructed to read_file
Repro
# When no repo skills/ directory exists, embedded skills are loaded
# The generated prompt contains:
<skill>
<name>example-skill</name>
<description>...</description>
<location><embedded:example-skill>/SKILL.md</location>
</skill>
# The prompt instructs:
"read the full skill file using `read_file` to get detailed instructions"
# Agent attempts:
read_file("<embedded:example-skill>/SKILL.md")
# Result: File not found error
Expected: Agent can read skill documentation
Actual: File path doesn't exist on disk
Diagnosis
- File:
crates/g3-core/src/skills/discovery.rs:97- sets path to<embedded:name>/SKILL.md - File:
crates/g3-core/src/skills/prompt.rs:14-15- instructs agent to useread_file - Root cause: Embedded skills use a synthetic path marker, but the prompt doesn't account for this
- Triggering condition: User has no
skills/directory in their repo (embedded skill not overridden) - Deterministic: Yes
Impact
- Severity: Annoying - agent will fail to read skill docs and may hallucinate or ask for help
- Likelihood: Common for users outside the g3 repo itself
Possible Fixes
- Include the full skill body in the prompt for embedded skills (increases prompt size)
- Add special handling in
read_filefor<embedded:*>paths - Change prompt to say "skill instructions are below" for embedded skills and inline the body
Issue 3: Hardcoded 'main' Branch in SDLC Pipeline
Title
studio sdlc assumes default branch is named 'main'
Repro
# In a repo where default branch is 'master':
studio sdlc run
# has_commits_on_branch runs:
git rev-list --count main..sdlc/session-branch
# Fails silently (returns Ok(false)) because 'main' doesn't exist
# merge_to_main runs:
git checkout main
# Fails with "Failed to checkout main"
Expected: Works with any default branch name
Actual: Fails or behaves incorrectly on repos using 'master' or other branch names
Diagnosis
- File:
crates/studio/src/main.rs:720-has_commits_on_branch()hardcodesmain..{branch} - File:
crates/studio/src/git.rs-merge_to_main()hardcodescheckout main - Root cause: No detection of actual default branch name
- Triggering condition: Repository uses 'master' or custom default branch
- Deterministic: Yes
Impact
- Severity: Incorrect behavior - merge fails or skipped incorrectly
- Likelihood: Common - many repos still use 'master'
Fix
Detect default branch:
git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'
# or
git config --get init.defaultBranch
Summary
| # | Issue | Severity | Likelihood |
|---|---|---|---|
| 1 | JSON escaping with newlines | Incorrect behavior | Uncommon |
| 2 | Embedded skill path unreadable | Annoying | Common |
| 3 | Hardcoded 'main' branch | Incorrect behavior | Common |
All issues are deterministic and reproducible.