@jahia/agentic 0.4.0 → 0.5.0

package/dist/cursor/.agents/skills/jahia-dev-cypress/SKILL.md

@@ -1,265 +0,0 @@
----
-name: jahia-dev-cypress
-description: Write and scaffold Cypress e2e tests for a Jahia JS template set. Covers test-package structure, site seeding, isolation, content setup, rendering assertions, and stable selector strategy.
----
-
-# Skill: jahia-dev-cypress
-
-Use this skill when a Jahia JS template set needs Cypress end-to-end coverage.
-Tests should ship with the component or page template, not weeks later.
-
----
-
-## Test directory layout
-
-Tests live in a separate `tests/` directory at the module root.
-
-```
-<module>/
-├── src/
-├── settings/
-├── tests/
-│   ├── package.json
-│   ├── cypress.config.ts
-│   ├── .env.example
-│   ├── cypress/
-│   │   ├── e2e/
-│   │   │   └── <component-name>/
-│   │   │       ├── happy-path.cy.ts
-│   │   │       ├── authorization.cy.ts
-│   │   │       └── edge-cases.cy.ts
-│   │   ├── fixtures/
-│   │   │   └── graphql/
-│   │   │       └── mutation/
-│   │   ├── plugins/
-│   │   │   └── index.js
-│   │   └── support/
-│   │       ├── commands.ts
-│   │       ├── constants.ts
-│   │       └── e2e.ts
-│   └── results/
-└── package.json
-```
-
----
-
-## Step 1 — Scaffold the Cypress package
-
-Create `tests/package.json`:
-
-```json
-{
-  "name": "<module-name>-cypress",
-  "private": true,
-  "scripts": {
-    "e2e:ci": "cypress run",
-    "e2e:debug": "cypress open"
-  },
-  "devDependencies": {
-    "@jahia/cypress": "^7.1.0",
-    "cypress": "^14.0.0",
-    "cypress-terminal-report": "^5.3.12",
-    "typescript": "^5.0.0"
-  },
-  "packageManager": "yarn@4.12.0"
-}
-```
-
-Install with:
-
-```bash
-cd tests && yarn install
-```
-
----
-
-## Step 2 — Configure Cypress
-
-```typescript
-import { defineConfig } from 'cypress';
-import * as fs from 'node:fs';
-
-export default defineConfig({
-  chromeWebSecurity: false,
-  defaultCommandTimeout: 10000,
-  requestTimeout: 300000,
-  responseTimeout: 300000,
-  viewportWidth: 1366,
-  viewportHeight: 768,
-  watchForFileChanges: false,
-  screenshotsFolder: './results/screenshots',
-  videosFolder: './results/videos',
-  e2e: {
-    baseUrl: 'http://localhost:8080',
-    specPattern: ['**/**.cy.ts'],
-    setupNodeEvents(on, config) {
-      require('@jahia/cypress/dist/plugins/registerPlugins').registerPlugins(on, config);
-      require('cypress-terminal-report/src/installLogsPrinter')(on, {
-        printLogsToConsole: 'onFail',
-        outputRoot: config.projectRoot + '/results/',
-      });
-      on('task', {
-        readFileMaybe(filename) {
-          if (fs.existsSync(filename)) return fs.readFileSync(filename, 'utf8');
-          return null;
-        },
-      });
-      return config;
-    },
-  },
-});
-```
-
----
-
-## Step 3 — Keep tests isolated
-
-### Site-per-suite isolation
-
-Every suite should create its own site in `before()` and delete it in `after()`.
-Do not rely on pre-existing sites.
-
-```typescript
-import { createSite, deleteSite } from '@jahia/cypress';
-
-describe('Hero banner', () => {
-  const SITE_KEY = 'hero-banner-tests';
-
-  before(() => {
-    cy.login();
-    createSite(SITE_KEY, {
-      templateSet: 'my-module',
-      locale: 'en',
-      languages: 'en,fr',
-      serverName: 'localhost',
-    });
-    cy.logout();
-  });
-
-  after(() => {
-    cy.login();
-    deleteSite(SITE_KEY);
-    cy.logout();
-  });
-});
-```
-
-### Session hygiene
-
-Use `beforeEach` / `afterEach` for login boundaries when the scenario needs authentication.
-
----
-
-## Step 4 — Keep the three mandatory spec files
-
-Every component test folder should contain:
-
-- `happy-path.cy.ts`
-- `authorization.cy.ts`
-- `edge-cases.cy.ts`
-
-### Happy path
-
-Validate the component renders correctly in live, preview, and at least one secondary locale.
-
-### Authorization
-
-Validate anonymous versus authenticated access where relevant.
-
-### Edge cases
-
-Seed only mandatory fields and verify missing optional values do not cause broken renders or 500s.
-
----
-
-## Step 5 — Seed content predictably
-
-Use `createSite`, `addNode`, and `publishAndWaitJobEnding` from `@jahia/cypress`.
-
-```typescript
-import { addNode, createSite, deleteSite, publishAndWaitJobEnding } from '@jahia/cypress';
-
-addNode({
-  parentPathOrId: `/sites/${SITE_KEY}/home/testPage/pagecontent`,
-  name: 'myComponent',
-  primaryNodeType: 'ns:myComponentType',
-  properties: [
-    { name: 'title', value: 'Hello World', language: 'en' },
-  ],
-});
-
-publishAndWaitJobEnding(`/sites/${SITE_KEY}`, ['en']);
-```
-
-Prefer fixture files over long inline GraphQL strings when seeding becomes complex.
-
-```typescript
-cy.apollo({
-  mutationFile: 'graphql/mutation/seedMyComponent.graphql',
-  variables: { parentPath: `/sites/${SITE_KEY}/home/testPage/pagecontent` },
-});
-```
-
----
-
-## Step 6 — Use stable selectors
-
-CSS Modules hash class names, so do not target final generated class names directly.
-
-```typescript
-// Better: add data-testid in the component
-cy.get('[data-testid="hero-banner"]').should('be.visible');
-
-// Acceptable fallback for CSS Modules
-cy.get('[class*="_card_"]').first().click();
-```
-
-Preferred approach in production views:
-
-```tsx
-<section data-testid="hero-banner" className={styles.hero}>
-```
-
----
-
-## Step 7 — Organize support code cleanly
-
-- Keep `cypress/support/commands.ts` focused on command registration.
-- Move larger helper implementations into small modules under `cypress/support/`.
-- Put run-level cleanup in `support/e2e.ts` so repeated runs stay idempotent.
-- Avoid large copy-pasted setup blocks across spec files.
-
----
-
-## Guardrails
-
-1. Never test against production data — always create isolated sites and fixtures.
-2. Always clean up created sites and users in `after()` hooks.
-3. Publish seeded content before asserting live renders.
-4. Prefer `data-testid` selectors over CSS classes.
-5. Avoid flaky `cy.wait(ms)` calls — use polling helpers or explicit conditions instead.
-6. Test both the happy path and the main failure/empty-state paths.
-7. Verify at least one secondary locale such as FR when the component is localized.
-
----
-
-## Running tests
-
-```bash
-# From the module root
-yarn build && yarn jahia-deploy
-
-# Then run Cypress
-cd tests && yarn e2e:ci
-```
-
-Use `yarn e2e:debug` locally when you need the interactive runner.
-
----
-
-## Related skills
-
-- `/jahia-dev-build-component` — build the component being tested
-- `/jahia-dev-accessibility` — catch semantic and keyboard issues before or after writing e2e tests
-- `/jahia-dev-create-page-template` — create the page templates that Cypress will exercise
-

package/dist/cursor/.agents/skills/jahia-dev-define-content-type/SKILL.md

@@ -1,93 +0,0 @@
----
-name: jahia-dev-define-content-type
-description: Creates a Jahia CND content type definition from a natural language description. Use when asked to model content, create a new content type, or define node types.
-allowed-tools: Bash, Read
----
-
-## Overview
-
-Orchestrates CND authoring by delegating to the `@jahia-cnd-author` sub-agent, which handles all CND syntax in an isolated context window. Your job here is to capture the spec and assemble the delegation call.
-
----
-
-## Step 0 — Capture the spec
-
-Confirm with the user (or infer from context):
-
-| Field | Answer |
-|---|---|
-| **Component name** | e.g. `HeroSection` |
-| **Description** | What is this type for? |
-| **Fields** | name / type / i18n? / mandatory? |
-| **Repeatable children?** | CTA buttons, feature items, testimonials? |
-| **Views** | default only, or also: card / fullPage |
-| **Used where** | In a page area? Child of another component? |
-
-For modeling decisions (semantic vs generic, children vs weakreference, mixin extraction), LOAD references/modeling-decisions.md.
-
----
-
-## Step 1 — Resolve module context
-
-```bash
-# Get namespace prefix
-grep -h "^<" settings/definitions.cnd | head -1
-
-# Check for two-tier mixin (pageComponent)
-grep "pageComponent" settings/definitions.cnd
-```
-
----
-
-## Step 2 — REQUIRED: Delegate to `@jahia-cnd-author`
-
-**Do not write CND directly.** Writing CND from memory always produces incorrect Jahia-specific patterns. The sub-agent reads reference files containing the exact syntax — you cannot reproduce this from training data.
-
-Invoke the sub-agent with the complete structured spec:
-
-```
-@jahia-cnd-author
-
-Component: <PascalCase name>
-Namespace prefix: <ns>
-Module path: <absolute path to module root>
-Fields:
-  - <fieldName>: <type description> [mandatory] [i18n] [multiple]
-  - ... (one line per field)
-Children: <describe any repeatable sub-items, e.g. "CTA buttons with label + link">
-Usage: <where this component appears, e.g. "dropped in page areas">
-```
-
-Wait for the agent to report back before proceeding.
-
----
-
-## Step 2b — Validate the CND
-
-After `@jahia-cnd-author` reports back, invoke `/jahia-dev-review-cnd` on the written file:
-
-```
-/jahia-dev-review-cnd <module-path>/src/components/<Category>/<Name>/definition.cnd
-```
-
-If the review reports errors, send them back to `@jahia-cnd-author` to fix. Do not proceed until the review is clean.
-
----
-
-## Step 3 — Continue with deployment
-
-After the CND review is PASS, proceed with:
-- Add UI translations (`/jahia-dev-build-component` handles this if invoked from there)
-- `yarn build && yarn jahia-deploy`
-- Verify the type appears in Jahia's content editor
-
----
-
-## Validation checklist
-
-- [ ] Spec confirmed before delegation
-- [ ] `@jahia-cnd-author` reported PASS (no errors)
-- [ ] Translation keys added to `.properties` files
-- [ ] Icon created at `settings/content-types-icons/<ns>_<typeName>.png`
-- [ ] `yarn build && yarn jahia-deploy` succeeded
-- [ ] Type appears in Jahia content editor with correct label and icon

package/dist/cursor/.agents/skills/jahia-dev-define-content-type/references/modeling-decisions.md

@@ -1,52 +0,0 @@
-# CND Modeling Decisions
-
-## Semantic vs generic types
-
-| Use **semantic types** for… | Use **generic types** for… |
-|---|---|
-| Business entities: articles, team members, events | Visual composition: banners, feature rows |
-| Items that appear in listings | One-off sections, layout containers |
-| Anything reused across pages | Unique per-page UI blocks |
-
-## Children vs weakreference
-
-| Use **child nodes** when… | Use **weakreference** when… |
-|---|---|
-| Parent is the visual container (e.g. CTA buttons inside a hero) | Linking to content managed elsewhere |
-| Children have no life outside the parent | Many-to-many relationships |
-| You always create the children together | Content editors need to reuse the referenced item |
-| Each item has multiple properties (label + link) | Each item is just a reference (a page, an image) |
-
-## Mixins are the primary reuse mechanism
-
-Whenever a set of properties appears on more than one type, extract them into a mixin in `settings/definitions.cnd`.
-
-Common reusable mixin patterns:
-
-| Mixin | Properties it adds | When to use |
-|---|---|---|
-| `nsmix:cta` | `ctaLabel`, `j:linkType` | Any type with a button or link |
-| `nsmix:badge` | `badgeText`, `badgeColor` | Cards, teasers, labelled content |
-| `nsmix:seo` | `metaTitle`, `metaDescription` | Any `jmix:mainResource` type |
-| `nsmix:media` | `image` (weakreference) | Any type with a visual asset — alt text comes from the image node's `jcr:title`, never add a separate imageAlt property |
-
-Example reusable CTA mixin:
-
-```cnd
-[nsmix:cta] mixin
- - ctaLabel (string) i18n
- - j:linkType (string, choicelist[linkTypeInitializer]) = 'none' autocreated mandatory
- // j:linknode and j:url are injected automatically
-```
-
-Any component that needs a CTA extends `nsmix:cta` — no property duplication.
-
-## `jmix:mainResource` — when NOT to use it
-
-Only for content that needs **both** a listing card AND a full detail page (e.g. blog posts, events).
-Do NOT add to: navigation-only types, visual composition components, containers.
-
-## Component location
-
-- **Component-level** (preferred): `src/components/<Category>/<Name>/definition.cnd`
-- **Module-level**: `settings/definitions.cnd` (for mixins and shared base types only)

package/dist/cursor/.agents/skills/jahia-dev-java/SKILL.md

@@ -1,110 +0,0 @@
----
-name: jahia-dev-java
-description: |
-  Jahia 8.2 Java module development — creating OSGi modules, defining content types (CND),
-  building JSP views, implementing backend logic (rules, actions, queries), and extending
-  the Jahia UI (Content Editor, jContent, component registry).
-  Trigger when the user is: creating or modifying a Java module, writing CND content type
-  definitions, building JSP rendering views, implementing Jahia rules or actions, running
-  JCR SQL2 queries, extending Content Editor or jContent UI, configuring OSGi services,
-  or troubleshooting module deployment issues.
-allowed-tools: Read
----
-
-# Jahia 8.2 Java Developer Skill
-
-## When to load which reference
-
-| Task | Reference |
-|------|-----------|
-| Creating a new module, Maven pom.xml, deployment, Java 11/17, static assets, deploy-free coding, troubleshooting bundle errors | `references/modules.md` |
-| Writing CND definitions, content type hierarchy, property types, choicelist initializers, modifying existing definitions | `references/content-types.md` |
-| JSP views, view selection, `@cache` tag, caching configuration, navigation menus, rendering filters, AMP | `references/rendering.md` |
-| Drools rules (DRL), JCR event listeners, JCR SQL2 queries, external data provider, permissions and roles | `references/backend.md` |
-| OSGi bundle lifecycle, Declarative Services, Blueprint XML, package Import/Export, service registry, Karaf tooling | `references/osgi.md` |
-| Content Editor JSON overrides, jContent UI extension points, component registry, custom selectors, settings pages, CKEditor | `references/ui-extensions.md` |
-| JCR session lifecycle, workspace, node names, SNS, mixins, locks, versioning — **correct patterns and pitfalls** | `/jahia-java-jcr` skill |
-| OSGi `@Component` state, `@Reference`, lifecycle side effects, Export-Package — **correct patterns and pitfalls** | `/jahia-java-osgi` skill |
-| Securing HTTP-reachable surfaces (servlets, GraphQL, filters) — Security Filter, CSRF Guard, ACLs | `/jahia-java-security` skill |
-| Relational persistence alongside JCR — N+1, timestamp consistency, entity model, transactional asymmetry | `/jahia-java-persistence` skill |
-| Thread safety in a multi-threaded webapp — `volatile`, locking, atomic variables, thread-safe collections, JCR session threading | `/jahia-java-concurrency` skill |
-
-## Key Concepts Glossary
-
-**Bundle / Module**
-An OSGi JAR deployed into Jahia. Every Jahia module is an OSGi bundle. Jahia adds custom MANIFEST attributes (`Jahia-Module-Type`, `Jahia-Depends`, `Jahia-Root-Folder`) on top of standard OSGi headers.
-
-**CND (Compact Namespace and Node Type Definition)**
-Apache Jackrabbit standard file format (`definitions.cnd`) that declares content types. Lives at `src/main/resources/META-INF/definitions.cnd`.
-
-**JCR (Java Content Repository)**
-The underlying storage model. Content is a tree of nodes, each with a primary type and optional mixin types. Jahia uses Apache Jackrabbit Oak as the JCR implementation.
-
-**jnt: prefix**
-Jahia Node Types namespace (`http://www.jahia.org/jahia/nt/1.0`). Used for concrete content types like `jnt:content`, `jnt:page`, `jnt:file`.
-
-**jmix: prefix**
-Jahia Mixin namespace (`http://www.jahia.org/jahia/mix/1.0`). Used for abstract mixin types like `jmix:editorialContent`, `jmix:list`, `jmix:cache`.
-
-**jmix:editorialContent**
-Key mixin — makes a content type visible in jContent and enables content versioning. Required for any user-editable content type.
-
-**jmix:droppableContent**
-Base mixin for component categories. Types that inherit from this mixin create a component folder in the content picker sidebar.
-
-**Declarative Services (DS)**
-Preferred OSGi service mechanism in Jahia 8.2. Uses `@Component`, `@Activate`, `@Reference` annotations. Blueprint XML is deprecated as of Jahia 8.2.
-
-**jahia-depends**
-MANIFEST / pom.xml property declaring other module artifact IDs that this module requires. OSGi resolves dependencies before starting the bundle. Supports version ranges and optional dependencies.
-
-**Embed-Dependency**
-Felix Maven Bundle Plugin instruction to embed non-OSGi JARs inside the module JAR. Default scope: `compile|runtime`. Dependencies scoped `provided` are NOT embedded.
-
-**Deploy-free coding**
-Development workflow where source file changes (JSP, CSS, JS, CND) are picked up live without redeployment. Requires initial deploy and `Jahia-Source-Folders` MANIFEST attribute pointing to the project base directory.
-
-**jahia:deploy Maven goal**
-Deploys the compiled module JAR to a local Jahia server or Docker container. Usage: `mvn clean install jahia:deploy -P <profile>`.
-
-**Content Editor**
-Jahia's React-based form UI for creating/editing content. Forms are generated from CND definitions merged with JSON override files. Override files live in `META-INF/jahia-content-editor-forms/`.
-
-**jContent**
-Jahia's React-based content management UI. Extended via the component registry (`window.jahia.uiExtender.registry`). Used by editors to browse, create, and manage content.
-
-**Component Registry**
-JavaScript hashmap (`type + key → value`) used to inject UI elements (actions, accordions, nav items, selector types) into jContent and Content Editor at runtime. Access via `import {registry} from '@jahia/ui-extender'`.
-
-**DRL (Drools Rule Language)**
-Rule files placed at `META-INF/rules.drl` (all workspaces), `META-INF/default-rules.drl` (edit workspace only), or `META-INF/live-rules.drl` (live workspace only). Jahia provides a built-in DSL that simplifies rule conditions and consequences.
-
-**Workspace**
-Jahia has two JCR workspaces: `default` (edit/preview, where authors work) and `live` (what visitors see). Publication copies nodes from default to live.
-
-**Felix Web Console**
-OSGi administration UI at `http://localhost:8080/tools`. Shows bundle states, packages, services. Useful for diagnosing dependency issues.
-
-**Karaf SSH Shell**
-Command-line OSGi console accessible via `ssh -p 8101 jahia@localhost`. Key commands: `jahia:modules`, `bundle:requirements`, `jcr:query`.
-
-**JCR SQL2**
-Query language for the JCR. Syntax: `SELECT * FROM [nodetype] AS alias WHERE condition`. Use `ISDESCENDANTNODE(alias, '/path')` to scope queries. Do NOT query `nt:base` — use `jmix:searchable` instead for broad content queries.
-
-**choicelist initializer**
-Java class implementing `ModuleChoiceListInitializer` that populates dropdown values in Content Editor. Registered as an OSGi `@Component` service. Referenced in CND with `choicelist[keyName]` syntax.
-
-**Rendering filter**
-OSGi service implementing `RenderFilter`. Wraps every JSP/module render. Priority < 16 runs per-request; priority > 16 runs only on cache miss. Extend `AbstractFilter` to use condition setters.
-
-**Migration scripts**
-Groovy scripts in `src/main/resources/META-INF/patches/` that run once on module deployment to migrate JCR content or configuration.
-
-**Module types**
-`Jahia-Module-Type` MANIFEST value controls module behavior:
-- `module` — regular content module (default)
-- `system` — loaded early, provides system-level services
-- `templatesSet` — template set module that defines site templates
-
-**Static resources**
-JS/CSS/images declared in `Jahia-Static-Resources` MANIFEST header (e.g. `/css,/icons,/javascript`). Served directly from the OSGi bundle JAR under `src/main/resources/`.