{"owner":"dbeaver","repo":"cloudbeaver","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":3207,"categories":["anthropic-skill","root-instruction","plugin-manifest"],"hasMcp":false,"mcpConfig":null,"found":[".agents/skills/cloudbeaver-form-parts/SKILL.md",".agents/skills/cloudbeaver-frontend-tests/SKILL.md","AGENTS.md","webapp/packages/tsconfig/README.md"],"skills":{".agents/skills/cloudbeaver-form-parts/SKILL.md":"---\nname: cloudbeaver-form-parts\ndescription: Guides CloudBeaver FormPart state and lifecycle handling. Use when creating, changing, or reviewing form parts, including tab parts, their loaders, isOutdated, or isLoaded checks.\n---\n\n# Form parts\n\nA `FormPart` adds functionality to a form, usually a tab. It loads, processes, and stores its own state and participates in the form lifecycle.\n\nKeep `loader()`, `isOutdated()`, and `isLoaded()` in sync:\n\n- Include every resource used by `loader()` in both checks, including dependencies loaded through helpers.\n- In `isOutdated()`, combine `super.isOutdated()` and resource checks with `||`. Any outdated dependency makes the part outdated.\n- In `isLoaded()`, combine `super.isLoaded()` and resource checks with `&&`. The part is loaded only when its loader has finished and all required dependencies are loaded.\n- Use the same resource keys, includes, and conditions as `loader()`. If the loader skips a resource, for example in create mode or without an ID, skip its checks too.\n\nExample for an unconditional resource dependency:\n\n```ts\noverride isOutdated(): boolean {\n return super.isOutdated() || this.resource.isOutdated(this.key);\n}\n\noverride isLoaded(): boolean {\n return super.isLoaded() && this.resource.isLoaded(this.key);\n}\n```\n\nAfter a successful load, `isLoaded()` should be `true` and `isOutdated()` should be `false` until a dependency changes. Auto-loading retries while either condition is unmet. Checking a resource or key that `loader()` never refreshes can cause an infinite reload loop.\n\n## Keep the ESLint contract synchronized\n\nWhen changing the base `FormPart` API, update `webapp/packages/eslint-plugin/formPartContract.js` and its tests to match, then run `yarn workspace @cloudbeaver/eslint-plugin test` from `webapp/`.\n",".agents/skills/cloudbeaver-frontend-tests/SKILL.md":"---\nname: cloudbeaver-frontend-tests\ndescription: Add tests, write tests, or test a file in the CloudBeaver frontend. Use for any webapp core or plugin test request, especially when the package is missing Vitest scripts, dependencies, TypeScript references, DOM or DI setup, mocks, or previously disabled tests.\n---\n\n# CloudBeaver Frontend Tests\n\nSet up the smallest environment required by the test, implement the test, and leave the package passing its focused checks.\n\n## Workflow\n\n1. Read `AGENTS.md`, the target package's `package.json` and `tsconfig.json`, the root `webapp/vitest.config.ts`, and the shared test configuration it exports. Identify the package name and its existing build, test, lint, and dependency-validation scripts.\n\n2. Find one nearby package with active tests of the same kind. Prefer the same package family and dependencies over a superficially similar test. Treat current configuration and active code as authoritative; commented or skipped tests may preserve obsolete APIs.\n\n3. Classify the narrowest required environment:\n\n - **Pure**: Vitest only; instantiate functions or services directly.\n - **DOM**: shared React test environment and Testing Library; use `renderInApp` only when a service provider is required.\n - **Application**: CloudBeaver DI lifecycle, module registration, GraphQL/MSW mocks, or application services through `@cloudbeaver/tests-runner`.\n\n4. Wire the package by comparing it with the chosen peer:\n\n - Add `\"test\": \"dbeaver-test\"` when absent.\n - Add only test tools and libraries actually required by scripts or test imports. The normal baseline is `@dbeaver/cli`, `@dbeaver/react-tests`, `typescript`, and `vitest`; application helpers require `@cloudbeaver/tests-runner`.\n - Add workspace dependencies with Yarn from `webapp/`, preserving the dependency section and range convention used by the peer.\n - Run a non-immutable Yarn install so the configured TypeScript project linker synchronizes project references. Inspect the resulting `tsconfig.json`; edit references manually only when the linker cannot produce the required reference.\n - Ensure `src/**/*.test.ts` and `src/**/*.test.tsx` are covered by the package's existing `include` rules and compile from `src` to `lib`. Do not add a package-local Vitest config when the root config already supplies the environment.\n\n5. Implement colocated `*.test.ts` or `*.test.tsx` tests. Use `.js` suffixes for relative imports. Keep fixtures local unless they are reusable package-level mocks; put reusable mocks under `__custom_mocks__` and declare every imported package in the correct dependency section.\n\n **Mocking with `isolate: false`:** Prefer injected doubles or typed `vi.spyOn` on module namespaces, installed in `beforeEach` and restored in `afterEach`. Hoisted `vi.mock` may miss cached consumers, and `restoreAllMocks` does not unregister module factories. Avoid blanket `vi.resetModules()`: re-importing DI modules can fail with “module already added”.\n\n6. For application tests, read the current implementations of `@cloudbeaver/tests-runner` and `core-di` before writing setup. Register current modules through `module.ts`, then create the application with the current `createApp()` API. Replace legacy manifest imports and `createApp(...manifests)` calls rather than recreating the removed manifest layer. Import every required module registration before application startup, and install focused GraphQL/MSW and known-console-message expectations for observable side effects.\n\n The shared Vitest configuration currently uses `isolate: false` in order to increase tests run speed. Test files in the same worker share the module cache and global environment, so module registration, mocks, globals, timers, environment variables, console handlers, DOM state, and open resources can affect later files. Make setup idempotent, restore mutable state in `afterEach` or `afterAll`, reset mocks and handlers to their declared baseline, unload applications, and close servers, sockets, and timers. Check that every test declares and initializes its own required dependencies and mocks instead of relying on another file having run first.\n\n7. Build before testing. The shared Vitest configuration discovers compiled `lib/**/*.test.js`, so a source test that has not compiled is not runnable.\n\n ```sh\n yarn workspace build\n yarn workspace test\n yarn workspace lint\n yarn workspace validate-dependencies\n ```\n\n8. Diagnose failures at the owning layer:\n\n - A missing test file usually means compilation did not emit it or the command ran from the wrong workspace.\n - A PnP resolution error means the importing package lacks a declared dependency.\n - A TypeScript project error means a workspace dependency/reference is missing or stale.\n - A missing service means its current module was not registered or an application dependency was omitted.\n - Unexpected console output must be asserted or fixed, not globally suppressed.\n\n9. Confirm the test would fail for the behavior it protects, then restore the implementation and rerun the focused checks. Run root `yarn test` and `yarn validate-dependencies` only for shared test-infrastructure or cross-package changes. Leave generated `lib`, coverage, install, and test-result artifacts uncommitted.\n\n Because isolation is disabled, also run the complete affected package suite rather than only the new file. When shared modules, registries, mocks, or test helpers changed, run the broader workspace suite to expose order-dependent state leakage. A test must pass both alone and with its neighboring suite.\n\n For mock changes, also run the affected package with `--maxWorkers=1`; separate workers can hide cached-module failures.\n\n## Boundaries\n\n- There is no plugin-level \"tests unsupported\" switch. Test support is the combination of scripts, dependencies, compilation, active tests, and a passing build.\n- Prefer pure tests over booting the application. Use the DI environment only when direct construction would bypass behavior under test.\n- Preserve package boundaries: import another workspace through public exports or documented mock exports, never through its `src` directory.\n- Keep production dependencies out of `devDependencies`; test-only imports belong in `devDependencies` unless the package also imports them from production code.\n- A package build failure blocks meaningful test execution because Vitest runs emitted JavaScript. Report unrelated pre-existing build failures explicitly rather than claiming the environment works.\n- Do not enable per-file isolation locally to hide leaked state. Keep the package compatible with the shared root configuration and fix ownership and cleanup at the source.\n","AGENTS.md":"# CloudBeaver\n\n## What is CloudBeaver?\n\nCloudBeaver is an open-source, web-based database management application. Its modular frontend provides the database navigator, SQL editor, data editor, administration, and related features, and communicates with the CloudBeaver server through GraphQL.\n\n## Frontend\n\n### Scope\n\n- These instructions apply to the frontend under `webapp/` in CloudBeaver Community Edition and to any other CloudBeaver edition or product that shares this frontend architecture.\n- Do not modify `server/`, `deploy/`, or backend configuration unless the task explicitly requires it. Backend GraphQL schemas are an input to frontend code generation, not part of the default edit scope.\n- Treat `package.json`, `.yarnrc.yml`, and the frontend CI workflows as the source of truth for tool and runtime versions; do not duplicate their version numbers in documentation.\n\n### Project map\n\n- `webapp/package.json`: Yarn Plug'n'Play workspace root and repository-wide frontend scripts.\n- `webapp/packages/core-*`: shared application foundations, services, UI primitives, state, and infrastructure.\n- `webapp/packages/plugin-*`: feature modules. A package normally registers services and bootstraps in `src/module.ts` and exposes its public API from `src/index.ts`.\n- `webapp/packages/product-*`: CE product composition and Vite entry points. `product-default` is the runnable/bundled frontend; `product-default-impl` selects the CE plugin set.\n- `webapp/packages/core-sdk`: GraphQL operations and generated client types.\n- `webapp/common-typescript/@dbeaver/*` and `webapp/common-react/@dbeaver/*`: shared DBeaver utilities and React components used by the workspace.\n- Tests are colocated with source as `*.test.ts` or `*.test.tsx`; styles are usually colocated CSS modules.\n\n### Stack\n\nTypeScript ES modules, React, MobX, the project DI/module registry, GraphQL Code Generator, Vite, Yarn workspaces with PnP, Vitest and Testing Library, ESLint, Prettier, CSS Modules, and Tailwind-based theming.\n\n### Setup and common commands\n\nUse the Node version configured by frontend CI and the Yarn version pinned in `webapp/package.json`. Run frontend commands from `webapp/` unless noted.\n\n```sh\ncorepack enable\ncd webapp\nyarn install --immutable\n```\n\n```sh\n# Start the frontend dev server; a compatible CloudBeaver API must run separately.\n(cd packages/product-default && yarn dev)\n\n# From webapp/: repository-wide checks.\nyarn lint\nyarn test\nyarn validate-dependencies\n\n# Production frontend build.\n(cd packages/product-default && yarn bundle)\n```\n\nFor a focused check, use a package's existing script, for example `yarn workspace @cloudbeaver/core-utils test` or `yarn workspace @cloudbeaver/plugin-sql-editor lint`. Do not invent a package script that is absent from its `package.json`.\n\n### Working conventions\n\n- Put changes in the smallest package that owns the behavior. Prefer existing `core-*` abstractions and UI primitives before adding cross-package helpers.\n- Keep dependencies directed from plugins to core: `core-*` packages must never import or depend on `plugin-*` packages. Plugins may use public APIs from core packages and from other plugins, subject to the administration boundary and the no-cycles rule below.\n- Put administration-only behavior in a separate package whose name ends with `-administration`. Public/non-administration plugins must not import or depend on administration packages.\n- Keep the workspace package dependency graph acyclic; do not introduce direct or indirect circular dependencies.\n- Import workspace packages through their public `@cloudbeaver/*` or `@dbeaver/*` exports; never reach into another package's `src/` directory.\n- When adding a workspace dependency, update the package's `package.json` through Yarn. The configured `ts-project-linker` synchronizes `tsconfig.json` project references during a non-immutable install; edit references manually only if automatic linking cannot complete. Run `yarn validate-dependencies` afterward.\n- Register services and bootstraps through the package's `src/module.ts`. Change product composition only when enabling or disabling a package for the CE product.\n- Put user-visible text in the package localization files and follow the neighboring `LocaleService` pattern; do not hardcode UI copy in components.\n- Add or change GraphQL operations as `.gql` files in `core-sdk`. Regenerate through `yarn workspace @cloudbeaver/core-sdk gql:gen`; never edit the ignored generated `src/sdk.ts` manually.\n- Preserve valid license headers on existing source files. When modifying an existing source file, update the ending copyright year to the current four-digit calendar year while keeping its original starting year. For new source files, use the template below and replace `` with the current year; never leave the placeholder in committed code. Use the repository ESLint and Prettier configuration rather than manual formatting rules.\n- Do not edit or commit generated/install artifacts such as `node_modules/`, `.pnp.*`, `lib/`, `dist/`, `coverage/`, or `allure-results/`.\n- Add focused tests for behavior changes. Before handoff, run lint and tests for affected packages; run the repository-wide checks and product bundle for cross-cutting or product-composition changes.\n\n### License header for new source files\n\n```text\n/*\n * CloudBeaver - Cloud Database Manager\n * Copyright (C) 2020- DBeaver Corp and others\n *\n * Licensed under the Apache License, Version 2.0.\n * you may not use this file except in compliance with the License.\n */\n```\n\n## Backend\n\n- Before backend work, read and follow `../dbeaver/AGENTS.md` for inherited Java and Tycho conventions.\n- Cloudbeaver does not use SWT or Eclipse RCP, and its backend is headless.\n- Configuration file is generated using `apps/config-generator`. For making changes there, update `config/template/cloudbeaver-base.conf` or use patches (for specific product parameters).\n- The backend must support at least the following databases: PostgreSQL, MySQL, Oracle, and SQL Server. Support for additional databases is optional.\n\n### GraphQL API\n\n- Use consistent names. IDs must use type `ID`; ID arguments and inputs must end with `Id`, for example `projectId`.\n- Top-level methods follow `{pluginId}{methodName}`, for example `authLogin`, `rmListProjects`, and `navNodeChildren`. Mark new public API with `@since`.\n- Preserve released APIs: deprecate instead of renaming or removing, include the deprecation version, and remove only after more than one year. EA-only APIs may change before public release.\n- New arguments and input fields added to a released API must be optional.\n\n### License header\n- Please use header from ../dbeaver/docs/license_header.txt for backend source files.","webapp/packages/tsconfig/README.md":"# tsconfig\n"},"files":{".agents/skills/cloudbeaver-form-parts/SKILL.md":"---\nname: cloudbeaver-form-parts\ndescription: Guides CloudBeaver FormPart state and lifecycle handling. Use when creating, changing, or reviewing form parts, including tab parts, their loaders, isOutdated, or isLoaded checks.\n---\n\n# Form parts\n\nA `FormPart` adds functionality to a form, usually a tab. It loads, processes, and stores its own state and participates in the form lifecycle.\n\nKeep `loader()`, `isOutdated()`, and `isLoaded()` in sync:\n\n- Include every resource used by `loader()` in both checks, including dependencies loaded through helpers.\n- In `isOutdated()`, combine `super.isOutdated()` and resource checks with `||`. Any outdated dependency makes the part outdated.\n- In `isLoaded()`, combine `super.isLoaded()` and resource checks with `&&`. The part is loaded only when its loader has finished and all required dependencies are loaded.\n- Use the same resource keys, includes, and conditions as `loader()`. If the loader skips a resource, for example in create mode or without an ID, skip its checks too.\n\nExample for an unconditional resource dependency:\n\n```ts\noverride isOutdated(): boolean {\n return super.isOutdated() || this.resource.isOutdated(this.key);\n}\n\noverride isLoaded(): boolean {\n return super.isLoaded() && this.resource.isLoaded(this.key);\n}\n```\n\nAfter a successful load, `isLoaded()` should be `true` and `isOutdated()` should be `false` until a dependency changes. Auto-loading retries while either condition is unmet. Checking a resource or key that `loader()` never refreshes can cause an infinite reload loop.\n\n## Keep the ESLint contract synchronized\n\nWhen changing the base `FormPart` API, update `webapp/packages/eslint-plugin/formPartContract.js` and its tests to match, then run `yarn workspace @cloudbeaver/eslint-plugin test` from `webapp/`.\n",".agents/skills/cloudbeaver-frontend-tests/SKILL.md":"---\nname: cloudbeaver-frontend-tests\ndescription: Add tests, write tests, or test a file in the CloudBeaver frontend. Use for any webapp core or plugin test request, especially when the package is missing Vitest scripts, dependencies, TypeScript references, DOM or DI setup, mocks, or previously disabled tests.\n---\n\n# CloudBeaver Frontend Tests\n\nSet up the smallest environment required by the test, implement the test, and leave the package passing its focused checks.\n\n## Workflow\n\n1. Read `AGENTS.md`, the target package's `package.json` and `tsconfig.json`, the root `webapp/vitest.config.ts`, and the shared test configuration it exports. Identify the package name and its existing build, test, lint, and dependency-validation scripts.\n\n2. Find one nearby package with active tests of the same kind. Prefer the same package family and dependencies over a superficially similar test. Treat current configuration and active code as authoritative; commented or skipped tests may preserve obsolete APIs.\n\n3. Classify the narrowest required environment:\n\n - **Pure**: Vitest only; instantiate functions or services directly.\n - **DOM**: shared React test environment and Testing Library; use `renderInApp` only when a service provider is required.\n - **Application**: CloudBeaver DI lifecycle, module registration, GraphQL/MSW mocks, or application services through `@cloudbeaver/tests-runner`.\n\n4. Wire the package by comparing it with the chosen peer:\n\n - Add `\"test\": \"dbeaver-test\"` when absent.\n - Add only test tools and libraries actually required by scripts or test imports. The normal baseline is `@dbeaver/cli`, `@dbeaver/react-tests`, `typescript`, and `vitest`; application helpers require `@cloudbeaver/tests-runner`.\n - Add workspace dependencies with Yarn from `webapp/`, preserving the dependency section and range convention used by the peer.\n - Run a non-immutable Yarn install so the configured TypeScript project linker synchronizes project references. Inspect the resulting `tsconfig.json`; edit references manually only when the linker cannot produce the required reference.\n - Ensure `src/**/*.test.ts` and `src/**/*.test.tsx` are covered by the package's existing `include` rules and compile from `src` to `lib`. Do not add a package-local Vitest config when the root config already supplies the environment.\n\n5. Implement colocated `*.test.ts` or `*.test.tsx` tests. Use `.js` suffixes for relative imports. Keep fixtures local unless they are reusable package-level mocks; put reusable mocks under `__custom_mocks__` and declare every imported package in the correct dependency section.\n\n **Mocking with `isolate: false`:** Prefer injected doubles or typed `vi.spyOn` on module namespaces, installed in `beforeEach` and restored in `afterEach`. Hoisted `vi.mock` may miss cached consumers, and `restoreAllMocks` does not unregister module factories. Avoid blanket `vi.resetModules()`: re-importing DI modules can fail with “module already added”.\n\n6. For application tests, read the current implementations of `@cloudbeaver/tests-runner` and `core-di` before writing setup. Register current modules through `module.ts`, then create the application with the current `createApp()` API. Replace legacy manifest imports and `createApp(...manifests)` calls rather than recreating the removed manifest layer. Import every required module registration before application startup, and install focused GraphQL/MSW and known-console-message expectations for observable side effects.\n\n The shared Vitest configuration currently uses `isolate: false` in order to increase tests run speed. Test files in the same worker share the module cache and global environment, so module registration, mocks, globals, timers, environment variables, console handlers, DOM state, and open resources can affect later files. Make setup idempotent, restore mutable state in `afterEach` or `afterAll`, reset mocks and handlers to their declared baseline, unload applications, and close servers, sockets, and timers. Check that every test declares and initializes its own required dependencies and mocks instead of relying on another file having run first.\n\n7. Build before testing. The shared Vitest configuration discovers compiled `lib/**/*.test.js`, so a source test that has not compiled is not runnable.\n\n ```sh\n yarn workspace build\n yarn workspace test\n yarn workspace lint\n yarn workspace validate-dependencies\n ```\n\n8. Diagnose failures at the owning layer:\n\n - A missing test file usually means compilation did not emit it or the command ran from the wrong workspace.\n - A PnP resolution error means the importing package lacks a declared dependency.\n - A TypeScript project error means a workspace dependency/reference is missing or stale.\n - A missing service means its current module was not registered or an application dependency was omitted.\n - Unexpected console output must be asserted or fixed, not globally suppressed.\n\n9. Confirm the test would fail for the behavior it protects, then restore the implementation and rerun the focused checks. Run root `yarn test` and `yarn validate-dependencies` only for shared test-infrastructure or cross-package changes. Leave generated `lib`, coverage, install, and test-result artifacts uncommitted.\n\n Because isolation is disabled, also run the complete affected package suite rather than only the new file. When shared modules, registries, mocks, or test helpers changed, run the broader workspace suite to expose order-dependent state leakage. A test must pass both alone and with its neighboring suite.\n\n For mock changes, also run the affected package with `--maxWorkers=1`; separate workers can hide cached-module failures.\n\n## Boundaries\n\n- There is no plugin-level \"tests unsupported\" switch. Test support is the combination of scripts, dependencies, compilation, active tests, and a passing build.\n- Prefer pure tests over booting the application. Use the DI environment only when direct construction would bypass behavior under test.\n- Preserve package boundaries: import another workspace through public exports or documented mock exports, never through its `src` directory.\n- Keep production dependencies out of `devDependencies`; test-only imports belong in `devDependencies` unless the package also imports them from production code.\n- A package build failure blocks meaningful test execution because Vitest runs emitted JavaScript. Report unrelated pre-existing build failures explicitly rather than claiming the environment works.\n- Do not enable per-file isolation locally to hide leaked state. Keep the package compatible with the shared root configuration and fix ownership and cleanup at the source.\n","AGENTS.md":"# CloudBeaver\n\n## What is CloudBeaver?\n\nCloudBeaver is an open-source, web-based database management application. Its modular frontend provides the database navigator, SQL editor, data editor, administration, and related features, and communicates with the CloudBeaver server through GraphQL.\n\n## Frontend\n\n### Scope\n\n- These instructions apply to the frontend under `webapp/` in CloudBeaver Community Edition and to any other CloudBeaver edition or product that shares this frontend architecture.\n- Do not modify `server/`, `deploy/`, or backend configuration unless the task explicitly requires it. Backend GraphQL schemas are an input to frontend code generation, not part of the default edit scope.\n- Treat `package.json`, `.yarnrc.yml`, and the frontend CI workflows as the source of truth for tool and runtime versions; do not duplicate their version numbers in documentation.\n\n### Project map\n\n- `webapp/package.json`: Yarn Plug'n'Play workspace root and repository-wide frontend scripts.\n- `webapp/packages/core-*`: shared application foundations, services, UI primitives, state, and infrastructure.\n- `webapp/packages/plugin-*`: feature modules. A package normally registers services and bootstraps in `src/module.ts` and exposes its public API from `src/index.ts`.\n- `webapp/packages/product-*`: CE product composition and Vite entry points. `product-default` is the runnable/bundled frontend; `product-default-impl` selects the CE plugin set.\n- `webapp/packages/core-sdk`: GraphQL operations and generated client types.\n- `webapp/common-typescript/@dbeaver/*` and `webapp/common-react/@dbeaver/*`: shared DBeaver utilities and React components used by the workspace.\n- Tests are colocated with source as `*.test.ts` or `*.test.tsx`; styles are usually colocated CSS modules.\n\n### Stack\n\nTypeScript ES modules, React, MobX, the project DI/module registry, GraphQL Code Generator, Vite, Yarn workspaces with PnP, Vitest and Testing Library, ESLint, Prettier, CSS Modules, and Tailwind-based theming.\n\n### Setup and common commands\n\nUse the Node version configured by frontend CI and the Yarn version pinned in `webapp/package.json`. Run frontend commands from `webapp/` unless noted.\n\n```sh\ncorepack enable\ncd webapp\nyarn install --immutable\n```\n\n```sh\n# Start the frontend dev server; a compatible CloudBeaver API must run separately.\n(cd packages/product-default && yarn dev)\n\n# From webapp/: repository-wide checks.\nyarn lint\nyarn test\nyarn validate-dependencies\n\n# Production frontend build.\n(cd packages/product-default && yarn bundle)\n```\n\nFor a focused check, use a package's existing script, for example `yarn workspace @cloudbeaver/core-utils test` or `yarn workspace @cloudbeaver/plugin-sql-editor lint`. Do not invent a package script that is absent from its `package.json`.\n\n### Working conventions\n\n- Put changes in the smallest package that owns the behavior. Prefer existing `core-*` abstractions and UI primitives before adding cross-package helpers.\n- Keep dependencies directed from plugins to core: `core-*` packages must never import or depend on `plugin-*` packages. Plugins may use public APIs from core packages and from other plugins, subject to the administration boundary and the no-cycles rule below.\n- Put administration-only behavior in a separate package whose name ends with `-administration`. Public/non-administration plugins must not import or depend on administration packages.\n- Keep the workspace package dependency graph acyclic; do not introduce direct or indirect circular dependencies.\n- Import workspace packages through their public `@cloudbeaver/*` or `@dbeaver/*` exports; never reach into another package's `src/` directory.\n- When adding a workspace dependency, update the package's `package.json` through Yarn. The configured `ts-project-linker` synchronizes `tsconfig.json` project references during a non-immutable install; edit references manually only if automatic linking cannot complete. Run `yarn validate-dependencies` afterward.\n- Register services and bootstraps through the package's `src/module.ts`. Change product composition only when enabling or disabling a package for the CE product.\n- Put user-visible text in the package localization files and follow the neighboring `LocaleService` pattern; do not hardcode UI copy in components.\n- Add or change GraphQL operations as `.gql` files in `core-sdk`. Regenerate through `yarn workspace @cloudbeaver/core-sdk gql:gen`; never edit the ignored generated `src/sdk.ts` manually.\n- Preserve valid license headers on existing source files. When modifying an existing source file, update the ending copyright year to the current four-digit calendar year while keeping its original starting year. For new source files, use the template below and replace `` with the current year; never leave the placeholder in committed code. Use the repository ESLint and Prettier configuration rather than manual formatting rules.\n- Do not edit or commit generated/install artifacts such as `node_modules/`, `.pnp.*`, `lib/`, `dist/`, `coverage/`, or `allure-results/`.\n- Add focused tests for behavior changes. Before handoff, run lint and tests for affected packages; run the repository-wide checks and product bundle for cross-cutting or product-composition changes.\n\n### License header for new source files\n\n```text\n/*\n * CloudBeaver - Cloud Database Manager\n * Copyright (C) 2020- DBeaver Corp and others\n *\n * Licensed under the Apache License, Version 2.0.\n * you may not use this file except in compliance with the License.\n */\n```\n\n## Backend\n\n- Before backend work, read and follow `../dbeaver/AGENTS.md` for inherited Java and Tycho conventions.\n- Cloudbeaver does not use SWT or Eclipse RCP, and its backend is headless.\n- Configuration file is generated using `apps/config-generator`. For making changes there, update `config/template/cloudbeaver-base.conf` or use patches (for specific product parameters).\n- The backend must support at least the following databases: PostgreSQL, MySQL, Oracle, and SQL Server. Support for additional databases is optional.\n\n### GraphQL API\n\n- Use consistent names. IDs must use type `ID`; ID arguments and inputs must end with `Id`, for example `projectId`.\n- Top-level methods follow `{pluginId}{methodName}`, for example `authLogin`, `rmListProjects`, and `navNodeChildren`. Mark new public API with `@since`.\n- Preserve released APIs: deprecate instead of renaming or removing, include the deprecation version, and remove only after more than one year. EA-only APIs may change before public release.\n- New arguments and input fields added to a released API must be optional.\n\n### License header\n- Please use header from ../dbeaver/docs/license_header.txt for backend source files.","webapp/packages/tsconfig/README.md":"# tsconfig\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/dbeaver/cloudbeaver/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# CloudBeaver\n\n## What is CloudBeaver?\n\nCloudBeaver is an open-source, web-based database management application. Its modular frontend provides the database navigator, SQL editor, data editor, administration, and related features, and communicates with the CloudBeaver server through GraphQL.\n\n## Frontend\n\n### Scope\n\n- These instructions apply to the frontend under `webapp/` in CloudBeaver Community Edition and to any other CloudBeaver edition or product that shares this frontend architecture.\n- Do not modify `server/`, `deploy/`, or backend configuration unless the task explicitly requires it. Backend GraphQL schemas are an input to frontend code generation, not part of the default edit scope.\n- Treat `package.json`, `.yarnrc.yml`, and the frontend CI workflows as the source of truth for tool and runtime versions; do not duplicate their version numbers in documentation.\n\n### Project map\n\n- `webapp/package.json`: Yarn Plug'n'Play workspace root and repository-wide frontend scripts.\n- `webapp/packages/core-*`: shared application foundations, services, UI primitives, state, and infrastructure.\n- `webapp/packages/plugin-*`: feature modules. A package normally registers services and bootstraps in `src/module.ts` and exposes its public API from `src/index.ts`.\n- `webapp/packages/product-*`: CE product composition and Vite entry points. `product-default` is the runnable/bundled frontend; `product-default-impl` selects the CE plugin set.\n- `webapp/packages/core-sdk`: GraphQL operations and generated client types.\n- `webapp/common-typescript/@dbeaver/*` and `webapp/common-react/@dbeaver/*`: shared DBeaver utilities and React components used by the workspace.\n- Tests are colocated with source as `*.test.ts` or `*.test.tsx`; styles are usually colocated CSS modules.\n\n### Stack\n\nTypeScript ES modules, React, MobX, the project DI/module registry, GraphQL Code Generator, Vite, Yarn workspaces with PnP, Vitest and Testing Library, ESLint, Prettier, CSS Modules, and Tailwind-based theming.\n\n### Setup and common commands\n\nUse the Node version configured by frontend CI and the Yarn version pinned in `webapp/package.json`. Run frontend commands from `webapp/` unless noted.\n\n```sh\ncorepack enable\ncd webapp\nyarn install --immutable\n```\n\n```sh\n# Start the frontend dev server; a compatible CloudBeaver API must run separately.\n(cd packages/product-default && yarn dev)\n\n# From webapp/: repository-wide checks.\nyarn lint\nyarn test\nyarn validate-dependencies\n\n# Production frontend build.\n(cd packages/product-default && yarn bundle)\n```\n\nFor a focused check, use a package's existing script, for example `yarn workspace @cloudbeaver/core-utils test` or `yarn workspace @cloudbeaver/plugin-sql-editor lint`. Do not invent a package script that is absent from its `package.json`.\n\n### Working conventions\n\n- Put changes in the smallest package that owns the behavior. Prefer existing `core-*` abstractions and UI primitives before adding cross-package helpers.\n- Keep dependencies directed from plugins to core: `core-*` packages must never import or depend on `plugin-*` packages. Plugins may use public APIs from core packages and from other plugins, subject to the administration boundary and the no-cycles rule below.\n- Put administration-only behavior in a separate package whose name ends with `-administration`. Public/non-administration plugins must not import or depend on administration packages.\n- Keep the workspace package dependency graph acyclic; do not introduce direct or indirect circular dependencies.\n- Import workspace packages through their public `@cloudbeaver/*` or `@dbeaver/*` exports; never reach into another package's `src/` directory.\n- When adding a workspace dependency, update the package's `package.json` through Yarn. The configured `ts-project-linker` synchronizes `tsconfig.json` project references during a non-immutable install; edit references manually only if automatic linking cannot complete. Run `yarn validate-dependencies` afterward.\n- Register services and bootstraps through the package's `src/module.ts`. Change product composition only when enabling or disabling a package for the CE product.\n- Put user-visible text in the package localization files and follow the neighboring `LocaleService` pattern; do not hardcode UI copy in components.\n- Add or change GraphQL operations as `.gql` files in `core-sdk`. Regenerate through `yarn workspace @cloudbeaver/core-sdk gql:gen`; never edit the ignored generated `src/sdk.ts` manually.\n- Preserve valid license headers on existing source files. When modifying an existing source file, update the ending copyright year to the current four-digit calendar year while keeping its original starting year. For new source files, use the template below and replace `` with the current year; never leave the placeholder in committed code. Use the repository ESLint and Prettier configuration rather than manual formatting rules.\n- Do not edit or commit generated/install artifacts such as `node_modules/`, `.pnp.*`, `lib/`, `dist/`, `coverage/`, or `allure-results/`.\n- Add focused tests for behavior changes. Before handoff, run lint and tests for affected packages; run the repository-wide checks and product bundle for cross-cutting or product-composition changes.\n\n### License header for new source files\n\n```text\n/*\n * CloudBeaver - Cloud Database Manager\n * Copyright (C) 2020- DBeaver Corp and others\n *\n * Licensed under the Apache License, Version 2.0.\n * you may not use this file except in compliance with the License.\n */\n```\n\n## Backend\n\n- Before backend work, read and follow `../dbeaver/AGENTS.md` for inherited Java and Tycho conventions.\n- Cloudbeaver does not use SWT or Eclipse RCP, and its backend is headless.\n- Configuration file is generated using `apps/config-generator`. For making changes there, update `config/template/cloudbeaver-base.conf` or use patches (for specific product parameters).\n- The backend must support at least the following databases: PostgreSQL, MySQL, Oracle, and SQL Server. Support for additional databases is optional.\n\n### GraphQL API\n\n- Use consistent names. IDs must use type `ID`; ID arguments and inputs must end with `Id`, for example `projectId`.\n- Top-level methods follow `{pluginId}{methodName}`, for example `authLogin`, `rmListProjects`, and `navNodeChildren`. Mark new public API with `@since`.\n- Preserve released APIs: deprecate instead of renaming or removing, include the deprecation version, and remove only after more than one year. EA-only APIs may change before public release.\n- New arguments and input fields added to a released API must be optional.\n\n### License header\n- Please use header from ../dbeaver/docs/license_header.txt for backend source files.","isInternal":false,"tokens":1439,"sizeBytes":6758},{"name":"SKILL.md","path":".agents/skills/cloudbeaver-form-parts/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dbeaver/cloudbeaver/HEAD/.agents/skills/cloudbeaver-form-parts/SKILL.md","title":"cloudbeaver-form-parts","category":"anthropic-skill","format":"markdown","content":"---\nname: cloudbeaver-form-parts\ndescription: Guides CloudBeaver FormPart state and lifecycle handling. Use when creating, changing, or reviewing form parts, including tab parts, their loaders, isOutdated, or isLoaded checks.\n---\n\n# Form parts\n\nA `FormPart` adds functionality to a form, usually a tab. It loads, processes, and stores its own state and participates in the form lifecycle.\n\nKeep `loader()`, `isOutdated()`, and `isLoaded()` in sync:\n\n- Include every resource used by `loader()` in both checks, including dependencies loaded through helpers.\n- In `isOutdated()`, combine `super.isOutdated()` and resource checks with `||`. Any outdated dependency makes the part outdated.\n- In `isLoaded()`, combine `super.isLoaded()` and resource checks with `&&`. The part is loaded only when its loader has finished and all required dependencies are loaded.\n- Use the same resource keys, includes, and conditions as `loader()`. If the loader skips a resource, for example in create mode or without an ID, skip its checks too.\n\nExample for an unconditional resource dependency:\n\n```ts\noverride isOutdated(): boolean {\n return super.isOutdated() || this.resource.isOutdated(this.key);\n}\n\noverride isLoaded(): boolean {\n return super.isLoaded() && this.resource.isLoaded(this.key);\n}\n```\n\nAfter a successful load, `isLoaded()` should be `true` and `isOutdated()` should be `false` until a dependency changes. Auto-loading retries while either condition is unmet. Checking a resource or key that `loader()` never refreshes can cause an infinite reload loop.\n\n## Keep the ESLint contract synchronized\n\nWhen changing the base `FormPart` API, update `webapp/packages/eslint-plugin/formPartContract.js` and its tests to match, then run `yarn workspace @cloudbeaver/eslint-plugin test` from `webapp/`.\n","frontmatter":{"name":"cloudbeaver-form-parts","description":"Guides CloudBeaver FormPart state and lifecycle handling. Use when creating, changing, or reviewing form parts, including tab parts, their loaders, isOutdated, or isLoaded checks."},"isInternal":false,"tokens":403,"sizeBytes":1796},{"name":"SKILL.md","path":".agents/skills/cloudbeaver-frontend-tests/SKILL.md","rawUrl":"https://raw.githubusercontent.com/dbeaver/cloudbeaver/HEAD/.agents/skills/cloudbeaver-frontend-tests/SKILL.md","title":"cloudbeaver-frontend-tests","category":"anthropic-skill","format":"markdown","content":"---\nname: cloudbeaver-frontend-tests\ndescription: Add tests, write tests, or test a file in the CloudBeaver frontend. Use for any webapp core or plugin test request, especially when the package is missing Vitest scripts, dependencies, TypeScript references, DOM or DI setup, mocks, or previously disabled tests.\n---\n\n# CloudBeaver Frontend Tests\n\nSet up the smallest environment required by the test, implement the test, and leave the package passing its focused checks.\n\n## Workflow\n\n1. Read `AGENTS.md`, the target package's `package.json` and `tsconfig.json`, the root `webapp/vitest.config.ts`, and the shared test configuration it exports. Identify the package name and its existing build, test, lint, and dependency-validation scripts.\n\n2. Find one nearby package with active tests of the same kind. Prefer the same package family and dependencies over a superficially similar test. Treat current configuration and active code as authoritative; commented or skipped tests may preserve obsolete APIs.\n\n3. Classify the narrowest required environment:\n\n - **Pure**: Vitest only; instantiate functions or services directly.\n - **DOM**: shared React test environment and Testing Library; use `renderInApp` only when a service provider is required.\n - **Application**: CloudBeaver DI lifecycle, module registration, GraphQL/MSW mocks, or application services through `@cloudbeaver/tests-runner`.\n\n4. Wire the package by comparing it with the chosen peer:\n\n - Add `\"test\": \"dbeaver-test\"` when absent.\n - Add only test tools and libraries actually required by scripts or test imports. The normal baseline is `@dbeaver/cli`, `@dbeaver/react-tests`, `typescript`, and `vitest`; application helpers require `@cloudbeaver/tests-runner`.\n - Add workspace dependencies with Yarn from `webapp/`, preserving the dependency section and range convention used by the peer.\n - Run a non-immutable Yarn install so the configured TypeScript project linker synchronizes project references. Inspect the resulting `tsconfig.json`; edit references manually only when the linker cannot produce the required reference.\n - Ensure `src/**/*.test.ts` and `src/**/*.test.tsx` are covered by the package's existing `include` rules and compile from `src` to `lib`. Do not add a package-local Vitest config when the root config already supplies the environment.\n\n5. Implement colocated `*.test.ts` or `*.test.tsx` tests. Use `.js` suffixes for relative imports. Keep fixtures local unless they are reusable package-level mocks; put reusable mocks under `__custom_mocks__` and declare every imported package in the correct dependency section.\n\n **Mocking with `isolate: false`:** Prefer injected doubles or typed `vi.spyOn` on module namespaces, installed in `beforeEach` and restored in `afterEach`. Hoisted `vi.mock` may miss cached consumers, and `restoreAllMocks` does not unregister module factories. Avoid blanket `vi.resetModules()`: re-importing DI modules can fail with “module already added”.\n\n6. For application tests, read the current implementations of `@cloudbeaver/tests-runner` and `core-di` before writing setup. Register current modules through `module.ts`, then create the application with the current `createApp()` API. Replace legacy manifest imports and `createApp(...manifests)` calls rather than recreating the removed manifest layer. Import every required module registration before application startup, and install focused GraphQL/MSW and known-console-message expectations for observable side effects.\n\n The shared Vitest configuration currently uses `isolate: false` in order to increase tests run speed. Test files in the same worker share the module cache and global environment, so module registration, mocks, globals, timers, environment variables, console handlers, DOM state, and open resources can affect later files. Make setup idempotent, restore mutable state in `afterEach` or `afterAll`, reset mocks and handlers to their declared baseline, unload applications, and close servers, sockets, and timers. Check that every test declares and initializes its own required dependencies and mocks instead of relying on another file having run first.\n\n7. Build before testing. The shared Vitest configuration discovers compiled `lib/**/*.test.js`, so a source test that has not compiled is not runnable.\n\n ```sh\n yarn workspace build\n yarn workspace test\n yarn workspace lint\n yarn workspace validate-dependencies\n ```\n\n8. Diagnose failures at the owning layer:\n\n - A missing test file usually means compilation did not emit it or the command ran from the wrong workspace.\n - A PnP resolution error means the importing package lacks a declared dependency.\n - A TypeScript project error means a workspace dependency/reference is missing or stale.\n - A missing service means its current module was not registered or an application dependency was omitted.\n - Unexpected console output must be asserted or fixed, not globally suppressed.\n\n9. Confirm the test would fail for the behavior it protects, then restore the implementation and rerun the focused checks. Run root `yarn test` and `yarn validate-dependencies` only for shared test-infrastructure or cross-package changes. Leave generated `lib`, coverage, install, and test-result artifacts uncommitted.\n\n Because isolation is disabled, also run the complete affected package suite rather than only the new file. When shared modules, registries, mocks, or test helpers changed, run the broader workspace suite to expose order-dependent state leakage. A test must pass both alone and with its neighboring suite.\n\n For mock changes, also run the affected package with `--maxWorkers=1`; separate workers can hide cached-module failures.\n\n## Boundaries\n\n- There is no plugin-level \"tests unsupported\" switch. Test support is the combination of scripts, dependencies, compilation, active tests, and a passing build.\n- Prefer pure tests over booting the application. Use the DI environment only when direct construction would bypass behavior under test.\n- Preserve package boundaries: import another workspace through public exports or documented mock exports, never through its `src` directory.\n- Keep production dependencies out of `devDependencies`; test-only imports belong in `devDependencies` unless the package also imports them from production code.\n- A package build failure blocks meaningful test execution because Vitest runs emitted JavaScript. Report unrelated pre-existing build failures explicitly rather than claiming the environment works.\n- Do not enable per-file isolation locally to hide leaked state. Keep the package compatible with the shared root configuration and fix ownership and cleanup at the source.\n","frontmatter":{"name":"cloudbeaver-frontend-tests","description":"Add tests, write tests, or test a file in the CloudBeaver frontend. Use for any webapp core or plugin test request, especially when the package is missing Vitest scripts, dependencies, TypeScript references, DOM or DI setup, mocks, or previously disabled tests."},"isInternal":false,"tokens":1361,"sizeBytes":6787},{"name":"README.md","path":"webapp/packages/tsconfig/README.md","rawUrl":"https://raw.githubusercontent.com/dbeaver/cloudbeaver/HEAD/webapp/packages/tsconfig/README.md","title":"tsconfig Documentation","category":"plugin-manifest","format":"markdown","content":"# tsconfig\n","isInternal":false,"tokens":4,"sizeBytes":11}],"systemPromptSnippet":"\n\n# CloudBeaver\n\n## What is CloudBeaver?\n\nCloudBeaver is an open-source, web-based database management application. Its modular frontend provides the database navigator, SQL editor, data editor, administration, and related features, and communicates with the CloudBeaver server through GraphQL.\n\n## Frontend\n\n### Scope\n\n- These instructions apply to the frontend under `webapp/` in CloudBeaver Community Edition and to any other CloudBeaver edition or product that shares this frontend architecture.\n- Do not modify `server/`, `deploy/`, or backend configuration unless the task explicitly requires it. Backend GraphQL schemas are an input to frontend code generation, not part of the default edit scope.\n- Treat `package.json`, `.yarnrc.yml`, and the frontend CI workflows as the source of truth for tool and runtime versions; do not duplicate their version numbers in documentation.\n\n### Project map\n\n- `webapp/package.json`: Yarn Plug'n'Play workspace root and repository-wide frontend scripts.\n- `webapp/packages/core-*`: shared application foundations, services, UI primitives, state, and infrastructure.\n- `webapp/packages/plugin-*`: feature modules. A package normally registers services and bootstraps in `src/module.ts` and exposes its public API from `src/index.ts`.\n- `webapp/packages/product-*`: CE product composition and Vite entry points. `product-default` is the runnable/bundled frontend; `product-default-impl` selects the CE plugin set.\n- `webapp/packages/core-sdk`: GraphQL operations and generated client types.\n- `webapp/common-typescript/@dbeaver/*` and `webapp/common-react/@dbeaver/*`: shared DBeaver utilities and React components used by the workspace.\n- Tests are colocated with source as `*.test.ts` or `*.test.tsx`; styles are usually colocated CSS modules.\n\n### Stack\n\nTypeScript ES modules, React, MobX, the project DI/module registry, GraphQL Code Generator, Vite, Yarn workspaces with PnP, Vitest and Testing Library, ESLint, Prettier, CSS Modules, and Tailwind-based theming.\n\n### Setup and common commands\n\nUse the Node version configured by frontend CI and the Yarn version pinned in `webapp/package.json`. Run frontend commands from `webapp/` unless noted.\n\n```sh\ncorepack enable\ncd webapp\nyarn install --immutable\n```\n\n```sh\n# Start the frontend dev server; a compatible CloudBeaver API must run separately.\n(cd packages/product-default && yarn dev)\n\n# From webapp/: repository-wide checks.\nyarn lint\nyarn test\nyarn validate-dependencies\n\n# Production frontend build.\n(cd packages/product-default && yarn bundle)\n```\n\nFor a focused check, use a package's existing script, for example `yarn workspace @cloudbeaver/core-utils test` or `yarn workspace @cloudbeaver/plugin-sql-editor lint`. Do not invent a package script that is absent from its `package.json`.\n\n### Working conventions\n\n- Put changes in the smallest package that owns the behavior. Prefer existing `core-*` abstractions and UI primitives before adding cross-package helpers.\n- Keep dependencies directed from plugins to core: `core-*` packages must never import or depend on `plugin-*` packages. Plugins may use public APIs from core packages and from other plugins, subject to the administration boundary and the no-cycles rule below.\n- Put administration-only behavior in a separate package whose name ends with `-administration`. Public/non-administration plugins must not import or depend on administration packages.\n- Keep the workspace package dependency graph acyclic; do not introduce direct or indirect circular dependencies.\n- Import workspace packages through their public `@cloudbeaver/*` or `@dbeaver/*` exports; never reach into another package's `src/` directory.\n- When adding a workspace dependency, update the package's `package.json` through Yarn. The configured `ts-project-linker` synchronizes `tsconfig.json` project references during a non-immutable install; edit references manually only if automatic linking cannot complete. Run `yarn validate-dependencies` afterward.\n- Register services and bootstraps through the package's `src/module.ts`. Change product composition only when enabling or disabling a package for the CE product.\n- Put user-visible text in the package localization files and follow the neighboring `LocaleService` pattern; do not hardcode UI copy in components.\n- Add or change GraphQL operations as `.gql` files in `core-sdk`. Regenerate through `yarn workspace @cloudbeaver/core-sdk gql:gen`; never edit the ignored generated `src/sdk.ts` manually.\n- Preserve valid license headers on existing source files. When modifying an existing source file, update the ending copyright year to the current four-digit calendar year while keeping its original starting year. For new source files, use the template below and replace `` with the current year; never leave the placeholder in committed code. Use the repository ESLint and Prettier configuration rather than manual formatting rules.\n- Do not edit or commit generated/install artifacts such as `node_modules/`, `.pnp.*`, `lib/`, `dist/`, `coverage/`, or `allure-results/`.\n- Add focused tests for behavior changes. Before handoff, run lint and tests for affected packages; run the repository-wide checks and product bundle for cross-cutting or product-composition changes.\n\n### License header for new source files\n\n```text\n/*\n * CloudBeaver - Cloud Database Manager\n * Copyright (C) 2020- DBeaver Corp and others\n *\n * Licensed under the Apache License, Version 2.0.\n * you may not use this file except in compliance with the License.\n */\n```\n\n## Backend\n\n- Before backend work, read and follow `../dbeaver/AGENTS.md` for inherited Java and Tycho conventions.\n- Cloudbeaver does not use SWT or Eclipse RCP, and its backend is headless.\n- Configuration file is generated using `apps/config-generator`. For making changes there, update `config/template/cloudbeaver-base.conf` or use patches (for specific product parameters).\n- The backend must support at least the following databases: PostgreSQL, MySQL, Oracle, and SQL Server. Support for additional databases is optional.\n\n### GraphQL API\n\n- Use consistent names. IDs must use type `ID`; ID arguments and inputs must end with `Id`, for example `projectId`.\n- Top-level methods follow `{pluginId}{methodName}`, for example `authLogin`, `rmListProjects`, and `navNodeChildren`. Mark new public API with `@since`.\n- Preserve released APIs: deprecate instead of renaming or removing, include the deprecation version, and remove only after more than one year. EA-only APIs may change before public release.\n- New arguments and input fields added to a released API must be optional.\n\n### License header\n- Please use header from ../dbeaver/docs/license_header.txt for backend source files.\n\n\n---\nname: cloudbeaver-form-parts\ndescription: Guides CloudBeaver FormPart state and lifecycle handling. Use when creating, changing, or reviewing form parts, including tab parts, their loaders, isOutdated, or isLoaded checks.\n---\n\n# Form parts\n\nA `FormPart` adds functionality to a form, usually a tab. It loads, processes, and stores its own state and participates in the form lifecycle.\n\nKeep `loader()`, `isOutdated()`, and `isLoaded()` in sync:\n\n- Include every resource used by `loader()` in both checks, including dependencies loaded through helpers.\n- In `isOutdated()`, combine `super.isOutdated()` and resource checks with `||`. Any outdated dependency makes the part outdated.\n- In `isLoaded()`, combine `super.isLoaded()` and resource checks with `&&`. The part is loaded only when its loader has finished and all required dependencies are loaded.\n- Use the same resource keys, includes, and conditions as `loader()`. If the loader skips a resource, for example in create mode or without an ID, skip its checks too.\n\nExample for an unconditional resource dependency:\n\n```ts\noverride isOutdated(): boolean {\n return super.isOutdated() || this.resource.isOutdated(this.key);\n}\n\noverride isLoaded(): boolean {\n return super.isLoaded() && this.resource.isLoaded(this.key);\n}\n```\n\nAfter a successful load, `isLoaded()` should be `true` and `isOutdated()` should be `false` until a dependency changes. Auto-loading retries while either condition is unmet. Checking a resource or key that `loader()` never refreshes can cause an infinite reload loop.\n\n## Keep the ESLint contract synchronized\n\nWhen changing the base `FormPart` API, update `webapp/packages/eslint-plugin/formPartContract.js` and its tests to match, then run `yarn workspace @cloudbeaver/eslint-plugin test` from `webapp/`.\n\n\n---\nname: cloudbeaver-frontend-tests\ndescription: Add tests, write tests, or test a file in the CloudBeaver frontend. Use for any webapp core or plugin test request, especially when the package is missing Vitest scripts, dependencies, TypeScript references, DOM or DI setup, mocks, or previously disabled tests.\n---\n\n# CloudBeaver Frontend Tests\n\nSet up the smallest environment required by the test, implement the test, and leave the package passing its focused checks.\n\n## Workflow\n\n1. Read `AGENTS.md`, the target package's `package.json` and `tsconfig.json`, the root `webapp/vitest.config.ts`, and the shared test configuration it exports. Identify the package name and its existing build, test, lint, and dependency-validation scripts.\n\n2. Find one nearby package with active tests of the same kind. Prefer the same package family and dependencies over a superficially similar test. Treat current configuration and active code as authoritative; commented or skipped tests may preserve obsolete APIs.\n\n3. Classify the narrowest required environment:\n\n - **Pure**: Vitest only; instantiate functions or services directly.\n - **DOM**: shared React test environment and Testing Library; use `renderInApp` only when a service provider is required.\n - **Application**: CloudBeaver DI lifecycle, module registration, GraphQL/MSW mocks, or application services through `@cloudbeaver/tests-runner`.\n\n4. Wire the package by comparing it with the chosen peer:\n\n - Add `\"test\": \"dbeaver-test\"` when absent.\n - Add only test tools and libraries actually required by scripts or test imports. The normal baseline is `@dbeaver/cli`, `@dbeaver/react-tests`, `typescript`, and `vitest`; application helpers require `@cloudbeaver/tests-runner`.\n - Add workspace dependencies with Yarn from `webapp/`, preserving the dependency section and range convention used by the peer.\n - Run a non-immutable Yarn install so the configured TypeScript project linker synchronizes project references. Inspect the resulting `tsconfig.json`; edit references manually only when the linker cannot produce the required reference.\n - Ensure `src/**/*.test.ts` and `src/**/*.test.tsx` are covered by the package's existing `include` rules and compile from `src` to `lib`. Do not add a package-local Vitest config when the root config already supplies the environment.\n\n5. Implement colocated `*.test.ts` or `*.test.tsx` tests. Use `.js` suffixes for relative imports. Keep fixtures local unless they are reusable package-level mocks; put reusable mocks under `__custom_mocks__` and declare every imported package in the correct dependency section.\n\n **Mocking with `isolate: false`:** Prefer injected doubles or typed `vi.spyOn` on module namespaces, installed in `beforeEach` and restored in `afterEach`. Hoisted `vi.mock` may miss cached consumers, and `restoreAllMocks` does not unregister module factories. Avoid blanket `vi.resetModules()`: re-importing DI modules can fail with “module already added”.\n\n6. For application tests, read the current implementations of `@cloudbeaver/tests-runner` and `core-di` before writing setup. Register current modules through `module.ts`, then create the application with the current `createApp()` API. Replace legacy manifest imports and `createApp(...manifests)` calls rather than recreating the removed manifest layer. Import every required module registration before application startup, and install focused GraphQL/MSW and known-console-message expectations for observable side effects.\n\n The shared Vitest configuration currently uses `isolate: false` in order to increase tests run speed. Test files in the same worker share the module cache and global environment, so module registration, mocks, globals, timers, environment variables, console handlers, DOM state, and open resources can affect later files. Make setup idempotent, restore mutable state in `afterEach` or `afterAll`, reset mocks and handlers to their declared baseline, unload applications, and close servers, sockets, and timers. Check that every test declares and initializes its own required dependencies and mocks instead of relying on another file having run first.\n\n7. Build before testing. The shared Vitest configuration discovers compiled `lib/**/*.test.js`, so a source test that has not compiled is not runnable.\n\n ```sh\n yarn workspace build\n yarn workspace test\n yarn workspace lint\n yarn workspace validate-dependencies\n ```\n\n8. Diagnose failures at the owning layer:\n\n - A missing test file usually means compilation did not emit it or the command ran from the wrong workspace.\n - A PnP resolution error means the importing package lacks a declared dependency.\n - A TypeScript project error means a workspace dependency/reference is missing or stale.\n - A missing service means its current module was not registered or an application dependency was omitted.\n - Unexpected console output must be asserted or fixed, not globally suppressed.\n\n9. Confirm the test would fail for the behavior it protects, then restore the implementation and rerun the focused checks. Run root `yarn test` and `yarn validate-dependencies` only for shared test-infrastructure or cross-package changes. Leave generated `lib`, coverage, install, and test-result artifacts uncommitted.\n\n Because isolation is disabled, also run the complete affected package suite rather than only the new file. When shared modules, registries, mocks, or test helpers changed, run the broader workspace suite to expose order-dependent state leakage. A test must pass both alone and with its neighboring suite.\n\n For mock changes, also run the affected package with `--maxWorkers=1`; separate workers can hide cached-module failures.\n\n## Boundaries\n\n- There is no plugin-level \"tests unsupported\" switch. Test support is the combination of scripts, dependencies, compilation, active tests, and a passing build.\n- Prefer pure tests over booting the application. Use the DI environment only when direct construction would bypass behavior under test.\n- Preserve package boundaries: import another workspace through public exports or documented mock exports, never through its `src` directory.\n- Keep production dependencies out of `devDependencies`; test-only imports belong in `devDependencies` unless the package also imports them from production code.\n- A package build failure blocks meaningful test execution because Vitest runs emitted JavaScript. Report unrelated pre-existing build failures explicitly rather than claiming the environment works.\n- Do not enable per-file isolation locally to hide leaked state. Keep the package compatible with the shared root configuration and fix ownership and cleanup at the source.\n\n\n# tsconfig\n"}