ROADMAP.md

Purpose

This roadmap answers a different question than it did earlier in the project:

What does Harbor need to do next to move from a strong local-first alpha into a safe, supportable, production launch?

The answer is no longer "build the missing surfaces." Most of the major surfaces now exist:

• Harbor Node and Harbor UI
• Harbor Hub
• public website and docs
• cloud member/account foundations
• internal cloud admin
• premium coordination foundations such as Central Manager and response pipelines

The roadmap now needs to focus on:

1. hardening
2. polish
3. release engineering
4. launch sequencing

Use docs/DELIVERY_PLAN.md for the tactical milestone order and docs/GO_LIVE_PLAN.md for release criteria.

Current product posture

Harbor is currently in a strong pre-production alpha state.

Strongest areas:

• Harbor Node local runtime and SQLite-backed state
• Harbor UI operator workflows
• Harbor Ports, draft lifecycle, approvals, audit, and execution
• Harbor Hub import and catalog flow
• shared contracts and TypeScript SDK
• public website, docs, and cloud admin surfaces
• multi-node foundations, Central Manager, and compact agent-facing APIs

Weakest areas:

• production auth/session posture on the cloud-facing browser surfaces
• deployment hardening, monitoring, and operational runbooks
• full go-live test coverage and CI depth
• polished first-run onboarding, policy visibility, and operator troubleshooting
• public website landing-page and gated-preview behavior
• narrow OAuth completion beyond the first shipped path
• billing/self-serve customer operations

Strategic priority order

1. Production foundations and security hardening
2. Harbor Node and Harbor UI polish for real operators
3. Narrow high-value integration completion
4. Design-partner beta readiness
5. Public v1 go-live
6. Post-launch premium expansion
7. Billing/self-serve and deeper org/team operations

This order matters. Harbor should launch the product it already has before expanding sideways into too many connectors, marketplace mechanics, or enterprise operations.

Phase 1: Production foundations

Goal

Make the current ecosystem safe and supportable enough to run as a real service, not just a strong developer stack.

Scope

• move cloud/admin browser auth toward HttpOnly cookie sessions
• add stronger deployment-layer security defaults and guidance
• expand CI from typecheck/build into meaningful automated test coverage
• align CI toolchain with the pinned local toolchain
• document backup, restore, rollback, and release procedures
• tighten observability and health expectations for Dockerized deployments

Definition of done

• a fresh deployment can be brought up, upgraded, and recovered with written instructions
• critical auth/session flows use production-appropriate patterns
• CI catches more than type regressions and broken builds

Phase 2: Finish the local operator product loop

Goal

Make Harbor Node feel obviously usable to a real operator without requiring repo familiarity.

Scope

• stronger first-run onboarding in Harbor UI
• clearer settings and node-target ergonomics
• clearer Harbor Guard policy and approval visibility
• clearer Harbor Hub import, update, and auth-readiness signals
• better install/troubleshooting help in UI and docs
• better operator visibility into manager flows, async callbacks, and OAuth state

Definition of done

• a new operator can install Harbor, import a Harbor Hub entry, configure auth, test an action, publish safely, and understand the resulting state without reading source code

Phase 3: Finish narrow production integrations

Goal

Turn the first high-value integrations into production-grade examples of the Harbor model.

Scope

• finish Gmail as a polished, auditable, local-first OAuth-backed integration
• add one additional high-value OAuth integration only if it preserves Harbor's trust model
• improve reconnect, token refresh, failure handling, and audit visibility
• make the docs and onboarding around OAuth flows straightforward

Definition of done

• at least one OAuth-backed Harbor Port is production-ready and supportable
• a second integration is only added if it improves product proof, not just connector count

Phase 4: Design-partner beta

Goal

Run Harbor with a small set of real users in an intentionally supported environment.

Scope

• finish design-partner install and support playbooks
• validate Community and premium account/license flows with real operators
• validate multi-node and manager workflows in real usage
• add regression coverage for the most important customer journeys
• tighten admin and support workflows around real member/account issues

Definition of done

• Breakwater can support a small set of real customers without unsafe shortcuts or constant manual debugging

Phase 5: Public v1 go-live

Goal

Launch Harbor publicly with a clear promise and a supportable operational model.

Scope

• website and docs reflect the actual shipped product
• install and upgrade path is stable
• Community path is clearly usable on its own
• premium path is clearly additive
• support/admin workflows are hardened enough for public use
• manual premium operations are acceptable if they are documented and reliable

Definition of done

• Harbor can be presented as a public product without hiding known operational gaps

Phase 6: Post-launch premium expansion

Goal

Deepen Pro and Business without weakening the Community local-first story.

Scope

• better multi-node coordination
• stronger premium notifications and summaries
• better managed-worker and manager workflows
• response pipeline maturity and business automation ergonomics
• better org/team structure where it clearly helps premium operations

Definition of done

• premium meaningfully improves convenience and scale while Harbor Node remains the trust boundary

Phase 7: Billing and deeper cloud operations

Goal

Make Harbor sustainable at larger scale without turning the cloud into the runtime trust boundary.

Scope

• self-serve billing and subscription operations
• cleaner production member lifecycle management
• more durable organization and team operations
• deeper support tooling, retention controls, and commercial reporting

Definition of done

• paying customers can manage their accounts cleanly without Harbor becoming a cloud-hosted credential broker

What is explicitly not next

Do not treat these as the next milestone:

• full Fleet orchestration as the default Harbor mode
• broad connector-count expansion for its own sake
• a generalized remote execution platform
• cloud-hosted connector runtime as the main product
• deep enterprise RBAC before core operator flow is polished
• marketplace economics or publisher payout systems

Recommended app-by-app next steps

apps/harbor-node-api

• tighten onboarding/status metadata
• improve policy visibility and auth-readiness metadata
• finish narrow OAuth maturity and callback diagnostics
• keep execution, manager, and hidden-config boundaries strict

apps/harbor-ui

• finish onboarding, policy visibility, and troubleshooting flows
• tighten manager and execution inspection ergonomics
• keep the local operator experience primary

apps/hub

• continue improving metadata, trust signals, and setup guidance
• improve update/version clarity
• avoid adding any secret-bearing or runtime-execution responsibilities

apps/website

• keep the public story minimal, clear, and aligned with the real product
• shift the public site toward an under-construction landing page plus gated preview
• improve install and product explanation rather than expanding into a SaaS dashboard

apps/docs-site

• make install, upgrade, troubleshooting, and premium explanations extremely clear
• use docs to reduce operator/support confusion, not to add platform complexity

apps/cloud-api

• finish auth/session hardening and release-grade member flows
• keep entitlement validation narrow and stable for Harbor Node consumption

apps/cloud-admin

• keep improving support operations, contact workflows, and account diagnostics
• do not turn it into the customer product surface

Success checkpoint

Harbor is ready for public v1 when all of the following are true:

• the local Harbor product loop is polished and understandable
• cloud/admin/browser auth is hardened appropriately for production use
• CI and automated coverage catch the highest-value regressions
• deployment, backup, restore, and rollback are documented and tested
• website and docs match the real shipped behavior
• at least one OAuth-backed integration is fully supportable
• premium features are clearly additive and supportable, even if some operations are still manual

That is the right bridge from strong alpha to public product.