Make Gitea MCP role selection operation-scoped instead of LLM-session-scoped #228

New Issue

2026-07-06T00:27:01-05:00

jcwalker3 commented

2026-07-06 00:27:01 -05:00

No description provided.

jcwalker3 commented

2026-07-06 00:27:07 -05:00

Here is the detailed requirement and problem description for this issue:

Problem

Current workflow treats an LLM session as permanently author-bound or reviewer-bound. This is wrong.

An LLM is not inherently an author or reviewer. The LLM should be able to perform whatever role the controller requests, as long as the MCP tool can authenticate the correct profile and enforce exact capabilities for the requested operation.

Repeated failure case:

A session that previously had only gitea-tools attached was author-bound as jcwalker3 / prgs-author. Later, the controller requested reviewer work. Even after gitea-reviewer was configured and verified externally, the live session could not see the new namespace because MCP servers do not hot-attach. The LLM then correctly stopped, but the workflow remained blocked even though valid reviewer credentials existed.

This creates unnecessary role friction and repeated false starts:

The LLM says “wrong role.”
The controller sends a reviewer prompt again.
The session still cannot see reviewer tools.
The LLM stops again.
No useful work happens.

Desired Model

The LLM should be role-neutral.
The MCP layer should decide, per requested operation:

which profile is required
which identity is active
whether exact capability is allowed
whether self-review/self-merge is blocked
whether the target repo/PR/issue is within scope

The tool should not care what role the LLM used earlier in the conversation. Previous author work should not prevent later reviewer work if the reviewer profile is available and the requested operation is authorized.

Required Behavior

Add an operation-scoped role/profile router.
Given a requested task such as:
- implement_issue
- create_pr
- review_pr
- approve_pr
- merge_pr
- request_changes
- comment_issue
- close_issue
The MCP layer should resolve:
- required profile
- required identity
- exact operation capability
- target repository
- target issue/PR
- self-review/self-merge constraints
Stop binding the entire LLM session to one role when multiple valid profiles are configured.
If both author and reviewer profiles exist, the tool should support either:
- dynamic profile activation, or
- a unified router namespace, or
- automatic dispatch to the correct configured profile for that operation.
gitea_activate_profile should either work or be removed/replaced.
Current state is confusing:
- gitea_activate_profile exists.
- Runtime switching reports unsupported.
- Sessions then hard-stop even when the needed profile exists.
Acceptance requires one clear behavior:
- profile activation works and is tested, or
- a better routing tool replaces it, or
- the tool returns a clear machine-readable restart-required result before any workflow prompt begins.
Do not weaken safety.
This change must not allow self-review or unauthorized mutation.
The router must still block:
- approving your own PR
- merging your own PR
- requesting changes on your own PR if policy forbids it
- using author credentials for reviewer actions
- using reviewer credentials for author branch/push actions
- reusing a capability result for a different operation
- cross-repo or cross-remote scope leakage

Add a preflight profile availability check.
Before a workflow begins, the tool should be able to report:

configured profiles
attached/available profiles
whether required profile is usable in this session
whether restart is required
exact reason if unavailable

Example result:

{
  "task_type": "review_pr",
  "required_profile": "prgs-reviewer",
  "available_in_session": false,
  "configured": true,
  "runtime_switching_supported": false,
  "restart_required": true,
  "stop_required": true,
  "reason": "Reviewer profile exists but MCP server was added after session startup and is not attached."
}

Add tests.
Required test cases:
- author task routes to prgs-author
- reviewer task routes to prgs-reviewer
- same LLM session can perform author preflight then reviewer preflight if both profiles are available
- reviewer action blocks when authenticated user is PR author
- reviewer action succeeds when reviewer profile is available and user is not PR author
- author mutation blocks under reviewer profile
- reviewer mutation blocks under author profile
- missing reviewer profile returns clear restart_required or profile_unavailable, not vague wrong-role output
- configured-but-not-attached reviewer profile produces a machine-readable blocker
- no read-only inventory is performed from the wrong profile when policy forbids it
Update controller workflow documentation.
Documentation should say:
- The LLM is role-neutral.
- Profiles/credentials are operation-scoped.
- The tool must select or require the correct profile per operation.
- Previous work by the LLM does not determine future role eligibility.
- Only live identity, live profile, exact capability, and target-specific conflict checks matter.

Acceptance Criteria

A controller can ask the same LLM to do author work and then reviewer work without relying on memory of the previous role.
The MCP tool gives a clear answer about whether the required role/profile is available now.
If the required profile is available, the operation can proceed through the correct profile.
If the required profile is configured but not attached, the tool returns a clear restart-required blocker.
If the required profile is unavailable, the tool stops before inventory or mutation.
Self-review/self-merge remains blocked.
Exact capability enforcement remains fail-closed.
Tests cover both happy paths and blocker paths.

Here is the detailed requirement and problem description for this issue: ## Problem Current workflow treats an LLM session as permanently author-bound or reviewer-bound. This is wrong. An LLM is not inherently an author or reviewer. The LLM should be able to perform whatever role the controller requests, as long as the MCP tool can authenticate the correct profile and enforce exact capabilities for the requested operation. ### Repeated failure case: A session that previously had only `gitea-tools` attached was author-bound as `jcwalker3 / prgs-author`. Later, the controller requested reviewer work. Even after `gitea-reviewer` was configured and verified externally, the live session could not see the new namespace because MCP servers do not hot-attach. The LLM then correctly stopped, but the workflow remained blocked even though valid reviewer credentials existed. This creates unnecessary role friction and repeated false starts: * The LLM says “wrong role.” * The controller sends a reviewer prompt again. * The session still cannot see reviewer tools. * The LLM stops again. * No useful work happens. --- ## Desired Model The LLM should be role-neutral. The MCP layer should decide, per requested operation: * which profile is required * which identity is active * whether exact capability is allowed * whether self-review/self-merge is blocked * whether the target repo/PR/issue is within scope The tool should not care what role the LLM used earlier in the conversation. Previous author work should not prevent later reviewer work if the reviewer profile is available and the requested operation is authorized. --- ## Required Behavior 1. **Add an operation-scoped role/profile router.** Given a requested task such as: * `implement_issue` * `create_pr` * `review_pr` * `approve_pr` * `merge_pr` * `request_changes` * `comment_issue` * `close_issue` The MCP layer should resolve: * required profile * required identity * exact operation capability * target repository * target issue/PR * self-review/self-merge constraints 2. **Stop binding the entire LLM session to one role when multiple valid profiles are configured.** If both author and reviewer profiles exist, the tool should support either: * dynamic profile activation, or * a unified router namespace, or * automatic dispatch to the correct configured profile for that operation. 3. **`gitea_activate_profile` should either work or be removed/replaced.** Current state is confusing: * `gitea_activate_profile` exists. * Runtime switching reports unsupported. * Sessions then hard-stop even when the needed profile exists. Acceptance requires one clear behavior: * profile activation works and is tested, or * a better routing tool replaces it, or * the tool returns a clear machine-readable restart-required result before any workflow prompt begins. 4. **Do not weaken safety.** This change must not allow self-review or unauthorized mutation. The router must still block: * approving your own PR * merging your own PR * requesting changes on your own PR if policy forbids it * using author credentials for reviewer actions * using reviewer credentials for author branch/push actions * reusing a capability result for a different operation * cross-repo or cross-remote scope leakage 5. **Add a preflight profile availability check.** Before a workflow begins, the tool should be able to report: * configured profiles * attached/available profiles * whether required profile is usable in this session * whether restart is required * exact reason if unavailable Example result: ```json { "task_type": "review_pr", "required_profile": "prgs-reviewer", "available_in_session": false, "configured": true, "runtime_switching_supported": false, "restart_required": true, "stop_required": true, "reason": "Reviewer profile exists but MCP server was added after session startup and is not attached." } ``` 6. **Add tests.** Required test cases: * author task routes to `prgs-author` * reviewer task routes to `prgs-reviewer` * same LLM session can perform author preflight then reviewer preflight if both profiles are available * reviewer action blocks when authenticated user is PR author * reviewer action succeeds when reviewer profile is available and user is not PR author * author mutation blocks under reviewer profile * reviewer mutation blocks under author profile * missing reviewer profile returns clear `restart_required` or `profile_unavailable`, not vague wrong-role output * configured-but-not-attached reviewer profile produces a machine-readable blocker * no read-only inventory is performed from the wrong profile when policy forbids it 7. **Update controller workflow documentation.** Documentation should say: * The LLM is role-neutral. * Profiles/credentials are operation-scoped. * The tool must select or require the correct profile per operation. * Previous work by the LLM does not determine future role eligibility. * Only live identity, live profile, exact capability, and target-specific conflict checks matter. --- ## Acceptance Criteria * A controller can ask the same LLM to do author work and then reviewer work without relying on memory of the previous role. * The MCP tool gives a clear answer about whether the required role/profile is available now. * If the required profile is available, the operation can proceed through the correct profile. * If the required profile is configured but not attached, the tool returns a clear restart-required blocker. * If the required profile is unavailable, the tool stops before inventory or mutation. * Self-review/self-merge remains blocked. * Exact capability enforcement remains fail-closed. * Tests cover both happy paths and blocker paths.

jcwalker3 referenced this issue from a commit

2026-07-06 10:28:03 -05:00

feat(mcp): implement operation-scoped role selection and automatic dispatch switching (#228)

jcwalker3 referenced a pull request that will close this issue

2026-07-06 10:28:33 -05:00

feat(mcp): implement operation-scoped role selection and automatic dispatch switching (#228) #239

sysadmin referenced this issue

2026-07-06 11:12:12 -05:00

feat(mcp): implement operation-scoped role selection and automatic dispatch switching (#228) #239

sysadmin referenced this issue

2026-07-06 11:13:36 -05:00

feat(mcp): implement operation-scoped role selection and automatic dispatch switching (#228) #239

jcwalker3 added the status:in-progress label 2026-07-06 11:36:52 -05:00

jcwalker3 commented

2026-07-06 11:36:52 -05:00

Starting work on operation-scoped role selection.

Problem observed: After a reviewer-task denial (wrong_role_stop / capability terminal), author mutations stay blocked even when the operator explicitly resolves an author task via gitea_resolve_task_capability — role state is LLM-session-scoped instead of operation-scoped.

Branch: feat/issue-228-operation-scoped-role-selection

Plan:

Clear stale reviewer-denial / route state when an allowed author capability is explicitly resolved for the target mutation
Keep fail-closed behavior when no explicit author task resolution precedes the mutation
Align role_session_router sticky route with capability_stop_terminal.sync_from_capability_result clearing semantics
Tests for author recovery after reviewer stop via explicit capability resolve

Refs #228

Starting work on operation-scoped role selection. **Problem observed:** After a reviewer-task denial (`wrong_role_stop` / capability terminal), author mutations stay blocked even when the operator explicitly resolves an author task via `gitea_resolve_task_capability` — role state is LLM-session-scoped instead of operation-scoped. **Branch:** `feat/issue-228-operation-scoped-role-selection` **Plan:** - Clear stale reviewer-denial / route state when an allowed author capability is explicitly resolved for the target mutation - Keep fail-closed behavior when no explicit author task resolution precedes the mutation - Align `role_session_router` sticky route with `capability_stop_terminal.sync_from_capability_result` clearing semantics - Tests for author recovery after reviewer stop via explicit capability resolve Refs #228

jcwalker3 referenced this issue from a commit

2026-07-06 11:39:05 -05:00

feat(mcp): implement operation-scoped role selection and automatic dispatch switching (#228)

jcwalker3 referenced this issue from a commit

2026-07-06 11:39:05 -05:00

test: align preflight tests with session-scoped porcelain baselines

jcwalker3 referenced this issue

2026-07-06 11:48:18 -05:00

feat: expose role-aware runtime context capabilities (#139) #257

sysadmin removed the status:in-progress label 2026-07-06 12:28:27 -05:00

sysadmin referenced a pull request that will close this issue

2026-07-06 12:39:00 -05:00