shoko/kugetsu
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

queue-daemon: delegate with just issue ref causes confusing agent behavior #209

New Issue
Open
opened 2026-04-07 11:13:29 +02:00 by shoko · 0 comments
shoko commented 2026-04-07 11:13:29 +02:00
Owner
Copy Link

Problem

When kugetsu delegate is called with just an issue ref as the message (e.g., kugetsu delegate "git.fbrns.co/shoko/kugetsu#118"), the agent receives the issue ref as both the issue_ref AND the message, causing confusing behavior.

Steps to Reproduce

  1. Run kugetsu delegate "git.fbrns.co/shoko/kugetsu#118"
  2. Queue item stores:
    • issue_ref: "git.fbrns.co/shoko/kugetsu#118"
    • message: "git.fbrns.co/shoko/kugetsu#118"
  3. Daemon calls cmd_continue "git.fbrns.co/shoko/kugetsu#118" "git.fbrns.co/shoko/kugetsu#118"
  4. Agent receives: "Additional instructions from delegator: git.fbrns.co/shoko/kugetsu#118"
  5. Agent gets confused because issue ref looks like a partial instruction

Root Cause

In cmd_delegate (kugetsu-session.sh:205-208):

if [ -n "$issue_ref" ] && [[ "$issue_ref" =~ \#[0-9]+$ ]]; then
    enqueue_task "$issue_ref" "$message"

When message == issue_ref, both get stored identically in the queue item.

Related Problem: Partial Issue Refs

Additionally, extract_issue_ref_from_message does not handle:

  • Natural language like "work on issue #81", "create pr for issue #91"
  • Partial refs like user/repo#81 or repo#81
  • Just #81 or 81

Proposed resolution order for partial refs:

  1. Check existing sessions/worktrees (have full issue ref stored)
  2. Check repos.json if it exists
  3. Check GIT_SERVERS - try to match against known repos on each server

Ambiguity handling (TBD): If issue number exists in multiple repos, should pick most recent session/worktree OR error listing matches.

Suggested Fix

TBD - requires deciding on partial ref resolution strategy above.

## Problem When `kugetsu delegate` is called with just an issue ref as the message (e.g., `kugetsu delegate "git.fbrns.co/shoko/kugetsu#118"`), the agent receives the issue ref as both the issue_ref AND the message, causing confusing behavior. ## Steps to Reproduce 1. Run `kugetsu delegate "git.fbrns.co/shoko/kugetsu#118"` 2. Queue item stores: - `issue_ref: "git.fbrns.co/shoko/kugetsu#118"` - `message: "git.fbrns.co/shoko/kugetsu#118"` 3. Daemon calls `cmd_continue "git.fbrns.co/shoko/kugetsu#118" "git.fbrns.co/shoko/kugetsu#118"` 4. Agent receives: "Additional instructions from delegator: git.fbrns.co/shoko/kugetsu#118" 5. Agent gets confused because issue ref looks like a partial instruction ## Root Cause In `cmd_delegate` (kugetsu-session.sh:205-208): ```bash if [ -n "$issue_ref" ] && [[ "$issue_ref" =~ \#[0-9]+$ ]]; then enqueue_task "$issue_ref" "$message" ``` When `message == issue_ref`, both get stored identically in the queue item. ## Related Problem: Partial Issue Refs Additionally, `extract_issue_ref_from_message` does not handle: - Natural language like "work on issue #81", "create pr for issue #91" - Partial refs like `user/repo#81` or `repo#81` - Just `#81` or `81` Proposed resolution order for partial refs: 1. Check existing sessions/worktrees (have full issue ref stored) 2. Check repos.json if it exists 3. Check GIT_SERVERS - try to match against known repos on each server Ambiguity handling (TBD): If issue number exists in multiple repos, should pick most recent session/worktree OR error listing matches. ## Suggested Fix TBD - requires deciding on partial ref resolution strategy above.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.2.x-only
Available only in 0.2.x, not backportable
 0.3.x-only
Available only in 0.3.x, not backportable
 backport
Backport compatible - can merge to 0.1.x
 blocked
Issue needs clarification/discussion before it can be worked on
 bug
Bug report
 critical
Critical - blocking parallel work
 feature
New feature
 foundation
Foundation work for 0.2.x
 high
High priority - workflow improvements
 meta
Meta issue tracking multiple issues
 need-review
PR needs review before merge
 parallelization
Issues related to parallelization
 ready
Issue is clear and ready to be implemented/delegated
 ready-to-merge
PR approved and ready to merge
 task-delegation
Issues related to task-delegation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
shoko
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: shoko/kugetsu#209
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?