code-ai-installer 1.1.4 → 1.1.6

package/locales/en/.agents/testing_strategy_js/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: testing_strategy_js
+description: Testing strategy for JS/TS projects: unit (vitest/jest), integration (API/DB), e2e (playwright) + organization of files and mocks of external services.
+---
+
+# Skill: Testing Strategy (JS/TS)
+
+## Unit
+- Pure functions, utilities, hooks/component logic
+- For UI: test user behavior
+
+## Integration
+- API routes/handlers
+- Repositories/DB (or test container/emulator)
+- Integrations via mocks/contracts
+
+## E2E (Playwright)
+- Only critical flows (login/key CRUD/payment/search) - by task
+
+## Organization
+- Tests next to the code (unit)
+- Integration next to the route/module
+- E2E in a separate folder (e2e/)
+
+## Moki
+- Mock external services (OpenAI/Redis/Supabase/HTTP)
+- Don’t mock everything: preserve the meaning of integration tests
+
+## See also
+- Examples: `$dev_reference_snippets`

package/locales/en/.agents/tests_quality_review/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: tests_quality_review
+description: Review of the quality of unit/integration tests: scenario coverage, boundaries, stability, absence of flakes and test “magic”.
+---
+
+# Skill: Tests Quality Review
+
+## Check
+- Tests check behavior, not implementation details
+- There are happy + edge + error paths
+- Integration tests actually test integration (API/DB/contracts), and are not “over-done”
+- Tests are independent (no hidden order)
+- Flakes: timings/random/external network → eliminated
+- The names of the tests are readable, the structure is clear
+
+## Exit
+- Missing cases (list)
+- Brittle tests (what to fix)

package/locales/en/.agents/threat_model_baseline/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: threat_model_baseline
+description: Threat baseline for MVP: assets, attack vectors, measures. Considers OWASP risks and roles/permissions.
+---
+
+# Skill: Threat Model Baseline
+
+## Target
+Build security into the design before the code.
+
+## Principles
+- Defense in depth
+- Least privilege
+- Input validation at boundaries
+- Secure by default
+- Audit trail for critical operations (if applicable)
+
+## Inputs
+- PRD (PII/payments/critical operations)
+- Roles/permissions
+- Integrations
+- API Contracts
+
+## Output (structure)
+- Assets
+- Attack surfaces
+- Threats → mitigations
+- Security requirements for implementation and tests
+
+## 1) Assets (what we protect)
+- accounts/sessions
+- user data (PII)
+- payments/orders (if any)
+- admin access
+
+## 2) Attack surfaces
+- public endpoints
+- uploading files
+- webhooks
+- auth flows
+
+## 3) Main threats → measures (minimum)
+- Injection (SQL/NoSQL/command) → validation/parameterization
+- XSS → escaping/sanitization/Content Security Policy (if applicable)
+- CSRF → CSRF tokens / sameSite cookies (if applicable)
+- Auth bypass → strict Authz check on the server
+- SSRF → allowlist/prohibition of internal addresses (if there is a fetch of external URLs)
+- Secrets leakage → secret storage + logging prohibited
+- Rate limiting / brute force → limits/blocking/captcha (if necessary)
+
+## 4) Security requirements for implementation
+- where audit logging is required
+- requirements for passwords/sessions/tokens
+- data storage/deletion policy
+
+## Note
+If there is compliance (GDPR, etc.) - fix mandatory measures and retention periods.

package/locales/en/.agents/tooling_bun_biome/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: tooling_bun_biome
+description: Tooling: biomejs (lint/format) and bunjs (runtime/package manager) - setting up scripts, uniform style, dev-loop acceleration.
+---
+
+# Skill: Tooling (Bun + Biome)
+
+## Biome
+- Uniform format and linting rules
+- Autofix in pre-commit/CI (if accepted)
+
+## Bun
+- Use as runtime/package manager if allowed by the project
+- Scripts: dev/test/lint/format/coverage
+
+## See also
+- Examples: `$dev_reference_snippets`

package/locales/en/.agents/typescript_beast_practices/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: typescript_beast_practices
+description: TypeScript practices: strong typing, type-safe contracts, validation schemes (zod/pydantic-analog on the stack), safe DTOs and minification of any.
+---
+
+# Skill: TypeScript Beast Practices
+
+## Target
+Type-safe contracts and refactor without fear.
+
+## Rules
+- strict whenever possible
+- DTO/Contracts are typed and validated at boundaries
+- Do not use any without explicit justification
+- Common types and utilities - in one place, without cyclic dependencies

package/locales/en/.agents/ui_a11y_smoke_review/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: ui_a11y_smoke_review
+description: Quick UI/a11y smoke review: states loading/empty/error, focus, keyboard, aria/labels by a11y baseline and UX Spec.
+---
+
+# Skill: UI & A11y Smoke Review
+
+## Check
+- There are loading/empty/error states according to UX Spec
+- Focus styles are visible, you can use the keyboard
+- Forms: label/aria, error messages available
+- No obvious content/CTA regressions
+
+## Exit
+- Findings + recommendations

package/locales/en/.agents/ui_inventory/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: ui_inventory
+description: Compile an inventory of UI components and rules for reuse: basic components, compositional components, patterns (forms, tables, dialogs), design tokens (minimum).
+---
+
+# Skill: UI Components Inventory
+
+## Target
+Reduce development costs and maintain UI consistency.
+
+## Exit
+List of components in catalog form:
+
+## 1) Basic (atoms)
+- Button (variants: primary/secondary/ghost/destructive, sizes)
+- Input / Textarea
+- Select / Combobox
+- Checkbox / Radio / Switch
+- Badge / Tag
+- Spinner / Skeleton
+- Icon
+- Tooltip
+
+## 2) Compounds (molecules/organisms)
+- FormField (label + control + help + error)
+- Modal / Dialog
+- Toast / Notification
+- Table (sorting/filter/pagination if necessary)
+- EmptyState (icon + text + CTA)
+- ErrorState (message + retry)
+- Pagination
+- Navbar / Sidebar
+- Breadcrumbs (if needed)
+
+## 3) Patterns
+- Loading strategy (skeleton vs spinner)
+- Empty vs zero-results
+- Bugs: levels (inline/page/toast)
+- Confirmation of destructive actions
+- Processing long operations (progress, optimistic UI)
+
+## 4) Minimum design tokens (if there is no design system)
+- Spacing scale (for example: 4/8/12/16/24/32)
+- Border radius levels
+- Typography: headings/text/captions
+- State colors: success/warn/error/info (without specific hex, if not specified)
+
+## Rule
+If there is a ready-made design system, inventory is tied to its components/options.
+If not, describe components with minimal parameters sufficient for implementation and testing of UX Spec.

package/locales/en/.agents/ux_discovery/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: ux_discovery
+description: Clarify UX introductory to PRD: roles, main flows, navigation, platforms (responsive), brand/references, localization, edge cases.
+---
+
+# Skill: UX Discovery
+
+## Target
+Collect the missing UX context before creating the UX Spec.
+
+## When to use
+- Immediately after receiving the PRD
+- When requirements/roles/flows change
+
+## Exit
+- List of clarifying questions (5–15), sorted by criticality
+- Assumptions, if you can’t move without them
+- Draft list of screens/streams
+
+## Questions (ask relevant ones)
+### Platform and layout
+- Is it desktop-first, mobile-first or equivalent to responsive?
+- Key breakpoints/minimum sizes?
+
+### Roles and rights
+- What are the user roles? What is prohibited for each role?
+- Do you need admin/moderation?
+
+### Navigation and structure
+- What are the main sections?
+- Is there deep linking/link sharing?
+
+### Brand/visual expectations
+- Is there a design system/references?
+- If not, do we use a “system UI” (for example, standard patterns of the selected framework)?
+
+### Localization
+- One language or several?
+- Date/time/currency formats?
+
+### UX edge cases
+- What do we show if the data is empty?
+- What do we do in case of network/validation errors?
+- Which operations are potentially long (need progress/skeletons)?
+
+## Rule
+If the answer is critical for the architecture/routing/API, be sure to clarify.
+If you can move forward with a safe assumption, make the assumption and celebrate.

package/locales/en/.agents/ux_spec/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: ux_spec
+description: Generate UX Spec: user flows, IA, list of screens, specification of each screen (actions/sections/validations/states), UX quality criteria for development and testing.
+---
+
+# Skill: UX Spec (Flows + Screens + States)
+
+## Target
+Make a specification according to which the UI can be implemented without “speculation”.
+
+## Exit
+UX Spec in structure:
+
+## 1) Users & Roles
+- Roles:
+- Rights/restrictions:
+
+## 2) Key User Flows
+For each thread:
+- Trigger (where to start)
+- Steps (1..n)
+- Success outcome
+- Failure/edge outcomes
+
+## 3) Information Architecture (IA)
+- Navigation map (sections/screens)
+- Access rules (if the role affects visibility)
+
+## 4) Screens Spec (for each screen)
+### Screen: <Name>
+- Purpose:
+- Primary actions:
+- Sections/components:
+- Forms & validation (if available):
+- States:
+  - Loading:
+  - Empty:
+  - Error:
+  - Success:
+- Notifications (toasts/modals):
+- Permissions notes:
+- Analytics events (if needed):
+- Notes:
+
+## 5) UI Rules (minimal)
+- Conventions: primary/secondary buttons, destructive actions, confirmations
+- Tables/lists: sorting/filters/pagination (if applicable)
+- Forms: inline errors, disabled submit, required markers
+
+## Quality (checklist)
+- No “holes”: every critical scenario from the PRD is covered by a flow + screen
+- For screens, the loading/empty/error/success states are described
+- Validation of forms is specific
+- There are rules for destructive actions (confirm/undo)
+- All sections/components on the screen are indicated (there is no “and there will be ...”)
+- All user actions are indicated (clicks, navigation, forms)

package/locales/en/.agents/wix_self_hosted_embedded_script/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: wix_self_hosted_embedded_script
+description: Practical runbook for Wix Self-Hosted Embedded Script: HTTPS locally, install webhook, embed script, resolve appInstanceId, DB-driven widget config, common errors and DEMO-ready check.
+---
+
+# Skill: Wix Self-Hosted Embedded Script
+
+## When to activate
+- You need to implement or repair the Embedded Script extension in the Wix Self-Hosted app.
+- It is necessary for the widget on the published site to take settings from the database via the backend.
+- There are problems with install webhook, appInstanceId, HTTPS/certificate, blank screen in Wix.
+
+## Mandatory rules
+- Only `https://` URL for Wix extension and local development.
+- No mock data in working flows.
+- The Widget is rendered from the real backend payload (`/api/v1/widget/:appInstanceId`).
+- All functions with JSDoc.
+
+## Basic architecture
+- Dashboard: manages settings and coupons.
+- API: stores settings/coupons, processes OAuth/webhooks, makes embed script.
+- Embedded script: loaded on the user's website, requests widget config from the API, shows popup/launcher.
+- Gateway (Caddy): single HTTPS point (`https://localhost:5173`).
+
+## Contract embedded script flow
+1. Wix uploads:
+   - `<script id="smart-cart-rescue-embedded-script" src="https://<host>/widget/embedded-script.js?appInstanceId=<id>" async="true"></script>`
+2. The script defines `apiOrigin` and `appInstanceId`:
+- from query `appInstanceId`, or
+- via `GET /api/v1/widget/resolve-instance?siteOrigin=<window.location.origin>`.
+3. Script reads payload:
+   - `GET /api/v1/widget/:appInstanceId`
+4. Script renders UI only from payload:
+   - overlay title/text/bg
+   - CTA text
+   - tab emoji/text
+   - timer settings
+- latest coupon (if available)
+
+## What should be in the API
+- `GET /api/v1/widget/:appInstanceId`
+- `GET /api/v1/widget/resolve-instance?siteOrigin=...`
+- `POST /api/v1/embedded-script/embed/:appInstanceId`
+- `POST /api/webhooks/v1/install`
+- `POST /api/webhooks/v1/uninstall`
+- `GET/PUT /api/v1/settings/:appInstanceId`
+
+## Install webhook and embed
+- On `install`:
+- extract `appInstanceId` from webhook JWT,
+- upsert installation + default settings,
+- call embed script API,
+- record audit event.
+- For manual recovery:
+  - `POST /api/v1/embedded-script/embed/:appInstanceId`
+
+## HTTPS and local development
+- Local entry point: `https://localhost:5173`.
+- The certificate must be trusted in the OS (not just browser bypass).
+- If the iframe in `manage.wix.com` is empty:
+- check trusted cert,
+- disable adblock/shields for `manage.wix.com` and `localhost`,
+- hard refresh and/or clean profile.
+
+## Frequent errors and diagnostics
+- `NET::ERR_CERT_AUTHORITY_INVALID`:
+- the certificate is not trusted by the system.
+- White screen in Wix iframe:
+- extension URL is not HTTPS or is blocked by extensions.
+- `App not found for script` / `404`:
+- `appInstanceId` not found, `resolve-instance` path broken.
+- Script loaded, but no UI:
+- script runtime error or invalid widget payload.
+- API 403/permission:
+- there are not enough Wix scopes/token for the required API.
+
+## Minimum smoke-checklist (DEMO-ready)
+1. Dashboard saves settings in the database.
+2. `GET /api/v1/widget/:appInstanceId` returns the current DB values.
+3. Embedded script is actually embedded in the site (visible in the DOM).
+4. Popup/launcher works on a published site.
+5. The timer behaves according to the requirements (without mock behavior).
+6. The CTA performs the expected action (for example, copying the coupon code).
+
+## Done criteria for a task
+- End-to-end flow works in Wix (dashboard -> API -> embedded script -> storefront UI).
+- No hardcoded/mock payload for production-like scenarios.
+- There are verification instructions in the README/DEMO report.

package/locales/en/AGENTS.md

@@ -0,0 +1,120 @@
+# AGENTS.md – Web Development Orchestra
+
+## Source of truth by role
+The roles are described in:
+- agents/conductor.md
+- agents/product_manager.md
+- agents/ux_ui_designer.md
+- agents/architect.md
+- agents/senior_full_stack.md
+- agents/reviewer.md
+- agents/tester.md
+
+Follow these roles when working. If necessary, open the appropriate role file and apply.
+
+---
+
+## Skills (explicitly call)
+Use skills (folders with `SKILL.md`). Full list:
+
+###Core/Orchestration
+- $board
+- $handoff
+- $memory
+- $gates
+- $release_gate
+- $release_gate_checklist_template
+
+### Product Management
+- $pm_interview
+- $pm_prd
+- $pm_backlog
+
+### UX/UI/Design
+- $ux_discovery
+- $ux_spec
+- $ui_inventory
+- $a11y_baseline
+- $design_intake
+- $design_parity_review
+- $design_systems
+- $ui_a11y_smoke_review
+
+### Architecture
+- $current_state_analysis
+- $system_design_checklist
+- $architecture_doc
+- $architecture_compliance_review
+- $adr_log
+- $api_contracts
+- $data_model
+- $threat_model_baseline
+- $observability_plan
+- $deployment_ci_plan
+- $docker_kubernetes_architecture
+- $k8s_manifests_conventions
+- $wix_self_hosted_embedded_script
+
+### Development (Senior Full Stack)
+- $tdd_workflow
+- $testing_strategy_js
+- $tests_quality_review
+- $es2025_beast_practices
+- $typescript_beast_practices
+- $react_beast_practices
+- $tanstack_beast_practices
+- $state_zustand_beast_practices
+- $state_rtk_beast_practices
+- $styling_css_stack
+- $tooling_bun_biome
+- $node_express_beast_practices
+- $go_beast_practices
+- $security_baseline_dev
+- $observability_logging
+- $dev_reference_snippets
+- $mongodb_mongoose_best_practices
+- $wix_self_hosted_embedded_script
+- $react_15_3_wix_iframe (conditionally, only if Wix iFrame / React 15.3)
+
+### Review (Best Practices + Security)
+- $code_review_checklist
+- $api_contract_compliance_review
+- $security_review
+- $security_review_baseline
+- $cloud_infrastructure_security
+- $dependency_supply_chain_review
+- $observability_review
+- $performance_review_baseline
+- $review_reference_snippets
+
+### Testing (QA)
+- $qa_test_plan
+- $qa_manual_run
+- $qa_api_contract_tests
+- $qa_security_smoke_tests
+- $qa_ui_a11y_smoke
+- $qa_e2e_playwright
+
+---
+
+## Gates (Pipeline)
+PM(PRD) → UX(UX Spec) → ARCH(Architecture/ADR/Contracts) → DEV(TDD) → REV(Security/Best) → TEST(Test plan/report) → RG(Release Gate)
+
+---
+
+## Mandatory function documentation rule
+- For all functions in the code base, use a JSDoc block in the format:
+
+```js
+/**
+ * Считает сумму двух чисел.
+ * @param {number} a - Первое число.
+ * @param {number} b - Второе число.
+ * @returns {number} Сумма a и b.
+ */
+function add(a, b) {
+    return a + b;
+}
+```
+
+- The requirement is mandatory for DEV and REV stages.