Add dual-profile MCP launcher pattern to eliminate identity-relaunch bottleneck #109

New Issue

2026-07-02T18:07:35-05:00

sysadmin commented

2026-07-02 18:07:35 -05:00

Summary

Document and support a dual-profile MCP launcher pattern so author and reviewer identities can be available at the same time without relaunching the MCP server.

Problem

The current workflow repeatedly stalls when a task needs a different Gitea identity.

Observed examples:

PR review/merge attempts blocked because the active identity was also the PR author.
Work had to stop while waiting for a human to relaunch MCP with another profile.
PRs created with the reviewer identity can deadlock review because the reviewer identity becomes the PR author (see #102 incident and #103/#108 branches stalled awaiting an author-profile PR step).
Claiming an issue before confirming the needed identity can waste the claim.

The trust model is sound, but the workflow mechanics are too slow.

Proposed direction

Document a dual-server launcher pattern:

register one MCP server as gitea-author
register one MCP server as gitea-reviewer
both use the same server code
each uses a different GITEA_MCP_PROFILE
tools become identity-scoped, for example:
- mcp__gitea-author__*
- mcp__gitea-reviewer__*

This preserves separate tokens and separate profile gates while avoiding relaunch delays.

Fallback if dual-server is rejected

Add an identity checklist to every relevant template:

State which profile this task needs before claiming the issue.
If whoami does not match the required profile, stop before claiming.

Scope

Update workflow docs/templates.
Add launcher examples.
Clarify when to use author vs reviewer identity.
Warn against creating PRs with reviewer/merge identities unless explicitly intended.
Add "required profile" check to start/review/merge templates.

Non-goals

Do not weaken identity gates.
Do not allow self-review or self-merge.
Do not merge author/reviewer credentials.
Do not store secrets in docs.
Do not implement profiles.json v2 in this issue.

Acceptance criteria

Docs show dual-profile MCP launcher pattern.
Templates require identifying the needed profile before claiming work.
Reviewer/merge identity PR-creation deadlock is documented.
The trust model remains unchanged.
No secrets are introduced.

Related: #107 (MDCPS reviewer provisioning), #100 (profiles.json v2 discussion).

## Summary Document and support a dual-profile MCP launcher pattern so author and reviewer identities can be available at the same time without relaunching the MCP server. ## Problem The current workflow repeatedly stalls when a task needs a different Gitea identity. Observed examples: - PR review/merge attempts blocked because the active identity was also the PR author. - Work had to stop while waiting for a human to relaunch MCP with another profile. - PRs created with the reviewer identity can deadlock review because the reviewer identity becomes the PR author (see #102 incident and #103/#108 branches stalled awaiting an author-profile PR step). - Claiming an issue before confirming the needed identity can waste the claim. The trust model is sound, but the workflow mechanics are too slow. ## Proposed direction Document a dual-server launcher pattern: - register one MCP server as `gitea-author` - register one MCP server as `gitea-reviewer` - both use the same server code - each uses a different `GITEA_MCP_PROFILE` - tools become identity-scoped, for example: - `mcp__gitea-author__*` - `mcp__gitea-reviewer__*` This preserves separate tokens and separate profile gates while avoiding relaunch delays. ## Fallback if dual-server is rejected Add an identity checklist to every relevant template: ```text State which profile this task needs before claiming the issue. If whoami does not match the required profile, stop before claiming. ``` ## Scope * Update workflow docs/templates. * Add launcher examples. * Clarify when to use author vs reviewer identity. * Warn against creating PRs with reviewer/merge identities unless explicitly intended. * Add "required profile" check to start/review/merge templates. ## Non-goals * Do not weaken identity gates. * Do not allow self-review or self-merge. * Do not merge author/reviewer credentials. * Do not store secrets in docs. * Do not implement profiles.json v2 in this issue. ## Acceptance criteria * Docs show dual-profile MCP launcher pattern. * Templates require identifying the needed profile before claiming work. * Reviewer/merge identity PR-creation deadlock is documented. * The trust model remains unchanged. * No secrets are introduced. Related: #107 (MDCPS reviewer provisioning), #100 (profiles.json v2 discussion).