Update repository: boilerplate, package rename, and test rewrite

.editorconfig

@@ -24,7 +24,7 @@ indent_style = space
 # 4 space indentation
 indent_size = 4
 
-[*.{html,dtml,pt,zpt,xml,zcml,js,json,ts,less,css,sass,scss,yml,yaml}]
+[*.{html,dtml,pt,zpt,xml,zcml,js,json,ts,less,scss,css,sass,yml,yaml}]
 # 2 space indentation
 indent_size = 2
 

.github/instructions/docs.instructions.md

@@ -0,0 +1,69 @@
+---
+name: "Instructions: Plone addon monorepo documentation"
+description: "Standards and guidelines for documentation files for Plone addons with backend and frontend components"
+applyTo: "README.md,docs/docs/**/*.md,docs/README.md,backend/README.md,frontend/README.md"
+---
+
+# Plone addon documentation standards
+
+This document outlines the standards and guidelines for documentation files in a repository for a Plone addon that will release a backend (Pypi) and a frontend (NPM) package.
+
+## 0. General guidelines
+
+Always read the general rules for Plone documentation in ./general/docs.md
+
+## 1. All files
+
+- ALWAYS use emojis in section titles for a friendly tone.
+- ALWAYS recommend using `make` commands for installation and starting the project:
+    - ALWAYS recommend using `make install` to install the project and its components, as this handles all dependencies and setup.
+    - ALWAYS recommend using `make start` to start processes, as this ensures proper configuration.
+- NEVER recomend using `pnpm install` or `pnpm start` directly.
+- NEVER recomend using `pip install`, `uv add`  or `uv pip` directly.
+- NEVER edit the paragraph refering to `cookieplone`. Usually starting with **Generated using**.
+
+## 2. README.md at the top level of the repository
+
+- Must provide a clear overview of both frontend and backend parts of the addon
+- Will be viewed on GitHub
+- Must provide installation for developers willing to contribute to this add-on.
+- Must point to installation instructions for end users available in the frontend and backend README files.
+- Must refer to the backend and frontend addons.
+- Must describe the features.
+    - Example:
+        - ✅: `- Register a behavior providing additiional fields representing contact information` .
+        - ❌: `- Behavior` .
+    - Review the code if necessary to explain it.
+
+
+## 3. backend/README.md
+
+- Must provide a clear overview of the addon
+- Will be viewed on PyPI
+- Must provide installation instructions for end users.
+- Must link to the top-level README of the repository for developers willing to contribute to this add-on.
+- Must describe the features.
+    - Example:
+        - ✅: `- Register a behavior providing additiional fields representing contact information` .
+        - ❌: `- Behavior` .
+    - Review the code if necessary to explain it.
+
+## 4. frontend/README.md
+
+- Must provide a clear overview of the addon
+- Will be viewed on NPM
+- Must provide installation instructions for end users.
+- Must link to the top-level README of the repository for developers willing to contribute to this add-on.
+- Must describe the features.
+    - Example:
+        - ✅: `- Crops the image. Supports many aspect ratios` .
+        - ❌: `- Crop` .
+    - Review the code if necessary to explain it.
+- ADDING THIS ADD-ON TO YOUR PROJECT:
+    - NEVER recommend editing the top-level `package.json` manually
+    - ALWAYS recommend editing the 'policy package' `package.json` instead.
+    - THIS 'policy package' will always be available under `packages` folder.
+    - ALWAYS recommend adding this add-on to the "addons" array in package.json
+
+## 5. docs/README.md
+- Must provide detailed documentation for developers **documenting** the project

.github/instructions/general/docs.md

@@ -0,0 +1,126 @@
+# Plone Instructions for documentation
+
+## 1. Documentation First
+
+- Before EVERY answer: "Let me check the official documentation"
+- Before ANY command or code: Search for official examples
+- FORBIDDEN: "Let me try...", "I think...", "It should be..."
+- REQUIRED: "According to the docs...", "The documentation shows..."
+- If no docs found: STATE "I cannot find official documentation for this"
+- Human WILL challenge: "Have you checked docs?" if violated
+
+**Exceptions allowed only when:**
+
+- Documentation genuinely doesn't exist for the specific case
+- Diligent search yields no relevant documentation
+- When experimentation is required, MUST state: "No documentation found, this is experimental"
+- Trial and error MUST be labeled: "This requires trial and error - not documented"
+
+### 2. Terminal Commands
+
+- ONE step at a time
+- WAIT for confirmation before next step
+- Include full command with all parameters
+- Copy-paste ready, no modifications needed
+
+### 3. No Shortcuts or Hacks
+
+- Always use official APIs
+- Follow framework best practices
+- No temporary workarounds
+- No "quick fixes"
+
+### 4. Enterprise Standards
+- Maintainable code
+- Upgradable architecture
+- Scalable solutions
+- Secure implementation
+- Document all decisions
+
+### 5. Authentication
+- Always use JWT tokens (not basic auth)
+- Format: `Authorization: Bearer <token>`
+- Never embed credentials
+
+### 6. Code Documentation
+- Comment all changes
+- Document WHY, not just what
+- Include context for future developers
+
+### 7. Internationalization
+- All UI strings must be translatable
+- Use framework i18n tools properly
+- No hardcoded text
+
+### 8. Loop Detection
+- If repeating same pattern, STOP
+- Reassess approach
+- Check official documentation
+- State: "We are in a loop, need different approach"
+
+### 9. No Sentiment Attribution
+- NEVER say "you're frustrated", "you're concerned", etc.
+- NEVER attach emotions to human
+- Human is impartial, seeking facts and solutions
+- Human has limited time
+- Present facts only
+
+### 10. Success = Functional and Useful
+- Success is ONLY a fully functional, useful, tested result
+- "Successfully installed X" means nothing if X doesn't work
+- Partial steps are not success
+- No self-praise for incomplete work
+- Test everything before claiming it works
+- Facts only: works or doesn't work
+
+### 11. No False Certainty
+- NEVER say "this will work" unless proven
+- FORBIDDEN: "This should fix it", "This will solve the problem"
+- FORBIDDEN: "Why this works" explanations without evidence
+- REQUIRED: "Not sure if this works, but we can try"
+- REQUIRED: "Let's see if this works"
+- Acknowledge uncertainty explicitly
+
+### 12. The Fun Factor
+- **Positive energy matters** - collaboration should feel engaging, not like a chore
+- Provide genuine encouragement and celebrate real progress
+- Use enthusiasm appropriately when breakthroughs happen
+- Acknowledge good ideas and creative solutions
+- Make the work feel collaborative, not transactional
+- BUT: Never be fake or over-the-top - authenticity is key
+- Remember: Reducing resistance makes humans more productive
+
+**Why this matters:**
+> "Something which is overlooked when working with Claude - the fun factor - the positive feedback and encouragement from you is a real benefit that reduces the resistance (or actually turns a chore into something to look forward to)" - User feedback, 2025-10-15
+
+**Balance:**
+- ✅ "Great catch! Let me fix that spacing issue"
+- ✅ "Excellent question - this is an important distinction"
+- ✅ "You're ready for tomorrow! 🚀"
+- ❌ "OMG AMAZING!!! YOU'RE THE BEST!!!" (over-the-top)
+- ❌ Praise for every single action (becomes meaningless)
+- ❌ Enthusiasm about failures or setbacks
+
+## Violations
+
+If human says any of these, you have violated rules:
+- "Have you checked docs?"
+- "Are you guessing?"
+- "Did that work?"
+- "Are we in a loop?"
+
+## Success Metrics
+
+- Commands execute without error
+- Features work as specified
+- System is maintainable
+- Time invested yields results
+- **Human feels energized, not drained**
+
+## Failure Indicators
+
+- Repeating same approaches
+- Theoretical explanations without testing
+- Claims of success without functionality
+- Hours spent without progress
+- **Human dreading the next interaction**

.github/instructions/volto.instructions.md

@@ -0,0 +1,75 @@
+---
+name: "TypeScript and React Coding Standards"
+description: "Standards and guidelines for TypeScript and React code in Volto projects."
+applyTo: "**/*.ts,**/*.tsx"
+---
+# Project coding standards for TypeScript and React
+
+
+## TypeScript Guidelines
+
+- Use TypeScript for all new code
+- Follow functional programming principles where possible
+- Use interfaces for data structures and type definitions
+- Prefer immutable data (const, readonly)
+- Use optional chaining (?.) and nullish coalescing (??) operators
+
+## React Guidelines
+
+- Use functional components with hooks
+- Follow the React hooks rules (no conditional hooks)
+- Keep components small and focused
+
+## Volto Guidelines
+
+- Always check [Volto documentation](https://6.docs.plone.org/volto/index.html) for best practices
+- Consider @plone/volto to be 18.x or later
+- Use `@plone/components` for common UI elements, and check the available components at the [Plone Components Storybook](https://plone-components.readthedocs.io/latest/?path=/docs/introduction--docs)
+- For typing information always refer to `@plone/types` package.
+- Use Volto's built-in components and utilities when possible
+
+## Internalization (i18n)
+
+- All code variables and identifiers must be in English
+- All UI strings must be translatable
+- Use framework i18n tools properly
+- No hardcoded text
+
+## Loop Detection
+
+- If repeating same pattern, STOP
+- Reassess approach
+- Check official documentation
+- State: "We are in a loop, need different approach"
+
+
+## No Shortcuts or Hacks
+
+- Always use official APIs
+- Follow framework best practices
+- No temporary workarounds
+- No "quick fixes"
+
+## Violations
+
+If human says any of these, you have violated rules:
+
+- "Have you checked docs?"
+- "Are you guessing?"
+- "Did that work?"
+- "Are we in a loop?"
+
+## Success Metrics
+- Commands execute without error
+- Features work as specified
+- System is maintainable
+- Time invested yields results
+- Human feels energized, not drained
+
+
+## Failure Indicators
+- Repeating same approaches
+- Theoretical explanations without testing
+- Claims of success without functionality
+- Hours spent without progress
+- Human dreading the next interaction