Backlog Dashboard
Prioritized backlog with ICE scoring. Items are ordered by their combined Impact, Confidence, and Ease scores.
External AuthZ REST API (POST /v1/authz/check)
Enable teams to check subscription-based authorization at runtime without replacing auth
K8s discovery bulk import UI
Create APIs from orphaned runtime records in one action when system is empty
Manual mapping dialog (link orphaned record to API)
Link discovered runtime record to existing API in the catalog
Soft delete / danger zone for APIs
Soft delete APIs with deleted_at; filter from all endpoints; danger zone UI
GitHub spec sync integration
Sync API specs from GitHub repos (design-time discovery)
OPA policy bundles (Phase D authz)
Edge-deployable policy bundles for offline-capable authorization
Usage analytics per subscription
Track usage per subscription for rate limiting and billing
UI completeness audit and polish
Audit all UI screens for unfinished elements — loading states, empty states, error handling, form validation, disabled/broken buttons. Fix before launch.
Settings and configuration end-to-end testing
Verify all settings flows work from the UI — API keys, org settings, team management, user invites, subscription approval. No silent failures.
Reserve production domain and configure DNS/TLS
Reserve production domain (e.g. app.winspect.io), configure DNS, provision TLS certificate, update CORS and OAuth callback URLs, test end-to-end.
Multi-org data isolation testing
Test with multiple independent organizations and users. Verify ABAC org isolation — users cannot see or act on resources from other orgs. Include cross-org API access, subscription requests, and team membership attempts.
Authorization enforcement end-to-end testing
Test the full authorization flow — subscription request, approval, permission assignment, ABAC policy evaluation. Verify VIEW/MANAGE/ADMIN levels enforced correctly. Test denied cases.
Production environment setup (Railway / infra)
Provision production Railway services, set all required env vars (Clerk prod keys, DB, CORS, domain), verify health endpoints, set up error monitoring.
Seed production with test org data and smoke test
Create at least two test organizations with real data, run through core flows (register API, invite user, subscribe, approve, check permissions) against the production domain before opening to users.
Auto-trigger notifications on API spec change
When an API spec is updated and the spec content has changed, automatically dispatch notifications to all active subscribers. Wire into ApiRegistryServiceImpl.updateApi() — compare spec hash, call NotificationService.notifySubscribers() with changelog message if provided.
Email delivery for notifications (SMTP)
Implement EmailNotificationService using spring-boot-starter-mail. Send HTML emails to user.contactInfo.emailAddress when notification preferences include EMAIL. Required env vars — SMTP_HOST, SMTP_PORT, SMTP_USERNAME, SMTP_PASSWORD, SMTP_FROM.
Slack delivery via Incoming Webhook
Implement SlackNotificationService using Slack Incoming Webhooks (no SDK needed). Requires extending ContactInfo schema to add slackWebhookUrl field (new DB migration). Send formatted markdown message with API name, version, changelog summary, and link.
Notification preferences settings UI
Add a Notifications section to Settings. Users select channels (UI, Email, Slack checkboxes), enter Slack Webhook URL if Slack selected. Calls updateNotificationPreferences() and saves slackWebhookUrl to ContactInfo. Requires adding updateNotificationPreferences to notificationsApiClient.ts.
Changelog form on API spec update
Add a collapsible Changelog section to the API edit dialog — breaking change checkbox, severity selector (MAJOR/MINOR/PATCH), title, description, optional migration guide. Fields sent as changelogTitle, changelogMessage, isBreakingChange, severity in the multipart update request.
Extend ChangelogEntry schema (breaking change, severity, migration guide)
Add isBreakingChange (boolean), severity (MAJOR/MINOR/PATCH enum), migrationGuide (text) to ChangelogEntry entity and OpenAPI spec. Requires Flyway migration and frontend type regeneration.
Extend ContactInfo schema for Slack webhook URL
Add slackWebhookUrl field to ContactInfo entity and OpenAPI spec. The existing slackChannel field stores a display name only; delivery requires a webhook URL. Requires Flyway migration and frontend type regeneration.
Bootstrap winspect-mcp-server repo (TypeScript, MCP SDK, Streamable HTTP)
Create winspect-mcp-server TypeScript repo using the official @modelcontextprotocol/sdk. Set up Streamable HTTP transport (Express or Fastify), environment config (ORG_ID, API_KEY / PERSONAL_ACCESS_TOKEN, PLATFORM_BASE_URL), and Docker packaging. Wire basic health check. This is the foundation all MCP tools are built on.
MCP tools — API catalog (list_apis, get_api, search_apis, get_api_operations)
Implement MCP tools that proxy to platform-backend-service: list_apis (GET /api-management/apis, filterable by name/tag/status), get_api (GET /api-management/apis/{apiId}, returns metadata + spec), get_api_operations (GET /api-management/apis/{apiId}/operations), search_apis (POST /platform-ai/search, wraps RAG semantic search). All tools accept org_id + api_key in server config; no per-call auth needed.
MCP tools — subscriptions and authorization (list_subscriptions, get_subscription, check_authz, list_subscribers)
Implement MCP tools: list_subscriptions (list subscriptions for caller's org/team), get_subscription (get subscription detail + status), list_subscribers (get all subscriber teams for a given API), check_authz (POST /v1/authz/check — check if a team has permission to an API). Enables AI agents to reason about who can access what.
MCP tools — org and team info (get_org, list_teams, get_team, list_team_members)
Implement MCP tools: get_org (get org name, settings, API key status), list_teams (list all teams in the org with member counts), get_team (get team details including member list), list_team_members (get members of a specific team with roles). Enables AI agents to understand org structure when answering governance questions.
MCP tool — publish_api (create or update API from spec)
Implement destructive MCP tool publish_api: accepts api_name, version, description, spec (OpenAPI YAML/JSON string), team_id. Proxies to POST /api-management/apis. Tool annotation: destructiveHint=true. Requires caller confirmation prompt. Enables AI agents and CI pipelines to register APIs programmatically via MCP.
MCP server — OAuth 2.0 auth for Claude Connector Directory submission
Implement OAuth 2.0 authorization code flow on the MCP server so it can be submitted to Anthropic's Claude Connectors Directory. Requires: /oauth/authorize, /oauth/token, /oauth/callback endpoints; PKCE support; scoped permissions (read:apis, write:apis, read:subscriptions, read:org). Store token-to-org mapping in the MCP server's own lightweight persistence layer. See Anthropic submission docs for exact requirements.
Submit Winspect connector to Anthropic Claude Connectors Directory
After OAuth flow is implemented (bl-027), prepare and submit Winspect MCP server to Anthropic's Claude Connectors Directory. Requires: privacy policy URL, tool annotations (readOnlyHint / destructiveHint), connector icon, description, and Anthropic review. This is the primary distribution channel for non-technical Claude.ai users.
Bootstrap winspect-cli repo (TypeScript, oclif, npm distribution)
Create winspect-cli using oclif (battle-tested Node.js CLI framework used by Heroku/Salesforce). Set up monorepo structure, TypeScript config, npm publish pipeline. Implement `winspect auth login` (prompts org ID + API key, saves to ~/.winspect/config.json) and `winspect auth whoami`. All subsequent commands read from config or WINSPECT_ORG_ID / WINSPECT_API_KEY env vars for CI use.
CLI commands — API management (apis:list, apis:get, apis:publish, apis:search)
Implement core API commands: winspect apis:list [--status <s>] [--team <id>] [--output json|table], winspect apis:get <apiId> [--spec] (--spec flag dumps raw OpenAPI spec), winspect apis:publish --name <n> --version <v> --spec-file <path> [--team <id>] (multipart POST to /api-management/apis; prints created API ID), winspect apis:search <query> (semantic search via RAG endpoint). Target: developers can script API publishing in CI pipelines.
CLI commands — subscriptions and subscribers (subscriptions:list, apis:subscribers)
Implement subscription commands: winspect subscriptions:list [--status pending|approved|rejected] [--output json|table], winspect apis:subscribers <apiId> [--output json|table] (lists all subscriber teams with permission levels and subscription status). Enables API owners to audit who has access to their APIs from the terminal.
CLI commands — org and team management (orgs:info, teams:list, teams:members)
Implement org/team commands: winspect orgs:info (show org name, ID, API key status), winspect teams:list [--output json|table], winspect teams:members <teamId> [--output json|table]. Useful for scripted org auditing and onboarding automation.
[Deferred] Extend subscription entity to support MCP server subscriptions
Extend the Subscription entity and data model so that the subscriber_type field accepts both TEAM (existing, for human teams subscribing to APIs) and AGENT (new, for agent identities subscribing to MCP servers). Add resource_type field to distinguish API subscriptions from MCP_SERVER subscriptions. Add AgentIdentity entity (client_id, hashed_secret, name, description, owning_team_id). Requires Flyway migration, updated OpenAPI spec, and frontend type regeneration. This is the schema foundation all other MCP governance features depend on. **Deferred** until after production launch — product focus is REST/OpenAPI APIs first; MCP governance model TBD.
[Deferred] MCP server registration UI (catalog list, register, detail view)
Add MCP Servers section to the catalog UI alongside APIs. Screens: MCP server list (name, team owner, tool count, quality score, status), register MCP server dialog (name, description, transport URL, tool manifest JSON upload or URL fetch), MCP server detail page (tools list, subscribers, quality report, owner team). Backend endpoints: GET /mcp-management/servers, POST /mcp-management/servers, GET /mcp-management/servers/{id}. Mirrors the API catalog UI patterns. **Deferred** — MCP catalog not in scope until post milestone.
[Deferred] MCP server team ownership model (assign owner team, ABAC roles)
Each MCP server must have an owning team (similar to API → team ownership). Owner team gets MANAGE-level ABAC permission; other teams can subscribe for CALL permission. Extend ABAC policy evaluation to cover mcp_server resources. Org admin can reassign ownership. Orphaned MCP servers (no owner team) are flagged with a warning in the catalog.
[Deferred] MCP server linting engine (tool description quality, schema validation, naming)
Build a static linting engine that runs on MCP server tool manifests at registration time and on-demand. Rules: tool name must be snake_case and verb-prefixed (e.g. get_order, list_users); tool description must be ≥20 characters and not start with "A tool that..."; all inputSchema properties must have a description; no required fields without type annotation; tool description must not contain tokens that look like secrets (regex for hex-40, base64-40+). Produces a structured lint report (rule_id, severity: error/warning/info, message, tool_name). Critical errors block registration. Warnings surface in UI.
[Deferred] MCP server quality score and dashboard
Compute a composite quality score (0–100) for each registered MCP server based on lint rule pass rates, tool description length/clarity, inputSchema completeness, number of warnings vs errors. Display score badge on catalog list and detail page. Org-level dashboard shows quality distribution across all MCP servers — which servers are below threshold, which teams own them, trend over time as servers are updated.
[Deferred] Agent identity registration and MCP server subscription workflow
UI and API for: (1) registering an agent identity (name, description, owning team, client_id generated, secret displayed once); (2) subscribing an agent identity to an MCP server (selects server, requests scope: read_tools or call_tools); (3) approval workflow — MCP server owner team approves/rejects with optional scope restriction; (4) approved agent receives a scoped token valid for calling that MCP server's tools. Mirrors the API subscription approval workflow. Backend: POST /mcp-management/agent-identities, POST /mcp-management/servers/{id}/subscriptions.
[Deferred] External AuthZ API for MCP tool access (POST /v1/mcp-authz/check)
REST endpoint for MCP servers to enforce authorization at tool invocation time. Request: { agent_client_id, mcp_server_id, tool_name, required_scope }. Response: { allowed: boolean, reason: string, subscription_id }. The MCP server calls this before executing any tool. Enables fine-grained tool-level access control beyond server-level subscription. Mirrors POST /v1/authz/check for APIs. Stateless and low-latency (<10ms p99 on warm cache). OPA-backed policy evaluation.
[Deferred] Per-agent rate limiting for MCP tool invocations
Configurable rate limits per MCP server subscription. Platform team sets limits at the MCP server level (e.g. 1000 tool calls/hour globally) and per-subscription (e.g. 100/hour per agent). Rate limit enforcement runs at the MCP authz check layer — if limit exceeded, /v1/mcp-authz/check returns allowed: false with reason RATE_LIMIT_EXCEEDED. Quota windows: per-minute, per-hour, per-day. Integrates with usage analytics. Critical for preventing runaway agent loops from overloading downstream services.
[Deferred] K8s MCP server auto-discovery (extend discovery agent)
Extend the winspect-api-discovery-agent to detect MCP servers deployed in customer K8s clusters. Detection heuristics: (1) pod/service label app.winspect.io/type=mcp-server; (2) service annotation winspect.io/mcp-transport-url pointing to Streamable HTTP endpoint; (3) ConfigMap with key winspect-mcp-manifest containing tool manifest JSON. Discovered MCP servers appear as orphaned runtime records in the MCP catalog, following the same bulk-import and manual-mapping workflow used for REST API discovery.
winspect CLI core (auth, config, publish, mock, lint)
TypeScript CLI with Commander; browser login exchanging to named org API key; ~/.winspect/config.json; publish via discovery sync; mock create/list/url; Spectral lint; CI env auto-detection and .winspect.yaml.
winspect init onboarding (spec detect, CODEOWNERS, first publish)
Scan for openapi.yaml; optional CODEOWNERS team default; write .winspect.yaml; run first publish; print mock URL — target under 30s to value.
winspect pull, search, diff, log, status commands
pull from registry endpoints; search via RAG; diff versions; version history log; org status overview — depends on registry read API and versioning.
winspect team commands (list, create, invite, members)
CLI surface for team management aligned with org plan limits (free tier max teams).
winspect mcp url and mcp test commands
Print hosted MCP URL and sample Cursor/Claude config; verify MCP health — thin client until hosted MCP server ships.
CLI distribution (npm, Homebrew tap, single binary, curl installer)
Publish @winspect/cli to npm; Homebrew formula; pkg/esbuild binaries on GitHub Releases; install.winspect.io script for CI.
publish-api-spec-action GitHub Action (PR comment outputs)
Marketplace action installing CLI; inputs spec path, check-breaking, strict; outputs mock-url, spec-url, api-id for workflow composition and PR comments.
CLI opt-in telemetry (commands, exit codes, CI detection)
Anonymous telemetry with opt-out via config or WINSPECT_TELEMETRY=false; no spec content.
Backend CLI source type and POST /cli/auth/complete (org API key for CLI login)
SpecRecord SourceType CLI; endpoint to complete browser login and create named org API key returned to CLI; extend discovery sync for CLI publish metadata.
Spec version history (spec_record_versions, tags, latest pointer)
Immutable rows per publish; semver or git-sha tags; migration from single-row spec records; enables pull @version and changelog correlation.
Registry read endpoints GET /registry/{org}/{name}[/{version}]
Authenticated and optional public read for opt-in APIs; list versions endpoint; powers winspect pull.
Breaking change diff on publish (openapi-diff / oasdiff, stored summary)
Server-side diff vs latest; store JSON summary on version row; CLI --check-breaking gates CI.
Mock server auto-regenerate variants after spec publish
Hook ApiSpecSyncService / registry update path to call mock generation when API has mock server — stable mock UUID, updated responses.
Public API registry index (opt-in, SEO, winspect search --public)
UI at app.winspect.io/registry; public read API for opted-in APIs; drives discovery and growth.
Organisation plan model and PlanEnforcementService (FREE/PRO/ENTERPRISE)
organisation_plans table; limits teams, mock count, mock calls/day; 402 with upgrade URL; UI surfacing plan.
Mock server call rate limiting (free tier daily quota)
Per-mock-server daily counter (DB or Redis); 429 + upgrade messaging; aligns with free tier mock_calls_per_day.
Spectral ruleset DB persistence (replace Next.js in-memory stub)
Persist custom rulesets in Java backend; Pro tier feature; CLI winspect lint --org-ruleset fetches from API.
Hosted MCP server at mcp.winspect.io/org/{orgId}/mcp
JSON-RPC MCP exposing list_apis, search_apis, get_api_spec, get_mock_url; Bearer org key; backed by RAG and catalog services.
MCP tool implementations (list_apis, search_apis, get_spec, get_mock_url)
Concrete tool handlers and schemas for Cursor/Claude Desktop integration; integration tests.
Free tier mock TTL policy (deactivate after prolonged inactivity)
Optional job to soft-disable mocks unused 90+ days with email warnings; re-enable via CLI or UI — protects shared infra cost.
winspect diff command (local vs published, semver pair)
Client-side oasdiff for winspect diff openapi.yaml and winspect diff name@v1 v2; complements server-side breaking detection on publish.
winspect log command (version history table)
Pretty-print version history from spec_record_versions — timestamps, git SHAs, breaking flags; depends on spec versioning (bl-051).
Prioritization Framework
We use ICE scoring (1–10 scale per dimension):
| Dimension | Question |
|---|---|
| Impact | How much will this move the needle? |
| Confidence | How sure are we about that impact? |
| Ease | How easy is it to ship? |
Score = (Impact + Confidence + Ease) ÷ 3. Higher = higher priority. The bar next to each item shows I (cyan), C (violet), and E (amber) visually.