docs: document dual-profile MCP launcher pattern and add identity checklist (#109) (#113)

Co-authored-by: Jason Walker <913443@dadeschools.net>
Co-committed-by: Jason Walker <913443@dadeschools.net>
This commit was merged in pull request #113.
This commit is contained in:
2026-07-02 18:18:43 -05:00
committed by jcwalker3
parent 790c2c80b1
commit 2e2da05eab
5 changed files with 61 additions and 18 deletions
+29 -2
View File
@@ -124,8 +124,35 @@ and the two `GITEA_MCP_*` variables — never a token or password:
}
```
Run the same server as several launcher entries (e.g. `-author`, `-reviewer`,
`-merger`), each pointing at a different `GITEA_MCP_PROFILE`.
### Dual-profile MCP launcher pattern (Recommended)
To avoid the bottleneck of relaunching/restarting the MCP server to switch between author and reviewer roles, the client should register **both** profiles concurrently as separate server instances in the client's MCP configuration:
```json
"gitea-author": {
"command": "/path/to/Gitea-Tools/venv/bin/python3",
"args": ["/path/to/Gitea-Tools/mcp_server.py"],
"env": {
"GITEA_MCP_CONFIG": "/path/to/.config/gitea-tools/profiles.json",
"GITEA_MCP_PROFILE": "prgs-author"
}
},
"gitea-reviewer": {
"command": "/path/to/Gitea-Tools/venv/bin/python3",
"args": ["/path/to/Gitea-Tools/mcp_server.py"],
"env": {
"GITEA_MCP_CONFIG": "/path/to/.config/gitea-tools/profiles.json",
"GITEA_MCP_PROFILE": "prgs-reviewer"
}
}
```
* **Tool Namespaces:** Tool calls become distinct and identity-scoped in the client UI:
* `mcp__gitea-author__*` (for creating issues, pushing branches, creating PRs)
* `mcp__gitea-reviewer__*` (for reviewing PRs, approving, requesting changes, merging)
* **Trust Model:** Separate tokens remain separate in the keychain/environment. Each instance operates under its own `GITEA_MCP_PROFILE` and enforces its own `allowed_operations`. A runtime `whoami` identity check is still performed independently, and self-review/self-merge checks remain strictly mandatory. The dual-server pattern is a operational convenience and never a security bypass.
* **Reviewer-Identity PR Creation Deadlock:** Reviewer/merge identities must not create PRs or push branches. Doing so makes the reviewer identity the PR author in Gitea, blocking subsequent independent review and causing a review deadlock. Normally, PRs must be created by the author/work identity (`gitea-author`), leaving the reviewer identity (`gitea-reviewer`) clean and available for independent review and merge.
* **Fallback:** If the dual-profile MCP launcher pattern is not supported or configured in the client, the LLM must relaunch or restart the client/MCP with the correct profile environment variable before claiming or working on any tasks.
## Setup runbook — interactive menu
+8 -7
View File
@@ -116,16 +116,17 @@ interpreter path, or create a venv inside the branch folder.
## C. Identity and profile safety
- Use canonical execution profiles where available; the profile is the role, not
the LLM. A task selects a profile; a profile is not permanently assigned.
- Use canonical execution profiles where available; the profile is the role, not the LLM. A task selects a profile; a profile is not permanently assigned.
- **Author and reviewer identities must be distinct.**
- Never place raw tokens/passwords in an LLM/MCP client config. Reference secrets
by keychain id or environment variable name only. Prefer a single canonical
config file selected by two env vars, e.g.:
- Never place raw tokens/passwords in an LLM/MCP client config. Reference secrets by keychain id or environment variable name only. Prefer a single canonical config file selected by two env vars, e.g.:
- `GITEA_MCP_CONFIG` — path to the canonical profiles file
- `GITEA_MCP_PROFILE` — the profile to activate
- **If the authenticated user equals the PR author, stop** — no self-review, no
self-merge.
- **Dual-Profile MCP Launcher Pattern (Recommended):** To avoid relaunch bottlenecks and PR-author deadlocks, register multiple instances of the same MCP server in the client's configuration simultaneously (e.g., `gitea-author` and `gitea-reviewer`), each pointing to its respective `GITEA_MCP_PROFILE`.
- Tool calls become namespace-scoped: `mcp__gitea-author__*` and `mcp__gitea-reviewer__*`.
- **Trust Model:** Separate tokens remain separate. Profile gates enforce allowed operations, `whoami` is still checked, and self-review/self-merge prevention remains mandatory. This pattern is for convenience and does not bypass security gates.
- **Deadlock Warning:** Reviewer/merge identities must not be used to create PRs, as this makes the reviewer the PR author in Gitea and blocks independent review. PRs should normally be created by the author/work identity, keeping the reviewer identity available for reviews.
- **Fallback:** If a dual-server launcher is not available in the client, relaunch or restart the client with the correct profile environment variable before claiming work.
- **If the authenticated user equals the PR author, stop** — no self-review, no self-merge.
## D. Branch naming
@@ -13,9 +13,14 @@ Rules (llm-project-workflow):
- If the PR is closed but `merged=false`, STOP and run reconciliation. Do not clean up.
Steps:
1. Verify authenticated identity + active profile.
2. Confirm PR #<pr>: author (not you), state open, mergeable, review approved.
3. If any gate fails → STOP and report.
1. Identity Checklist: Before claiming/working on merge, verify and state:
- Required identity/profile for this task: merger (allowed to merge PRs)
- Current authenticated identity (from whoami): <username>
- Target task role: merger identity (must NOT be the PR author)
*If the current identity does not match the required role (or is the PR author), STOP. Relaunch/switch to the correct profile first.*
2. Verify authenticated identity + active profile.
3. Confirm PR #<pr>: author (not you), state open, mergeable, review approved.
4. If any gate fails → STOP and report.
4. Merge with explicit confirmation (e.g. confirmation="MERGE PR <pr>"),
optionally pinning the reviewed head SHA / changed-file set.
5. Confirm remote master now contains the merge commit.
@@ -13,9 +13,14 @@ Rules (llm-project-workflow):
- Do not merge if any check fails.
Steps:
1. Verify your authenticated identity (whoami) and the active profile.
2. Fetch the PR facts: PR author, head SHA, state (must be open), base branch.
3. If authenticated user == PR author → STOP (no self-review).
1. Identity Checklist: Before claiming/working on review, verify and state:
- Required identity/profile for this task: reviewer (allowed to review/approve/request_changes)
- Current authenticated identity (from whoami): <username>
- Target task role: reviewer identity (must NOT be the PR author)
*If the current identity does not match the required role (or is the PR author), STOP. Relaunch/switch to the correct profile first.*
2. Verify your authenticated identity (whoami) and the active profile.
3. Fetch the PR facts: PR author, head SHA, state (must be open), base branch.
4. If authenticated user == PR author → STOP (no self-review).
4. scripts/worktree-review <pr-head-branch> # detached, branches/review-*
cd branches/review-<pr-head-branch-slug>
5. Confirm the worktree is clean. Inspect the FULL diff; confirm scope matches
@@ -13,9 +13,14 @@ Rules (llm-project-workflow):
- Do not self-review or self-merge.
Steps:
1. Verify the orchestration checkout is the right repo and clean.
2. git fetch <remote> --prune; confirm local master == <remote>/master (0 0).
3. Create the issue "<title>" (problem, scope, acceptance) and claim it
1. Identity Checklist: Before claiming work, verify and state:
- Required identity/profile for this task: author (allowed to push branches / create PRs)
- Current authenticated identity (from whoami): <username>
- Target task role: author/work identity
*If the current identity does not match the required role (or lacks push/PR permissions), STOP before claiming the issue. Relaunch/switch to the correct profile first.*
2. Verify the orchestration checkout is the right repo and clean.
3. git fetch <remote> --prune; confirm local master == <remote>/master (0 0).
4. Create the issue "<title>" (problem, scope, acceptance) and claim it
(status:in-progress + a "starting work" comment naming the branch).
4. scripts/worktree-start <type>/issue-<n>-<slug> # type = fix|feat|docs
cd branches/<type>-issue-<n>-<slug>