@openparachute/app 0.2.0-rc.4 → 0.2.0-rc.6

package/.parachute/module.json

@@ -3,6 +3,7 @@
   "manifestName": "parachute-app",
   "displayName": "App",
   "tagline": "Host module for custom Parachute UIs — drop a built bundle in and serve it under one origin.",
+  "kind": "api",
   "port": 1946,
   "paths": ["/app", "/.parachute"],
   "stripPrefix": false,

package/CHANGELOG.md

@@ -9,6 +9,47 @@ side-by-side:
 The admin SPA at `web/admin/` ships inside the host package as
 `dist/admin/`; its version mirrors the host's version.
 
+## [app 0.2.0-rc.6] - 2026-05-22
+
+fix(app): correct `kind` to `"api"` — app is a backend that proxies,
+not a static-served frontend (folds the in-flight rc.6 per
+[app#14](https://github.com/ParachuteComputer/parachute-app/issues/14)).
+
+The initial rc.6 in-flight version carried `"kind": "frontend"` to
+unblock the hub validator (which at rc.13 still required the field).
+That was the wrong value semantically. App is a **backend** that
+serves UI bundles via its own HTTP server — hub's `/app/*` proxy
+forwards to app on `:1946`, then app's HTTP layer serves the admin
+SPA + `notes-ui` + any installed sub-units. Hub does NOT static-serve
+from app's `dist/`; the `"frontend"` framing was inaccurate and
+risked future tooling that branches on `kind === "frontend"` (already
+in `parachute-hub/src/commands/upgrade.ts:376` — which runs
+`bun run build` for kind-frontend modules) treating app as a
+static-bundle module and breaking the runtime HTTP layer.
+
+`"api"` is the accurate value: app's role is the backend-proxy lane,
+same as vault / scribe / runner. With hub#327 landing alongside this
+PR — the validator no longer inspects `kind` at all — future app
+releases can drop the field entirely. For now keeping it explicit
+works under both the old validator (rc.13 strict-require) and the
+new (rc.14+ no-validate); safest immediate fix that doesn't gate on
+hub-rc.14 propagation.
+
+## [app 0.2.0-rc.5] - 2026-05-22
+
+fix(app): self-register uses `manifestName` as services.json row key
+(matches hub install path; closes duplicate-port bug).
+
+Hub installs modules under `manifest.manifestName` (`"parachute-app"`),
+but the boot-time self-registration was writing under the short name
+`"app"`. The two writes left services.json with two rows on the same
+port, which trips hub's duplicate-port detector on re-read
+(`duplicate port 1946 — claimed by both "parachute-app" and "app"`).
+
+The row key is now sourced from `.parachute/module.json#manifestName`,
+so the install path and the runtime path converge to one row. Mirrors
+the fix landed in parachute-runner.
+
 ## [app 0.2.0-rc.1] + [app-client 0.1.0-rc.1] - 2026-05-21
 
 feat(app): Phase 2.0 — extract `@openparachute/app-client` shared

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openparachute/app",
-  "version": "0.2.0-rc.4",
+  "version": "0.2.0-rc.6",
   "description": "Host module for custom Parachute UIs — drop a built bundle in and serve it under one origin.",
   "module": "src/index.ts",
   "type": "module",

package/src/self-register.ts

@@ -31,11 +31,40 @@
  * When per-UI `uis` map lands (design doc section 12), the caller assembles
  * the `uis` field and passes it through via `extraFields`.
  */
+import { readFileSync } from "node:fs";
 import * as path from "node:path";
 
 import pkg from "../package.json" with { type: "json" };
 import { type ServiceEntry, readServiceEntry, upsertService } from "./services-manifest.ts";
 
+/**
+ * The canonical services.json row key for the app module — sourced from
+ * `.parachute/module.json#manifestName`. Hub looks up modules in
+ * services.json by `manifestName` (vault + scribe use this convention), so
+ * self-registering under the short name "app" would create a duplicate row
+ * alongside the hub-installed `parachute-app` row and trip hub's
+ * duplicate-port detector on re-read. See parachute-patterns or the
+ * `manifestName` field on .parachute/module.json files. */
+const ROW_NAME = resolveManifestName();
+
+function resolveManifestName(): string {
+  // Read once at module load — `.parachute/module.json` ships in the
+  // package and doesn't change at runtime.
+  try {
+    const manifestPath = path.resolve(import.meta.dir, "..", ".parachute", "module.json");
+    const raw = JSON.parse(readFileSync(manifestPath, "utf8")) as { manifestName?: unknown };
+    if (typeof raw.manifestName === "string" && raw.manifestName.length > 0) {
+      return raw.manifestName;
+    }
+  } catch {
+    // Fall through to the conservative fallback. The module.json is part
+    // of the published package, so this branch is effectively unreachable
+    // in production — it exists so tests that mount a stub package layout
+    // don't hard-crash on import.
+  }
+  return "parachute-app";
+}
+
 export type SelfRegisterOpts = {
   /**
    * The port app just bound. Used only as the first-run fallback — if
@@ -68,7 +97,7 @@ export type SelfRegisterResult = {
   ok: boolean;
   /** The path we wrote to (or attempted to write to). */
   manifestPath: string;
-  /** True when services.json already had a row for `app` before we wrote. */
+  /** True when services.json already had a row for `parachute-app` before we wrote. */
   hadExistingEntry: boolean;
   /** The port we ended up stamping (existing-entry port or boundPort). */
   portWritten: number;
@@ -92,7 +121,7 @@ export function selfRegister(opts: SelfRegisterOpts): SelfRegisterResult {
 
   let existing: ServiceEntry | undefined;
   try {
-    existing = readServiceEntry("app", manifestPath);
+    existing = readServiceEntry(ROW_NAME, manifestPath);
   } catch (e) {
     const err = e as Error;
     logger.warn(`[app] skipped self-register: ${err.message}`);
@@ -107,7 +136,7 @@ export function selfRegister(opts: SelfRegisterOpts): SelfRegisterResult {
 
   const portToWrite = existing?.port ?? opts.boundPort;
   const entry: ServiceEntry = {
-    name: "app",
+    name: ROW_NAME,
     port: portToWrite,
     paths: ["/app", "/.parachute"],
     health: "/app/healthz",