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

docs: fix trailing whitespace and add approved naming for #52

Browse Source 
Address reviewer blockers on PR #8:
- Remove trailing whitespace in credential-isolation.md and release-workflows.md
- Add approved naming coverage (MCP Control Plane / mcp-control-plane project
  and repo names; common, gitea-mcp, jenkins-mcp, ops-mcp, release-mcp packages)
  to tool-boundaries.md

Documentation-only. No code, scaffolding, or config changes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jason Walker
2026-07-01 04:17:30 -04:00
parent 509ff7574a
commit b402de83fe
3 changed files with 4 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/credential-isolation.md
+1 -1
View File
@@ -3,7 +3,7 @@
This document describes how credentials and sensitive environment variables are handled within the MCP tools monorepo. This document describes how credentials and sensitive environment variables are handled within the MCP tools monorepo.
## Separate Credentials ## Separate Credentials
Even though multiple MCP servers share the same monorepo, they **must** have separate credentials and runtimes. Even though multiple MCP servers share the same monorepo, they **must** have separate credentials and runtimes.
- **No Shared Environments**: Each MCP server (`gitea-mcp`, `jenkins-mcp`, `ops-mcp`, etc.) must be instantiated as an independent service with its own dedicated `.env` configuration file. - **No Shared Environments**: Each MCP server (`gitea-mcp`, `jenkins-mcp`, `ops-mcp`, etc.) must be instantiated as an independent service with its own dedicated `.env` configuration file.
- **Strict Isolation**: A server will only have access to the credentials required for its specific trust boundary. For instance, `gitea-mcp` has no access to Jenkins or Ops authentication tokens. - **Strict Isolation**: A server will only have access to the credentials required for its specific trust boundary. For instance, `gitea-mcp` has no access to Jenkins or Ops authentication tokens.
docs/release-workflows.md
+1 -1
View File
@@ -5,5 +5,5 @@ This document outlines the scope and boundaries of the optional future `release-
## Orchestrator Role ## Orchestrator Role
The `release-mcp` package may be introduced later to coordinate workflows across the different MCP packages. The `release-mcp` package may be introduced later to coordinate workflows across the different MCP packages.
- **Coordination, not Consolidation**: It can call or compose other tools, but it **must not** become an all-powerful server holding credentials for all other components. - **Coordination, not Consolidation**: It can call or compose other tools, but it **must not** become an all-powerful server holding credentials for all other components.
- **Example Workflows**: Tasks such as collecting release evidence, verifying TEST deploy checklists, summarizing state (issue/PR/build/deploy), and posting evidence back to Gitea. - **Example Workflows**: Tasks such as collecting release evidence, verifying TEST deploy checklists, summarizing state (issue/PR/build/deploy), and posting evidence back to Gitea.
docs/tool-boundaries.md
+2
View File
@@ -2,6 +2,8 @@
This document defines the strict boundaries between the different MCP server packages within the monorepo. This document defines the strict boundaries between the different MCP server packages within the monorepo.
The project is named **MCP Control Plane** and lives in the `mcp-control-plane` repository. It groups the following packages: `common`, `gitea-mcp`, `jenkins-mcp`, `ops-mcp`, and `release-mcp`.
## 1. Architectural Philosophy ## 1. Architectural Philosophy
- **One MCP Server per Trust Boundary**: While the packages share a monorepo, their runtime services must remain entirely separate. There is no single "everything" server. - **One MCP Server per Trust Boundary**: While the packages share a monorepo, their runtime services must remain entirely separate. There is no single "everything" server.