personal-projects/leo-claude-mktplace
Template
0
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[Bug] Projman diagnostic failure: MCP tools require explicit repo parameter #73

New Issue
Closed
opened 2026-01-21 21:48:16 +00:00 by lmiranda · 2 comments
lmiranda commented 2026-01-21 21:48:16 +00:00
Owner
Copy Link

Overview

During /projman:labels-sync execution on the personal-projects/personal-portfolio repository, several issues were encountered with the MCP Gitea tools.

Failed Tests / Error Messages

1. Missing Default Repository Configuration

Error:

Error: Use 'owner/repo' format (e.g. 'org/repo-name')

Context: Called validate_repo_org and get_labels without explicit repo parameter.

Expected: Tools should use a default repository from project context (e.g., from .claude/ config or working directory git remote).

Actual: Tools fail immediately without explicit repo parameter on every call.

2. Empty Organization Labels Array

Response:

{
  "organization": [],
  "repository": [...18 labels...]
}

Context: Repository personal-projects/personal-portfolio belongs to org personal-projects.

Uncertainty: Unable to determine if:

  • Organization genuinely has no org-level labels (expected behavior)
  • There's an API issue fetching org-level labels (bug)

Suggested Fix: Add diagnostic output or verification step to confirm org label fetch succeeded vs returned empty.

3. Label Naming Convention Mismatch

Documentation states: Labels use slash format (Type/Bug, Priority/High)

Actual Gitea labels: Colon-space format (Type: Bug, Priority: High)

Impact: The suggest_labels tool may return suggestions in wrong format, or documentation is outdated.

Repository Context

  • Repository tested: personal-projects/personal-portfolio
  • Gitea host: gitea.hotserv.cloud
  • Skill invoked: /projman:labels-sync
  • MCP tools used: validate_repo_org, get_labels

Reproduction Steps

  1. Navigate to any projman-configured repository
  2. Run /projman:labels-sync
  3. Observe first MCP call fails without explicit repo parameter
  4. Note organization labels array is empty
  5. Compare label format in response vs skill documentation

Suggested Fixes

  1. Default repo resolution: Implement repo detection from git remote or .claude/ project config
  2. Org labels diagnostic: Add confirmation message when org has no labels vs fetch failure
  3. Documentation update: Align label format in skill docs with actual Gitea convention

Labels: Type: Bug, Source: Internal

## Overview During `/projman:labels-sync` execution on the `personal-projects/personal-portfolio` repository, several issues were encountered with the MCP Gitea tools. ## Failed Tests / Error Messages ### 1. Missing Default Repository Configuration **Error:** ``` Error: Use 'owner/repo' format (e.g. 'org/repo-name') ``` **Context:** Called `validate_repo_org` and `get_labels` without explicit `repo` parameter. **Expected:** Tools should use a default repository from project context (e.g., from `.claude/` config or working directory git remote). **Actual:** Tools fail immediately without explicit `repo` parameter on every call. ### 2. Empty Organization Labels Array **Response:** ```json { "organization": [], "repository": [...18 labels...] } ``` **Context:** Repository `personal-projects/personal-portfolio` belongs to org `personal-projects`. **Uncertainty:** Unable to determine if: - Organization genuinely has no org-level labels (expected behavior) - There's an API issue fetching org-level labels (bug) **Suggested Fix:** Add diagnostic output or verification step to confirm org label fetch succeeded vs returned empty. ### 3. Label Naming Convention Mismatch **Documentation states:** Labels use slash format (`Type/Bug`, `Priority/High`) **Actual Gitea labels:** Colon-space format (`Type: Bug`, `Priority: High`) **Impact:** The `suggest_labels` tool may return suggestions in wrong format, or documentation is outdated. ## Repository Context - **Repository tested:** `personal-projects/personal-portfolio` - **Gitea host:** `gitea.hotserv.cloud` - **Skill invoked:** `/projman:labels-sync` - **MCP tools used:** `validate_repo_org`, `get_labels` ## Reproduction Steps 1. Navigate to any projman-configured repository 2. Run `/projman:labels-sync` 3. Observe first MCP call fails without explicit repo parameter 4. Note organization labels array is empty 5. Compare label format in response vs skill documentation ## Suggested Fixes 1. **Default repo resolution:** Implement repo detection from git remote or `.claude/` project config 2. **Org labels diagnostic:** Add confirmation message when org has no labels vs fetch failure 3. **Documentation update:** Align label format in skill docs with actual Gitea convention --- **Labels:** `Type: Bug`, `Source: Internal`
lmiranda commented 2026-01-21 21:54:55 +00:00
Author
Owner
Copy Link

Investigation Results

Sub-issue 1: Missing repo parameter ✅ ALREADY FIXED

Fixed in PRs #70, #71, #72. The _find_project_directory() and _detect_repo_from_git() methods now handle repo auto-detection from git remote.

Sub-issue 2: Empty organization labels ✅ EXPECTED BEHAVIOR

The personal-projects organization simply has no org-level labels defined in Gitea. This is not a bug - the labels exist only at the repository level in this case.

Sub-issue 3: Label format mismatch 🔧 NEEDS FIX

Confirmed issue. The suggest_labels function hardcodes slash format while the repository uses colon-space format:

suggest_labels output Actual Gitea label
Type/Bug Type: Bug
Priority/High Priority: High
Complexity/Medium Complexity: Medium
Efforts/M Effort: M (singular)

Root cause: labels.py:suggest_labels() hardcodes label names without checking actual labels in the repository.

Fix approach: Modify suggest_labels to:

  1. Fetch actual labels from the repository first
  2. Match keywords to existing label patterns dynamically
  3. Return only labels that actually exist in the repo

Working on the fix now.

## Investigation Results ### Sub-issue 1: Missing repo parameter ✅ ALREADY FIXED Fixed in PRs #70, #71, #72. The `_find_project_directory()` and `_detect_repo_from_git()` methods now handle repo auto-detection from git remote. ### Sub-issue 2: Empty organization labels ✅ EXPECTED BEHAVIOR The `personal-projects` organization simply has no org-level labels defined in Gitea. This is not a bug - the labels exist only at the repository level in this case. ### Sub-issue 3: Label format mismatch 🔧 NEEDS FIX **Confirmed issue.** The `suggest_labels` function hardcodes slash format while the repository uses colon-space format: | suggest_labels output | Actual Gitea label | |----------------------|-------------------| | `Type/Bug` | `Type: Bug` | | `Priority/High` | `Priority: High` | | `Complexity/Medium` | `Complexity: Medium` | | `Efforts/M` | `Effort: M` (singular) | **Root cause:** `labels.py:suggest_labels()` hardcodes label names without checking actual labels in the repository. **Fix approach:** Modify `suggest_labels` to: 1. Fetch actual labels from the repository first 2. Match keywords to existing label patterns dynamically 3. Return only labels that actually exist in the repo Working on the fix now.
lmiranda commented 2026-01-21 22:05:51 +00:00
Author
Owner
Copy Link

Resolution

All three sub-issues have been addressed:

Sub-issue Status Resolution
1. Missing repo parameter ✅ Fixed PRs #70, #71, #72 (already merged)
2. Empty org labels ✅ Expected Org has no labels configured (not a bug)
3. Label format mismatch ✅ Fixed PR #75 (merged to development), PR #76 (to main)

Fix Details (Sub-issue 3)

The suggest_labels function now dynamically detects the label naming convention:

  • Fetches actual labels from repository first
  • Builds a lookup map supporting multiple formats (slash, colon-space, etc.)
  • Returns suggestions that match actual label names in the repo
  • Handles Effort/Efforts normalization (singular/plural)

PRs:

  • #75: Merged to development ✅
  • #76: Pending merge to main

This issue can be closed once PR #76 is merged.

## Resolution All three sub-issues have been addressed: | Sub-issue | Status | Resolution | |-----------|--------|------------| | 1. Missing repo parameter | ✅ Fixed | PRs #70, #71, #72 (already merged) | | 2. Empty org labels | ✅ Expected | Org has no labels configured (not a bug) | | 3. Label format mismatch | ✅ Fixed | PR #75 (merged to development), PR #76 (to main) | ### Fix Details (Sub-issue 3) The `suggest_labels` function now dynamically detects the label naming convention: - Fetches actual labels from repository first - Builds a lookup map supporting multiple formats (slash, colon-space, etc.) - Returns suggestions that match actual label names in the repo - Handles Effort/Efforts normalization (singular/plural) **PRs:** - #75: Merged to development ✅ - #76: Pending merge to main This issue can be closed once PR #76 is merged.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Component/API
API endpoints, contracts, and integration
 Component/Auth
Authentication and authorization
 Component/Backend
Backend service code and business logic
 Component/Database
Database schemas, migrations, queries
 Component/Deploy
Deployment, infrastructure, DevOps
 Component/Docs
Documentation and guides
 Component/Frontend
User interface and client-side code
 Component/Infra
Infrastructure and system configuration
 Component/Testing
Test infrastructure and frameworks
 Tech/Docker
Docker containers and compose
 Tech/FastAPI
FastAPI backend framework
 Tech/JavaScript
JavaScript/Node.js code
 Tech/PostgreSQL
PostgreSQL database
 Tech/Python
Python language and libraries
 Tech/Redis
Redis cache and pub/sub
 Tech/Vue
Vue.js frontend framework
Complexity/Complex
High uncertainty or many dependencies
 Complexity/Medium
Some unknowns or dependencies
 Complexity/Simple
Straightforward, well-understood
 Effort/L
3-5 days
 Effort/M
1-2 days
 Effort/S
2-4 hours
 Effort/XL
> 1 week
 Effort/XS
< 2 hours
 Priority/Critical
Immediate attention required
 Priority/High
Important, needs attention soon
 Priority/Low
Nice to have, can wait
 Priority/Medium
Normal priority
 Type/Bug
Something isn't working
 Type/Chore
Maintenance tasks
 Type/Documentation
Documentation improvements
 Type/Feature
New feature or request
 Type/Refactor
Code refactoring without changing behavior
 Type/Test
Testing related
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
lmiranda
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: personal-projects/leo-claude-mktplace#73
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?