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 format #70

New Issue
Closed
opened 2026-01-21 21:20:39 +00:00 by lmiranda · 1 comment
lmiranda commented 2026-01-21 21:20:39 +00:00
Owner
Copy Link

Summary

The projman Gitea MCP tools fail when called without an explicit repo parameter, even when operating within a project that has Gitea configuration documented in CLAUDE.md.

Failed Tests

Command: /projman:labels-sync

First Attempt (Failed):

mcp__plugin_projman_gitea__validate_repo_org()
mcp__plugin_projman_gitea__get_labels()

Error Message:

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

Second Attempt (Success):

mcp__plugin_projman_gitea__validate_repo_org(repo="personal-projects/personal-portfolio")
mcp__plugin_projman_gitea__get_labels(repo="personal-projects/personal-portfolio")

Expected Behavior

The MCP tools should either:

  1. Read a default repository from project configuration (e.g., from CLAUDE.md or a .projman config file)
  2. Infer the repository from git remote configuration
  3. Provide a clearer error message suggesting how to configure a default

Repository Context

  • Project: personal-portfolio
  • Gitea Repo: personal-projects/personal-portfolio
  • Host: gitea.hotserv.cloud
  • CLAUDE.md contains: Full Gitea configuration including repo path, host, and SSH URL

Additional Observations

  • Once repo parameter is provided explicitly, all tools work correctly
  • The repo parameter is marked as optional in tool descriptions ("for PMO mode") but appears to be required
  • This creates friction for single-repo workflows where the repo should be implicit

Suggested Fix

Consider adding a configuration mechanism (environment variable, config file, or git remote detection) to set a default repository context for non-PMO workflows.

Labels: Type: Bug, Source: Internal

## Summary The projman Gitea MCP tools fail when called without an explicit `repo` parameter, even when operating within a project that has Gitea configuration documented in CLAUDE.md. ## Failed Tests **Command:** `/projman:labels-sync` **First Attempt (Failed):** ``` mcp__plugin_projman_gitea__validate_repo_org() mcp__plugin_projman_gitea__get_labels() ``` **Error Message:** ``` Error: Use 'owner/repo' format (e.g. 'org/repo-name') ``` **Second Attempt (Success):** ``` mcp__plugin_projman_gitea__validate_repo_org(repo="personal-projects/personal-portfolio") mcp__plugin_projman_gitea__get_labels(repo="personal-projects/personal-portfolio") ``` ## Expected Behavior The MCP tools should either: 1. Read a default repository from project configuration (e.g., from CLAUDE.md or a `.projman` config file) 2. Infer the repository from git remote configuration 3. Provide a clearer error message suggesting how to configure a default ## Repository Context - **Project:** personal-portfolio - **Gitea Repo:** `personal-projects/personal-portfolio` - **Host:** `gitea.hotserv.cloud` - **CLAUDE.md contains:** Full Gitea configuration including repo path, host, and SSH URL ## Additional Observations - Once repo parameter is provided explicitly, all tools work correctly - The `repo` parameter is marked as optional in tool descriptions ("for PMO mode") but appears to be required - This creates friction for single-repo workflows where the repo should be implicit ## Suggested Fix Consider adding a configuration mechanism (environment variable, config file, or git remote detection) to set a default repository context for non-PMO workflows. --- **Labels:** Type: Bug, Source: Internal
lmiranda commented 2026-01-21 21:39:29 +00:00
Author
Owner
Copy Link

Fix Applied

Root Cause

The MCP server runs with cwd set to the plugin directory (${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea), not the user's project directory. This caused:

  • Path.cwd() to return the plugin directory
  • git remote get-url origin to run in the wrong directory
  • Auto-detection to fail

Solution

Added _find_project_directory() method in config.py with multiple detection strategies:

  1. CLAUDE_PROJECT_DIR - Environment variable (if set by Claude Code)
  2. PWD - Original working directory before cwd override (if has .git or .env)
  3. cwd - Current directory fallback (for tests and direct execution)

The git remote command now runs in the detected project directory.

Tests Added

  • test_find_project_directory_from_env
  • test_find_project_directory_from_cwd
  • test_find_project_directory_none_when_no_markers

All 9 config tests passing.

PRs

  • PR #71: Fix merged to development
  • PR #72: Ready for release to main

Workaround (if needed before update)

If the fix doesn't work in your environment, set GITEA_REPO explicitly in your project's .env:

GITEA_REPO=personal-projects/personal-portfolio
## Fix Applied ### Root Cause The MCP server runs with `cwd` set to the plugin directory (`${CLAUDE_PLUGIN_ROOT}/mcp-servers/gitea`), not the user's project directory. This caused: - `Path.cwd()` to return the plugin directory - `git remote get-url origin` to run in the wrong directory - Auto-detection to fail ### Solution Added `_find_project_directory()` method in `config.py` with multiple detection strategies: 1. **CLAUDE_PROJECT_DIR** - Environment variable (if set by Claude Code) 2. **PWD** - Original working directory before cwd override (if has `.git` or `.env`) 3. **cwd** - Current directory fallback (for tests and direct execution) The git remote command now runs in the detected project directory. ### Tests Added - `test_find_project_directory_from_env` - `test_find_project_directory_from_cwd` - `test_find_project_directory_none_when_no_markers` **All 9 config tests passing.** ### PRs - PR #71: Fix merged to development - PR #72: Ready for release to main ### Workaround (if needed before update) If the fix doesn't work in your environment, set `GITEA_REPO` explicitly in your project's `.env`: ``` GITEA_REPO=personal-projects/personal-portfolio ```
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#70
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?