Files
g3/analysis/breaker/2025-02-05.md
Dhanji R. Prasanna ff15db44c0 Restore research as first-class tool, remove research skill
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
2026-02-06 07:38:06 +11:00

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 research tool in crates/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/g matches 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.json becomes 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 use read_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

  1. Include the full skill body in the prompt for embedded skills (increases prompt size)
  2. Add special handling in read_file for <embedded:*> paths
  3. 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() hardcodes main..{branch}
  • File: crates/studio/src/git.rs - merge_to_main() hardcodes checkout 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.