Strip submit_doc_bug tool and gate (Zerto-specific, not applicable to label MCP)

PLAN.md

@@ -7,8 +7,7 @@ product-specific has been factored out.
 The end product is a streamable-HTTP MCP server with ~15 tools that
 any LLM client (Claude Desktop, Claude Code, Cursor, Copilot) can
 call to answer questions against the docs, surface what changed
-recently, find inconsistencies, and (optionally) submit doc bugs
-back upstream.
+recently, and flag likely inconsistencies.
 
 ---
 
@@ -27,7 +26,7 @@ upstream docs portal
         │           ──► bm25/   (FTS5 lexical index)
         ▼
    MCP server  ──► search_docs / get_page / diff_versions / weekly_digest /
-                   find_doc_inconsistencies / submit_doc_bug / ...
+                   find_doc_inconsistencies / ...
         │
         ▼
    reverse proxy / Cloudflare Tunnel ──► public endpoint
@@ -440,10 +439,10 @@ The "RAG can't tell you what isn't in the docs" gap. Surfaces:
   suspenders for queries where the LLM doesn't think to call it
   proactively.
 
-### Phase 12 — Doc-bug workflow tools  *(1 day, optional)*
+### Phase 12 — Doc-inconsistency tool  *(half a day, optional)*
 
-Two tools that pair up to enable a *"check the docs for
-inconsistencies, draft bugs, confirm, submit"* workflow.
+A *"scan the corpus for likely doc bugs"* tool the model can call
+when an operator asks "is this section reliable?"
 
 - `find_doc_inconsistencies(scope_query, version=None, platform=None,
   max_pages=30, checks=None)`: deterministic, read-only. Two checks:
@@ -454,31 +453,6 @@ inconsistencies, draft bugs, confirm, submit"* workflow.
   diff (`difflib`) against editor-curated cluster peers; the model
   judges which findings are real bugs.
 
-- `submit_doc_bug(page_url, content, email=None, rating=None,
-  like=None)`: POSTs to the docs portal's feedback endpoint.
-  Env-gated by `DOC_BUG_SUBMIT_ENABLED=true` so dev/staging
-  deployments can't accidentally hit the upstream. The tool's
-  docstring is loud about a mandatory operator-confirmation
-  workflow per submission — LLM must draft, show, ask, then
-  submit. Explicit *"do not loop"* instruction. Defensive
-  validation upfront (URL host matches expected portal, content
-  non-empty, etc.) so the LLM gets a clean error instead of a
-  rejected POST.
-
-**You'll need to find the docs portal's feedback endpoint.** Most
-portals route the "Was this helpful?" widget through a backend
-API; sniff the browser network tab on the live site. The payload
-shape varies; common fields: content/body, page url/href, optional
-email, optional rating, optional thumbs. Most accept anonymous
-POSTs with no captcha at the JSON-API layer (even if the widget
-shows a captcha). Validate before you ship — and if the endpoint
-has rate limits or captcha enforcement, the tool returns a clean
-"submission rejected — paste manually at <url>" fallback.
-
-The whole point is the per-bug operator confirmation in the
-LLM-side conversation flow; the tool description enforces it. Do
-not bypass.
-
 ### Phase 13 — Weekly digest tool  *(half a day)*
 
 Goal: a tool that answers *"what changed in the docs in the last N
@@ -524,7 +498,6 @@ shape:
 | `weekly_digest` | What changed in the last N days, with filters |
 | `corpus_status` | Freshness + size of the knowledge base |
 | `find_doc_inconsistencies` | Scoped scan for doc bugs |
-| `submit_doc_bug` | Submit a drafted bug (env-gated, operator-confirmed) |
 | `<product>_api_lessons` | Curated API gotchas, proactively-called |
 | product-specific tools | Interop matrix, lifecycle queries, etc. |
 
@@ -553,11 +526,6 @@ to figure out yourself — everything else is shared infrastructure:
   - One filter per high-cardinality facet
   - Skip filters that have <5 distinct values — they're not worth
     the surface area
-- **Feedback endpoint** (for `submit_doc_bug`, if you want it)
-  - URL of the POST endpoint
-  - Required + optional payload fields
-  - Captcha / rate-limit behavior
-  - Whether anonymous submissions are accepted
 - **Curated knowledge** for the `_api_lessons` tool
   - What does the product's API documentation NOT say that you've
     learned from real integration work?