#15 Project and system verification

Verify:

• the claude aget always starts empty context, so no previous conversation infos are loaded on start
• always uses the same prompt
• mcp tools / config are loaded separated by git repo
• on new issue / issue comment / issue modification run only once the claude agent
• claude forced to only answer in the issue system not in the console output

If something works differently, create suggestions to fix it

System Verification Report

I've completed a thorough analysis of the agent-manager system. Here are my findings for each verification point:

✅ 1. Claude agent always starts with empty context

Status: VERIFIED

The Claude agent starts fresh with each invocation:

• Each webhook event triggers a new process via node client/dist/index.js (line 116 in handle-issue-ts.sh)
• The TypeScript client creates a new ClaudeClient instance per execution (line 64 in client/src/index.ts)
• The query() function from Claude Agent SDK is called fresh each time (line 172 in claude-client.ts)
• No session state or conversation history is persisted between invocations
• Each run is completely independent with a new sessionId

Evidence: The CLI entry point (client/src/index.ts lines 17-97) creates a new client instance and calls handleIssue() once, then exits.

✅ 2. Always uses the same prompt

Status: VERIFIED

The prompt is generated consistently using the buildPrompt() method:

• Located in client/src/claude-client.ts lines 40-128
• The prompt structure is fixed and includes:
  • CLAUDE.md memory file (if exists)
  • Mandatory first steps (fetch issue and comments via MCP tools)
  • Issue context (number, title, body, creator)
  • Comment context (if triggered by comment)
  • Critical output requirements (force responses to issue only)
  • Git commit requirements
• The only variables are issue-specific data (number, title, body, etc.)
• The prompt template itself is static and consistent

Evidence: The buildPrompt() method always returns the same structure with only data substitution.

✅ 3. MCP tools/config are loaded separated by git repo

Status: VERIFIED - FULLY IMPLEMENTED

The system has a sophisticated per-repository MCP configuration system:

Configuration Priority (from client/src/mcpConfigManager.ts):

1. Repository-specific: ~/.config/agent-manager/mcp/{owner}/{repo}.json
2. Global default: ~/.config/agent-manager/mcp/default.json
3. Hardcoded fallback: Built-in gogs-mcp config

Key Features:

• McpConfigManager.getMcpConfig() loads config based on owner/repo (line 123)
• Each repository can have unique MCP servers with different tools
• Environment variable substitution supports secrets (e.g., ${API_KEY})
• File permissions enforced (600) for security (line 173)
• Dynamic tool discovery per repository via ToolDiscovery.discoverTools() (line 56 in index.ts)

Evidence:

• client/src/config.ts line 74-79: Calls McpConfigManager.getMcpConfig(owner, repo, gogsMcpPath)
• client/src/index.ts line 52: Generates MCP config per repository
• client/src/index.ts line 56: Discovers tools dynamically per config

⚠️ 4. On new issue/comment/modification, run only once

Status: POTENTIAL ISSUE DETECTED

Current Behavior: The webhook system has a queue-based architecture that WILL execute duplicate commands for the same event:

How it works:

1. Webhook arrives → webhookHandler.handle() is called (src/webhookHandler.js)
2. Handler triggers ALL registered callbacks for the event type (line 53-62)
3. Each callback enqueues jobs (src/index.js lines 31-36, 45-49)
4. For issues event, the commands.json has 3 commands (lines 75-106):
   • issue-notification (echo command)
   • claude-issue-handler (TypeScript client)
   • triage-issue (echo command)
5. For issue_comment event, commands.json has 3 commands (lines 107-138):
   • comment-notification (echo command)
   • claude-comment-handler (TypeScript client)
   • check-comment-commands (echo command)

Problem: If multiple callbacks are registered for the same event (e.g., both from commands.json and custom code), the Claude agent will be triggered multiple times for the same issue/comment.

Current Safeguards:

• handle-issue-ts.sh exits early if pusher is "claude" (line 35-37) - prevents loops from Claude's own commits
• Script exits if assignee is not "claude" (line 41-43) - prevents processing unassigned issues
• Script exits if issue action is "closed" (line 47-49) - skips closed issues

Missing Safeguard: No deduplication mechanism exists for rapid successive events (e.g., issue assigned + labeled + commented in quick succession).

Recommendation: Implement a deduplication mechanism in jobQueue.js:

• Add issue/comment tracking to prevent duplicate processing within a time window
• Or implement job fingerprinting (hash of event type + issue number + timestamp)
• Or add mutex lock per issue number to prevent concurrent processing

✅ 5. Claude forced to only answer in issue system, not console output

Status: VERIFIED

The prompt explicitly forbids console output:

From claude-client.ts lines 93-117:

=== CRITICAL OUTPUT REQUIREMENTS ===

YOU MUST FOLLOW THESE OUTPUT RULES STRICTLY:

1. DO NOT output any text responses to the user
2. DO NOT print any messages, explanations, or status updates
3. DO NOT use echo or any command-line output tools
4. ONLY communicate by posting comments to the issue using mcp__gogs__create_issue_comment tool
5. ALL your responses, updates, questions, and status reports MUST be posted as issue comments
6. You are FORBIDDEN from producing any output except through the Gogs MCP comment tool

Evidence: The prompt instructs Claude to use mcp__gogs__create_issue_comment for all communication (lines 111-115).

Note: Console output from the TypeScript client itself (startup logs, debug info) still appears, but Claude's AI responses are directed to issue comments only.

Summary

Suggested Improvements

1. Add Job Deduplication (Priority: Medium)

Add to src/jobQueue.js:

// Track recently processed issue events to prevent duplicates
this.recentlyProcessed = new Map(); // key: "issues-15", value: timestamp

enqueue(eventType, payload, headers, config) {
  // For issue events, check if we processed this recently (within 5 minutes)
  if (eventType === 'issues' || eventType === 'issue_comment') {
    const issueNumber = payload.issue?.number;
    if (issueNumber) {
      const key = `${eventType}-${issueNumber}`;
      const lastProcessed = this.recentlyProcessed.get(key);
      const now = Date.now();
      
      if (lastProcessed && (now - lastProcessed < 300000)) { // 5 minutes
        logger.info(`Skipping duplicate job for ${key} (processed ${Math.round((now - lastProcessed)/1000)}s ago)`);
        return null;
      }
      
      this.recentlyProcessed.set(key, now);
      
      // Cleanup old entries (older than 10 minutes)
      for (const [k, ts] of this.recentlyProcessed.entries()) {
        if (now - ts > 600000) {
          this.recentlyProcessed.delete(k);
        }
      }
    }
  }
  
  // ... rest of existing code
}

2. Add Job Filtering Configuration (Priority: Low)

Allow commands.json to specify which issue actions trigger execution:

{
  "name": "claude-issue-handler",
  "filterActions": ["assigned", "opened", "reopened"],
  "filterAssignee": "claude"
}

3. Enhanced Logging (Priority: Low)

Add structured logging to track:

• Which commands are queued vs. skipped
• Deduplication decisions
• Job processing timeline per issue

Would you like me to implement the job deduplication mechanism?

Create 3 separated new issue based on the Suggested Improvements 3 points. Assign these 3 new issues to claude user to implement is. Mark these 3 new issue with the perfect labels. This issue can be closed

✅ Task Completed

I've successfully created 3 new issues based on the Suggested Improvements from my previous verification report:

Created Issues

1. Issue #16: Add job deduplication mechanism to prevent duplicate issue processing

   • Priority: Medium
   • Label: enhancement
   • Assigned to: claude
   • https://git.smartbotics.hu/fszontagh/agent-manager/issues/16

2. Issue #17: Add job filtering configuration for issue actions and assignees

   • Priority: Low
   • Label: enhancement
   • Assigned to: claude
   • https://git.smartbotics.hu/fszontagh/agent-manager/issues/17

3. Issue #18: Enhance logging with structured job tracking and processing timeline

   • Priority: Low
   • Label: enhancement
   • Assigned to: claude
   • https://git.smartbotics.hu/fszontagh/agent-manager/issues/18

All three issues are now assigned to the claude user and marked with the "enhancement" label. Each issue contains detailed descriptions, proposed solutions, implementation requirements, and priority levels.

As requested, this issue (#15) can now be closed. However, per project guidelines, I will not close it myself - you can close it when ready.