MVP_SCOPE.md

MVP goal

Ship a believable Harbor product that proves the local-first trust model and feels installable.

The MVP is not a full enterprise platform. It is a local-first gateway with:

• a local UI
• a local action API
• a safe import/distribution story
• a small set of real connector patterns
• policy and approval scaffolding
• audit event capture
• optional cloud/member hooks

Current baseline already achieved

The repo has moved beyond the earliest MVP draft.

Implemented baseline now includes:

• Harbor Node local runtime with SQLite state
• Harbor UI for ports, actions, approvals, and audit inspection
• http_api, webhook, and discord_webhook connector patterns
• action drafts with validate, test, publish, and reject lifecycle
• Harbor Pack import/export foundation
• Dock / Hub hosted catalog and manifest delivery
• operator-only Dock import into Harbor Node and Harbor UI
• cloud API placeholders for account, enrollment, and license checks

That means the next MVP work should not restart foundations. It should finish the missing user-facing and premium-ready layers around them.

In scope

Harbor Node and Harbor UI

• local web UI
• local action API
• local database
• local audit log
• Harbor Ports registry model
• action draft lifecycle
• Dock import flow
• Harbor Pack foundation
• approval-required action flow
• overview / health page
• ports page
• port workspace page
• approvals page
• audit page
• local settings and auth maintenance

Harbor Node API

• health endpoint
• port list/detail/update endpoints
• action execution endpoint
• action state management endpoints
• draft validation/test/publish endpoints
• audit query endpoint
• approval creation / resolution endpoints
• Dock import endpoints
• Harbor Pack import/export endpoints

Dock / Hub MVP

• hosted catalog homepage
• hosted integration detail pages
• manifest JSON delivery
• a small starter catalog of real integrations
• import-ready URLs for Harbor Node and Harbor UI

Website and docs MVP

• minimal public website
• docs frontend that publishes /docs
• clear install path for community users
• clear explanation of Dock, Harbor Node, and premium add-ons

Shared packages

• typed contracts
• TypeScript SDK client for scripts and agent use
• common response, manifest, and error shapes

Cloud/member MVP

• account existence and sign-in placeholder -> then real implementation
• enrollment records
• license validation
• premium feature check
• member-facing account area for plan and node visibility

Admin MVP

• internal account lookup
• license state inspection
• enrollment inspection
• premium flag operations

Out of scope for MVP

• full Fleet orchestration
• multi-node sync
• org-grade RBAC
• broad marketplace economics or publisher payouts
• high availability
• full compliance tooling
• large connector coverage
• polished enterprise workflow engine

Narrow OAuth scope for the next milestone

OAuth should not stay fully out of scope forever, but it should be narrow.

Allowed next:

• first-party Harbor OAuth support for one or two high-value ports
• operator-initiated connect flow
• local token custody where feasible
• clear premium/community boundary if applicable

Not next:

• universal OAuth broker for every provider
• generic secret exchange service
• broad cloud-hosted token custody as the default model

Preferred MVP connector examples

Current real examples are already better than this early note.

Near-term focus should be:

1. HTTP API imports through Dock manifests
2. Gmail as a strong local-first OAuth candidate later
3. Google Calendar as another strong OAuth candidate later
4. GitHub as a strong token-based developer-tool reference

MVP success criteria

• Harbor Node runs locally in Docker
• Harbor UI is reachable on the local network
• Harbor Node API exposes safe named actions and drafts
• agent can request a named action
• policy can allow/deny/require approval
• audit records show what happened
• Dock can distribute safe manifests without carrying secrets
• docs are clear enough for users and Codex to keep building
• website and docs explain Community vs premium clearly
• cloud/member layer can represent license and enrollment state without becoming the runtime