OpenTest

English | 简体中文

OpenTest is a Windows desktop application with an Electron shell, a Vue frontend, a Java backend, and independently installed measurement plugins. The host provides projects, device connections, acquisition, charts, storage, and plugin management; business plugins provide measurement and analysis workflows.

This guide takes a fresh Windows x64 checkout through a real FFT measurement with a local WASAPI microphone, including saving and reopening the result. It targets the code accompanying this README. Use matching host and plugin revisions; local changes on another developer's machine are not included in a clone.

1. Before cloning

Have the following ready. A source checkout does not include account credentials or user entitlement certificates.

Requirement	What to obtain or check
Windows x64 and PowerShell	Use a writable local development directory. Administrator access is needed to install the C++ build tools.
Git	Install Git first; check git --version.
Repository and network access	Use matching revisions of OpenTest and OpenTest-Plugins. Access is also needed to npm, GitHub, Node/Electron downloads, and the host's Maven repositories.
Workspace and FFT authorization	For online use, obtain the Casdoor application configuration, a real account, the business license service configuration, and the applicable FFT entitlement. Alternatively, obtain valid machine-bound or USB offline authorization permitting the measurement.
Real audio input	A working built-in or USB microphone visible to Windows. Allow desktop apps to access it in Windows privacy settings and check that the input meter responds to your voice.

Install your own base development tools; see section 3 for versions and configuration. Repository scripts check the environment and prepare local Java artifacts; native materials are stored directly in the source tree. See development environment and dependencies for details.

2. Clone OpenTest

Replace the URL placeholder with the host repository URL. Choose a new checkout directory; this example uses D:\WorkSpace\opentest.

$hostDirectory = 'D:\WorkSpace\opentest'
$hostRepository = 'REPLACE_WITH_HOST_REPOSITORY_URL'
New-Item -ItemType Directory -Force -Path (Split-Path -Parent $hostDirectory) | Out-Null
Set-Location (Split-Path -Parent $hostDirectory)
git clone $hostRepository $hostDirectory
Set-Location $hostDirectory

If your team specifies a branch or tag, check out that revision. Resolve any failed command before continuing. Run the host preparation, build, and startup commands from this checkout's root.

OpenTest-Plugins is the independent plugin development repository, introduced in step 6. Host setup requires only this repository; running FFT later requires a compatible .otplugin package.

3. Prepare development tools, native materials, and project dependencies

Install your own development tools

The repository does not download/install base tools or change PATH, JAVA_HOME, package-manager settings or cache locations. Install the following tools yourself and open a new regular PowerShell:

Tool	Requirement and configuration
Node.js	>=22.14.0, available on PATH.
pnpm	Stable versions >=10.6.5 and <11, available on PATH. Choose your own installation method. packageManager retains 10.6.5 as the pinned tool version.
JDK	Full JDK 21 with java and javac; set JAVA_HOME.
Maven	3.9.x; set MAVEN_HOME (M2_HOME is also supported) or add Maven to PATH.
Python	Required when compiling native modules: Python 3.11 or newer. Set PYTHON or npm_config_python to its executable path. Not checked by pnpm deps:check.
Visual Studio C++ Build Tools	Visual Studio 2022 or 2026 C++ x64/x86 build tools and Windows SDK 10.0.26100. Install them through the vendor installer.
Git	Available on PATH, with access to the required GitHub repositories.

Run the read-only check below. Install Node yourself first if it is missing; the checker requires Node to run.

node --version
pnpm deps:check

The checker reports missing or incompatible tools without fixing them. For frontend-only work, pnpm deps:check --node-only checks Node, pnpm and Git.

Install project dependencies and locate native materials

Run pnpm install --frozen-lockfile from the host root. It installs locked JavaScript dependencies; the existing onlyBuiltDependencies allows Electron, esbuild and protobufjs to run their required build scripts. The Electron runtime and node-gyp headers remain project dependencies.

Native C++ sources and backend runtime materials have separate locations. Runtime libraries and their matching default Windows licenses are stored directly in Git. No extraction or restoration command is needed:

Directory	Purpose
apps/native	Native C++ sources and build projects, separate from deployed backend runtime files
apps/backend/crydaq-server/src/main/resources/native/<platform>	Backend runtime libraries, auxiliary files, and native-libs-load-order.txt
apps/backend/crydaq-server/src/main/resources/native/<platform>/prd	Platform-specific production overlay applied to staging without changing base libraries
apps/desktop/packages/native-modules/vendor/algorithm-bridge	Desktop algorithm DLLs copied into native-module build outputs

<platform> is windows-amd64, linux-amd64, or macos-arm64. Source startup selects the platform and architecture of the runtime; WSL configured to launch Windows Java selects windows-amd64. OPENTEST_NATIVE_MATERIALS_ROOT selects a resources root containing native/<platform>, with production overrides inside that platform's prd directory. Each runtime uses the main native-libs-load-order.txt and its referenced files. Windows installers, upgrades, and signing always select windows-amd64; installed bundles keep the selected runtime directly in resources/backend/native.

Windows requires a matching native/windows-amd64/License.dat; production also requires native/windows-amd64/prd/License.dat and its matching cry_analyst.dll. Both default license files are tracked and delivered with their matching runtime libraries. Linux and macOS licenses are optional, but a supplied license must be a nonempty regular file. Production requires the selected platform's matching overlay and never falls back to test materials or another platform. User entitlement certificates and logs remain separate. New checkouts no longer need Git LFS or ZIP archives.

Normal host and plugin consumers use prebuilt core runtime materials and the public SDK. They do not need access to OpenTest-NativeDriver. Windows packaging uses its existing Windows runtime and desktop vendor DLLs independently of POSIX materials. Public Node addons still compile with node-gyp.

Matching new algorithm SDK and runtime materials for Mac/Linux are pending. Those platforms are outside the current acceptance scope. Their consumer scripts require prebuilt JNI, Host, algorithm bridge, unit-conversion and dependency libraries. Packaging checks the current com.opentest.core.jni namespace and prepareManagedRuntime marker and rejects missing or outdated files without a private-source compilation fallback. These checks do not establish POSIX functionality.

Preparation command	Scope
pnpm deps:check	Read-only development tool/version checks
pnpm install --frozen-lockfile	Install locked JavaScript project dependencies
pnpm prepare:backend-deps	Run mvn clean install -DskipTests in apps/backend, including all backend modules; compile tests but skip execution

The old deps install/offline/restore/verify/download wrappers and prepare:backend-native have been removed. Existing tool folders and caches remain local and are not automatically discovered or activated. Open a new terminal if you previously ran env.ps1. npm/pnpm follow developer cache and registry settings; Maven follows settings/default (usually %USERPROFILE%/.m2/repository). Old caches are not automatically migrated or deleted.

To compile and install all backend artifacts into the local Maven repository, run pnpm prepare:backend-deps from the host root. This is equivalent to running mvn clean install -DskipTests in apps/backend. Stop the source backend first to avoid concurrent changes to target directories. It uses the terminal JDK/Maven configuration and Maven settings without selecting modules. Tests are compiled but not executed; run mvn clean install directly in apps/backend when full test verification is needed. It does not read the adjacent plugin repository; --plugins-dir is no longer supported. deps:*/build/dev commands do not invoke it implicitly.

The complete Java runtime used by Windows installers is tracked in ordinary Git at vendor/java/windows-x64. Mac/Linux packaging uses the target JDK 21 and jlink by default. It is independent of the development JAVA_HOME; default packaging does not depend on .runtime/release/java or files from another computer. See Java materials for version and update requirements.

Run pnpm test:dependencies for dependency toolchain regression checks. Source startup reads the authorization environment and service URL from root runtime.env; packaging selects them from the requested mode in packaging.config.json.

Localization resources are versioned. Backend Maven builds download translations by default; use -Dskip.crowdin.download=true to build with local resources. Private Crowdin configuration stays local, and running the app requires no Crowdin access.

Paths below are relative to opentest/. Local directories are ignored by Git. Replace all placeholders with values issued for your environment.

New-Item -ItemType Directory -Force -Path .local, apps/desktop/.runtime, apps/backend/.runtime | Out-Null
Copy-Item -LiteralPath apps/desktop/local-settings.example.json -Destination apps/desktop/.runtime/local-settings.json
Copy-Item -LiteralPath runtime.env.example -Destination runtime.env
notepad .\runtime.env

Create root runtime.env from runtime.env.example. The template selects production and uses the license service at https://update.opentest.com. Source startup reads OPENTEST_LICENSE_ENVIRONMENT and OPENTEST_LICENSE_URL from this file. Both packaging modes default to the same service URL in packaging.config.json.

Save as UTF-8 with the exact name runtime.env, not runtime.env.txt. The source authorization environment and service URL come from this file. Restart development services and the desktop after changes.

Online account and business license service

If you will use approved offline authorization, skip this subsection and follow the offline alternative below.

Online use needs both desktop public settings and Java authentication settings. Obtain the matching Casdoor application/client and registered callback from the identity-service administrator. No login or business license service is started by cloning this repository.

Edit apps/desktop/.runtime/local-settings.json using this structure. Chart rendering uses the fixed CRYChart artifact in vendor/crychart/; no chart runtime license configuration is required.

{
  "auth": {
    "serverUrl": "https://identity.example.com",
    "clientId": "REPLACE_WITH_CLIENT_ID",
    "application": "REPLACE_WITH_APPLICATION",
    "organization": "REPLACE_WITH_ORGANIZATION",
    "redirectUrl": "http://127.0.0.1:15021/login/oauth2/code/casdoor",
    "signupUrl": "",
    "forgetPasswordUrl": ""
  },
  "updates": {
    "enabled": false,
    "apiUrl": "",
    "productId": "opentest-framework"
  }
}

Create apps/backend/.runtime/application-local.properties as UTF-8:

spring.security.oauth2.client.registration.casdoor.client-id=REPLACE_WITH_CLIENT_ID
spring.security.oauth2.client.registration.casdoor.client-secret=REPLACE_WITH_CLIENT_SECRET
spring.security.oauth2.client.registration.casdoor.redirect-uri=http://127.0.0.1:15021/login/oauth2/code/casdoor
spring.security.oauth2.client.provider.casdoor.authorization-uri=https://identity.example.com/login/oauth/authorize
spring.security.oauth2.client.provider.casdoor.token-uri=https://identity.example.com/api/login/oauth/access_token
spring.security.oauth2.client.provider.casdoor.user-info-uri=https://identity.example.com/api/get-account
spring.security.oauth2.client.provider.casdoor.jwk-set-uri=https://identity.example.com/.well-known/jwks

Replace the identity-service example host. Set the source authorization environment and cloud-service base URL in root runtime.env; package URLs live under each mode in packaging.config.json. Casdoor login alone does not provide FFT rights. The backend defaults (unconfigured client and loopback service placeholders) do not provide working cloud authentication/authorization.

The client ID and registered callback must match the desktop settings. Changing BACKEND_PORT also requires checking callbacks. Keep client secrets in the backend local file or backend process environment, never in frontend VITE_* fields or public desktop JSON. Properties values do not use surrounding dotenv-style quotes; escape backslashes as required by the properties format.

If your business license service requires client JWT authentication, add its administrator-supplied settings to the backend properties file:

# Only if required by the business license service:
cloud.client-jwt.enabled=true
cloud.client-jwt.private-key=REPLACE_WITH_SINGLE_LINE_BASE64_PKCS8_RSA_PRIVATE_KEY

This is disabled by default. Use the service's trusted key material; do not generate an arbitrary replacement. CASDOOR_SERVER_URL only sets the desktop public address, not Java provider URLs. Explicit CASDOOR_CLIENT_ID / CASDOOR_CLIENT_SECRET process variables can override the backend file; check stale overrides when configurations disagree.

Offline authorization alternative

For an approved offline workflow, obtain a machine-bound authorization file or supported USB material with the required FFT rights. In the initial authorization dialog, choose Offline Use / 离线使用, generate/copy the machine code, have the license administrator issue the matching authorization, then import the file and wait for success. The offline page's Dongle Auth / 加密狗认证 entry provides the USB workflow; follow your issued material's provisioning instructions. Generating a machine code alone grants no rights.

The user menu's later Login / 登录 action opens a cloud-login-only dialog. If you need the initial offline workflow after dismissing it while still unauthorized, restart the application to show the initial authorization dialog again.

Valid offline authorization can enable the workspace and plugin management without cloud account login. It does not bypass FFT limits. The online Casdoor setup is required for the online path, not for a workspace using valid offline authorization.

5. Build and start the host

In the activated host terminal, run each command only after the preceding one succeeds:

pnpm build
pnpm start

The build compiles the client SDK, Java backend, frontend, and desktop/native modules. Plugin packages are built and installed separately; this command does not create a Windows installer. The host Java build uses -DskipTests; build success is not a Java test result.

Wait for the startup screen to finish and the backend to become ready. Complete online login or the approved offline workflow. The shell can be visible before authorization; verify that project/workspace operations are available. A logged-in account may still lack an FFT entitlement.

For later starts, pnpm start reuses the build. Close the desktop normally and wait for its Java process and the terminal command to finish before starting another instance.

To develop the Java backend independently, use the activated host terminal:

pnpm dev:backend           # run Maven clean package, then start the executable JAR

Every development start runs Maven clean package -DskipTests, clearing previous build output before rebuilding the executable JAR. This avoids packaging stale classes or resources left by deleted or renamed source files. The launcher no longer hashes build inputs or JARs, maintains success records, or holds a custom build lock.

pnpm dev uses the same backend build command. Failed or cancelled builds prevent startup; the launcher never falls back to an older JAR. Stop the existing source backend before rebuilding, and run builds of the same source directory serially. start:backend has been removed; normal pnpm start remains the strict release entry.

Development starts launch the resulting JAR with java -jar and explicitly enable the mutable installed-content policy. Plugins still load only from their active installed package directories. The commands retain the local configuration, port checks, logs and cleanup below. Wait for readiness; Ctrl+C stops the owned backend. Do not share ports with another launcher. A Java edit may still rebuild multiple modules.

Item	Default for root startup commands
Frontend / HTTP / gRPC ports	19010 / 15021 / 19021
Runtime data	.runtime/app (OPENTEST_RUNTIME_DIR)
Projects and results	.runtime/app/projects (OPENTEST_PROJECTS_DIR)
Desktop profile	.runtime/app/user-data
Backend console log	.runtime/app/logs/backend/backend-console.log
Backend service logs	.runtime/app/logs/service

Paths change when the runtime directory is overridden. Preserve the profile and project directories to retain sessions/data. Installed builds default to a separate root, %LOCALAPPDATA%/OpenTest.

6. Obtain and install FFT

OpenTest-Plugins contains the FFT plugin implementation, development materials, and build tools. Use its README for available plugins, supported host versions, and build instructions. OpenTest and its plugins integrate through the public SDK and .otplugin packages.

For the first measurement, obtain a compatible FFT .otplugin from the plugin maintainer, or build one using the independent development workflow below. The package name is com.opentest.fft-tools-<version>.otplugin; read its version from plugin.json and the build's package metadata. The current FFT manifest declares host compatibility >=2.5.0 <2.6.0; check openTestVersion in the selected plugin revision against your host.

In the desktop:

1. Hover over the navigation bar's more/settings icon, then select 插件管理 (Plugin Management).
2. Click Load Plugin, then Choose file, and select the FFT .otplugin you obtained or built. The independent manager follows the main window's English/Chinese language and theme.
3. Review the package details and validation result, explicitly trust this package, and click Load Plugin. Enable after restart is selected for a new installation; the resulting change remains pending until restart.
4. Completely exit OpenTest, wait for the backend to stop, then run pnpm start again in the host terminal. Restore login/authorization if required.
5. Open/create a project and go to Measure / 测量 → FFT. Check that FFT parameters and measurement controls appear. Pending restart alone does not mean the plugin is active.

To upgrade, load a higher version of the same plugin; upgrades preserve its enabled state and take effect after a complete restart. Same-version replacements and downgrades are rejected. Enable, disable and remove actions also remain pending, with per-plugin undo and undo all. Disabling or removing retains data but stops all plugin capabilities after restart, including result viewing and export. A failed upgrade requires another complete restart to restore the previous version; business data is not rolled back. Managed backends offer Restart now, which blocks running measurements, sequences and signal output and discards unsaved edits. External backend sessions require manually restarting both backend and desktop. Do not edit plugin state files or rename packages to bypass version checks. Installing FFT does not install audio drivers or grant feature rights.

Develop plugins with OpenTest-Plugins

Clone the plugin project to a location of your choice and follow its own README and dev-kit/README.md. Prepare Node.js ≥22.14.0, Corepack/pnpm 10.6.5, JDK 21, and Maven; set JAVA_HOME and provide Maven through PATH or MAVEN_HOME. The committed dev-kit supplies frontend SDKs. Java dependencies first require mvn clean install in the matching host's apps/backend, or pnpm prepare:backend-deps in its root to compile tests while skipping execution. Stop the source backend before either command. Both projects must use the same Maven local repository; plugins resolve public dependencies without importing host private source.

git clone https://github.com/crysound/OpenTest-Plugins.git
Set-Location .\OpenTest-Plugins

Use these paths within OpenTest-Plugins as development references:

Reference	What to learn
plugins/fft-tools/plugin.json	Plugin identity, host compatibility, entry points, and contributions
plugins/fft-tools/frontend/index.ts and plugins/fft-tools/frontend/src/contributions/	Frontend activation, measurement workspace, and parameter editor
plugins/fft-tools/backend/src/	Backend registration, measurement providers, and execution handlers
plugins/fft-tools/backend/src/main/java/com/opentest/plugins/fft/measure/ and plugins/fft-tools/frontend/locales/	Typed business configuration, provider execution, and localization; the manifest declares configVersion
dev-kit/README.md	Public SDK usage, dependency configuration, and interface boundaries

After preparing that project's environment, run in the plugin repository root:

node tools/build.mjs fft-tools
Get-ChildItem -LiteralPath .\dist -Filter 'com.opentest.fft-tools-*.otplugin'

This validates its dev-kit, installs frozen frontend dependencies through Corepack/pnpm, runs frontend type checking/tests/build, runs Java mvn package including tests, and writes dist/com.opentest.fft-tools-<version>.otplugin. First-time plugin builds need network access. Import the resulting package through the host UI as described above. Use the matching committed dev-kit for ordinary plugin development; host API maintainers export updated material when public interfaces change.

Develop against the active installed plugin

Install the plugin once through the normal .otplugin flow and complete the required full restart. In the plugin repository root, create the Git-ignored plugin-development.json:

{
  "runtimeDirectory": "../opentest/.runtime/app"
}

The path may be absolute or relative to this configuration file. In the plugin repository, pnpm dev fft-tools builds and directly updates FFT's active installed directory; pnpm dev:watch only rebuilds and deploys frontend and locale files. Neither command installs frontend dependencies or changes the host's active plugin state.

Start the host with pnpm dev, which explicitly allows mutable installed content. Plugin Java changes require another full plugin pnpm dev and a manual backend restart. Frontend changes require a successful deployment and a full page refresh; there is no plugin-specific hot reload. Manifest or contract changes require the full plugin command and a backend restart. pnpm start and installed applications remain strict and reject a modified package; restore strict use through normal uninstall and reinstall.

7. Make, save, and reopen a real microphone measurement

Use the actual microphone input, not an output/loopback channel, an existing file, or a simulated source. One input channel is sufficient.

1. Confirm Windows enables the microphone, its input meter reacts to speech, and desktop microphone access is allowed. Refresh OpenTest's device list if necessary and find that real WASAPI device. Names vary by machine; Realtek is not required.
2. Use the project menu to create a New Project / 新建工程, such as First FFT, or open the project created in step 6.
3. In the project's channel panel, select ＋ / Hardware Configuration / 硬件配置. In that dialog, select ＋ / Add Channels / 新增通道, expand the microphone device, select at least one physical input, and click Submit / 提交. Confirm the input is present in the project and online.
4. In Measure → FFT, select it again under Input Channels / 输入通道. Adding a project channel and selecting an FFT input are separate steps. Keep basic/default FFT settings and choose Stop Method / 停止方式 → Manual / 手动. Use a sample format supported by the device; 48 kHz is suitable when available. Leave advanced licensed modes disabled for this check.
5. Click Start / 开始, speak near the microphone, and observe the live frequency spectrum responding for about six seconds. No speaker output or signal generator is needed. A static empty grid, license error, or immediate run failure does not pass.
6. Click Stop / 停止 once. Wait until controls return to ready and a new entry appears under Test Data / 测试数据. Normal stopping saves acquired results; this workflow has no separate save-button step. Record the project and result entry/time.
7. Select the new record and check its FFT chart. Close OpenTest normally, wait for the backend, restart with pnpm start, reopen the same project, and select the same saved record under Test Data. Confirm its spectrum displays without a new acquisition.

The first-run check is complete only when:

• The desktop/backend start with the intended configuration and the workspace is authorized.
• FFT is registered after a complete restart and its spectrum chart renders correctly.
• Real microphone data produces a changing spectrum.
• Normal stopping saves a result that can be read after a complete restart.
• The desktop and its managed backend exit normally.

The existing plugin acceptance helper checks persisted records, nonzero microphone WAV samples, saved FFT data, and history rendering. It expects a prepared acceptance session/project, so it does not replace the setup and UI installation above. This guide describes the procedure, not a claim that your hardware has passed it. A microphone smoke test does not establish calibrated instrument accuracy.

For a dedicated acquisition device, install its vendor driver, connect it, refresh discovery, and bind its real inputs instead. An installed ASIO driver does not establish that hardware is online. Device-specific calibration/performance acceptance remains separate.

8. Daily development and troubleshooting

After first-time preparation, run in a terminal with your development tools configured:

pnpm dev

This starts the frontend source server, builds Java with Maven clean package -DskipTests and launches the executable JAR, and starts the desktop source entry, preparing necessary SDK/native outputs. A prior full build is not required. Independent pnpm dev:frontend, pnpm dev:backend, and pnpm dev:desktop commands need separate configured terminals; closing an independent desktop does not stop an independent backend. Use build/start for the first measurement documented above.

After loading backend plugins, the host waits for frontend registration. Waiting longer than two minutes only logs a warning; after starting or restarting the backend, fully reload the page to complete registration. Development and production follow the same rule. Actual activation failures or timeouts still enter recovery. dev and dev:desktop open DevTools by default; set OPEN_DEVTOOLS=false to close them. Other entry points keep DevTools closed.

Browser-only development also needs public auth values in apps/frontend/.env.local, based on apps/frontend/.env.example, because there is no Electron auth bridge. It does not provide desktop device/plugin capabilities. OPENTEST_ENV_FILE, OPENTEST_LOCAL_SETTINGS_PATH, and OPENTEST_BACKEND_CONFIG select alternate local files; use absolute paths across terminals.

Symptom	Check or action
PowerShell blocks scripts	If permitted by your organization, manually run Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass for the current process only. Machine policy may override it.
A host tool is not found	Install/configure tools as described in section 3 and run pnpm deps:check; check PATH, JAVA_HOME and MAVEN_HOME.
A plugin build tool is not found	Follow the plugin project's own README to check Node/Corepack, JAVA_HOME, and Maven on PATH or through MAVEN_HOME.
Native materials missing	Check native/windows-amd64, its prd overlay, their matching default License.dat files, the desktop vendor directory, and explicit path overrides.
npm Git dependency fails	Check the repository URL, GitHub access, network connection, and Git authentication.
node-gyp/C++ compilation fails	Check MSVC/Windows SDK installation, requested reboot, and configured Python 3.11 or newer.
Java dependency download fails	Check Maven settings, the selected local repository and remote access. Development, full builds and dependency preparation follow the same defaults unless explicitly overridden.
Blank chart	Check the CRYChart artifact/build integrity, container size, input data and browser console. Run pnpm test:chart:browser to exercise host rendering.
Login or FFT authorization fails	Check both Casdoor configurations, registered callback, business service/entitlements, or offline authorization validity.
No microphone or Start unavailable	Check Windows access, device discovery, online input status, project binding, FFT input selection, and feature authorization.
Plugin not visible	Check package compatibility, successful import, complete desktop/backend restart, and backend logs.
Plugin dev-kit checksum mismatch	Check matching frontend materials and lockfiles; compare original bytes before repairing local changes. Java dependencies come from Maven install. Do not change checksums or export an unrelated kit.
Port conflict or backend timeout	Check 19010, 15021, 19021, native materials, and backend logs. Close the conflicting instance or set FRONTEND_PORT, BACKEND_PORT, GRPC_PORT in the root environment file; align callbacks when changing the HTTP port.
No readable result after Stop	Wait for saving, check errors/backend logs. A failed/cancelled run or an in-memory chart is not proof of persistence.

Repository map and further reading

Directory	Responsibility
apps/frontend	Vue UI, projects, workspaces, charts, and frontend plugin host
apps/backend	Java services, authorization, devices, algorithms, persistence
apps/desktop	Electron, managed backend lifecycle, native modules
apps/native	Native C++ source and build projects; backend runtime materials are maintained under apps/backend
sdks/client/typescript	Client API, protocol types, HTTP/gRPC, desktop shared-memory access
sdks/plugin	Public plugin SDK materials
tools	Build, startup, delivery, dependency preparation
tests/acceptance	Real desktop acceptance helpers

Measurement mode shows Setup, Measure, and Report; Sequence mode shows Setup and Sequence. Clicking the measurement mode icon opens Setup; clicking Measure defaults to FFT. Report opens the current active measurement workspace only; clicking Report from Setup prompts “请完成测量” (complete a measurement first). A missing or failed plugin is shown as unavailable, without switching to another measurement or report. The host preserves navigation, permissions, sequence locks, running-task protection, and synchronous measurement coordination. Sequence retains its step library, editor, parameters, testing/debugging, logs, variables, charts, and history. The Analysis mode icon displays “敬请期待” (coming soon).

FFT source and build tools are maintained in OpenTest-Plugins. Check that repository for available plugins and compatible host versions. Monitor is built into the host. Host builds do not automatically build or install external plugins.

Related resources:

• Dependency preparation (Chinese)
• Plugin repository and build instructions
• CRYChart materials
• Java runtime materials

Useful checks include pnpm check:unit, pnpm test:coverage, and pnpm test:integration; they do not replace device acceptance. Delivery selects platform, environment, artifact kind and signing independently: pnpm package --platform windows|mac|linux --mode test|production --kind installer|upgrade|both [--sign]. Signing is opt-in for both environments. Plugin build tools produce the signed final archives; the host verifies and bundles them without signing them again. Use pnpm package:windows:both:prod:signed for both signed release artifacts. pnpm build compiles the application; use a packaging command to create an installer.

License

OpenTest-owned code and components in this repository are licensed under the OpenTest Community License 1.0. See the English license and Chinese license. The Chinese version prevails if interpretations differ. Third-party components remain subject to their own licenses; the license text defines the scope of free use and the scenarios requiring a Commercial License.

Platform commands: pnpm package --platform windows, pnpm package --platform mac, and pnpm package --platform linux. Mac/Linux packages require matching native runtime materials; their functional acceptance remains pending.