docs: update operator runbooks and roadmap docs for Jenkins/GlitchTip MCP status (#154)

- Updated jenkins-readonly and glitchtip-readonly skills in _PROJECT_SKILLS:
  - Descriptions and notes now use actual server names (jenkins-mcp, glitchtip-mcp)
  - Explain historical -readonly skill names vs registration in mcp-control-plane #55
  - Note gated trigger in jenkins-mcp (see #56), partial filing in glitchtip (see #57)
- Updated docs/safety-model.md: naming note, corrected mutation gating claims for trigger/filing
- Updated docs/architecture/jenkins-readonly-build-status-design.md: naming note, updated Phase 1 to account for gated trigger
- No behavior change to skill status/availability; no secrets exposed
- AC: stale naming explained, actual names documented, Jenkins claims corrected, GlitchTip filing as partial, no over-claiming

Closes #154

docs/architecture/jenkins-readonly-build-status-design.md

@@ -5,20 +5,22 @@
 - **Related:** #77 (repo/branch/PR → job mapping, designed separately)
 - **Date:** 2026-07-02
 
+Note on naming: This design used historical `jenkins-readonly` skill name in Gitea-Tools. Actual package/server is `jenkins-mcp` (see mcp-control-plane registration in #55). The server boundary now contains gated trigger (see #56), but read tools remain as designed.
+
 ## 1. Purpose and scope
 
 Define the minimum **read-only** Jenkins MCP tool set that lets an LLM answer:
 *"Did the latest build for this project/branch succeed or fail?"* — plus enough
 detail (build URL, number, timing, result) to report or investigate.
 
-Phase 1 is **strictly read-only**, per ADR-0001
+Phase 1 is **primarily read-only**, per ADR-0001
 ([`adr-0001-mcp-control-plane-boundaries.md`](adr-0001-mcp-control-plane-boundaries.md)):
 
-- **Excluded: build triggers.**
+- Build triggers are gated behind dedicated profile + exact confirmation (landed in #4, boundary correction in #56).
 - **Excluded: deploy triggers.**
 - **Excluded: parameterized job launches.**
 - Excluded: job creation/deletion/config changes, queue manipulation, node
-  management — any Jenkins mutation whatsoever.
+  management — any Jenkins mutation whatsoever unless explicitly configured.
 
 ## 2. Boundary placement
 

docs/safety-model.md

@@ -17,7 +17,9 @@ To maintain a secure environment, all secrets, tokens, passwords, and sensitive
 ## 4. Read-Only First Policy
 By default, MCP servers (such as `jenkins-mcp` and `ops-mcp`) operate in a **read-only** mode. Mutation capabilities are deny-by-default and fail-closed.
 
+Note on naming: Historical design docs used `jenkins-readonly` / `glitchtip-readonly` skill names. Actual server packages are `jenkins-mcp` / `glitchtip-mcp` (registered via entry points in mcp-control-plane). See Gitea-Tools skills and mcp-control-plane #55 for registration.
+
 ## 5. Mutation Gating
 Any mutating action (e.g., Gitea issue creation from GlitchTip, or Jenkins builds) must be explicitly allowed by the execution profile.
-- **Jenkins build triggers** are explicitly deferred for phase 1.
-- **GlitchTip to Gitea issue filing** is documented as a gated, orchestrated workflow, not a direct unprompted automatic action.
+- **Jenkins build triggers** exist in jenkins-mcp (landed #4) but require dedicated profile/identity and exact confirmation; not on standard reader profiles. See #56 for boundary correction.
+- **GlitchTip to Gitea issue filing** is documented as a gated, orchestrated workflow (not in glitchtip-mcp), currently partial (mocked, dedup not wired, audit missing). See #57.