Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 74 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Disambiguate target repo names and require Gitea-Tools inventory when user references the MCP Gitea tool #184

New Issue
Closed
opened 2026-07-05 14:27:36 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-05 14:27:36 -05:00
Owner
Copy Link
Copy Source

Problem:
A reviewer run authenticated correctly as sysadmin / prgs-reviewer, but only checked:

  • Scaled-Tech-Consulting/mcp-control-plane

It reported no open PRs and stopped. However, the user was referring to the MCP Gitea tooling repo, and Scaled-Tech-Consulting/Gitea-Tools still had open PRs.

Observed report:

  • Repository checked: Scaled-Tech-Consulting/mcp-control-plane
  • Live gitea_list_prs(state=open) returned no PRs.
  • No PR selected.
  • No review/merge performed.

Problem:
The run incorrectly treated mcp-control-plane as the only target repo. In this project context, phrases like “MCP Gitea tool,” “gitea tool,” or “gitea-tools” should resolve to:

  • Scaled-Tech-Consulting/Gitea-Tools

not only:

  • Scaled-Tech-Consulting/mcp-control-plane

Required behavior:

  1. Add repo-name disambiguation rules:

    • “Gitea-Tools”
    • “gitea tool”
    • “MCP Gitea tool”
    • “gitea MCP tool”
    • “gitea-tools repo”

    should map to Scaled-Tech-Consulting/Gitea-Tools.

  2. “mcp-control-plane” should map only to Scaled-Tech-Consulting/mcp-control-plane.

  3. If the user says “open PRs” without an explicit repo, default to checking all configured repos:

    • Scaled-Tech-Consulting/Gitea-Tools
    • Scaled-Tech-Consulting/mcp-control-plane

  4. If the workflow checks only one repo, the final report must say:

    • “Only <repo> was checked.”
    • “Other configured repos were not checked.”
    • “This is not a complete queue inventory.”

  5. If the user’s wording is ambiguous between the two repos, the workflow must either:

    • check both repos, or
    • explicitly state the ambiguity and avoid claiming no open PRs globally.

  6. Add tests/harness assertions:

    • “MCP Gitea tool has open PRs” checks Scaled-Tech-Consulting/Gitea-Tools
    • “mcp-control-plane has open PRs” checks Scaled-Tech-Consulting/mcp-control-plane
    • “review open PRs” checks both configured repos
    • single-repo zero result cannot hide open PRs in the other configured repo
    • final report must include repo scope and configured repos not checked

Acceptance criteria:

  • A reviewer run must not report “no open PRs” when it only checked mcp-control-plane and Gitea-Tools has open PRs.
  • Repo naming must be explicit and unambiguous in the final report.
  • Blind queue review must inventory all configured repos before stopping.

Related: #173, #175, #179 (review proofs hardening)

Problem: A reviewer run authenticated correctly as `sysadmin / prgs-reviewer`, but only checked: * `Scaled-Tech-Consulting/mcp-control-plane` It reported no open PRs and stopped. However, the user was referring to the MCP Gitea tooling repo, and `Scaled-Tech-Consulting/Gitea-Tools` still had open PRs. Observed report: * Repository checked: `Scaled-Tech-Consulting/mcp-control-plane` * Live `gitea_list_prs(state=open)` returned no PRs. * No PR selected. * No review/merge performed. Problem: The run incorrectly treated `mcp-control-plane` as the only target repo. In this project context, phrases like “MCP Gitea tool,” “gitea tool,” or “gitea-tools” should resolve to: * `Scaled-Tech-Consulting/Gitea-Tools` not only: * `Scaled-Tech-Consulting/mcp-control-plane` Required behavior: 1. Add repo-name disambiguation rules: * “Gitea-Tools” * “gitea tool” * “MCP Gitea tool” * “gitea MCP tool” * “gitea-tools repo” should map to `Scaled-Tech-Consulting/Gitea-Tools`. 2. “mcp-control-plane” should map only to `Scaled-Tech-Consulting/mcp-control-plane`. 3. If the user says “open PRs” without an explicit repo, default to checking all configured repos: * `Scaled-Tech-Consulting/Gitea-Tools` * `Scaled-Tech-Consulting/mcp-control-plane` 4. If the workflow checks only one repo, the final report must say: * “Only `<repo>` was checked.” * “Other configured repos were not checked.” * “This is not a complete queue inventory.” 5. If the user’s wording is ambiguous between the two repos, the workflow must either: * check both repos, or * explicitly state the ambiguity and avoid claiming no open PRs globally. 6. Add tests/harness assertions: * “MCP Gitea tool has open PRs” checks `Scaled-Tech-Consulting/Gitea-Tools` * “mcp-control-plane has open PRs” checks `Scaled-Tech-Consulting/mcp-control-plane` * “review open PRs” checks both configured repos * single-repo zero result cannot hide open PRs in the other configured repo * final report must include repo scope and configured repos not checked Acceptance criteria: * A reviewer run must not report “no open PRs” when it only checked `mcp-control-plane` and `Gitea-Tools` has open PRs. * Repo naming must be explicit and unambiguous in the final report. * Blind queue review must inventory all configured repos before stopping. Related: #173, #175, #179 (review proofs hardening)
sysadmin commented 2026-07-05 14:34:42 -05:00
Owner
Copy Link
Copy Source

Review fallback after PR #185 closed before I could submit a verdict.

I found a concrete follow-up blocker at pinned PR head e2bccbafeeb93124ba068bfb06058d5aa7467cae: the new docs say ambiguous wording such as MCP Gitea tooling must inventory both configured repos, but resolve_repos_from_user_reference() currently resolves that phrase to only Scaled-Tech-Consulting/Gitea-Tools because the alias check uses substring matching and matches tool inside tooling.

Reproduction run at the pinned head:

MCP Gitea tooling => ['Scaled-Tech-Consulting/Gitea-Tools']
MCP Gitea tool => ['Scaled-Tech-Consulting/Gitea-Tools']
review open PRs => ['Scaled-Tech-Consulting/Gitea-Tools', 'Scaled-Tech-Consulting/mcp-control-plane']

Expected per the PR's own workflow docs/template: MCP Gitea tooling without an explicit repo should be treated as ambiguous and inventory both Scaled-Tech-Consulting/Gitea-Tools and Scaled-Tech-Consulting/mcp-control-plane.

Validation before the PR closed:

  • python3 -m py_compile review_proofs.py tests/test_review_proofs.py: exit 0
  • git diff --check prgs/master...HEAD: exit 0
  • ./venv/bin/python -m pytest tests/test_review_proofs.py -q --tb=no: 42 passed in 0.03s
  • ./venv/bin/python -m pytest tests/test_review_proofs.py tests/test_pr_queue_inventory.py -q --tb=no: 58 passed in 0.73s
  • Secret/provenance grep over the PR diff: no matches

No review, merge, issue closure, branch, or PR mutation was performed by my run. This comment is the fallback escalation because the PR closed before review submission.

Review fallback after PR #185 closed before I could submit a verdict. I found a concrete follow-up blocker at pinned PR head `e2bccbafeeb93124ba068bfb06058d5aa7467cae`: the new docs say ambiguous wording such as `MCP Gitea tooling` must inventory both configured repos, but `resolve_repos_from_user_reference()` currently resolves that phrase to only `Scaled-Tech-Consulting/Gitea-Tools` because the alias check uses substring matching and matches `tool` inside `tooling`. Reproduction run at the pinned head: ```text MCP Gitea tooling => ['Scaled-Tech-Consulting/Gitea-Tools'] MCP Gitea tool => ['Scaled-Tech-Consulting/Gitea-Tools'] review open PRs => ['Scaled-Tech-Consulting/Gitea-Tools', 'Scaled-Tech-Consulting/mcp-control-plane'] ``` Expected per the PR's own workflow docs/template: `MCP Gitea tooling` without an explicit repo should be treated as ambiguous and inventory both `Scaled-Tech-Consulting/Gitea-Tools` and `Scaled-Tech-Consulting/mcp-control-plane`. Validation before the PR closed: - `python3 -m py_compile review_proofs.py tests/test_review_proofs.py`: exit 0 - `git diff --check prgs/master...HEAD`: exit 0 - `./venv/bin/python -m pytest tests/test_review_proofs.py -q --tb=no`: `42 passed in 0.03s` - `./venv/bin/python -m pytest tests/test_review_proofs.py tests/test_pr_queue_inventory.py -q --tb=no`: `58 passed in 0.73s` - Secret/provenance grep over the PR diff: no matches No review, merge, issue closure, branch, or PR mutation was performed by my run. This comment is the fallback escalation because the PR closed before review submission.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#184