@beehexa/workflow-designer-vscode

The private dedicated Beehexa Workflow Designer workspace extension. It owns the shipped playground app, editor commands, IntelliSense installation, and native MCP registration, and is the consumer entrypoint for VS Code users.

Product: design and inspect, not execute

Workflow Designer renders workflow structure and lets you author presentation profiles and design configuration in a bundled local playground. Its configuration controls node shapes, themes, classification, connections and layout. Workflow source remains separate from the profile and saved design; this extension does not run your business workflow, supply a hosted service or perform application-specific writeback.

The dedicated extension coordinates its bundled Model, Profile, Core, renderer, Playground, Docs, IntelliSense and MCP components as one recorded release cohort. You do not install renderer npm packages to use this VSIX. Its playground and MCP runtime are included locally; reading Guidelines does not require a network download or another checkout. External client registration still needs the client you select.

Included authoring and AI toolkit

This VSIX includes the standalone Workflow Designer authoring application and the AI toolkit; neither the HexaSync Templates extension nor separately installed Graphkit packages are required. Run Beehexa Workflow Designer: Start Playground, open its authenticated workspace preview, and click Open Workflow Authoring to reach Theme/Shape/Node Rule/Connectivity Studios and Workflow Composer. The existing workspace profile preview and folder synchronization remain available; authoring changes stay in the authoring tab until you export their configuration. The authoring document and its assets use the same bridge session protection as the preview.

Run Beehexa Workflow Designer: Install AI Toolkit to preview and explicitly install bundled skills/MCP configuration for your selected client. The bundled toolkit and stdio MCP run locally, without runtime package downloads. Standalone MCP, toolkit and playground packages remain independently installable outside VS Code.

Package facts

• Manifest version: 2608.20.17
• Release cohort: extension@2608.20.17
• Buyer range: ^2608.20.17 (local proof tarball only; consumers install the private extension as a VSIX)
• Version scheme: yymm.dd.count (year/month, day 1–31, positive daily count; npm segments unpadded). Committed manifests are floors, not authoritative release stamps; do not hand-reconcile split floors.
• Range semantics: A caret uses the package version for resolution, permits later versions in the same numeric yymm major and excludes the next month; it does not assert API stability or cohort uniformity.
• Support/evidence identity: cohort BOM sha256:bb78ff3b1e8e8bfa1186630583ab7088fa02814f120f9188cc674dfba0212d3f plus the per-component table in the package reference. Quote package name/version for resolution instead. Sources is outside BOM membership.
• Entry stability: . — stable
• API/support policy: unenumerated paths and explicitly internal entries are unsupported; stable APIs receive at least 180 calendar days of deprecation notice in artifact README/reference/CHANGELOG (and TypeScript @deprecated where applicable). Calendar-major changes do not authorize breaks. Buyer API/support policy states migration limits, security exceptions and licence/contract coverage.
• Support boundary: exact measured host/client/version/platform configurations only; unmeasured is manual/UNVERIFIED, not certification or blanket denial. Compatibility and engine floors are not measurement. Contact https://www.beehexa.com/ or your written agreement’s support channel; no SLA or support entitlement is created by the artifact licence.

API stability, deprecation and support policy

The Exports column enumerates every declared package export entry with its reviewed stability class, also shipped as workflowDesignerApiStability in each artifact manifest. A class covers the documented API and types at that entry, not every incidental implementation symbol or deep file. Anything not enumerated is internal and unsupported. Entries explicitly classified internal exist for product composition only and are unsupported for external integrations even when Node can resolve them.

• stable: documented contracts are maintained; incompatible changes require the notice and migration policy below.
• experimental: opt-in, no compatibility or minimum deprecation-notice guarantee; changes are identified in the artifact changelog.
• deprecated: still usable under the prior stable contract until its published removal date; migrate using the stated replacement.
• internal: no external compatibility or support commitment. Import only the public entries you need, not artifact deep paths.

Deprecation and breaking changes

For a stable API, give at least 180 calendar days from the first shipped notice before removal or an incompatible documented-contract change. The consumer signal is a dated artifact-local README/API-reference notice and CHANGELOG entry identifying the package, entry or symbol, affected cohort bomHash, replacement, migration steps and earliest removal date; deprecated TypeScript APIs also carry @deprecated in shipped declarations. No runtime telemetry or warning delivery is promised. Read these artifacts before upgrading. No APIs are declared deprecated by this policy alone.

A planned breaking-change release may remove deprecated APIs or change documented signatures, behavior or protocol/schema contracts only after that notice, explicit migration guidance and declared compatibility negotiation/version changes where applicable. It may not silently redefine an unchanged protocol/schema, remove before the announced date, overwrite a prior artifact, withdraw previously granted licence rights, weaken security boundaries, or label unmeasured configurations supported. Urgent security fixes may disable unsafe behavior immediately with a security/changelog notice and mitigation; this exception is not permission for unrelated API removal.

The package scheme remains yymm.dd.count, not conventional semantic API versioning. Its numeric major is a calendar month: a month rollover is neither a promise nor authorization for an API break, and same-month caret eligibility does not guarantee compatibility. Breaking intent must be explicit in the notice regardless of the numeric segment. Pin a lockfile, review migration notes and qualify upgrades. Package versions select dependencies; support and evidence identify the cohort bomHash plus per-component/protocol table. A changed built cohort must have its newly generated BOM; a package version cannot substitute for it, and an old evidence row is not a new cohort measurement.

Buyer support boundary

Ask Beehexa for documented public-API integration guidance, reproducible defects on measured configurations, diagnostic interpretation, migration/deprecation guidance, licence authorization and third-party notice/source-delivery questions. Start through https://www.beehexa.com/ (official commercial/contact channel), or the support channel expressly named in your written commercial agreement. Include cohort bomHash, component/package versions, host/client version, platform and redacted reproduction/diagnostics; never send credentials or private workflow payloads unnecessarily.

Paid response times, SLA, maintenance term, warranties, custom work and remedies exist only if your written commercial agreement grants them. The artifact-local commercial LICENSE covers prospective Beehexa-owned Designer material and reserves use/redistribution rights to that authorization; it does not itself grant support entitlements. Previously granted MIT rights and the separate MIT HexaSync products remain intact. Third-party components retain their own licences/notices/source obligations and do not supply Beehexa support or warranty. The commercial agreement and applicable licence govern their respective material and commitments; this policy creates no extra contractual rights.

Out of scope absent an express contract: unsupported internal/deep imports, experimental compatibility guarantees, workflow/business-engine execution, consumer business writeback, customer code/infrastructure administration, arbitrary third-party clients or undocumented custom integrations, universal platform/browser certification and registry/Marketplace availability. Unmeasured configurations may receive manual guidance and requests for reproducible evidence; absence of a measurement is neither certification nor a blanket refusal of help.

Compatible is not measured-supported

Only exact measured host/client/version/platform configurations are supported to the extent their recorded evidence proves. See Host capabilities and limitations for measured host observations and the exact client/version/platform rows and evidence IDs. Do not combine unrelated host and client rows into a newly certified configuration. Manifest engine floors and successful protocol negotiation describe eligibility/compatibility, not measured support. Measurements retain their dated provenance; locally installed candidate smoke proves the paths exercised, not a fresh third-party client qualification.

For a known supported MCP profile, an unmeasured version/platform returns manual / UNVERIFIED with safe generated configuration, informational DESIGNER_MCP_CLIENT_VERSION_UNTESTED and DESIGNER_MCP_CLIENT_MANUAL_CONFIGURATION_REQUIRED, and no evidence ID. Automatic installation refuses manual results without writing. The existing manual profiles likewise offer unverified guidance. Unknown or explicitly unsupported profiles and unsafe/non-package launch descriptors remain refused by their existing guards. Protocol, credential, workspace, size and atomic-install protections are unchanged. Windows/macOS or an unlisted version are not blanket-denied merely for missing evidence.

• Peer dependencies: none
• Host prerequisites: VS Code ^1.90.0; redhat.vscode-yaml >=1.22.0 is required only for active profile YAML IntelliSense, not extension activation or unrelated commands

The workspace:* values above are source-manifest facts; Yarn may rewrite workspace protocols when packing. This package is private and is not an npm library.

Install and minimum launch

This private package is the VS Code extension, not an npm renderer library. Obtain the local .vsix artifact and install it into the host you run:

code --install-extension ./workflow-designer-vscode.vsix

One-command local development install

Team members with the source workspace and its dependencies installed can build, package and install the Designer into their selected host with one command from the workspace root (these commands are not required to install a supplied VSIX):

yarn workspace @beehexa/workflow-designer-vscode install:vscode-server
yarn workspace @beehexa/workflow-designer-vscode install:vscode

The server command selects the newest-mtime downloaded VS Code serve-web build under the current user's home, falling back to code-server on PATH. The desktop command uses code on PATH. Before building/packaging, each prints the target, CLI, resolution method, host version and extensions directory, and rejects hosts outside the complete ^1.90.0 engine range. It then uses the existing production build/staging route, installs the VSIX and rereads that host's extensions.json; a CLI exit status of zero alone is not success.

Use HEXASYNC_VSCODE_CLI to select the running host's native executable if the newest downloaded build is not the running one, or PATH selects a different host. In a remote terminal, code may itself be a remote-only launcher: select the desktop executable explicitly for a desktop install. Use HEXASYNC_VSCODE_EXTENSIONS_DIR to override the concrete extensions directory; otherwise the installer uses the host product's native default (including native environment defaults), not whichever extension directory happens to exist. HEXASYNC_VSIX_OUT optionally selects the local output artifact path; its parent directory must already exist.

DESIGNER_INSTALL_CLI_MISSING names an absent/unusable CLI. DESIGNER_INSTALL_HOST_ENGINE names the incompatible host version and required range/floor before any packaging. If a newer Designer version is installed, the installer warns first. DESIGNER_INSTALL_DOWNGRADE_DECLINED means the registry still selects a higher version even though the CLI exited zero: keep the newer version, or intentionally uninstall only the Designer with the printed native CLI/directory command before reinstalling. DESIGNER_INSTALL_WRONG_EXTENSIONS_DIR means the target version is absent without a higher version; check both overrides against the running host. Neither failure prints a successful reload instruction. Other extensions and user configuration are not removed.

After verified installation, desktop users run Developer: Reload Window; server users reload the browser tab (or Reload Window). For a same-version replacement, hard-reload the tab if an icon or manifest remains cached. Reload and activation are separate from the CLI inventory verification.

Open a trusted workspace, then run Beehexa Workflow Designer: Start Playground followed by Open Playground from the Command Palette. The browser application mounts the designer; VS Code supplies workspace filesystem and process capabilities. Restricted/virtual workspaces have the declared read-only limitations. Stop with Stop Playground. Profile/sample commands retain their sample bundle format; finished configuration uses two separately versioned files in the design UI.

No npm peers are required by extension users; framework dependencies are bundled by the extension. Active YAML IntelliSense requires redhat.vscode-yaml >=1.22.0. VS Code ^1.90.0 is required. Library consumers choose one renderer instead. No Marketplace publication is claimed.

This README and the accompanying CHANGELOG are shipped in the locally built VSIX and are readable in the installed extension’s Details and Changelog tabs. This extension is distinct from HexaSync Templates.

Package selection contract

• Exports: .
• Direct Workflow Designer dependencies: @beehexa/workflow-designer-core@workspace:*, @beehexa/workflow-designer-docs@workspace:*, @beehexa/workflow-designer-intellisense@workspace:*, @beehexa/workflow-designer-mcp@workspace:*, @beehexa/workflow-designer-model@workspace:*, @beehexa/workflow-designer-playground@workspace:*, @beehexa/workflow-designer-profile@workspace:*, @beehexa/workflow-designer-react@workspace:*, @beehexa/workflow-designer-vanilla@workspace:*, @beehexa/workflow-designer-vue@workspace:*
• Graph position / direct edges: Private extension host; directly depends on the ten packages shown
• Role: Consumer entrypoint
• Domain neutrality: Not claimed for this dedicated host product.

The dependency summary is Model → Profile → Core → adapters → Playground/Docs/MCP/IntelliSense → extension; this is a branching layer guide, not a claim that every package depends on every previous package. The direct edges above are authoritative. Source-manifest workspace:* ranges identify sibling packages; normal packing rewrites them to supplied versions. Read the installed manifest for the actual resolution ranges.

Canonical Guidelines · Package selection

Canonical Workflow Designer Guidelines

Choose exactly one starting renderer: @beehexa/workflow-designer-vue for Vue, @beehexa/workflow-designer-react for React, or @beehexa/workflow-designer-vanilla for plain DOM. Core is the renderer-neutral/headless start; MCP and VS Code are host-specific starts. Model, Profile, Sources, Docs, IntelliSense and Playground are low-level extension points, not additional framework entrypoints. Public internal subpaths do not make a whole package internal.

Installation and package facts in this README are usable without a checkout. Preserve the supplied lockfile, qualify upgrades, keep workflow source separate from profile/design configuration and import only supported entries. The optional installed MCP resource bwd://docs/package-selection-reference and installed Docs bundle provide the fuller canonical reference; neither is required to read this README.

These are a different, separately published product: @beehexa/hexasync-workflow-profile-flow, @beehexa/hexasync-workflow-vue, @beehexa/hexasync-workflow-react, @beehexa/hexasync-workflow-vanilla, @beehexa/hexasync-workflow-playground, and the @beehexa/hexasync-template-* family. Do not substitute them for Workflow Designer packages.

Command Palette reference

Open the Command Palette and search Beehexa Workflow Designer. These are the commands contributed by this extension; their names are not npm entrypoints.

Reading the bundled Guidelines

Run Beehexa Workflow Designer: Open Guidelines for the extension-host reading surface. MCP clients can initialize the bundled server, discover its resources and read the canonical bwd://index resource; the documentation index leads to package selection, profiles, host capabilities and authoring references. MCP resource URIs are protocol identifiers, not HTTP addresses to paste into a web browser.

Workspace and runtime requirements

Use a trusted local or remote filesystem workspace for the playground and MCP processes. Restricted Mode and virtual filesystems retain their declared read-only profile behavior; they do not gain writable/process capabilities by installing a VSIX. YAML completion requires redhat.vscode-yaml >=1.22.0; install that separately if you need completion. An engine-compatible host is not automatically a measured supported host/client/platform configuration.

If a command reports incompatible cohort components, inspect Show Status and install a coherent supplied artifact instead of editing bundled version metadata. For MCP failures use Run MCP Doctor and the local Guidelines. Keep the diagnostic, host/client versions and cohort BOM when requesting help; redact private paths, credentials and workflow data. For workspace write restrictions, change workspace trust or select a writable filesystem only when appropriate for your environment.

Licence and included third-party material

The installed LICENSE.txt preserves the commercial terms and prior grants; installation is not itself a licence authorization. THIRD-PARTY-NOTICES and any included corresponding-source materials preserve third-party rights independently. The embedded MCP runtime also carries its own licence/notices. Do not remove these materials when redistributing an artifact under an applicable authorization.