Refresh external-tool-library docs after MCP policy completion #73

New issue

Closed

opened 2026-08-17 07:38:28 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-17 07:38:28 +00:00

(Migrated from github.com)

Problem

After PR #72 / #52 merged to canonical main at 7b527750a64d5cbd9fff79413a399a8c69e90c75, docs/external-tool-libraries.md still says the MCP lifecycle "still tracks first-class external secret/config references and the final host-controlled installer/package-manager allow-list separately in issue #52."

That statement is now stale: #52 is closed and PR #72 implemented those boundaries.

Severity

Low runtime risk; documentation correctness / architecture-boundary risk. The stale sentence can cause future workers or downstream integrators to treat completed security policy as unfinished and design around an obsolete repository state.

Reproduction / architecture failure

Read canonical docs/external-tool-libraries.md on main after 7b527750....
Inspect the MCP category section.
Observe that it describes #52's config-reference and installer allow-list work as still pending.
Compare with closed #52 and docs/mcp-lifecycle.md, which document the completed first-class config references and trusted installer/stdio execution profiles.

Required invariant

Repository architecture documentation must describe the current canonical boundary and must not advertise closed security work as pending.

Acceptance criteria

update the MCP section of docs/external-tool-libraries.md to describe the completed #52 boundary;
preserve the separation between loader availability, capability permission, authority mediation, and hard MCP execution policy;
cross-reference the canonical MCP lifecycle documentation without duplicating its implementation detail unnecessarily;
remove or update obsolete "#52 remains pending" language elsewhere if the same stale claim is found;
deterministic documentation/static/whitespace gates remain green.

Scope exclusions

no MCP lifecycle redesign;
no concrete standard tool-pack implementation;
no authority/capability changes;
no loader ABI changes.

Discovered during the required post-merge audit of PR #72.

## Problem After PR #72 / #52 merged to canonical `main` at `7b527750a64d5cbd9fff79413a399a8c69e90c75`, `docs/external-tool-libraries.md` still says the MCP lifecycle "still tracks first-class external secret/config references and the final host-controlled installer/package-manager allow-list separately in issue #52." That statement is now stale: #52 is closed and PR #72 implemented those boundaries. ## Severity Low runtime risk; documentation correctness / architecture-boundary risk. The stale sentence can cause future workers or downstream integrators to treat completed security policy as unfinished and design around an obsolete repository state. ## Reproduction / architecture failure 1. Read canonical `docs/external-tool-libraries.md` on `main` after `7b527750...`. 2. Inspect the MCP category section. 3. Observe that it describes #52's config-reference and installer allow-list work as still pending. 4. Compare with closed #52 and `docs/mcp-lifecycle.md`, which document the completed first-class config references and trusted installer/stdio execution profiles. ## Required invariant Repository architecture documentation must describe the current canonical boundary and must not advertise closed security work as pending. ## Acceptance criteria - update the MCP section of `docs/external-tool-libraries.md` to describe the completed #52 boundary; - preserve the separation between loader availability, capability permission, authority mediation, and hard MCP execution policy; - cross-reference the canonical MCP lifecycle documentation without duplicating its implementation detail unnecessarily; - remove or update obsolete "#52 remains pending" language elsewhere if the same stale claim is found; - deterministic documentation/static/whitespace gates remain green. ## Scope exclusions - no MCP lifecycle redesign; - no concrete standard tool-pack implementation; - no authority/capability changes; - no loader ABI changes. Discovered during the required post-merge audit of PR #72.