PROJECT_FEATURE_INVENTORY.md

Purpose

This document inventories what Harbor already has across the monorepo, what is still weak, and what is most worth doing next while staying inside the current mission:

• local-first trust boundary
• action-based access instead of raw secret forwarding
• no raw third-party secrets exposed to agents
• cloud as additive, not the main runtime
• policy, approval, and audit before convenience

It is intentionally not a broad wishlist. It is a scope filter and current-state snapshot.

Mission fit test

Before adding a feature, ask:

1. Does this strengthen Harbor Node as the primary product surface?
2. Does this keep secrets local or minimize cloud custody?
3. Does this expose named actions rather than arbitrary remote transport?
4. Does this improve policy, approval, audit, installability, supportability, or operator clarity?
5. Does this avoid turning Dock, website, or cloud into the runtime trust boundary?

If the answer is mostly no, it is probably out of order.

Current release posture

Harbor is currently best described as:

• strong local-first alpha
• credible design-partner beta candidate
• not yet ready for broad public production launch

Strongest areas now

• Harbor Node local runtime and SQLite-backed state
• Harbor UI local operator workflows after the app refactor
• Harbor Ports, drafts, approvals, audit, and execution model
• Dock / Hub catalog and import flow
• Harbor Pack import/export foundation
• Central Manager and managed-worker foundations
• response compaction and response-pipeline foundations
• shared contracts and TypeScript SDK
• website, docs, and internal cloud admin surfaces

Weakest areas now

• production auth/session posture on cloud-facing browser surfaces
• release engineering, CI depth, and broader automated test coverage
• deployment hardening, monitoring, backup/restore, and rollback discipline
• polished onboarding, policy visibility, and install/troubleshooting UX
• narrow OAuth maturity beyond the first Google/Gmail path
• billing and self-serve commercial lifecycle depth

Main go-live blockers now

• move cloud/admin auth away from JS-readable session tokens
• strengthen CI and ecosystem regression coverage
• finish release/runbook/backup/restore documentation
• tighten the last operator UX gaps in Harbor UI and docs
• finish at least one production-grade OAuth-backed integration

Inventory by project

apps/harbor-node-api

Implemented now

• Fastify local runtime with SQLite-backed Harbor Node state
• local ports model for http_api, webhook, discord_webhook, and built-in system actions
• hidden local config storage with redaction boundaries and encrypted-at-rest foundation
• bounded action execution with classified failure handling
• node-local execution manager, async execution delivery, and execution records
• action drafts with create, validate, test, publish, reject, and publish-request flows
• action enable/disable controls and per-port bulk action state updates
• local approvals and operator decision routes
• local audit log and status surfaces
• Dock manifest import by URL and direct manifest import
• Harbor Pack export and import
• Dock entitlement gating for premium catalog entries
• local settings, notifications, backup export, and runtime settings
• Central Manager routes for config, policy modes, managed-node inventory, bootstrap, callback, and events
• managed-worker bootstrap that switches steady-state automation to dedicated worker-side agent tokens
• response compaction and Business response-pipeline/artifact storage
• cloud-additive hooks for session, enrollment, license, entitlement, and activity sync
• narrow OAuth plumbing for supported ports, including start, status, refresh, disconnect, and callback flows
• recent route hardening around operator auth and remote-access-key boundaries

Useful next features still in scope

• cleaner first-run status payloads for onboarding and troubleshooting
• better policy summary and policy inspection payloads for Harbor UI
• more explicit auth-readiness state for each configured port
• clearer import/update metadata for Dock-synced ports
• stronger OAuth lifecycle and retry diagnostics
• richer callback delivery diagnostics and retention visibility
• small operational/status improvements that help support and installability

Do not start yet

• generic remote execution broker
• universal outbound request proxy with user credentials
• large connector explosion before onboarding and OAuth maturity improve
• turning multi-node coordination into the default Harbor runtime

apps/harbor-ui

Implemented now

• modular React UI backed by the Harbor Node API
• page ownership for home, manager, ports, port detail, executions, fleet, audit, plan, security, and settings
• local health, status, settings, notifications, entitlement, and node-target visibility
• configured port creation/editing for supported port types
• action draft authoring, validation, testing, and publish flows
• live action execution and result inspection
• execution queue, async execution monitoring, and cancellation controls
• approval workflow and audit inspection
• Dock shelves, import flow, and Dock sync status handling
• plan-tier messaging and premium visibility
• OAuth connection status surfaces for ports
• Fleet connect, refresh, disconnect, and managed-target flows
• Central Manager page for provider config, managed-worker inventory, bootstrap handoff, and autonomy policy editing
• response-pipeline authoring and artifact inspection foundations
• backup export trigger and result handling

Useful next features still in scope

• stronger first-run onboarding panel and install troubleshooting guidance
• clearer Harbor Guard policy visibility and approval explanation
• clearer separation between local drafts, published actions, and Dock-synced actions
• better update visibility for imported Dock ports and auto-update state
• stronger settings UX for node target, execution manager, entitlement state, and operator auth
• stronger OAuth operator guidance, reconnect flows, and failure messaging
• better notification organization and surfacing of important state

Do not start yet

• full enterprise workspace shell
• turning the UI into a cloud-first operator console
• deep collaboration workflows before the single-operator flow is fully polished

apps/hub

Implemented now

• hosted Dock catalog service with Fastify and SQLite
• integration home, detail, manifest, and search surfaces
• full-text search for integrations and action templates
• starter catalog of real integrations
• structured service metadata for port entries, setup steps, capabilities, and service links
• import-ready detail URLs and manifest delivery for Harbor Node and Harbor UI
• premium-plan requirement metadata in catalog entries
• connector reference sidecar linkage for Hub/detail pages

Useful next features still in scope

• continue improving integration metadata quality and consistency
• add clearer publisher/trust metadata while remaining secret-free
• improve category shelves, ranking, and install guidance quality
• make Dock entry version/update state more explicit
• improve workflow template discoverability where templates stay action-based and safe

Do not start yet

• secret storage
• customer execution on behalf of Harbor Node
• hidden credential brokerage
• generic hosted connector runtime

apps/cloud-api

Implemented now

• Fastify cloud service with member, license, enrollment, notification, and entitlement state
• sign-up, sign-in, sign-out, session, account self, and profile basics
• plan, license, entitlement, and node-limit modeling for Community, Pro, and Business
• enrollment tracking and activity event ingestion
• contact-submission intake and admin-facing retrieval
• Google OAuth provider metadata surface
• support for license overrides and premium feature shaping used by admin workflows
• recent session hardening, password-change transaction hardening, and duplicate-sign-up conflict handling

Useful next features still in scope

• move browser-facing sessions toward HttpOnly cookie patterns
• keep entitlement validation stable and minimal for Harbor Node consumption
• improve member account, enrolled-node, and profile flows for a public member area
• improve premium coordination metadata for notifications and multi-node visibility
• add production-grade operational safeguards and observability

Do not start yet

• generalized cloud token custody as the default model
• broad cloud-run connector orchestration
• complex billing platform work before production auth/session basics are finished

apps/cloud-admin

Implemented now

• internal admin/support surface for account lookup, license inspection, safe override, enrollment troubleshooting, notifications, and contact submissions
• clear separation from Harbor Node secret-bearing runtime data
• shared site shell and internal support-console structure

Useful next features still in scope

• richer internal support flows around account history, enrollment diagnostics, and override reason capture
• safer support tooling for premium operations and customer issue review
• internal notification and support workflow improvements tied to real member operations
• stronger production auth/session posture

Do not start yet

• turning admin tooling into a customer-facing control plane
• adding direct access to local connector secrets or hidden port config

apps/website

Implemented now

• static-first public site
• home, product, plans, about, contact, and account entry flows
• env-backed shared public links and shared site-map layout
• contact form that writes to cloud storage
• shared Harbor branding through @harbor/ui-theme
• clear public positioning for Community versus premium direction

Useful next features still in scope

• sharpen install path and product explanation further
• make Dock, Harbor Node, Harbor Guard, and Harbor Fleet terminology even more explicit
• improve conversion from public site to docs and install without turning the site into the product
• keep the launch story tightly aligned with real product supportability

Do not start yet

• a heavy SaaS application shell
• trying to replace Harbor UI with a public cloud dashboard

apps/docs-site

Implemented now

• static docs frontend sourced from repo docs
• shared shell direction across public surfaces
• connector reference routing and generated docs navigation
• architecture, security, trust-model, install, roadmap, and release-direction publication
• improved nested-link handling and static HTML 404s

Useful next features still in scope

• improve install, upgrade, backup, restore, and troubleshooting coverage
• add more operator-facing walkthroughs for Harbor Node, Dock import, approvals, manager flows, and OAuth
• keep docs terminology fully consistent with website, Hub, and Harbor UI
• add launch/readiness documentation that reduces support burden

Do not start yet

• heavy docs platform complexity
• documentation that implies Harbor cloud is the main runtime

packages/shared

Implemented now

• shared TypeScript contracts for Harbor Node, Dock, cloud, approvals, audit, OAuth, plans, manager flows, and response pipelines
• shared product vocabulary for Community, Pro, and Business tiers
• manifest, action, and response shapes used across apps

Useful next features still in scope

• continue tightening shared contracts around policy visibility, onboarding state, OAuth lifecycle, and Dock sync metadata
• keep local-only, cloud-additive, and premium-only fields unambiguous
• reduce drift between UI, API, SDK, and docs

Do not start yet

• premature abstraction for speculative enterprise or Fleet surfaces that are not real product yet

packages/sdk-ts

Implemented now

• TypeScript client for health, status, settings, notifications, ports, actions, drafts, approvals, audit, packs, Dock import, OAuth, manager flows, and response artifacts
• compact agent-facing action helpers and caller metadata support
• targeted tests around short execute routes and response-pipeline request shapes

Useful next features still in scope

• keep SDK coverage aligned with all safe Harbor Node APIs
• improve helper ergonomics for common operator and agent workflows
• add better examples for local agent usage, especially around approvals, artifacts, manager flows, and Dock imports

Do not start yet

• SDK methods that encourage raw secret access or generic arbitrary transport behavior

packages/ui-theme

Implemented now

• shared Harbor theme tokens, typography, theme preference storage, and document theme helpers
• shared styling foundation used by website, docs, Hub, and Harbor UI
• cloud-fetchable theme support hook points

Useful next features still in scope

• continue unifying cross-surface visual language
• polish accessibility, readability, and product-specific UI primitives
• keep theming lightweight and reusable across all current apps

Do not start yet

• a large design-system program disconnected from the current product loop

Best next work by priority

Priority 1: Production foundations

• cloud/admin/browser auth hardening
• CI and automated test coverage expansion
• deployment, backup, restore, rollback, and monitoring guidance
• production security header and runtime guidance

Priority 2: Finish the local operator product loop

• Harbor UI onboarding and install guidance
• Harbor UI policy visibility
• Harbor UI Dock import/update clarity
• Harbor Node status/settings improvements that support those UX flows

Priority 3: Finish narrow integration maturity

• production-grade Gmail path
• one additional high-value OAuth-backed integration only if justified
• reconnect/refresh/failure/audit clarity

Priority 4: Design-partner beta readiness

• support/admin playbooks
• journey-level regression coverage
• better real-customer troubleshooting guidance

Priority 5: Public launch readiness

• website/docs alignment with shipped behavior
• clear Community and premium story
• stable install/upgrade/support path

Features that are attractive but should wait

• full Harbor Fleet orchestration
• org-wide RBAC
• large connector catalog expansion
• generalized cloud-hosted OAuth/token brokerage
• marketplace economics and publisher payout systems
• centralized remote execution as the main Harbor model
• deep self-serve billing before the current product is production-ready

Recommended build order from this inventory

1. Finish production hardening and release foundations.
2. Polish Harbor UI onboarding, settings, policy visibility, and Dock clarity.
3. Finish narrow OAuth only for selected high-value integrations.
4. Run a real design-partner beta with supportable operations.
5. Prepare and execute a public v1 launch.
6. Expand premium depth after the launch is stable.

Bottom line

Harbor already has a credible local-first product core and a credible ecosystem around it. The repo does not most need more surfaces or more connector count. It most needs production hardening, operator polish, launch discipline, and one or two fully supportable flagship integrations.

That stays aligned with the mission: safe local execution, hidden credentials, governed actions, optional cloud, and a product center that remains Harbor Node.