Repository navigation
bug(init): avoid selecting one-character literals as the agent name #320
Description
Summary
agents-shipgate init selected the one-character identifier t as the generated agent.name for the Strix repository, even though the same static pass also found the much more plausible candidate Strix.
This can produce a syntactically valid manifest whose declared agent identity is misleading. The user must correct it manually before relying on later reports or handoffs.
Reproduction
From a local clone of usestrix/strix:
env AGENTS_SHIPGATE_AGENT_MODE=1 \
PYTHONPATH=/path/to/agents-shipgate/src \
python -m agents_shipgate init \
--workspace /path/to/strix \
--write \
--jsonRelevant output:
{
"auto_detected": {
"is_agent_project": true,
"frameworks": [
{
"type": "openai_agents_sdk",
"score": 64.0,
"confidence": "high"
}
],
"agent_name": "t",
"agent_name_candidates": [
{ "value": "t", "source": "Agent_name_literal" },
{ "value": "Strix", "source": "Agent_name_literal" },
{ "value": "strix", "source": "workspace_dir" }
]
}
}The command successfully wrote shipgate.yaml and a managed .gitignore block. The issue is the automatic choice of t as the manifest's agent identity, not framework detection or file writing.
Actual behavior
- The repository is correctly detected as a high-confidence OpenAI Agents SDK project.
- The one-character literal
tis ranked aboveStrix. init --writeusestas the generated agent name.
Expected behavior
When several literals are available, a one-character, context-poor identifier should not be silently selected over a plausible project/agent identity.
Possible fail-closed behavior:
- Penalize or exclude very short/generic name literals unless they are the only candidate.
- Prefer candidates with stronger agent-definition context and meaningful names.
- If ambiguity remains material, write a
CHANGE_MEplaceholder (or emit an explicit diagnostic) rather than asserting an unreliable agent identity.
Why this matters
agent.name appears in scan output and reviewer/agent-handoff artifacts. Selecting the wrong identity makes reports harder to interpret and can lead users to trust an auto-generated manifest that needs semantic correction.
This is a static candidate-ranking problem. It does not require executing the Strix agent, calling tools, or making network requests.
Activity
pengfei-threemoonslab commentedon Aug 7, 2026
Confirmed at
7e0bfdf5— and the underlying cause is more basic than "ranking needs tuning": there is no ranking at all.cli/discovery/signals.py:567-578:Candidates are appended in file-iteration then AST order, with no scoring, no length filter, and no context weighting.
cli/_register_init.py:363-364then takes the first candidate whose source isAgent_name_literalorADK_name_field. Sotdid not out-rankStrix— it was simply encountered first, and "first" is the entire policy.That explains this issue and #324 as one defect with two faces: #320 is a candidate-quality problem and #324 is a candidate-hierarchy problem, but both exist because the selection step has no notion of either. They share one function and should be fixed together, with a single ranking pass rather than two stacked filters.
Suggested split of responsibility, since the two halves have very different costs:
App(root_agent=...)to the actual coordinator. That fix subsumes this one for ADK but does nothing for Strix.Both are needed. The acceptance criterion worth adding to whichever lands first is that
agent_name_candidatescarry their ranking rationale, which #324 already asks for — without it, a future regression in ordering is invisible in the output.Labeled P2 / v0.17.0: the manifest is schema-valid and the identity is human-correctable, so it degrades interpretation rather than the gate.
[-]init: avoid selecting one-character literals as the agent name[/-][+]bug(init): avoid selecting one-character literals as the agent name[/+]fix(init): rank agent-name candidates instead of taking the first one (…