Обновление зависимостей и адаптация тестов под актуальные Actions SDK

.checkov.yml

@@ -0,0 +1,7 @@
+# See: https://www.checkov.io/1.Welcome/Quick%20Start.html
+
+compact: true
+quiet: true
+skip-path:
+  - coverage
+  - node_modules

.codex/AGENTS.md

@@ -0,0 +1,32 @@
+# Project rule
+
+You're an experienced engineer who doesn't ask unnecessary questions and tries to figure everything out on your own, delving into the project in detail and independently studying anything that's unclear.
+
+Always output the answer in Russian language. Proper names, code blocks, and other variable names should remain in English.
+
+Use 2 for indent using spaces in all project
+Take into account the versions of the modules used, they can be found in the file package.json this project
+
+The main IDE for development is VSCode. Follow the appropriate formatting for comments and other features for this IDE.
+
+Use `pnpm` package manager for run package script commands.
+
+Don't overload the readme file with unnecessary information. Move any instructions to a separate file. The main readme file should be short and reflect the essence of the project, information for developers on how to get started, licensing information, and the modules used.
+
+After creating or making changes to any file, be sure to double-check it several times.
+
+## Project history. Agent context
+
+Always use the `.agent/agent_context` folder to retrieve information about your most recent actions in a project. If this folder not exists, create this.
+Always use the `.agent/agent_context` to save your most recent work. Save them as separate files - max 2000 rows. Save in these files anything that will help you later recall the work you did. The completeness of your records should be based on your ability to remember what was done in the project.
+To store the history of actions (in folder `.agent/agent_context`), use Markdown files. Include the current date down to the second in file names. Mandatory date and time and name format for these files `YearMonthDayHourMinuteSecond-your_action.md`, example: `20260214212215-fix_modal.md`. These files must be written in English.
+Be sure to record the user's query that he asked before starting work.
+
+To understand what you last did on this project, use the files in this folder and review them from the earliest to the latest to understand what was changed and why.
+
+Please be sure to read all of the following rules:
+
+- [Project Overview](./rules/project.md)
+- [TypeScript Guidelines](./rules/typescript.md)
+- [Markdown files](./rules/mark.md)
+- [Git work rules](./rules/git.md)

.codex/rules/git.md

@@ -0,0 +1,12 @@
+# Git work rules
+
+When requested to provide a Git commit, it must be:
+
+* the commit must be in markdown format
+* the title must not be in Markdown style
+* must be output as a code block
+* include changes since the last Git commit
+* display in Russian in the chat
+* do not use the infinitive
+* there should be NO extra git add, git rm or git commit -m commands, only the text of the commit itself
+* a commit must have a title and then a list of changes

.codex/rules/mark.md

@@ -0,0 +1,4 @@
+# Markdown files
+
+- Before creating any markdown documentation, ask user whether it needs to be created.
+- Do not create a docs folder or documentation files in it under any circumstances.

.codex/rules/project.md

@@ -0,0 +1,9 @@
+# Project Overview
+
+- Backend project using TypeScript only, no web elements.
+- Do not import new libraries without permission.
+- Use ES imports, not require().
+
+## Project Description
+
+Read [README.md](../../README.md)

.codex/rules/typescript.md

@@ -0,0 +1,301 @@
+# TypeScript Guidelines
+
+TypeScript code style, type co-location, constant naming conventions, and arktype patterns. Use when writing TypeScript code, defining types, creating constants, or working with arktype schemas.
+
+## Core Rules
+
+- Always use `type` instead of `interface` in TypeScript.
+- TypeScript 5.5+ automatically infers type predicates in `.filter()` callbacks. Don't add manual type assertions:
+
+  ```typescript
+  // Good - TypeScript infers the narrowed type automatically
+  const filtered = items.filter((x) => x !== undefined);
+
+  // Bad - unnecessary type predicate
+  const filtered = items.filter((x): x is NonNullable<typeof x> => x !== undefined);
+  ```
+
+- When moving components to new locations, always update relative imports to absolute imports (e.g., change `import Component from '../Component.ts'` to `import Component from '$lib/components/Component.ts'`)
+- When functions are only used in the return statement of a factory/creator function, use object method shorthand syntax instead of defining them separately. For example, instead of:
+
+  ```typescript
+  function myFunction() {
+   const helper = () => {
+    /* ... */
+   };
+   return { helper };
+  }
+  ```
+
+  Use:
+
+  ```typescript
+  function myFunction() {
+   return {
+    helper() {
+     /* ... */
+    },
+   };
+  }
+  ```
+
+# Type Co-location Principles
+
+## Never Use Generic Type Buckets
+
+Don't create generic type files like `$lib/types/models.ts`. This creates unclear dependencies and makes code harder to maintain.
+
+### Bad Pattern
+
+```typescript
+// $lib/types/models.ts - Generic bucket for unrelated types
+export type LocalModelConfig = { ... };
+export type UserModel = { ... };
+export type SessionModel = { ... };
+```
+
+### Good Pattern
+
+```typescript
+// $lib/services/transcription/local/types.ts - Co-located with service
+export type LocalModelConfig = { ... };
+
+// $lib/services/user/types.ts - Co-located with user service
+export type UserModel = { ... };
+```
+
+## Co-location Rules
+
+1. **Service-specific types**: Place in `[service-folder]/types.ts`
+2. **Component-specific types**: Define directly in the component file
+3. **Shared domain types**: Place in the domain folder's `types.ts`
+4. **Cross-domain types**: Only if truly shared across multiple domains, place in `$lib/types/[specific-name].ts`
+
+## Benefits
+
+- Clear ownership and dependencies
+- Easier refactoring and deletion
+- Better code organization
+- Reduces coupling between unrelated features
+
+# Constant Array Naming Conventions
+
+## Pattern Summary
+
+| Pattern | Suffix | Description | Example |
+|---------|--------|-------------|---------|
+| Simple values (source of truth) | Plural noun with unit | Raw values array | `BITRATES_KBPS`, `SAMPLE_RATES` |
+| Rich array (source of truth) | Plural noun | Contains all metadata | `PROVIDERS`, `RECORDING_MODE_OPTIONS` |
+| IDs only (for validation) | `_IDS` | Derived from rich array | `PROVIDER_IDS` |
+| UI options `{value, label}` | `_OPTIONS` | For dropdowns/selects | `BITRATE_OPTIONS`, `SAMPLE_RATE_OPTIONS` |
+| Label map | `_TO_LABEL` (singular) | `Record<Id, string>` | `LANGUAGES_TO_LABEL` |
+
+## When to Use Each Pattern
+
+### Pattern 1: Simple Values -> Derived Options
+
+Use when the label can be computed from the value:
+
+```typescript
+// constants/audio/bitrate.ts
+export const BITRATES_KBPS = ['16', '32', '64', '128'] as const;
+
+export const BITRATE_OPTIONS = BITRATES_KBPS.map((bitrate) => ({
+  value: bitrate,
+  label: `${bitrate} kbps`,
+}));
+```
+
+### Pattern 2: Simple Values + Metadata Object
+
+Use when labels need richer information than the value alone:
+
+```typescript
+// constants/audio/sample-rate.ts
+export const SAMPLE_RATES = ['16000', '44100', '48000'] as const;
+
+const SAMPLE_RATE_METADATA: Record<SampleRate, { shortLabel: string; description: string }> = {
+  '16000': { shortLabel: '16 kHz', description: 'Optimized for speech' },
+  '44100': { shortLabel: '44.1 kHz', description: 'CD quality' },
+  '48000': { shortLabel: '48 kHz', description: 'Studio quality' },
+};
+
+export const SAMPLE_RATE_OPTIONS = SAMPLE_RATES.map((rate) => ({
+  value: rate,
+  label: `${SAMPLE_RATE_METADATA[rate].shortLabel} - ${SAMPLE_RATE_METADATA[rate].description}`,
+}));
+```
+
+### Pattern 3: Rich Array as Source of Truth
+
+Use when options have extra fields beyond `value`/`label` (e.g., `icon`, `desktopOnly`):
+
+```typescript
+// constants/audio/recording-modes.ts
+export const RECORDING_MODES = ['manual', 'vad', 'upload'] as const;
+export type RecordingMode = (typeof RECORDING_MODES)[number];
+
+export const RECORDING_MODE_OPTIONS = [
+  { label: 'Manual', value: 'manual', icon: 'mic', desktopOnly: false },
+  { label: 'Voice Activated', value: 'vad', icon: 'mic-voice', desktopOnly: false },
+  { label: 'Upload File', value: 'upload', icon: 'upload', desktopOnly: false },
+] as const satisfies { label: string; value: RecordingMode; icon: string; desktopOnly: boolean }[];
+
+// Derive IDs for validation if needed
+export const RECORDING_MODE_IDS = RECORDING_MODE_OPTIONS.map(o => o.value);
+```
+
+## Choosing a Pattern
+
+| Scenario | Pattern |
+|----------|---------|
+| Label = formatted value (e.g., "128 kbps") | Simple Values -> Derived |
+| Label needs separate data (e.g., "16 kHz - Optimized for speech") | Values + Metadata |
+| Options have extra UI fields (icon, description, disabled) | Rich Array |
+| Platform-specific or runtime-conditional content | Keep inline in component |
+
+## Naming Rules
+
+### Source Arrays
+
+- Use **plural noun**: `PROVIDERS`, `MODES`, `LANGUAGES`
+- Add unit suffix when relevant: `BITRATES_KBPS`, `SAMPLE_RATES`
+- Avoid redundant `_VALUES` suffix
+
+### Derived/Options Arrays
+
+- Use **plural noun** + `_OPTIONS` suffix: `BITRATE_OPTIONS`, `SAMPLE_RATE_OPTIONS`
+- For IDs: **plural noun** + `_IDS` suffix: `PROVIDER_IDS`
+
+### Label Maps
+
+- Use **singular** `_TO_LABEL` suffix: `LANGUAGES_TO_LABEL`
+- Describes the operation (id -> label), not the container
+- Reads naturally: `LANGUAGES_TO_LABEL[lang]` = "get the label for this language"
+
+### Constant Casing
+
+- Always use `SCREAMING_SNAKE_CASE` for exported constants
+- Never use `camelCase` for constant objects/arrays
+
+## Co-location
+
+Options arrays should be co-located with their source array in the same file. Avoid creating options inline in `ts` components; import pre-defined options instead.
+
+Exception: Keep options inline when they have platform-specific or runtime-conditional content that would require importing platform constants into the data module.
+
+# Parameter Destructuring for Factory Functions
+
+## Prefer Parameter Destructuring Over Body Destructuring
+
+When writing factory functions that take options objects, destructure directly in the function signature instead of in the function body. This is the established pattern in the codebase.
+
+### Bad Pattern (Body Destructuring)
+
+```typescript
+// DON'T: Extra line of ceremony
+function createSomething(opts: { foo: string; bar?: number }) {
+  const { foo, bar = 10 } = opts;  // Unnecessary extra line
+  return { foo, bar };
+}
+```
+
+### Good Pattern (Parameter Destructuring)
+
+```typescript
+// DO: Destructure directly in parameters
+function createSomething({ foo, bar = 10 }: { foo: string; bar?: number }) {
+  return { foo, bar };
+}
+```
+
+### Why This Matters
+
+1. **Fewer lines**: Removes the extra destructuring statement
+2. **Defaults at API boundary**: Users see defaults in the signature, not hidden in the body
+3. **Works with `const` generics**: TypeScript literal inference works correctly:
+
+   ```typescript
+   function select<const TOptions extends readonly string[]>({
+     options,
+     nullable = false,
+   }: {
+     options: TOptions;
+     nullable?: boolean;
+   }) { ... }
+   ```
+
+4. **Closures work identically**: Inner functions capture the same variables either way
+
+### When Body Destructuring is Valid
+
+- Need to distinguish "property missing" vs "property is `undefined`" (`'key' in opts`)
+- Complex normalization/validation of the options object
+- Need to pass the entire `opts` object to other functions
+
+### Codebase Examples
+
+```typescript
+// From packages/epicenter/src/core/schema/columns.ts
+export function select<const TOptions extends readonly [string, ...string[]]>({
+  options,
+  nullable = false,
+  default: defaultValue,
+}: {
+  options: TOptions;
+  nullable?: boolean;
+  default?: TOptions[number];
+}): SelectColumnSchema<TOptions, boolean> {
+  return { type: 'select', nullable, options, default: defaultValue };
+}
+
+// From apps/whispering/.../create-key-recorder.ts
+export function createKeyRecorder({
+  pressedKeys,
+  onRegister,
+  onClear,
+}: {
+  pressedKeys: PressedKeys;
+  onRegister: (keyCombination: KeyboardEventSupportedKey[]) => void;
+  onClear: () => void;
+}) { ... }
+```
+
+# Arktype Optional Properties
+
+## Never Use `| undefined` for Optional Properties
+
+When defining optional properties in arktype schemas, always use the `'key?'` syntax instead of `| undefined` unions. This is critical for JSON Schema conversion (used by OpenAPI/MCP).
+
+### Bad Pattern
+
+```typescript
+// DON'T: Explicit undefined union - breaks JSON Schema conversion
+const schema = type({
+  window_id: 'string | undefined',
+  url: 'string | undefined',
+});
+```
+
+This produces invalid JSON Schema with `anyOf: [{type: "string"}, {}]` because `undefined` has no JSON Schema equivalent.
+
+### Good Pattern
+
+```typescript
+// DO: Optional property syntax - converts cleanly to JSON Schema
+const schema = type({
+  'window_id?': 'string',
+  'url?': 'string',
+});
+```
+
+This correctly omits properties from the `required` array in JSON Schema.
+
+### Why This Matters
+
+| Syntax | TypeScript Behavior | JSON Schema |
+|--------|---------------------|-------------|
+| `key: 'string \| undefined'` | Required prop, accepts string or undefined | Broken (triggers fallback) |
+| `'key?': 'string'` | Optional prop, accepts string | Clean (omitted from `required`) |
+
+Both behave similarly in TypeScript, but only the `?` syntax converts correctly to JSON Schema for OpenAPI documentation and MCP tool schemas.