renaming app to workflow-cli, releasing goes to public npm, cli SPA as package

Author: Daniel

.claude/commands/sync-translations.md

@@ -11,7 +11,7 @@ the `locales/` dirs (today: `en`, `de`).
 
 - **`ts/workflow-builder/src/i18n/locales/*.json`** — the builder's private instance:
   canvas/panel/dialog UI **plus** the optional description overrides (below).
-- **`ts/app/src/i18n/locales/*.json`** — the host app's UI (toolbar, status, dialogs).
+- **`ts/workflow-cli/src/i18n/locales/*.json`** — the CLI host SPA's UI (toolbar, status, dialogs).
 
 ## What makes this repo different: descriptions live in code
 
@@ -57,11 +57,11 @@ parity/description checks — don't re-derive it by hand.
 
 ## 2. Validate t() key usage (agent check)
 
-The script can't see runtime usage. Search `ts/workflow-builder/src` and `ts/app/src`
+The script can't see runtime usage. Search `ts/workflow-builder/src` and `ts/workflow-cli/src`
 (`.ts`/`.tsx`) for translation keys and confirm each resolves:
 
 - Direct: `` t("…") ``, `t('…')`, `` t(`…`) `` — for builder keys check
-  `workflow-builder/.../en.json`; for app keys check `app/.../en.json`.
+  `workflow-builder/.../en.json`; for CLI keys check `workflow-cli/.../en.json`.
 - Indirect: string literals later passed to `t()` (`labelKey: "…"`, `key: "…"`, arrays
   of keys). Look for `namespace.keyName`-shaped literals.
 - Template literals: extract the static prefix; a dynamic tail
@@ -73,7 +73,7 @@ resolve via `defaultValue` by design (see above).
 
 ## 3. Hardcoded user-visible strings (agent check)
 
-Scan builder panels/dialogs/toolbars (and app UI) for user-visible strings that bypass
+Scan builder panels/dialogs/toolbars (and CLI SPA UI) for user-visible strings that bypass
 `t()`: JSX text, `placeholder`/`title`/`aria-label`/`alt`, toast/dialog titles and
 descriptions, error messages shown to users.
 

.claude/scripts/sync-translations.ts

@@ -30,7 +30,7 @@ import { ModelRegistry } from "../../ts/workflow-core/src/model/index.ts";
 const here = dirname(fileURLToPath(import.meta.url));
 const tsRoot = join(here, "..", "..", "ts");
 const builderLocales = join(tsRoot, "workflow-builder", "src", "i18n", "locales");
-const appLocales = join(tsRoot, "app", "src", "i18n", "locales");
+const cliLocales = join(tsRoot, "workflow-cli", "src", "i18n", "locales");
 
 // A locale key counts as a code-defined description override if it sits in one of
 // these namespaces and ends in `.description`. Everything else is "general UI".
@@ -147,7 +147,7 @@ function parity(label: string, dir: string) {
   }
 }
 parity("workflow-builder", builderLocales);
-parity("app", appLocales);
+parity("workflow-cli", cliLocales);
 
 h("summary");
 log(issues === 0 ? "✓ no issues" : `⚠ ${issues} issue(s) — see above`);

.github/CONTRIBUTING.md

@@ -19,7 +19,7 @@ Thanks for your interest in edge-agents! Please read our
 | ----------- | ------------------------------------------------------------------------------------------------- |
 | `contract/` | Language-neutral OpenAPI schemas — the **source of truth** for both Go and TS.                    |
 | `go/`       | Go module: the engine runtime + LLM proxy. See [`go/CLAUDE.md`](../go/CLAUDE.md).                 |
-| `ts/`       | npm workspace: `workflow-core`, `workflow-builder`, `app`. See [`ts/CLAUDE.md`](../ts/CLAUDE.md). |
+| `ts/`       | npm workspace: `workflow-core`, `workflow-builder`, `workflow-cli`. See [`ts/CLAUDE.md`](../ts/CLAUDE.md). |
 | `skills/`   | Claude Code skill wrapping the workflow CLI.                                                      |
 
 `go/` and `ts/` are independent — you only need the toolchain for the side you touch.
@@ -40,7 +40,7 @@ go test ./...
 
 Format edited files with `goimports -w <file>`.
 
-### TypeScript (workflow model, builder, app)
+### TypeScript (workflow model, builder, cli)
 
 Requires Node 20+.
 
@@ -52,7 +52,7 @@ npm run typecheck
 npm run lint
 npm run build
 npm test
-cd app && npm run dev    # run the reference SPA (embeds the visual builder)
+cd workflow-cli && npm run dev    # run the reference SPA (embeds the visual builder)
 ```
 
 ## The contract is the source of truth (read this first)
@@ -102,7 +102,7 @@ Use clear, prefixed messages: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`.
 
 edge-agents uses a **two-tier license model**: the `contract/` and
 `ts/workflow-core/` subdirectories are released under [Apache-2.0](../contract/LICENSE),
-and all other components (engine, LLM proxy, workflow-builder, app) are released
+and all other components (engine, LLM proxy, workflow-builder, workflow-cli) are released
 under [AGPL-3.0](../LICENSE) with the option for ForestHub to also offer them under a
 separate commercial license for use cases that are incompatible with the AGPL
 (commercial licensing: root@foresthub.ai). To keep this model viable, every
@@ -163,7 +163,7 @@ The repository uses a two-tier license model:
 
 - Contributions to `contract/` and `ts/workflow-core/` are released under
   **Apache-2.0**.
-- Contributions to all other paths (engine, LLM proxy, workflow-builder, app) are
+- Contributions to all other paths (engine, LLM proxy, workflow-builder, workflow-cli) are
   released under **AGPL-3.0-only** with the option for ForestHub to also offer them
   under a commercial license (per the CLA above).
 

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -27,7 +27,7 @@ body:
         - Contract (OpenAPI schemas)
         - workflow-core (TS)
         - workflow-builder (TS, visual canvas)
-        - app / fh-builder CLI (TS)
+        - workflow-cli / fh-workflow CLI (TS)
         - skills
         - Other / not sure
     validations:

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -53,7 +53,7 @@ body:
         - Contract (OpenAPI schemas)
         - workflow-core (TS)
         - workflow-builder (TS, visual canvas)
-        - app / fh-builder CLI (TS)
+        - workflow-cli / fh-workflow CLI (TS)
         - skills
         - Other / not sure
     validations:

.gitignore

@@ -3,7 +3,9 @@
 # Node
 node_modules/
 ts/**/dist/
+ts/**/dist-cli/
 *.tsbuildinfo
+*.tgz
 
 # Go
 *.test

CLAUDE.md

@@ -20,7 +20,8 @@ go/              Go module — go.mod lives HERE, not at repo root, so `go get`
                  Module: github.com/ForestHubAI/edge-agents/go. See go/CLAUDE.md.
 
 ts/              npm workspace: workflow-core (headless model), workflow-builder
-                 (React canvas), app (reference SPA + CLI). See ts/CLAUDE.md.
+                 (React canvas), workflow-cli (fh-workflow CLI + reference SPA).
+                 See ts/CLAUDE.md.
 
 skills/          Claude Code skill wrapping the workflow CLI.
 ```

README.md

@@ -60,13 +60,13 @@ Requires the Go version pinned in `go/go.mod`. Configuration via `ENGINE_*` env
 ```sh
 cd ts
 npm ci
-cd app && npm run dev      # http://localhost:5173
+cd workflow-cli && npm run dev      # http://localhost:5173
 ```
 
 **Validate a workflow:**
 
 ```sh
-cd ts/app
+cd ts/workflow-cli
 npm run validate -- path/to/file.workflow.json
 # exit 0 → clean; exit 1 → diagnostics JSON on stdout
 ```
@@ -141,14 +141,14 @@ See [`go/CLAUDE.md`](go/CLAUDE.md) and [`ts/CLAUDE.md`](ts/CLAUDE.md) for deeper
 | [`go/`](go) | Engine binary, LLM proxy, hardware drivers, MQTT transport. Module `github.com/ForestHubAI/edge-agents/go`. |
 | [`ts/workflow-core`](ts/workflow-core) | `@foresthubai/workflow-core` — headless workflow model, validation, (de)serialization. No React. |
 | [`ts/workflow-builder`](ts/workflow-builder) | `@foresthubai/workflow-builder` — React canvas component. |
-| [`ts/app`](ts/app) | Reference SPA + `fh-builder` CLI. |
+| [`ts/workflow-cli`](ts/workflow-cli) | `@foresthubai/workflow-cli` — the `fh-workflow` CLI + the reference SPA it serves. |
 | [`examples/`](examples) | Runnable workflow examples per use case. |
 | [`skills/`](skills) | Claude Code skill wrapping the workflow CLI. |
 
 ## Releases
 
 - **Go runtime** — tagged `go/vX.Y.Z`. `go get github.com/ForestHubAI/edge-agents/go@vX.Y.Z`. Current: `go/v1.0.1`.
-- **TypeScript packages** — `@foresthubai/workflow-core` and `@foresthubai/workflow-builder` ship in lockstep at the same version.
+- **TypeScript packages** — `@foresthubai/workflow-core`, `@foresthubai/workflow-builder`, and `@foresthubai/workflow-cli` ship in lockstep at the same version, published to public npm.
 - **Container image** — multi-arch (`linux/amd64`, `linux/arm64`), distroless, nonroot, published to GitHub Container Registry.
 
 See [RELEASING.md](RELEASING.md).
@@ -171,7 +171,7 @@ Do not open public issues for security vulnerabilities. Use [GitHub private vuln
 | [`ts/workflow-core`](ts/workflow-core) (headless model) | **Apache-2.0** | Workflow model and validation. Same reasoning — should be embeddable into any TypeScript/JavaScript project without copyleft friction. |
 | [`go/`](go) (engine, LLM proxy, drivers) | **AGPL-3.0-only** or **commercial** | Keeps hosted "edge-agents as a service" offerings honest. For commercial use cases incompatible with AGPL, contact **root@foresthub.ai**. |
 | [`ts/workflow-builder`](ts/workflow-builder) (React canvas) | **AGPL-3.0-only** or **commercial** | Same dual-license terms as the engine. |
-| [`ts/app`](ts/app) (reference SPA, not published) | **AGPL-3.0-only** | Reference implementation, not for redistribution. |
+| [`ts/workflow-cli`](ts/workflow-cli) (`@foresthubai/workflow-cli` + reference SPA) | **AGPL-3.0-only** or **commercial** | Bundles the AGPL builder; same dual-license terms. |
 
 For the AGPL components, the AGPL network clause applies — providing a modified version over a network requires making the corresponding source available to users of that service.
 

RELEASING.md

@@ -7,10 +7,11 @@ never collide.
 | Artifact                            | Ecosystem             | Version source            | Consumer pins with                          |
 | ----------------------------------- | --------------------- | ------------------------- | ------------------------------------------- |
 | `github.com/ForestHubAI/edge-agents/go` | Go modules            | **git tag** `go/vX.Y.Z`   | `go get ...@vX.Y.Z`                         |
-| `@foresthubai/workflow-core`        | npm (GitHub Packages) | `version` in package.json | `npm i @foresthubai/workflow-core@X.Y.Z`    |
-| `@foresthubai/workflow-builder`     | npm (GitHub Packages) | `version` in package.json | `npm i @foresthubai/workflow-builder@X.Y.Z` |
+| `@foresthubai/workflow-core`        | npm (public, npmjs)   | `version` in package.json | `npm i @foresthubai/workflow-core@X.Y.Z`    |
+| `@foresthubai/workflow-builder`     | npm (public, npmjs)   | `version` in package.json | `npm i @foresthubai/workflow-builder@X.Y.Z` |
+| `@foresthubai/workflow-cli`         | npm (public, npmjs)   | `version` in package.json | `npm i -g @foresthubai/workflow-cli@X.Y.Z`  |
 
-Go and TS version on **independent cadences**. The two TS packages, however, are
+Go and TS version on **independent cadences**. The three TS packages, however, are
 **locked to each other** (see below) — they always ship one shared version.
 
 The real coupling risk between Go and TS is **not** version numbers — it's `contract/`
@@ -19,53 +20,62 @@ to diverge across ecosystems.
 
 ## TS (`@foresthubai/*`) — one lockstep command
 
-`workflow-core` (headless) and `workflow-builder` (React) are **always released together
-at the same version**, and the builder pins core to that exact version. They are split
-into two packages only so a CLI can import core's validator without pulling in React —
-not because they version independently. There is therefore no changeset/changelog
-machinery: a release is a single command, run from `ts/`:
+`workflow-core` (headless), `workflow-builder` (React), and `workflow-cli` are **always
+released together at the same version**; the builder pins core to that exact version.
+core and builder are split only so a CLI can import core's validator without pulling in
+React — not because they version independently; `workflow-cli` needs no pin because it
+bundles core/builder from source at build time (they're its devDeps). There is therefore
+no changeset/changelog machinery: a release is a single command, run from `ts/`:
 
 ```sh
 npm run release -- 0.2.0
 ```
 
 `ts/scripts/release.mjs` then:
 
-1. sets both packages' `version` to `0.2.0`,
+1. sets all three packages' `version` to `0.2.0`,
 2. pins `workflow-builder`'s `@foresthubai/workflow-core` dependency to exactly `0.2.0`,
 3. refreshes the lockfile, and
-4. runs `npm publish --workspaces` — which publishes core + builder and **skips** the
-   private `@foresthubai/app`.
+4. runs `npm publish --workspaces` — which publishes core + builder + workflow-cli.
 
-Each package's `prepublishOnly` rebuilds `dist/` first, so you never publish stale output.
+Each package's `prepublishOnly` rebuilds `dist/` (and the CLI bundle) first, so you never
+publish stale output.
 
-### Registry: GitHub Packages
+### Registry: public npm (npmjs.com)
 
-Both packages carry `publishConfig.registry = https://npm.pkg.github.com`.
+All three packages carry `publishConfig` targeting the public registry with public access:
 
-**To publish**, npm needs a GitHub token with `write:packages`, supplied via `~/.npmrc`
-(never commit it):
+```jsonc
+"publishConfig": {
+  "registry": "https://registry.npmjs.org/",
+  "access": "public"
+}
+```
+
+`access: public` is required — scoped packages (`@foresthubai/*`) publish as restricted
+by default, which fails on a free org plan.
+
+**To publish**, you must be a member of the `@foresthubai` org on npmjs.com and be logged
+in (`npm login`). For CI, use an npm **automation** access token (bypasses 2FA) via
+`~/.npmrc` (never commit it):
 
 ```
-//npm.pkg.github.com/:_authToken=$[Token with write access]
+//registry.npmjs.org/:_authToken=${NPM_TOKEN}
 ```
 
-**To consume** (e.g. the private FE repo), add `FH_PACKAGES_TOKEN` as env variable and add an `.npmrc` in consumers' root folder:
+**To consume** — nothing special. They're public:
 
-```
-@foresthubai:registry=https://npm.pkg.github.com
-//npm.pkg.github.com/:_authToken=${FH_PACKAGES_TOKEN}
+```sh
+npm i @foresthubai/workflow-core@X.Y.Z
 ```
 
-then `npm i @foresthubai/workflow-builder@X.Y.Z` as normal. See
+No `.npmrc`, scope mapping, or token needed (including from the private FE repo — drop any
+leftover `@foresthubai:registry=https://npm.pkg.github.com` redirect there). See
 [`ts/workflow-builder/README.md`](ts/workflow-builder/README.md) for the Tailwind/styles
 wiring the consumer must also do.
 
 > **No automated changelog.** Put a one-line "what changed" in the release commit so the
 > FE maintainer (often future-you) can see why a pinned version moved.
->
-> **Going public** keeps the `@foresthubai` scope — you'd own that org on npmjs.com and
-> drop the GitHub Packages registry line; the package name does not change.
 
 ## Go module — manual tag
 

skills/workflow-generate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: workflow-generate
-description: Build a ForestHub workflow JSON from a natural-language description, conforming exactly to contract/workflow.yaml, and validate it via the fh-builder CLI. Use when the user describes a workflow in prose and wants a ready-to-use *.workflow.json.
+description: Build a ForestHub workflow JSON from a natural-language description, conforming exactly to contract/workflow.yaml, and validate it via the fh-workflow CLI. Use when the user describes a workflow in prose and wants a ready-to-use *.workflow.json.
 ---
 
 # workflow-generate
@@ -19,9 +19,9 @@ The user describes a workflow in prose and wants a usable `*.workflow.json`.
 
 Do NOT use this skill for:
 
-- Editing an existing workflow visually — that's `fh-builder open`
+- Editing an existing workflow visually — that's `fh-workflow open`
 - Bundling a finished workflow for a controller — that's the `workflow-bundle` skill
-- Only checking an existing file — run `fh-builder check-schema` / `validate` directly
+- Only checking an existing file — run `fh-workflow check-schema` / `validate` directly
 
 ## How to run it
 
@@ -117,7 +117,7 @@ schema check must be green **before** the semantic validator is run at all.
 **Gate 1 — structural (`check-schema`). Loop here until it passes.**
 
 ```bash
-node ts/app/cli/fh-builder.mjs check-schema <path>
+node ts/workflow-cli/cli/fh-workflow.mjs check-schema <path>
 ```
 
 It catches shape errors (wrong `type`, missing required field, bad enum) with a
@@ -129,7 +129,7 @@ check is still failing** — a malformed shape must never reach Gate 2.
 **Gate 2 — semantic (`validate`). Only once Gate 1 is green.**
 
 ```bash
-node ts/app/cli/fh-builder.mjs validate <path>
+node ts/workflow-cli/cli/fh-workflow.mjs validate <path>
 ```
 
 It catches semantics: missing required parameters, unconnected nodes, type
@@ -157,7 +157,7 @@ Close by asking whether any of these values should be changed — plainly, e.g.
 can correct it in one reply.
 
 Finally, point at the natural next steps without doing them automatically:
-`fh-builder open <path>` to inspect visually, or the `workflow-bundle` skill to
+`fh-workflow open <path>` to inspect visually, or the `workflow-bundle` skill to
 ship it. **Never auto-bundle.**
 
 ## Notes for Claude