Understand the current ak:hub launcher limitation

ak:hub is intended to start a local Content Hub and Marketing Dashboard, open the asset gallery, rescan project assets, or stop the related local services. The current Skill body is not aligned with the packaged sibling Skills: it still uses the legacy /write:hub name, references non-canonical sibling paths, and describes dashboard features that the current dashboard authority says are not implemented.

Use this page to understand the intended scope

Intended scope

• Start a local asset gallery and a local dashboard development stack.
• Open the Content Hub near http://localhost:3457/hub and the dashboard near http://localhost:5173 when those services actually bind the default ports.
• Rescan the current project's assets/ tree.
• Stop the local processes associated with the two default ports.

Do not use ak:hub when

• You need a supported, unattended, production, remote, or authenticated dashboard service.
• You need campaign management, a content-generation API, automation recipes, or an active API-key security boundary. The current Marketing Dashboard does not implement those claims.
• You cannot review dependency installation, process creation, browser opening, local file indexing, SQLite writes, or port-based termination first.
• You need cloud storage or publishing. Content Hub's R2 fields are local manifest metadata; they do not enable cloud sync.

Review prerequisites before any manual recovery

The intended local stack requires:

• Marketing Kit installed in a project you control.
• Node.js and npm for the dashboard and Content Hub scripts.
• Available local ports, normally 3457 for the API or hub and 5173 for the dashboard development UI.
• Permission to scan assets/, write local manifest or database state, create PID files, start child processes, and optionally open a browser.
• Review of any dependency installation. The dashboard development starter can run npm install when its node_modules directories are absent.

Runtime invocation status

See Runtime adapters for why Skill discovery does not establish shell, process, browser, or Hook parity.

Understand the intended effects

Do not run these options through ak:hub while the launcher contract remains unresolved.

Separate the two current product surfaces

The related components have different, narrower scopes:

1. Content Hub scans supported files under project assets/, stores gallery metadata in .assets/manifest.json, serves local previews, reads brand context, and exposes local file read and save routes.
2. Marketing Dashboard currently provides Assets, Brand, and Settings views. Its API can scan and update asset metadata, read brand context, and upload validated logos. It stores local state in data/marketing.db when its SQLite driver is available.
3. Settings is not authentication. The UI retains a legacy API-key field, but the current local server does not enforce it as a security boundary.

The two services must not be documented as one authenticated campaign or automation platform.

Keep local process and data approval explicit

• Starting a development stack is a workspace and process mutation. Approve dependency changes, ports, working directory, browser opening, and database creation separately.
• Asset scanning reads filenames, paths, sizes, timestamps, and selected file types from the current project. Confirm the project contains no sensitive material that should not be indexed or served.
• A local HTTP label does not by itself prove access is restricted to the local machine. Inspect the actual bind address and CORS or authentication behavior before using sensitive assets.
• Saving through Content Hub can overwrite a selected asset file. Require an exact path, preview, and backup or version-control boundary.
• Never authorize port-based stop logic until you have identified the owning processes. Do not terminate an unrelated service merely because it uses a default port.
• No launcher action authorizes cloud upload, publication, provider spend, or external sharing.

Expected evidence after a future fix

A supported launcher should report:

• The exact installed sibling Skill directories it resolved.
• Every dependency install it proposes before running it.
• Process IDs, bind addresses, actual ports, health results, and URLs for each started service.
• Local files created or changed, including manifest, database, and PID files.
• Ownership checks before stopping processes.
• Which documented feature surface is active, without legacy campaign, generation, automation, or authentication claims.

Troubleshoot or continue

Continue with the Marketing Kit overview, Kit installation problems, or Projects, artifacts, and checkpoints.

Know the current limits

• The canonical name is clear, but the launcher implementation still depends on legacy names and directory assumptions that do not match current exports.
• Current dashboard authority explicitly excludes campaign management, content generation, automation recipes, and enforced API-key authentication.
• The Content Hub and dashboard have separate storage and route contracts; the combined Skill does not reconcile them into one supported system.