inspector/specification/README.md
olaservo 9d5110f8f4 docs(spec): Restructure UX docs and add visual reference
Break up v2_ux.md (1400+ lines) into smaller, focused documents:
- v2_ux.md - Core UX (overview, server list, modals)
- v2_ux_features.md - Feature screens (Tools, Resources, etc.)
- v2_ux_handlers.md - Client handlers, form generation, errors
- v2_screenshots.md - Visual reference with Shadcn prototype screenshots

Add screenshots from Shadcn prototype to specification/screenshots/.
Update navigation headers across all spec files.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-17 09:06:08 -07:00

46 lines
1.7 KiB
Markdown

# Inspector V2 Brief
### Brief | [V1 Problems](v1_problems.md) | [V2 Scope](v2_scope.md) | [V2 Tech Stack](v2_tech_stack.md)
### UX: [Overview](v2_ux.md) | [Features](v2_ux_features.md) | [Handlers](v2_ux_handlers.md) | [Screenshots](v2_screenshots.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