feature/api-spec-first

.claude/agent-memory/frontend-developer/MEMORY.md

@@ -0,0 +1,5 @@
+# Frontend-developer memory
+
+## Project
+
+- [event-category-identity frontend iteration 2](project_event_category_identity_frontend.md) — no separate "Moje přihláška" component, orphaned category display pattern, hideEmptyColumns gotcha, openapi regen against live 8443 backend without touching docs/

.claude/agent-memory/frontend-developer/project_event_category_identity_frontend.md

@@ -0,0 +1,42 @@
+---
+name: event-category-identity-frontend
+description: Frontend iteration 2 of event-category-identity — registration category is now an id-backed object, single shared registrations table doubles as admin view and member's own view
+metadata:
+  type: project
+---
+
+OpenSpec change `event-category-identity` iteration 2 (backend done as of 2026-07-26): registration
+requests use `categoryId` (UUID via `EventCategoryId {value}`), responses carry `category: {id, name} | undefined`
+(absent/null = orphaned registration, category was removed from the event after the member registered).
+
+**Key discovery: there is no dedicated "Moje přihláška" component.** The admin-facing
+`RegistrationsTable` inside `frontend/src/pages/events/EventDetailPage.tsx` is the single shared
+table both admins and the registered member see (member sees their own row via the same
+`_embedded.registrationDtoList`, other rows/columns hidden per-field by backend authorization).
+Don't build a separate "own registration" component — extend this one.
+
+**HAL-FORMS `register`/`editRegistration` needed zero custom field code** — the affordance's
+`categoryId` property comes with `options.inline` (value=id, prompt=name), and the existing generic
+`HalFormsSelect` (`frontend/src/components/HalNavigator2/halforms/fields/HalFormsSelect.tsx`) already
+renders inline options generically. Only the table's category *display* cell needed a change.
+
+**Fix pattern for orphaned category display**: `TableCell column="category"` needs a `dataRender`
+reading `(value as EventCategory | null | undefined)?.name ?? labels.ui.notProvided` — reused the
+existing `notProvided: 'neuvedeno'` label rather than adding a new one for "unset category".
+
+**`KlabisTable`'s `hideEmptyColumns` gotcha**: it hides a column if *every* row's raw value is
+`null`/`undefined`/`''`. A test with only an orphaned row (`category: null`) and no other row with a
+real category will hide the whole category column — the "neuvedeno" cell never renders in that case.
+Tests (and real orphaned-registration scenarios) need at least one row with a real category present
+so the column stays visible. See `frontend/src/pages/events/EventDetailPage.test.tsx` describe block
+`'category cell display (event-category-identity)'`.
+
+## Regenerating klabisApi.d.ts against a running backend
+
+`docs/openapi/klabis-full.json` (source for `npm run openapi`) is generated by a Gradle task that
+expects the backend on port **8080**, but local dev backend runs on **8443** (self-signed TLS). When
+you need fresh types and only 8443 is up: `curl -sk https://localhost:8443/v3/api-docs -o <tmp>.json`
+then `npx openapi-typescript <tmp>.json -o ./src/api/klabisApi.d.ts` directly — skip writing into
+`docs/openapi/klabis-full.json` since that file lives outside `frontend/` and frontend-developer must
+not touch files outside `./frontend`. Verify with `python3 -c "import json; json.load(open(...))"` that
+the curl didn't truncate before trusting the regenerated types.

.claude/hookify.block-direct-tests.local.md

@@ -1,6 +1,6 @@
 ---
 name: block-direct-tests
-enabled: true
+enabled: false
 event: bash
 pattern: (gradlew?\s+.*test|vitest|npm\s+(run\s+)?test)
 action: warn

.claude/skills/backend-patterns/references/aggregate-checklist.md

@@ -37,9 +37,13 @@ Use this checklist when adding a new Spring Modulith module or new Aggregate to
   - [ ] `@SecurityRequirement(name = "KlabisAuth", scopes = {...})`
 - [ ] Convert UUID path variables to typed IDs at controller boundary: `new <Aggregate>Id(uuid)`
 - [ ] Implement role-based command routing (admin vs. self-update)
-- [ ] Add state-driven HATEOAS affordances using `klabisLinkTo()` / `klabisAfford()`
+- [ ] Add state-driven HATEOAS affordances using `klabisLinkTo()` / `klabisAfford()`, passing the
+      generated `*Api` interface to `methodOn(...)` — never the controller class, or the template
+      loses its input metadata (see SKILL.md, "HATEOAS Rules")
+- [ ] Leave `@RequestBody` and Bean Validation constraints on the interface; the override declares
+      only `@Parameter` / `@Operation` for springdoc
 - [ ] Create MapStruct `@Mapper` for simple DTO mapping
-- [ ] Create manual mapper utility class for complex PATCH operations with `PatchField`
+- [ ] Create manual mapper utility class for complex PATCH operations with `JsonNullable`
 
 ## 4. Infrastructure — JDBC
 

.claude/skills/developer-manual-maintainer/references/page-inventory.md

@@ -54,7 +54,7 @@ Onboarding pro vývojáře bez Spring/DDD znalostí. Žádný projektový kód 
 - `@HalForms` annotation + `Access` enum
 - `RootController` a navigace
 - `EntityModelWithDomain` + `ModelWithDomainPostprocessor`
-- `PatchField<T>` framework
+- `JsonNullable<T>` tri-state PATCH wrapper
 - `@ValidOptionalSize`
 - `MvcExceptionHandler` mapování výjimek na HTTP statusy
 - `HateoasConfiguration`, `MvcConfiguration`, `SpaFallbackController`, `@MvcComponent`

.claude/skills/developer-manual-maintainer/references/scope.md

@@ -19,7 +19,7 @@ Vše v `backend/src/main/java/com/klabis/common/` — celý package:
 - `common.mvc` — MvcExceptionHandler, MvcComponent, MvcConfiguration
 - `common.observability` — Custom metriky pro Modulith
 - `common.pagination` — TranslatedPageable
-- `common.patch` — PatchField, PatchFieldDeserializer
+- `common.patch` — JsonNullable wiring (JsonNullableConfiguration)
 - `common.ratelimit` — PerKeyRateLimiter
 - `common.security` (vč. `fieldsecurity`) — SecurityConfiguration, Authority, OwnerVisible, OwnerId, KlabisJwtAuthenticationToken, OwnershipResolver
 - `common.templating` — TemplateRenderer

.claude/skills/hal-navigator-patterns/references/component-api.md

@@ -200,7 +200,40 @@ Maps HAL-FORMS property types to React components:
 | boolean | HalFormsBoolean |
 | datetime | HalFormsDateTime |
 
-Extend with `expandHalFormsFieldFactory(customFactory)` to add custom field types.
+**Signature:** `halFormsFieldsFactory(fieldType: string, conf: HalFormsInputProps, customFactory?: CustomFieldFactory): ReactElement | null`
+
+Dispatch order for every call:
+1. **`multi` always wins first** — if `conf.prop` is multi-valued (and has no `options`/`suggest`), the property routes to `HalFormsCollectionField` unconditionally, before `customFactory` ever runs. `HalFormsCollectionField` then recurses per row (`multiple: false`) back through the same custom-aware factory.
+2. **`customFactory`** is consulted next — a custom type wins over any built-in default.
+3. **Built-in `switch`** on `fieldType` (the table above) as the final fallback.
+
+Because of step 1, a `CustomFieldFactory` only ever receives a **single-row** call for a multi-valued property — it never sees the array itself and does not need to special-case `isMultipleProperty` to avoid being called at the array level.
+
+**Important:** a custom type must never try to render its own multi-value UI by checking `isMultipleProperty` inside the `CustomFieldFactory` — step 1 already claimed the array before the factory runs, so that check will only ever see single-row calls and is dead code for the array case. If a custom type needs different behavior for the multi-valued case (e.g. `MemberId`/`UUID`, which used to render one combined checkbox-group for a multi-select), re-express it as a plain single-field component and let the standard `multi` → `HalFormsCollectionField` mechanism iterate it instead: the base `multi` branch routes the array to `HalFormsCollectionField`, which recurses per row (`multiple: false`) back into the same custom factory, landing on the same single-field component once per item — with add/remove handled generically. This trades one combined widget for N per-row rows, but requires no special exemption in the framework.
+
+**`fieldFactory` is not part of `HalFormsInputProps`.** It used to be threaded through `conf.fieldFactory` solely so `HalFormsCollectionField` could recurse into it; it is now an explicit component prop on `HalFormsCollectionField` (`<HalFormsCollectionField {...conf} fieldFactory={boundFactory(customFactory)} />`, an internal helper in `HalFormsFieldFactory.tsx`), set only in the `multi` branch above. Don't read or set `fieldFactory` off `HalFormsInputProps`/`conf` anywhere else — `HalFormsForm`'s `subElementProps` no longer carries it either.
+
+**Extending with custom field types:** use `expandHalFormsFieldFactory(customFactory: CustomFieldFactory): HalFormFieldFactory` — it binds your custom logic into `halFormsFieldsFactory`'s 3rd parameter and returns a normal `HalFormFieldFactory` (the shape `HalFormButton`/`HalFormDisplay`/`HalFormsForm` consumers expect, so call-sites don't change).
+
+```ts
+type CustomFieldFactory = (fieldType: string, conf: HalFormsInputProps) => ReactElement | null;
+
+const myCustomFactory: CustomFieldFactory = (fieldType, conf) => {
+    if (fieldType === 'MyCustomType') return <MyCustomField {...conf} />;
+    return null; // falls through to the next factory / built-ins
+};
+
+export const myFieldsFactory = expandHalFormsFieldFactory(myCustomFactory);
+```
+
+To compose several custom factories (e.g. a base factory plus feature-specific extras), chain them by falling through to the previous one instead of nesting `expandHalFormsFieldFactory` calls:
+
+```ts
+const combinedCustomFactory: CustomFieldFactory = (fieldType, conf) =>
+    myExtraCaseOrNull(fieldType, conf) ?? baseCustomFactory(fieldType, conf);
+
+export const combinedFieldsFactory = expandHalFormsFieldFactory(combinedCustomFactory);
+```
 
 ## HATEOAS Utility Functions