d68202a88b
Add a specification/v2_auth.md landing page summarizing the four auth specs (EMA / XAA, Hardening, Mid-session, Smoke testing) with a section submenu, mirroring the V2 UX index pattern. Add a V2 Auth link (after V2 UX) and a V2 New Spec Impact link to every spec page's top menu so the top-level nav is uniform, and restructure the four v2_auth_*.md pages onto the shared two-tier menu (top menu + auth submenu). Docs only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S3fTN8H3R8YV4yUGvZjYnX
45 lines
1.6 KiB
Markdown
45 lines
1.6 KiB
Markdown
# Inspector V2 Brief
|
|
|
|
### Brief | [V1 Problems](v1_problems.md) | [V2 Scope](v2_scope.md) | [V2 Tech Stack](v2_web_client.md) | [V2 UX](v2_ux.md) | [V2 Auth](v2_auth.md) | [V2 New Spec Impact](v2_new_spec_impact.md)
|
|
|
|
## Table of Contents
|
|
* [Motivation and Context](#motivation-and-context)
|
|
* [Track Protocol Conformance](#track-protocol-conformance)
|
|
* [Improve Maintainability](#improve-maintainability)
|
|
* [Provide Extensibility](#provide-extensibility)
|
|
* [Proper Documentation](#proper-documentation)
|
|
|
|
## Motivation and Context
|
|
|
|
The existing Inspector is hard to maintain for a number of reasons. We decided to create a more maintainable Inspector
|
|
from the ground up, that retains the deterministic boundary of operation, but exposes a plugin architecture.
|
|
|
|
## Track Protocol Conformance
|
|
* Identify any gaps in V1 inspector
|
|
* Track which features are covered
|
|
* Implement to parity and fill gaps
|
|
* Provide conformance testing in CI
|
|
|
|
## Improve Maintainability
|
|
* Clearer separation of concerns
|
|
* Smaller, reusable components
|
|
|
|
## Provide Extensibility
|
|
* Plugin SDK / API
|
|
* Third parties cand develop/maintain their own plugins for features such as
|
|
* LLM usage
|
|
* Evals
|
|
* Multiple server connections
|
|
* Apps playground
|
|
* Testing of registry configuration
|
|
* Interface with registry
|
|
|
|
## Proper Documentation
|
|
* One big README won't cut it anymore
|
|
* Published documentation in MDX should
|
|
* Render in style of spec
|
|
* Kept up to date
|
|
* Cover all features
|
|
* Discuss troubleshooting strategies
|
|
* Provide detailed contribution guidance that explains architecture and expected idioms
|
|
|