diff --git a/.claude/openspec/architecture/adr-001-data-layer.md b/.claude/openspec/architecture/adr-001-data-layer.md
new file mode 100644
index 00000000..6b52c806
--- /dev/null
+++ b/.claude/openspec/architecture/adr-001-data-layer.md
@@ -0,0 +1,221 @@
+- ALL domain data → OpenRegister objects. NO custom Entity/Mapper for domain data.
+- App config → `IAppConfig`. NOT OpenRegister.
+- Cross-entity references: OpenRegister relations (register+schema+objectId). NO foreign keys.
+  MUST NOT store foreign keys or embed full objects.
+
+### Schema standards
+
+- Schemas: PascalCase, schema.org vocabulary, explicit types + required flags + description field.
+- MUST NOT invent custom property names when a schema.org equivalent exists.
+- Contact schemas MUST align with vCard properties (fn, email, tel, adr).
+- Dutch government fields SHOULD use a mapping layer translating between international standards
+  and Dutch specs — do not hardcode Dutch field names as primary.
+- Schema changes that remove or rename properties are BREAKING. Adding optional properties is non-breaking.
+
+### Register templates
+
+- Location: `lib/Settings/{app}_register.json` (OpenAPI 3.0 + `x-openregister` extensions).
+- Three template categories:
+  - **App configuration** — define data models (schemas/registers/views/mappings).
+    Mark with `x-openregister.type: "application"`.
+  - **Mock data** — fictional but realistic seed data for dev/test.
+    Mark with `x-openregister.type: "mock"`.
+  - **Government standards** — aligned to Dutch API specs (BAG, BRP, KVK, DSO).
+- Import mechanism: `ConfigurationService::importFromApp(appId, data, version, force)` →
+  `ImportHandler::importFromApp()`. Called from repair step or `SettingsLoadService`.
+- Idempotency: re-importing with `force: false` MUST NOT create duplicates. Match by slug
+  using `ObjectService::searchObjects` with `_rbac: false` and `_multitenancy: false`.
+  Use `version_compare` for skip logic.
+
+### Seed data
+
+Apps that store data in OpenRegister are empty on first install. An empty app cannot be
+meaningfully tested — there are no objects to view, search, filter, or interact with.
+This blocks both automated browser testing and manual QA. The Loadable Register Template
+pattern (see Register templates above) already supports seed data via `components.objects[]`
+with the `@self` envelope.
+
+**Requirements:**
+
+- Every app using OpenRegister MUST include 3-5 realistic objects per schema in
+  `lib/Settings/{app}_register.json`.
+- Use `@self` envelope: `{ "@self": { "register": ..., "schema": ..., "slug": ... }, ...properties }`.
+  Register/schema MUST match keys; slug is unique human-readable identifier for matching.
+- Use general organisation data (municipality, consultancy, travel agency, non-profit) —
+  NOT context-specific. Varied, realistic field values.
+- Mock data quality: real Dutch street names, valid postcodes (`[1-9][0-9]{3}[A-Z]{2}`),
+  correct municipality/KVK codes, BSNs that pass 11-proef. Fictional but distinguishable from real.
+- Cross-register consistency: BRP→BAG, KVK→BAG, DSO→BAG references must be valid.
+- Loaded on install alongside schemas via same `importFromApp()` pipeline.
+- MUST be idempotent — re-importing skips existing objects matched by slug.
+
+**In OpenSpec artifacts:**
+
+- **In design.md**: MUST include a Seed Data section when change introduces/modifies schemas —
+  define seed objects per schema with concrete field values and related items (files, notes, tasks, contacts).
+- **In tasks.md**: MUST include a seed data generation task when change introduces/modifies schemas.
+
+**Exceptions** (no seed data required):
+
+- **nldesign** — has no OpenRegister schemas.
+- **ExApp sidecar wrappers** (openklant, opentalk, openzaak, valtimo, n8n-nextcloud) — proxy
+  external services and do not use OpenRegister.
+- **nextcloud-vue** — shared library, no seed data applicable.
+- Changes that only modify frontend components or non-schema backend logic (e.g., settings,
+  permissions) do not require seed data.
+
+**Limitations:** OpenRegister's `ImportHandler` currently supports only flat seed objects.
+Related items (files, notes, tasks, contacts) linked through the relation system are tracked
+on the product roadmap. Until then, seed data is limited to object properties defined in schemas.
+
+### Deduplication check
+
+- Before proposing new capability: search `openspec/specs/` and `openregister/lib/Service/` for overlap
+  with ObjectService, RegisterService, SchemaService, ConfigurationService, and shared Vue components.
+- If similar capability exists: MUST reference it and explain why new code is needed rather than extending.
+- Proposals duplicating existing functionality without justification MUST be rejected.
+- **In design.md**: MUST include a "Reuse Analysis" section listing existing OpenRegister services leveraged.
+- **In tasks.md**: MUST include a "Deduplication Check" task verifying no overlap — document findings
+  even if "no overlap found".
+
+### Schema migrations
+
+- Breaking schema changes → new migration in repair step. NEVER modify existing migrations.
+
+### OpenRegister + @conduction/nextcloud-vue — DO NOT REBUILD
+
+The platform provides 258+ backend methods and 69+ frontend components. Apps ONLY build
+custom logic for domain-specific business rules. Everything below is provided for FREE.
+
+**CRUD & Data Management** (use ObjectService + CnIndexPage + CnDetailPage):
+- Single & bulk create, read, update, delete — `ObjectService.saveObject()`, `deleteObject()`
+- List with pagination, sorting, filtering — `ObjectService.findAll()` + `CnDataTable`
+- Schema-driven forms — `CnFormDialog` (auto-generates from schema) or `CnAdvancedFormDialog`
+- Detail views — `CnDetailPage` with `CnDetailGrid`, `CnDetailCard` sections
+- Record merging/deduplication — `ObjectService.mergeObjects()`
+- Object locking — `ObjectService.lockObject()` / `unlockObject()`
+
+**Import & Export** (use ImportService/ExportService + CnMassImportDialog/CnMassExportDialog):
+- CSV, Excel, JSON import with intelligent field mapping — `ImportService`
+- CSV, Excel, JSON export with column selection — `ExportService`
+- Bulk import with validation and progress — `CnMassImportDialog`
+- Filtered export with format picker — `CnMassExportDialog`
+- NO custom import dialogs, parsers, upload handlers, or export controllers
+
+**Search & Discovery** (use IndexService + CnFilterBar + CnFacetSidebar):
+- Full-text search with field weighting — `IndexService`
+- Faceted navigation with counts — `FacetBuilder` + `CnFacetSidebar`
+- Semantic search with embeddings — `VectorizationService`
+- Hybrid search (keyword + semantic) — automatic
+- Search analytics — `SearchTrailService` (popular terms, activity)
+- NO custom search endpoints, query builders, or search pages
+
+**File Management** (use FileService + CnObjectSidebar):
+- Upload (single/multipart), download, share links — `FileService`
+- File tagging, public/private toggle — `FileService`
+- Bulk download as ZIP — `createObjectFilesZip()`
+- Text extraction from PDFs/Office docs — `TextExtractionService`
+- File tab in object sidebar — `CnObjectSidebar` → `CnFilesTab`
+- NO custom file upload components, file controllers, or download handlers
+
+**Audit & Compliance** (use AuditTrailService + CnObjectSidebar):
+- Full change tracking with before/after snapshots — automatic
+- Audit trail tab — `CnObjectSidebar` → `CnAuditTrailTab`
+- GDPR data subject access requests — `inzageverzoek()`, `verwerkingsregister()`
+- Audit export and analytics — `AuditTrailController`
+- NO custom audit logging, change tracking, or compliance controllers
+
+**Dashboard & Analytics** (use CnDashboardPage + CnChartWidget + CnStatsBlock):
+- Drag-drop widget dashboard — `CnDashboardPage` with GridStack
+- KPI cards — `CnKpiGrid`, `CnStatsBlock`, `CnStatsPanel`
+- Charts (line/bar/pie/donut) — `CnChartWidget` (ApexCharts)
+- Data tables as widgets — `CnTableWidget`
+- Editable data grids — `CnObjectDataWidget`
+- NO custom dashboard layouts, chart components, or KPI cards
+
+**Forms & Dialogs** (use CnFormDialog + schema-driven generation):
+- Auto-generated create/edit forms — `CnFormDialog` reads schema → generates fields
+- JSON/metadata editing — `CnAdvancedFormDialog` with Properties/Data/Metadata tabs
+- Schema editor — `CnSchemaFormDialog`
+- Delete/Copy/Mass operations — `CnDeleteDialog`, `CnCopyDialog`, `CnMassDeleteDialog`
+- NO custom form components, validation logic, or dialog wrappers
+
+**Navigation & Pagination** (use CnPagination + CnActionsBar + useListView):
+- Pagination control with size selector — `CnPagination`
+- Action bar (add, search, toggle views) — `CnActionsBar`
+- List state management — `useListView` composable (handles search, filter, sort, page)
+- Detail state management — `useDetailView` composable
+- NO custom pagination logic, debounced search, or list state management
+
+**Authorization & RBAC** (use AuthorizationService + PropertyRbacHandler):
+- Role-based access control — `AuthorizationService`
+- Field-level permissions — `PropertyRbacHandler`
+- Object-level restrictions — `PermissionHandler`
+- Authorization audit — `AuthorizationAuditService`
+- NO custom permission checks, role systems, or access control middleware
+
+**Webhooks & Events** (use WebhookService):
+- Create, test, retry webhooks — `WebhookService`
+- CloudEvents format — automatic
+- Event subscriptions — selective per schema/action
+- NO custom webhook controllers or event dispatchers
+
+**Notifications & Activity** (use NotificationService + ActivityService):
+- Nextcloud notifications — `NotificationService`
+- Activity feed — `ActivityService`
+- Calendar events — `CalendarEventService`
+- Deck/Kanban cards — `DeckCardService`
+
+**Store & State** (use createObjectStore + plugins):
+- Object stores — `createObjectStore(name)` generates Pinia CRUD store
+- Store plugins: `auditTrails`, `files`, `lifecycle`, `relations`, `search`, `selection`
+- Column/field/filter generation from schema — `columnsFromSchema()`, `fieldsFromSchema()`
+- NO custom Pinia stores for CRUD, Vuex, or manual API call management
+
+**Chat & AI** (use ChatService):
+- Multi-turn conversation — `ChatService`
+- RAG-based knowledge retrieval — `ContextRetrievalHandler`
+- LLM response generation — `ResponseGenerationHandler`
+
+**Data Retention & Archival** (use ArchivalService):
+- Legal hold — `LegalHoldService`
+- Destruction schedules — `DestructionService`
+- Retention policies — `RetentionService`
+
+**Semantic & Hybrid Search** (use SolrController + SettingsController):
+- Semantic search via vector embeddings — `SettingsController.semanticSearch()`
+- Hybrid search (keyword + semantic combined) — `SolrController.hybridSearch()`
+- Vector embedding generation — `VectorizationService`
+- NO custom search algorithms — configure via OpenRegister settings
+
+**GraphQL API** (use GraphQLController):
+- Query objects across schemas via GraphQL — `GraphQLController.execute()`
+- Alternative to REST for complex cross-entity queries
+
+**Organization / Multi-Tenancy** (use OrganisationController):
+- Organization CRUD — `OrganisationController`
+- Tenant-scoped data isolation — automatic via `TenantLifecycleService`
+- NO custom multi-tenancy logic
+
+**Task & Workflow Management** (use TasksController + WorkflowEngineController):
+- Task creation and tracking — `TasksController`
+- Workflow orchestration — `WorkflowEngineRegistry`
+- Scheduled workflows — `ScheduledWorkflowController`
+- NO custom task/workflow systems
+
+**Text Extraction** (use FileTextController):
+- Extract text from PDFs and Office docs — `TextExtractionService`
+- Entity recognition (PII detection) — `EntityRecognitionHandler`
+- Content anonymization — automatic
+
+**Timeline & Stages** (use CnTimelineStages):
+- Workflow progression visualization — `CnTimelineStages` component
+- Stage tracking with status colors
+
+### What apps SHOULD build (custom business logic only):
+- External API integrations (SAP, Peppol, TenderNed, etc.)
+- PDF/document generation with business-specific templates
+- Workflow triggers and business rules specific to the domain
+- Notification dispatch with app-specific event types
+- Custom settings pages with app-specific configuration
+- Background jobs for domain-specific processing
diff --git a/.claude/openspec/architecture/adr-002-api.md b/.claude/openspec/architecture/adr-002-api.md
new file mode 100644
index 00000000..4f956593
--- /dev/null
+++ b/.claude/openspec/architecture/adr-002-api.md
@@ -0,0 +1,6 @@
+- URL pattern: `/index.php/apps/{app}/api/{resource}` — lowercase plural, hyphens.
+- Methods: GET=read, POST=create, PUT=update, DELETE=remove. No custom methods.
+- Pagination: support `_page` + `_limit`. Response includes `total`, `page`, `pages`.
+- Errors: appropriate HTTP status + `message` field. NO stack traces in responses.
+- Auth: Nextcloud built-in only. NO custom login/session/token flows.
+- Public endpoints: annotate `#[PublicPage]` + `#[NoCSRFRequired]`. Register CORS OPTIONS route.
diff --git a/.claude/openspec/architecture/adr-003-backend.md b/.claude/openspec/architecture/adr-003-backend.md
new file mode 100644
index 00000000..82abe764
--- /dev/null
+++ b/.claude/openspec/architecture/adr-003-backend.md
@@ -0,0 +1,14 @@
+- **Controller → Service → Mapper** (strict 3-layer). Controllers NEVER call mappers directly.
+- Controllers: thin (<10 lines/method). Routing + validation + response only.
+- Services: ALL business logic. Stateless — no instance state between requests.
+- Mappers: DB CRUD only. No business logic.
+- DI: constructor injection with `private readonly`. NO `\OC::$server` or static locators.
+- Entity setters: POSITIONAL args only. `$e->setName('val')` — NEVER `$e->setName(name: 'val')`.
+  (`__call` passes `['name' => val]` but `setter()` uses `$args[0]`.)
+- Routes: `appinfo/routes.php`. Specific routes BEFORE wildcard `{slug}` routes.
+- Config: `IAppConfig` with sensitive flag for secrets. NEVER read DB directly.
+- Lifecycle: schema init via repair steps (`IRepairStep`), background via job queue, events via dispatcher.
+- **Spec traceability**: every class and public method MUST have `@spec` PHPDoc tag(s) linking to
+  the OpenSpec change that caused it: `@spec openspec/changes/{name}/tasks.md#task-N`.
+  Multiple `@spec` tags allowed (code touched by multiple changes). File-level `@spec` in header docblock.
+  This enables: code → docblock → spec traceability alongside code → git blame → commit → issue → spec.
diff --git a/.claude/openspec/architecture/adr-004-frontend.md b/.claude/openspec/architecture/adr-004-frontend.md
new file mode 100644
index 00000000..2484aa21
--- /dev/null
+++ b/.claude/openspec/architecture/adr-004-frontend.md
@@ -0,0 +1,129 @@
+- **Vue 2 + Pinia + @nextcloud/vue + @conduction/nextcloud-vue**. NO Vuex. Options API only.
+- State: Pinia stores in `src/store/modules/`. Use `createObjectStore` for OpenRegister CRUD.
+- API calls: `axios` from `@nextcloud/axios` — auto-attaches CSRF token. NEVER raw `fetch()` for mutations.
+  Loading state with `try/finally`.
+- Translations: ALL user-visible strings via `t(appName, 'text')`. NO hardcoded strings.
+  Translation keys MUST be English — Dutch translations go in `l10n/nl.json`.
+- CSS: ONLY Nextcloud CSS variables (`var(--color-primary-element)`, etc.). NO hardcoded colors.
+  NEVER reference `--nldesign-*` directly — nldesign app handles theming.
+- Router: history mode, base `generateUrl('/apps/{app}/')`. Requires matching PHP routes in `routes.php`.
+  Deep link URL templates MUST match the router mode — use path format (`/apps/{app}/entities/{uuid}`),
+  NOT hash format (`/apps/{app}/#/entities/{uuid}`).
+- OpenRegister dependency: settings returns `openRegisters` (bool) + `isAdmin`.
+  Show empty state if OR missing. NEVER use `OC.isAdmin` — get from backend.
+- NEVER `window.confirm()` or `window.alert()` — use `NcDialog` or `CnFormDialog` (WCAG, theming).
+- NEVER read app state from DOM (`document.getElementById`, `dataset`) — use backend API or store.
+- EVERY `await store.action()` call MUST be wrapped in `try/catch` with user-facing error feedback.
+- NEVER import from `@nextcloud/vue` directly — use `@conduction/nextcloud-vue` which re-exports all
+  NC components plus Conduction components. This ensures consistent theming and component versions.
+- EVERY component used in `<template>` MUST be imported AND registered in `components: {}`.
+  Vue 2 silently renders unknown elements — missing imports cause invisible runtime failures.
+
+### NL Design System
+
+- ALL UI components MUST use CSS custom properties from NL Design System tokens.
+- MUST support theme switching via nldesign app's token sets.
+- MUST meet WCAG AA compliance: keyboard-navigable, associated labels, color is not the sole
+  method of conveying information.
+- SHOULD work on 320px–1920px viewports; critical functionality MUST work at 768px (tablet).
+- Exceptions: PDF generation (docudesk), admin-only screens (simpler styling allowed).
+
+### @conduction/nextcloud-vue — ALWAYS check before building custom
+
+**Pages & Layout:**
+  `CnIndexPage` (schema-driven list+CRUD) | `CnDetailPage` (detail+sidebar) |
+  `CnPageHeader` (title+icon) | `CnActionsBar` (add+search+toggle)
+
+**Data Display:**
+  `CnDataTable` (sortable+paginated) | `CnCardGrid` + `CnObjectCard` (card views) |
+  `CnDetailGrid` (label-value pairs) | `CnFilterBar` (search+filters) |
+  `CnFacetSidebar` (faceted filters) | `CnPagination` | `CnCellRenderer` (type-aware)
+
+**Forms & Dialogs:**
+  `CnFormDialog` (schema-driven create/edit) | `CnAdvancedFormDialog` (properties+JSON+metadata) |
+  `CnSchemaFormDialog` (JSON Schema editor) | `CnTabbedFormDialog` (tabbed form framework) |
+  `CnDeleteDialog` | `CnCopyDialog`
+
+**Mass Actions:**
+  `CnMassDeleteDialog` | `CnMassCopyDialog` | `CnMassExportDialog` (CSV/JSON/XML) |
+  `CnMassImportDialog` (upload+summary) | `CnMassActionBar` (floating selection bar)
+
+**Dashboard & Widgets:**
+  `CnDashboardPage` (GridStack drag-drop layout) | `CnDashboardGrid` (layout engine) |
+  `CnWidgetWrapper` (widget shell) | `CnWidgetRenderer` (NC Dashboard API v1/v2) |
+  `CnChartWidget` (ApexCharts: area/line/bar/pie/donut/radial) |
+  `CnTableWidget` (data table widget) | `CnTileWidget` (quick-access tile) |
+  `CnInfoWidget` (label-value grid) | `CnKpiGrid` (responsive KPI layout) |
+  `CnStatsBlock` (metric card) | `CnStatsPanel` (stats sections) | `CnProgressBar` |
+  `CnObjectDataWidget` (schema-driven editable data grid, inline edit + save via objectStore) |
+  `CnObjectMetadataWidget` (read-only object metadata display)
+
+**UI Elements:**
+  `CnStatusBadge` | `CnEmptyState` | `CnIcon` (MDI) | `CnCard` | `CnDetailCard` |
+  `CnRowActions` | `CnTimelineStages` (workflow progression) |
+  `CnUserActionMenu` (user context menu) | `CnJsonViewer` (CodeMirror)
+
+**Detail Sidebar:**
+  `CnObjectSidebar` (Files/Notes/Tags/Tasks/Audit tabs) | `CnIndexSidebar` |
+  `CnNotesCard` (inline notes) | `CnTasksCard` (inline tasks)
+
+**Settings:**
+  `CnSettingsSection` + `CnVersionInfoCard` (MUST be first on admin pages) |
+  `CnSettingsCard` | `CnConfigurationCard` | `CnRegisterMapping`
+  User settings: `NcAppSettingsDialog` (NOT `NcDialog`)
+
+**Composables:**
+  `useListView` (search/filter/sort/pagination) | `useDetailView` (load/edit/delete) |
+  `useSubResource` (related items) | `useDashboardView` (widgets/layout/edit)
+
+**Store Plugins:**
+  `auditTrailsPlugin` | `relationsPlugin` | `filesPlugin` | `lifecyclePlugin` |
+  `selectionPlugin` | `searchPlugin` | `registerMappingPlugin`
+
+**Utilities:**
+  `columnsFromSchema()` | `filtersFromSchema()` | `fieldsFromSchema()` |
+  `formatValue()` | `buildHeaders()` | `buildQueryString()`
+
+### Page Construction Patterns (follow these recipes)
+
+**App.vue:** `NcContent` → 3 states: loading (`NcLoadingIcon`), no-OpenRegister (`NcEmptyContent`),
+  ready (`MainMenu` + `NcAppContent` + `router-view` + optional `CnIndexSidebar`).
+  Inject `sidebarState` for child components. `created()` calls `initializeStores()`.
+
+**MainMenu:** `NcAppNavigation` with `NcAppNavigationItem` per route (icon + name + `:to`).
+  Footer: `NcAppNavigationSettings` (gear foldout) with admin/config nav items.
+  Settings item emits `@click="$emit('open-settings')"` — opens `NcAppSettingsDialog` modal.
+  Do NOT route to `/settings` — in-app settings is a modal overlay, not a page.
+
+**Dashboard:** `CnDashboardPage` with `CnStatsBlock` KPIs (4 cards: open/overdue/value/completed),
+  status distribution chart, "My Work" list (grouped: overdue → due this week → rest).
+  Fetch all collections in parallel via `Promise.all`. Widget templates via `#widget-{id}` slots.
+
+**Index page:** `CnIndexPage` with `useListView(entityType, { sidebarState, objectStore })`.
+  Inject sidebarState. Row click → `$router.push({ name: 'EntityDetail', params: { id } })`.
+  Add button → new entity detail with id='new'.
+
+**Detail page:** Two modes — edit (form component) / view (`CnDetailPage` + `CnDetailCard` sections).
+  Header actions: Edit + Delete buttons. Related entities in table inside `CnDetailCard`.
+  Props: `entityId` from route. `isNew = entityId === 'new'`. Sidebar via `CnObjectSidebar`.
+  **Relations:** Every entity referenced in the spec MUST have a `CnDetailCard` section.
+  Use `fetchUsed` for reverse lookups (find objects that reference THIS entity) and
+  `fetchUses` for forward lookups (find objects THIS entity references).
+  If the spec lists a "linked X section", it MUST be implemented — not deferred or stubbed.
+
+**Settings — two surfaces, never a route:**
+  *Admin settings* (`/settings/admin/{appid}`): `AdminRoot.vue` rendered by `settings.js` entry point,
+  registered via `AdminSettings.php`. Layout: `CnVersionInfoCard` (FIRST) → `CnRegisterMapping` →
+  `CnSettingsSection` per feature. Load via `GET /api/settings`, save via `POST /api/settings`.
+  *In-app settings*: `UserSettings.vue` wrapping `NcAppSettingsDialog` — opened as a modal from the
+  gear menu (`@open-settings` event on MainMenu), handled in `App.vue` with `:open` / `@update:open`.
+  Do NOT create a `/settings` route. Do NOT create a standalone `SettingsView.vue` page component.
+
+**Router:** Flat routes (no nesting), all named, props via arrow function for params.
+  Routes: `/` (Dashboard), `/{entities}` (list), `/{entities}/:id` (detail).
+  No `/settings` route — settings is a modal (see Settings section above).
+
+**Store init:** `initializeStores()` in `store/store.js` — fetches settings, then calls
+  `objectStore.registerObjectType(name, schemaSlug, registerSlug)` for each entity.
+  Object store uses `createObjectStore` with plugins (files, auditTrails, relations).
+  Settings store: Pinia `defineStore` with `fetchSettings()` and `saveSettings()`.
diff --git a/.claude/openspec/architecture/adr-005-security.md b/.claude/openspec/architecture/adr-005-security.md
new file mode 100644
index 00000000..20674cff
--- /dev/null
+++ b/.claude/openspec/architecture/adr-005-security.md
@@ -0,0 +1,9 @@
+- Auth: Nextcloud built-in ONLY. NO custom login, sessions, tokens, password storage.
+- Admin check: `IGroupManager::isAdmin()` on BACKEND. Frontend-only checks = vulnerability.
+- Multi-tenant isolation: enforce at API/service level, not UI only.
+- NO PII in logs, error responses, or debug output.
+- Audit trails: use `$user->getUID()` — NEVER `$user->getDisplayName()` (mutable, spoofable).
+- Identity: always derive from `IUserSession` on backend — NEVER trust frontend-sent user IDs or display names.
+- File uploads: validate type + size before storage.
+- API responses: NO stack traces, SQL, or internal paths.
+- Test collections: NEVER commit default credentials — use env variable placeholders.
diff --git a/.claude/openspec/architecture/adr-006-metrics.md b/.claude/openspec/architecture/adr-006-metrics.md
new file mode 100644
index 00000000..58a9bf8e
--- /dev/null
+++ b/.claude/openspec/architecture/adr-006-metrics.md
@@ -0,0 +1,3 @@
+- Every app: `GET /api/metrics` (Prometheus text, admin auth) + `GET /api/health` (JSON, public).
+- Metric names: `{app}_` prefix. MUST include `{app}_health_status` and `{app}_info`.
+- Health check MUST verify OpenRegister connectivity (for apps that depend on it).
diff --git a/.claude/openspec/architecture/adr-007-i18n.md b/.claude/openspec/architecture/adr-007-i18n.md
new file mode 100644
index 00000000..a27210e9
--- /dev/null
+++ b/.claude/openspec/architecture/adr-007-i18n.md
@@ -0,0 +1,40 @@
+# ADR-007: Internationalization (i18n)
+
+## Status
+Accepted
+
+## Context
+All Conduction Nextcloud apps serve Dutch government users but must support multiple languages. We need a consistent approach to internationalization across all apps.
+
+## Decision
+
+### Primary Language: English
+- **English (en) is the source/primary language** for all code and translation keys.
+- All `t()` keys and `$this->l10n->t()` strings MUST be written in English.
+- `l10n/en.json` is the identity-mapped source file (key == value).
+- Hardcoded Dutch strings in code MUST be converted to English keys with Dutch translations in `nl.json`.
+
+### Required Languages
+- Minimum: English (en) + Dutch (nl) translations.
+- `l10n/en.json` and `l10n/nl.json` MUST exist in every app with a UI.
+- Both files MUST contain exactly the same keys, with zero gaps.
+
+### Frontend Translation
+- JS: `t(appName, 'key')` for singular, `n(appName, 'singular', 'plural', count)` for plurals.
+- `Vue.mixin({ methods: { t, n } })` for Options API components.
+- `<script setup>` components MUST import `t` directly from `@nextcloud/l10n` (mixin does not apply).
+
+### Backend Translation
+- PHP: `$this->l10n->t('key')` for user-facing messages in JSONResponse.
+- Controllers returning user-facing messages MUST inject `OCP\IL10N`.
+- Log messages, internal exceptions, and database values are NOT translated.
+
+### API and Data
+- API field names: always English (language-neutral data layer).
+- Date/number formatting: respect user locale via Nextcloud core.
+- Each app with OpenRegister: define `register-i18n` spec listing translatable fields.
+
+## Consequences
+- All apps maintain two translation files that must stay in sync.
+- Dutch strings used as translation keys (e.g., `t('app', 'Besluiten')`) are a violation — the English equivalent must be the key.
+- New features must include both `en.json` and `nl.json` entries before merging.
diff --git a/.claude/openspec/architecture/adr-008-testing.md b/.claude/openspec/architecture/adr-008-testing.md
new file mode 100644
index 00000000..e057572c
--- /dev/null
+++ b/.claude/openspec/architecture/adr-008-testing.md
@@ -0,0 +1,24 @@
+- Every new PHP service/controller → PHPUnit tests in `tests/Unit/` (≥3 methods).
+- Every new Vue component → test file (if test framework exists).
+- Every new API endpoint → Newman/Postman collection in `tests/integration/`.
+- Every spec scenario → browser test (GIVEN/WHEN/THEN verified via Playwright).
+- All tests MUST pass in `composer check:strict`.
+- Integration tests MUST cover error paths (403, 401, 400) — not just happy path (200).
+- Test collections: use env variable placeholders for credentials — NEVER hardcode defaults.
+
+### Smoke testing (before opening PR)
+
+After implementing, verify your code actually works — quality gates catch lint/types, not logic:
+
+1. Call each new API endpoint with `curl` — verify response shape and status code
+2. Test at least one error path per endpoint (missing param, wrong auth, invalid input)
+3. If the spec says a feature is deferred, verify it is NOT registered/enabled
+4. If tasks.md marks a task `[x]`, verify it is fully implemented — not a stub or TODO
+
+### Task completeness verification
+
+Before marking a task `[x]` in tasks.md or opening a PR:
+- Re-read every task in tasks.md
+- For each `[x]` task, verify the implementation exists AND works — not a placeholder
+- Stub components, empty relation sections, and TODO comments are NOT complete
+- If a task cannot be completed, leave it `[ ]` and explain in the PR description
diff --git a/.claude/openspec/architecture/adr-009-docs.md b/.claude/openspec/architecture/adr-009-docs.md
new file mode 100644
index 00000000..372cfacf
--- /dev/null
+++ b/.claude/openspec/architecture/adr-009-docs.md
@@ -0,0 +1,2 @@
+- Every user-facing feature → docs in `docs/` with screenshots from running app.
+- English primary, Dutch recommended. Update docs when behavior changes.
diff --git a/.claude/openspec/architecture/adr-010-nl-design.md b/.claude/openspec/architecture/adr-010-nl-design.md
new file mode 100644
index 00000000..6f0450d5
--- /dev/null
+++ b/.claude/openspec/architecture/adr-010-nl-design.md
@@ -0,0 +1,8 @@
+- ALL UI: CSS custom properties from NL Design System tokens. NO hardcoded colors, fonts, spacing.
+- Theme switching: support `nldesign` app's token sets (Rijkshuisstijl, Utrecht, municipality-specific).
+- Components: `@nextcloud/vue` primary. Custom components styled via NL Design tokens only.
+- Scoped styles: ALL `<style>` blocks MUST use `scoped` attribute.
+- WCAG AA mandatory: keyboard-navigable, labelled forms, color not sole conveyor, alt text on images.
+- Responsive: work from 320px to 1920px. Critical features accessible at 768px.
+- Specs: reference token names ("primary action color") NOT hex values. Include a11y verification in ACs.
+- Exception: PDF generation (docudesk) may use fixed dimensions. Admin screens MAY simplify but MUST meet WCAG AA.
diff --git a/.claude/openspec/architecture/adr-011-schema-standards.md b/.claude/openspec/architecture/adr-011-schema-standards.md
new file mode 100644
index 00000000..0125ef17
--- /dev/null
+++ b/.claude/openspec/architecture/adr-011-schema-standards.md
@@ -0,0 +1,8 @@
+- schema.org types/properties as primary vocabulary (`schema:Person`, `schema:Organization`, `schema:Event`).
+- Contact schemas: align with vCard properties (`fn`, `email`, `tel`, `adr`).
+- Dutch government fields: mapping layer translating between international standards and Dutch APIs (VNG, ZGW).
+- NO custom property names when schema.org equivalent exists.
+- Relations: OpenRegister relation mechanism (register + schema + objectId). NO foreign keys or embedded objects.
+- Versioning: removing/renaming properties = BREAKING → migration via repair step. Adding optional = non-breaking.
+- Specs MUST define data models using schema.org vocabulary; design docs MUST include schema definitions with types, required flags, relations.
+- Exception: app-specific workflow states (pipeline stages, process statuses) MAY use custom vocabularies.
diff --git a/.claude/openspec/architecture/adr-012-deduplication.md b/.claude/openspec/architecture/adr-012-deduplication.md
new file mode 100644
index 00000000..d069cdd8
--- /dev/null
+++ b/.claude/openspec/architecture/adr-012-deduplication.md
@@ -0,0 +1,7 @@
+- Before proposing new capability: search OpenRegister specs + services for overlap. Reference + justify if similar exists.
+- Design docs MUST include "Reuse Analysis" listing which OpenRegister services are leveraged.
+- If logic could benefit other apps → propose adding to OpenRegister core, not app-specific.
+- Tasks MUST include "Deduplication Check" verifying no overlap with:
+  ObjectService, RegisterService, SchemaService, ConfigurationService, shared specs, @conduction/nextcloud-vue.
+- Document findings even if "no overlap found".
+- Exception: OpenRegister checks internal duplication only. nldesign checks token sets. nextcloud-vue checks own components.
diff --git a/.claude/openspec/architecture/adr-013-container-pool.md b/.claude/openspec/architecture/adr-013-container-pool.md
new file mode 100644
index 00000000..43341ef7
--- /dev/null
+++ b/.claude/openspec/architecture/adr-013-container-pool.md
@@ -0,0 +1,133 @@
+# ADR-013: Unified Container Pool
+
+**Status:** accepted
+**Date:** 2026-04-12
+
+## Context
+
+Specter (intelligence/research) and Hydra (build/review/merge) both run LLM workloads in Docker containers. Today they operate independently: Hydra spins up builder/reviewer/security containers on demand, Specter has a separate `run_llm_containers.sh` wrapper. Both compete for the same Claude Max rate limits.
+
+We want to unify these into a **single priority-scheduled container pool** so that:
+- Critical work (bugfixes, reviews) preempts lower-priority work (discovery, research)
+- A fixed number of containers (e.g. 10) run continuously, pulling from a shared queue
+- Token rotation and rate limit recovery happen at the pool level, not per-script
+- Adding a new workload type (audit, spec generation, test) is just a new queue entry
+
+## Decision
+
+### Container types (priority order)
+
+| Priority | Type | Source | Container image | Model |
+|----------|------|--------|-----------------|-------|
+| 1 | **bugfix** | Hydra: fix iteration after review failure | `hydra-builder` | sonnet |
+| 2 | **code-review** | Hydra: PR code review | `hydra-reviewer` | sonnet |
+| 3 | **security-review** | Hydra: PR security review | `hydra-security` | sonnet |
+| 4 | **build** | Hydra: initial spec build | `hydra-builder` | sonnet |
+| 5 | **audit** | Hydra: codebase audit | `hydra-builder` | sonnet |
+| 6 | **spec-generation** | Specter: push_spec_pipeline | `specter-llm-worker` | sonnet |
+| 7 | **schema-synthesis** | Specter: generate/dedup schemas | `specter-llm-worker` | haiku |
+| 8 | **classification** | Specter: classify/redistribute features | `specter-llm-worker` | haiku |
+| 9 | **translation** | Specter: translate requirements | `specter-llm-worker` | haiku |
+| 10 | **discovery** | Specter: research, feature extraction | `specter-llm-worker` | haiku |
+
+### Architecture
+
+```
+┌─────────────────────────────────────────────────────┐
+│  Scheduler (cron or daemon)                         │
+│                                                     │
+│  reads: queue table (postgres)                      │
+│  writes: container assignments, status updates      │
+│                                                     │
+│  ┌──────────────────────────────────────────┐       │
+│  │ Pool: 10 container slots                 │       │
+│  │                                          │       │
+│  │  slot-1: [bugfix]     ← highest prio     │       │
+│  │  slot-2: [code-review]                   │       │
+│  │  slot-3: [build]                         │       │
+│  │  slot-4: [build]                         │       │
+│  │  slot-5: [classify]                      │       │
+│  │  slot-6: [classify]                      │       │
+│  │  slot-7: [translate]                     │       │
+│  │  slot-8: [discovery]                     │       │
+│  │  slot-9: [idle]       ← waiting for work │       │
+│  │  slot-10: [idle]                         │       │
+│  └──────────────────────────────────────────┘       │
+│                                                     │
+│  Token rotation: credentials.json (work → private)  │
+│  Rate limit: pool-level tracking per account        │
+│  Preemption: low-prio containers stopped when       │
+│              high-prio work arrives and pool is full │
+└─────────────────────────────────────────────────────┘
+```
+
+### Queue table (future)
+
+```sql
+CREATE TABLE container_queue (
+    id SERIAL PRIMARY KEY,
+    type VARCHAR(50) NOT NULL,        -- bugfix, code-review, build, classify, etc.
+    priority INTEGER NOT NULL,         -- 1=highest
+    payload JSONB NOT NULL,            -- script args, spec slug, issue URL, etc.
+    status VARCHAR(20) DEFAULT 'pending', -- pending, running, completed, failed
+    container_id VARCHAR(100),         -- docker container name when running
+    token_account VARCHAR(50),         -- which OAuth account is assigned
+    created_at TIMESTAMP DEFAULT NOW(),
+    started_at TIMESTAMP,
+    completed_at TIMESTAMP,
+    exit_code INTEGER,
+    error_message TEXT
+);
+```
+
+### Phased rollout
+
+**Phase 1 (now):** All LLM calls containerized. Specter scripts run via `run_llm_containers.sh`. Hydra containers use `run_container_with_fallback`. Both read from `credentials.json`. No shared queue yet — each system schedules its own containers.
+
+**Phase 2:** Shared queue table. A single scheduler script replaces both `cron-hydra.sh` dispatch and `run_llm_containers.sh`. Pool size configurable. Priority enforcement by not starting low-prio work when high-prio is queued.
+
+**Phase 3:** Preemption. Running low-priority containers can be stopped (gracefully, with checkpoint) when high-priority work arrives and all slots are occupied. Container images support checkpoint/resume via DB state.
+
+### Current state (Phase 1)
+
+**Container images:**
+
+| Image | Size | Purpose |
+|-------|------|---------|
+| `conduction/nextcloud-test:stable31` | 1.5GB | Prebuild NC server + PostgreSQL + OpenRegister (cloned) |
+| `hydra-builder:latest` | 1.9GB | Code implementation: NC test env + Claude CLI + PHP + skills |
+| `hydra-reviewer:latest` | 1.3GB | Code review: Claude CLI + review skills |
+| `hydra-security:latest` | 1.9GB | Security review: Claude CLI + Semgrep + security skills |
+| `specter-spec-writer:latest` | ~800MB | Spec generation: Claude CLI + openspec CLI + skills (no PHP) |
+| `specter-llm-worker:latest` | ~500MB | Intelligence pipeline: Claude CLI + DB access |
+
+**Credential separation:**
+- **Specter:** `concurrentie-analyse/secrets/credentials.json` (work + private tokens)
+- **Hydra:** `hydra/secrets/credentials.json` (work token only)
+
+**Token detection:**
+- Container mode: uses exit code (0 = success, non-zero checks output for rate limit)
+- Local mode: checks output text for "rate limit" / "auth failed" strings
+
+**NC test environment:**
+- Prebuild image with PostgreSQL (matches production, not SQLite)
+- Builder `COPY --from=conduction/nextcloud-test` at build time
+- Entrypoint starts PG + enables OpenRegister at runtime
+- Each container gets its own isolated NC+PG instance
+
+**Spec generation flow:**
+- `push_spec_pipeline.py` prepares repos in parallel, generates in `specter-spec-writer` containers
+- Each spec gets its own container + clone (compartmentalized)
+- Dependency tiers control ordering: Phase 1 → Phase 2 → Phase 3 → Phase 4
+- Specs with met deps push to development directly (doc-only merge guard)
+- Issues created with `yolo` label → Hydra auto-builds, reviews, merges, closes issue
+
+## Consequences
+
+- All LLM calls go through containers — no direct `claude -p` from host scripts
+- Token management is centralized per system (Specter has private fallback, Hydra doesn't)
+- Container exit code determines token rotation (not mid-session JSONL text)
+- Prebuild NC image eliminates 30-60s clone overhead per builder container
+- Container images are the unit of deployment — version, test, rollback independently
+- ADR-000 convention: every repo's data model is at `openspec/architecture/adr-000-data-model.md`
+- `context-brief.md` in each change directory carries intelligence data through the full pipeline
diff --git a/.claude/openspec/architecture/adr-014-licensing.md b/.claude/openspec/architecture/adr-014-licensing.md
new file mode 100644
index 00000000..c470005c
--- /dev/null
+++ b/.claude/openspec/architecture/adr-014-licensing.md
@@ -0,0 +1,7 @@
+- Licence: EUPL-1.2 (European Union Public Licence). SPDX header on every source file.
+- `appinfo/info.xml`: MUST use `<licence>agpl</licence>` — Nextcloud app store does not recognise EUPL.
+- This is intentional dual-tagging, NOT a conflict. Do NOT change info.xml to eupl. Do NOT flag as review finding.
+- PHP: `// SPDX-License-Identifier: EUPL-1.2` after `<?php` opening tag.
+- Vue: `<!-- SPDX-License-Identifier: EUPL-1.2 -->` as first line.
+- JS: `// SPDX-License-Identifier: EUPL-1.2` as first line.
+- File header block: `@licence EUPL-1.2`, `@copyright {year} Conduction B.V.`, `@link https://conduction.nl`
diff --git a/.claude/openspec/architecture/adr-015-common-patterns.md b/.claude/openspec/architecture/adr-015-common-patterns.md
new file mode 100644
index 00000000..06718121
--- /dev/null
+++ b/.claude/openspec/architecture/adr-015-common-patterns.md
@@ -0,0 +1,98 @@
+- Common Conduction patterns. These apply to ALL apps. Every item below was found 3+ times
+  across multiple code reviews. Get these right during implementation — not after review.
+- When fixing any pattern violation, ALWAYS generalize: grep for the same issue across ALL
+  files and fix every instance in one pass. Fixing one file while leaving the same issue in
+  nine others guarantees another review round.
+
+### OpenRegister ObjectService API
+- `findObject($register, $schema, $id)` — 3 positional args, register first
+- `findObjects($register, $schema, $params)` — 3 positional args, $params is filter array
+- `saveObject($register, $schema, $object)` — 3 positional args, $object is array
+- NEVER `getObject($id)` or `saveObject($data)` — those 1-arg signatures do not exist
+- When unsure, check the OpenRegister source or existing app code
+
+### Store registration (Vue/Pinia)
+- Register each entity type ONCE in `src/store/store.js` via `createObjectStore`
+- NEVER register in both `OBJECT_TYPES` and `ENTITY_STORES` — pick one pattern
+- Type names: kebab-case (`action-item`), NOT camelCase (`actionItem`)
+- Use platform `createObjectStore` — do NOT build custom stores (hand-rolled object.js)
+
+### Authorization enforcement
+- ALL mutation endpoints MUST have `IGroupManager::isAdmin()` check on backend
+- Settings endpoints: `#[AuthorizedAdminSetting]` or `@RequireAdmin` annotation
+- NEVER rely on frontend-only auth — always enforce on backend
+- User identity: derive from `IUserSession` — NEVER trust frontend-sent user IDs
+- Null dependency checks: throw 503, do NOT silently return empty response
+
+### Error responses
+- NEVER return `$e->getMessage()` to API — use static, generic error messages
+- Pattern: `catch (\Throwable $e) { return new JSONResponse(['message' => 'Operation failed'], 500); }`
+- Log the real error: `$this->logger->error('Context', ['exception' => $e]);`
+- Frontend: EVERY `await store.action()` MUST be in `try/catch` with user feedback
+
+### API calls & CSRF
+- Use `axios` from `@nextcloud/axios` for ALL API calls — it auto-attaches the CSRF token
+- NEVER use raw `fetch()` for mutations — missing requesttoken causes silent 403 failures
+- Pattern: `import axios from '@nextcloud/axios'` + `const { data } = await axios.post(url, payload)`
+
+### Vue component imports
+- NEVER import from `@nextcloud/vue` directly — use `@conduction/nextcloud-vue` which re-exports everything
+- EVERY component used in `<template>` MUST be imported AND listed in `components: {}`
+- Vue 2 silently renders unknown elements — a missing import = invisible runtime failure
+- Pre-commit check: for every `<NcFoo>` or `<CnFoo>` in template, verify the import exists
+
+### SPDX headers (see also ADR-014)
+- EVERY new file needs an SPDX header — apply to ALL new files in one pass
+- PHP: `// SPDX-License-Identifier: EUPL-1.2` after `<?php`
+- Vue: `<!-- SPDX-License-Identifier: EUPL-1.2 -->` as first line
+- JS: `// SPDX-License-Identifier: EUPL-1.2` as first line
+
+### Dependency management
+- When importing from a package, verify it exists in `package.json` before committing
+- `@nextcloud/auth` for `getRequestToken()` — add to dependencies if missing
+- Run `npm ci && npm run lint` to catch `n/no-extraneous-import` BEFORE pushing
+
+### Translations (i18n)
+- ALL user-visible strings: `this.t('appid', 'text')` in Vue, `$this->l->t('text')` in PHP
+- NEVER hardcode Dutch or English strings in templates, CSV headers, or notifications
+- NEVER bare `t()` in Vue — always `this.t()` (Options API)
+
+### Data patterns
+- Relations: verify `fetchUsed` vs `fetchUses` direction — wrong direction = empty cards
+- Lifecycle: use the service's `transitionLifecycle()` — NEVER `saveObject()` directly for status
+- Pagination: `_limit: 999` silently undercounts — use proper pagination or document the cap
+
+### Nextcloud UI patterns
+- NEVER `window.confirm()` or `window.alert()` — use `NcDialog` or `CnFormDialog`
+- NEVER read app state from DOM (`document.getElementById`, `dataset`) — use backend API
+- Audit trails: use `$user->getUID()` — NEVER `$user->getDisplayName()` (mutable, spoofable)
+- Deferred features: if spec says "defer to phase N", do NOT register/enable them in info.xml or anywhere else
+- Router: history mode with `generateUrl` base (see ADR-004). Deep link URLs must use path format, NOT hash format.
+- Relations: `fetchUsed` = reverse lookup (who references me), `fetchUses` = forward lookup (what do I reference)
+- Detail views: every spec-required "linked X section" MUST have a `CnDetailCard` — never stub or omit
+
+### Pre-commit verification (run before EVERY commit)
+
+Before committing, verify your code against these patterns:
+
+1. **SPDX headers**: `grep -rL 'SPDX-License-Identifier' src/ lib/ --include='*.php' --include='*.vue' --include='*.js'`
+   → Add headers to EVERY file missing one — all of them, not just one.
+2. **ObjectService calls**: `grep -rn 'findObject\|saveObject\|findObjects' lib/ --include='*.php'`
+   → Verify every call has 3 positional args: `($register, $schema, $idOrParams)`
+3. **Error responses**: `grep -rn 'getMessage()' lib/Controller/ --include='*.php'`
+   → Replace any `$e->getMessage()` in JSONResponse with a static error string
+4. **Auth checks**: For every POST/PUT/DELETE controller method, verify `IGroupManager::isAdmin()` is called
+5. **Store registration**: `grep -rn 'registerObjectType\|OBJECT_TYPES\|ENTITY_STORES' src/`
+   → Verify each entity registered exactly once, kebab-case names
+6. **Dependencies**: `npm run lint` — catches missing package.json entries
+7. **Translations**: `grep -rn "'" src/ --include='*.vue' | grep -v "this\.t\|import\|//\|console"` — scan for hardcoded strings
+8. **try/catch**: `grep -rn 'await.*Store\.' src/ --include='*.vue'` — verify every store call is wrapped
+9. **No raw fetch**: `grep -rn 'fetch(' src/ --include='*.vue' --include='*.js'` — must use `@nextcloud/axios`, not raw fetch (CSRF)
+10. **Import source**: `grep -rn "from '@nextcloud/vue'" src/` — must be zero matches. Use `@conduction/nextcloud-vue` instead.
+11. **Component imports**: for every `<NcFoo>` or `<CnFoo>` in templates, verify the component is imported AND in `components: {}`
+12. **Type slug consistency**: verify every entity type string across ALL files (store, search, routes, views) uses the same kebab-case slug — `grep -rn "agendaItem\|governanceBody\|actionItem" src/` should return zero matches
+13. **Translation keys**: `grep -rn "t('.*'," src/ --include='*.vue' --include='*.js'` — verify ALL t() keys are English, not Dutch. Dutch translations go in `l10n/nl.json`.
+14. **Route consistency**: verify every entity type referenced in search, navigation, or links has a matching named route in `src/router/`
+15. **Task completeness**: re-read tasks.md — every `[x]` task must be fully implemented, not a stub
+
+If ANY check fails, fix ALL instances (not just the first one) before committing.
diff --git a/.claude/openspec/architecture/adr-017-component-composition.md b/.claude/openspec/architecture/adr-017-component-composition.md
new file mode 100644
index 00000000..542b0650
--- /dev/null
+++ b/.claude/openspec/architecture/adr-017-component-composition.md
@@ -0,0 +1,86 @@
+# ADR-017: Component Composition Rules
+
+## Status
+Accepted
+
+## Date
+2026-04-14
+
+## Context
+
+Conduction apps share a Vue component library (`@conduction/nextcloud-vue`) that provides self-contained, higher-level components like `CnObjectDataWidget`, `CnStatsPanel`, `CnDetailPage`, and `CnTimelineStages`. These components internally render their own card wrappers (`CnDetailCard`), headers, and layout containers.
+
+Developers have been wrapping these self-contained components inside additional layout containers (e.g. `CnDetailCard` wrapping `CnObjectDataWidget`), producing a "card-in-card" visual artifact where headers and borders are doubled. This was found across Procest, Pipelinq, and earlier OpenCatalogi iterations.
+
+The same principle applies to `CnDetailPage` which renders its own `NcAppContent` wrapper — apps must not add another `NcAppContent` around it.
+
+## Decision
+
+### Self-contained components render their own container
+
+The following components are **self-contained** and MUST NOT be wrapped in `CnDetailCard`, `NcAppContent`, or other layout containers:
+
+| Component | Renders its own | Use directly inside |
+|---|---|---|
+| `CnObjectDataWidget` | `CnDetailCard` | `CnDetailPage` slot, `<div>`, or grid cell |
+| `CnObjectMetadataWidget` | `CnDetailCard` | `CnDetailPage` slot, `<div>`, or grid cell |
+| `CnStatsPanel` | Sections with headers | `CnDetailPage` slot or `<div>` |
+| `CnDetailPage` | `NcAppContent`-level layout | Directly in `<router-view>` |
+| `CnDashboardPage` | `NcAppContent`-level layout | Directly in `<router-view>` |
+| `CnIndexPage` | `NcAppContent`-level layout | Directly in `<router-view>` |
+| `CnTimelineStages` | Standalone timeline | Inside `CnDetailCard` or any container (no own card) |
+
+### How to identify self-contained components
+
+A component is self-contained if its template root is a card, panel, or page-level wrapper. Check the component source: if it starts with `<CnDetailCard>`, `<div class="cn-*-card">`, or similar, it manages its own container.
+
+### Correct patterns
+
+```vue
+<!-- CORRECT: CnObjectDataWidget renders its own card -->
+<CnObjectDataWidget
+  :schema="schema"
+  :object-data="data"
+  title="Case Information" />
+
+<!-- CORRECT: CnTimelineStages is NOT self-contained, wrap it -->
+<CnDetailCard :title="t('app', 'Status')">
+  <CnTimelineStages :stages="stages" :current-stage="current" />
+</CnDetailCard>
+```
+
+### Anti-patterns
+
+```vue
+<!-- WRONG: Double card wrapping -->
+<CnDetailCard :title="t('app', 'Case Information')">
+  <CnObjectDataWidget :schema="schema" :object-data="data" />
+</CnDetailCard>
+
+<!-- WRONG: Double page wrapping -->
+<NcAppContent>
+  <CnDetailPage :title="title">...</CnDetailPage>
+</NcAppContent>
+```
+
+### External sidebar pattern
+
+Components like `CnDetailPage` that support sidebars communicate with a parent-provided `objectSidebarState` via Vue's `provide`/`inject`. The sidebar component (`CnObjectSidebar`) MUST be rendered at the `NcContent` level in `App.vue`, NOT inside `NcAppContent`:
+
+```vue
+<!-- App.vue -->
+<NcContent app-name="myapp">
+  <MainMenu />
+  <NcAppContent>
+    <router-view />
+  </NcAppContent>
+  <CnObjectSidebar v-if="objectSidebarState.active" ... />
+</NcContent>
+```
+
+## Consequences
+
+- Developers must check if a shared component is self-contained before wrapping it
+- The component library documents which components are self-contained in their JSDoc headers
+- Code reviews should flag card-in-card nesting as a pattern violation
+- Existing violations should be fixed when encountered (per ADR-015 pre-existing issues rule)
diff --git a/.claude/openspec/architecture/adr-018-widget-header-actions.md b/.claude/openspec/architecture/adr-018-widget-header-actions.md
new file mode 100644
index 00000000..53ed0e42
--- /dev/null
+++ b/.claude/openspec/architecture/adr-018-widget-header-actions.md
@@ -0,0 +1,105 @@
+# ADR-018: Widget Header Actions Pattern
+
+## Status
+Accepted
+
+## Date
+2026-04-14
+
+## Context
+
+Card and widget components across Conduction apps need action controls (buttons, dropdowns, selects) for user interactions like changing status, adding items, or toggling views. Developers have been placing these controls inline with card content, taking up vertical space and creating inconsistent layouts.
+
+Nextcloud's own UI pattern places actions in the title bar (top-right) of panels and sidebars. Our shared component library should enforce this same pattern so all card/widget components have a consistent location for actions.
+
+## Decision
+
+### All card/widget components MUST support a `header-actions` slot
+
+Every component that renders a title bar or header MUST provide a `header-actions` slot positioned in the **top-right of the header**, inline with the title. This is the standard location for action controls.
+
+### Standard slot name: `header-actions`
+
+All components use the slot name `header-actions` for consistency. Components that previously used `actions` retain it for backwards compatibility but `header-actions` is the canonical name.
+
+### Component support status
+
+All card/widget components in `@conduction/nextcloud-vue` now support `header-actions`:
+
+| Component | Slot name | Notes |
+|---|---|---|
+| `CnDetailCard` | `header-actions` | Primary card component |
+| `CnWidgetWrapper` | `header-actions` | Dashboard widget container |
+| `CnObjectDataWidget` | `header-actions` | Passes through to CnDetailCard |
+| `CnObjectMetadataWidget` | `header-actions` | Passes through to CnDetailCard |
+| `CnStatsPanel` | `header-actions` | Added in this ADR |
+| `CnSettingsCard` | `header-actions` | Added in this ADR |
+| `CnConfigurationCard` | `header-actions` + `actions` (legacy) | `header-actions` added alongside existing `actions` |
+| `CnVersionInfoCard` | `header-actions` + `actions` (legacy) | `header-actions` added alongside existing `actions` |
+
+### What goes in header-actions
+
+- Status change dropdowns / selects
+- Add/create buttons
+- Toggle switches (e.g. edit mode)
+- Refresh buttons
+- Filter controls specific to this widget
+
+### What does NOT go in header-actions
+
+- Save/cancel for the entire page (those belong in `CnDetailPage` `#header-actions`)
+- Bulk action toolbars (those belong in `CnMassActionBar`)
+- Form inputs that are part of the data being edited
+
+### Usage pattern
+
+```vue
+<CnDetailCard :title="t('app', 'Status')">
+  <template #header-actions>
+    <NcSelect
+      v-model="selectedStatus"
+      :options="statusOptions"
+      :placeholder="t('app', 'Change status...')" />
+  </template>
+
+  <!-- Card content -->
+  <CnTimelineStages :stages="stages" :current-stage="current" />
+</CnDetailCard>
+```
+
+### New components
+
+When creating new card or widget components, the `header-actions` slot MUST be included from the start. The standard template pattern:
+
+```vue
+<div class="cn-my-widget__header">
+  <h4 class="cn-my-widget__title">{{ title }}</h4>
+  <div v-if="$slots['header-actions']" class="cn-my-widget__header-actions">
+    <slot name="header-actions" />
+  </div>
+</div>
+```
+
+With CSS:
+```css
+.cn-my-widget__header {
+  display: flex;
+  align-items: center;
+  justify-content: space-between;
+}
+
+.cn-my-widget__header-actions {
+  display: flex;
+  align-items: center;
+  gap: 4px;
+  flex-shrink: 0;
+}
+```
+
+## Consequences
+
+- All existing card components now support `header-actions`
+- New components must include this slot from creation
+- Existing apps should migrate inline actions to `header-actions` when touching those files
+- Code reviews should flag action controls placed in card content as a pattern violation
+- The `actions` slot name in CnConfigurationCard and CnVersionInfoCard is deprecated but retained for backwards compatibility
diff --git a/.claude/skills/clean-env/SKILL.md b/.claude/skills/clean-env/SKILL.md
new file mode 100644
index 00000000..8d0e93c8
--- /dev/null
+++ b/.claude/skills/clean-env/SKILL.md
@@ -0,0 +1,48 @@
+---
+name: clean-env
+description: Reset the OpenRegister development environment (stop, remove volumes, restart, install apps)
+---
+
+# Clean Environment
+
+Run the `clean-env.sh` script to fully reset the OpenRegister development environment.
+
+This will:
+1. Stop all containers from the OpenRegister docker-compose
+2. Remove all containers and volumes (full data reset)
+3. Start containers fresh
+4. Wait for Nextcloud to become ready
+5. Install core apps: openregister, opencatalogi, softwarecatalog, nldesign, mydash
+
+**Model check — only apply when this skill is run standalone. Skip this section entirely if this skill was called from within another skill — the calling skill is responsible for model selection.**
+
+**Check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- **On Haiku**: proceed normally — this is the right model for this task.
+- **On Sonnet**: inform the user and ask using AskUserQuestion:
+  > "⚠️ You're on Sonnet. This skill runs a shell script — purely mechanical, no reasoning required. Haiku is a better fit and conserves quota for heavier tasks. Switch with `/model haiku`, or proceed with Sonnet."
+  Options: **Proceed with Sonnet** / **Switch to Haiku first** (stop here if switching)
+- **On Opus**: stop immediately:
+  > "You're on Opus. This skill runs a shell script — purely mechanical, no reasoning required. Opus is overkill here and will waste quota unnecessarily. Please switch to Haiku (`/model haiku`) and re-run."
+
+## Instructions
+
+Run the clean-env script:
+
+```bash
+bash .claude/scripts/clean-env.sh
+```
+
+**Important:** This is a destructive operation — it removes all database data and volumes. Only run when a full reset is intended.
+
+After the script completes, verify the environment:
+1. Check that Nextcloud is accessible at http://localhost:8080
+2. Log in with admin/admin
+3. Confirm apps are listed and enabled
+
+If any app fails to enable, try running manually:
+```bash
+docker exec nextcloud php occ app-enable <appname>
+```
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`).
diff --git a/.claude/skills/clean-env/evals/evals.json b/.claude/skills/clean-env/evals/evals.json
new file mode 100644
index 00000000..a45a67da
--- /dev/null
+++ b/.claude/skills/clean-env/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"clean-env","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"full-reset","description":"Full environment reset","prompt":"Run /clean-env","setup":"Docker environment running with data","expected":"Should stop, remove, restart fresh","assertions":["Stops running containers","Removes volumes (full data reset)","Restarts fresh containers","Waits for Nextcloud readiness","Installs core apps"]},{"id":"verification","description":"Verify after reset","prompt":"Check environment after reset","setup":"Reset completed","expected":"Should verify environment is working","assertions":["Nextcloud responds at expected URL","Core apps are installed and enabled","Database is fresh","No errors in container logs"]},{"id":"destructive-warning","description":"Warn about data loss","prompt":"Run clean-env with important data","setup":"Environment with user data","expected":"Should warn before destroying","assertions":["Shows warning about data loss","Requires explicit confirmation","Lists what will be destroyed","Proceeds only after approval"]}],"trigger_tests":{"should_trigger":["reset the environment","clean environment","clean env","reset docker","start fresh"],"should_not_trigger":["restart containers","update config","test the app","create a PR","deploy changes"]}}
diff --git a/.claude/skills/create-pr/SKILL.md b/.claude/skills/create-pr/SKILL.md
new file mode 100644
index 00000000..f6c55c05
--- /dev/null
+++ b/.claude/skills/create-pr/SKILL.md
@@ -0,0 +1,446 @@
+---
+name: create-pr
+description: Create a Pull Request from the current branch — runs local checks, picks target branch, and opens the PR on GitHub
+---
+
+# Create Pull Request
+
+Guides the developer through creating a Pull Request for a Nextcloud app. Confirms the source branch, recommends a target branch based on the branching strategy, optionally runs local quality checks, then creates the PR via the GitHub REST API.
+
+---
+
+## Model Recommendation
+
+This skill involves parsing CI workflows, detecting branch-protection rules, resolving bootstrap deadlocks, and reasoning about code diffs. Mistakes here have real consequences.
+
+**First, check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- If the active model is **Haiku or any model other than Sonnet or Opus**: stop immediately and tell the user:
+  > "This command requires Sonnet or Opus — the CI workflow parsing and branch-protection analysis steps need stronger reasoning than Haiku can reliably provide. Please switch models and re-run."
+
+- If the active model is **Sonnet or Opus**: ask the user using AskUserQuestion:
+
+**"You're on [active-model]. Which model should I use for this PR?"**
+
+| Model | Best for |
+|---|---|
+| **Sonnet** | Most PRs — handles CI parsing and branch logic well |
+| **Opus** | Repos with reusable CI workflows, branch-protection rulesets, or a complex branching strategy — that's where it pays off most |
+
+- **Sonnet**
+- **Opus**
+
+If the chosen model differs from the active model, tell the user:
+> "You're on [active-model] but chose [chosen-model]. To switch: use `/model [chosen-model]` in the chat input, or open the model picker in the Claude Code UI. Then re-run this command."
+Then stop.
+
+---
+
+## Hard Rules
+
+**NEVER modify `.github/workflows/` files.** This skill reads workflow files to understand what CI runs, but must never edit, create, or delete any workflow file or change any job definition — regardless of what checks fail or what the branch protection requires. If a workflow mismatch is detected (e.g. wrong job name for a required status check), report the issue to the user and stop — do not attempt to fix it.
+
+---
+
+## Step 0: Select Repository
+
+Scan the workspace for available git repositories:
+
+```bash
+# Scan sibling directories of the current git repo for other repos
+WORKSPACE_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)/.."
+for dir in "$WORKSPACE_ROOT"/*/; do
+  if [ -d "$dir/.git" ] || git -C "$dir" rev-parse --git-dir > /dev/null 2>&1; then
+    echo "$dir"
+  fi
+done
+```
+
+For each found repo, also get its remote URL and current branch:
+```bash
+git -C {dir} remote get-url origin 2>/dev/null
+git -C {dir} branch --show-current 2>/dev/null
+```
+
+Ask the user using AskUserQuestion:
+
+**"Which repository do you want to create a PR for?"**
+
+List each repo as: `{app-name}  [{current-branch}]  ({remote-url})`
+
+Store the selected repo's absolute path as `{REPO_ROOT}`.
+
+---
+
+## Step 1: Detect Current Branch & Repo
+
+Run within `{REPO_ROOT}`:
+```bash
+git -C {REPO_ROOT} branch --show-current
+git -C {REPO_ROOT} remote get-url origin
+```
+
+Store:
+- `{CURRENT_BRANCH}` — active branch name
+- `{REMOTE_URL}` — GitHub repo URL
+
+---
+
+## Step 2: Confirm Source Branch
+
+Ask the user using AskUserQuestion:
+
+**"Your current branch is `{CURRENT_BRANCH}`. Is this the correct branch to create a PR from?"**
+- **Yes** — proceed with `{CURRENT_BRANCH}`
+- **No, let me specify** → ask them for the correct branch name and store it as `{CURRENT_BRANCH}`
+
+---
+
+## Step 3: Recommend Target Branch
+
+Based on `{CURRENT_BRANCH}`, determine the recommended target using the project branching strategy:
+
+| Source branch pattern | Recommended target | Allowed targets |
+|-----------------------|--------------------|-----------------|
+| `feature/*`, `bugfix/*`, or other non-standard branch | `development` | `development` |
+| `development` | `beta` | `beta` |
+| `beta` | `main` | `main` |
+| `hotfix/*` | `main` | `main`, `beta`, `development` |
+
+Fetch available remote branches:
+```bash
+git -C {REPO_ROOT} fetch --prune
+git -C {REPO_ROOT} branch -r | grep -v HEAD | sed 's|origin/||' | sort
+```
+
+Ask the user using AskUserQuestion:
+
+**"Which branch should this PR target?"**
+
+List the allowed target branches, marking the recommended one with `(recommended)`. If there is only one valid option, pre-select it and ask for confirmation instead.
+
+Store the answer as `{TARGET_BRANCH}`.
+
+---
+
+## Step 3.2: Validate Target Branch Against Branch-Protection Workflow
+
+Read [references/branch-protection-guide.md](references/branch-protection-guide.md) for the full procedure covering: branch-protection workflow validation (Step 3.2), required-check bootstrap deadlock detection (Step 3.2b), and bootstrap deadlock resolution post-push (Step 3.2c). Apply all three steps now.
+
+---
+
+## Step 3.4: Verify Global Settings Version (ConductionNL/.github only)
+
+**Only run this step if `{REMOTE_URL}` contains `ConductionNL/.github`.**
+
+Invoke the `/verify-global-settings-version` skill now and follow its steps completely.
+
+- If it reports **Case A or B** (no changes, or correctly bumped) → proceed silently to Step 3.5.
+- If it reports **Case C** (VERSION BUMP MISSING) → pause the PR flow. Ask using AskUserQuestion:
+
+  **"The global-settings VERSION has not been bumped. How do you want to proceed?"**
+  - **Apply a patch bump now** — increment to next patch, show the new value, then continue to Step 3.5
+  - **Apply a minor bump now** — increment minor, show new value, then continue to Step 3.5
+  - **I'll fix it manually** — stop here
+
+- If it reports **Case D** (VERSION bumped but no file changes) → warn the user but allow the PR to proceed.
+
+---
+
+## Step 3.5: Check for Existing PR
+
+Before running any checks, look up whether a PR already exists for this source → target combination:
+
+```bash
+gh pr list --repo "{REMOTE_URL}" --head "{CURRENT_BRANCH}" --base "{TARGET_BRANCH}" --state open --json number,title,url,createdAt,author
+```
+
+Also check for a closed/merged PR to give full context:
+```bash
+gh pr list --repo "{REMOTE_URL}" --head "{CURRENT_BRANCH}" --base "{TARGET_BRANCH}" --state merged --json number,title,url,mergedAt --limit 1
+```
+
+**If an open PR already exists:**
+
+Inform the user clearly:
+
+> "An open PR already exists for `{CURRENT_BRANCH}` → `{TARGET_BRANCH}`:
+> **#{number}: {title}**
+> {url}
+> Opened by {author} on {createdAt}"
+
+Then ask using AskUserQuestion:
+
+**"A PR for this branch already exists. What would you like to do?"**
+- **View the existing PR** — open the URL and stop here
+- **Update the existing PR** (push new commits + update description) — store `{EXISTING_PR_NUMBER}` and proceed to Step 3.7 as normal; in Step 7 use PATCH instead of POST
+- **Continue anyway** (create a duplicate — not recommended) — proceed to Step 3.7 as normal
+
+**If a merged PR was found but no open PR:**
+
+Inform the user:
+
+> "Note: A previous PR for `{CURRENT_BRANCH}` → `{TARGET_BRANCH}` was already merged (#{number}: {title}, merged {mergedAt}). You may be re-opening the same work."
+
+Then proceed normally to Step 4.
+
+**If no PR exists:** proceed silently to Step 4.
+
+---
+
+## Step 3.7: Check for Uncommitted or Unpushed Changes
+
+Check the working tree and push status of `{CURRENT_BRANCH}`:
+
+```bash
+git -C {REPO_ROOT} status --short
+git -C {REPO_ROOT} log origin/{CURRENT_BRANCH}...HEAD --oneline 2>/dev/null || echo "(branch not yet on remote)"
+```
+
+**If there are uncommitted changes** (modified, untracked, or staged files):
+
+Before listing all uncommitted changes, specifically check for lock files that are untracked or modified:
+```bash
+git -C {REPO_ROOT} status --short | grep -E "composer\.lock|package-lock\.json"
+```
+
+If `composer.lock` or `package-lock.json` appear as untracked (`??`) or modified (`M`), warn prominently:
+> "⚠️ `{filename}` is not committed. CI installs dependencies from the lock file — without it, dependency versions may differ between local and CI, causing check failures. This should be committed before creating the PR."
+
+Inform the user of all uncommitted changes, listing the files. Then ask using AskUserQuestion:
+
+**"There are uncommitted changes on `{CURRENT_BRANCH}`. What would you like to do?"**
+- **Commit them now** — ask for a commit message, run `git -C {REPO_ROOT} add -A && git -C {REPO_ROOT} commit -m "{message}"`, then continue
+- **Stash them** — run `git -C {REPO_ROOT} stash`, continue, and remind user to `git stash pop` afterwards
+- **Continue without committing** — proceed (these changes will not be in the PR)
+
+**If the branch has commits not yet pushed to origin:**
+
+Inform the user. Then ask using AskUserQuestion:
+
+**"Branch `{CURRENT_BRANCH}` has unpushed commits. Push them now before continuing?"**
+- **Yes, push now** — run `git -C {REPO_ROOT} push -u origin {CURRENT_BRANCH}`, then continue
+- **No, push later** — note that unpushed commits won't be in the PR until pushed; continue
+
+---
+
+## Step 4: Run Local Checks (optional)
+
+Ask the user using AskUserQuestion:
+
+**"Do you want to run local quality checks before creating the PR? This mirrors exactly what CI will run and ensures the PR checks pass."**
+- **Yes, run checks** — proceed to Step 4a
+- **No, skip checks** — proceed to Step 5
+
+### Step 4a: Read CI Workflows — the Source of Truth
+
+**The workflow files define exactly what to run locally. Do not hardcode assumptions.**
+
+Find all workflow files triggered on `push` or `pull_request`:
+```bash
+find {REPO_ROOT}/.github/workflows -name "*.yml" -o -name "*.yaml" 2>/dev/null | sort
+```
+
+If no `.github/workflows` directory exists:
+> "No GitHub Actions workflows found — skipping local checks."
+Then proceed to Step 5.
+
+Read each workflow file. For each job in a triggered workflow:
+
+**If the job runs steps directly** — read and record every `run:` step in order.
+
+**If the job delegates to a reusable workflow** (`uses: org/repo/.github/workflows/file.yml@ref`) — fetch and read that workflow too:
+```bash
+# Parse org, repo, path, ref from the 'uses:' value
+# e.g. uses: ConductionNL/.github/.github/workflows/quality.yml@main
+gh api "repos/{org}/{repo}/contents/{path}?ref={ref}" --jq '.content' | base64 -d
+```
+Then read the reusable workflow's jobs and their `run:` steps, also noting any `inputs:` the calling workflow passes (e.g. `enable-eslint: true`) — these control which jobs/steps actually execute.
+
+Build a complete ordered list of every `run:` step the CI executes for this repo's push/PR trigger.
+
+### Step 4b: Determine Check Working Directory
+
+For the Nextcloud workspace, checks run inside the app subdirectory. Detect from the changed files:
+```bash
+git -C {REPO_ROOT} diff --name-only origin/{TARGET_BRANCH}...HEAD
+```
+
+Look for which app directory has the most changed files. If ambiguous, ask:
+
+**"Which app directory should we run checks in?"** — list the changed app directories.
+
+Store as `{CHECK_DIR}`.
+
+### Step 4c: Categorise Steps and Build Execution Plan
+
+Read [references/ci-step-categorisation-guide.md](references/ci-step-categorisation-guide.md) for the full categorisation rules (Install / Check / Docker check / Skip), mixed-job handling, "requires Nextcloud" detection signals, Docker check adaptations (PHPUnit, Newman), lock file gate, and execution plan display format. Apply the full procedure now.
+
+### Step 4d: Run Install Steps
+
+Run each install step **exactly as it appears in the CI workflow**, in CI order. If any install step fails, stop immediately and show the full error — do not proceed to checks.
+
+### Step 4d-verify: Verify Check Tools Are Available
+
+Read [references/check-tool-verification.md](references/check-tool-verification.md) for the full verification procedure: tool checklist by command pattern, local vs Docker probe commands, missing-tool report format, and the three-option resolution prompt. Apply the full procedure now.
+
+### Step 4e: Run Check Steps
+
+Run each check step **exactly as it appears in the CI workflow**, in CI order. Run them one by one, show output as each completes, and record pass/fail.
+
+For steps flagged as optional (e.g. slow test suites with `phpunit`/`pytest`), ask first:
+**"Run `{command}` too? (this may be slow)"**
+
+### Step 4f: Report & Decide
+
+Display a results table with one row per check step:
+
+```
+CI check results:
+  [{job name}] {command}   ✅ PASS / ❌ FAIL
+  [{job name}] {command}   ✅ PASS / ❌ FAIL
+  ...
+```
+
+- If **all checks pass** → proceed to Step 5 with a success note.
+- If **any check fails** → show the full output and ask using AskUserQuestion:
+
+  **"Some checks failed. How do you want to proceed?"**
+  - **Fix issues first, then re-run** — stop here; let the user fix and re-invoke the skill
+  - **Create PR anyway** — proceed to Step 5 with a warning note in the PR body listing which checks failed
+
+---
+
+## Step 5: Analyse Branch Changes
+
+Collect the full picture of what is on this branch before drafting anything:
+
+```bash
+git -C {REPO_ROOT} log origin/{TARGET_BRANCH}...HEAD --oneline
+git -C {REPO_ROOT} log origin/{TARGET_BRANCH}...HEAD --format="%H %s%n%b" --no-merges
+git -C {REPO_ROOT} diff --stat origin/{TARGET_BRANCH}...HEAD
+git -C {REPO_ROOT} diff origin/{TARGET_BRANCH}...HEAD -- "*.php" "*.js" "*.ts" "*.vue" | head -300
+```
+
+Read each changed file's diff to understand what actually changed (not just filenames). This is the basis for the title and description — derive them from the actual code changes, not just commit messages.
+
+---
+
+## Step 5.5: Check for OpenSpec issue link
+
+Check if a `plan.json` exists for the current change:
+
+```bash
+find {REPO_ROOT}/openspec/changes -maxdepth 2 -name "plan.json" ! -path "*/archive/*" 2>/dev/null
+```
+
+If found, read it and extract `tracking_issue` and `repo`. Store as `{TRACKING_ISSUE}` (e.g. `42`) or `null` if not found.
+
+This will be included in the PR description to auto-close the issue on merge.
+
+---
+
+## Step 6: Draft PR Title & Description
+
+Using the commit log, diff stat, and file-level diffs from Step 5, draft:
+
+**Title**: Concise, action-verb sentence describing the main purpose (e.g. `Add full-text search to registers`). Do not use the branch name verbatim. Do not include app names or ticket numbers unless the commits reference them.
+
+**Description**:
+
+```markdown
+## Summary
+
+{3–6 bullet points derived from the actual commits and diffs — what changed and why}
+
+## Checks
+
+{one of:}
+- ✅ All local checks passed (`composer check:strict`)
+- ⚠️ Some checks failed — see CI for details
+- ⏭️ Checks skipped
+
+## Test plan
+
+- [ ] CI passes
+- [ ] Tested locally
+- [ ] Reviewed for regressions
+
+{if TRACKING_ISSUE is set:}
+Closes #{TRACKING_ISSUE}
+```
+
+Present the draft to the user **in the chat** — show both the title and the full description as they would appear on GitHub.
+
+Then ask using AskUserQuestion:
+
+**"Does this PR title and description look good?"**
+- **Yes, proceed** — proceed to Step 7 (will create or update depending on whether `{EXISTING_PR_NUMBER}` is set)
+- **Change something** → ask: "What would you like to change or improve?" — apply the feedback, show the updated draft, and ask again
+- **Let me write my own title** → ask for a new title, update the draft, show it, and ask again
+
+Repeat the review loop until the user approves.
+
+Store the approved title as `{PR_TITLE}` and description as `{PR_BODY}`.
+
+---
+
+## Step 7: Create or Update the PR
+
+Push the branch to origin if not already pushed:
+```bash
+git -C {REPO_ROOT} push -u origin {CURRENT_BRANCH}
+```
+
+Parse `{OWNER}` and `{REPO}` from `{REMOTE_URL}` (e.g. `https://github.com/ConductionNL/myapp.git` → owner=`ConductionNL`, repo=`myapp`).
+
+**Always use the GitHub REST API directly — never use `gh pr create` or `gh pr edit` (they use GraphQL and may trigger deprecation errors).**
+
+### If updating an existing PR (`{EXISTING_PR_NUMBER}` is set):
+
+```bash
+gh api repos/{OWNER}/{REPO}/pulls/{EXISTING_PR_NUMBER} \
+  --method PATCH \
+  -f title="{PR_TITLE}" \
+  -f body="{PR_BODY}" \
+  --jq '{number: .number, title: .title, url: .html_url}'
+```
+
+### If creating a new PR:
+
+```bash
+gh api repos/{OWNER}/{REPO}/pulls \
+  --method POST \
+  -f title="{PR_TITLE}" \
+  -f head="{CURRENT_BRANCH}" \
+  -f base="{TARGET_BRANCH}" \
+  -f body="{PR_BODY}" \
+  --jq '{number: .number, title: .title, url: .html_url}'
+```
+
+Store the returned PR number as `{PR_NUMBER}` and URL as `{PR_URL}`.
+
+---
+
+## Step 8: Confirm & Report
+
+After the PR is created, display:
+- The PR URL
+- Source → target branch
+- Check status summary
+- Next steps (e.g., "Request a review", "Watch CI status")
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`).
diff --git a/.claude/skills/create-pr/evals/evals.json b/.claude/skills/create-pr/evals/evals.json
new file mode 100644
index 00000000..a72a4195
--- /dev/null
+++ b/.claude/skills/create-pr/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"create-pr","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"standard-pr","description":"Create PR from feature branch","prompt":"Run /create-pr","setup":"On feature branch with commits","expected":"Should detect repo, pick target, create PR","assertions":["Detects current repo and branch","Recommends target branch (feature→dev, dev→beta, etc.)","Runs local quality checks if applicable","Creates PR via gh CLI with proper format"]},{"id":"branch-protection","description":"Respect branch protection","prompt":"Create PR targeting main","setup":"main has branch protection","expected":"Should validate protection rules","assertions":["Detects branch protection on target","Validates required status checks exist","Warns about bootstrap deadlock if checks missing","Suggests alternative target if needed"]},{"id":"quality-checks","description":"Run local checks before PR","prompt":"Create PR with failing checks","setup":"Code has quality issues","expected":"Should block PR on failures","assertions":["Runs composer check:strict for PHP apps","Runs npm lint for frontend","Reports failures before creating PR","Suggests fixes","Does NOT create PR with failing checks"]}],"trigger_tests":{"should_trigger":["create a PR","make a pull request","create-pr","push and create PR","open a pull request"],"should_not_trigger":["review a PR","merge a PR","close a PR","push to remote","check PR comments"]}}
diff --git a/.claude/skills/create-pr/learnings.md b/.claude/skills/create-pr/learnings.md
new file mode 100644
index 00000000..d32e0745
--- /dev/null
+++ b/.claude/skills/create-pr/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — create-pr
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/create-pr/references/branch-protection-guide.md b/.claude/skills/create-pr/references/branch-protection-guide.md
new file mode 100644
index 00000000..571c2afd
--- /dev/null
+++ b/.claude/skills/create-pr/references/branch-protection-guide.md
@@ -0,0 +1,95 @@
+# Branch Protection Validation Guide
+
+Reference for Steps 3.2, 3.2b, and 3.2c of `create-pr`.
+
+---
+
+## Step 3.2: Validate Target Branch Against Branch-Protection Workflow
+
+Some repos enforce allowed source→target combinations via a branch-protection reusable workflow. Check for this **before** doing anything else, so the user doesn't waste time running checks only to have the PR rejected.
+
+**1. Find any branch-protection workflow triggered on pull_request:**
+```bash
+grep -rl "branch-protection" {REPO_ROOT}/.github/workflows/ 2>/dev/null
+```
+
+**2. For each found workflow, read it and extract the `uses:` line:**
+```bash
+# e.g. uses: ConductionNL/.github/.github/workflows/branch-protection.yml@main
+```
+
+**3. Fetch and read the reusable workflow:**
+```bash
+gh api "repos/{org}/{repo}/contents/{path}?ref={ref}" --jq '.content' | base64 -d
+```
+
+**4. Simulate the validation logic** — look for `run:` steps that check `github.base_ref` / `github.head_ref` (source/target branch patterns). Parse the allowed combinations and evaluate them with `{CURRENT_BRANCH}` as source and `{TARGET_BRANCH}` as target.
+
+**If the combination is forbidden by the branch-protection rules:**
+
+> "❌ The branch-protection workflow will reject this PR.
+> `{CURRENT_BRANCH}` → `{TARGET_BRANCH}` is not an allowed combination.
+> Allowed patterns: {list the allowed patterns from the workflow}"
+
+Then ask using AskUserQuestion:
+
+**"This PR would be blocked by branch protection. How do you want to proceed?"**
+- **Choose a different target branch** — go back to Step 3 and ask again
+- **Create the PR anyway** — note the user explicitly acknowledged this will fail branch-protection CI
+
+**If no branch-protection workflow is found, or the combination is allowed:** proceed silently.
+
+---
+
+## Step 3.2b: Check for Required-Check Bootstrap Deadlock
+
+After confirming the source→target combination is allowed, check whether a required status check will never run because its workflow doesn't exist on the base branch yet. This is a **bootstrap deadlock** — the workflow is being introduced by this very PR, but GitHub reads PR workflows from the base branch.
+
+**1. Find all required status check names for `{TARGET_BRANCH}`:**
+```bash
+gh api repos/{owner}/{repo}/rulesets --jq '
+  .[] | select(.enforcement == "active") |
+  .rules[] | select(.type == "required_status_checks") |
+  .parameters.required_status_checks[].context' 2>/dev/null
+```
+
+**2. For each required check name, find which workflow file produces it:**
+Look for workflow files in `{REPO_ROOT}/.github/workflows/` where the workflow `name:` or job name matches the required check name (e.g. a workflow named `pull-request-lint-check` produces a check called `lint-check`).
+
+**3. Check if that workflow file exists on the base branch:**
+```bash
+gh api "repos/{owner}/{repo}/contents/.github/workflows/{filename}?ref={TARGET_BRANCH}" --jq '.name' 2>/dev/null || echo "NOT ON BASE BRANCH"
+```
+
+**If a required check's workflow is missing from `{TARGET_BRANCH}`:**
+
+Warn the user:
+> "⚠️ Bootstrap deadlock detected: the `{check-name}` check is required to merge into `{TARGET_BRANCH}`, but the workflow that produces it (`{filename}`) doesn't exist on `{TARGET_BRANCH}` yet. GitHub reads PR workflows from the base branch, so this check will show as 'Expected — Waiting' and block merging."
+
+Then offer:
+> "This can be resolved after creating the PR by posting a commit status via the GitHub API — no admin access required."
+
+Store `{BOOTSTRAP_CHECKS}` = list of affected check names + their head SHA (retrieved after push in Step 7).
+
+---
+
+## Step 3.2c: Resolve Bootstrap Deadlock (run after Step 7 if needed)
+
+If `{BOOTSTRAP_CHECKS}` is non-empty, after the PR is created and the branch is pushed:
+
+**Get the PR head SHA:**
+```bash
+gh api repos/{owner}/{repo}/pulls/{pr_number} --jq '.head.sha'
+```
+
+**Post a commit status for each affected check:**
+```bash
+gh api repos/{owner}/{repo}/statuses/{head_sha} \
+  -X POST \
+  -f state=success \
+  -f context="{check-name}" \
+  -f description="Bootstrap: workflow added in this PR, check passes" \
+  -f target_url="{PR_URL}"
+```
+
+This satisfies GitHub's required status check by posting a commit status with the matching context name. The check will show as ✅ pass and the PR will become mergeable. This is a legitimate one-time bootstrap workaround — once merged, the workflow exists on the base branch and all future PRs will run it normally.
diff --git a/.claude/skills/create-pr/references/check-tool-verification.md b/.claude/skills/create-pr/references/check-tool-verification.md
new file mode 100644
index 00000000..6e707d85
--- /dev/null
+++ b/.claude/skills/create-pr/references/check-tool-verification.md
@@ -0,0 +1,71 @@
+# Check Tool Verification
+
+Reference for Step 4d-verify of `create-pr`. Verifies that every tool binary required by the check steps actually exists before running any checks.
+
+---
+
+## Step 4d-verify: Verify Check Tools Are Available
+
+After install steps complete, verify that **every tool binary** required by the check steps actually exists before running any checks. This prevents silent skips (e.g. composer scripts that fall back to `|| echo 'not installed, skipping...'`).
+
+**1. Build a tool checklist** from the execution plan's check steps. For each check command, identify the binary it needs:
+
+| Check command pattern | Binary to verify |
+|---|---|
+| `composer psalm` | `vendor/bin/psalm` |
+| `composer phpstan` | `vendor/bin/phpstan` |
+| `composer phpcs` | `vendor/bin/phpcs` |
+| `composer phpmd` | `vendor/bin/phpmd` |
+| `composer phpmetrics` | `vendor/bin/phpmetrics` |
+| `composer lint` | `php` (always available) |
+| `npx eslint` / `npm run lint` | `node_modules/.bin/eslint` |
+| `npx stylelint` / `npm run stylelint` | `node_modules/.bin/stylelint` |
+| Any `vendor/bin/{tool}` | that exact path |
+| Any `node_modules/.bin/{tool}` | that exact path |
+
+**2. Determine WHERE to check** — checks may run locally or inside the Docker container:
+
+- For **local check steps**: verify the binary exists at `{CHECK_DIR}/{binary_path}`
+- For **Docker check steps**: verify inside the container:
+  ```bash
+  docker exec "$NC_CONTAINER" test -f /var/www/html/apps-extra/{APP_DIR}/{binary_path} && echo "EXISTS" || echo "MISSING"
+  ```
+
+**3. Probe each tool** and collect results:
+
+```bash
+# Local example:
+test -f {CHECK_DIR}/vendor/bin/psalm && echo "EXISTS" || echo "MISSING"
+
+# Docker example:
+docker exec "$NC_CONTAINER" test -f /var/www/html/apps-extra/{APP_DIR}/vendor/bin/psalm && echo "EXISTS" || echo "MISSING"
+```
+
+**4. If ALL tools are available:** proceed silently to Step 4e.
+
+**5. If ANY tools are missing:** display a clear report:
+
+```
+Tool availability check:
+  ✅ vendor/bin/phpcs          — available
+  ✅ vendor/bin/phpstan        — available
+  ❌ vendor/bin/psalm          — MISSING
+  ❌ vendor/bin/phpmd          — MISSING
+  ✅ node_modules/.bin/eslint  — available
+```
+
+Then determine the likely fix. Missing tools are almost always caused by a failed or incomplete dependency install:
+
+- **Missing `vendor/bin/*` tools** → `composer install` likely failed or was never run. The fix is:
+  - Locally: `composer install --ignore-platform-reqs` (in `{CHECK_DIR}`)
+  - In Docker: `docker exec -w /var/www/html/apps-extra/{APP_DIR} "$NC_CONTAINER" composer install --ignore-platform-reqs`
+- **Missing `node_modules/.bin/*` tools** → `npm ci` or `npm install` likely failed or was never run. The fix is:
+  - Locally: `npm ci` (in `{CHECK_DIR}`)
+  - In Docker: `docker exec -w /var/www/html/apps-extra/{APP_DIR} "$NC_CONTAINER" npm ci`
+
+Ask the user using AskUserQuestion:
+
+**"Some check tools are missing and checks would silently skip without them. Should I install the missing dependencies now?"**
+- **Yes, install now** — run the appropriate install command(s), then re-verify all tools. If still missing after install, report the specific failures and stop.
+- **Skip missing checks** — proceed to Step 4e, but mark any check whose tool is missing as `⏭️ SKIPPED (tool not installed)` in the results table instead of running it. Include this in the PR description.
+- **Stop here** — let the user fix the environment manually and re-run the skill.
diff --git a/.claude/skills/create-pr/references/ci-step-categorisation-guide.md b/.claude/skills/create-pr/references/ci-step-categorisation-guide.md
new file mode 100644
index 00000000..3da95a42
--- /dev/null
+++ b/.claude/skills/create-pr/references/ci-step-categorisation-guide.md
@@ -0,0 +1,128 @@
+# CI Step Categorisation Guide
+
+Reference for Step 4c of `create-pr`. Categorises CI `run:` steps into Install / Check / Docker check / Skip groups and builds the execution plan.
+
+---
+
+## Categorise Steps and Build Execution Plan
+
+From the full list of CI `run:` steps, categorise each as:
+
+- **Install** — dependency install commands that must be run first:
+  - `composer install`, `composer ci`, `npm ci`, `npm install`, `pip install`, etc.
+  - Note the **exact flags** the CI uses (e.g. `--no-interaction`, `--legacy-peer-deps`, `--frozen-lockfile`)
+- **Check** — quality/lint/test commands that run against source files only (no live server needed):
+  - phpcs, phpstan, psalm, phpmd, eslint, stylelint, pytest, ruff, mypy, etc.
+  - Use the **exact command** from the workflow, adapted to run from `{CHECK_DIR}`
+- **Docker check** — commands from jobs that require a running Nextcloud server (see detection rule below)
+- **Skip** — steps that cannot run locally at all (cloud infrastructure, upload/deploy, CI secrets/runners)
+
+---
+
+## Handling jobs that mix runnable and skippable steps
+
+Some CI jobs combine steps that are locally runnable (e.g. `npm audit`) with steps that are CI-only (e.g. generating and committing SBOM files, uploading artifacts, installing Grype). **Do not skip the entire job** — extract the individually runnable steps and classify them as Check steps.
+
+The key pattern to watch for: a job that generates artifact files (CycloneDX SBOM, coverage reports, etc.) but **also contains audit or quality commands**. Extract those commands as Check steps with their **exact flags from that job** — not the flags from a different job.
+
+**Critical example:** the SBOM job runs `npm audit --audit-level=critical` (no `--omit=dev`), while the Security job runs `npm audit --audit-level=critical --omit=dev`. These are different commands producing different results. Always use the exact flags from the job where the step appears.
+
+Steps to skip within an otherwise-mixed job:
+- Any step that installs/runs Grype, Trivy, or other CVE scanners (requires network + CI credentials)
+- Any step that generates SBOM files (CycloneDX npm/composer commands)
+- Any step that commits files back to the repo (`git commit`, `git push` in CI)
+- Any step that uploads/attaches artifacts (`actions/upload-artifact`, `softprops/action-gh-release`)
+
+Steps to extract and run:
+- `composer audit ...` — run locally with the exact flags from the job
+- `npm audit ...` — run locally with the exact flags from the job (pay attention to `--omit=dev` or lack thereof)
+
+---
+
+## Detecting "requires Nextcloud" jobs
+
+**Do not hardcode tool names.** Instead, read each CI job and ask: does it set up a live Nextcloud server before running tests? The signals are job steps that contain any of:
+- `nextcloud/server` checkout or `git submodule update --init 3rdparty`
+- `php occ maintenance:install` or `php occ app-enable`
+- `docker-compose up` or `docker run` targeting a Nextcloud image
+- Any `nextcloud-test-refs` matrix variable being used
+
+If a job has these signals, **every `run:` step in that job that executes test/check commands** is a Docker check — regardless of the tool name. This covers phpunit, newman, and any future tools added to such a job.
+
+---
+
+## Running Docker checks locally
+
+For any job classified as "requires Nextcloud", check the environment once before running any of its steps:
+
+**1. Check if the Nextcloud container is running:**
+```bash
+NC_CONTAINER=$(docker ps --format '{{.Names}}' | grep -i nextcloud | head -1)
+echo "Container: $NC_CONTAINER"
+```
+
+**2. Check the app is mounted inside it:**
+```bash
+docker exec "$NC_CONTAINER" ls /var/www/html/apps-extra/{APP_DIR}/vendor/bin/ 2>/dev/null | head -3
+```
+
+**If the container is running and the app is mounted:**
+
+Adapt each test command from that job to run via `docker exec` (for server-side commands) or against `http://nextcloud.local` (for HTTP/API commands). Specific adaptations:
+
+- **PHPUnit** (runs inside server):
+  ```bash
+  docker exec -w /var/www/html/apps-extra/{APP_DIR} -e XDEBUG_MODE=coverage "$NC_CONTAINER" \
+    ./vendor/bin/phpunit -c phpunit-unit.xml --colors=always
+  ```
+  Note: Use `phpunit-unit.xml` locally (unit tests only, fast). CI uses `phpunit.xml` + coverage. The `XDEBUG_MODE=coverage` env var is required — without it phpunit emits a runner warning that causes a non-zero exit code even when all tests pass.
+
+- **Newman / HTTP integration tests** (calls the server over HTTP):
+  ```bash
+  npx newman run tests/integration/*.postman_collection.json \
+    --env-var base_url=http://nextcloud.local \
+    --env-var admin_user=admin \
+    --env-var admin_password=admin
+  ```
+  Note: Use `base_url`, `admin_user`, `admin_password` — these are the exact variable names the CI workflow passes (CI uses `http://localhost:8080` via PHP built-in server; locally use `http://nextcloud.local`). Using different names causes Newman to silently fall back to the collection's hardcoded defaults, making tests pass locally but fail in CI.
+
+- **Any other command from a Nextcloud-server job**: run via `docker exec -w /var/www/html/apps-extra/{APP_DIR} "$NC_CONTAINER" {command}` unless the command clearly makes HTTP requests, in which case substitute `http://nextcloud.local` as the base URL.
+
+**If no Nextcloud container is running, or the app is not mounted:**
+
+Ask using AskUserQuestion:
+**"Some CI checks require the Nextcloud Docker environment, which is not running. What would you like to do?"**
+- **Start Docker first** — stop here; remind user to start the environment (e.g. `cd openregister && docker compose up -d`), then re-run the skill
+- **Skip Docker checks** — continue without them; note in the PR which jobs were not run locally
+
+---
+
+## Execution plan display
+
+**Lock file gate (before install):** Check that lock files expected by the install commands are committed:
+- CI uses `npm ci` → `package-lock.json` must be committed and up-to-date
+- CI uses `composer install` → `composer.lock` should be committed
+
+If a required lock file is missing or not committed, stop:
+> "⚠️ `{lockfile}` is required by the CI install step (`{command}`) but is not committed. Run `{generate-command}`, commit the file, then re-run."
+
+Display the full execution plan to the user before running anything:
+```
+Execution plan derived from CI workflows:
+
+  Install steps:
+    1. {exact install command from CI}
+    2. {exact install command from CI}
+
+  Check steps:
+    3. {exact check command from CI}   [{job name}]
+    4. {exact check command from CI}   [{job name}]
+    ...
+
+  Docker check steps (require Nextcloud container — {NC_CONTAINER}):
+    N. docker exec ... {command}   [{job name}]
+    N. npx newman run ...          [{job name}]
+
+  Skipped (cannot run locally):
+    - {step description}
+```
diff --git a/.claude/skills/feature-counsel/SKILL.md b/.claude/skills/feature-counsel/SKILL.md
new file mode 100644
index 00000000..4618b658
--- /dev/null
+++ b/.claude/skills/feature-counsel/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: feature-counsel
+description: Analyze a project's OpenSpec from 8 persona perspectives and suggest additional features
+---
+
+# Feature Counsel — Multi-Persona Feature Advisory
+
+Analyze a project's OpenSpec specifications from 8 different persona perspectives to identify missing features, usability gaps, and improvement opportunities.
+
+**Input**: Optional argument after `/feature-counsel`:
+- No argument → ask which project to analyze
+- Project name → analyze that project directly (e.g., `opencatalogi`, `openregister`)
+
+**Available projects**: Any directory under apps-extra with an `openspec/` folder.
+
+---
+
+## Personas
+
+The Feature Counsel uses 8 personas representing the full spectrum of Dutch public sector users. Each persona card is stored in `.claude/personas/`:
+
+| Persona | File | Perspective |
+|---------|------|-------------|
+| Henk Bakker | `henk-bakker.md` | Elderly citizen (78) — low digital skills, accessibility, plain Dutch |
+| Fatima El-Amrani | `fatima-el-amrani.md` | Low-literate migrant (52) — visual design, simplicity, inclusivity |
+| Sem de Jong | `sem-de-jong.md` | Young digital native (22) — performance, keyboard shortcuts, modern UX |
+| Noor Yilmaz | `noor-yilmaz.md` | Municipal CISO (36) — security, audit trails, BIO2/ENSIA compliance |
+| Annemarie de Vries | `annemarie-de-vries.md` | VNG standards architect (38) — GEMMA, Common Ground, NLGov API rules |
+| Mark Visser | `mark-visser.md` | MKB software vendor (48) — business efficiency, CRUD, Dutch terminology |
+| Priya Ganpat | `priya-ganpat.md` | ZZP developer (34) — API quality, DX, OpenAPI specs, integration |
+| Jan-Willem van der Berg | `janwillem-van-der-berg.md` | Small business owner (55) — plain language, no jargon, simple workflows |
+
+---
+
+## Steps
+
+### Step 0: Determine the Project
+
+If no project was provided as argument, use AskUserQuestion to ask:
+
+**"Which project would you like the Feature Counsel to analyze?"**
+
+List the available projects by checking which directories have `openspec/` folders:
+```
+Available projects:
+- opencatalogi
+- openregister
+- pipelinq
+- procest
+```
+
+Store the chosen project as `{PROJECT}`.
+
+### Step 1: Read the Project's Specs
+
+Read the following files to understand the project:
+
+1. `{PROJECT}/project.md` — Project context, architecture, purpose
+2. `{PROJECT}/openspec/specs/` — All spec files (the main specifications)
+3. `{PROJECT}/openspec/changes/` — Any active changes (proposals, delta specs)
+4. `openspec/specs/` — Shared cross-project specs (api-patterns, nl-design, nextcloud-app)
+
+Build a mental model of:
+- What the project does
+- Who it's for
+- What features exist
+- What APIs are exposed
+- What the UI looks like
+- What standards it must comply with
+
+### Step 1.5: Select Agent Model
+
+Ask the user using AskUserQuestion:
+
+**"Which model should the persona agents use?"**
+
+| Model | Speed | Quota | Best for |
+|---|---|---|---|
+| **Haiku** | Fastest | Low | Parallel runs — broad coverage, efficient |
+| **Sonnet** | Balanced | Moderate | Better reasoning, more nuanced findings |
+| **Opus** | Slowest | High | Deepest analysis — for critical or final runs |
+
+- **Sonnet (default)** — Recommended. No browser snapshots involved — agents read specs and docs only, so context window size is not a concern. Better reasoning produces more useful feature suggestions.
+- **Haiku** — Faster, lower quota. Use when you want a quick broad pass rather than depth.
+- **Opus** — Highest quality analysis. With 8 agents running in parallel this uses substantial quota — best reserved for final pre-release testing or targeted critical reviews.
+
+Store as `{MODEL}`:
+- Haiku → `"haiku"`
+- Sonnet → `"sonnet"`
+- Opus → `"opus"`
+
+### Step 2: Launch Persona Agents in Parallel
+
+Launch 8 Task agents in parallel (all in a single message), one per persona. Each agent evaluates the specs from their persona's perspective. Use `subagent_type: "general-purpose"` and `model: "{MODEL}"` (from Step 1.5).
+
+**Sub-agent prompt template** (replace `{PERSONA_NAME}`, `{PERSONA_FILE}`, `{PROJECT}`, and `{PERSPECTIVE}`):
+
+```
+You are a Feature Counsel advisor representing **{PERSONA_NAME}**.
+
+## Your Persona
+Read the persona card at `.claude/personas/{PERSONA_FILE}` to understand your character's background, digital skills, frustrations, needs, and behavior. Stay fully in character.
+
+## Your Task
+Analyze the OpenSpec specifications of the **{PROJECT}** project and suggest features, improvements, or changes from your persona's perspective.
+
+## Read These Files
+1. `{PROJECT}/project.md` — Project context
+2. All files in `{PROJECT}/openspec/specs/` — Current specifications
+3. All files in `{PROJECT}/openspec/changes/` — Active changes (if any)
+4. Relevant shared specs in `openspec/specs/` (api-patterns, nl-design, nextcloud-app)
+
+## Analysis Focus: {PERSPECTIVE}
+
+For each spec section, ask yourself:
+- Does this feature serve my needs as {PERSONA_NAME}?
+- What's missing that I would need?
+- What would frustrate me about this design?
+- What would make this easier/better/more compliant for people like me?
+
+## Output Format
+
+Return your analysis as a structured report:
+
+```markdown
+# Feature Counsel: {PERSONA_NAME} — {one-line role description}
+
+## Overall Assessment
+{2-3 sentences from your persona's perspective on whether this project serves your needs}
+
+## Missing Features (things I need that aren't in the specs)
+| # | Feature | Priority | Why I need this | Spec section affected |
+|---|---------|----------|-----------------|----------------------|
+| 1 | {feature name} | MUST/SHOULD/COULD | "{persona perspective}" | {which spec} |
+
+## Improvement Suggestions (existing features that need enhancement)
+| # | Current Feature | Suggested Improvement | Why | Spec section |
+|---|----------------|----------------------|-----|-------------|
+| 1 | {feature} | {improvement} | "{persona perspective}" | {spec} |
+
+## Compliance/Standards Gaps (from my perspective)
+| # | Gap | Standard/Requirement | Impact | Recommendation |
+|---|-----|---------------------|--------|----------------|
+| 1 | {gap} | {standard} | HIGH/MEDIUM/LOW | {recommendation} |
+
+## Usability Concerns
+| # | Concern | Severity | {PERSONA_NAME} would say... |
+|---|---------|----------|----------------------------|
+| 1 | {concern} | HIGH/MEDIUM/LOW | "{in-character quote}" |
+
+## {PERSONA_NAME}'s Top 3 Recommendations
+1. {most important suggestion with rationale}
+2. {second most important}
+3. {third most important}
+```
+```
+
+**Agent assignments:**
+
+| Agent | Persona | Perspective Focus |
+|-------|---------|-------------------|
+| 1 | Henk Bakker | Accessibility, readability, plain Dutch, elderly-friendly design, text size, button size, simple navigation |
+| 2 | Fatima El-Amrani | Visual design, literacy barriers, icon usage, mobile-first, minimal text, RTL support, B1 language level |
+| 3 | Sem de Jong | Performance, keyboard shortcuts, dark mode, loading states, modern UX patterns, URL state, developer console |
+| 4 | Noor Yilmaz | Security features, audit trails, RBAC, BIO2 compliance, ENSIA readiness, AVG/GDPR, data minimization |
+| 5 | Annemarie de Vries | GEMMA alignment, Common Ground 5-layer, NLGov API Design Rules, interoperability, publiccode.yml, FSC |
+| 6 | Mark Visser | Business efficiency, CRUD workflows, Dutch business terminology, status indicators, bulk operations, export |
+| 7 | Priya Ganpat | API quality, OpenAPI spec, developer experience, error handling, pagination, webhooks, integration readiness |
+| 8 | Jan-Willem van der Berg | Plain language, no jargon, simple forms, findability, contact info, 3-click rule, Dutch B1 level |
+
+### Step 3: Synthesize the Results
+
+After all 8 agents complete, read their reports and create a synthesized Feature Counsel report.
+
+**Write the synthesis to**: `{PROJECT}/openspec/feature-counsel-report.md`
+
+```markdown
+# Feature Counsel Report: {PROJECT}
+
+**Date:** {today's date}
+**Method:** 8-persona feature advisory analysis against OpenSpec specifications
+**Personas:** Henk Bakker, Fatima El-Amrani, Sem de Jong, Noor Yilmaz, Annemarie de Vries, Mark Visser, Priya Ganpat, Jan-Willem van der Berg
+
+---
+
+## Executive Summary
+
+{3-5 sentences summarizing the overall findings across all personas}
+
+---
+
+## Consensus Features (suggested by 3+ personas)
+
+| # | Feature | Suggested by | Priority | Impact |
+|---|---------|-------------|----------|--------|
+| 1 | {feature} | {persona names} | MUST/SHOULD/COULD | {why it matters} |
+
+---
+
+## Per-Persona Highlights
+
+### Henk Bakker (Elderly Citizen)
+- **Top need**: {one-liner}
+- **Key missing feature**: {feature}
+- **Quote**: "{in-character Dutch quote}"
+
+### Fatima El-Amrani (Low-Literate Migrant)
+...{repeat for all 8}
+
+---
+
+## Feature Suggestions by Category
+
+### Accessibility & Inclusivity
+| # | Feature | Personas | Priority | Notes |
+|---|---------|----------|----------|-------|
+| 1 | {feature} | {who suggested} | {priority} | {details} |
+
+### Security & Compliance
+| # | Feature | Personas | Priority | Standard |
+|---|---------|----------|----------|----------|
+| 1 | {feature} | {who suggested} | {priority} | {BIO2/AVG/etc} |
+
+### API & Developer Experience
+| # | Feature | Personas | Priority | Notes |
+|---|---------|----------|----------|-------|
+| 1 | {feature} | {who suggested} | {priority} | {details} |
+
+### UX & Performance
+| # | Feature | Personas | Priority | Notes |
+|---|---------|----------|----------|-------|
+| 1 | {feature} | {who suggested} | {priority} | {details} |
+
+### Standards & Interoperability
+| # | Feature | Personas | Priority | Standard |
+|---|---------|----------|----------|----------|
+| 1 | {feature} | {who suggested} | {priority} | {GEMMA/NLGov/etc} |
+
+### Business & Workflow
+| # | Feature | Personas | Priority | Notes |
+|---|---------|----------|----------|-------|
+| 1 | {feature} | {who suggested} | {priority} | {details} |
+
+---
+
+## Recommended Actions
+
+### MUST (blocking for key user groups)
+1. {action + rationale}
+
+### SHOULD (significant improvement for multiple personas)
+1. {action + rationale}
+
+### COULD (nice-to-have, improves specific persona experience)
+1. {action + rationale}
+
+---
+
+## Potential OpenSpec Changes
+
+These features could be turned into OpenSpec changes using `/opsx-new`:
+
+| Change Name | Description | Related Personas | Estimated Complexity |
+|-------------|-------------|-----------------|---------------------|
+| {change-name} | {description} | {personas} | S/M/L/XL |
+```
+
+### Step 4: Report to User
+
+Display a concise summary to the user:
+- Number of features suggested across all personas
+- Top consensus features (suggested by 3+ personas)
+- Top 5 recommended actions
+- Link to the full report: `{PROJECT}/openspec/feature-counsel-report.md`
+- Offer to create OpenSpec changes for any of the suggested features
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
diff --git a/.claude/skills/feature-counsel/evals/evals.json b/.claude/skills/feature-counsel/evals/evals.json
new file mode 100644
index 00000000..988a5ae7
--- /dev/null
+++ b/.claude/skills/feature-counsel/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"feature-counsel","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"multi-persona","description":"Analyze from 8 perspectives","prompt":"Run /feature-counsel on openregister","setup":"App with specs defined","expected":"Should spawn 8 persona agents in parallel","assertions":["Launches 8 persona agents","Each analyzes specs from their perspective","Identifies missing features per persona","Synthesizes into feature-counsel-report.md"]},{"id":"suggestions","description":"Suggest concrete features","prompt":"Check feature suggestions quality","setup":"Analysis complete","expected":"Should suggest specific, actionable features","assertions":["Suggests features with clear user value","Links suggestions to personas who need them","Identifies compliance gaps (GEMMA, BIO2)","Suggests OpenSpec changes for top features"]},{"id":"model-selection","description":"Supports model selection","prompt":"Run with Haiku agents","setup":"User selects model per agent","expected":"Should respect model choice","assertions":["Accepts model parameter (Haiku/Sonnet/Opus)","Spawns agents with specified model","Reports which model each persona used"]}],"trigger_tests":{"should_trigger":["analyze features from personas","feature counsel","suggest features for openregister","what features are missing","persona feature analysis"],"should_not_trigger":["test the app","test counsel","implement features","explore the app","design the app"]}}
diff --git a/.claude/skills/feature-counsel/learnings.md b/.claude/skills/feature-counsel/learnings.md
new file mode 100644
index 00000000..54630d3f
--- /dev/null
+++ b/.claude/skills/feature-counsel/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — feature-counsel
+
+## Patterns That Work
+<!-- Approaches that consistently produce good results -->
+
+## Mistakes to Avoid
+<!-- Errors encountered and how they were resolved -->
+
+## Domain Knowledge
+<!-- Facts discovered during execution -->
+
+## Open Questions
+<!-- Unresolved items for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 00000000..d474dc13
--- /dev/null
+++ b/.claude/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 00000000..9b1f851a
--- /dev/null
+++ b/.claude/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
new file mode 100644
index 00000000..ffa10cad
--- /dev/null
+++ b/.claude/skills/openspec-explore/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
new file mode 100644
index 00000000..d27bc531
--- /dev/null
+++ b/.claude/skills/openspec-propose/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/opsx-apply-loop/SKILL.md b/.claude/skills/opsx-apply-loop/SKILL.md
new file mode 100644
index 00000000..79ec421b
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/SKILL.md
@@ -0,0 +1,470 @@
+---
+name: opsx-apply-loop
+description: Iteratively run apply→verify in a loop until verify passes, then auto-archive — runs per-app in Docker context
+metadata:
+  category: Workflow
+  tags: [workflow, automated, loop, docker, experimental]
+---
+
+**Check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- **On Haiku**: stop immediately:
+  > "This command requires Sonnet or Opus — the apply→verify loop needs strong reasoning to implement tasks and evaluate verification results. Please switch to Sonnet (`/model sonnet`) or Opus (`/model opus`) and re-run."
+- **On Sonnet or Opus**: proceed normally.
+
+---
+
+**Check container authentication** — follow the procedure in [references/container-auth-check.md](references/container-auth-check.md). Stop immediately if no credentials are found.
+
+---
+
+**AUTONOMOUS MODE — This skill is a fully automated orchestrator.** The standard CLAUDE.md workflow (ask clarifying questions → present plan → wait for approval) does NOT apply here. Do NOT pause between steps to ask for confirmation or approval unless a step explicitly says to use AskUserQuestion. Proceed through all steps automatically. When an inline skill completes and returns control, immediately continue to the next numbered step without waiting.
+
+---
+
+Automated orchestrator: runs `opsx-apply` → `opsx-verify` in a loop until verify is clean, optionally runs targeted tests (on host), then runs `opsx-archive`. The apply→verify loop runs inside an isolated Docker container (Claude CLI + app files only, no git, no GitHub). Tests run outside the container. Host handles testing, archive, branch creation, GitHub sync, and git commits.
+
+Each app in this workspace has its own git repository. The container mounts the app's directory and a read-only copy of the shared `.claude/` skills. Nextcloud containers must be running on the host for environment checks and post-container testing.
+
+```
+[host] issue check → branch (from development) → container start (app dir + .claude skills)
+  [container] apply → verify → loop (max 5) → verify-clean → exit
+[host] test loop (optional, max 3) → deferred tests (optional, once) → archive (once) → git commit → github sync
+```
+
+**Input**: Optionally specify `<app> <change-name>` (e.g., `/opsx-apply-loop procest add-sla-tracking`). If omitted, prompt for app and change.
+
+---
+
+## Step 1: Select app and change
+
+**If both app and change name are provided**, use them directly.
+
+**If only one argument is provided**, treat it as the change name and scan all apps for a match.
+
+**Otherwise**, scan all app directories for active changes and use **AskUserQuestion** to let the user select:
+
+```bash
+# Scan for active changes across all apps
+for app in procest pipelinq openregister opencatalogi docudesk mydash nldesign openconnector softwarecatalog zaakafhandelapp openklant larpingapp planix; do
+  if [ -d "$app/openspec/changes" ]; then
+    for change_dir in $app/openspec/changes/*/; do
+      if [ -f "${change_dir}tasks.md" ] && [[ "$change_dir" != *"/archive/"* ]]; then
+        echo "$app: $(basename $change_dir)"
+      fi
+    done
+  fi
+done
+```
+
+Ask the user to select from the list. Do not auto-select.
+
+Store as `{APP}` and `{CHANGE_NAME}`. All subsequent file paths use `{APP}/openspec/changes/{CHANGE_NAME}/`.
+
+Always announce: "Using change: `<app>/<change-name>`" and how to override.
+
+---
+
+## Step 2: Check GitHub issue — create if missing
+
+Check whether a GitHub tracking issue already exists for this change:
+
+```bash
+cat {APP}/openspec/changes/{CHANGE_NAME}/plan.json 2>/dev/null | grep -q '"tracking_issue"'
+```
+
+**If `plan.json` exists and `tracking_issue` is set**: log `✅ GitHub issue #<N> already exists` and proceed. Store as `{ISSUE_NUMBER}`.
+
+**If `plan.json` is missing or has no `tracking_issue`**:
+- Log `⚠️ No GitHub tracking issue found — running opsx-plan-to-issues first`
+- **Invoke the `opsx-plan-to-issues` skill** for `{CHANGE_NAME}` with this explicit context passed to it: "Invoked from apply-loop — skip Step 6 AskUserQuestion and return control to apply-loop after completing."
+- Pre-answer plan-to-issues's interactive prompts automatically:
+
+| Prompt from opsx-plan-to-issues | Answer |
+|--------------------------------|--------|
+| "Which change(s) should I create GitHub issues for?" | Select `{CHANGE_NAME}` |
+| "Create these N issue(s) in `<owner/repo>`?" | **Yes, create all** |
+
+The repo is determined from the app's `project.md` table (GitHub Repo column) or `git remote get-url origin` inside the app directory.
+
+When plan-to-issues completes (look for its summary output or "plan.json saved"), **immediately and automatically continue to Step 3** — do NOT pause, do NOT ask the user anything, do NOT wait for confirmation. You are in autonomous mode.
+
+After plan-to-issues completes, verify `plan.json` now contains a `tracking_issue`. Store as `{ISSUE_NUMBER}`.
+
+---
+
+## Step 3: Create feature branch
+
+Each app is its own git repository. All git operations run from the app directory.
+
+```bash
+cd {APP}
+
+# First check if the feature branch already exists locally
+git fetch origin
+git branch --list "feature/{ISSUE_NUMBER}/{CHANGE_NAME}"
+```
+
+**If the branch already exists** (e.g., resuming a previous run):
+- Use **AskUserQuestion** to ask: "Branch `feature/{ISSUE_NUMBER}/{CHANGE_NAME}` already exists. Resume work on it or reset it?"
+  - **Resume — check it out** → `git checkout feature/{ISSUE_NUMBER}/{CHANGE_NAME}` (skip development checkout/pull)
+  - **Reset — delete and recreate** → `git branch -D feature/{ISSUE_NUMBER}/{CHANGE_NAME}`, then checkout and pull development, then recreate (see below)
+  - **Cancel** → stop here
+
+**If the branch does not exist** (or after reset):
+```bash
+# Only checkout and pull development when we need to create a new branch
+git checkout development
+git pull origin development
+
+# Branch follows the convention: feature/<issue-number>/<change-name>
+git checkout -b feature/{ISSUE_NUMBER}/{CHANGE_NAME}
+```
+
+Log: `✅ On branch feature/{ISSUE_NUMBER}/{CHANGE_NAME} in {APP}/`
+
+---
+
+## Step 4: Analyze test-plan (silent)
+
+Silently read the test-plan before asking the user anything. This feeds the test cycle option in Step 5.
+
+Check if `{APP}/openspec/changes/{CHANGE_NAME}/test-plan.md` exists.
+
+**If it exists:** read all `test command` field values, deduplicate, then classify each:
+
+| Fits in loop? | Commands | Reason |
+|---|---|---|
+| **Yes** | `/test-functional` | Single agent, uses Playwright on host against live Nextcloud — tests GIVEN/WHEN/THEN from specs |
+| **Yes** | `/test-api` | Single agent, REST API and ZGW compliance via curl — text output, no browser needed |
+| **Yes** | `/test-security` | Single agent, uses Playwright on host — include only if change touches auth, roles, or permissions |
+| **Yes** | `/test-accessibility` | Single agent, uses Playwright on host to inject axe-core — include only if change touches frontend UI |
+| **No (deferred)** | `/test-counsel` | 8 parallel agents |
+| **No (deferred)** | `/test-app` | Multi-agent or full-app sweep |
+| **No (deferred)** | `/test-persona-*` | Too broad, not change-specific |
+| **No (deferred)** | `/test-regression`, `/test-performance` | Cross-feature or non-blocking |
+
+Rules:
+- Any persona-specific command (`/test-persona-*`) that appears in the test-plan → replace with `/test-functional` in `{TEST_COMMANDS_IN_LOOP}` (same coverage, single agent)
+- If no test-plan exists but tests are opted in → default `{TEST_COMMANDS_IN_LOOP}` = `[/test-functional]`
+- All "fits in loop" commands run on the **host** (Step 9) via Playwright MCP and the live Nextcloud app — none of them run inside the Docker container
+
+Store:
+- `{TEST_COMMANDS_IN_LOOP}` — the filtered commands to run in the automated test loop
+- `{TEST_COMMANDS_DEFERRED}` — the excluded commands to surface at the end (Step 13)
+- `{TEST_PLAN_EXISTS}` — true/false
+
+---
+
+## Step 5: Confirm and show plan
+
+Use **AskUserQuestion** to ask:
+
+> "Ready to run `opsx-apply-loop` for `{APP}/{CHANGE_NAME}`?
+>
+> **Branch:** `feature/{ISSUE_NUMBER}/{CHANGE_NAME}` in `{APP}/`
+> **GitHub issue:** #`{ISSUE_NUMBER}`
+>
+> **Apply→verify loop** (inside isolated Docker container):
+> - Max 5 iterations; CRITICAL issues stop the loop; warnings-only proceeds to archive
+>
+> **Optional: test cycle** (outside container, requires running Nextcloud environment):
+> - After verify is clean, runs: `<list TEST_COMMANDS_IN_LOOP, or 'test-functional (default)' if no test-plan>`
+> - Max 3 test iterations; if tests fail, loops back into apply→verify
+> - ⚠️ These tests run on your host using the live Nextcloud app — NOT inside the container"
+
+Options:
+- **Start with test cycle** — include Phase 4 tests (set `{TESTS_ENABLED}=true`)
+- **Start without tests** — skip test cycle (set `{TESTS_ENABLED}=false`)
+- **Cancel** — stop here
+
+---
+
+## Step 6: Set up the apply-loop container
+
+Read [references/container-setup-guide.md](references/container-setup-guide.md) for the full procedure: creating the log folder (6.1), scanning prior run history (6.2), version checks and image build (6.3), network creation (6.4), container startup with prompt construction (6.5, including the full startup prompt text), monitoring loop (6.6), and container exit handling with all 5 scenarios (6.7). Apply all sub-steps now.
+
+> Steps 7–8 execute **inside the container** by the container's Claude CLI session. The startup prompt (in references/container-setup-guide.md Step 6.5) directs the container to read [references/apply-verify-loop-protocol.md](references/apply-verify-loop-protocol.md).
+
+---
+
+> The steps below (9–15) execute on the **host**, after the container has exited.
+
+---
+
+## Step 9: Host test loop (conditional)
+
+**Skip this step entirely if `{TESTS_ENABLED}=false`.** Proceed directly to Step 10.
+
+Read [references/host-test-loop-protocol.md](references/host-test-loop-protocol.md) for the full protocol: Nextcloud environment check, in-loop test command execution via Agent tool (9a), test result evaluation (9b), and container re-entry for test-failure fixes (9c). Apply the full procedure now.
+
+---
+
+## Step 10: Deferred tests (conditional)
+
+**Skip this step if any of these are true:**
+- `{TESTS_ENABLED}=false`
+- `{TEST_COMMANDS_DEFERRED}` is empty
+- The test loop exhausted in Step 9 with unresolved failures and the user chose to cancel
+
+If applicable, use **AskUserQuestion** to ask:
+
+> "The following test commands were in your test-plan but were not included in the automated loop (multi-agent or broad-scope):
+>
+> <list {TEST_COMMANDS_DEFERRED} with reason each was excluded>
+>
+> Would you like to run these now? If any fail, one final apply→verify cycle will run to address the findings before archiving."
+
+Options:
+- **Yes, run them** — proceed
+- **Skip** — proceed to Step 11 (archive)
+
+**If yes:**
+
+Use the **Agent tool** (NOT the Skill tool) to run each command in `{TEST_COMMANDS_DEFERRED}` sequentially, exactly as described in Step 9a — construct the skill file path, launch a general-purpose Agent in READ-ONLY mode, and read its structured result line. Run all commands once (not looped). After each Agent returns, immediately continue to the next — do NOT pause between commands.
+
+> **Note — reduced parallelism**: Sub-agents spawned via the Agent tool do not have access to the Agent tool themselves, so multi-agent skills like `/test-counsel` (which normally runs 8 persona agents in parallel) will run sequentially instead. Coverage is the same; it just takes longer. This is expected and acceptable for the deferred test pass.
+
+**If all pass**: log `✅ Deferred tests all passed` — **immediately and automatically continue to Step 11** (archive).
+
+**If any fail**:
+- Log: `⚠️ Deferred test failures found — running one final apply→verify cycle`
+- Write failures: `FAIL_TIME=$(date +%H:%M)` then write to `${LOG_DIR}/apply-loop-${FAIL_TIME}-test-failures-${TEST_ITERATION}.log`
+- Start one final container run (Step 6.5, test-failure re-entry variant)
+- Wait for exit; handle per Step 6.7
+- **Immediately and automatically continue to Step 11** regardless of `STATUS` (report exhaustion if needed, but archive once)
+
+---
+
+## Step 11: Archive (host)
+
+**Use the Agent tool (NOT the Skill tool)** to run `opsx-archive`. The Agent tool runs as a subprocess and returns results directly — this is what allows the orchestrator to continue to Steps 12–15 after archiving. Using the Skill tool inline would terminate the conversation instead of returning control.
+
+Construct the skill file path:
+```
+CLAUDE_SKILLS="$(cd {APP}/.. && pwd)/.claude/skills"
+SKILL_FILE="${CLAUDE_SKILLS}/opsx-archive/SKILL.md"
+```
+
+Launch a **general-purpose Agent** with a prompt that includes:
+1. "Read and follow the skill instructions at `{SKILL_FILE}`."
+2. "Change: `{CHANGE_NAME}`. Working directory: `$(pwd)/{APP}/`."
+3. "You are invoked from apply-loop — do NOT close the GitHub issue (that is handled by the host in Step 13c). Return control to apply-loop after completing."
+4. Pre-answered prompts:
+
+| Prompt from opsx-archive | Answer |
+|--------------------------|--------|
+| "Sync delta specs first?" | **Sync now** |
+| "Convert test cases to test scenarios?" (step 4.5) | **Skip** — apply-loop asks after all loops finish (Step 14) |
+| "Close GitHub issue #N?" | **No, leave it open** |
+
+5. "End with the line `ARCHIVE_RESULT: DONE  ARCHIVE_PATH: <path>`. Output nothing after the result line."
+
+The archive skill handles: artifact completion check, delta spec sync, spec link updates in main specs, `docs/features/` updates, and `CHANGELOG.md`.
+
+When the Agent returns, extract `{ARCHIVE_PATH}` from the result line.
+
+**Immediately and automatically continue to Step 12** — do NOT pause or wait for user input.
+
+Log: `📦 Change archived`
+
+---
+
+## Step 12: Git commit (host)
+
+Commit all changes — implementation, test fixes, and archive artifacts — in one commit. Run from the app directory:
+
+```bash
+cd {APP}
+git add .
+git status  # review what changed
+git commit -m "feat: implement {CHANGE_NAME}
+
+Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"
+```
+
+Log: `✅ Changes committed to feature/{ISSUE_NUMBER}/{CHANGE_NAME} in {APP}/`
+
+---
+
+## Step 13: GitHub sync (host)
+
+The container skipped all GitHub operations. Run them now from the host using the gh CLI.
+
+**13a. Final checkbox sync** — verify the issue reflects the fully archived state of `tasks.md`. Earlier syncs (Step 6.7 Scenario A and Step 9c) updated checkboxes from the pre-archive location; this final sync reads the archived copy to ensure nothing was missed:
+- Read `{APP}/openspec/changes/archive/YYYY-MM-DD-{CHANGE_NAME}/tasks.md` (archived location)
+- For every task marked `[x]`, ensure the corresponding checkbox is checked in issue #`{ISSUE_NUMBER}` — update any that are still unchecked:
+  - **MCP (preferred):** `get_issue` → find any remaining `- [ ]` task lines → change to `- [x]` → `update_issue` (single call)
+  - **CLI (fallback):** `gh issue view {ISSUE_NUMBER} --repo <owner/app> --json body --jq '.body'` → update checkboxes → `gh issue edit {ISSUE_NUMBER} --repo <owner/app> --body "<updated>"`
+
+**13b. Add a completion comment** to the issue:
+- **MCP (preferred):** `add_issue_comment` → `{owner, repo, issue_number: {ISSUE_NUMBER}, body: "✓ apply-loop complete — all tasks implemented and verified. Change archived to {APP}/openspec/changes/archive/YYYY-MM-DD-{CHANGE_NAME}/"}`
+- **CLI (fallback):** `gh issue comment {ISSUE_NUMBER} --repo <owner/app> --body "..."`
+
+**13c. Ask about closing the issue** using **AskUserQuestion**:
+
+> "Close GitHub issue #{ISSUE_NUMBER}?"
+
+Options:
+- **Yes, close it** — `gh issue close {ISSUE_NUMBER} --repo <owner/app>`
+- **No, leave it open** — skip (e.g., if a PR review will handle it)
+
+Log: `✅ GitHub issue synced`
+
+---
+
+## Step 14: Post-archive — test scenario conversion
+
+Check if `{APP}/openspec/changes/archive/YYYY-MM-DD-{CHANGE_NAME}/test-plan.md` exists.
+
+**If test-plan.md exists**, use **AskUserQuestion** to ask:
+
+> "The change had a test-plan.md. Convert test cases to reusable test scenarios?
+>
+> Test scenarios are picked up automatically by `/test-counsel`, `/test-app`, and persona test commands."
+
+Options:
+- **Yes, convert all** — run the test scenario conversion step from opsx-archive
+- **Let me choose** — list each TC, user picks which to convert
+- **Skip** — do not create test scenarios
+
+**If test-plan.md does not exist**: skip silently.
+
+---
+
+## Step 15: Final report and what's next
+
+Before composing the report, **read all log files** in `${LOG_DIR}` to ensure the summary reflects everything that actually happened across all container runs and test iterations:
+
+```bash
+ls -t "${LOG_DIR}"/
+```
+
+Read each file:
+- All `apply-loop-*-result.log` files — collect STATUS, ITERATIONS, WARNINGS_ONLY from each run
+- All `apply-loop-*-container.log` files — skim for apply/verify outcomes per iteration
+- All `apply-loop-*-test-failures-*.log` files — note which test iterations failed and what was reported
+- The in-memory iteration log you maintained throughout this session
+
+Reconcile any discrepancies between the in-memory log and the file contents — the files are authoritative.
+
+Then display the complete report:
+
+```
+## opsx-apply-loop — {APP}/{CHANGE_NAME}
+
+### Loop Log
+| Iter | Phase         | Result                    | Notes                       |
+|------|---------------|---------------------------|-----------------------------|
+| 1    | apply         | 4 tasks implemented       | Quality: ✓ pass             |
+| 1    | verify        | 1 CRITICAL                | Missing unit test           |
+| 2    | apply         | Fixed: added test         | Quality: ✓ pass             |
+| 2    | verify        | ✓ Clean                   | —                           |
+| T1   | test-functional | ✓ Pass                  | —                           |
+| —    | archive       | ✓ Archived               | {APP}/openspec/changes/archive/ |
+
+### Summary
+- App: {APP}
+- Branch: feature/{ISSUE_NUMBER}/{CHANGE_NAME} (committed)
+- Apply→verify iterations used: 2 / 5
+- Test iterations used: 1 / 3 (or: tests skipped)
+- Final verify status: ✓ Clean
+- Warnings noted: 0
+- Archive: ✓ {APP}/openspec/changes/archive/YYYY-MM-DD-{CHANGE_NAME}/
+- GitHub issue: #{ISSUE_NUMBER} synced + closed / left open
+```
+
+Write the same report to a file **first, before any cleanup**:
+
+```bash
+cat > "${LOG_DIR}/final-result.md" << 'EOF'
+<the full report text above>
+EOF
+```
+
+Then run the **per-file log cleanup**. The goal is to delete files whose content is fully superseded (all issues they mention were resolved), while keeping any file that references an issue still open in the final state.
+
+**What counts as currently unresolved**: any CRITICAL or WARNING that appears in the final `result` or final `container.log` and was NOT fixed in a subsequent iteration. Specifically:
+- `WARNINGS_ONLY=true` in the final result → there are still warnings; the final `container.log` is needed as evidence
+- A test-failures file → its failures are unresolved UNLESS a subsequent `container.log` or `result` shows those areas were fixed and verify passed clean after
+
+Evaluate each file:
+
+| File type | Delete if… | Keep if… |
+|---|---|---|
+| `apply-loop-*-result.log` (non-final) | All issues it reported were fixed in a later iteration | It's the most recent, or its issues are still open |
+| `apply-loop-*-container.log` (non-final) | All CRITICALs/WARNINGs it reported were fixed in a later run | It references issues still unresolved in the final state |
+| `apply-loop-*-container.log` (final/most recent) | — | Always keep |
+| `apply-loop-*-test-failures-*.log` | The specific failures it lists were fixed (a later container run shows verify-clean covering those areas) | The failures were never resolved |
+
+Always keep: `final-result.md`, the most recent `container.log`, the most recent `result`.
+
+Log which files were deleted and which were kept, with the reason for each kept file.
+
+Then use **AskUserQuestion** to ask: "What would you like to do next?"
+
+Options:
+- **Create a PR** (`/create-pr`) — open a pull request from `feature/{ISSUE_NUMBER}/{CHANGE_NAME}` in `{APP}/`
+- **Sync app docs** (`/sync-docs app {APP}`) — update `{APP}/docs/` to reflect the new feature
+- **Sync dev docs** (`/sync-docs dev`) — update `.claude/docs/`
+- **Start a new change** (`/opsx-new`)
+- **Done for now** — end the session
+
+---
+
+**If loop exhausted (CRITICAL issues remain after 5 apply→verify iterations)**:
+
+```
+⛔ Loop stopped after 5 iterations — CRITICAL issues remain.
+
+### Remaining CRITICAL issues:
+- <issue 1 with file:line reference>
+- <issue 2 with file:line reference>
+```
+
+The container has exited. The feature branch in `{APP}/` has partial changes. Use **AskUserQuestion** to ask: "How would you like to proceed?"
+
+- **Fix manually, then re-run** — edit files in `{APP}/` on the feature branch and run `/opsx-apply-loop {APP} {CHANGE_NAME}` again
+- **Open verify interactively** — run `/opsx-verify {CHANGE_NAME}` from within `{APP}/` to inspect in detail
+- **Commit partial work and open a draft PR** — commit what's there, open a draft PR for review
+- **Abandon branch** — `cd {APP} && git checkout -` and `git branch -D feature/{ISSUE_NUMBER}/{CHANGE_NAME}`
+
+---
+
+## Container Limitations
+
+See [references/container-limitations.md](references/container-limitations.md) for the full table of what the container cannot do (and which host step handles each), container volume mappings, and the optional iptables network restriction to `api.anthropic.com`.
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+## Guardrails
+
+- **Orchestrator only — NO direct code changes** — the host (orchestrator) session MUST NOT edit, create, or delete code files directly. All code changes — including fixes to dependency bugs discovered during testing — must go through the container's apply→verify loop. If a discovered bug is in a file the container cannot access (e.g., a different app's directory not mounted in the container), use **AskUserQuestion** to ask the user how they want to handle it before proceeding.
+- **Orchestrator only** — this skill does not implement, verify, archive, or test directly; it delegates to `opsx-apply`, `opsx-verify`, `opsx-archive`, and the test commands
+- **Per-app isolation** — all git operations, quality checks, and openspec commands run from within `{APP}/`; never across app boundaries
+- **Host handles git, GitHub, tests, and archive** — all git commits, GitHub API calls, browser tests, and archive happen on the host; the container only runs apply→verify
+- **Max 5 apply→verify iterations** — CRITICAL issues stop the loop after all iterations are exhausted; warnings-only always proceeds
+- **Max 3 test iterations** — test failures loop back into apply→verify a maximum of 3 times; on exhaustion the user chooses whether to archive anyway
+- **Deferred tests run once** — multi-agent/broad tests deferred from the loop are run once at most; if they fail, exactly one more apply→verify cycle runs (no further test looping)
+- **Container is stateless** — it writes file changes to the mounted app volume and result/failure files to `.claude/logs/` via the third volume mount (already gitignored); the host reads those on exit
+- **Pre-answer all interactive prompts** — apply, verify, and archive prompts are answered automatically (see prompt tables); the only interactive moments are closing the GitHub issue (Step 13c) and deferred tests (Step 10)
+- **Archive runs exactly once** — deferred tests (Step 10) run before archive (Step 11); there is no re-archive
+- **Single git commit** — all changes from all apply→verify cycles, all test fixes, and the archive are committed together in Step 12
+- **Test scenario conversion is deferred** — archive's step 4.5 is skipped; apply-loop asks in Step 14
+- **No force push, no destructive git ops** — same git safety rules as all opsx skills
+- **Branch naming convention** — `feature/<issue-number>/<change-name>` to match the opsx-pipeline convention used across this workspace
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`) when done.
diff --git a/.claude/skills/opsx-apply-loop/assets/apply-loop-check.sh b/.claude/skills/opsx-apply-loop/assets/apply-loop-check.sh
new file mode 100644
index 00000000..3d4ed7f0
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/assets/apply-loop-check.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+# apply-loop-check.sh — single-poll status check for the apply-loop container
+# Run once per monitoring cycle. Claude re-runs it in a loop, printing a brief status
+# update to the user after each invocation (~1 min per cycle).
+#
+# Usage: apply-loop-check.sh <container-name> <work-dir>
+#
+# Exit codes:
+#   0 = container still running — re-run to continue monitoring
+#   1 = container stopped
+#   2 = stuck detected (no file changes or output for STUCK_THRESHOLD seconds)
+#   3 = usage error
+
+CONTAINER="$1"
+WORK_DIR="$2"
+LIVE_LOG="$3"   # optional — if provided, all output is also appended to this file
+
+if [ -z "$CONTAINER" ] || [ -z "$WORK_DIR" ]; then
+  echo "Usage: $0 <container-name> <work-dir> [live-log-path]"
+  exit 3
+fi
+
+# Tee all output to the live log if provided
+if [ -n "$LIVE_LOG" ]; then
+  exec > >(tee -a "$LIVE_LOG") 2>&1
+fi
+
+CHECK_INTERVAL=60
+STUCK_THRESHOLD=300  # 5 minutes
+
+# Persistent state files — survive across invocations for the same container run
+ACTIVITY_REF="/tmp/apply-loop-activity-${CONTAINER}"
+LAST_ACTIVITY_FILE="/tmp/apply-loop-last-activity-${CONTAINER}"
+
+# Initialize on first invocation
+[ -f "$ACTIVITY_REF" ] || touch "$ACTIVITY_REF"
+[ -f "$LAST_ACTIVITY_FILE" ] || date +%s > "$LAST_ACTIVITY_FILE"
+LAST_ACTIVITY_TIME=$(cat "$LAST_ACTIVITY_FILE")
+
+# Quick-poll every 5s within the interval to catch early container exit
+ELAPSED=0
+while [ $ELAPSED -lt $CHECK_INTERVAL ]; do
+  STATUS=$(docker inspect "$CONTAINER" --format '{{.State.Status}}' 2>/dev/null || echo "gone")
+  if [ "$STATUS" != "running" ]; then
+    EXIT_CODE=$(docker inspect "$CONTAINER" --format '{{.State.ExitCode}}' 2>/dev/null || echo "n/a")
+    echo "CONTAINER_STOPPED status=$STATUS exit_code=$EXIT_CODE"
+    DOCKER_FINAL=$(docker logs "$CONTAINER" --tail 10 2>&1)
+    [ -n "$DOCKER_FINAL" ] && echo "--- final docker logs (last 10) ---" && echo "$DOCKER_FINAL"
+    rm -f "$ACTIVITY_REF" "$LAST_ACTIVITY_FILE"
+    exit 1
+  fi
+  sleep 5
+  ELAPSED=$((ELAPSED + 5))
+done
+
+# Gather evidence after the interval
+NOW=$(date +%s)
+DOCKER_RECENT=$(docker logs "$CONTAINER" --since 65s 2>&1 | tail -5)
+DOCKER_STATS=$(docker stats "$CONTAINER" --no-stream --format "CPU: {{.CPUPerc}}  MEM: {{.MemUsage}}" 2>/dev/null)
+CHANGED_FILES=$(find "$WORK_DIR" -newer "$ACTIVITY_REF" \
+  -not -path '*/.git/*' -not -path '*/vendor/*' -not -path '*/node_modules/*' \
+  -type f 2>/dev/null | head -10)
+
+HAS_ACTIVITY=false
+[ -n "$DOCKER_RECENT" ] && HAS_ACTIVITY=true
+[ -n "$CHANGED_FILES" ] && HAS_ACTIVITY=true
+
+if [ "$HAS_ACTIVITY" = true ]; then
+  echo "$(date '+%H:%M:%S') — container active"
+  [ -n "$DOCKER_STATS" ] && echo "  $DOCKER_STATS"
+  [ -n "$CHANGED_FILES" ] && echo "  Files changed:" && echo "$CHANGED_FILES" | sed "s|${WORK_DIR}/||" | sed 's/^/    /'
+  [ -n "$DOCKER_RECENT" ] && echo "  Recent output:" && echo "$DOCKER_RECENT" | sed 's/^/    /'
+  echo "$NOW" > "$LAST_ACTIVITY_FILE"
+  touch "$ACTIVITY_REF"
+else
+  SILENT=$((NOW - LAST_ACTIVITY_TIME))
+  SILENT_MIN=$((SILENT / 60))
+  SILENT_SEC=$((SILENT % 60))
+  echo "$(date '+%H:%M:%S') — idle for ${SILENT_MIN}m${SILENT_SEC}s (no file changes, no new output)"
+  [ -n "$DOCKER_STATS" ] && echo "  $DOCKER_STATS"
+  if [ $SILENT -ge $STUCK_THRESHOLD ]; then
+    echo "STUCK_DETECTED no activity for ${SILENT}s"
+    rm -f "$ACTIVITY_REF" "$LAST_ACTIVITY_FILE"
+    exit 2
+  fi
+fi
+
+exit 0
diff --git a/.claude/skills/opsx-apply-loop/assets/apply-loop.Dockerfile b/.claude/skills/opsx-apply-loop/assets/apply-loop.Dockerfile
new file mode 100644
index 00000000..da39f07d
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/assets/apply-loop.Dockerfile
@@ -0,0 +1,38 @@
+# Base: official PHP image pinned to PHP 8.3 (matches Nextcloud dev environment)
+# Using the debian bookworm variant for consistency with the host environment
+FROM php:8.3-cli-bookworm
+
+# System libraries required by PHP extensions
+RUN apt-get update && apt-get install -y libxml2-dev libonig-dev libicu-dev && rm -rf /var/lib/apt/lists/*
+
+# PHP extensions required by phpcs (Nextcloud coding standards), phpstan, phpmd, and psalm
+RUN docker-php-ext-install xml dom mbstring intl
+
+# Install Node.js LTS (for Claude CLI and frontend quality checks)
+RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - \
+    && apt-get install -y nodejs \
+    && apt-get clean && rm -rf /var/lib/apt/lists/*
+
+# Install Composer (PHP dependency manager for quality checks)
+RUN curl -fsSL https://getcomposer.org/installer | php -- \
+    --install-dir=/usr/local/bin --filename=composer
+
+# Install Claude CLI — pinned to host version 2.1.83
+# Authentication: mount ~/.claude/.credentials.json into /home/claude/.claude/.credentials.json:ro
+# The credentials file is created by `claude auth login` on the host and contains OAuth tokens.
+# The skill mounts it read-only into the container at runtime (see docker run command in SKILL.md).
+RUN npm install -g @anthropic-ai/claude-code@2.1.83
+
+# Install openspec CLI — pinned to host version 1.2.0
+RUN npm install -g @fission-ai/openspec@1.2.0
+
+# Create a non-root user — claude --dangerously-skip-permissions refuses to run as root
+# Pre-create /home/claude/.claude/ so that volume-mounting the credentials file into it
+# does not cause Docker to create the directory as root (which blocks CLI writes to session-env/)
+RUN useradd -m -u 1000 -s /bin/bash claude && \
+    mkdir -p /workspace /home/claude/.claude && \
+    chown claude:claude /workspace /home/claude/.claude
+
+# Intentionally NOT installed: git, gh CLI, Docker client, SSH client
+USER claude
+WORKDIR /workspace
diff --git a/.claude/skills/opsx-apply-loop/evals/evals.json b/.claude/skills/opsx-apply-loop/evals/evals.json
new file mode 100644
index 00000000..d05b6520
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-apply-loop","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"loop-until-pass","description":"Apply-verify loop until clean","prompt":"Run /opsx-apply-loop for register-export","setup":"Change with tasks, Docker environment ready","expected":"Should iterate apply→verify until pass","assertions":["Runs apply inside Docker container","Runs verify after apply","Loops on failure (max 5 iterations)","Auto-archives on successful verify"]},{"id":"max-iterations","description":"Stop after max retries","prompt":"Run on a change that keeps failing verify","setup":"Change with persistent verification failures","expected":"Should stop after max iterations","assertions":["Stops after 5 Docker iterations","Reports remaining failures","Does NOT loop infinitely","Suggests manual intervention"]},{"id":"auto-archive","description":"Archive on success","prompt":"Apply-loop succeeds on first try","setup":"Simple change that passes immediately","expected":"Should auto-archive","assertions":["Detects verify pass","Auto-commits changes","Auto-archives the change","Reports success"]}],"trigger_tests":{"should_trigger":["run apply loop","apply and verify in a loop","opsx apply loop","auto-apply until verified","iterate apply verify"],"should_not_trigger":["apply the change","verify the change","archive the change","run tests","create a PR"]}}
diff --git a/.claude/skills/opsx-apply-loop/learnings.md b/.claude/skills/opsx-apply-loop/learnings.md
new file mode 100644
index 00000000..550d9af3
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — opsx-apply-loop
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/opsx-apply-loop/references/apply-verify-loop-protocol.md b/.claude/skills/opsx-apply-loop/references/apply-verify-loop-protocol.md
new file mode 100644
index 00000000..9969cdfb
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/references/apply-verify-loop-protocol.md
@@ -0,0 +1,139 @@
+# Apply → Verify Loop Protocol
+
+Reference for Steps 7–8 of `opsx-apply-loop`. These steps execute **inside the container** (not on the host). The container's Claude CLI session reads this file and executes the loop.
+
+---
+
+## Step 7: Initialise the loop log (inside container)
+
+Create an in-memory iteration log. Append to it after each apply and verify pass. Use **plain-text status lines** (not a markdown pipe table) — pipe tables look misaligned in terminal output and raw log files when column content widths vary. The formatted summary table is produced once in Step 15.
+
+```
+## apply-loop log — {APP}/{CHANGE_NAME}
+```
+
+Set `iteration = 1`. Set `max_iterations = 5`.
+
+The log directory and log file prefix for this run were passed in your startup prompt. Use them for all output files:
+- `<log-dir>` = the log directory (e.g. `/workspace/.claude-logs/YYYY-MM-DD-{APP}-{CHANGE_NAME}`)
+- `{RUN_TIME_PREFIX}` = the log file prefix (e.g. `apply-loop-11:26`) — use this as the prefix for result files: `<log-dir>/{RUN_TIME_PREFIX}-result`
+
+Working directory is `/workspace` (= the app directory). All openspec paths are relative to this: `openspec/changes/{CHANGE_NAME}/`.
+
+---
+
+## Step 8: Apply → Verify loop (inside container)
+
+Repeat the following until verify is clean or `iteration > max_iterations`.
+
+### 8a. Run apply (via opsx-apply)
+
+Log: `⚙️ Iteration <N> — running apply`
+
+**Invoke the `opsx-apply` skill** for `{CHANGE_NAME}`. Pre-answer its interactive prompts to keep the loop automated:
+
+| Prompt from opsx-apply | Answer |
+|------------------------|--------|
+| "Ready to implement N remaining tasks?" | **Start implementing** |
+| "Which task number?" (if shown) | Not applicable — start from first pending |
+| "What would you like to do next?" (end of apply) | Do NOT answer — return control to apply-loop |
+
+**Note**: The apply skill will attempt GitHub issue updates — these will silently fail inside the container (no gh CLI/GitHub access). This is expected. GitHub sync is handled after the container exits (Step 12).
+
+**Seed data (ADR-001)**: When apply implements tasks that introduce or modify OpenRegister schemas, the seed data entries in `lib/Settings/{app}_register.json` must also be created/updated. The apply skill handles this — ensure it does not skip this step even inside the container.
+
+**If this is a test-failure re-entry**: read the test-failures file specified in your startup prompt (e.g. `<log-dir>/apply-loop-HH:MM-test-failures-N`) for context on what the host-side tests reported. Use those failures to guide which code areas to focus on during apply.
+
+Quality checks run directly in the container (PHP and Composer are installed in this image). The `docker compose exec` approach is not available — run directly:
+```bash
+cd /workspace && composer check:strict 2>&1
+# If check:strict not available:
+composer phpcs 2>&1 && composer phpmd 2>&1 && composer psalm 2>&1
+```
+
+For auto-fixable issues:
+```bash
+cd /workspace && composer phpcs:fix 2>&1
+# OR: composer cs:fix
+```
+
+Frontend quality checks (if `package.json` exists with lint scripts):
+```bash
+cd /workspace && npm run lint 2>&1
+npm run stylelint 2>&1
+```
+
+**If apply is blocked** (missing artifacts, design issues, unclear requirements): stop the loop, report the blocker, write the result file to `<log-dir>`, and exit cleanly:
+```bash
+echo "STATUS=blocked" > <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+echo "REASON=<blocker description>" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+```
+The host (Step 6.7 Scenario C) handles user prompting and container removal.
+
+Append to iteration log:
+`[Iter <N> | apply ] <N> tasks implemented — Quality: ✓ pass / N issues fixed / N issues remain`
+
+### 8b. Run verify (via opsx-verify)
+
+Log: `🔍 Iteration <N> — running verify`
+
+**Invoke the `opsx-verify` skill** for `{CHANGE_NAME}`. Pre-answer its interactive prompts:
+
+| Prompt from opsx-verify | Answer |
+|-------------------------|--------|
+| "Would you also like to run API and/or browser tests?" | **Skip testing** — no network access to Nextcloud in this container |
+| "Found issues. Would you like me to fix them?" | **No, leave as-is** — the next apply iteration handles fixes |
+| "Ready to archive this change?" | **No, not yet** — archive is handled on the host |
+| "Archive with warnings?" | **No, not yet** — archive is handled on the host |
+
+**Note**: The verify skill will attempt GitHub issue sync — this will silently fail inside the container. Expected. Sync happens after container exits (Step 12).
+
+**Classify all findings** as CRITICAL, WARNING, or SUGGESTION (as reported by opsx-verify).
+
+**Append to iteration log**, e.g.:
+`[Iter <N> | verify] ✓ Clean` or `[Iter <N> | verify] X CRITICAL, Y WARNING — <brief summary>`
+
+### 8c. Evaluate and decide
+
+**If CRITICAL issues found (with or without WARNINGs) and `iteration < max_iterations`**:
+- Display the findings clearly
+- Log: `[Iter <N> | verify] X CRITICAL — continuing loop`
+- Increment `iteration`
+- Go back to **Step 8a**
+
+**If only WARNING (or SUGGESTION) issues found and `iteration < max_iterations`**:
+- Assess whether each warning is **actionable** (a further apply pass could plausibly fix it) or **non-actionable** (e.g., unverifiable inside this container, requires a live runtime environment, depends on external data, or is by design):
+  - **All actionable** → continue loop:
+    Log: `[Iter <N> | verify] Y WARNING(s) — actionable, continuing loop`
+    Increment `iteration`, go back to **Step 8a**
+  - **All non-actionable** (or no actionable ones remain) → proceed without restarting:
+    Log: `[Iter <N> | verify] Y WARNING(s) — loop not restarted: <reason for each non-actionable warning>`
+    Write result file with `WARNINGS_ONLY=true` and exit (same path as the max-iterations warnings case below)
+
+**If CRITICAL issues found and `iteration == max_iterations`**:
+- Stop — CRITICAL issues cannot be carried to archive
+- Write `<log-dir>/apply-loop-{RUN_TIME_PREFIX}-result` with `STATUS=exhausted` and the list of remaining issues
+- Exit the container
+
+**If only WARNING (or SUGGESTION) issues remain and `iteration == max_iterations`**:
+- Log: `[Iter <N> | verify] Y WARNING(s) — max iterations reached, proceeding`
+- Write the result file and exit:
+  ```bash
+  echo "STATUS=verify-clean" > <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "APP={APP}" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "CHANGE={CHANGE_NAME}" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "ITERATIONS=<N>" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "WARNINGS_ONLY=true" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  ```
+
+**If no CRITICAL and no WARNING issues**:
+- Log: `[Iter <N> | verify] ✓ Clean`
+- Write the result file and exit:
+  ```bash
+  echo "STATUS=verify-clean" > <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "APP={APP}" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "CHANGE={CHANGE_NAME}" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  echo "ITERATIONS=<N>" >> <log-dir>/apply-loop-{RUN_TIME_PREFIX}-result
+  ```
+
+Container exits cleanly. **Do NOT run opsx-archive — that is handled on the host.**
diff --git a/.claude/skills/opsx-apply-loop/references/container-auth-check.md b/.claude/skills/opsx-apply-loop/references/container-auth-check.md
new file mode 100644
index 00000000..003e2f72
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/references/container-auth-check.md
@@ -0,0 +1,41 @@
+# Container Authentication Check
+
+The container needs credentials to call the Claude API. The Claude CLI authenticates via a credentials file, not environment variables alone. Two methods are supported, checked in order of preference:
+
+1. **Credentials file** (preferred) — `~/.claude/.credentials.json`, created automatically by `claude auth login`. Uses your existing Claude subscription (no extra cost).
+2. **`ANTHROPIC_API_KEY`** (fallback) — uses prepaid API credits (costs money). Get one at console.anthropic.com.
+
+**Important**: The `apply-loop` container image runs as user `claude` with `HOME=/home/claude`. The credentials file must be mounted to `/home/claude/.claude/.credentials.json` inside the container. Passing `CLAUDE_CODE_AUTH_TOKEN` as an env var alone is NOT sufficient — the CLI requires the actual credentials file.
+
+```bash
+CREDS_FILE="$HOME/.claude/.credentials.json"
+if [ -f "$CREDS_FILE" ]; then
+  echo "✅ Credentials file found at $CREDS_FILE (will mount into container)"
+elif [ -n "${ANTHROPIC_API_KEY}" ]; then
+  echo "⚠️ ANTHROPIC_API_KEY is set (using paid API credits — consider running 'claude auth login' instead)"
+else
+  echo "❌ No authentication configured"
+fi
+```
+
+Store the result: `{AUTH_METHOD}` = `credentials_file` or `api_key`.
+
+**If neither is available — stop immediately:**
+> "⛔ The apply-loop container needs authentication. No credentials file (`~/.claude/.credentials.json`) or `ANTHROPIC_API_KEY` found.
+>
+> **Recommended: use your existing subscription (free)**
+> 1. Run `claude auth login` in your terminal
+> 2. This creates `~/.claude/.credentials.json` automatically
+> 3. Re-run this command — the file will be mounted read-only into the container
+>
+> **Alternative: use API credits (costs money)**
+> 1. Go to console.anthropic.com → API Keys → Create Key
+> 2. Add credits to your account (Billing → Add credits)
+> 3. Add the key to your shell profile:
+>    ```bash
+>    export ANTHROPIC_API_KEY='sk-ant-...'
+>    ```
+>
+> There is no alternative — the loop always runs inside an isolated Docker container."
+
+**Do not suggest running apply→verify on the host as an alternative. There is no fallback.**
diff --git a/.claude/skills/opsx-apply-loop/references/container-limitations.md b/.claude/skills/opsx-apply-loop/references/container-limitations.md
new file mode 100644
index 00000000..a101c2bf
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/references/container-limitations.md
@@ -0,0 +1,39 @@
+# Container Limitations
+
+Reference for `opsx-apply-loop`. The loop container has no git and no GitHub access by design.
+
+---
+
+## What the container cannot do
+
+The following things the sub-skills normally do **will not work inside the container** — they are handled by the host steps instead:
+
+| Capability | Why it fails in container | Handled by |
+|-----------|--------------------------|------------|
+| GitHub issue checkbox updates (opsx-apply, opsx-verify) | No gh CLI / GITHUB_TOKEN | Step 13a (host) |
+| GitHub issue comments | No gh CLI / GITHUB_TOKEN | Step 13b (host) |
+| GitHub issue closing (opsx-archive) | No gh CLI / GITHUB_TOKEN | Step 13c (host) |
+| Quality checks via `docker compose exec` (opsx-apply) | No Docker socket in container | PHP + Composer + npm run directly in container |
+| curl API tests against Nextcloud (opsx-verify) | No network path to Nextcloud containers | Pre-answered "Skip testing" |
+| Browser tests (opsx-verify, test-functional, etc.) | No browser in container | Test loop runs on host (Step 9) |
+| git commits | No git in container | Step 12 (host) |
+| opsx-archive | Moved to host — runs after test loop | Step 11 (host) |
+
+## Container volumes
+
+- `/workspace` → `{APP}/` (read-write: app code + openspec changes)
+- `/workspace/.claude` → `.claude/` (read-only: shared skill files for the container's Claude session)
+
+## Restricting the container network to Claude API only (optional but recommended)
+
+The `apply-loop-net` bridge network allows general outbound by default. To lock it down to `api.anthropic.com` only, add these iptables rules on the host after creating the network:
+
+```bash
+SUBNET=$(docker network inspect apply-loop-net --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}')
+iptables -I DOCKER-USER -s $SUBNET -p udp --dport 53 -j ACCEPT
+iptables -I DOCKER-USER -s $SUBNET -p tcp --dport 53 -j ACCEPT
+iptables -I DOCKER-USER -s $SUBNET -d api.anthropic.com -j ACCEPT
+iptables -I DOCKER-USER -s $SUBNET -j DROP
+```
+
+Run `iptables -D DOCKER-USER ...` with the same rules to remove them when done.
diff --git a/.claude/skills/opsx-apply-loop/references/container-setup-guide.md b/.claude/skills/opsx-apply-loop/references/container-setup-guide.md
new file mode 100644
index 00000000..a2fdd679
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/references/container-setup-guide.md
@@ -0,0 +1,287 @@
+# Container Setup Guide
+
+Reference for Step 6 of `opsx-apply-loop`. Covers log folder creation (6.1), prior run history scan (6.2), version checks and image build (6.3), network creation (6.4), container startup with prompt construction (6.5), monitoring loop (6.6), and container exit handling with all 5 scenarios (6.7).
+
+**Important:** In the Step 6.5 startup prompt, the container is instructed to read `references/apply-verify-loop-protocol.md` (not SKILL.md directly) for the apply→verify loop instructions.
+
+---
+
+### 6.1 Create the log folder for this run
+
+Before building or starting the container, create the dedicated log folder. All log files for this run go here — change name is in the folder, not the file names.
+
+**Important:** Use an absolute path to the apps-extra root. Each app is its own git repo, so go one level up from the current app directory.
+
+```bash
+APPS_EXTRA_ROOT="$(cd .. && pwd)"
+
+LOG_SUBDIR="$(date +%Y-%m-%d)-{APP}-{CHANGE_NAME}"
+LOG_DIR="${APPS_EXTRA_ROOT}/.claude/logs/${LOG_SUBDIR}"
+CONTAINER_LOG_DIR="/workspace/.claude-logs/${LOG_SUBDIR}"
+mkdir -p "${LOG_DIR}"
+```
+
+> `LOG_DIR` is the absolute host-side path; `CONTAINER_LOG_DIR` is the same folder as seen inside the container (via the `.claude/logs` → `/workspace/.claude-logs` volume mount).
+
+Log: `📁 Log folder: ${LOG_DIR}`
+
+### 6.2 Scan for prior run history (host — do NOT delegate to container or test skills)
+
+**You** (the host apply-loop orchestrator) scan the log folder now, before building the container. This step runs entirely in the host session — do not delegate to the container, to opsx-apply, to opsx-verify, or to any test skill.
+
+```bash
+ls "${LOG_DIR}" 2>/dev/null
+```
+
+If the folder is empty or does not yet contain any log files, set `{PRIOR_RUN_CONTEXT}` = `""` and continue.
+
+If files exist, read each one yourself (use the Read tool) and build a plain-text summary. Files to look for and how to interpret them:
+
+| File pattern | What it contains | How to use it |
+|---|---|---|
+| `apply-loop-*-result.log` | Final status of a previous container run (`STATUS=verify-clean`, `exhausted`, `blocked`) | Record status + iteration count |
+| `apply-loop-*-live.log` | Per-minute monitoring status lines (file changes, CPU/mem, docker output) | Useful to see what the container was doing at each point in time |
+| `apply-loop-*-container.log` | Full container output (captured on exit) | Skim for CRITICAL issues reported by verify, apply errors, and quality check failures — extract unresolved ones |
+| `apply-loop-*-test-failures-*.log` | Host-side test failures written by Step 9b | Extract all FAILED test commands and their failure descriptions |
+| `prompt.txt` | The startup prompt used for the last container run | Read to understand what context was already given |
+
+**Build `{PRIOR_RUN_CONTEXT}`** as a structured plain-text block covering:
+
+1. **Previous runs summary** — for each prior container run found: the run time, status, and number of iterations
+2. **Unresolved CRITICAL issues** — list every CRITICAL issue reported by opsx-verify in prior runs that does NOT appear to have been fixed (i.e., it appeared in a result or log file and the final STATUS was not `verify-clean`, or it appeared in the last clean result's WARNING list). Be specific: file name, issue description, severity.
+3. **Unresolved test failures** — list every test failure from `test-failures-*` files that was not subsequently resolved (i.e., the test was re-run after the failure was written and still failed, or no re-run was found). Include the failed command, affected area, and failure description.
+4. **What was already attempted** — briefly note what apply tried to fix in prior iterations so the container does not repeat the same approach if it failed.
+
+If no unresolved issues are found (e.g., the only prior run has `STATUS=verify-clean`), note that and set `{PRIOR_RUN_CONTEXT}` to a short "Previous run: verify-clean — no unresolved issues." string.
+
+Log: `📋 Prior run history: <N result file(s), M test-failure file(s) found — <brief one-line summary>>`
+
+### 6.3 Check versions and build/rebuild the container image
+
+The Dockerfile lives at [assets/apply-loop.Dockerfile](assets/apply-loop.Dockerfile). **Always** check host versions against the Dockerfile — if versions have drifted, update the Dockerfile and rebuild.
+
+**Step 1 — Read host versions:**
+```bash
+# Claude CLI version — must match the pinned version in the Dockerfile
+claude --version
+# → e.g. 2.1.83
+
+# openspec version — must match the pinned version in the Dockerfile
+openspec --version
+# → e.g. 1.2.0
+```
+
+**Step 2 — Compare with Dockerfile and update if needed:**
+
+Read `assets/apply-loop.Dockerfile` and check the `claude-code@X.X.X` and `@fission-ai/openspec@X.X.X` version pins. If either differs from the host version:
+- Update the version in the Dockerfile in-place (edit `assets/apply-loop.Dockerfile` directly)
+- Log: `📦 Updated Dockerfile: claude-code@<old> → <new>` (and/or openspec)
+- Force a rebuild (even if the image already exists)
+
+**Step 3 — Build if needed:**
+```bash
+# Check if image exists
+docker image inspect apply-loop:latest >/dev/null 2>&1 && echo "exists" || echo "build needed"
+```
+
+Build (or rebuild after version update):
+```bash
+docker build -t apply-loop:latest -f .claude/skills/opsx-apply-loop/assets/apply-loop.Dockerfile .
+```
+
+> **Container user**: The image creates a non-root user `claude` with `HOME=/home/claude`. The `/home/claude/.claude/` directory is pre-created with correct ownership so that volume-mounting the credentials file does not cause permission issues with the CLI's `session-env/` directory.
+
+Skip the build only if the image exists AND versions match.
+
+### 6.4 Create the restricted Docker network (first time only)
+
+```bash
+docker network inspect apply-loop-net >/dev/null 2>&1 || \
+  docker network create apply-loop-net
+```
+
+> **Note on full network isolation**: The network above still allows general outbound internet. To restrict it to the Claude API only (`api.anthropic.com`) you need iptables rules on the host — see the **Container Limitations** section at the bottom of this skill.
+
+### 6.5 Start the container
+
+Do **not** pass `--rm` — the container must be kept alive after exit so logs can be captured before removal.
+
+Three volumes are mounted:
+- The **app directory** → `/workspace` (read-write, contains code + openspec changes)
+- The **shared `.claude/` directory** → `/workspace/.claude` (read-only, provides skill files to the container's Claude session)
+- The **`.claude/logs/` directory** → `/workspace/.claude-logs` (read-write, for result and test-failure files — already gitignored in the config repo)
+
+If this is a **test-failure re-entry** (Step 9c), use the re-entry prompt variant in Step 6.5 below.
+
+Set the run time prefix for all log files created by this container run:
+```bash
+RUN_TIME=$(date +%H:%M)
+```
+
+Run the container in **detached mode** (`-d`) so the host session can monitor it while it runs.
+
+**First, write the startup prompt to a file** to avoid shell quoting issues:
+
+```bash
+cat > "${LOG_DIR}/prompt.txt" << PROMPT_EOF
+You are running inside an isolated Docker container for Nextcloud app {APP}, change {CHANGE_NAME}.
+You have no git, no gh CLI, and no GitHub access. Do not attempt git or GitHub operations.
+Archive is handled on the host after you exit — do NOT run opsx-archive.
+
+Working directory is /workspace (= the {APP}/ app directory).
+Skill files are at /workspace/.claude/skills/ (read-only mount of the shared .claude/).
+
+Execute the apply→verify loop protocol from /workspace/.claude/skills/opsx-apply-loop/references/apply-verify-loop-protocol.md.
+Read that file first to get the full instructions.
+
+App: {APP}
+Change name: {CHANGE_NAME}
+Max iterations: 5
+Log directory: ${CONTAINER_LOG_DIR}
+Log file prefix: apply-loop-${RUN_TIME}
+Result file: ${CONTAINER_LOG_DIR}/apply-loop-${RUN_TIME}-result.log
+PROMPT_EOF
+```
+
+**Always append the prior run context** (even if empty — write the header so the container always sees a consistent block):
+
+```bash
+cat >> "${LOG_DIR}/prompt.txt" << PRIOR_EOF
+
+## Prior run history for today (same app + change)
+
+{PRIOR_RUN_CONTEXT}
+
+If any unresolved CRITICAL issues or test failures are listed above, treat them as known bugs that your apply pass MUST address — do not skip them even if the task list does not explicitly mention them. If the prior run history says "no unresolved issues", proceed normally from the task list.
+PRIOR_EOF
+```
+
+**If this is a test-failure re-entry**, additionally append:
+```bash
+echo "Test-failure re-entry: Also read ${CONTAINER_LOG_DIR}/apply-loop-{FAIL_TIME}-test-failures-{TEST_ITERATION} for the latest host-side test failures — use it alongside the prior run history above to guide what apply should fix in this iteration." >> "${LOG_DIR}/prompt.txt"
+```
+
+Then start the container:
+
+```bash
+docker run -d \
+  --name "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}" \
+  -v "$(pwd)/{APP}:/workspace" \
+  -v "$(pwd)/.claude:/workspace/.claude:ro" \
+  -v "$(pwd)/.claude/logs:/workspace/.claude-logs" \
+  $(if [ -f "$HOME/.claude/.credentials.json" ]; then echo "-v $HOME/.claude/.credentials.json:/home/claude/.claude/.credentials.json:ro"; elif [ -n "${ANTHROPIC_API_KEY}" ]; then echo "-e ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}"; fi) \
+  -w /workspace \
+  -e "CONTAINER_LOG_DIR=${CONTAINER_LOG_DIR}" \
+  -e "RUN_TIME=${RUN_TIME}" \
+  --network apply-loop-net \
+  apply-loop:latest \
+  sh -c 'claude --dangerously-skip-permissions --print "$(cat ${CONTAINER_LOG_DIR}/prompt.txt)"'
+```
+
+```bash
+echo "$(date '+%H:%M:%S') — 🚀 Container started (detached). Monitoring begins..." >> "${LOG_DIR}/apply-loop-${RUN_TIME}-live.log"
+```
+
+Log: `🚀 Container started (detached). Monitoring begins...`
+
+### 6.6 Monitor the container (host)
+
+The monitoring script runs **one check per invocation** (~60s), then exits. Claude re-runs it in a loop and posts a brief status update to the user after each invocation — giving you a live progress line in chat approximately every minute.
+
+**Setup** (one-time):
+```bash
+chmod +x .claude/skills/opsx-apply-loop/assets/apply-loop-check.sh
+```
+
+**Monitoring loop** — run this command repeatedly (timeout: 120000ms per invocation):
+```bash
+.claude/skills/opsx-apply-loop/assets/apply-loop-check.sh "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}" "$(pwd)/{APP}" "${LOG_DIR}/apply-loop-${RUN_TIME}-live.log"
+```
+
+After **each invocation**, immediately:
+1. **Show the output to the user** as a brief inline status — e.g. `⚙️ 14:32 — active | CPU: 85% MEM: 420MiB | changed: src/views/Foo.vue, src/store/bar.js`
+2. Check the exit code and act:
+
+| Exit code | Meaning | Action |
+|-----------|---------|--------|
+| **0** | Container still running | Re-run immediately (no new user approval needed) |
+| **1** | Container stopped | Proceed to Step 6.7 |
+| **2** | Stuck (5+ min no activity) | Use **AskUserQuestion**: "⚠️ Container appears stuck — no file changes or output for 5+ minutes." Options: **Keep waiting** (re-run the monitor — same command, already approved), **Show logs** (`docker logs apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION} --tail=50`), **Kill and retry** (stop container, restart from Step 6.5), **Kill and stop** (stop container, report failure) |
+
+The `CONTAINER_STOPPED` marker in the output confirms the container exited and includes the docker exit code.
+
+### 6.7 Handle container exit
+
+When the container stops (for any reason), immediately capture its full logs before doing anything else:
+
+```bash
+docker logs "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}" 2>&1 | tee "${LOG_DIR}/apply-loop-${RUN_TIME}-container.log"
+# These files served their purpose during the run — clean them up now
+rm -f "${LOG_DIR}/prompt.txt"
+rm -f "${LOG_DIR}/apply-loop-${RUN_TIME}-live.log"
+# Fallback: also catch any live.log not matched by RUN_TIME (e.g. resumed sessions)
+find "${LOG_DIR}" -name "*-live.log" -delete 2>/dev/null || true
+```
+
+`container.log` is written to `${LOG_DIR}` (gitignored) and survives on the host regardless of what happens to the container next.
+
+Determine the exit scenario:
+
+```bash
+EXIT_CODE=$(docker inspect "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}" --format '{{.State.ExitCode}}')
+RESULT=$(cat "${LOG_DIR}/apply-loop-${RUN_TIME}-result.log" 2>/dev/null || echo "STATUS=unknown")
+```
+
+**Scenario A — Verify clean** (`EXIT_CODE=0`, `STATUS=verify-clean`):
+- Remove the container automatically:
+  ```bash
+  docker rm "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}"
+  ```
+- **Sync GitHub issue checkboxes immediately** — read current `{APP}/openspec/changes/{CHANGE_NAME}/tasks.md` (pre-archive location) and check off every task marked `[x]` in issue #`{ISSUE_NUMBER}`:
+  - **MCP (preferred):** `get_issue` → patch all `- [ ]` → `- [x]` for done tasks → `update_issue`
+  - **CLI (fallback):** `gh issue view {ISSUE_NUMBER} --repo <owner/{APP}> --json body` → update checkboxes → `gh issue edit ...`
+  - Log: `✅ GitHub issue #<N> checkboxes synced (post-container)`
+- **Update apply-loop status comment** — post or update a single comment starting with `## Apply-Loop Status` on issue #`{ISSUE_NUMBER}`. Search existing comments for one with that header; update via PATCH if found, create if not:
+  ```markdown
+  ## Apply-Loop Status
+
+  | Stage | Status | Details |
+  |-------|--------|---------|
+  | Implementation | ✓ Complete | All tasks done |
+  | Quality Checks | ✓ Pass | |
+  | Verification | ✓ Pass | verify-clean |
+  | Host Tests | pending | |
+  | Archive | pending | |
+
+  *Updated: YYYY-MM-DD HH:MM UTC*
+  ```
+  - **MCP (preferred):** `list_issue_comments` → find comment → `update_issue_comment` or `add_issue_comment`
+  - **CLI (fallback):** `gh api repos/{owner}/{repo}/issues/{n}/comments` → PATCH or POST
+- Proceed to Step 9 (host test loop)
+
+**Scenario B — Loop exhausted** (`EXIT_CODE=0`, `STATUS=exhausted`):
+- Show the remaining CRITICAL issues from `${LOG_DIR}/apply-loop-${RUN_TIME}-result.log` and the tail of the log
+- Use **AskUserQuestion** to ask:
+  > "Loop exhausted. Logs saved to `${LOG_DIR}`. Inspect the container before removing?"
+  - **No, remove it** → `docker rm "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}"` → go to the Loop exhausted section
+  - **Yes, keep it for now** → print `docker exec -it apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION} bash` → do NOT remove → go to Loop exhausted section
+
+**Scenario C — Apply blocked** (`EXIT_CODE=0`, `STATUS=blocked`):
+- Show the blocker details from `${LOG_DIR}/apply-loop-${RUN_TIME}-result.log` and the tail of the log
+- Use **AskUserQuestion** to ask:
+  > "Apply was blocked. Logs saved to `${LOG_DIR}`. Inspect the container before removing?"
+  - **No, remove it** → `docker rm "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}"` → stop and wait for user to resolve the blocker
+  - **Yes, keep it for now** → print the `docker exec` command → do NOT remove → stop and wait
+
+**Scenario D — Container crashed** (`EXIT_CODE≠0`):
+- Show the full log output
+- Use **AskUserQuestion** to ask:
+  > "The container exited unexpectedly (exit code `{EXIT_CODE}`). Logs saved to `${LOG_DIR}`. Keep the container for debugging?"
+  - **No, remove it** → `docker rm "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}"` → stop, report the crash
+  - **Yes, keep it for debugging** → print `docker exec -it apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION} bash` → do NOT remove → stop, report the crash
+
+**Scenario E — User interrupted (SIGTERM/Ctrl+C)**:
+- Capture logs (already done above), then use **AskUserQuestion** to ask:
+  > "The loop was interrupted. Logs saved to `${LOG_DIR}`. Some files may be partially written. Inspect the container before removing?"
+  - **No, remove it** → `docker rm "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}"` → stop
+  - **Yes, keep it for now** → print the `docker exec` command → do NOT remove → stop
diff --git a/.claude/skills/opsx-apply-loop/references/host-test-loop-protocol.md b/.claude/skills/opsx-apply-loop/references/host-test-loop-protocol.md
new file mode 100644
index 00000000..41d43722
--- /dev/null
+++ b/.claude/skills/opsx-apply-loop/references/host-test-loop-protocol.md
@@ -0,0 +1,122 @@
+# Host Test Loop Protocol
+
+Reference for Step 9 of `opsx-apply-loop`. Executes on the **host** after the container exits. Only runs if `{TESTS_ENABLED}=true`.
+
+---
+
+## Step 9: Host test loop (conditional)
+
+**Skip this step entirely if `{TESTS_ENABLED}=false`.** Proceed directly to Step 10.
+
+**Check Nextcloud environment** — quick check before running tests:
+
+```bash
+DOCKER_DEV_ROOT="$(cd ../../../.. && pwd)"
+HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/status.php 2>/dev/null)
+```
+
+**If `HTTP_CODE` is `200`**: Nextcloud is running. Verify the app is enabled:
+
+```bash
+docker compose -f "$DOCKER_DEV_ROOT/.github/docker-compose.yml" exec -T nextcloud php occ app:list --enabled 2>/dev/null | grep -q "^  - {APP}$" && echo "✅ {APP} enabled" || echo "⚠️ {APP} not found in enabled apps"
+```
+
+Log: `✅ Nextcloud ready, {APP} enabled`
+
+**If `HTTP_CODE` is not `200`** (or app is not enabled): start containers and wait up to 60s:
+
+```bash
+docker compose -f "$DOCKER_DEV_ROOT/.github/docker-compose.yml" up -d nextcloud proxy
+```
+
+Poll `http://localhost:8080/status.php` every 5s. If still not `200` after 60s, show logs and stop:
+
+```bash
+docker compose -f "$DOCKER_DEV_ROOT/.github/docker-compose.yml" logs master-nextcloud-1 --tail=20
+```
+
+> "⛔ Nextcloud did not start in time. Fix the environment and re-run `/opsx-apply-loop`."
+
+Set `test_iteration = 1`. Set `max_test_iterations = 3`.
+
+### 9a. Run the in-loop test commands
+
+Log: `🧪 Test iteration <T> — running: <TEST_COMMANDS_IN_LOOP>`
+
+**Use the Agent tool (NOT the Skill tool)** to run each command in `{TEST_COMMANDS_IN_LOOP}` sequentially. The Agent tool runs as a subprocess and returns results directly to you — this is what allows the loop to continue after each test without getting stuck. Never use the Skill tool here; it loads the skill inline and the conversation will terminate instead of returning control.
+
+For each command (e.g. `/test-functional` → skill name `test-functional`), determine the absolute path to the skill file. The `.claude/` directory is at the apps-extra workspace root, one level above `{APP}/`. Construct the path as:
+
+```
+CLAUDE_SKILLS="$(cd {APP}/.. && pwd)/.claude/skills"
+SKILL_FILE="${CLAUDE_SKILLS}/{skill-name}/SKILL.md"
+```
+
+Launch a **general-purpose Agent** with a prompt that includes:
+1. "Read and follow the skill instructions at `{SKILL_FILE}`."
+2. "App: `{APP}`. Change: `{CHANGE_NAME}`. Save all test output (screenshots, result files) inside `{APP}/test-results/` — never in the workspace root."
+3. "You are in READ-ONLY mode — do NOT modify any code files. Your job is to test the current state, identify failures, and produce a structured report."
+4. "End with the structured result line (e.g. `FUNCTIONAL_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>`). Output nothing after the result line."
+5. Any relevant prior-run context (test failures from earlier iterations if this is a re-entry).
+
+**CRITICAL: Test skills must NEVER make code changes.** They must only:
+1. Run tests against the current code
+2. Identify what is failing and why
+3. Produce a report describing what needs to change (file, line, issue, suggested fix)
+
+Each command automatically targets `{APP}` when invoked (or pass the app name as an argument if the skill supports it).
+
+After each Agent call returns, read its result summary to extract pass/fail from the structured result line (e.g., `FUNCTIONAL_TEST_RESULT: PASS | FAIL`). A command **fails** if it reports FAIL or any CRITICAL/HIGH-level finding. If a test skill does not output a result line, treat its recommendation as: APPROVE/COMPLIANT/SECURE = PASS, anything else = FAIL.
+
+Update the loop log:
+```
+| T<N> | test:<cmd> | ✓ Pass / X FAIL | <summary> |
+```
+
+After the Agent returns, **immediately continue to the next command or Step 9b** — do NOT pause, do NOT ask the user anything, do NOT wait for confirmation.
+
+### 9b. Evaluate test results
+
+**If all commands pass**:
+- Log: `✅ Test iteration <T> — all tests pass`
+- Proceed to **Step 10** (deferred tests)
+
+**If any command fails and `test_iteration < max_test_iterations`**:
+- Log: `⚠️ Test iteration <T> — failures found, re-entering apply→verify`
+- Write test failures to a file for the container to read:
+  ```bash
+  FAIL_TIME=$(date +%H:%M)
+  echo "TEST_ITERATION=<T>" > "${LOG_DIR}/apply-loop-${FAIL_TIME}-test-failures-${TEST_ITERATION}.log"
+  echo "FAILED_COMMANDS=<list>" >> "${LOG_DIR}/apply-loop-${FAIL_TIME}-test-failures-${TEST_ITERATION}.log"
+  # Append the full failure output from each failed test command
+  ```
+- Increment `test_iteration`
+- Go to **Step 9c**
+
+**If any command fails and `test_iteration == max_test_iterations`**:
+- Log: `⛔ Test loop exhausted after 3 iterations — failures remain`
+- Use **AskUserQuestion** to ask:
+  > "Tests still failing after 3 iterations. How would you like to proceed?"
+  - **Archive anyway** — proceed to Step 10 with a warning note
+  - **Fix manually, then re-run** — stop here; user can run `/opsx-apply-loop {APP} {CHANGE_NAME}` again
+  - **Skip tests and archive** — proceed to Step 10, skip remaining test steps
+  - **Cancel** — stop here, do not archive
+
+### 9c. Re-enter container for test-failure fixes
+
+Start a new container run (reuse Step 6.5 with test-failure re-entry variant). The container will:
+1. Read the test-failures file passed in the startup prompt (e.g. `${CONTAINER_LOG_DIR}/apply-loop-${FAIL_TIME}-test-failures-${TEST_ITERATION}.log`) for context
+2. Run `opsx-apply` targeting the failing areas
+3. Run `opsx-verify` to check the fix
+4. Exit with `STATUS=verify-clean` or `STATUS=exhausted`
+
+Wait for container exit (monitoring via Step 6.6). Handle exit scenarios per Step 6.7.
+
+After a **verify-clean** exit from the re-entry container, sync GitHub issue checkboxes immediately (same as Scenario A in Step 6.7) — read current `{APP}/openspec/changes/{CHANGE_NAME}/tasks.md` and update issue #`{ISSUE_NUMBER}`.
+
+Clean up the container after re-entry exits (keep all log and test-failure files):
+```bash
+docker rm "apply-loop-{APP}-{CHANGE_NAME}-{ITERATION}-t{TEST_ITERATION}"
+```
+
+Return to **Step 9a**.
diff --git a/.claude/skills/opsx-apply/SKILL.md b/.claude/skills/opsx-apply/SKILL.md
new file mode 100644
index 00000000..bc38ca1e
--- /dev/null
+++ b/.claude/skills/opsx-apply/SKILL.md
@@ -0,0 +1,329 @@
+---
+name: opsx-apply
+description: Implement tasks from an OpenSpec change (Experimental)
+metadata:
+  category: Workflow
+  tags: [workflow, artifacts, experimental]
+---
+
+**Check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- **On Haiku**: stop immediately:
+  > "This command requires Sonnet or Opus — implementing tasks from OpenSpec changes needs stronger reasoning than Haiku can reliably provide. Please switch to Sonnet (`/model sonnet`) or Opus (`/model opus`) and re-run."
+- **On Sonnet or Opus**: proceed normally.
+
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx-apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx-continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Load architectural context**
+
+   Before reading change-specific files, load ALL applicable ADRs. These are hard constraints on implementation — violating an ADR is a bug.
+
+   | Location | What | Priority |
+   |----------|------|----------|
+   | `openspec/changes/<name>/context-brief.md` | Specter intelligence brief — features, user stories, stakeholders, schemas, standards. Contains market research data that informed the spec. | Load if present — provides domain context for implementation decisions |
+   | `.claude/openspec/architecture/adr-*.md` | Company-wide ADRs (13 Conduction-wide decisions: data layer, API patterns, frontend, security, i18n, testing, etc.) | **Always load — these are non-negotiable** |
+   | `openspec/architecture/adr-*.md` | Repo-specific ADRs (app's data model, workflows, standards compliance, security model) | Always load if present |
+   | `docs/ARCHITECTURE.md` | App-specific technology decisions and component structure | Load if present |
+
+   Read these silently. Key ADRs to enforce during implementation:
+   - **ADR-001 (data layer)**: All data via OpenRegister, no custom DB tables
+   - **ADR-002 (API)**: REST-API Design Rules, HAL+JSON responses
+   - **ADR-003 (backend)**: PHP AppFramework patterns, service layer
+   - **ADR-004 (frontend)**: Vue 2.7 + Pinia, @nextcloud/vue components
+   - **ADR-005 (security)**: Nextcloud auth, RBAC, no direct SQL
+   - **ADR-007 (i18n)**: Dutch + English minimum, t() for all strings
+   - **ADR-013 (container pool)**: @self envelope pattern for seed data
+
+5. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+   **Additionally, load optional artifacts if present:**
+   - `openspec/changes/<name>/contract.md` — if it exists, treat it as the authoritative interface definition. Do not deviate from its declared endpoints, schemas, or error codes during implementation.
+   - `openspec/changes/<name>/test-plan.md` — if it exists, use it to guide verification steps for each task. Each TC's acceptance criteria tell you how to verify the task is done.
+
+6. **Show current progress and confirm**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+   Then use **AskUserQuestion** to ask:
+
+   > "Ready to implement <N> remaining tasks for `<change-name>`?"
+
+   Options:
+   - **Start implementing** — proceed through all pending tasks in order
+   - **Show me the full task list first** — display all tasks with titles and acceptance criteria, then ask again
+   - **Start from a specific task** — ask "Which task number?" and skip to that task
+   - **Cancel** — end the session without making changes
+
+7. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - **Write tests for every new PHP service/controller** — PHPUnit test in `tests/Unit/` or `tests/unit/` with at least 3 test methods covering the happy path, error handling, and edge cases
+   - **Write tests for every new Vue component** — if the project has a test framework (Jest/Vitest), create a basic mount + render test
+   - **Update documentation** — add/update the feature description in the project's README.md or docs/ folder. At minimum, document new API endpoints (method, path, request/response) and new admin settings
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - **Update GitHub issue checkboxes** (if `plan.json` exists):
+     - Read `openspec/changes/<name>/plan.json`, find the `tracking_issue` number
+     1. **Check off this task and ALL its sub-checkboxes in the issue body**:
+        - Fetch the issue body once
+        - Find the parent task line by matching the task title (e.g., `- [ ] **1.1 Task title**`)
+        - Change that line from `- [ ]` to `- [x]`
+        - Scan every line immediately following the parent — for each line that starts with `  - [ ]` (2-space indent), change it to `  - [x]`
+        - Stop scanning when you hit a line that is NOT an indented sub-checkbox (blank line, new parent checkbox, section header, etc.)
+        - **MCP (preferred):** `get_issue` → `{owner, repo, issue_number: <tracking_issue>}` → apply the above changes to the body → `update_issue` → `{owner, repo, issue_number: <tracking_issue>, body: <updated_body>}`
+        - **CLI (fallback):** `gh issue view <tracking_issue> --repo <repo> --json body --jq '.body'` → apply the above changes → `gh issue edit <tracking_issue> --repo <repo> --body "<updated_body>"`
+     - Update `plan.json`: set `"status": "done"` for that task
+     - **Do NOT close the issue** — the issue will be closed when the PR is merged or during archive
+   - Continue to next task
+
+   **Seed data requirement (ADR-001):**
+   - When implementing tasks that introduce or modify OpenRegister schemas, MUST also generate seed data entries in `lib/Settings/{app}_register.json`
+   - Use the Seed Data section from `design.md` as the source — it defines objects, field values, and related items
+   - Seed objects MUST use the `@self` envelope pattern (`register`, `schema`, `slug`) per ADR-013
+   - Use general organization data that feels natural for a municipality, consultancy, or travel agency
+   - Include 3-5 objects per schema with varied, realistic field values
+   - If `design.md` has no Seed Data section, flag this and suggest adding one before continuing
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+8. **On completion or pause, show status and update progress comment**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If paused: explain why and wait for guidance
+
+   **Pipeline progress comment (if plan.json exists with tracking_issue):**
+
+   Post or update a **single progress comment** on the GitHub issue. Search existing comments for one starting with `## Pipeline Progress` — if found, update it via PATCH; if not, create a new one. This keeps progress in one place instead of spamming multiple comments.
+
+   Format:
+   ```markdown
+   ## Pipeline Progress
+
+   | Stage | Status | Details |
+   |-------|--------|---------|
+   | Implementation | ✓ N/M tasks | Completed tasks X, Y, Z |
+   | Quality Checks | pending | |
+   | Verification | pending | |
+   | Archive | pending | |
+
+   *Updated: YYYY-MM-DD HH:MM UTC*
+   ```
+
+   - **MCP (preferred):** Use `list_issue_comments` to find existing progress comment, then `update_issue_comment` or `add_issue_comment`
+   - **CLI (fallback):** `gh api repos/{owner}/{repo}/issues/{n}/comments` to search, then PATCH or POST
+
+   **If all tasks done:** proceed to Step 8 (quality checks). Update the progress comment with Implementation = "✓ Complete" and Quality Checks = "running...".
+
+   **If plan.json exists and all tasks are now done:** also add a separate brief comment:
+   - **MCP (preferred):** GitHub MCP `add_issue_comment` → `{owner, repo, issue_number: <tracking_issue>, body: "✓ All tasks implemented. Running quality checks."}`
+   - **CLI (fallback):** `gh issue comment <tracking_issue> --repo <repo> --body "✓ All tasks implemented. Running quality checks."`
+
+9. **Run code quality checks**
+
+   After all tasks are complete, run the full quality suite from the project directory.
+
+   **PHP quality** (if the project has a `composer.json` with quality scripts):
+   ```bash
+   cd <project-dir> && composer check:strict 2>&1
+   ```
+   This runs: lint + named-args check + phpcs + phpmd + psalm + phpstan + unit tests.
+
+   If `check:strict` is not available, fall back to running individually:
+   ```bash
+   composer phpcs 2>&1
+   composer phpmd 2>&1
+   composer psalm 2>&1
+   ```
+
+   **Frontend quality** (if the project has a `package.json` with lint scripts):
+   ```bash
+   cd <project-dir> && npm run lint 2>&1
+   npm run stylelint 2>&1
+   ```
+
+   **Handle failures:**
+   - Parse the output to identify specific errors
+   - For auto-fixable issues, run the fixer first:
+     - `composer phpcs:fix` (PHPCBF auto-fixes ~60% of PHPCS issues)
+     - `npm run lint -- --fix` (ESLint auto-fix)
+   - For remaining issues, fix them manually in the code
+   - Re-run the quality checks to confirm all issues are resolved
+   - Maximum 3 fix cycles — if issues persist after 3 rounds, report remaining issues and continue
+
+   **Show quality results:**
+   ```
+   ## Quality Checks
+
+   | Tool | Status |
+   |------|--------|
+   | PHPCS | ✓ Pass (or X errors fixed) |
+   | PHPMD | ✓ Pass |
+   | Psalm | ✓ Pass |
+   | PHPStan | ✓ Pass |
+   | ESLint | ✓ Pass |
+   | Stylelint | ✓ Pass |
+   | Unit Tests | ✓ Pass (N tests) |
+   ```
+
+10. **Ask what's next**
+
+   After quality checks pass (or remaining issues are reported), show the completion summary, then use **AskUserQuestion** to ask:
+
+   > "Implementation complete! What would you like to do next?"
+
+   Options:
+   - **Verify implementation** (`/opsx-verify`) — recommended: check the code matches specs and run API/browser tests
+   - **Get a code review first** (`/team-reviewer`) — have a reviewer look at the code before verifying
+   - **Sync delta specs** (`/opsx-sync`) — sync this change's specs to main specs first
+   - **Archive directly** (`/opsx-archive`) — skip verification if already reviewed externally
+   - **Done for now** — end the session
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+### Quality Checks
+| Tool | Status |
+|------|--------|
+| PHPCS | ✓ Pass |
+| PHPMD | ✓ Pass |
+| Psalm | ✓ Pass |
+| ESLint | ✓ Pass |
+| Unit Tests | ✓ 42 tests passed |
+
+**What's Next**
+Recommended: `/opsx-verify` | Optional: `/team-reviewer`, `/opsx-sync` | Alternative: `/opsx-archive`
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+## Capture Learnings
+
+After completing tasks, review what happened and append any new observations to [learnings.md](learnings.md):
+
+- **Patterns That Work** — implementation approaches that consistently navigate OpenSpec tasks well
+- **Mistakes to Avoid** — errors, wrong assumptions, or approaches that caused implementation problems
+- **Domain Knowledge** — facts about OpenSpec workflows or project-specific implementation patterns
+- **Open Questions** — unresolved challenges or edge cases for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`) when done.
diff --git a/.claude/skills/opsx-apply/evals/evals.json b/.claude/skills/opsx-apply/evals/evals.json
new file mode 100644
index 00000000..7f903db0
--- /dev/null
+++ b/.claude/skills/opsx-apply/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-apply","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"implement-tasks","description":"Implement tasks from change","prompt":"Run /opsx-apply on register-export","setup":"Change has tasks.md with pending tasks","expected":"Should implement tasks in order","assertions":["Reads tasks.md and identifies pending tasks","Implements tasks sequentially","Writes tests for PHP services","Runs composer check:strict after changes","Updates GitHub issue checkboxes"]},{"id":"quality-gate","description":"Block on quality failures","prompt":"Apply when code fails quality checks","setup":"Implementation has lint errors","expected":"Should fix before continuing","assertions":["Runs composer check:strict","Blocks on failures","Fixes issues before moving to next task","Does NOT skip quality checks"]},{"id":"model-guard","description":"Requires Sonnet/Opus","prompt":"Run on Haiku","setup":"Haiku model","expected":"Should block","assertions":["Detects Haiku","Stops immediately","Suggests Sonnet/Opus"]}],"trigger_tests":{"should_trigger":["apply the change","implement the tasks","opsx apply register-export","start implementing","build the change"],"should_not_trigger":["verify the change","archive the change","explore the change","apply app config","create a PR"]}}
diff --git a/.claude/skills/opsx-apply/learnings.md b/.claude/skills/opsx-apply/learnings.md
new file mode 100644
index 00000000..7b97468d
--- /dev/null
+++ b/.claude/skills/opsx-apply/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — opsx-apply
+
+## Patterns That Work
+<!-- Implementation approaches that consistently navigate OpenSpec tasks well -->
+
+## Mistakes to Avoid
+<!-- Errors, wrong assumptions, or approaches that caused implementation problems -->
+
+## Domain Knowledge
+<!-- Facts about OpenSpec workflows, task structures, or project-specific implementation patterns -->
+
+## Open Questions
+<!-- Unresolved challenges or edge cases for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/opsx-archive/SKILL.md b/.claude/skills/opsx-archive/SKILL.md
new file mode 100644
index 00000000..11e3917f
--- /dev/null
+++ b/.claude/skills/opsx-archive/SKILL.md
@@ -0,0 +1,332 @@
+---
+name: opsx-archive
+description: Archive a completed change in the experimental workflow
+metadata:
+  category: Workflow
+  tags: [workflow, archive, experimental]
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx-archive` (e.g., `/opsx-archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   - Determine which artifacts are **required** vs **optional**: build the required set by walking the dependency graph backwards from `applyRequires` — any artifact transitively needed to satisfy `apply.requires` is required; all others are optional.
+
+   **If any REQUIRED artifacts are not `done`:**
+   - Display warning listing the incomplete required artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If only OPTIONAL artifacts are not `done` (or were never created):**
+   - Do not warn — optional artifacts that were skipped are expected. Proceed silently.
+
+3. **Check task completion status**
+
+   Run two checks in parallel — local tasks file and GitHub tracking issue.
+
+   **A. Local tasks.md check**: Read the tasks file (typically `tasks.md`) and count tasks marked `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **B. GitHub issue check** (if plan.json exists): Read plan.json to get `tracking_issue` and `repo`, then:
+   - **MCP (preferred):** `get_issue` → `{owner, repo, issue_number: <tracking_issue>}` → scan body for `- [ ]` lines
+   - **CLI (fallback):** `gh issue view <tracking_issue> --repo <repo> --json body --jq '.body'` → count `- [ ]` lines
+
+   **Reconcile findings** — two distinct failure modes:
+
+   **Case A — Sync gap**: tasks.md shows all done, but the GitHub tracking issue has unchecked boxes. The work is complete but GitHub is out of date.
+   - **BLOCK the archive** and display:
+     ```
+     ⛔ Cannot archive: GitHub tracking issue #<n> has N unchecked task(s) but tasks.md shows all complete.
+     This is a sync gap — the tracking issue needs to be updated.
+     ```
+   - Use **AskUserQuestion** to ask: "How do you want to proceed?"
+     - **Fix the tracking issue checkboxes now** — Fetch the issue body once, then for each task marked `[x]` in tasks.md: find the parent task line by matching its title, change `- [ ]` to `- [x]`; scan every immediately following line — for each line starting with `  - [ ]` (2-space indent), change it to `  - [x]`; stop scanning at any line that is NOT an indented sub-checkbox (blank line, new parent checkbox, section header, etc.). Write the updated body back in a single call. Then continue to archive.
+     - **Archive anyway (override)** — Archive without fixing; add a warning note to the archive summary
+   - Only proceed if user explicitly chooses one of these options
+
+   **Case B — Genuinely incomplete tasks**: tasks.md has `- [ ]` items (regardless of what GitHub shows). The work is not done.
+   - **BLOCK the archive** and display:
+     ```
+     ⛔ Cannot archive: N task(s) are still incomplete in tasks.md:
+     - Task X: <title>
+     ```
+   - Use **AskUserQuestion** to ask: "How do you want to proceed?"
+     - **Go back and complete tasks** — End the session so the user can finish the work
+     - **Archive anyway (override)** — Archive despite incomplete tasks; add a warning note to the archive summary
+   - Only proceed if user explicitly chooses the override option
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, execute `/opsx-sync` logic. Proceed to archive regardless of choice.
+
+4.5. **Convert test-plan test cases to reusable test scenarios**
+
+   Check if `openspec/changes/<name>/test-plan.md` exists. If it does not exist, skip this step silently.
+
+   **If test-plan.md exists:**
+
+   a. Parse all test cases by scanning for `### TC-N:` headers. For each, extract: title (rest of the header line), type, persona, preconditions, steps, expected result, spec_ref, and test command fields.
+
+   b. Determine which app this change belongs to (from the change's `.openspec.yaml` or the project field in plan.json). The test scenarios directory is `<APP>/test-scenarios/` relative to the workspace root (e.g., `openregister/test-scenarios/`, `opencatalogi/test-scenarios/`).
+
+   c. Use **AskUserQuestion** to ask:
+
+   > "This change has N test cases in test-plan.md. Convert them to reusable test scenarios?
+   >
+   > Test scenarios live in `<APP>/test-scenarios/` and are automatically picked up by `/test-persona-*`, `/test-app`, and `/test-counsel` commands after this change is archived."
+
+   Options:
+   - **All N test cases** — convert every TC to a TS file
+   - **Let me choose** — select which ones to convert
+   - **Skip** — don't create any test scenarios
+
+   **If "Let me choose":** use a second **AskUserQuestion** with `multiSelect: true`, listing each TC as `TC-N: <title>`. User picks which to convert.
+
+   d. For each selected TC, create a test scenario file:
+
+   - **Determine next ID**: scan `<APP>/test-scenarios/` for files matching `TS-NNN-*.md`, find the highest N, increment by 1. Start at `TS-001` if none exist. Create the directory if it doesn't exist.
+   - **Map TC fields to TS format:**
+     - TC `type` → TS `category` (`persona` type → `functional`; all others map directly)
+     - TC `persona` → TS `personas` list (map display name to persona slug: Henk → `henk-bakker`, Fatima → `fatima-el-amrani`, Sem → `sem-de-jong`, Noor → `noor-yilmaz`, Annemarie → `annemarie-de-vries`, Mark → `mark-visser`, Priya → `priya-ganpat`, Jan-Willem → `janwillem-van-der-berg`; omit if `—`)
+     - TC `preconditions` → TS Preconditions section + GIVEN line
+     - TC `steps` → WHEN line(s) in Scenario
+     - TC `expected result` → THEN line(s) in Scenario
+     - TC `test command` → TS `test-commands` list
+     - TC `spec_ref` → TS `spec-refs` list
+     - Priority: default `medium`; use `high` if the TC is compliance-critical (AVG/GDPR, authorisation, security) or if the spec_ref points to a High-severity requirement
+     - Goal: derive from TC title (e.g., "TC-4: Admin can view audit log" → "Verify admin can access and view the audit log")
+   - **Generate slug** from title: lowercase, hyphens, no special chars
+   - **Write** `<APP>/test-scenarios/TS-NNN-<slug>.md` using the standard scenario file format:
+
+   Use the format defined in [templates/test-scenario-template.md](templates/test-scenario-template.md).
+
+   e. Report: "Created N test scenario file(s): TS-NNN, TS-NNN+1, …"
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+5.5. **Update spec links in main specs**
+
+   After moving the change to archive, update any spec that references this change in its `**OpenSpec changes**` list:
+
+   a. Search all spec files for links pointing to `../../changes/<name>/` (or `changes/<name>/`):
+      ```bash
+      grep -rl "changes/<name>/" openspec/specs/
+      ```
+
+   b. For each matching spec file:
+      - Replace the active link `[<name>](../../changes/<name>/)` with the archived link `[<name>](../../changes/archive/YYYY-MM-DD-<name>/) _(archived YYYY-MM-DD)_`
+      - If this was the **last active change** for that spec (all other entries in `**OpenSpec changes**` are also archived), update the spec's `**Status**` field to `done`
+      - If the list now exceeds 15 entries, apply the grouping rule from `.claude/docs/writing-specs.md` (group by timeframe, oldest first, never remove entries)
+
+   c. If a spec exists for a capability defined in this change's `## Capabilities` section but the spec does NOT yet have this change in its `**OpenSpec changes**` list — add it as an archived entry now.
+
+   d. Also check the shared specs at `.claude/openspec/specs/` for any cross-app capabilities this change touched.
+
+6. **Update feature documentation**
+
+   If a `docs/features/README.md` exists in the project root, update the corresponding feature doc:
+
+   a. Read the **Spec-to-Feature Mapping** section from `docs/features/README.md` to find which feature doc corresponds to the change name (or the delta spec names).
+
+   b. Identify the matching feature doc file. A change may map to a feature doc in two ways:
+      - The change name directly matches a spec name in the mapping (e.g., change `lead-management` → `lead-management.md`)
+      - The change's delta specs match spec names in the mapping
+
+   c. If a matching feature doc is found:
+      - Read the current feature doc
+      - Read the main spec(s) that were synced (from `openspec/specs/<spec-name>/spec.md`)
+      - Update the feature doc to reflect any new, changed, or removed features from the spec
+      - Preserve the document structure (heading hierarchy, Specs section, Features section, Planned sections)
+      - Move features from "Planned" sections to implemented sections if the spec now marks them as done
+      - Add new features that appear in the updated spec
+      - Keep the writing style consistent: short descriptions, bullet points for sub-features
+
+   d. If no matching feature doc is found, **create one** at `docs/features/<change-name>.md` with:
+      - Feature title and one-line summary
+      - Standards references (GEMMA referentiecomponent URL, TEC RFP section, Forum Standaardisatie standards if applicable)
+      - Overview section describing the feature
+      - Key capabilities as bullet points (from the spec requirements)
+
+   e. **Update the feature overview table** in `docs/features/README.md`:
+      - Add a row for the new/updated feature in the Features table
+      - Each row must have: Feature name, short summary (max 1 line), Standards column (GEMMA/TEC/ZGW references), link to feature doc
+      - If `docs/features/README.md` doesn't exist, create it with:
+        - App name and description
+        - Standards Compliance table (GEMMA components, TEC sections, Forum Standaardisatie standards)
+        - Features table with all implemented features
+
+   **Standards references to include where applicable:**
+   - GEMMA referentiecomponent URL (from `gemmaonline.nl`)
+   - TEC RFP template section numbers
+   - ZGW API standard references
+   - Forum Standaardisatie 'Pas toe of leg uit' standards
+   - ISO/NEN standards (27001, 15489, etc.)
+
+6.5. **Update CHANGELOG.md**
+
+   Create or update `CHANGELOG.md` in the project root.
+
+   a. **Determine the version**:
+      - Read `openspec/app-config.json` → use `version` field
+      - Fallback: read `appinfo/info.xml` → use `<version>` element
+      - If neither exists, use `Unreleased`
+
+   b. **Gather entry content**:
+      - Read the completed tasks from `tasks.md` — items marked `- [x]` become bullet points (strip the `[x]` prefix, keep the description)
+      - Read the change title/summary from `.openspec.yaml` or `proposal.md` if available (use as a comment or section intro)
+      - If no tasks file exists, use the change name as a single entry line
+
+   c. **Categorize tasks** using [Keep a Changelog](https://keepachangelog.com/) categories:
+      - **Added** — new features or capabilities
+      - **Changed** — changes to existing functionality
+      - **Fixed** — bug fixes
+      - **Removed** — removed features
+      - **Security** — security fixes
+
+      If a task description clearly fits a category, group it there. If uncertain, place it under **Added**.
+
+   d. **Format the new entry**:
+      ```markdown
+      ## [<version>] - YYYY-MM-DD
+
+      ### Added
+      - <task description>
+      - <task description>
+
+      ### Fixed
+      - <task description>
+      ```
+
+   e. **If CHANGELOG.md already exists**:
+      - Read the current content
+      - Check if a `## [<version>]` entry already exists (exact version match)
+      - **If yes**: append the new items into the existing entry's sections (merge, no duplicates)
+      - **If no**: insert the new entry at the top — immediately after the `# Changelog` header line (or at line 1 if no header)
+
+   f. **If CHANGELOG.md does not exist**: create it:
+      ```markdown
+      # Changelog
+
+      All notable changes to this project will be documented in this file.
+
+      The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+      and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+      ## [<version>] - YYYY-MM-DD
+
+      ### Added
+      - <item>
+      ```
+
+7. **Close GitHub issue** (if plan.json exists)
+
+   Read `openspec/changes/<name>/plan.json` (from its new archive location).
+
+   If `tracking_issue` is set, use **AskUserQuestion** to ask:
+
+   > "Close GitHub issue #<tracking_issue>?"
+   >
+   > ℹ️ **Future feature:** In a planned update, issues will auto-close when the associated PR is merged, managed via a GitHub Project board (to do → refinement → ready for development → in progress → code quality check → code security check → review → done). For now, you can close it manually here.
+
+   Options:
+   - **Yes, close the issue** — close with archive comment
+   - **No, leave it open** — skip closing (e.g., if a PR will handle it)
+
+   **If user chooses to close:**
+   - **MCP (preferred):** GitHub MCP `update_issue` → `{owner, repo, issue_number: <tracking_issue>, state: "closed"}`, then `add_issue_comment` → `{owner, repo, issue_number: <tracking_issue>, body: "✓ Change archived: openspec/changes/archive/YYYY-MM-DD-<name>/"}`
+   - **CLI (fallback):** `gh issue close <tracking_issue> --repo <repo> --comment "✓ Change archived: openspec/changes/archive/YYYY-MM-DD-<name>/"`
+
+8. **Display summary and ask what's next**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - GitHub issue closed or left open (if plan.json existed)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+   Then use **AskUserQuestion** to ask:
+
+   > "Change archived! What would you like to do next?"
+
+   Options:
+   - **Sync dev docs** (`/sync-docs dev`) — update `.claude/docs/` to reflect current commands and conventions (recommended after any workflow change)
+   - **Start a new change** (`/opsx-new`) — begin working on the next feature or fix
+   - **Explore ideas first** (`/opsx-explore`) — think through what to build next before committing
+   - **Run feature counsel** (`/feature-counsel`) — get multi-persona analysis of what to build next
+   - **Done for now** — end the session
+
+For all output formats, see [examples/output-templates.md](examples/output-templates.md).
+
+**What's Next**
+
+The change is archived. Start your next change with:
+- `/opsx-new` — start a new change
+- `/opsx-explore` — explore ideas before starting
+
+**Capture Learnings**
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use /opsx-sync approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/opsx-archive/evals/evals.json b/.claude/skills/opsx-archive/evals/evals.json
new file mode 100644
index 00000000..3482242e
--- /dev/null
+++ b/.claude/skills/opsx-archive/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-archive","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"archive-complete","description":"Archive verified change","prompt":"Run /opsx-archive on register-export","setup":"Change verified, all tasks done","expected":"Should archive and sync","assertions":["Validates all artifacts complete","Syncs delta specs to main specs","Converts test cases to reusable scenarios","Creates PR to development branch","Closes GitHub tracking issue"]},{"id":"block-incomplete","description":"Block on incomplete change","prompt":"Archive a change with pending tasks","setup":"Tasks not all complete","expected":"Should refuse to archive","assertions":["Detects incomplete tasks","Reports which tasks remain","Suggests running /opsx-apply first","Does NOT archive incomplete changes"]},{"id":"spec-sync","description":"Sync delta specs correctly","prompt":"Archive change with delta specs","setup":"Change has ADDED and MODIFIED spec sections","expected":"Should merge deltas into main specs","assertions":["Applies ADDED requirements to main specs","Applies MODIFIED requirements","Handles REMOVED requirements","Preserves existing content not mentioned in delta"]}],"trigger_tests":{"should_trigger":["archive the change","complete the change","opsx archive register-export","finalize the change","close the change"],"should_not_trigger":["verify the change","apply the change","start new change","create a PR","sync specs"]}}
diff --git a/.claude/skills/opsx-archive/examples/output-templates.md b/.claude/skills/opsx-archive/examples/output-templates.md
new file mode 100644
index 00000000..b17e0fa8
--- /dev/null
+++ b/.claude/skills/opsx-archive/examples/output-templates.md
@@ -0,0 +1,70 @@
+# Output Templates
+
+## Archive Complete
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+**Feature docs:** ✓ Updated docs/features/<feature-file>.md
+**Changelog:** ✓ CHANGELOG.md updated (v<version>)
+**Test scenarios:** ✓ Created N scenario(s): TS-NNN, … (or "Skipped" / "No test-plan.md")
+
+All artifacts complete. All tasks complete.
+```
+
+## Archive Complete No Delta Specs
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+**Feature docs:** ✓ Updated docs/features/<feature-file>.md (or "No matching feature doc")
+**Changelog:** ✓ CHANGELOG.md updated (v<version>)
+**Test scenarios:** ✓ Created N scenario(s): TS-NNN, … (or "Skipped" / "No test-plan.md")
+
+All artifacts complete. All tasks complete.
+```
+
+## Archive Complete With Warnings
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+**Feature docs:** ✓ Updated docs/features/<feature-file>.md (or "Skipped — no mapping found")
+**Changelog:** ✓ CHANGELOG.md updated (v<version>)
+**Test scenarios:** ✓ Created N scenario(s): TS-NNN, … (or "Skipped" / "No test-plan.md")
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+## Archive Failed
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
diff --git a/.claude/skills/opsx-archive/learnings.md b/.claude/skills/opsx-archive/learnings.md
new file mode 100644
index 00000000..e0dec720
--- /dev/null
+++ b/.claude/skills/opsx-archive/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — opsx-archive
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/opsx-archive/templates/test-scenario-template.md b/.claude/skills/opsx-archive/templates/test-scenario-template.md
new file mode 100644
index 00000000..1b14b28b
--- /dev/null
+++ b/.claude/skills/opsx-archive/templates/test-scenario-template.md
@@ -0,0 +1,45 @@
+# Test Scenario File Format
+
+---
+id: TS-NNN
+title: "<TC title>"
+priority: <high|medium|low>
+category: <category>
+personas:
+- <persona-slug>
+test-commands:
+- <test command>
+tags:
+- <category>
+- regression
+status: active
+created: YYYY-MM-DD
+spec-refs:
+- <spec_ref>
+---
+
+# TS-NNN: <TC title>
+
+**Goal**: <derived goal>
+
+## Preconditions
+
+- <preconditions from TC>
+
+## Scenario
+
+- GIVEN <preconditions>
+- WHEN <steps>
+- THEN <expected result>
+
+## Test Data
+
+_(no specific test data required — use default dev environment)_
+
+## Acceptance Criteria
+
+- <THEN clause as checkbox>
+
+## Notes
+
+_Converted from test-plan.md TC-N during archive of `<change-name>` change._
diff --git a/.claude/skills/opsx-bulk-archive/SKILL.md b/.claude/skills/opsx-bulk-archive/SKILL.md
new file mode 100644
index 00000000..96ac3aa0
--- /dev/null
+++ b/.claude/skills/opsx-bulk-archive/SKILL.md
@@ -0,0 +1,300 @@
+---
+name: opsx-bulk-archive
+description: Archive multiple completed changes at once
+metadata:
+  category: Workflow
+  tags: [workflow, archive, experimental, bulk]
+---
+
+Archive multiple completed changes in a single operation.
+
+This skill allows you to batch-archive changes, handling spec conflicts intelligently by checking the codebase to determine what's actually implemented.
+
+**Input**: None required (prompts for selection)
+
+**Steps**
+
+1. **Get active changes**
+
+   Run `openspec list --json` to get all active changes.
+
+   If no active changes exist, inform user and stop.
+
+2. **Prompt for change selection**
+
+   Use **AskUserQuestion tool** with multi-select to let user choose changes:
+   - Show each change with its schema
+   - Include an option for "All changes"
+   - Allow any number of selections (1+ works, 2+ is the typical use case)
+
+   **IMPORTANT**: Do NOT auto-select. Always let the user choose.
+
+3. **Batch validation - gather status for all selected changes**
+
+   For each selected change, collect:
+
+   a. **Artifact status** - Run `openspec status --change "<name>" --json`
+      - Parse `schemaName` and `artifacts` list
+      - Note which artifacts are `done` vs other states
+
+   b. **Task completion** - Two checks in parallel:
+      - Read `openspec/changes/<name>/tasks.md` — count `- [ ]` (incomplete) vs `- [x]` (complete)
+      - If plan.json exists and has a `tracking_issue`, fetch the GitHub tracking issue body and count its `- [ ]` lines
+      - If tasks.md says all done but the GitHub tracking issue has unchecked boxes, flag as a sync gap (treat as incomplete)
+      - If no tasks file exists, note as "No tasks"
+
+   c. **Delta specs** - Check `openspec/changes/<name>/specs/` directory
+      - List which capability specs exist
+      - For each, extract requirement names (lines matching `### Requirement: <name>`)
+
+4. **Detect spec conflicts**
+
+   Build a map of `capability -> [changes that touch it]`:
+
+   ```
+   auth -> [change-a, change-b]  <- CONFLICT (2+ changes)
+   api  -> [change-c]            <- OK (only 1 change)
+   ```
+
+   A conflict exists when 2+ selected changes have delta specs for the same capability.
+
+5. **Resolve conflicts agentically**
+
+   **For each conflict**, investigate the codebase:
+
+   a. **Read the delta specs** from each conflicting change to understand what each claims to add/modify
+
+   b. **Search the codebase** for implementation evidence:
+      - Look for code implementing requirements from each delta spec
+      - Check for related files, functions, or tests
+
+   c. **Determine resolution**:
+      - If only one change is actually implemented -> sync that one's specs
+      - If both implemented -> apply in chronological order (older first, newer overwrites)
+      - If neither implemented -> skip spec sync, warn user
+
+   d. **Record resolution** for each conflict:
+      - Which change's specs to apply
+      - In what order (if both)
+      - Rationale (what was found in codebase)
+
+6. **Show consolidated status table**
+
+   Display a table summarizing all changes:
+
+   ```
+   | Change               | Artifacts | Tasks | Specs   | Conflicts | Status |
+   |---------------------|-----------|-------|---------|-----------|--------|
+   | schema-management   | Done      | 5/5   | 2 delta | None      | Ready  |
+   | project-config      | Done      | 3/3   | 1 delta | None      | Ready  |
+   | add-oauth           | Done      | 4/4   | 1 delta | auth (!)  | Ready* |
+   | add-verify-skill    | 1 left    | 2/5   | None    | None      | Warn   |
+   ```
+
+   For conflicts, show the resolution:
+   ```
+   * Conflict resolution:
+     - auth spec: Will apply add-oauth then add-jwt (both implemented, chronological order)
+   ```
+
+   For incomplete changes, show warnings:
+   ```
+   Warnings:
+   - add-verify-skill: 1 incomplete artifact, 3 incomplete tasks
+   ```
+
+7. **Confirm batch operation**
+
+   Use **AskUserQuestion tool** with a single confirmation.
+
+   **If ALL selected changes are complete** (all tasks `[x]`, all artifacts done):
+   - "Archive N changes?" with options:
+     - "Archive all N changes (Recommended)"
+     - "Cancel"
+
+   **If SOME selected changes have incomplete tasks or artifacts:**
+   - Show clearly which changes are blocked:
+     ```
+     ⛔ N change(s) have incomplete tasks and cannot be archived:
+     - <change-name>: X task(s) still open
+     ```
+   - Options:
+     - "Archive only M ready changes, skip incomplete (Recommended)"
+     - "Archive all N changes including incomplete (override)"
+     - "Cancel"
+   - Default/recommended is always to skip incomplete — never archive incomplete changes without explicit user override.
+
+8. **Execute archive for each confirmed change**
+
+   Process changes in the determined order (respecting conflict resolution):
+
+   a. **Sync specs** if delta specs exist:
+      - Use the openspec-sync-specs approach (agent-driven intelligent merge)
+      - For conflicts, apply in resolved order
+      - Track if sync was done
+
+   b. **Perform the archive**:
+      ```bash
+      mkdir -p openspec/changes/archive
+      mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+      ```
+
+   b2. **Close GitHub issue** (if plan.json exists in the change):
+      - Read `openspec/changes/archive/YYYY-MM-DD-<name>/plan.json`
+      - Collect all `tracking_issue` numbers across the batch for the user prompt in step 8.5
+
+   c. **Update feature documentation** (if `docs/features/README.md` exists):
+      - Read the Spec-to-Feature Mapping from `docs/features/README.md`
+      - Find the feature doc matching the change name or its delta spec names
+      - If found, read the current feature doc and the synced main spec(s), then update the feature doc to reflect any new/changed/removed features
+      - Preserve document structure (heading hierarchy, Specs section, Features section, Planned sections)
+      - Skip silently if no matching feature doc found
+
+   c2. **Update CHANGELOG.md**:
+      - **Determine the version**: read `openspec/app-config.json` → `version` field; fallback to `appinfo/info.xml` → `<version>`; fallback to `Unreleased`
+      - **Gather content**: completed tasks (`- [x]` items) from the change's `tasks.md`; change title/summary from `.openspec.yaml` or `proposal.md` if available
+      - **Categorize** using [Keep a Changelog](https://keepachangelog.com/) categories: Added / Changed / Fixed / Removed / Security
+      - **If CHANGELOG.md exists**: check for an existing `## [<version>]` entry — if found, merge new items into it; if not found, insert the new entry at the top (after `# Changelog` header)
+      - **If CHANGELOG.md does not exist**: create it with standard Keep a Changelog header and the new entry
+      - Across a bulk archive of N changes, all entries use the same version (resolved once before the loop). If multiple changes contribute to the same version entry, merge their items together under the appropriate categories.
+
+   d. **Track outcome** for each change:
+      - Success: archived successfully
+      - Failed: error during archive (record error)
+      - Skipped: user chose not to archive (if applicable)
+
+8.5. **Ask about closing GitHub issues**
+
+   If any archived changes had a `tracking_issue` in their plan.json, ask the user about closing them in a single prompt:
+
+   Use **AskUserQuestion** to ask:
+
+   > "Close GitHub issues for archived changes?"
+   >
+   > Issues: #<issue-1> (<change-1>), #<issue-2> (<change-2>), ...
+   >
+   > ℹ️ **Future feature:** In a planned update, issues will auto-close when the associated PR is merged, managed via a GitHub Project board (to do → refinement → ready for development → in progress → code quality check → code security check → review → done). For now, you can close them manually here.
+
+   Options:
+   - **Yes, close all issues** — close all with archive comments
+   - **No, leave them open** — skip closing (e.g., if PRs will handle it)
+
+   **If user chooses to close:**
+   For each tracking issue:
+   - **MCP (preferred):** GitHub MCP `update_issue` → `{owner, repo, issue_number: <tracking_issue>, state: "closed"}`, then `add_issue_comment` → `{..., body: "✓ Change archived"}`
+   - **CLI (fallback):** `gh issue close <tracking_issue> --repo <repo> --comment "✓ Change archived"`
+
+9. **Display summary**
+
+   Show final results:
+
+   ```
+   ## Bulk Archive Complete
+
+   Archived 3 changes:
+   - schema-management-cli -> archive/2026-01-19-schema-management-cli/
+   - project-config -> archive/2026-01-19-project-config/
+   - add-oauth -> archive/2026-01-19-add-oauth/
+
+   Skipped 1 change:
+   - add-verify-skill (user chose not to archive incomplete)
+
+   Spec sync summary:
+   - 4 delta specs synced to main specs
+   - 1 conflict resolved (auth: applied both in chronological order)
+   ```
+
+   If any failures:
+   ```
+   Failed 1 change:
+   - some-change: Archive directory already exists
+   ```
+
+**Conflict Resolution Examples**
+
+Example 1: Only one implemented
+```
+Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt]
+
+Checking add-oauth:
+- Delta adds "OAuth Provider Integration" requirement
+- Searching codebase... found src/auth/oauth.ts implementing OAuth flow
+
+Checking add-jwt:
+- Delta adds "JWT Token Handling" requirement
+- Searching codebase... no JWT implementation found
+
+Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
+```
+
+Example 2: Both implemented
+```
+Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql]
+
+Checking add-rest-api (created 2026-01-10):
+- Delta adds "REST Endpoints" requirement
+- Searching codebase... found src/api/rest.ts
+
+Checking add-graphql (created 2026-01-15):
+- Delta adds "GraphQL Schema" requirement
+- Searching codebase... found src/api/graphql.ts
+
+Resolution: Both implemented. Will apply add-rest-api specs first,
+then add-graphql specs (chronological order, newer takes precedence).
+```
+
+**Output On Success**
+
+```
+## Bulk Archive Complete
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+- <change-2> -> archive/YYYY-MM-DD-<change-2>/
+
+Spec sync summary:
+- N delta specs synced to main specs
+- No conflicts (or: M conflicts resolved)
+
+Feature docs updated:
+- docs/features/<feature-file-1>.md
+- docs/features/<feature-file-2>.md
+
+Changelog: ✓ CHANGELOG.md updated (v<version>, N entries added)
+```
+
+**Output On Partial Success**
+
+```
+## Bulk Archive Complete (partial)
+
+Archived N changes:
+- <change-1> -> archive/YYYY-MM-DD-<change-1>/
+
+Skipped M changes:
+- <change-2> (user chose not to archive incomplete)
+
+Failed K changes:
+- <change-3>: Archive directory already exists
+```
+
+**Output When No Changes**
+
+```
+## No Changes to Archive
+
+No active changes found. Use `/opsx-new` to create a new change.
+```
+
+**Guardrails**
+- Allow any number of changes (1+ is fine, 2+ is the typical use case)
+- Always prompt for selection, never auto-select
+- Detect spec conflicts early and resolve by checking codebase
+- When both changes are implemented, apply specs in chronological order
+- Skip spec sync only when implementation is missing (warn user)
+- Show clear per-change status before confirming
+- Use single confirmation for entire batch
+- Track and report all outcomes (success/skip/fail)
+- Preserve .openspec.yaml when moving to archive
+- Archive directory target uses current date: YYYY-MM-DD-<name>
+- If archive target exists, fail that change but continue with others
diff --git a/.claude/skills/opsx-bulk-archive/evals/evals.json b/.claude/skills/opsx-bulk-archive/evals/evals.json
new file mode 100644
index 00000000..ceab9552
--- /dev/null
+++ b/.claude/skills/opsx-bulk-archive/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-bulk-archive","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"batch-archive","description":"Archive multiple changes","prompt":"Run /opsx-bulk-archive","setup":"3 completed changes exist","expected":"Should archive all in order","assertions":["Detects all completed changes","Applies specs in chronological order","Handles conflicts between overlapping changes","Shows consolidated status table"]},{"id":"conflict-resolution","description":"Resolve overlapping specs","prompt":"Bulk archive with 2 changes touching same spec","setup":"Two changes modify same capability spec","expected":"Should investigate and resolve","assertions":["Detects overlapping spec sections","Investigates codebase for actual state","Applies chronological ordering","Asks user for ambiguous conflicts"]},{"id":"partial","description":"Some changes incomplete","prompt":"Bulk archive mix of complete and incomplete","setup":"2 complete, 1 incomplete","expected":"Should archive complete ones only","assertions":["Identifies which changes are ready","Archives only complete changes","Reports incomplete changes with reasons","Does NOT block complete ones on incomplete"]}],"trigger_tests":{"should_trigger":["archive all changes","bulk archive","archive multiple changes","opsx bulk archive","batch archive completed changes"],"should_not_trigger":["archive one change","apply changes","verify changes","create PR","sync specs"]}}
diff --git a/.claude/skills/opsx-continue/SKILL.md b/.claude/skills/opsx-continue/SKILL.md
new file mode 100644
index 00000000..4d79913a
--- /dev/null
+++ b/.claude/skills/opsx-continue/SKILL.md
@@ -0,0 +1,152 @@
+---
+name: opsx-continue
+description: Continue working on a change - create the next artifact (Experimental)
+metadata:
+  category: Workflow
+  tags: [workflow, artifacts, experimental]
+---
+
+Continue working on a change by creating the next artifact.
+
+**Input**: Optionally specify a change name after `/opsx-continue` (e.g., `/opsx-continue add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to work on.
+
+   Present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from `schema` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from `lastModified` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to continue.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+1.5. **Load app design context (if present)**
+
+   Before creating any artifact, check for and silently load app design documents. These inform proposal scope, architecture constraints, and applicable ADRs.
+
+   | File | If present, use to... |
+   |------|----------------------|
+   | `openspec/changes/<name>/context-brief.md` | **Specter intelligence brief** — features, user stories, stakeholders, journeys, schemas. Primary input when present — read fully |
+   | `openspec/architecture/` | Repo-specific ADRs — ADR-000 is always the data model |
+   | `.claude/openspec/architecture/` | Check company-wide ADRs (always apply) |
+   | `docs/ARCHITECTURE.md` | Understand app-specific technology decisions and data model |
+   | `docs/FEATURES.md` | Confirm the feature tier and roadmap phase for what is being built |
+
+   If a `context-brief.md` exists, it contains market-researched intelligence data. Use it directly — do not invent features or stories when the brief provides them.
+
+   If none of these files exist beyond the standard ADRs, proceed silently — do not block or prompt the user.
+
+2. **Check current status**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand current state. The response includes:
+   - `schemaName`: The workflow schema being used (e.g., "spec-driven")
+   - `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
+   - `isComplete`: Boolean indicating if all artifacts are complete
+
+3. **Act based on status**:
+
+   ---
+
+   **If all artifacts are complete (`isComplete: true`)**:
+   - Congratulate the user
+   - Show final status including the schema used
+   - Show **What's Next**:
+
+     **Recommended:** `/opsx-apply` — start implementing the tasks
+
+     **Optional before that:**
+     - `/opsx-plan-to-issues` — create GitHub Issues for progress tracking
+   - STOP
+
+   ---
+
+   **If artifacts are ready to create** (status shows artifacts with `status: "ready"`):
+   - First, determine which ready artifacts are **required** vs **optional**:
+     - Build the required set by walking the dependency graph backwards from `applyRequires` — any artifact transitively needed to satisfy `apply.requires` is required; all others are optional
+     - If any **required** artifacts are `status: "ready"`, pick the first one and proceed normally
+     - If only **optional** artifacts are `status: "ready"` (all required artifacts are done), ask the user using AskUserQuestion:
+       > "All required artifacts are done. These optional artifacts are available — would you like to create one before implementing?"
+       Present each optional artifact with its id and description as a choice, plus "No — proceed to implementation (`/opsx-apply`)"
+       Create whichever artifact the user selects, or stop if they choose to proceed.
+   - Pick the selected artifact with `status: "ready"` from the status output
+   - Get its instructions:
+     ```bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     ```
+   - Parse the JSON. The key fields are:
+     - `context`: Project background (constraints for you - do NOT include in output)
+     - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+     - `template`: The structure to use for your output file
+     - `instruction`: Schema-specific guidance
+     - `outputPath`: Where to write the artifact
+     - `dependencies`: Completed artifacts to read for context
+   - **Create the artifact file**:
+     - Read any completed dependency files for context
+     - Use `template` as the structure - fill in its sections
+     - Apply `context` and `rules` as constraints when writing - but do NOT copy them into the file
+     - Write to the output path specified in instructions
+   - Show what was created and what's now unlocked
+   - STOP after creating ONE artifact
+
+   ---
+
+   **If no artifacts are ready (all blocked)**:
+   - This shouldn't happen with a valid schema
+   - Show status and suggest checking for issues
+
+4. **After creating an artifact, show progress**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After each invocation, show:
+- Which artifact was created
+- Schema workflow being used
+- Current progress (N/M complete)
+- What artifacts are now unlocked
+
+**What's Next**
+
+**Recommended:** `/opsx-continue` — create the next artifact
+
+**Alternative (skip ahead):** `/opsx-ff` — generate all remaining artifacts in one go
+
+**Artifact Creation Guidelines**
+
+The artifact types and their purpose depend on the schema. Use the `instruction` field from the instructions output to understand what to create.
+
+Common artifact patterns:
+
+**spec-driven schema** (proposal → specs → design → tasks):
+- **proposal.md**: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
+  - The Capabilities section is critical - each capability listed will need a spec file.
+  - **After creating proposal.md**: check the `## Capabilities` section. For each capability listed under "Modified Capabilities" or "New Capabilities", find (or create) the corresponding spec at `openspec/specs/<capability>/spec.md` and:
+    - Add this change to the `**OpenSpec changes**` list (new entry at bottom, oldest-first ordering)
+    - Set `**Status**: in-progress` if it was `planned` or `done` — a new active change always moves the spec back to `in-progress`
+    - If the list exceeds 15 entries, apply the grouping rule from `.claude/docs/writing-specs.md` (group by timeframe, never remove entries)
+- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
+- **design.md**: Document technical decisions, architecture, and implementation approach. **MUST include a Seed Data section** (ADR-001) with realistic objects per schema — general organization data that works for municipalities, consultancies, or travel agencies. Research realistic field values. The apply agent generates `_registers.json` entries from this section.
+- **tasks.md**: Break down implementation into checkboxed tasks. Include a task for generating seed data in `_registers.json` when the change introduces or modifies schemas.
+
+For other schemas, follow the `instruction` field from the CLI output.
+
+**Guardrails**
+- Create ONE artifact per invocation
+- Always read dependency artifacts before creating a new one
+- Never skip artifacts or create out of order
+- If context is unclear, ask the user before creating
+- Verify the artifact file exists after writing before marking progress
+- Use the schema's artifact sequence, don't assume specific artifact names
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
diff --git a/.claude/skills/opsx-continue/evals/evals.json b/.claude/skills/opsx-continue/evals/evals.json
new file mode 100644
index 00000000..81fef66a
--- /dev/null
+++ b/.claude/skills/opsx-continue/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-continue","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"next-artifact","description":"Create next artifact","prompt":"Run /opsx-continue on register-export","setup":"Change has proposal but no specs yet","expected":"Should create the next ready artifact (specs)","assertions":["Detects which artifacts exist","Creates only the next required artifact","Stops after one artifact","Shows updated status"]},{"id":"all-done","description":"All artifacts complete","prompt":"Run /opsx-continue when all artifacts exist","setup":"All artifacts already created","expected":"Should report complete and suggest next step","assertions":["Detects all artifacts are present","Does NOT create duplicate artifacts","Suggests /opsx-apply or /opsx-plan-to-issues","Reports completion status"]},{"id":"loads-context","description":"Loads app design context","prompt":"Continue with design context available","setup":"App has ARCHITECTURE.md and FEATURES.md","expected":"Should load context before creating artifact","assertions":["Loads ARCHITECTURE.md","Loads FEATURES.md","Loads existing change artifacts","Uses context in new artifact"]}],"trigger_tests":{"should_trigger":["continue the change","create next artifact","opsx continue","next artifact for register-export","continue working on change"],"should_not_trigger":["start new change","fast forward","apply change","archive change","explore"]}}
diff --git a/.claude/skills/opsx-explore/SKILL.md b/.claude/skills/opsx-explore/SKILL.md
new file mode 100644
index 00000000..b1417c0e
--- /dev/null
+++ b/.claude/skills/opsx-explore/SKILL.md
@@ -0,0 +1,221 @@
+---
+name: opsx-explore
+description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
+metadata:
+  category: Workflow
+  tags: [workflow, explore, experimental, thinking]
+---
+
+**Check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- **On Haiku**: stop immediately:
+  > "This command requires Sonnet or Opus — strategic exploration and analysis need stronger reasoning than Haiku can provide. Please switch to Sonnet (`/model sonnet`) or Opus (`/model opus`) and re-run."
+- **On Sonnet or Opus**: ask the user using AskUserQuestion:
+
+**"You're on [active-model]. Which model should I use for this exploration session?"**
+
+| Model | Best for |
+|---|---|
+| ⚠️ **Sonnet** | Most exploration sessions |
+| ✅ **Opus** | Recommended — complex analysis, architecture decisions, and strategic thinking benefit from stronger reasoning |
+
+- **Sonnet**
+- **Opus**
+
+If the chosen model differs from the active model, tell the user:
+> "You're on [active-model] but chose [chosen-model]. To switch: use `/model [chosen-model]` in the chat input, then re-run this command."
+Then stop.
+
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first (e.g., start a change with `/opsx-new` or `/opsx-ff`). You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+**Input**: The argument after `/opsx-explore` is whatever the user wants to think about. Could be:
+- A vague idea: "real-time collaboration"
+- A specific problem: "the auth system is getting unwieldy"
+- A change name: "add-dark-mode" (to explore in context of that change)
+- A comparison: "postgres vs sqlite for this"
+- Nothing (just enter explore mode)
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+If the user mentioned a specific change name, read its artifacts for context.
+
+Also silently check for app design documents — if present, load them as background context:
+
+| File | If present, use to... |
+|------|----------------------|
+| `openspec/changes/<name>/context-brief.md` | Specter intelligence brief — features, stories, stakeholders, journeys. Use as primary context when exploring a specific change |
+| `openspec/architecture/` | Repo-specific ADRs — ADR-000 is always the data model |
+| `.claude/openspec/architecture/` | Check company-wide ADRs that constrain options |
+| `docs/ARCHITECTURE.md` | Understand app-specific technology decisions |
+| `docs/FEATURES.md` | Reference feature tiers and roadmap when discussing what to build |
+
+Do not mention loading these unless they're directly relevant to the conversation.
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create one?"
+  → Can transition to `/opsx-new` or `/opsx-ff`
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+   | Approach is uncertain / NC API availability unclear | `discovery.md` (optional artifact — create before specs) |
+   | Change introduces API consumed by other projects | `contract.md` (optional artifact — create before specs) |
+   | Change introduces DB/schema migrations | `migration.md` (optional artifact — create before tasks) |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might flow into action, result in captured artifacts, or just provide clarity.
+
+When things crystallize, offer a summary and natural next step:
+
+**If the idea is clear and ready to build:**
+
+**Recommended:** `/opsx-ff` — generate all artifacts and start implementing in one go
+
+**Alternative:** `/opsx-new` — scaffold the change first and review before generating artifacts
+
+**If more thinking is needed before building:**
+- Keep exploring — "We can pick this up anytime"
+- Or capture decisions in artifacts: "That's a design decision. Capture it in design.md?"
+
+The summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`) when done.
diff --git a/.claude/skills/opsx-ff/SKILL.md b/.claude/skills/opsx-ff/SKILL.md
new file mode 100644
index 00000000..83dd4c73
--- /dev/null
+++ b/.claude/skills/opsx-ff/SKILL.md
@@ -0,0 +1,183 @@
+---
+name: opsx-ff
+description: Create a change and generate all artifacts needed for implementation in one go
+metadata:
+  category: Workflow
+  tags: [workflow, artifacts, experimental]
+---
+
+Fast-forward through artifact creation - generate everything needed to start implementation.
+
+**Input**: The argument after `/opsx-ff` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+1.5. **Confirm the plan before generating**
+
+   Summarize your understanding and use **AskUserQuestion** to confirm before doing any work:
+
+   > "I'll create a change called `<name>` to: <one-sentence summary of what the user wants to build>. Ready to generate all artifacts?"
+
+   Options:
+   - **Yes, generate all artifacts** — proceed to Step 2
+   - **Let me clarify something first** — ask a targeted follow-up question, then re-confirm before continuing
+
+   **Do NOT create any files until confirmed.**
+
+1.55. **Select model for artifact generation**
+
+   This skill generates OpenSpec artifacts (proposal, specs, design, tasks) — the quality of these artifacts determines implementation quality downstream.
+
+   Ask the user using AskUserQuestion:
+
+   **"Which model should I use for artifact generation?"**
+
+   | Model | Pros | Cons |
+   |---|---|---|
+   | **Sonnet (recommended)** | Good artifact quality, moderate quota | Solid for most changes |
+   | **Opus** | Best design and architectural reasoning | Uses more quota — worth it for complex or architectural changes |
+
+   - **Sonnet**
+   - **Opus**
+
+   Use the **Agent tool** with `model: "sonnet"` or `model: "opus"` (whichever was selected) to delegate Steps 2–4. Pass the subagent:
+   - The change name
+   - Full contents of any app design files loaded in Step 1.6
+   - The complete instructions for Steps 2–4 from this skill
+   - Instruction: return a `DEFERRED_QUESTIONS` list at the end of its output — one entry per decision made under uncertainty (see Step 4c)
+
+   When the subagent completes:
+   - **MANDATORY**: If the subagent returned ANY `DEFERRED_QUESTIONS`, you MUST ask the user EVERY question — no exceptions. Do NOT evaluate, triage, or skip questions yourself. Do NOT conclude "no user input needed" for any question. The subagent deferred these questions precisely because they require human judgment.
+   - For each deferred question, use **AskUserQuestion** to present:
+     1. The question the subagent would have asked
+     2. The provisional decision the subagent made
+     3. Which artifact it affects
+   - Ask one question at a time. Wait for the user's answer before asking the next.
+   - After each answer: re-read the relevant artifact. If the user's answer differs from the provisional decision, update the artifact. Show "✎ Updated <artifact-id>" or "✓ Kept as-is" based on the user's explicit confirmation.
+   - Then continue to Step 5.
+
+1.6. **Load app design context (if present)**
+
+   Before creating any artifacts, check for and silently load app design documents. These inform proposal scope, architecture constraints, and applicable ADRs — the `openspec instructions` context does not include them.
+
+   | File | If present, use to... |
+   |------|----------------------|
+   | `openspec/changes/<name>/context-brief.md` | **Specter intelligence brief** — full features, user stories, stakeholders, schemas, standards, ADRs. This is the PRIMARY input when present — read it fully and use its data for all artifacts |
+   | `openspec/architecture/` | Check for repo-specific ADRs that constrain or inform the implementation approach |
+   | `.claude/openspec/architecture/` | Check company-wide ADRs (always apply) |
+   | `docs/ARCHITECTURE.md` | Understand app-specific technology decisions and data model |
+   | `docs/FEATURES.md` | Confirm the feature tier and roadmap phase for what is being built |
+
+   If a `context-brief.md` exists, it contains market-researched features with demand scores, real user stories with acceptance criteria, stakeholder profiles with pain points, and full data model schemas. Use this data directly in artifacts — do not invent features or stories when the brief provides them.
+
+   If none of these files exist beyond the standard ADRs, proceed silently — do not block or prompt the user.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "✓ Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Make a reasonable decision and continue — AskUserQuestion is not available inside a subagent
+      - Add an entry to `DEFERRED_QUESTIONS`: the question you would have asked, the decision you made, and which artifact it affected
+      - Return the full `DEFERRED_QUESTIONS` list at the end of your output so the parent can follow up with the user
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+
+**What's Next**
+
+**Recommended:** `/opsx-apply` — start implementing the tasks
+
+**Optional before that:**
+- `/opsx-plan-to-issues` — create GitHub Issues for progress tracking
+
+**Spec maintenance:** After creating artifacts, check the proposal's `## Capabilities` section. For each capability listed under "Modified Capabilities" or "New Capabilities", find (or create) the corresponding spec at `openspec/specs/<capability>/spec.md` and:
+- Add this change to the `**OpenSpec changes**` list (as a new line, after any existing entries, oldest-first ordering)
+- Set `**Status**: in-progress` if it was `planned` or `done` — a new active change always moves the spec back to `in-progress`
+- If the list exceeds 15 entries, apply the grouping rule from `.claude/docs/writing-specs.md` (group by timeframe, never remove entries)
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use the `template` as a starting point, filling in based on context
+- **design.md MUST include a Seed Data section** (ADR-001): research realistic objects per schema with general organization data (municipality, consultancy, travel agency). The apply agent generates `_registers.json` entries from this section
+- **tasks.md MUST include a seed data task** when the change introduces or modifies OpenRegister schemas
+
+## Capture Learnings
+
+After artifacts are created, review what happened and append any new observations to [learnings.md](learnings.md):
+
+- **Patterns That Work** — artifact generation approaches that produce high-quality, implementation-ready output
+- **Mistakes to Avoid** — artifact generation errors, underspecified decisions, or deferred question pitfalls
+- **Domain Knowledge** — facts about OpenSpec artifact schemas, dependency ordering, or generation patterns
+- **Open Questions** — unresolved artifact quality challenges for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- **NEVER skip deferred questions from the subagent** — every `DEFERRED_QUESTIONS` entry MUST be presented to the user via AskUserQuestion, regardless of how reasonable the subagent's provisional decision seems
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/opsx-ff/evals/evals.json b/.claude/skills/opsx-ff/evals/evals.json
new file mode 100644
index 00000000..61476a17
--- /dev/null
+++ b/.claude/skills/opsx-ff/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-ff","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"full-artifacts","description":"Generate all artifacts","prompt":"Run /opsx-ff for register-export","setup":"Change directory exists from opsx-new","expected":"Should create proposal, specs, design, tasks in one session","assertions":["Creates proposal.md","Creates delta specs","Creates design/contract if needed","Creates tasks.md with numbered tasks","Loads ARCHITECTURE.md, FEATURES.md, ADRs for context"]},{"id":"model-guard","description":"Blocks on Haiku","prompt":"Run /opsx-ff on Haiku model","setup":"Model is Haiku","expected":"Should block and suggest Sonnet/Opus","assertions":["Detects Haiku model","Stops immediately","Suggests switching to Sonnet or Opus","Does NOT attempt artifact generation"]},{"id":"handoff","description":"Suggests next steps","prompt":"After artifacts are generated","setup":"All artifacts created","expected":"Should suggest apply or plan-to-issues","assertions":["Suggests /opsx-apply for implementation","Suggests /opsx-plan-to-issues for tracking","Shows artifact completion status","Does NOT auto-proceed to implementation"]}],"trigger_tests":{"should_trigger":["fast forward the change","generate all artifacts","opsx ff register-export","create all change artifacts","ff the change"],"should_not_trigger":["start a new change","apply the change","continue one artifact","archive the change","explore the change"]}}
diff --git a/.claude/skills/opsx-ff/learnings.md b/.claude/skills/opsx-ff/learnings.md
new file mode 100644
index 00000000..a2fb65b1
--- /dev/null
+++ b/.claude/skills/opsx-ff/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — opsx-ff
+
+## Patterns That Work
+<!-- Artifact generation approaches that produce high-quality, implementation-ready output -->
+
+## Mistakes to Avoid
+<!-- Artifact generation errors, underspecified decisions, or deferred question pitfalls -->
+
+## Domain Knowledge
+<!-- Facts about OpenSpec artifact schemas, dependency ordering, or generation patterns -->
+
+## Open Questions
+<!-- Unresolved artifact quality challenges for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/opsx-new/SKILL.md b/.claude/skills/opsx-new/SKILL.md
new file mode 100644
index 00000000..2387952c
--- /dev/null
+++ b/.claude/skills/opsx-new/SKILL.md
@@ -0,0 +1,95 @@
+---
+name: opsx-new
+description: Start a new change using the experimental artifact workflow (OPSX)
+metadata:
+  category: Workflow
+  tags: [workflow, artifacts, experimental]
+---
+
+Start a new change using the experimental artifact-driven approach.
+
+**Input**: The argument after `/opsx-new` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Determine the workflow schema**
+
+   Use the default schema (omit `--schema`) unless the user explicitly requests a different workflow.
+
+   **Use a different schema only if the user mentions:**
+   - A specific schema name → use `--schema <name>`
+   - "show workflows" or "what workflows" → run `openspec schemas --json` and let them choose
+
+   **Otherwise**: Omit `--schema` to use the default.
+
+3. **Load architectural context**
+
+   Before creating the change, silently read all applicable ADRs. These inform what is architecturally possible and constrain the proposal scope.
+
+   | Location | What | When |
+   |----------|------|------|
+   | `openspec/changes/<name>/context-brief.md` | Specter intelligence brief — features, stories, stakeholders, schemas | If present — this is the primary input |
+   | `openspec/architecture/adr-*.md` | Repo-specific ADRs (data model, workflows, security) | Always check |
+   | `.claude/openspec/architecture/adr-*.md` | Company-wide ADRs (13 Conduction-wide decisions) | Always load |
+   | `docs/ARCHITECTURE.md` | App-specific technology decisions | If present |
+   | `docs/FEATURES.md` | Feature tiers and roadmap phases | If present |
+
+   Read these silently — do not list them to the user. If a `context-brief.md` exists for this change, it contains market-researched intelligence data. Use it as the primary source for the change description — do not ask the user what to build when the brief already describes it.
+
+   Use them to inform the change name validation (e.g., if the user asks for something that contradicts an ADR, flag it).
+
+4. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   Add `--schema <name>` only if the user requested a specific workflow.
+   This creates a scaffolded change at `openspec/changes/<name>/` with the selected schema.
+
+5. **Show the artifact status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+   This shows which artifacts need to be created and which are ready (dependencies satisfied).
+
+6. **Get instructions for the first artifact**
+   The first artifact depends on the schema. Check the status output to find the first artifact with status "ready".
+   ```bash
+   openspec instructions <first-artifact-id> --change "<name>"
+   ```
+   This outputs the template and context for creating the first artifact.
+
+7. **Ask how to proceed**
+
+   After showing the status and first artifact template, use **AskUserQuestion** to ask:
+
+   > "Change `<name>` is ready. How would you like to proceed?"
+
+   Options:
+   - **Generate all artifacts at once** (`/opsx-ff <name>`) — fastest path to implementation; I'll create proposal, specs, design, and tasks in one go
+   - **Create artifacts one at a time** (`/opsx-continue <name>`) — more control; you review and approve each artifact before the next
+   - **Think through the problem first** (`/opsx-explore`) — explore ideas, constraints, and approach before committing to a direction
+   - **Done for now** — come back later with `/opsx-continue <name>`
+
+**Output**
+
+After completing the steps, summarize:
+- Change name and location
+- Schema/workflow being used and its artifact sequence
+- Current status (0/N artifacts complete)
+- The template for the first artifact
+
+**Guardrails**
+- Do NOT create any artifacts yet - just show the instructions
+- Do NOT advance beyond showing the first artifact template
+- If the name is invalid (not kebab-case), ask for a valid name
+- If a change with that name already exists, suggest using `/opsx-continue` instead
+- Pass --schema if using a non-default workflow
diff --git a/.claude/skills/opsx-onboard/SKILL.md b/.claude/skills/opsx-onboard/SKILL.md
new file mode 100644
index 00000000..e7aa12de
--- /dev/null
+++ b/.claude/skills/opsx-onboard/SKILL.md
@@ -0,0 +1,430 @@
+---
+name: opsx-onboard
+description: Guided onboarding - walk through a complete OpenSpec workflow cycle with narration
+metadata:
+  category: Workflow
+  tags: [workflow, onboarding, tutorial, learning]
+---
+
+Guide the user through their first complete OpenSpec workflow cycle. This is a teaching experience—you'll do real work in their codebase while explaining each step.
+
+---
+
+## Preflight
+
+Before starting, check if OpenSpec is initialized:
+
+```bash
+openspec status --json 2>&1 || echo "NOT_INITIALIZED"
+```
+
+**If not initialized:**
+> OpenSpec isn't set up in this project yet. Run `openspec init` first, then come back to `/opsx-onboard`.
+
+Stop here if not initialized.
+
+**If initialized**, also validate the configuration:
+
+```bash
+openspec validate --all 2>&1
+```
+
+If validation fails, display the errors and ask whether the user wants to fix them before continuing or proceed anyway.
+
+---
+
+## Phase 1: Welcome
+
+Display:
+
+```
+## Welcome to OpenSpec!
+
+I'll walk you through a complete change cycle—from idea to implementation—using a real task in your codebase. Along the way, you'll learn the workflow by doing it.
+
+**What we'll do:**
+1. Pick a small, real task in your codebase
+2. Explore the problem briefly
+3. Create a change (the container for our work)
+4. Build the artifacts: proposal → specs → design → tasks
+5. Implement the tasks
+6. Archive the completed change
+
+**Time:** ~15-20 minutes
+
+Let's start by finding something to work on.
+```
+
+---
+
+## Phase 2: Task Selection
+
+### Codebase Analysis
+
+Scan the codebase for small improvement opportunities. Look for:
+
+1. **TODO/FIXME comments** - Search for `TODO`, `FIXME`, `HACK`, `XXX` in code files
+2. **Missing error handling** - `catch` blocks that swallow errors, risky operations without try-catch
+3. **Functions without tests** - Cross-reference `src/` with test directories
+4. **Type issues** - `any` types in TypeScript files (`: any`, `as any`)
+5. **Debug artifacts** - `console.log`, `console.debug`, `debugger` statements in non-debug code
+6. **Missing validation** - User input handlers without validation
+
+Also check recent git activity:
+```bash
+git log --oneline -10 2>/dev/null || echo "No git history"
+```
+
+### Present Suggestions
+
+From your analysis, present 3-4 specific suggestions:
+
+```
+## Task Suggestions
+
+Based on scanning your codebase, here are some good starter tasks:
+
+**1. [Most promising task]**
+   Location: `src/path/to/file.ts:42`
+   Scope: ~1-2 files, ~20-30 lines
+   Why it's good: [brief reason]
+
+**2. [Second task]**
+   Location: `src/another/file.ts`
+   Scope: ~1 file, ~15 lines
+   Why it's good: [brief reason]
+
+**3. [Third task]**
+   Location: [location]
+   Scope: [estimate]
+   Why it's good: [brief reason]
+
+**4. Something else?**
+   Tell me what you'd like to work on.
+
+Which task interests you? (Pick a number or describe your own)
+```
+
+**If nothing found:** Fall back to asking what the user wants to build:
+> I didn't find obvious quick wins in your codebase. What's something small you've been meaning to add or fix?
+
+### Scope Guardrail
+
+If the user picks or describes something too large (major feature, multi-day work):
+
+```
+That's a valuable task, but it's probably larger than ideal for your first OpenSpec run-through.
+
+For learning the workflow, smaller is better—it lets you see the full cycle without getting stuck in implementation details.
+
+**Options:**
+1. **Slice it smaller** - What's the smallest useful piece of [their task]? Maybe just [specific slice]?
+2. **Pick something else** - One of the other suggestions, or a different small task?
+3. **Do it anyway** - If you really want to tackle this, we can. Just know it'll take longer.
+
+What would you prefer?
+```
+
+Let the user override if they insist—this is a soft guardrail.
+
+---
+
+## Phase 3: Explore Demo
+
+Once a task is selected, briefly demonstrate explore mode:
+
+```
+Before we create a change, let me quickly show you **explore mode**—it's how you think through problems before committing to a direction.
+```
+
+Spend 1-2 minutes investigating the relevant code:
+- Read the file(s) involved
+- Draw a quick ASCII diagram if it helps
+- Note any considerations
+
+```
+## Quick Exploration
+
+[Your brief analysis—what you found, any considerations]
+
+┌─────────────────────────────────────────┐
+│   [Optional: ASCII diagram if helpful]  │
+└─────────────────────────────────────────┘
+
+Explore mode (`/opsx-explore`) is for this kind of thinking—investigating before implementing. You can use it anytime you need to think through a problem.
+
+Now let's create a change to hold our work.
+```
+
+**PAUSE** - Wait for user acknowledgment before proceeding.
+
+---
+
+## Phase 4: Create the Change
+
+**EXPLAIN:**
+```
+## Creating a Change
+
+A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in `openspec/changes/<name>/` and holds your artifacts—proposal, specs, design, tasks.
+
+Let me create one for our task.
+```
+
+**DO:** Create the change with a derived kebab-case name:
+```bash
+openspec new change "<derived-name>"
+```
+
+**SHOW:**
+```
+Created: `openspec/changes/<name>/`
+
+The folder structure:
+```
+openspec/changes/<name>/
+├── proposal.md    ← Why we're doing this (empty, we'll fill it)
+├── design.md      ← How we'll build it (empty)
+├── specs/         ← Detailed requirements (empty)
+└── tasks.md       ← Implementation checklist (empty)
+```
+
+Now let's fill in the first artifact—the proposal.
+```
+
+---
+
+## Phase 5: Proposal
+
+**EXPLAIN:**
+```
+## The Proposal
+
+The proposal captures **why** we're making this change and **what** it involves at a high level. It's the "elevator pitch" for the work.
+
+I'll draft one based on our task.
+```
+
+**DO:** Draft the proposal content (don't save yet) using [examples/proposal-template.md](examples/proposal-template.md) as the template. Show the draft to the user.
+
+**PAUSE** - Wait for user approval/feedback.
+
+After approval, save the proposal:
+```bash
+openspec instructions proposal --change "<name>" --json
+```
+Then write the content to `openspec/changes/<name>/proposal.md`.
+
+```
+Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
+
+Next up: specs.
+```
+
+---
+
+## Phase 6: Specs
+
+**EXPLAIN:**
+```
+## Specs
+
+Specs define **what** we're building in precise, testable terms. They use a requirement/scenario format that makes expected behavior crystal clear.
+
+For a small task like this, we might only need one spec file.
+```
+
+**DO:** Create the spec file:
+```bash
+mkdir -p openspec/changes/<name>/specs/<capability-name>
+```
+
+Draft the spec content using [examples/specs-template.md](examples/specs-template.md) as the template. Save to `openspec/changes/<name>/specs/<capability>/spec.md`.
+
+---
+
+## Phase 7: Design
+
+**EXPLAIN:**
+```
+## Design
+
+The design captures **how** we'll build it—technical decisions, tradeoffs, approach.
+
+For small changes, this might be brief. That's fine—not every change needs deep design discussion.
+```
+
+**DO:** Draft design.md using [examples/design-template.md](examples/design-template.md) as the template. Save to `openspec/changes/<name>/design.md`.
+
+---
+
+## Phase 8: Tasks
+
+**EXPLAIN:**
+```
+## Tasks
+
+Finally, we break the work into implementation tasks—checkboxes that drive the apply phase.
+
+These should be small, clear, and in logical order.
+```
+
+**DO:** Generate tasks based on specs and design using [examples/tasks-template.md](examples/tasks-template.md) as the template.
+
+**PAUSE** - Wait for user to confirm they're ready to implement.
+
+Save to `openspec/changes/<name>/tasks.md`.
+
+---
+
+## Phase 9: Apply (Implementation)
+
+**EXPLAIN:**
+```
+## Implementation
+
+Now we implement each task, checking them off as we go. I'll announce each one and occasionally note how the specs/design informed the approach.
+```
+
+**DO:** For each task:
+
+1. Announce: "Working on task N: [description]"
+2. Implement the change in the codebase
+3. Reference specs/design naturally: "The spec says X, so I'm doing Y"
+4. Mark complete in tasks.md: `- [ ]` → `- [x]`
+5. Brief status: "✓ Task N complete"
+
+Keep narration light—don't over-explain every line of code.
+
+After all tasks:
+
+```
+## Implementation Complete
+
+All tasks done:
+- [x] Task 1
+- [x] Task 2
+- [x] ...
+
+The change is implemented! One more step—let's archive it.
+```
+
+---
+
+## Phase 10: Archive
+
+**EXPLAIN:**
+```
+## Archiving
+
+When a change is complete, we archive it. This moves it from `openspec/changes/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
+
+Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
+```
+
+**DO:**
+```bash
+openspec archive "<name>"
+```
+
+**SHOW:**
+```
+Archived to: `openspec/changes/archive/YYYY-MM-DD-<name>/`
+
+The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
+```
+
+---
+
+## Phase 11: Recap & Next Steps
+
+```
+## Congratulations!
+
+You just completed a full OpenSpec cycle:
+
+1. **Explore** - Thought through the problem
+2. **New** - Created a change container
+3. **Proposal** - Captured WHY
+4. **Specs** - Defined WHAT in detail
+5. **Design** - Decided HOW
+6. **Tasks** - Broke it into steps
+7. **Apply** - Implemented the work
+8. **Archive** - Preserved the record
+
+This same rhythm works for any size change—a small fix or a major feature.
+
+---
+
+## Command Reference
+
+| Command | What it does |
+|---------|--------------|
+| `/opsx-explore` | Think through problems before/during work |
+| `/opsx-new` | Start a new change, step through artifacts |
+| `/opsx-ff` | Fast-forward: create all artifacts at once |
+| `/opsx-continue` | Continue working on an existing change |
+| `/opsx-apply` | Implement tasks from a change |
+| `/opsx-verify` | Verify implementation matches artifacts |
+| `/opsx-archive` | Archive a completed change |
+
+---
+
+## What's Next?
+
+Try `/opsx-new` or `/opsx-ff` on something you actually want to build. You've got the rhythm now!
+```
+
+---
+
+## Graceful Exit Handling
+
+### User wants to stop mid-way
+
+If the user says they need to stop, want to pause, or seem disengaged:
+
+```
+No problem! Your change is saved at `openspec/changes/<name>/`.
+
+To pick up where we left off later:
+- `/opsx-continue <name>` - Resume artifact creation
+- `/opsx-apply <name>` - Jump to implementation (if tasks exist)
+
+The work won't be lost. Come back whenever you're ready.
+```
+
+Exit gracefully without pressure.
+
+### User just wants command reference
+
+If the user says they just want to see the commands or skip the tutorial:
+
+```
+## OpenSpec Quick Reference
+
+| Command | What it does |
+|---------|--------------|
+| `/opsx-explore` | Think through problems (no code changes) |
+| `/opsx-new <name>` | Start a new change, step by step |
+| `/opsx-ff <name>` | Fast-forward: all artifacts at once |
+| `/opsx-continue <name>` | Continue an existing change |
+| `/opsx-apply <name>` | Implement tasks |
+| `/opsx-verify <name>` | Verify implementation |
+| `/opsx-archive <name>` | Archive when done |
+
+Try `/opsx-new` to start your first change, or `/opsx-ff` if you want to move fast.
+```
+
+Exit gracefully.
+
+---
+
+## Guardrails
+
+- **Follow the EXPLAIN → DO → SHOW → PAUSE pattern** at key transitions (after explore, after proposal draft, after tasks, after archive)
+- **Keep narration light** during implementation—teach without lecturing
+- **Don't skip phases** even if the change is small—the goal is teaching the workflow
+- **Pause for acknowledgment** at marked points, but don't over-pause
+- **Handle exits gracefully**—never pressure the user to continue
+- **Use real codebase tasks**—don't simulate or use fake examples
+- **Adjust scope gently**—guide toward smaller tasks but respect user choice
diff --git a/.claude/skills/opsx-onboard/evals/evals.json b/.claude/skills/opsx-onboard/evals/evals.json
new file mode 100644
index 00000000..35109617
--- /dev/null
+++ b/.claude/skills/opsx-onboard/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-onboard","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"guided-tour","description":"Walk through full workflow","prompt":"Run /opsx-onboard","setup":"App with codebase, no prior OpenSpec usage","expected":"Should guide through complete cycle with narration","assertions":["Scans codebase for improvement opportunities","Presents 3-4 starter tasks","Guides through proposal→specs→design→tasks→apply→archive","Narrates each step with explanations"]},{"id":"real-work","description":"Does real work in codebase","prompt":"Follow onboarding to implement a small fix","setup":"Codebase with TODOs or missing tests","expected":"Should make real changes, not just demonstrate","assertions":["Identifies real issues (TODOs, missing tests, type issues)","Creates actual change artifacts","Implements actual code changes","Runs quality checks on changes"]},{"id":"educational","description":"Explains as it goes","prompt":"Check narration quality during onboarding","setup":"Mid-onboarding","expected":"Should explain WHY at each step","assertions":["Explains purpose of each artifact type","Describes workflow philosophy","Points out guardrails and why they exist","Suggests resources for deeper learning"]}],"trigger_tests":{"should_trigger":["onboard me to OpenSpec","walk me through the workflow","opsx onboard","teach me OpenSpec","guided tour of the workflow"],"should_not_trigger":["start a new change","apply a change","explore the app","create a PR","run tests"]}}
diff --git a/.claude/skills/opsx-onboard/examples/design-template.md b/.claude/skills/opsx-onboard/examples/design-template.md
new file mode 100644
index 00000000..6ccd6b8c
--- /dev/null
+++ b/.claude/skills/opsx-onboard/examples/design-template.md
@@ -0,0 +1,29 @@
+# Design Template
+
+```
+Here's the design:
+
+---
+
+## Context
+
+[Brief context about the current state]
+
+## Goals / Non-Goals
+
+**Goals:**
+- [What we're trying to achieve]
+
+**Non-Goals:**
+- [What's explicitly out of scope]
+
+## Decisions
+
+### Decision 1: [Key decision]
+
+[Explanation of approach and rationale]
+
+---
+
+For a small task, this captures the key decisions without over-engineering.
+```
diff --git a/.claude/skills/opsx-onboard/examples/proposal-template.md b/.claude/skills/opsx-onboard/examples/proposal-template.md
new file mode 100644
index 00000000..17543aae
--- /dev/null
+++ b/.claude/skills/opsx-onboard/examples/proposal-template.md
@@ -0,0 +1,32 @@
+# Proposal Template
+
+```
+Here's a draft proposal:
+
+---
+
+## Why
+
+[1-2 sentences explaining the problem/opportunity]
+
+## What Changes
+
+[Bullet points of what will be different]
+
+## Capabilities
+
+### New Capabilities
+- `<capability-name>`: [brief description]
+
+### Modified Capabilities
+<!-- If modifying existing behavior -->
+
+## Impact
+
+- `src/path/to/file.ts`: [what changes]
+- [other files if applicable]
+
+---
+
+Does this capture the intent? I can adjust before we save it.
+```
diff --git a/.claude/skills/opsx-onboard/examples/specs-template.md b/.claude/skills/opsx-onboard/examples/specs-template.md
new file mode 100644
index 00000000..383ca0be
--- /dev/null
+++ b/.claude/skills/opsx-onboard/examples/specs-template.md
@@ -0,0 +1,23 @@
+# Specs Template
+
+```
+Here's the spec:
+
+---
+
+## ADDED Requirements
+
+### Requirement: <Name>
+
+<Description of what the system should do>
+
+#### Scenario: <Scenario name>
+
+- **WHEN** <trigger condition>
+- **THEN** <expected outcome>
+- **AND** <additional outcome if needed>
+
+---
+
+This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
+```
diff --git a/.claude/skills/opsx-onboard/examples/tasks-template.md b/.claude/skills/opsx-onboard/examples/tasks-template.md
new file mode 100644
index 00000000..1339a59f
--- /dev/null
+++ b/.claude/skills/opsx-onboard/examples/tasks-template.md
@@ -0,0 +1,20 @@
+# Tasks Template
+
+```
+Here are the implementation tasks:
+
+---
+
+## 1. [Category or file]
+
+- [ ] 1.1 [Specific task]
+- [ ] 1.2 [Specific task]
+
+## 2. Verify
+
+- [ ] 2.1 [Verification step]
+
+---
+
+Each checkbox becomes a unit of work in the apply phase. Ready to implement?
+```
diff --git a/.claude/skills/opsx-pipeline/SKILL.md b/.claude/skills/opsx-pipeline/SKILL.md
new file mode 100644
index 00000000..ea401c6a
--- /dev/null
+++ b/.claude/skills/opsx-pipeline/SKILL.md
@@ -0,0 +1,486 @@
+---
+name: opsx-pipeline
+description: Process multiple OpenSpec changes in parallel using subagents — full lifecycle from proposal to merged PR
+metadata:
+  category: Workflow
+  tags: [workflow, parallel, pipeline, experimental]
+---
+
+Process one or more OpenSpec change proposals through the full lifecycle using parallel subagents. Each change gets its own agent, worktree, branch, and PR.
+
+**Input**: Optionally specify change names, a repo name, or `all` to process all open proposals.
+
+Examples:
+- `/opsx-pipeline all` — process all open proposals across all repos
+- `/opsx-pipeline procest` — process all open proposals in Procest
+- `/opsx-pipeline sla-tracking routing` — process specific changes by name
+
+**Overview**
+
+This command automates the full OpenSpec lifecycle per change:
+
+```
+proposal → ff (specs/design/tasks) → apply (implement) → verify → browser verify (optional) → archive + feature docs → PR
+```
+
+Each change runs as an independent subagent in an isolated git worktree on its own feature branch. The main agent orchestrates, monitors, and reports.
+
+---
+
+## Steps
+
+### 1. Discover changes to process
+
+Scan for open proposals (directories in `openspec/changes/` that contain a `proposal.md` but are NOT in `archive/`).
+
+```bash
+# For each app directory, find open proposals
+for app in procest pipelinq docudesk openregister opencatalogi mydash nldesign larpingapp openconnector softwarecatalog zaakafhandelapp; do
+  if [ -d "$app/openspec/changes" ]; then
+    for change in $app/openspec/changes/*/proposal.md; do
+      echo "$app:$(basename $(dirname $change))"
+    done
+  fi
+done
+```
+
+Also check `.github/openspec/changes/` for org-wide proposals.
+
+**Filter** based on input:
+- `all` → process everything found
+- `<repo-name>` → only changes in that repo
+- `<change-name> [change-name...]` → only those specific changes (search across all repos)
+
+**If no input provided**, list all discovered changes and use **AskUserQuestion** to let the user select which to process.
+
+### 2. Build the execution plan
+
+For each change, determine:
+- **App directory**: e.g., `procest/`
+- **Change name**: e.g., `brp-kvk-register-sets`
+- **GitHub repo**: e.g., `ConductionNL/procest` (from git remote)
+- **Existing issue**: Check if an `openspec`-labeled issue already exists for this change (search GitHub issues by title)
+
+Display the plan:
+
+```
+## Pipeline Plan
+
+| # | App | Change | GitHub Repo | Issue |
+|---|-----|--------|-------------|-------|
+| 1 | procest | brp-kvk-register-sets | ConductionNL/procest | #103 |
+| 2 | pipelinq | sla-tracking | ConductionNL/pipelinq | #79 |
+| ... | ... | ... | ... | ... |
+
+Total: N changes across M repositories
+Max parallel agents: 5 (browser-2 through browser-5, browser-7)
+```
+
+Use **AskUserQuestion** to confirm: "Process these N changes? Each will get a feature branch, full implementation, and PR to development."
+
+Options:
+- **Yes, start the pipeline** — proceed
+- **Let me adjust the selection** — re-select changes
+- **Cancel** — abort
+
+### 2.5. Select model strategy
+
+Explain the model options for implementation sub-agents:
+
+| Model | Speed | Quota | Best for |
+|---|---|---|---|
+| **Haiku** | Fastest | Low | Config tweaks, text changes, single-file edits, minor fixes |
+| **Sonnet** | Balanced | Moderate | Feature additions, standard CRUD, multi-file changes |
+| **Opus** | Slowest | High | Complex architectural changes, new services/schemas, cross-app impact |
+
+Ask the user using AskUserQuestion:
+
+**"How should models be assigned across the {N} changes in this pipeline run?"**
+
+- **One model for all** — pick a single model for every sub-agent
+- **Choose per change** — you select the model for each change individually
+- **Auto-select per change** — I'll read each change's proposal and assign the best model based on scope
+
+---
+
+**If "One model for all"**, ask using AskUserQuestion:
+
+> **"Which model for all sub-agents?"**
+> - **Haiku** — fastest, lowest quota. Best if all changes are small/simple.
+> - **Sonnet (recommended)** — balanced. Handles most feature work well.
+> - **Opus** — highest quality. Best for complex architectural changes, but uses significant quota per agent — consider carefully with multiple parallel changes.
+
+Store as `{PIPELINE_MODEL}` (apply uniformly to all agents).
+
+---
+
+**If "Choose per change"**, for each change show its name and (if available) the title from its `proposal.md`. Ask per change using AskUserQuestion:
+
+> **"Model for `[change-name]`?"**
+> - **Haiku** — simple change (config, text, minor fix)
+> - **Sonnet (recommended)** — standard feature work
+> - **Opus** — complex change (new architecture, cross-app impact)
+
+Store results as `{CHANGE_MODELS}` map of `change-name → model`.
+
+---
+
+**If "Auto-select per change"**, for each change read the first 50 lines of its `proposal.md` (title, type, scope). Assign:
+- **Haiku**: Config/copy/text changes, single-file edits, documentation only
+- **Sonnet**: New features, multi-file changes, standard CRUD, UI additions
+- **Opus**: New services or schemas, cross-app changes, migrations, architectural decisions, security-sensitive changes
+
+Show the assignments and ask using AskUserQuestion:
+
+> **"Auto-assigned models — proceed or adjust?"**
+> - **Proceed** — use as assigned
+> - **Adjust** — change any individual assignments
+
+Store results as `{CHANGE_MODELS}` map of `change-name → model`.
+
+---
+
+### 2.75. Check local environment & browser testing
+
+Before launching agents, check whether the Nextcloud development environment is reachable:
+
+```bash
+curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/status.php
+```
+
+**If reachable (HTTP 200)**, ask using AskUserQuestion:
+
+**"Nextcloud is running at localhost:8080. Include browser testing in the pipeline?"**
+
+- **Yes, test all changes** — every subagent gets a browser and runs UI verification after implementation
+- **Yes, but only for UI changes** — only assign browsers to changes that touch frontend files (`.vue`, `.js`, `.ts`, `.css`)
+- **No, skip browser testing** — code-only verification, no browser
+
+Store as `{BROWSER_TESTING}` (`all`, `ui-only`, or `none`).
+
+**If NOT reachable**, ask using AskUserQuestion:
+
+**"Nextcloud is not running at localhost:8080. Browser testing requires a running environment."**
+
+- **Start it and retry** — I'll wait while you start the environment, then re-check
+- **Skip browser testing** — proceed without browser verification
+- **Cancel pipeline** — abort so you can fix the environment first
+
+If the user chooses "Start it and retry", re-run the health check after they confirm. If still unreachable, ask again.
+
+When `{BROWSER_TESTING}` is `all` or `ui-only`, assign browser numbers to eligible agents: browser-2 through browser-5, browser-7 (max 5 concurrent).
+
+---
+
+### 3. Prepare branches and worktrees
+
+For each change, **before launching agents**:
+
+a. **Determine branch name**: `feature/<issue-number>/<change-name>`
+   - If no issue exists yet, create one first (titled `[OpenSpec] <change-title>`, labeled `openspec`)
+   - Example: `feature/103/brp-kvk-register-sets`
+
+b. **Create git worktree**:
+   ```bash
+   cd <app-directory>
+   git fetch origin development
+   git worktree add /tmp/worktrees/<app>-<change-name> -b feature/<issue-number>/<change-name> origin/development
+   ```
+
+c. **Update issue status**: Add a comment "🚀 Pipeline started — processing change"
+
+### 4. Launch parallel subagents
+
+Launch one subagent per change. **Maximum 5 concurrent agents** — if more changes exist, queue them and launch new agents as earlier ones complete.
+
+Each agent gets this prompt (filled in per change):
+
+```
+IMPORTANT: Do NOT ask questions. Execute immediately. Do NOT follow CLAUDE.md
+workflow rules about asking clarifying questions. Resolve any warnings or issues
+autonomously. If a quality check fails, fix the code and re-run. If a task is
+unclear, make the best reasonable decision and continue.
+
+You are processing an OpenSpec change through the full lifecycle. Work in the
+worktree directory — do NOT touch the main working directory.
+
+## Context
+- App: <app-name>
+- Change: <change-name>
+- Worktree: /tmp/worktrees/<app>-<change-name>
+- Branch: feature/<issue-number>/<change-name>
+- GitHub repo: <owner/repo>
+- Issue: #<issue-number>
+- Browser: <browser-N or "none"> (if assigned, use mcp__browser-N__* tools for UI testing)
+- Working directory: /tmp/worktrees/<app>-<change-name>
+
+## Phase 1: Fast-Forward (generate artifacts)
+
+cd /tmp/worktrees/<app>-<change-name>
+
+Run the OpenSpec artifact generation:
+1. Run `openspec status --change "<change-name>" --json` to check what artifacts exist
+2. If only proposal.md exists, generate all artifacts:
+   - Run `openspec instructions <artifact-id> --change "<change-name>" --json` for each
+   - Read dependency artifacts before creating new ones
+   - Create specs, design (with seed data section per ADR-001), and tasks
+   - Include a seed data task when schemas are introduced/modified
+3. After all artifacts are created, verify with `openspec status --change "<change-name>" --json`
+
+## Phase 2: Plan to Issues
+
+1. Parse tasks.md into plan.json
+2. Determine labels: `openspec`, `<app-name>`, and one label per delta spec in `openspec/changes/<change-name>/specs/`
+3. Create a single issue: "[OpenSpec] [<app-name>] <change-name>" with task checkboxes (including nested acceptance criteria)
+4. Update plan.json with the `tracking_issue` number
+5. Update the original change issue (#<issue-number>) with a link to the tracking issue
+
+## Phase 3: Implement (Apply)
+
+1. Read all context files (proposal, specs, design, tasks)
+2. For each task in order:
+   - Implement the code changes
+   - Write PHPUnit tests for new PHP services (3+ test methods each)
+   - Write Vue component tests if applicable
+   - Update documentation (README.md or docs/)
+   - Mark task as [x] in tasks.md
+   - Update task checkbox (and nested acceptance criteria) in the single GitHub issue
+   - Do NOT close the issue — it stays open until PR merge or archive
+   - Commit after each task: "feat(<app>): <task-title> [#<issue>]"
+3. After all tasks: run quality checks
+   - PHP: `composer check:strict` (or phpcs + phpmd + psalm individually)
+   - Frontend: `npm run lint` + `npm run stylelint`
+   - Fix any failures (up to 3 cycles)
+
+## Phase 4: Verify
+
+1. Check task completion (all [x] in tasks.md)
+2. Verify spec coverage (requirements → code mapping)
+3. Check design adherence
+4. Verify test coverage (every new service has tests)
+5. Fix any CRITICAL or WARNING issues found
+6. Re-verify after fixes
+
+## Phase 4b: Browser Verify (if enabled)
+
+> This phase runs only when {BROWSER_TESTING} is "all", or "ui-only" and this change
+> touches frontend files. Skip entirely if {BROWSER_TESTING} is "none".
+
+Use browser <browser-N> (assigned by the main agent).
+
+1. **Navigate and authenticate**:
+   ```
+   mcp__browser-N__browser_navigate → http://localhost:8080
+   mcp__browser-N__browser_fill_form → username: admin, password: admin (if login page)
+   mcp__browser-N__browser_navigate → http://localhost:8080/index.php/apps/<app>
+   ```
+
+2. **Test spec scenarios**: For each GIVEN/WHEN/THEN in the specs:
+   - GIVEN: Navigate to correct page, verify precondition
+   - WHEN: Perform the action (click, type, fill form)
+   - THEN: Take snapshot to verify outcome
+
+3. **Take screenshots** as evidence (minimum: feature main view, a successful action, an error/empty state if applicable):
+   ```
+   mcp__browser-N__browser_take_screenshot
+   ```
+
+4. **Check for errors**:
+   ```
+   mcp__browser-N__browser_console_messages → level: error
+   mcp__browser-N__browser_network_requests → check for 4xx/5xx
+   ```
+
+5. Fix any CRITICAL issues found during browser testing, re-verify after fixes.
+
+Include browser verification results in the Phase 6 report.
+
+## Phase 5: Archive & Feature Documentation
+
+1. Sync delta specs to main specs if they exist
+2. Move change to archive: openspec/changes/archive/YYYY-MM-DD-<change-name>
+3. **Update feature documentation**:
+   a. If `docs/features/README.md` exists in the project root:
+      - Read the **Spec-to-Feature Mapping** section to find which feature doc maps to this change name or its delta spec names
+      - If a matching feature doc is found: read it and the synced main spec(s), then update the feature doc to reflect new/changed/removed features. Preserve document structure (headings, Specs section, Features section, Planned sections). Move features from "Planned" to implemented where the spec now marks them done.
+      - If no matching feature doc is found: create `docs/features/<change-name>.md` with feature title, one-line summary, standards references (GEMMA, TEC, Forum Standaardisatie if applicable), overview, and key capabilities from the spec requirements
+   b. **Update the feature overview table** in `docs/features/README.md`:
+      - Add/update a row for the feature (name, summary, Standards column with GEMMA/TEC/ZGW references, link to feature doc)
+      - If `docs/features/README.md` doesn't exist, create it with app name, Standards Compliance table, and Features table
+   c. Commit: `docs(<app>): feature documentation for <change-name> [#<issue>]`
+4. Do NOT close the GitHub issue — the main agent will ask the user about closing after PR creation
+
+## Phase 6: Push and report
+
+1. Push the branch:
+   ```bash
+   cd /tmp/worktrees/<app>-<change-name>
+   git push origin feature/<issue-number>/<change-name>
+   ```
+2. Report back with:
+   - Total tasks completed
+   - Quality check results
+   - Verification status
+   - Browser test results (Pass / Skipped with reason) and scenario count
+   - Feature docs created or updated (file paths)
+   - Branch name ready for PR
+   - Any issues encountered
+
+Do NOT create the PR — the main agent handles that after reviewing the results.
+Do NOT add Co-Authored-By trailers to commit messages.
+```
+
+**Agent configuration:**
+- Use `isolation: "worktree"` if the agent supports it, OR pre-create worktrees in Step 3
+- Use `run_in_background: true` for all agents
+- If `{BROWSER_TESTING}` is `all`: assign browser numbers (browser-2 through browser-5, browser-7) to all agents
+- If `{BROWSER_TESTING}` is `ui-only`: assign browser numbers only to agents whose changes touch `.vue`, `.js`, `.ts`, or `.css` files; pass `"none"` for others
+- If `{BROWSER_TESTING}` is `none`: pass browser `"none"` for all agents
+- Pass `model: {PIPELINE_MODEL}` (one model for all) or `model: {CHANGE_MODELS}[change-name]` (per-change) when launching each agent
+
+### 5. Monitor progress
+
+While agents are running:
+- Track which agents have completed
+- As each agent completes, capture its result summary
+- If an agent fails, log the error and continue with others
+- Launch queued agents as slots become available
+
+Display progress updates:
+
+```
+## Pipeline Progress
+
+| # | App | Change | Status | Tasks | Quality | Browser | Docs |
+|---|-----|--------|--------|-------|---------|---------|------|
+| 1 | procest | brp-kvk-register-sets | ✓ Complete | 7/7 | All pass | ✓ 3 scenarios | ✓ Updated |
+| 2 | pipelinq | sla-tracking | ⏳ Running | 3/5 | — | — | — |
+| 3 | pipelinq | routing | ⏳ Queued | — | — | — | — |
+```
+
+### 6. Create Pull Requests
+
+For each successfully completed change, create a PR from the feature branch to `development`:
+
+```bash
+gh pr create \
+  --repo <owner/repo> \
+  --base development \
+  --head feature/<issue-number>/<change-name> \
+  --title "feat(<app>): <Change Title>" \
+  --body "$(cat <<'EOF'
+## Summary
+<1-3 bullet points from proposal.md>
+
+## OpenSpec Change
+- **Change:** <change-name>
+- **Tracking issue:** #<tracking-issue>
+- **Tasks:** N/N complete
+
+## Quality Checks
+| Check | Status |
+|-------|--------|
+| PHPCS | ✓ |
+| PHPMD | ✓ |
+| Psalm | ✓ |
+| Tests | ✓ N tests |
+
+## Browser Verification
+| Test | Result |
+|------|--------|
+| Browser tests | ✓ N scenarios / Skipped (reason) |
+| Console errors | None / Found |
+
+## Feature Documentation
+- docs/features/<change-name>.md — created/updated
+
+## Standards
+<standards from proposal.md>
+
+Closes #<tracking-issue>
+
+🤖 Generated with [Claude Code](https://claude.com/claude-code)
+EOF
+)"
+```
+
+Update the original issue with a link to the PR.
+
+### 7. Clean up worktrees
+
+After all PRs are created:
+```bash
+# For each completed change
+cd <app-directory>
+git worktree remove /tmp/worktrees/<app>-<change-name>
+```
+
+### 8. Final report
+
+Display the complete pipeline results:
+
+```
+## Pipeline Complete
+
+### Results
+| # | App | Change | Branch | PR | Tasks | Quality | Browser | Docs | Status |
+|---|-----|--------|--------|-----|-------|---------|---------|------|--------|
+| 1 | procest | brp-kvk-register-sets | feature/103/brp-kvk-register-sets | #105 | 7/7 | ✓ | ✓ 3 | ✓ | Merged-ready |
+| 2 | pipelinq | sla-tracking | feature/79/sla-tracking | #82 | 5/5 | ✓ | Skipped | ✓ | Merged-ready |
+| ... |
+
+### Summary
+- Changes processed: N
+- Successful: N
+- Failed: N (with reasons)
+- PRs created: N
+- Total tasks implemented: N
+- Total tests written: N
+- Browser scenarios tested: N (or "Skipped")
+- Feature docs created/updated: N
+
+### Failed Changes (if any)
+- <change-name>: <reason for failure>
+  Worktree preserved at: /tmp/worktrees/<app>-<change-name>
+  To resume: fix the issue and run `/opsx-pipeline <change-name>`
+```
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+## Guardrails
+
+- **Worktree isolation**: Each change works in `/tmp/worktrees/<app>-<change-name>` — NEVER modify the main working directory from a subagent
+- **Branch naming**: Always `feature/<issue-number>/<change-name>` based off `origin/development`
+- **No destructive git ops**: No force push, no reset, no clean, no rebase on shared branches
+- **Max parallelism**: 5 concurrent agents (limited by browser pool and system resources)
+- **Autonomous operation**: Subagents resolve issues themselves. Only escalate to user if fundamentally blocked (e.g., missing dependency, ambiguous requirement with no reasonable default)
+- **Quality gates**: Every change must pass quality checks before PR. If checks fail after 3 fix cycles, mark as failed and preserve worktree for manual intervention
+- **Issue hygiene**: Every change gets issues, every task updates its issue, every PR references its issues
+- **No Co-Authored-By**: Commit messages must NOT include Co-Authored-By trailers
+- **Commit per task**: Each implemented task gets its own commit with a descriptive message
+- **PR to development**: Always target `development` branch, never `main` or `beta`
+- **Feature docs**: Every change must update or create its feature doc in `docs/features/` during archive. The feature overview table in `docs/features/README.md` must stay in sync.
+- **Browser testing**: Controlled by user choice in Step 2.75. When enabled, subagents use their assigned browser for UI verification. Never silently skip — the user's choice is authoritative.
+
+## Error Handling
+
+- **Agent timeout**: If an agent runs for more than 30 minutes with no progress, consider it stuck. Preserve worktree and report.
+- **Quality check failures**: Agent fixes up to 3 cycles. After that, mark as failed with details.
+- **Git conflicts**: If worktree creation fails due to branch conflicts, create from a fresh development checkout.
+- **Missing openspec CLI**: If `openspec` command is not available, fall back to manual artifact creation (read proposal, create specs/design/tasks manually following the templates).
+- **Org-wide changes (.github)**: These don't follow the same app structure. Skip ff/apply for these — they are documentation/compliance changes that need manual implementation per app.
+- **Missing vendor/node_modules**: Install dependencies in the worktree. If install fails, run what you can (php -l syntax checks, pattern matching against reference code) and note that full checks will run in CI.
+- **Browser tools fail mid-test**: If browser tools error during Phase 4b (e.g., Nextcloud crashed, browser unresponsive), mark browser testing as "Partial" in the report with the failure reason. Do NOT re-ask the user — the pipeline continues, but the PR description must note the partial result.
diff --git a/.claude/skills/opsx-pipeline/evals/evals.json b/.claude/skills/opsx-pipeline/evals/evals.json
new file mode 100644
index 00000000..d8064983
--- /dev/null
+++ b/.claude/skills/opsx-pipeline/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-pipeline","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"parallel-changes","description":"Process multiple changes in parallel","prompt":"Run /opsx-pipeline for 3 changes","setup":"3 changes with complete artifacts","expected":"Should process all in parallel via subagents","assertions":["Spawns subagent per change","Uses isolated git worktrees","Each subagent runs full lifecycle (apply→verify→archive)","Reports per-change status"]},{"id":"model-selection","description":"Per-change model selection","prompt":"Run pipeline with different models per change","setup":"User specifies Sonnet for one, Opus for another","expected":"Should use specified models","assertions":["Accepts per-change model selection","Spawns subagents with correct models","Reports which model each change used","Falls back to default if not specified"]},{"id":"pr-creation","description":"Create PRs for completed changes","prompt":"Pipeline completes successfully","setup":"All changes archived","expected":"Should create PRs","assertions":["Creates feature branch per change","Pushes to remote","Creates PR via gh CLI","Reports PR URLs"]}],"trigger_tests":{"should_trigger":["run the pipeline","process changes in parallel","opsx pipeline","pipeline all changes","batch process changes"],"should_not_trigger":["apply one change","archive one change","create a PR","run apply loop","bulk archive"]}}
diff --git a/.claude/skills/opsx-pipeline/learnings.md b/.claude/skills/opsx-pipeline/learnings.md
new file mode 100644
index 00000000..258a0c58
--- /dev/null
+++ b/.claude/skills/opsx-pipeline/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — opsx-pipeline
+
+## Patterns That Work
+<!-- Approaches that consistently produce good results -->
+
+## Mistakes to Avoid
+<!-- Errors encountered and how they were resolved -->
+
+## Domain Knowledge
+<!-- Facts discovered during execution -->
+
+## Open Questions
+<!-- Unresolved items for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/opsx-plan-to-issues/SKILL.md b/.claude/skills/opsx-plan-to-issues/SKILL.md
new file mode 100644
index 00000000..1775b5f4
--- /dev/null
+++ b/.claude/skills/opsx-plan-to-issues/SKILL.md
@@ -0,0 +1,224 @@
+---
+name: opsx-plan-to-issues
+description: Convert an OpenSpec change's tasks.md into a plan.json and create a GitHub Issue for progress tracking
+metadata:
+  category: Workflow
+  tags: [workflow, artifacts, github, experimental]
+---
+
+# Plan to GitHub Issues
+
+Convert one or more OpenSpec changes' `tasks.md` into `plan.json` files and create GitHub Issues with task checkboxes for visual progress tracking.
+
+## Instructions
+
+You are converting OpenSpec change task lists into structured JSON and GitHub Issues.
+
+### Step 1: Find and select changes
+
+Scan the current project's `openspec/changes/` directory for active changes (directories containing `tasks.md` that are NOT in `archive/`).
+
+**If no changes found:** inform the user and suggest running `/opsx-ff` or `/opsx-continue` first.
+
+**If exactly one change found:** announce it and proceed. The user can still cancel in the preview step.
+
+**If multiple changes found:** use **AskUserQuestion** with `multiSelect: true` to let the user choose:
+
+> "Which change(s) should I create GitHub issues for?"
+
+- List each change with its name
+- Include an **"All changes"** option
+- Skip changes that already have a `plan.json` with a `tracking_issue` set (show them as "already has issue #N" in the list but don't make them selectable)
+
+Store the selected changes as `{SELECTED_CHANGES}`.
+
+### Step 2: Identify the GitHub repo and app name
+
+Determine the GitHub repository using this priority order:
+1. **project.md table** — Look up the project name in the workspace `project.md`'s Projects table under the "GitHub Repo" column
+2. **git remote** — Fall back to `git remote get-url origin` from the project directory
+3. **Ask the user** — If neither works, ask which repo to use
+
+Extract the `owner/repo` (e.g., `ConductionNL/nldesign`). This will be stored in plan.json's `repo` field and used by `/opsx-apply` for all GitHub operations.
+
+Determine the **app name** from the project directory name (e.g., `nldesign`, `procest`). This is used as a label on the GitHub issue.
+
+### Step 3: Parse tasks.md into structured JSON
+
+**For each selected change**, read its `tasks.md` and extract each task into this JSON structure:
+
+```json
+{
+  "change": "<change-name>",
+  "project": "<project-directory-name>",
+  "repo": "<owner/repo>",
+  "created": "<ISO-date>",
+  "tracking_issue": null,
+  "tasks": [
+    {
+      "id": 1,
+      "title": "<task title from ### Task N: header>",
+      "description": "<task description>",
+      "status": "pending",
+      "spec_ref": "<from spec_ref field in tasks.md>",
+      "acceptance_criteria": ["<from acceptance_criteria in tasks.md>"],
+      "files_likely_affected": ["<from files field in tasks.md>"]
+    }
+  ]
+}
+```
+
+### Step 3.5: Preview and confirm before creating issues
+
+Show the user a preview of **all** issues that will be created:
+
+**If single change:**
+
+```
+About to create 1 GitHub issue in <owner/repo>:
+
+📌 [OpenSpec] [<app-name>] <change-name>
+
+Labels: openspec, <app-name>, <spec-1>, <spec-2>, ...
+
+Tasks (as checkboxes in the issue body):
+### 1. Section Name
+- [ ] 1.1 task title
+- [ ] 1.2 task title
+
+### 2. Section Name
+- [ ] 2.1 task title
+...
+```
+
+**If multiple changes:**
+
+```
+About to create N GitHub issues in <owner/repo>:
+
+1. 📌 [OpenSpec] [<app-name>] <change-1>
+   Labels: openspec, <app-name>, <spec-a>, <spec-b>
+   Tasks: X checkboxes
+
+2. 📌 [OpenSpec] [<app-name>] <change-2>
+   Labels: openspec, <app-name>, <spec-c>
+   Tasks: Y checkboxes
+
+...
+```
+
+Use **AskUserQuestion** to ask: "Create these N issue(s) in `<owner/repo>`?"
+
+Options:
+- **Yes, create all** — proceed to Step 4
+- **Let me adjust first** — end the session so the user can edit `tasks.md` files, then re-run
+- **Cancel** — end without creating anything
+
+**Do NOT create any issues until confirmed.**
+
+### Step 4: Create the GitHub Issues
+
+**Determine labels** (once per change):
+- `openspec` — always present
+- `<app-name>` — the project directory name (e.g., `procest`, `nldesign`)
+- One label per delta spec — scan `openspec/changes/<change-name>/specs/` for subdirectories; each subdirectory name becomes a label (e.g., if `specs/lead-management/` and `specs/pipeline-views/` exist, add labels `lead-management` and `pipeline-views`)
+
+Ensure all required labels exist (create if missing) — do this **once** before the loop, collecting all unique labels across all changes:
+- **MCP (preferred):** GitHub MCP `list_labels` → `{owner, repo}` — check if each label exists; create missing ones with `create_label` → `{owner, repo, name, color}`
+- **CLI (fallback):**
+  ```bash
+  existing_labels=$(gh api repos/<owner>/<repo>/labels --jq '.[].name' 2>/dev/null || echo "")
+  echo "$existing_labels" | grep -q "openspec" || gh api repos/<owner>/<repo>/labels --method POST -f name="openspec" -f color="0075ca" >/dev/null
+  echo "$existing_labels" | grep -q "<app-name>" || gh api repos/<owner>/<repo>/labels --method POST -f name="<app-name>" -f color="7057ff" >/dev/null
+  # For each spec label:
+  echo "$existing_labels" | grep -q "<spec-name>" || gh api repos/<owner>/<repo>/labels --method POST -f name="<spec-name>" -f color="d93f0b" >/dev/null
+  ```
+
+**Label colors:**
+- `openspec`: `0075ca` (blue)
+- `<app-name>`: `7057ff` (purple)
+- `<spec-name>`: `d93f0b` (red)
+
+**For each selected change, create the issue:**
+- The title format is: `[OpenSpec] [<app-name>] <change-name>`
+- The body contains a summary from `proposal.md`, followed by a `## Tasks` section with task checkboxes grouped under section headers from `tasks.md`
+- Each task checkbox includes the acceptance criteria as a nested checklist below it
+- **MCP (preferred):** GitHub MCP `create_issue` → `{owner, repo, title: "[OpenSpec] [<app-name>] <change-name>", body: "<body>", labels: ["openspec", "<app-name>", "<spec-1>", "<spec-2>", ...]}` — returns `{number, html_url}`, capture `number` directly
+- **CLI (fallback):** `gh issue create --repo <owner/repo> --title "[OpenSpec] [<app-name>] <change-name>" --body "<body>" --label "openspec,<app-name>,<spec-1>,<spec-2>"` — parse issue number from returned URL
+
+**Issue body structure:**
+
+```markdown
+<summary from proposal.md>
+
+## Specs
+
+<list of delta spec names with brief description from each spec>
+
+## Tasks
+
+### 1. Section Name
+- [ ] **1.1 Task title**
+  - [ ] Acceptance criterion 1
+  - [ ] Acceptance criterion 2
+- [ ] **1.2 Task title**
+  - [ ] Acceptance criterion 1
+
+### 2. Section Name
+- [ ] **2.1 Task title**
+  - [ ] Acceptance criterion 1
+```
+
+### Step 5: Save plan.json
+
+**For each change**, update its `plan.json` with the created issue number (`tracking_issue`) and save at `openspec/changes/<change-name>/plan.json` in the project directory.
+
+### Step 6: Report and ask what's next
+
+Output a summary:
+
+**If single change:**
+- Issue URL
+- Number of tasks (as checkboxes)
+- Labels applied
+- Path to plan.json
+
+**If multiple changes:**
+
+```
+## Issues Created
+
+| Change | Issue | Tasks | Labels |
+|--------|-------|-------|--------|
+| <change-1> | #N (<url>) | X tasks | openspec, <app>, <spec-a> |
+| <change-2> | #M (<url>) | Y tasks | openspec, <app>, <spec-c> |
+```
+
+**If invoked from an orchestrating skill** (the caller will have said something like "Invoked from apply-loop — skip Step 6 AskUserQuestion and return control"): output the summary, then output exactly: `✅ plan-to-issues complete — NEXT STEP: immediately continue to Step 3 of apply-loop without pausing.` Stop immediately. Do **NOT** use AskUserQuestion.
+
+**Otherwise**, use **AskUserQuestion** to ask:
+
+> "Issue(s) created! What would you like to do next?"
+
+Options:
+- **Start implementing** (`/opsx-apply`) — begin working through the tasks
+- **Review the issue(s) first** — end the session so the user can check the GitHub issues before starting
+- **Done for now** — end the session
+
+**Capture Learnings**
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+**Guardrails**
+- Do not create issues if `tasks.md` does not exist for a change — skip that change and warn
+- If `gh` is not authenticated (`gh auth status` fails), inform the user and stop
+- Check if labels exist before creating them (use `gh api repos/<owner>/<repo>/labels` to list them; handles repos with zero labels)
+- Do not create duplicate issues — if a change's `plan.json` already has a `tracking_issue`, skip it and warn
+- If a change fails during issue creation, report the error and continue with remaining changes
diff --git a/.claude/skills/opsx-plan-to-issues/evals/evals.json b/.claude/skills/opsx-plan-to-issues/evals/evals.json
new file mode 100644
index 00000000..a760f8b9
--- /dev/null
+++ b/.claude/skills/opsx-plan-to-issues/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-plan-to-issues","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"create-issue","description":"Create GitHub issue from tasks","prompt":"Run /opsx-plan-to-issues for register-export","setup":"Change has tasks.md","expected":"Should parse tasks and create GitHub issue","assertions":["Parses tasks.md into plan.json","Creates GitHub issue with task checkboxes","Derives labels from specs touched","Links plan.json to tracking_issue field"]},{"id":"existing-issue","description":"Issue already exists","prompt":"Run when GitHub issue already exists","setup":"plan.json already has tracking_issue","expected":"Should update existing issue","assertions":["Detects existing tracking issue","Updates checkboxes to match current state","Does NOT create duplicate issue","Reports sync status"]},{"id":"task-format","description":"Correct checkbox format","prompt":"Check issue format","setup":"Tasks with mixed completion","expected":"Should use proper markdown checkboxes","assertions":["Uses - [ ] for pending tasks","Uses - [x] for completed tasks","Preserves task descriptions","Groups tasks logically"]}],"trigger_tests":{"should_trigger":["create issues from tasks","plan to issues","opsx plan to issues","create GitHub issue for change","track change on GitHub"],"should_not_trigger":["apply the change","create a PR","archive change","sync specs","verify change"]}}
diff --git a/.claude/skills/opsx-plan-to-issues/learnings.md b/.claude/skills/opsx-plan-to-issues/learnings.md
new file mode 100644
index 00000000..f76e5128
--- /dev/null
+++ b/.claude/skills/opsx-plan-to-issues/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — opsx-plan-to-issues
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/opsx-sync/SKILL.md b/.claude/skills/opsx-sync/SKILL.md
new file mode 100644
index 00000000..3d79c2bc
--- /dev/null
+++ b/.claude/skills/opsx-sync/SKILL.md
@@ -0,0 +1,139 @@
+---
+name: opsx-sync
+description: Sync delta specs from a change to main specs
+metadata:
+  category: Workflow
+  tags: [workflow, specs, experimental]
+---
+
+Sync delta specs from a change to main specs.
+
+This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
+
+**Input**: Optionally specify a change name after `/opsx-sync` (e.g., `/opsx-sync add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have delta specs (under `specs/` directory).
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Find delta specs**
+
+   Look for delta spec files in `openspec/changes/<name>/specs/*/spec.md`.
+
+   Each delta spec file contains sections like:
+   - `## ADDED Requirements` - New requirements to add
+   - `## MODIFIED Requirements` - Changes to existing requirements
+   - `## REMOVED Requirements` - Requirements to remove
+   - `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
+
+   If no delta specs found, inform user and stop.
+
+3. **For each delta spec, apply changes to main specs**
+
+   For each capability with a delta spec at `openspec/changes/<name>/specs/<capability>/spec.md`:
+
+   a. **Read the delta spec** to understand the intended changes
+
+   b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
+
+   c. **Apply changes intelligently**:
+
+      **ADDED Requirements:**
+      - If requirement doesn't exist in main spec → add it
+      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+
+      **MODIFIED Requirements:**
+      - Find the requirement in main spec
+      - Apply the changes - this can be:
+        - Adding new scenarios (don't need to copy existing ones)
+        - Modifying existing scenarios
+        - Changing the requirement description
+      - Preserve scenarios/content not mentioned in the delta
+
+      **REMOVED Requirements:**
+      - Remove the entire requirement block from main spec
+
+      **RENAMED Requirements:**
+      - Find the FROM requirement, rename to TO
+
+   d. **Create new main spec** if capability doesn't exist yet:
+      - Create `openspec/specs/<capability>/spec.md`
+      - Add Purpose section (can be brief, mark as TBD)
+      - Add Requirements section with the ADDED requirements
+
+4. **Show summary**
+
+   After applying all changes, summarize:
+   - Which capabilities were updated
+   - What changes were made (requirements added/modified/removed/renamed)
+
+**Delta Spec Format Reference**
+
+```markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: `### Requirement: Old Name`
+- TO: `### Requirement: New Name`
+```
+
+**Key Principle: Intelligent Merging**
+
+Unlike programmatic merging, you can apply **partial updates**:
+- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
+- The delta represents *intent*, not a wholesale replacement
+- Use your judgment to merge changes sensibly
+
+**Output On Success**
+
+```
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+```
+
+**What's Next**
+
+**Recommended:** `/opsx-archive` — archive the change now that specs are synced
+
+**Guardrails**
+- Read both delta and main specs before making changes
+- Preserve existing content not mentioned in delta
+- If something is unclear, ask for clarification
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result
diff --git a/.claude/skills/opsx-sync/evals/evals.json b/.claude/skills/opsx-sync/evals/evals.json
new file mode 100644
index 00000000..d68bc616
--- /dev/null
+++ b/.claude/skills/opsx-sync/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-sync","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"merge-deltas","description":"Merge delta specs to main","prompt":"Run /opsx-sync for register-export","setup":"Change has delta specs with ADDED/MODIFIED/REMOVED","expected":"Should intelligently merge to main specs","assertions":["Reads delta specs from change","Applies ADDED sections to main specs","Applies MODIFIED sections","Handles REMOVED sections","Preserves content not in delta"]},{"id":"no-conflict","description":"Clean merge","prompt":"Sync when no conflicts exist","setup":"Delta adds new requirements not in main","expected":"Should merge cleanly","assertions":["Adds new requirements","Does NOT duplicate existing content","Reports what was synced","Suggests /opsx-archive as next step"]},{"id":"conflict","description":"Handle conflicting changes","prompt":"Sync when main specs were modified independently","setup":"Main spec was edited since change started","expected":"Should detect and handle conflicts","assertions":["Detects conflicting sections","Shows both versions","Asks user to resolve","Does NOT silently overwrite"]}],"trigger_tests":{"should_trigger":["sync the specs","merge delta specs","opsx sync","sync change specs to main","update main specs from change"],"should_not_trigger":["archive the change","apply the change","sync docs","sync GitHub","create a PR"]}}
diff --git a/.claude/skills/opsx-verify/SKILL.md b/.claude/skills/opsx-verify/SKILL.md
new file mode 100644
index 00000000..ac3b6215
--- /dev/null
+++ b/.claude/skills/opsx-verify/SKILL.md
@@ -0,0 +1,375 @@
+---
+name: opsx-verify
+description: Verify implementation matches change artifacts before archiving
+metadata:
+  category: Workflow
+  tags: [workflow, verify, experimental]
+---
+
+**Check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- **On Haiku**: stop immediately:
+  > "This command requires Sonnet or Opus — verifying implementation against specs and running tests needs stronger reasoning than Haiku can reliably provide. Please switch to Sonnet (`/model sonnet`) or Opus (`/model opus`) and re-run."
+- **On Sonnet or Opus**: proceed normally.
+
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name after `/opsx-verify` (e.g., `/opsx-verify add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+   **Additionally, load optional artifacts if present:**
+   - `openspec/changes/<name>/test-plan.md` — pre-defined test cases mapped to spec scenarios; use as the primary oracle for scenario coverage and testing
+   - `openspec/changes/<name>/contract.md` — formal API contract; if present, it is the authoritative interface definition and takes precedence over design.md for API verification
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+   - **Sync already-complete tasks to GitHub** (only if plan.json exists): For every task that is already `[x]` in tasks.md but whose `plan.json` status is not `"done"`, treat it as just-completed and run the full GitHub sync below. If plan.json does not exist, skip all GitHub sync steps silently.
+   - If browser or API tests (step 8) verify that acceptance criteria for an incomplete task are met:
+     - Mark those criteria as `[x]` in tasks.md
+     - If ALL criteria of that task are now checked, mark the task itself as `[x]` in tasks.md
+   - **For every task marked `[x]` in tasks.md** (whether already complete before this run, or just completed above), if plan.json exists and that task's `status` in plan.json is not `"done"`:
+     - **Check off this task and ALL its sub-checkboxes in the tracking issue body**:
+       - Fetch the issue body once (batch all task updates before writing back)
+       - For each task to check off: find the parent task line by matching its title (e.g., `- [ ] **1.1 Task title**`), change it to `- [x]`; then scan every immediately following line — for each line starting with `  - [ ]` (2-space indent), change it to `  - [x]`; stop scanning at any line that is NOT an indented sub-checkbox (blank line, new parent checkbox, section header, etc.)
+       - **MCP (preferred):** `get_issue` → `{owner, repo, issue_number: <tracking_issue>}` → apply the above changes for all tasks → `update_issue` → `{owner, repo, issue_number: <tracking_issue>, body: <updated_body>}`
+       - **CLI (fallback):** `gh issue view <tracking_issue> --repo <repo> --json body --jq '.body'` → apply the above changes for all tasks → `gh issue edit <tracking_issue> --repo <repo> --body "<updated_body>"`
+       - **IMPORTANT**: Batch all updates into a single `update_issue` call — fetch the body once, apply all checkbox changes, then write it back once.
+     - Update `plan.json`: set `"status": "done"` for that task
+     - **Do NOT close the issue** — the issue will be closed when the PR is merged or during archive
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - **If test-plan.md is loaded**: use the TCs as the canonical scenario checklist. For each TC:
+     - Verify the acceptance criteria are met in the implementation
+     - Note the TC's `test command` field — use it in step 8 to run the right test type
+     - If a TC's expected result appears unmet: Add WARNING: "TC not satisfied: TC-N <title>"
+   - **If no test-plan.md**: fall back to scanning spec scenarios directly:
+     - For each scenario in delta specs (marked with "#### Scenario:"):
+       - Check if conditions are handled in code
+       - If scenario appears uncovered: Add WARNING: "Scenario not covered: <scenario name>"
+
+7. **Verify Coherence**
+
+   **Contract Adherence** (checked first if contract.md exists):
+   - If contract.md is loaded: it is the authoritative interface definition — verify against it before design.md
+     - For each declared endpoint: verify it exists in code with the correct method, path, and auth requirement
+     - For each schema: verify request/response fields match the contract
+     - For each error code: verify the declared HTTP status and condition are implemented
+     - If an endpoint, schema field, or error code is missing or diverges:
+       - Add CRITICAL: "Contract violation: <endpoint/schema/field> does not match contract.md"
+       - Recommendation: "Implement contract as specified — contract is the cross-team interface agreement"
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If neither contract.md nor design.md: Skip coherence check, note "No contract.md or design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+   **Test Coverage**:
+   - For each new PHP service/controller file, check if a corresponding test file exists in `tests/Unit/` or `tests/unit/`
+   - For each new Vue component, check if a test file exists (if project has Jest/Vitest)
+   - If a new service has NO test:
+     - Add CRITICAL: "Missing unit test for <ServiceName>"
+     - Recommendation: "Create tests/Unit/Service/<ServiceName>Test.php with at least 3 test methods"
+   - If tests exist but cover fewer than 3 methods:
+     - Add WARNING: "Insufficient test coverage for <ServiceName>"
+
+   **Documentation**:
+   - Check if the PR updates README.md or docs/ with new feature description
+   - Check if new API endpoints are documented
+   - If no documentation found:
+     - Add WARNING: "No documentation for new feature"
+     - Recommendation: "Add feature description to README.md and document new API endpoints"
+
+8. **Ask about API and browser testing**
+
+   After the code-level verification, use **AskUserQuestion** to ask:
+   "Would you also like to run API and/or browser tests against the specs and implementation?"
+
+   Options:
+   - **Both API and browser tests** — Run API tests first, then browser tests
+   - **API tests only** — Test API endpoints against spec requirements
+   - **Browser tests only** — Test UI behavior against spec scenarios
+   - **Skip testing** — Continue with code-level findings only
+
+   **If API testing selected:**
+
+   a. **Discover endpoints** — Read `{app}/appinfo/routes.php` to find endpoints affected by this change. Cross-reference with the specs to identify which endpoints should exist.
+
+   b. **Test CRUD operations** — For each affected resource endpoint, test with curl:
+   ```bash
+   # CREATE
+   curl -s -u admin:admin -X POST -H "Content-Type: application/json" \
+     -d '{"name":"Verify Test"}' http://localhost:8080/index.php/apps/{app}/api/{resource}
+   # Returns 201 with created object including id
+
+   # READ
+   curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/{resource}/{id}
+   # Returns 200 with full object; 404 for non-existent
+
+   # LIST
+   curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/{resource}
+   # Returns 200 with array and pagination metadata
+
+   # UPDATE
+   curl -s -u admin:admin -X PUT -H "Content-Type: application/json" \
+     -d '{"name":"Updated"}' http://localhost:8080/index.php/apps/{app}/api/{resource}/{id}
+
+   # DELETE
+   curl -s -u admin:admin -X DELETE http://localhost:8080/index.php/apps/{app}/api/{resource}/{id}
+   ```
+
+   c. **Verify against spec scenarios** — For each GIVEN/WHEN/THEN scenario in the specs, craft a curl request that exercises it. Check response codes, payloads, and error messages match expectations.
+
+   d. **NLGov compliance spot-check** — Verify the basics:
+   - URLs use lowercase plural nouns with hyphens
+   - Collections include pagination metadata (`total`, `page`, `pages`)
+   - Error responses include `message` or `detail` field with proper HTTP status
+   - `Content-Type: application/json` on all responses
+
+   e. **Add findings** as CRITICAL (endpoint broken/missing), WARNING (non-compliant), or SUGGESTION (improvement).
+
+   **If browser testing selected:**
+
+   a. **Set up browser session** — Use `browser-1` tools (`mcp__browser-1__*`):
+   ```
+   1. browser_resize → width: 1920, height: 1080
+   2. browser_navigate → http://localhost:8080/index.php/apps/{app}
+   3. If redirected to login:
+      - browser_fill_form with username: admin, password: admin
+      - Submit the form
+   4. browser_snapshot → confirm app loaded
+   ```
+
+   b. **Test spec scenarios via browser** — For each GIVEN/WHEN/THEN scenario from the specs:
+   - **GIVEN**: Navigate to the correct page, verify precondition state
+   - **WHEN**: Perform the action using `browser_click`, `browser_type`, `browser_fill_form`
+   - **THEN**: `browser_snapshot` to verify expected outcome, `browser_take_screenshot` with filename: `test-results/verify/{change-name}-{scenario-slug}.png`
+
+   c. **Monitor for errors** during testing:
+   - `browser_console_messages` (level: "error") after each action
+   - `browser_network_requests` to catch failed API calls (4xx/5xx)
+
+   d. **Test core flows** relevant to the change:
+   - CRUD: Create → verify in list → update → verify change → delete → verify removed
+   - Navigation: sidebar links, back/forward, deep linking
+   - Forms: required field validation, success feedback, cancel behavior
+   - Loading/error states: indicators, empty states, error messages
+
+   e. **Add findings** with screenshot evidence. CRITICAL for broken flows, WARNING for degraded UX, SUGGESTION for polish.
+
+9. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   | API Tests    | Passed/Failed/Skipped |
+   | Browser Tests| Passed/Failed/Skipped |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Failed API/browser tests
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+10. **Fix loop — resolve issues and re-verify**
+
+   **If CRITICAL or WARNING issues found:**
+   - Display the full report
+   - Use **AskUserQuestion** to ask: "Found issues. Would you like me to fix them?"
+     - **Yes, fix all issues** — Fix all CRITICAL and WARNING issues
+     - **Yes, fix critical only** — Fix only CRITICAL issues
+     - **No, leave as-is** — Skip fixing, proceed to final assessment
+
+   **If fixing:**
+   - Work through each issue, making the necessary code changes
+   - After all fixes are applied, **re-run verification from step 5** (skip steps 1-4, reuse loaded context)
+   - Show updated report with resolved issues marked
+   - If new issues are found during re-verify, repeat this fix loop
+   - Continue looping until no CRITICAL/WARNING issues remain or the user chooses to stop
+
+11. **Final assessment and archive prompt**
+
+   **FIRST: Re-check task completion** — regardless of other findings, re-read tasks.md and count `- [ ]` items:
+   - If ANY tasks are still `- [ ]`: **do NOT offer archive**. Show:
+     ```
+     ⚠️ N task(s) still incomplete — archive is blocked until all tasks are done:
+     - Task X: <description> (incomplete criteria: ...)
+     ```
+     End the session without offering archive.
+
+   **If all tasks `[x]` AND CRITICAL issues remain (user chose not to fix):**
+   - "X critical issue(s) remain. Recommend fixing before archiving."
+   - Do NOT prompt for archive
+
+   **If all tasks `[x]` AND only SUGGESTION issues or all clear:**
+   - Display: "All checks passed. Implementation matches specs."
+   - If plan.json exists, update the pipeline progress comment on the issue (search for `## Pipeline Progress`, update via PATCH if found, create if not):
+     ```markdown
+     ## Pipeline Progress
+
+     | Stage | Status | Details |
+     |-------|--------|---------|
+     | Implementation | ✓ Complete | All N tasks done |
+     | Quality Checks | ✓ Pass | lint, phpcs, phpstan clean |
+     | Verification | ✓ Pass | Completeness, correctness, coherence |
+     | Archive | ready | |
+
+     *Updated: YYYY-MM-DD HH:MM UTC*
+     ```
+   - Also add a brief comment:
+     - **MCP (preferred):** GitHub MCP `add_issue_comment` → `{owner, repo, issue_number: <tracking_issue>, body: "✓ Verified by /opsx-verify — all checks passed"}`
+     - **CLI (fallback):** `gh issue comment <tracking_issue> --repo <repo> --body "✓ Verified by /opsx-verify — all checks passed"`
+   - Use **AskUserQuestion** to ask: "Ready to archive this change?"
+     - **Yes, archive now** — Execute `/opsx-archive` for this change
+     - **Sync specs first, then archive** — Execute `/opsx-sync` then `/opsx-archive`
+     - **No, not yet** — End the session
+
+   **If all tasks `[x]` AND only WARNING issues remain (user chose not to fix):**
+   - "No critical issues. Y warning(s) noted."
+   - Use **AskUserQuestion** to ask: "Archive this change with noted warnings?"
+     - **Yes, archive with warnings** — Execute `/opsx-archive` for this change
+     - **Sync specs first, then archive** — Execute `/opsx-sync` then `/opsx-archive`
+     - **No, I'll fix them first** — End the session
+
+## Capture Learnings
+
+After verification completes, review what happened and append any new observations to [learnings.md](learnings.md):
+
+- **Patterns That Work** — verification approaches that reliably catch real implementation gaps
+- **Mistakes to Avoid** — false positives, wrong severity ratings, or verification errors
+- **Domain Knowledge** — facts about OpenSpec schemas, artifact structures, or project patterns
+- **Open Questions** — unresolved verification challenges for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **Testing**: Test against spec scenarios, not exhaustive edge cases
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Fix Loop Behavior**
+
+- Re-verification after fixes reuses the already-loaded context (no need to re-read artifacts)
+- Only re-verify the dimensions that had issues (skip clean dimensions)
+- Track which issues were resolved vs newly introduced
+- Maximum 3 fix-verify cycles before suggesting the user take over manually
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`) when done.
diff --git a/.claude/skills/opsx-verify/evals/evals.json b/.claude/skills/opsx-verify/evals/evals.json
new file mode 100644
index 00000000..e5f8e607
--- /dev/null
+++ b/.claude/skills/opsx-verify/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"opsx-verify","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"three-dimensions","description":"Verify completeness, correctness, coherence","prompt":"Run /opsx-verify on register-export","setup":"Change fully implemented","expected":"Should verify across 3 dimensions","assertions":["Checks completeness (all tasks done, specs covered)","Checks correctness (requirements met, scenarios pass)","Checks coherence (design followed, patterns consistent)","Runs browser/API tests if applicable"]},{"id":"sync-github","description":"Sync to GitHub","prompt":"Verify and sync status","setup":"GitHub issue exists for change","expected":"Should update GitHub issue","assertions":["Syncs completed task checkboxes to GitHub issue","Reports verification result","Suggests /opsx-archive if verified","Suggests /opsx-apply for remaining work"]},{"id":"fail-gracefully","description":"Handle verification failures","prompt":"Verify with missing implementation","setup":"Some tasks not yet implemented","expected":"Should report gaps clearly","assertions":["Identifies which tasks/specs are incomplete","Does NOT mark change as verified","Suggests running /opsx-apply for remaining work","Reports specific failures with evidence"]}],"trigger_tests":{"should_trigger":["verify the change","check if implementation matches specs","opsx verify register-export","validate the change","is the change complete"],"should_not_trigger":["apply the change","archive the change","verify app config","run tests","create a PR"]}}
diff --git a/.claude/skills/opsx-verify/learnings.md b/.claude/skills/opsx-verify/learnings.md
new file mode 100644
index 00000000..4f53dbd4
--- /dev/null
+++ b/.claude/skills/opsx-verify/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — opsx-verify
+
+## Patterns That Work
+<!-- Verification approaches that reliably catch real implementation gaps -->
+
+## Mistakes to Avoid
+<!-- False positives, wrong severity ratings, or verification errors -->
+
+## Domain Knowledge
+<!-- Facts about OpenSpec schemas, artifact structures, or verification patterns -->
+
+## Open Questions
+<!-- Unresolved verification challenges for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/skill-level-overview.html b/.claude/skills/skill-level-overview.html
new file mode 100644
index 00000000..03c71ba9
--- /dev/null
+++ b/.claude/skills/skill-level-overview.html
@@ -0,0 +1,620 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<title>Skill Level Overview — Hydra</title>
+<style>
+  body { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif; margin: 2rem; background: #1e1e1e; color: #d4d4d4; }
+  h1 { color: #e0e0e0; }
+  h2 { color: #c0c0c0; margin-top: 2rem; }
+  table { border-collapse: collapse; width: 100%; margin-bottom: 2rem; }
+  th, td { border: 1px solid #444; padding: 8px 12px; text-align: left; }
+  th { background: #2d2d2d; cursor: pointer; user-select: none; position: relative; color: #e0e0e0; }
+  th:hover { background: #3a3a3a; }
+  th::after { content: ' \25B4\25BE'; font-size: 0.7em; color: #888; }
+  th.asc::after { content: ' \25B4'; color: #fff; }
+  th.desc::after { content: ' \25BE'; color: #fff; }
+  tr:nth-child(even) { background: #252525; }
+  tr:nth-child(odd) { background: #1e1e1e; }
+  tr:hover { background: #333; }
+
+  td a { color: #70a8f0; text-decoration: none; }
+  td a:hover { text-decoration: underline; }
+
+  /* Line count colours */
+  td.lines { text-align: right; font-size: 0.9em; }
+  .regels-perfecte    { background: #0a2040; color: #60a8f0; }  /* ≤200 */
+  .regels-heel-weinig { background: #0a3a1a; color: #60e070; }  /* 201–300 */
+  .regels-weinig      { background: #1c4a2a; color: #80d090; }  /* 301–400 */
+  .regels-midden      { background: #4a4400; color: #e0d850; }  /* 401–450 */
+  .regels-veel        { background: #4a2800; color: #f09040; }  /* 451–500 */
+  .regels-heel-veel   { background: #5c0000; color: #ff8080; }  /* 501+ */
+
+  /* Level dots */
+  .level-dots { display: flex; gap: 3px; align-items: center; }
+  .level-dot {
+    width: 16px; height: 16px; border-radius: 50%;
+    display: inline-block; flex-shrink: 0;
+    cursor: default;
+    position: relative;
+  }
+  .level-dot.achieved   { background: #1c7a2c; box-shadow: 0 0 4px #1c7a2c88; }
+  .level-dot.gap-struct { background: transparent; border: 2px solid #c87800; box-shadow: 0 0 4px #c8780044; }
+  .level-dot.empty      { background: #3a3a3a; }
+  .level-dot.target-zone { background: #2a5090; box-shadow: 0 0 4px #2a509044; }
+  .level-dot.target-zone.gap-struct { background: #2a5090; border: 2px solid #c87800; box-shadow: 0 0 4px #c8780044; }
+
+  .level-dot[title]:hover::after {
+    content: attr(title);
+    position: absolute;
+    top: -28px; left: 50%; transform: translateX(-50%);
+    background: #444; color: #eee;
+    font-size: 0.7em; padding: 2px 5px; border-radius: 3px;
+    white-space: nowrap; pointer-events: none; z-index: 10;
+  }
+
+  /* Target level badges */
+  td.target-cell { text-align: center; white-space: nowrap; }
+  .target-badge {
+    display: inline-block;
+    padding: 2px 8px; border-radius: 10px;
+    font-weight: bold; font-size: 0.85em;
+  }
+  .tl1 { background: #2a2a2a; color: #888; }
+  .tl2 { background: #0a2050; color: #70a8f0; }
+  .tl3 { background: #073a3a; color: #50d0c0; }
+  .tl4 { background: #2a3a08; color: #a8cc40; }
+  .tl5 { background: #3a2800; color: #f0b840; }
+  .tl6 { background: #4a1800; color: #f07030; }
+  .tl7 { background: #3a0855; color: #cc60f0; }
+
+  /* Legend */
+  .legend { display: flex; gap: 3rem; flex-wrap: wrap; }
+  .legend-group { min-width: 320px; }
+  .legend-group table { width: auto; }
+  .legend-group td:first-child { min-width: 120px; text-align: center; font-weight: bold; }
+  .legend-group td { vertical-align: top; padding: 5px 10px; }
+  .legend-group td small { display: block; color: #888; font-weight: normal; margin-top: 2px; }
+
+  .legend-dot-row { display: flex; gap: 8px; align-items: flex-start; padding: 5px 0; }
+  .legend-dot { width: 14px; height: 14px; border-radius: 50%; display: inline-block; flex-shrink: 0; margin-top: 2px; }
+  .legend-dot.achieved   { background: #1c7a2c; }
+  .legend-dot.gap-struct { background: transparent; border: 2px solid #c87800; }
+  .legend-dot.empty      { background: #3a3a3a; }
+  .legend-dot.target-zone { background: #2a5090; }
+  .legend-dot-label small { display: block; color: #888; font-size: 0.85em; margin-top: 1px; }
+</style>
+</head>
+<body>
+
+<h1>Skill Level Overview — Hydra</h1>
+<p style="margin-top: -0.5rem; color: #888;">Based on the <a href="https://github.com/ConductionNL/.github/blob/feature/claude-code-tooling/docs/claude/writing-skills.md" style="color: #70a8f0;">7-level skill maturity framework</a></p>
+
+<table id="skills">
+<thead>
+<tr>
+  <th data-col="0">Skill</th>
+  <th data-col="1">Description</th>
+  <th data-col="2">Current Level</th>
+  <th data-col="3">Target Level</th>
+  <th data-col="4">Lines</th>
+</tr>
+</thead>
+<tbody>
+<!--
+  data-maturity   = highest level where ALL criteria are fully met (1-7)
+  data-structural = highest level pattern structurally present (equals maturity if no gap)
+  data-target     = desired maximum level to reach (1-7)
+-->
+<tr data-maturity="2" data-structural="2" data-target="3" data-l5struct="1">
+  <td><a href="clean-env/SKILL.md">clean-env</a></td><td>Reset the OpenRegister development environment (stop, remove volumes, restart, install apps)</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl3">L3</span></td>
+  <td class="lines regels-perfecte">48</td>
+</tr>
+<tr data-maturity="5" data-structural="5" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="create-pr/SKILL.md">create-pr</a></td><td>Create a Pull Request from the current branch — runs local checks, picks target branch, and opens the PR on GitHub</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-midden">446</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="7" data-l5struct="1" data-l6infra="1" data-l7struct="1">
+  <td><a href="feature-counsel/SKILL.md">feature-counsel</a></td><td>Analyze a projects OpenSpec from 8 persona perspectives and suggest additional features</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-heel-weinig">288</td>
+</tr>
+<tr data-maturity="2" data-structural="1" data-target="4">
+  <td><a href="openspec-apply-change/SKILL.md">openspec-apply-change</a></td><td>Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">156</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="5" data-l7struct="1">
+  <td><a href="openspec-archive-change/SKILL.md">openspec-archive-change</a></td><td>Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl5">L5</span></td>
+  <td class="lines regels-perfecte">114</td>
+</tr>
+<tr data-maturity="2" data-structural="1" data-target="4">
+  <td><a href="openspec-explore/SKILL.md">openspec-explore</a></td><td>Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think th…</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">288</td>
+</tr>
+<tr data-maturity="2" data-structural="1" data-target="4">
+  <td><a href="openspec-propose/SKILL.md">openspec-propose</a></td><td>Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete…</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">110</td>
+</tr>
+<tr data-maturity="2" data-structural="6" data-target="7" data-l6infra="1" data-l5struct="1">
+  <td><a href="opsx-apply/SKILL.md">opsx-apply</a></td><td>Implement tasks from an OpenSpec change (Experimental)</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-weinig">309</td>
+</tr>
+<tr data-maturity="5" data-structural="7" data-target="6" data-l5struct="1" data-l6infra="1" data-l7struct="1">
+  <td><a href="opsx-apply-loop/SKILL.md">opsx-apply-loop</a></td><td>Iteratively run apply→verify in a loop until verify passes, then auto-archive — runs per-app in Docker context</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-veel">470</td>
+</tr>
+<tr data-maturity="5" data-structural="5" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="opsx-archive/SKILL.md">opsx-archive</a></td><td>Archive a completed change in the experimental workflow</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-weinig">332</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="opsx-bulk-archive/SKILL.md">opsx-bulk-archive</a></td><td>Archive multiple completed changes at once</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">300</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="opsx-continue/SKILL.md">opsx-continue</a></td><td>Continue working on a change - create the next artifact (Experimental)</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">149</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="5">
+  <td><a href="opsx-explore/SKILL.md">opsx-explore</a></td><td>Enter explore mode - think through ideas, investigate problems, clarify requirements</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl5">L5</span></td>
+  <td class="lines regels-heel-weinig">220</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="5" data-l6infra="1" data-l5struct="1" data-l7struct="1">
+  <td><a href="opsx-ff/SKILL.md">opsx-ff</a></td><td>Create a change and generate all artifacts needed for implementation in one go</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl5">L5</span></td>
+  <td class="lines regels-perfecte">180</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4">
+  <td><a href="opsx-new/SKILL.md">opsx-new</a></td><td>Start a new change using the experimental artifact workflow (OPSX)</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">79</td>
+</tr>
+<tr data-maturity="5" data-structural="5" data-target="5" data-l5struct="1">
+  <td><a href="opsx-onboard/SKILL.md">opsx-onboard</a></td><td>Guided onboarding - walk through a complete OpenSpec workflow cycle with narration</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl5">L5</span></td>
+  <td class="lines regels-midden">430</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="7" data-l5struct="1" data-l6infra="1" data-l7struct="1">
+  <td><a href="opsx-pipeline/SKILL.md">opsx-pipeline</a></td><td>Process multiple OpenSpec changes in parallel using subagents — full lifecycle from proposal to merged PR</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-veel">486</td>
+</tr>
+<tr data-maturity="2" data-structural="5" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="opsx-plan-to-issues/SKILL.md">opsx-plan-to-issues</a></td><td>Convert an OpenSpec changes tasks.md into a plan.json and create a GitHub Issue for progress tracking</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-heel-weinig">224</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="opsx-sync/SKILL.md">opsx-sync</a></td><td>Sync delta specs from a change to main specs</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">139</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="7" data-l6infra="1" data-l5struct="1">
+  <td><a href="opsx-verify/SKILL.md">opsx-verify</a></td><td>Verify implementation matches change artifacts before archiving</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-weinig">375</td>
+</tr>
+<tr data-maturity="5" data-structural="5" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="sync-docs/SKILL.md">sync-docs</a></td><td>Check and sync documentation to reflect current project state — app feature docs (docs/) for a specific Nextcloud app, or developer/Claude docs in th…</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-veel">473</td>
+</tr>
+<tr data-maturity="5" data-structural="4" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="team-architect/SKILL.md">team-architect</a></td><td>Architect — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-weinig">325</td>
+</tr>
+<tr data-maturity="5" data-structural="4" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="team-backend/SKILL.md">team-backend</a></td><td>Backend Developer — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-weinig">345</td>
+</tr>
+<tr data-maturity="5" data-structural="4" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="team-frontend/SKILL.md">team-frontend</a></td><td>Frontend Developer — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-midden">436</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="team-po/SKILL.md">team-po</a></td><td>Product Owner — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">168</td>
+</tr>
+<tr data-maturity="5" data-structural="5" data-target="6" data-l5struct="1" data-l6infra="1">
+  <td><a href="team-qa/SKILL.md">team-qa</a></td><td>QA Tester — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl6">L6</span></td>
+  <td class="lines regels-heel-weinig">219</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="team-reviewer/SKILL.md">team-reviewer</a></td><td>Code Reviewer — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">296</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="team-sm/SKILL.md">team-sm</a></td><td>Scrum Master — Scrum Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">224</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-accessibility/SKILL.md">test-accessibility</a></td><td>Accessibility Tester — Testing Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">229</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-api/SKILL.md">test-api</a></td><td>API Tester — Testing Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">272</td>
+</tr>
+<tr data-maturity="5" data-structural="7" data-target="7" data-l6infra="1" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-app/SKILL.md">test-app</a></td><td>Run automated browser tests for a Nextcloud app — single agent or multi-perspective parallel testing</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-heel-weinig">213</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="7" data-l6infra="1" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-counsel/SKILL.md">test-counsel</a></td><td>Test a projects features from 8 persona perspectives using browser, API, and documentation testing</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-veel">469</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="7" data-l6infra="1" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-functional/SKILL.md">test-functional</a></td><td>Functional Tester — Testing Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl7">L7</span></td>
+  <td class="lines regels-perfecte">176</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-performance/SKILL.md">test-performance</a></td><td>Performance Tester — Testing Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">227</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-annemarie/SKILL.md">test-persona-annemarie</a></td><td>Persona Tester: Annemarie de Vries — VNG Standards Architect</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">214</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-fatima/SKILL.md">test-persona-fatima</a></td><td>Persona Tester: Fatima El-Amrani — Low-Literate Migrant Citizen</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">165</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-henk/SKILL.md">test-persona-henk</a></td><td>Persona Tester: Henk Bakker — Elderly Citizen</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">172</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-janwillem/SKILL.md">test-persona-janwillem</a></td><td>Persona Tester: Jan-Willem van der Berg — Small Business Owner</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">176</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-mark/SKILL.md">test-persona-mark</a></td><td>Persona Tester: Mark Visser — MKB Software Vendor</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">175</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-noor/SKILL.md">test-persona-noor</a></td><td>Persona Tester: Noor Yilmaz — Municipal CISO / Functional Admin</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">194</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-priya/SKILL.md">test-persona-priya</a></td><td>Persona Tester: Priya Ganpat — ZZP Developer / Integrator</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">202</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1">
+  <td><a href="test-persona-sem/SKILL.md">test-persona-sem</a></td><td>Persona Tester: Sem de Jong — Young Digital Native</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-perfecte">175</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-regression/SKILL.md">test-regression</a></td><td>Regression Tester — Testing Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">224</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="4" data-l5struct="1">
+  <td><a href="test-scenario-create/SKILL.md">test-scenario-create</a></td><td>Create a reusable test scenario for a Nextcloud app — structured Gherkin-style, linked to personas and test commands</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-weinig">323</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="3" data-l5struct="1">
+  <td><a href="test-scenario-edit/SKILL.md">test-scenario-edit</a></td><td>Edit an existing test scenario — update title, steps, personas, tags, priority, status, or any other field</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl3">L3</span></td>
+  <td class="lines regels-heel-weinig">229</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-scenario-run/SKILL.md">test-scenario-run</a></td><td>Execute a specific test scenario against a live Nextcloud app using a browser agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">252</td>
+</tr>
+<tr data-maturity="2" data-structural="7" data-target="4" data-l5struct="1" data-l7struct="1">
+  <td><a href="test-security/SKILL.md">test-security</a></td><td>Security Tester — Testing Team Agent</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl4">L4</span></td>
+  <td class="lines regels-heel-weinig">271</td>
+</tr>
+<tr data-maturity="2" data-structural="2" data-target="3" data-l5struct="1">
+  <td><a href="verify-global-settings-version/SKILL.md">verify-global-settings-version</a></td><td>Check whether global-settings/VERSION has been correctly bumped after any changes to files in the global-settings/ directory</td>
+  <td class="level-cell"></td>
+  <td class="target-cell"><span class="target-badge tl3">L3</span></td>
+  <td class="lines regels-perfecte">121</td>
+</tr>
+</tbody>
+</table>
+
+<h2>Legend</h2>
+<div class="legend">
+  <div class="legend-group">
+    <h3>Current Level (maturity dots)</h3>
+    <div class="legend-dot-row">
+      <span class="legend-dot achieved"></span>
+      <div class="legend-dot-label">
+        <strong>Level achieved (maturity)</strong>
+        <small>All criteria for this level are fully met, including all lower levels.</small>
+      </div>
+    </div>
+    <div class="legend-dot-row">
+      <span class="legend-dot gap-struct"></span>
+      <div class="legend-dot-label">
+        <strong>Structurally present — gap exists</strong>
+        <small>Can appear at three levels: <strong>L5</strong> — <code>evals/</code> folder with 3+ scenarios exists, but L3 or L4 criteria aren't met to reach L5 maturity (auto-detected). <strong>L6</strong> — <code>learnings.md</code> and a "Capture Learnings" step exist, but no dated entries yet (auto-detected). <strong>L7</strong> — agent-spawning or workflow-chain patterns are present, but lower levels aren't fully met (auto-detected). Multiple orange rings can appear on the same row.</small>
+      </div>
+    </div>
+    <div class="legend-dot-row">
+      <span class="legend-dot target-zone"></span>
+      <div class="legend-dot-label">
+        <strong>Target zone — not yet reached</strong>
+        <small>This level falls within the skill's target but is not yet achieved. Shows the remaining levels the skill is working towards.</small>
+      </div>
+    </div>
+    <div class="legend-dot-row">
+      <span class="legend-dot empty"></span>
+      <div class="legend-dot-label">
+        <strong>Not reached — beyond target</strong>
+        <small>Beyond the skill's target level. Not planned for this skill.</small>
+      </div>
+    </div>
+  </div>
+
+  <div class="legend-group">
+    <h3>Maturity Levels</h3>
+    <table>
+      <tr>
+        <td><span class="target-badge tl1">L1</span></td>
+        <td>
+          <strong>Anatomy</strong>
+          <small>The skill has a valid SKILL.md with frontmatter (name, description, metadata), numbered self-contained steps, and explicit guardrails defining what it must never do.</small>
+        </td>
+      </tr>
+      <tr>
+        <td><span class="target-badge tl2">L2</span></td>
+        <td>
+          <strong>Triggering</strong>
+          <small>The description is written in third person, front-loads the key use case within 250 characters, includes specific trigger terms, and the SKILL.md body is under 500 lines using progressive disclosure to extract large blocks into subfolders.</small>
+        </td>
+      </tr>
+      <tr>
+        <td><span class="target-badge tl3">L3</span></td>
+        <td>
+          <strong>Patterns</strong>
+          <small>Built on proven foundations: uses consistent common patterns (model guard, AskUserQuestion, destructive action confirmation), has an <code>examples/</code> folder for expected output formats, and references standards documents where applicable.</small>
+        </td>
+      </tr>
+      <tr>
+        <td><span class="target-badge tl4">L4</span></td>
+        <td>
+          <strong>Domain</strong>
+          <small>Contains business-specific knowledge unique to this project — Dutch government standards (BIO2, GEMMA, NLGov API rules), Nextcloud app patterns, OpenSpec workflow integration, and project architecture. Could not be dropped into a different project and work as-is.</small>
+        </td>
+      </tr>
+      <tr>
+        <td><span class="target-badge tl5">L5</span></td>
+        <td>
+          <strong>Measurement</strong>
+          <small>Has 3+ evaluation scenarios with input prompts, expected output characteristics, and pass/fail assertion criteria. A baseline has been measured (output without the skill), description trigger-testing has been done, and at least one improve cycle has been completed based on eval results.</small>
+        </td>
+      </tr>
+      <tr>
+        <td><span class="target-badge tl6">L6</span></td>
+        <td>
+          <strong>Self-improvement</strong>
+          <small>Captures learnings during execution in a <code>learnings.md</code> file with dated, atomic entries. The skill includes a "capture learnings" step and consolidates insights back into SKILL.md guardrails and rules after ~80–100 entries.</small>
+        </td>
+      </tr>
+      <tr>
+        <td><span class="target-badge tl7">L7</span></td>
+        <td>
+          <strong>Orchestration</strong>
+          <small>Spawns and coordinates multiple sub-agents, or is part of a defined workflow chain with explicit handoff points. Uses isolated execution contexts where needed, supports parallel execution, and has autonomous operation capability for a defined scope.</small>
+        </td>
+      </tr>
+    </table>
+    <p style="margin-top: 0.5rem;"><a href="https://github.com/ConductionNL/.github/blob/feature/claude-code-tooling/docs/claude/writing-skills.md" style="color: #70a8f0; font-size: 0.85em;">Full level criteria in writing-skills.md</a></p>
+  </div>
+
+  <div class="legend-group">
+    <h3>Lines</h3>
+    <table>
+      <tr><td class="lines regels-perfecte">≤ 200</td><td>Ideal — concise, well-extracted</td></tr>
+      <tr><td class="lines regels-heel-weinig">201–300</td><td>Very lean</td></tr>
+      <tr><td class="lines regels-weinig">301–400</td><td>Lean</td></tr>
+      <tr><td class="lines regels-midden">401–450</td><td>Medium — consider extracting</td></tr>
+      <tr><td class="lines regels-veel">451–500</td><td>Large — at the L2 limit</td></tr>
+      <tr><td class="lines regels-heel-veel">501+</td><td>Over limit — extraction needed</td></tr>
+    </table>
+  </div>
+</div>
+
+<script>
+const LEVEL_NAMES = ['', 'Anatomy', 'Triggering', 'Patterns', 'Domain', 'Measurement', 'Self-improvement', 'Orchestration'];
+
+// Render level dots for each row
+document.querySelectorAll('tr[data-maturity]').forEach(row => {
+  const maturity   = parseInt(row.dataset.maturity);
+  const target     = parseInt(row.dataset.target);
+  const l5struct   = row.dataset.l5struct === '1';
+  const l6infra    = row.dataset.l6infra === '1';
+  const l7struct   = row.dataset.l7struct === '1';
+  const cell = row.querySelector('.level-cell');
+  const wrapper = document.createElement('div');
+  wrapper.className = 'level-dots';
+
+  for (let i = 1; i <= 7; i++) {
+    const dot = document.createElement('span');
+    dot.className = 'level-dot';
+    dot.title = `L${i}: ${LEVEL_NAMES[i]}`;
+
+    if (i <= maturity) {
+      dot.classList.add('achieved');
+    } else {
+      dot.classList.add(i <= target ? 'target-zone' : 'empty');
+      if (i === 5 && l5struct && 5 > maturity) dot.classList.add('gap-struct');
+      if (i === 6 && l6infra  && 6 > maturity) dot.classList.add('gap-struct');
+      if (i === 7 && l7struct && 7 > maturity) dot.classList.add('gap-struct');
+    }
+    wrapper.appendChild(dot);
+  }
+  cell.appendChild(wrapper);
+});
+
+// Sortable columns
+const table = document.getElementById('skills');
+const headers = table.querySelectorAll('th');
+const tbody   = table.querySelector('tbody');
+let currentSort = { col: -1, asc: true };
+
+headers.forEach(th => {
+  th.addEventListener('click', () => {
+    const col = parseInt(th.dataset.col);
+    const asc = currentSort.col === col ? !currentSort.asc : true;
+    currentSort = { col, asc };
+
+    headers.forEach(h => h.classList.remove('asc', 'desc'));
+    th.classList.add(asc ? 'asc' : 'desc');
+
+    const rows = Array.from(tbody.querySelectorAll('tr'));
+    rows.sort((a, b) => {
+      let va, vb;
+
+      if (col === 2) {
+        // Green > blue > orange > lines (all descending when high-to-low)
+        const orangeCount = r => {
+          const m = parseInt(r.dataset.maturity);
+          let n = 0;
+          if (r.dataset.l5struct === '1' && 5 > m) n++;
+          if (r.dataset.l6infra  === '1' && 6 > m) n++;
+          if (r.dataset.l7struct === '1' && 7 > m) n++;
+          return n;
+        };
+        const lvl = r => {
+          const m = parseInt(r.dataset.maturity);
+          const t = parseInt(r.dataset.target);
+          const blue = Math.max(0, t - m);
+          const orange = orangeCount(r);
+          const lines = parseInt(r.cells[4].textContent.trim()) || 0;
+          return m * 100000000 + blue * 1000000 + orange * 10000 + lines;
+        };
+        va = lvl(a);
+        vb = lvl(b);
+      } else if (col === 3) {
+        va = parseInt(a.dataset.target);
+        vb = parseInt(b.dataset.target);
+      } else if (col === 4) {
+        va = parseInt(a.cells[col].textContent.trim()) || 0;
+        vb = parseInt(b.cells[col].textContent.trim()) || 0;
+      } else {
+        va = a.cells[col].textContent.trim();
+        vb = b.cells[col].textContent.trim();
+      }
+
+      if (typeof va === 'number' && typeof vb === 'number') {
+        return asc ? va - vb : vb - va;
+      }
+      return asc ? va.toString().localeCompare(vb.toString(), 'en') : vb.toString().localeCompare(va.toString(), 'en');
+    });
+
+    rows.forEach(row => tbody.appendChild(row));
+  });
+});
+
+// Default sort: Current Level, high to low
+headers[2].click();
+headers[2].click();
+</script>
+
+<h2>Updating</h2>
+<p>Run <code>bash <a href="update-skill-overview.sh" style="color: #70a8f0;">update-skill-overview.sh</a></code> to auto-update:</p>
+<ul style="color: #b0b0b0;">
+  <li>Maturity levels (L1, L2, L3, L5, L6, L7 auto-detected from SKILL.md)</li>
+  <li>Line counts and color classes</li>
+  <li>L5/L6/L7 struct flags (orange ring detection)</li>
+  <li>Skill descriptions (synced from SKILL.md frontmatter, truncated at 150 chars)</li>
+  <li>Skill name links (new rows link to SKILL.md)</li>
+  <li>New skill rows (auto-added when a new skill directory is detected)</li>
+  <li>Orphan detection (warns when a row's skill directory no longer exists)</li>
+</ul>
+<p style="color: #888;"><strong>Requires human judgment</strong> (the script flags mismatches, but can't verify quality):</p>
+<ul style="color: #888;">
+  <li><strong>L4 (Domain Knowledge)</strong> — never auto-set or auto-removed. The script prominently asks for your input when L4 blocks higher maturity. Requires verifying that business-specific references, templates, and architecture knowledge are present.</li>
+  <li><strong>L3 quality</strong> — the script detects examples/ and references/ folders + common patterns, but can't verify the quality of examples or whether patterns are applied correctly.</li>
+  <li><strong>L5 baseline</strong> — the script checks for eval scenarios and trigger tests, but can't verify if evals were actually executed against a baseline.</li>
+  <li><strong>Target level</strong> — a product decision about where the skill should be headed.</li>
+</ul>
+
+</body>
+</html>
diff --git a/.claude/skills/sync-docs/SKILL.md b/.claude/skills/sync-docs/SKILL.md
new file mode 100644
index 00000000..a21d7d86
--- /dev/null
+++ b/.claude/skills/sync-docs/SKILL.md
@@ -0,0 +1,473 @@
+---
+name: sync-docs
+description: "Check and sync documentation to reflect current project state — app feature docs (docs/) for a specific Nextcloud app, or developer/Claude docs in the .github repo (docs/claude/)"
+metadata:
+  category: Workflow
+  tags: [docs, sync, maintenance]
+---
+
+# Sync Docs — Check and Update Documentation
+
+Two documentation targets can be synced:
+
+- **`app`** — Feature and user-facing docs for a specific Nextcloud app in `{APP_DIR}/docs/` (feature docs, architecture docs, standards references, etc.)
+- **`dev`** — Developer/Claude guides in the `.github` repo at `{GITHUB_REPO}/docs/claude/` (workflow.md, writing-specs.md, writing-docs.md, commands.md, testing.md, etc.)
+
+**Input**: Optional argument `app [app-name]`, `dev`, or just the app name directly. If omitted, ask which target.
+
+---
+
+## Step 0: Determine Target
+
+If no argument provided, ask using AskUserQuestion:
+
+**"Which docs do you want to sync?"**
+- **`app` — App and user-facing docs** (`{APP_DIR}/docs/`) — feature documentation, standards references, admin guides
+- **`dev` — Developer and Claude guides** (`~/.github/docs/claude/`) — workflow docs, spec writing guide, command reference
+
+Store as `{SYNC_TARGET}` (`app` or `dev`).
+
+### If `dev` is selected — locate the `.github` repo
+
+Check if `~/.github` exists and contains a `.git` directory (i.e., is a git repo). Expand `~` to the actual home directory.
+
+- **Found** — store the absolute path as `{GITHUB_REPO}` (e.g. `/home/wilco/.github`). The docs to sync live at `{GITHUB_REPO}/docs/claude/`.
+- **Not found** — inform the user: *"Cannot find the .github repo at ~/.github. This repo is required for dev docs sync. Clone it first and try again."* **Stop the skill.**
+
+### If `app` is selected — locate `.github` repo, `apps-extra`, and resolve `{APP_NAME}`
+
+Also resolve `{GITHUB_REPO}` (same check as dev mode above) — needed for reading `writing-docs.md`. If not found, warn the user but continue (writing-docs.md is used as guidance, not as the sync target).
+
+Discover the `apps-extra` directory:
+1. Check if the workspace root's parent directory is named `apps-extra` — if so, use that parent as `{APPS_EXTRA}`.
+2. Otherwise, check if an `apps-extra/` subdirectory exists inside the workspace root.
+3. If neither is found, inform the user: *"Cannot find an apps-extra directory (checked parent of workspace and workspace/apps-extra/). This directory is required for app docs sync."* **Stop the skill.**
+
+Determine `{APP_NAME}`:
+- If passed as argument (e.g. `/sync-docs app openregister` or `/sync-docs openregister`), use it directly.
+- Otherwise, scan `{APPS_EXTRA}/` for subdirectories that are git repos (contain a `.git` directory) and ask the user which app to sync docs for. If no git repos are found, inform the user and stop.
+
+Store the resolved app directory path as `{APP_DIR}` (e.g. `{APPS_EXTRA}/openregister`).
+
+---
+
+## Step 0.5: Check writing-docs.md Currency *(optional)*
+
+After determining the target, ask using AskUserQuestion:
+
+**"Run pre-flight metadata checks before syncing?"**
+
+These checks validate `config.yaml` rules, Sources of Truth accuracy, and schema alignment with `writing-specs.md`. Useful for catching project-level drift, but skippable for quick syncs.
+
+- **Yes, run checks** — continue with Step 0.5
+- **No, skip** — proceed directly to the relevant sync mode
+
+Only run the following if the user selected "Yes":
+
+Run the four checks described in [references/preflight-checks.md](references/preflight-checks.md) (Checks A–D) in parallel, then follow the reporting and confirmation flow in that file.
+
+---
+
+## Documentation Principles (applies to all modes)
+
+All auditing and updating follows `writing-docs.md` (located at `{GITHUB_REPO}/docs/claude/writing-docs.md`). Read it before starting any sync. The sections most relevant to gap analysis:
+
+- **[Reference, Don't Duplicate](../../docs/writing-docs.md#the-core-rule-reference-dont-duplicate)** — every piece of information should live in exactly one place; flag any content that restates a source of truth and replace it with a link
+- **[Sources of Truth](../../docs/writing-docs.md#sources-of-truth)** — the authoritative table mapping each concern to its canonical file; use this to determine what to load and what to link to
+- **[Audience Determines Location](../../docs/writing-docs.md#audience-determines-location)** — each doc has one target audience; flag content written for the wrong audience
+- **[Document Lifecycle Markers](../../docs/writing-docs.md#document-lifecycle-markers)** — rules for `[Future]` and `[Legacy]` markers
+- **[Outdated and Legacy Documentation](../../docs/writing-docs.md#outdated-and-legacy-documentation)** — when to update, move, mark, or delete
+- **[Writing Anti-Patterns](../../docs/writing-docs.md#writing-anti-patterns)** — flag time-sensitive language, hardcoded versions, vague actors
+- **[Formatting Alignment](../../docs/writing-docs.md#formatting-alignment)** — check markdown table separator width and cell padding; check ASCII diagram `│` alignment and label/description spacing; fix misalignments when editing any file
+
+Do not re-derive these principles inline; read `writing-docs.md` and apply them directly.
+
+---
+
+## APP DOCS MODE
+
+Syncs the feature and user-facing documentation for a specific Nextcloud app to match what is actually implemented.
+
+### Phase 1: Load Source of Truth
+
+Read all of the following in parallel:
+
+**Specs and roadmap:**
+1. All spec files in `{APP_DIR}/openspec/specs/*/spec.md` — what is currently specified
+2. `{APP_DIR}/openspec/ROADMAP.md` — project phases and current phase (if present)
+3. `{APP_DIR}/openspec/app-config.json` — app identity, goals, features list (if present)
+
+**Company-wide Architectural Design Rules:**
+4. All ADR files in `{APPS_EXTRA}/.claude/openspec/architecture/` — the constraints every Conduction app must follow (API conventions, NL Design, i18n requirements, test coverage, screenshots, etc.). These are **read as auditing context only** — never link to them from app docs.
+
+**App-specific ADRs** (if present):
+5. All ADR files in `{APP_DIR}/openspec/architecture/` — app-level overrides or additions to company-wide rules.
+
+### Phase 2: Read Existing Docs
+
+Read all user- and admin-facing documentation files for the app. At minimum check for:
+
+**Root level:**
+- `{APP_DIR}/README.md` — the primary public-facing description: feature summary, screenshots, setup/install instructions, external links
+
+**`{APP_DIR}/docs/` tree:**
+- `{APP_DIR}/docs/features/README.md` and all individual feature docs in `{APP_DIR}/docs/features/`
+- `{APP_DIR}/docs/ARCHITECTURE.md` — high-level architecture and data model description (if present)
+- `{APP_DIR}/docs/FEATURES.md` — consolidated feature overview (if present)
+- `{APP_DIR}/docs/GOVERNMENT-FEATURES.md` — government/standards-specific feature notes (if present)
+- `{APP_DIR}/docs/DESIGN-REFERENCES.md` — standards and design references (if present)
+- `{APP_DIR}/docs/zgw-implementation.md` or similar standards implementation notes (if present)
+- Any other `.md` files in `{APP_DIR}/docs/` that are not clearly developer-internal
+
+**Developer-internal folders to skip** (do not audit for user-facing correctness):
+- `{APP_DIR}/docs/development/`, `{APP_DIR}/docs/development-notes/`, `{APP_DIR}/docs/Technical/` — these are developer notes, not user docs; flag only if they contain content that belongs in user-facing docs instead
+
+### Phase 3: Gap Analysis
+
+For each doc file, compare content against the loaded specs, ADRs, and documentation principles (see [Documentation Principles](#documentation-principles-applies-to-all-modes)). Identify:
+
+**Outdated content** — describes functionality that has changed or been removed
+**Missing content** — features that are implemented (per specs with status `in-progress` or `done`) but not documented
+**Stale `[Future]` markers** — things marked as future that are now implemented; apply the full removal checklist from [Document Lifecycle Markers](../../docs/writing-docs.md#document-lifecycle-markers)
+**Broken cross-references** — links to spec files or other docs that have moved or been renamed (see [Link Structure](../../docs/writing-docs.md#link-structure))
+**Duplicated content** — information that already lives in a spec; flag and propose replacing with a link per [Reference, Don't Duplicate](../../docs/writing-docs.md#the-core-rule-reference-dont-duplicate)
+**Wrong audience content** — developer/technical content in user-facing guides; flag for removal or relocation per [Audience Determines Location](../../docs/writing-docs.md#audience-determines-location)
+**Writing anti-patterns** — time-sensitive language, hardcoded versions, vague actors; see [Writing Anti-Patterns](../../docs/writing-docs.md#writing-anti-patterns)
+**Missing standards references** — features that lack GEMMA, ZGW, or Forum Standaardisatie references where applicable
+
+**ADR compliance gaps** — use the loaded ADRs as a checklist against the docs:
+- ADR-003 (NL Design System) — does the UI/UX description reflect NL Design components?
+- ADR-005 (i18n) — does the docs mention both Dutch and English support where relevant?
+- ADR-007 (Security) — are authentication and role requirements described accurately?
+- ADR-010 (Documentation with Screenshots) — does `{APP_DIR}/README.md` and feature docs include screenshots for key views? Are the image files present on disk? Use `docs/features/img/` for feature-specific screenshots (reference as `img/{feature}-{view}.png`), `docs/img/` for general or multi-doc screenshots, and `docs/screenshots/` for App Store gallery shots.
+- Any app-specific ADRs — does the documentation reflect app-level architectural decisions?
+
+**`{APP_DIR}/README.md`-specific checks:**
+- Does the feature list match what is actually implemented (per specs)?
+- Are setup/install instructions still accurate?
+- Do screenshots exist on disk for all screenshot references?
+- Are external links (docs site, GitHub badges) still correct?
+
+Present a summary table:
+
+```
+{APP_DIR}/README.md:
+  ✓ Feature list — matches implemented specs
+  ✗ Screenshots missing for "Settings" view — ADR-010 requires screenshots for all key views
+  ~ Install instructions — reference old environment variable name
+
+{APP_DIR}/docs/features/README.md:
+  ✓ Search feature — up to date
+  ✗ Export feature — not documented, but openspec/specs/export/spec.md exists with status done
+  ~ Export section still marked [Future] — check if implemented
+
+{APP_DIR}/docs/ARCHITECTURE.md:
+  ✓ Data model — accurate
+  ✗ API layer diagram — does not reflect current controller structure per specs
+  ...
+```
+
+### Phase 4: Confirm and Update
+
+Use AskUserQuestion:
+
+**"I found N outdated or missing items across {APP_NAME} docs. How would you like to proceed?"**
+- **Update all** — apply all identified updates
+- **Review each file** — go file by file, confirm before each update
+- **Show full diff first** — show all proposed changes, then confirm once
+- **Cancel** — no changes
+
+Apply updates using the Edit tool (never rewrite entire files unless everything needs changing).
+
+**When updating**, follow the full guidance in `writing-docs.md` (at `{GITHUB_REPO}/docs/claude/writing-docs.md`):
+- Keep the existing writing style and structure
+- Update factual content only (URLs, feature descriptions, steps, settings)
+- Move `[Future]` items to implemented sections when appropriate — follow the full removal checklist in [Document Lifecycle Markers](../../docs/writing-docs.md#document-lifecycle-markers)
+- Use `[Legacy]` markers for superseded content — see [Outdated and Legacy Documentation](../../docs/writing-docs.md#outdated-and-legacy-documentation)
+- Add new sections for features not yet documented
+- Preserve any content that is still accurate
+- **Replace duplicated content with links** — follow [Reference, Don't Duplicate](../../docs/writing-docs.md#the-core-rule-reference-dont-duplicate) and [Handling large duplicates](../../docs/writing-docs.md#handling-large-duplicates)
+- Avoid writing anti-patterns — see [Writing Anti-Patterns](../../docs/writing-docs.md#writing-anti-patterns)
+- **Never add links pointing into `.claude/`** — see the No `.claude/` Links rule in [Guardrails](#guardrails)
+- **Screenshot storage** — all feature screenshots go in `{APP_DIR}/docs/features/img/` with filenames `{feature}-{view}.png` (e.g., `projects-list.png`). Reference them from feature docs with relative paths (`img/projects-list.png`). Copy from `{APPS_EXTRA}/test-results/` after test runs — that directory is ephemeral.
+
+### Phase 5: Report
+
+```
+Docs Sync — {APP_NAME} App Docs
+──────────────────────────────────
+{APP_DIR}/README.md                       — N changes applied
+{APP_DIR}/docs/features/README.md         — N changes applied
+{APP_DIR}/docs/features/search.md         — up to date, no changes
+{APP_DIR}/docs/ARCHITECTURE.md            — N changes applied
+{APP_DIR}/docs/ARCHITECTURE.md            — up to date, no changes
+
+All {APP_NAME} docs are now current.
+```
+
+---
+
+## DEV DOCS MODE (`{GITHUB_REPO}/docs/claude/`)
+
+Syncs the developer and Claude workflow documentation in the `.github` repo to match current commands, skills, and project conventions.
+
+**Prerequisites:** `{GITHUB_REPO}` was resolved in Step 0. The docs to sync live at `{GITHUB_REPO}/docs/claude/`.
+
+### Phase 1: Load Source of Truth
+
+The authoritative list of what counts as a source of truth for this project lives in the **Sources of Truth** table in `{GITHUB_REPO}/docs/claude/writing-docs.md`. Read that table first, then load all sources relevant to the dev docs. Sources come from two locations — the `.github` repo and the current workspace:
+
+**From the `.github` repo (`{GITHUB_REPO}`):**
+8. `{GITHUB_REPO}/global-settings/settings.json` and `{GITHUB_REPO}/global-settings/VERSION` — source of truth for harness configuration; used to verify `global-claude-settings.md` accuracy
+9. `{GITHUB_REPO}/usage-tracker/README.md`, `{GITHUB_REPO}/usage-tracker/SETUP.md`, `{GITHUB_REPO}/usage-tracker/MODELS.md` — source of truth for usage tracker setup and model list; used to verify tracker references in `README.md` and `global-claude-settings.md`
+
+**From the current workspace:**
+1. All skill SKILL.md files in `.claude/skills/`
+3. All spec files in `openspec/specs/*/spec.md` — for writing-specs.md accuracy check
+4. `openspec/config.yaml` — active schema name and context rules
+5. The conduction schema: `openspec/schemas/conduction/schema.yaml` and all files in `openspec/schemas/conduction/templates/`
+6. All files in `personas/` — source of truth for persona names, behavior, and device preferences; used to verify `testing.md` and persona tester references
+7. The workspace root `Makefile` — source of truth for available `make` targets; used to verify `make` command references in `README.md` and `getting-started.md`
+
+### Phase 2: Read Existing Dev Docs
+
+Read all files in `{GITHUB_REPO}/docs/claude/`:
+- `README.md`
+- `commands.md`
+- `workflow.md`
+- `writing-specs.md`
+- `writing-docs.md`
+- `testing.md`
+- `docker.md`
+- `getting-started.md`
+- `global-claude-settings.md`
+- `parallel-agents.md`
+- Any other `.md` files found
+
+### Phase 3: Gap Analysis
+
+Check each doc for accuracy, completeness, and documentation principle violations (see [Documentation Principles](#documentation-principles-applies-to-all-modes)). For all files, also apply:
+- [Reference, Don't Duplicate](../../docs/writing-docs.md#the-core-rule-reference-dont-duplicate) — flag any content that restates a source of truth elsewhere
+- [Audience Determines Location](../../docs/writing-docs.md#audience-determines-location) — flag content written for the wrong audience
+- [Link Structure](../../docs/writing-docs.md#link-structure) — flag broken or absolute-path links
+- [Writing Anti-Patterns](../../docs/writing-docs.md#writing-anti-patterns) — flag time-sensitive language, hardcoded versions, vague actors
+
+**`commands.md`** — Does it list all current skills/commands? Are any commands missing or have outdated descriptions? Are there command descriptions that duplicate content already in command files (should link instead)?
+
+**`workflow.md`** — Does the artifact progression diagram match actual command behavior? Are the step descriptions accurate?
+
+**`writing-specs.md`** — Does the spec structure template match what actual specs look like? Is the field reference table accurate? Is the grouping rule for the `**OpenSpec changes**` list present?
+
+**`writing-docs.md`** — Do the documentation principles reflect current project rules? Is the Sources of Truth table up to date? Are all entries pointing to files that actually exist?
+
+**`testing.md`** — Are the testing commands described accurately? Do persona references match current `personas/` in the workspace?
+
+**`getting-started.md`** — Are the setup steps still accurate for the current Docker/bootstrap setup? Do any `make` commands referenced exist as targets in the workspace root `Makefile`?
+
+**`global-claude-settings.md`** — Do the permissions, hooks, and env vars described match what is actually in `{GITHUB_REPO}/global-settings/settings.json`? Are any settings documented that no longer exist in `settings.json`? Are there settings or hooks in `settings.json` that are undocumented or misdescribed?
+
+**`README.md`** (docs/claude/) — Is the docs index complete? Does the Quick Reference flow match the actual workflow?
+
+**`schema.yaml` (specs artifact instruction)** — Does the `specs` artifact instruction in `openspec/schemas/conduction/schema.yaml` align with `writing-specs.md`? Apply the same logic as Check C from Step 0.5. Flag any scenario format, RFC 2119 guidance, or required-section differences that were introduced in `writing-specs.md` but not reflected in the schema instruction.
+
+**`templates/spec.md`** — Does the template in `openspec/schemas/conduction/templates/spec.md` use GIVEN/WHEN/THEN? Does it include all three delta operations (ADDED/MODIFIED/REMOVED)? Does it match the delta spec format documented in `writing-specs.md`?
+
+**`{GITHUB_REPO}/README.md`** — Does it accurately describe the project, workspace structure, and setup steps? Is it consistent with what's actually implemented? Do any `make` commands referenced exist as targets in the workspace root `Makefile`? Do any references to usage-tracker (setup steps, CLI commands, model list) still match `{GITHUB_REPO}/usage-tracker/README.md`, `SETUP.md`, and `MODELS.md`?
+
+Present a summary per file showing what's accurate, what's outdated, what's missing, and what violates documentation principles.
+
+### Phase 4: Confirm and Update
+
+Same flow as App Docs Phase 4 — ask before making changes, offer per-file or all-at-once.
+
+**When updating `{GITHUB_REPO}/docs/claude/`**, follow `{GITHUB_REPO}/docs/claude/writing-docs.md`:
+- Never change the *intent* of the documentation without user confirmation — these docs guide Claude's behavior
+- Focus on factual accuracy: command names, file paths, step descriptions
+- **Replace duplicated content with links** — if a dev doc restates what's already in a command file or spec, replace with a reference per [Reference, Don't Duplicate](../../docs/writing-docs.md#the-core-rule-reference-dont-duplicate)
+- Use `[Legacy]` markers for superseded approaches — see [Outdated and Legacy Documentation](../../docs/writing-docs.md#outdated-and-legacy-documentation)
+- Avoid writing anti-patterns — see [Writing Anti-Patterns](../../docs/writing-docs.md#writing-anti-patterns)
+- If a significant behavioral change is proposed, flag it for user review
+
+### Phase 5: Report
+
+```
+Docs Sync — Dev Docs ({GITHUB_REPO})
+──────────────────────────────────────
+{GITHUB_REPO}/README.md                                         — N changes applied
+{GITHUB_REPO}/docs/claude/commands.md                           — N commands added/updated
+{GITHUB_REPO}/docs/claude/workflow.md                           — artifact diagram updated
+{GITHUB_REPO}/docs/claude/writing-specs.md                      — up to date, no changes
+{GITHUB_REPO}/docs/claude/testing.md                            — N changes applied
+{GITHUB_REPO}/docs/claude/README.md                             — N links updated
+openspec/schemas/conduction/schema.yaml                         — specs instruction updated
+openspec/schemas/conduction/templates/spec.md                   — template updated
+```
+
+### Phase 6: Commands and Skills Review
+
+After applying documentation changes, audit commands and skills in two parts.
+
+---
+
+#### Part A — Change-impact check
+
+Run this unconditionally. Read all `SKILL.md` files in `.claude/skills/` and compare them against the documentation changes just made in this sync. Look for:
+
+- **Stale references** — a command or skill references a file path, section heading, or doc name that was renamed or moved during this sync
+- **Outdated instructions** — a command or skill instructs Claude to follow a workflow, use a tool, or apply a principle that was updated in the docs just synced
+- **Missing guidance** — the updated doc introduced a new rule or convention (e.g. a new writing anti-pattern, a new source of truth entry) that a command or skill should now follow but doesn't mention
+- **Redundant inline content** — a command or skill restates something now clearly documented in a doc file; replace with a link
+
+After completing Part A, present its findings and ask using AskUserQuestion:
+
+**"Part A (change-impact check) complete. Would you also like to run the standalone health check on all skill files (`.claude/skills/`)?"**
+
+The standalone health check reads every command and skill file independently and audits the full content — broken links, stale references, anti-patterns, scope creep, and more. It is thorough but takes significantly longer.
+
+- **Yes, run the health check** — continue to Part B
+- **No, skip** — go straight to the combined summary with Part A findings only
+
+---
+
+#### Part B — Standalone health check *(optional)*
+
+Only run if the user selected "Yes" above.
+
+Read every command and skill file independently and audit against the current state of the project. This is not limited to what changed in this sync — it is a full content review.
+
+**What to load as reference:**
+- `{GITHUB_REPO}/docs/claude/writing-docs.md` — documentation principles (link vs duplicate, audience, anti-patterns)
+- `openspec/config.yaml` — current rules, schema name, and context conventions
+- `{GITHUB_REPO}/docs/claude/commands.md` — canonical command descriptions and signatures
+- `openspec/schemas/conduction/schema.yaml` — active schema artifact instructions
+
+**What to check for each command and skill file:**
+
+1. **Broken or stale links** — any `[text](path)` that points to a file, section heading, or anchor that no longer exists or was moved. Cross-check against the actual file tree. Flag every broken path.
+
+2. **Stale content references** — mentions of file paths, command names, persona names, spec names, or tool names that have changed. Example: a command that references an app directory that was renamed, or a skill that lists a command flag that no longer exists.
+
+3. **Duplicated content** — inline content that restates something already clearly covered in a source of truth (per `writing-docs.md` Sources of Truth table). Per the Reference, Don't Duplicate principle: flag blocks of inline guidance that should link to the authoritative doc instead. Common cases:
+   - A skill that restates writing-docs.md rules rather than pointing to the section
+   - A command that restates spec structure details already in writing-specs.md
+   - A command that inlines persona descriptions that live in `personas/`
+
+4. **Missing cross-references** — a command or skill covers a concern for which a relevant doc exists, but doesn't reference it. Example: a testing skill that describes persona behavior without pointing to `personas/`; a spec-creation command that doesn't reference `writing-specs.md`. Only flag where the missing link would meaningfully help Claude.
+
+5. **Writing anti-patterns** — time-sensitive language ("currently", "as of now", "recently"), hardcoded version numbers in prose, vague actors ("the user", "you should"), "see above" / "see below" positional references. See [Writing Anti-Patterns](../../docs/writing-docs.md#writing-anti-patterns).
+
+6. **Outdated workflow steps** — steps that no longer match current project conventions, tooling, or the command descriptions in `commands.md`. Examples: a skill that says to run a command with a flag that was removed; a command that refers to an artifact phase that no longer exists; a skill that references the wrong browser number for parallel testing.
+
+7. **Content that should be removed** — instructions for features or workflows that have been removed from scope, or caveats that are no longer true. Only remove content when it is clearly no longer valid — if in doubt, flag as `[Verify]`.
+
+8. **Scope creep** — a skill or command that has grown to include guidance that belongs in a different file (e.g. lengthy setup instructions in a testing skill that belong in `getting-started.md`). Flag for extraction and linking.
+
+**Depth guidance:**
+- Read every `SKILL.md` in `.claude/skills/`
+- For each file, run all 8 checks above
+- Flag only real issues — don't flag something just because it could theoretically be shorter or link somewhere. The bar is: does this mislead Claude, break something, or clearly violate writing-docs.md principles?
+
+---
+
+After presenting Part B findings (or if B was skipped), ask using AskUserQuestion:
+
+**"Would you also like to run a doc structure review of `{GITHUB_REPO}/docs/claude/`?"**
+
+- **Yes, run doc structure review** — continue to Part C
+- **No, skip** — go straight to the combined summary
+
+---
+
+#### Part C — Doc structure review *(optional)*
+
+Only run if the user selected "Yes" above.
+
+Read all files in `{GITHUB_REPO}/docs/claude/` and audit the structure holistically — not individual file content, but how the files relate to each other.
+
+**What to check:**
+
+1. **Overlap in purpose** — do any two docs serve the same audience for the same concern? A doc that overlaps heavily in topic and audience with another is a maintenance risk: they will diverge over time. Flag pairs that cover more than ~50% of the same ground.
+
+2. **Differentiation** — for docs that overlap in subject or audience, is each doc's distinct role clear from the first paragraph? A reader picking up either file should immediately understand why this one exists and how it differs from the other. If the distinction is not visible from the intro, flag it.
+
+3. **Missing cross-references between overlapping docs** — when two docs share topic or audience, do they reference each other at the relevant point? Could the overlap in one file be reduced by replacing duplicated content with a link to the other? Flag cases where a single well-placed cross-reference would eliminate meaningful duplication.
+
+4. **Doc proliferation** — docs that cover a concern narrow enough to warrant only a section in an existing file. A standalone doc is justified when it has internal navigation needs, targets a distinct audience, or is frequently referenced from multiple places. A short, narrowly-scoped doc that is always read alongside one other doc is a candidate for merger.
+
+**Depth guidance:**
+- Read every file in `{GITHUB_REPO}/docs/claude/`
+- For each pair of docs that share subject matter, run checks 1–4
+- Flag only real structural issues — a different angle on the same topic is not overlap; repetition of the same content for the same audience is
+
+---
+
+#### Combined summary and confirmation
+
+Present a single consolidated summary covering all parts that were run.
+
+```
+Dev Docs Review
+────────────────────────────────────────
+Skills & Commands  (Part A + Part B — or "Part A only" if B was skipped)
+
+  .claude/skills/sync-docs/SKILL.md               — N items  [A: 1, B: 2]
+  .claude/skills/opsx-ff/SKILL.md                  — up to date
+  .claude/skills/test-counsel/SKILL.md             — N items  [B: 1 stale link, 1 anti-pattern]
+  .claude/skills/test-scenario-create/SKILL.md     — up to date
+  ...
+  Subtotal: N items across M skills
+
+Doc Structure  (Part C — omit section if C was skipped)
+
+  docs/claude/workflow.md + getting-started.md    — N items  [C: overlap, no cross-ref]
+  docs/claude/docker.md                           — up to date
+  ...
+  Subtotal: N items across M doc pairs
+
+Total: N items across M files
+```
+
+For each flagged item, include a one-line description of the issue and which check (1–8, Part A, or C) identified it.
+
+Then ask using AskUserQuestion:
+
+**"Documentation sync is complete. I found N items across M files. What would you like to do?"**
+- **Update all** — apply all identified updates
+- **Review each** — go through each file one at a time, confirm before each update
+- **Show proposed changes first** — show all diffs, then confirm once
+- **Skip** — leave commands and skills as-is for now
+
+Apply updates following the same guardrails as Phase 4 — never change the intent of a command or skill without user confirmation. Flag anything ambiguous as `[Verify]` rather than making assumptions.
+
+```
+All dev docs are now current.
+```
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+## Guardrails
+
+- **Never auto-save** — always show what will change and ask for confirmation before writing
+- **Docs only — never touch code or config** — this command makes changes exclusively to `.md` documentation files. Never modify source code, scripts, JSON, YAML, TOML, shell scripts, or any other non-markdown file, even if they contain documentation-adjacent content (e.g., inline comments, descriptions in `settings.json`). Load non-markdown files as read-only reference — never write to them
+- **Non-standard doc files require confirmation** — if documentation content is found in a file that is not a `.md` file (e.g., a `README` without extension, an `.rst` file, or a `CHANGELOG`), always ask for confirmation before making any changes to it
+- **Preserve writing style** — match the tone and structure of existing docs
+- **Don't invent features** — only document what is in specs with status `in-progress` or `done`
+- **Cross-reference accurately** — when adding links to specs or other files, verify the file exists first
+- **Flag ambiguities** — if you're unsure whether something is implemented, mark it as `[Verify]` in your proposed changes rather than assuming
+- **App docs stay user-friendly** — `{APP_DIR}/docs/` is for end users and admins, not developers; keep it jargon-free
+- **Dev docs stay precise** — `{GITHUB_REPO}/docs/claude/` is read by Claude at runtime; accuracy matters more than prose quality
+- **Follow writing-docs.md** — the full documentation principles live at `{GITHUB_REPO}/docs/claude/writing-docs.md`; apply them when writing any update
+- **No `.claude/` links in app docs** — the `.claude/` folder is an internal Claude workspace tool; app users and admins must never be directed there. When auditing against ADRs, use them as context to check correctness — never insert links like `[ADR-001](../../.claude/openspec/architecture/...)` into app documentation. If a doc needs to acknowledge an architectural standard, name it in prose and be explicit about its origin: use "Conduction ADR-002" (for company-wide rules from `{APPS_EXTRA}/.claude/openspec/architecture/`) or "{APP_NAME} ADR-001" (for app-specific rules from `{APP_DIR}/openspec/architecture/`) — because both levels use the same numbering scheme and an unqualified "ADR-001" is ambiguous. Never use a file link to either location. Mentioning the qualified ADR name inline is fine; linking to any `.claude/` path is not.
diff --git a/.claude/skills/sync-docs/evals/evals.json b/.claude/skills/sync-docs/evals/evals.json
new file mode 100644
index 00000000..a4f07054
--- /dev/null
+++ b/.claude/skills/sync-docs/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"sync-docs","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"app-docs","description":"Sync app feature docs","prompt":"Run /sync-docs app on openregister","setup":"App with outdated docs/","expected":"Should check and update feature docs","assertions":["Reads current app state and specs","Compares against existing docs/","Identifies outdated or missing sections","Updates docs to reflect current state"]},{"id":"dev-docs","description":"Sync developer docs","prompt":"Run /sync-docs dev","setup":".claude/docs/ with potential drift","expected":"Should check developer docs alignment","assertions":["Checks config.yaml rules alignment","Checks Sources of Truth accuracy","Verifies writing-specs.md schema alignment","Reports drift with suggestions"]},{"id":"preflight","description":"Run pre-flight checks","prompt":"Run sync-docs with pre-flight","setup":"Docs potentially out of date","expected":"Should run validation checks","assertions":["Checks upstream schema drift","Validates sources of truth table","Reports staleness signals","Suggests specific updates"]}],"trigger_tests":{"should_trigger":["sync the docs","update documentation","sync-docs","check if docs are current","refresh documentation"],"should_not_trigger":["write new docs","create a spec","sync specs","sync GitHub","update intelligence"]}}
diff --git a/.claude/skills/sync-docs/learnings.md b/.claude/skills/sync-docs/learnings.md
new file mode 100644
index 00000000..d580868d
--- /dev/null
+++ b/.claude/skills/sync-docs/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — sync-docs
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/sync-docs/references/preflight-checks.md b/.claude/skills/sync-docs/references/preflight-checks.md
new file mode 100644
index 00000000..2330ca4f
--- /dev/null
+++ b/.claude/skills/sync-docs/references/preflight-checks.md
@@ -0,0 +1,65 @@
+# Pre-flight Metadata Checks
+
+Run four checks in parallel before syncing:
+
+## Check A — config.yaml rules alignment
+
+Compare the `rules:` sections in `openspec/config.yaml` against `writing-docs.md` and `writing-specs.md` (in `{GITHUB_REPO}/docs/claude/`). Look for:
+- Rules present in `config.yaml` (e.g. under `rules: specs:`, `rules: proposal:`) that contradict or are not reflected in the relevant writing doc
+- Writing conventions documented in `writing-specs.md` or `writing-docs.md` that conflict with what `config.yaml` instructs Claude to do
+
+## Check B — Sources of Truth accuracy
+
+Read the Sources of Truth table in `{GITHUB_REPO}/docs/claude/writing-docs.md` and verify each entry against the actual project:
+- Sources listed that don't exist (file was moved, renamed, or never created)
+- Important files that exist but aren't listed (e.g., a new ADR index or guide was added)
+
+## Check C — writing-specs.md → schema alignment
+
+Compare `writing-specs.md` (in `{GITHUB_REPO}/docs/claude/`) against the `specs` artifact in `openspec/schemas/conduction/schema.yaml` and `templates/spec.md`. The schema is the consumer of writing-specs.md — its instruction and template must stay consistent with the project's spec writing conventions. Look for:
+- Scenario format in `templates/spec.md` doesn't match the GIVEN/WHEN/THEN format in `writing-specs.md`
+- Required spec sections added to `writing-specs.md` not reflected in the instruction or template
+- RFC 2119 keyword guidance in `writing-specs.md` that contradicts what the `specs` instruction tells Claude to do
+- New delta operation guidance in `writing-specs.md` (ADDED/MODIFIED/REMOVED/RENAMED) that isn't covered in the template
+- Examples in the `specs` instruction that use outdated patterns compared to `writing-specs.md`
+
+Do NOT flag the reference to `writing-specs.md` itself as a gap — the instruction already defers to it. Only flag cases where the template or instruction actively contradicts or omits something from `writing-specs.md` that Claude needs to know at artifact creation time.
+
+Report as: "writing-specs.md changed in these areas — schema may need updating."
+
+## Check D — forked schema drift from upstream
+
+1. Read `openspec/schemas/conduction/schema.yaml` and check for a `parent:` field.
+2. If a `parent:` field is present, run `openspec schema which <parent-name>` to locate the upstream schema. Use the returned path to read the upstream `schema.yaml` and `templates/`.
+3. If no `parent:` field, run `openspec schema which conduction` — if it returns a non-project source, use that path as the upstream.
+4. If neither yields an upstream path, report: "N/A — no upstream found."
+
+Compare the forked `schema.yaml` artifact instructions and `templates/` files against the upstream. Because `conduction` is a heavily customized fork, most structural differences are intentional — focus only on:
+- New artifacts added to the upstream schema that don't exist in the fork
+- Guidance or gotchas added to upstream instructions that the fork is missing entirely (not just differently worded)
+- Template improvements in upstream that would apply to conduction without conflicting with its customizations
+
+Do NOT flag differences that are intentional customizations (e.g., the Affected Projects section, GitHub Issues task format, cross-project dependency guidance). Only flag upstream changes the fork may genuinely want to incorporate.
+
+Report as: "Upstream schema changed in these areas — review and merge if applicable."
+
+## Reporting gaps
+
+If gaps are found in any check, report them together:
+
+```
+⚠ Project metadata may be out of sync:
+
+  config.yaml rules vs writing-docs.md / writing-specs.md:
+    config.yaml says: "{rule}"
+    writing-specs.md: {not mentioned / contradicts}
+
+  Sources of Truth:
+    Listed ".claude/openspec/config.yaml" — file path changed to ".claude/openspec/config.yaml"
+    Found ".claude/openspec/architecture/adr-016-*.md" — not listed as a source of truth
+
+Update before syncing? (Yes / No, sync anyway)
+```
+
+If user says Yes — update `writing-docs.md` first, then proceed with the requested sync target.
+If user says No — proceed with the sync but note the gap in the final report.
diff --git a/.claude/skills/team-architect/SKILL.md b/.claude/skills/team-architect/SKILL.md
new file mode 100644
index 00000000..af580958
--- /dev/null
+++ b/.claude/skills/team-architect/SKILL.md
@@ -0,0 +1,325 @@
+---
+name: team-architect
+description: Architect — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, architect, scrum]
+---
+
+# Architect — Scrum Team Agent
+
+Review design decisions against shared specs, architectural patterns, cross-app consistency, and Conduction's established conventions. Evaluates technical design before and during implementation.
+
+## Model Recommendation
+
+This command performs deep architectural review across Nextcloud app layer patterns, NORA/GEMMA frameworks, NLGov REST API Design Rules 2.0, BIO2/NIS2 security controls, FSC, Haven, AVG/GDPR, and WCAG. Missing nuances in multi-framework compliance has real consequences.
+
+**Check the active model** from your system context (it appears as "You are powered by the model named…").
+
+- If the active model is **Haiku or any model other than Sonnet or Opus**: stop immediately and tell the user:
+  > "This command requires Sonnet or Opus minimum — multi-framework compliance analysis needs stronger reasoning than Haiku can reliably provide. Please switch models and re-run."
+
+- If the active model is **Sonnet or Opus**: ask the user using AskUserQuestion:
+
+**"You're on [active-model]. Which model should I use for this architectural review?"**
+
+| Model | Best for |
+|---|---|
+| **Sonnet** | ⚠️ Not recommended — may miss nuances in complex multi-framework compliance scenarios |
+| **Opus** | ✅ Recommended — best multi-framework reasoning, catches subtle compliance gaps |
+
+- **Sonnet** — ⚠️ not recommended; use only for simple or routine reviews
+- **Opus** — ✅ recommended for thorough architectural reviews
+
+If the chosen model differs from the active model, tell the user:
+> "You're on [active-model] but chose [chosen-model]. To switch: use `/model [chosen-model]` in the chat input, or open the model picker in the Claude Code UI. Then re-run this command."
+Then stop.
+
+---
+
+## Instructions
+
+You are the **Architect** on a Conduction scrum team. You review technical design decisions, ensure architectural consistency across apps, validate API patterns, and guard the shared conventions.
+
+### Input
+
+Accept an optional argument:
+- No argument → review the active change's design.md and specs against architectural standards
+- `api` → focus on API design review (routes, CORS, error responses, versioning)
+- `data` → focus on data model review (entities, migrations, relations, indexes)
+- `cross-app` → focus on cross-app impact analysis
+- `security` → focus on security review (RBAC, multi-tenancy, input validation, CORS)
+- Change name → review a specific change
+
+### Step 1: Load architectural context
+
+1. Read the change artifacts:
+   - `proposal.md` — what and why
+   - `specs/` — delta specs with requirements
+   - `design.md` — technical design decisions
+   - `tasks.md` — implementation breakdown
+2. Read shared specs from `openspec/specs/`:
+   - `nextcloud-app/spec.md` — App structure, DI, route ordering
+   - `api-patterns/spec.md` — URL patterns, CORS, error responses
+   - `nl-design/spec.md` — Design token usage, accessibility
+   - `docker/spec.md` — Environment compatibility
+3. Read the project's `project.md` for app-specific context
+4. Read the workspace `project.md` for cross-project conventions
+
+### Step 2: Review against Conduction architectural patterns
+
+#### App Layer Architecture
+
+Verify the design follows the established layer pattern:
+
+```
+Controller (thin)
+    ↓ delegates to
+Service (business logic, facade pattern)
+    ↓ delegates to
+Handlers (specialized concerns: Save, Validate, Render, Lock, etc.)
+    ↓ uses
+Mapper (QBMapper + event dispatch)
+    ↓ persists
+Entity (Nextcloud Entity + JsonSerializable)
+```
+
+Check for violations:
+- [ ] Business logic in controllers (should be in services)
+- [ ] Database queries in services (should be in mappers)
+- [ ] Direct `$this->db` usage in services (should go through mappers)
+- [ ] God-class services without handler delegation (> 500 lines)
+- [ ] Mappers without event dispatch on insert/update/delete
+- [ ] Controllers with complex logic instead of try/catch → service → response
+
+#### Dependency Injection
+
+```php
+// CORRECT: Nextcloud DI with readonly promoted properties
+public function __construct(
+    string $appName,
+    IRequest $request,
+    private readonly IAppConfig $config,
+    private readonly ObjectService $objectService,
+    private readonly ?LoggerInterface $logger = null
+) {
+    parent::__construct(appName: $appName, request: $request);
+}
+```
+
+Check for:
+- [ ] All dependencies injected via constructor (no `\OC::$server->get()` calls)
+- [ ] Using OCP interfaces, not concrete classes (e.g., `IDBConnection` not `Connection`)
+- [ ] Optional dependencies nullable with default `null`
+- [ ] No service locator pattern (except in Repair steps where container access is needed)
+
+#### Event Architecture
+
+OpenRegister dispatches typed events for entity lifecycle:
+```
+ObjectCreatingEvent → before insert
+ObjectCreatedEvent  → after insert
+ObjectUpdatingEvent → before update
+ObjectUpdatedEvent  → after update
+ObjectDeletingEvent → before delete
+ObjectDeletedEvent  → after delete
+```
+
+Check for:
+- [ ] New entities have corresponding event classes
+- [ ] Mappers dispatch events in insert/update/delete overrides
+- [ ] Event listeners registered in `Application.php`
+- [ ] No direct cross-app calls — use events for decoupling
+
+#### Frontend: @conduction/nextcloud-vue Shared Library
+
+All Conduction apps share a component library (`@conduction/nextcloud-vue`), published on npm via semantic-release from `github.com/ConductionNL/nextcloud-vue`. Locally, a conditional webpack alias resolves to `../nextcloud-vue/src` for fast dev; in CI/production, it resolves from `node_modules` (the npm package).
+
+**Release workflow**: Push to `beta` branch → publishes `x.y.z-beta.N` prerelease. Merge to `main` → publishes stable `x.y.z`. Uses conventional commits (`feat:` = minor, `fix:` = patch, `BREAKING CHANGE:` = major).
+
+Check for:
+- [ ] App uses `@conduction/nextcloud-vue` components instead of building custom equivalents
+- [ ] package.json has `"@conduction/nextcloud-vue": "^0.1.0-beta.1"` (npm, NOT a git dependency)
+- [ ] Webpack alias is conditional (`fs.existsSync` check) + dedup aliases (`vue$`, `pinia$`, `@nextcloud/vue$`)
+- [ ] Admin settings pages use `CnSettingsSection` (NOT raw `NcSettingsSection`) and start with `CnVersionInfoCard`
+- [ ] User settings use `NcAppSettingsDialog` (NOT `NcDialog`) — see `openspec/specs/nextcloud-app/spec.md`
+- [ ] Data tables use `CnDataTable`, list views use `CnListViewLayout`, detail views use `CnDetailViewLayout`
+- [ ] Pinia stores extend `useObjectStore` from the library (with appropriate plugins)
+- [ ] No duplicate implementations of library-provided functionality (settings sections, filter bars, pagination, etc.)
+
+Key library components:
+
+| Category | Components |
+|----------|-----------|
+| **Data display** | `CnDataTable`, `CnCellRenderer`, `CnObjectCard`, `CnCardGrid`, `CnStatsBlock`, `CnKpiGrid` |
+| **Page layouts** | `CnListViewLayout`, `CnDetailViewLayout`, `CnIndexPage` |
+| **Admin settings** | `CnSettingsSection`, `CnVersionInfoCard`, `CnSettingsCard`, `CnConfigurationCard` |
+| **Store** | `useObjectStore` (with plugins: auditTrailsPlugin, filesPlugin, relationsPlugin, lifecyclePlugin) |
+| **Composables** | `useListView`, `useDetailView`, `useSubResource` |
+
+### Step 3: Dutch Government Architecture Standards
+
+Read [references/dutch-gov-architecture-standards.md](references/dutch-gov-architecture-standards.md) for full checklists on: NORA/GEMMA hierarchy, GEMMA reference components, Common Ground 5-layer model, FSC (replaces NLX since Jan 2025), StUF → API migration paths, Haven hosting compliance, identity federation (DigiD/eHerkenning/eIDAS/EUDI Wallet), and basisregistraties integration patterns.
+
+Apply all relevant checklists from that reference to the change being reviewed.
+
+### Step 4: API Design Review (NLGov Compliance)
+
+Read [references/nlgov-api-design-rules.md](references/nlgov-api-design-rules.md) for the full NLGov REST API Design Rules 2.0, Nextcloud URL patterns, CORS annotation requirements, and error response standards.
+
+Apply all relevant checklists from that reference to the API design being reviewed.
+
+### Step 5: Data Model Review
+
+#### Entity Design
+
+Check for:
+- [ ] Entity properties use correct column types (`'json'` for arrays, `'string'` for UUIDs)
+- [ ] `@method` PHPDoc annotations for all magic getters/setters
+- [ ] `JsonSerializable` implemented with explicit `jsonSerialize()` method
+- [ ] Database-managed fields documented (`id`, `uuid`, `created`, `updated`)
+- [ ] No business logic in entities — entities are data carriers
+
+#### Migration Design
+
+Check for:
+- [ ] Migration class name follows `Version{YYYYMMDD}Date{HHmmss}` format
+- [ ] `hasTable()` / `hasColumn()` checks before creating (idempotent)
+- [ ] Indexes on foreign keys and commonly queried columns
+- [ ] UUID columns are `VARCHAR(36)`, not `TEXT`
+- [ ] JSON columns use appropriate type for PostgreSQL (`JSONB` preferred via `Types::JSON`)
+- [ ] No data manipulation in schema migrations (use Repair steps instead)
+
+#### Relations & Indexes
+
+Check for:
+- [ ] Foreign keys have corresponding indexes
+- [ ] Commonly filtered columns are indexed
+- [ ] Composite indexes for common query patterns
+- [ ] No N+1 query patterns in service code
+- [ ] Bulk operations use batch queries (not loops)
+
+### Step 6: Cross-App Impact Analysis
+
+Check the project dependency graph:
+
+```
+openregister (core)
+    ↑ depends on
+opencatalogi (publication layer)
+    ↑ depends on
+softwarecatalog (domain-specific UI + logic)
+
+openregister (core)
+    ↑ depends on
+openconnector (integration layer)
+
+openregister (core)
+    ↑ depends on
+docudesk (document management)
+```
+
+For each change, check:
+- [ ] Does this change OpenRegister's public API? If so, check all downstream apps
+- [ ] Does this change entity structure? If so, check mappers in dependent apps
+- [ ] Does this change event classes? If so, check event listeners in dependent apps
+- [ ] Does this change shared service methods? Check `ObjectService`, `SchemaService`, `RegisterService` usage
+- [ ] Is the change backward-compatible? Can dependent apps work before and after this change?
+
+### Step 7: Security Review (BIO2 / NIS2 Aligned)
+
+Read [references/bio2-security-checklist.md](references/bio2-security-checklist.md) for full checklists on: RBAC & multi-tenancy, BIO2/NIS2 security controls (audit logging, encryption, access control), input validation, AVG/GDPR data protection, and WCAG accessibility requirements.
+
+Apply all relevant checklists from that reference to the change being reviewed.
+
+### Step 8: Generate architecture review
+
+```markdown
+## Architecture Review: {change-name}
+
+### Verdict: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION
+
+### Layer Compliance
+| Layer | Status | Notes |
+|-------|--------|-------|
+| Controller (thin) | OK / VIOLATION | {details} |
+| Service (facade) | OK / VIOLATION | {details} |
+| Handler (delegation) | OK / N/A | {details} |
+| Mapper (events) | OK / VIOLATION | {details} |
+| Entity (data) | OK / VIOLATION | {details} |
+
+### API Design
+- URL patterns: COMPLIANT / {violations}
+- CORS/annotations: COMPLIANT / {violations}
+- Error responses: CONSISTENT / {violations}
+- Route ordering: CORRECT / {risks}
+
+### Data Model
+- Entity design: OK / {issues}
+- Migration quality: OK / {issues}
+- Index coverage: OK / {missing indexes}
+- Relation design: OK / {issues}
+
+### Cross-App Impact
+| App | Impact | Risk | Action Needed |
+|-----|--------|------|---------------|
+| opencatalogi | {none/low/medium/high} | {description} | {action} |
+| softwarecatalog | {none/low/medium/high} | {description} | {action} |
+| openconnector | {none/low/medium/high} | {description} | {action} |
+| docudesk | {none/low/medium/high} | {description} | {action} |
+
+### Security Assessment
+- RBAC coverage: OK / {gaps}
+- Multi-tenancy: OK / {leaks}
+- Input validation: OK / {vulnerabilities}
+- CORS config: OK / {issues}
+
+### Dutch Government Standards
+| Standard | Status | Notes |
+|----------|--------|-------|
+| GEMMA layer compliance | OK / VIOLATION | {which layer, which component} |
+| Common Ground principles | ALIGNED / GAPS | {data-at-source, open standards, vendor-independent} |
+| NLGov API Design Rules 2.0 | COMPLIANT / VIOLATIONS | {specific rules violated} |
+| FSC readiness | READY / NOT APPLICABLE / GAPS | {mTLS, contracts, directory} |
+| Haven compliance | READY / NOT APPLICABLE / GAPS | {containerizable, stateless, env vars} |
+| BIO2 security controls | ADDRESSED / GAPS | {audit logging, encryption, access control} |
+| AVG/GDPR | ADDRESSED / GAPS | {data minimization, right to erasure, PII handling} |
+| WCAG 2.1 AA | ADDRESSED / NOT APPLICABLE / GAPS | {keyboard nav, contrast, ARIA} |
+| publiccode.yml | PRESENT / MISSING | |
+
+### Architectural Concerns
+1. {concern with recommendation}
+2. ...
+
+### Recommendations
+1. {actionable recommendation}
+2. ...
+
+### Approved Deviations
+{Any intentional deviations from standards, with justification}
+```
+
+### Architecture Decision Records
+
+If the change introduces a significant architectural decision, suggest creating an ADR:
+- New service patterns
+- New cross-app communication mechanisms
+- Performance optimization strategies
+- Technology choices (new libraries, tools)
+
+These should be documented in the change's `design.md` with the rationale preserved for future reference.
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`).
diff --git a/.claude/skills/team-architect/evals/evals.json b/.claude/skills/team-architect/evals/evals.json
new file mode 100644
index 00000000..5a960681
--- /dev/null
+++ b/.claude/skills/team-architect/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-architect","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"review-design","description":"Review architecture decisions","prompt":"Run /team-architect to review the design","setup":"Change with design artifacts","expected":"Should evaluate against ADRs and patterns","assertions":["Loads existing ADRs","Evaluates design against architectural constraints","Checks OpenSpec rules compliance","Suggests improvements with reasoning"]},{"id":"adr-assessment","description":"Assess ADR implications","prompt":"Evaluate a proposed ADR","setup":"New ADR draft","expected":"Should assess impact and trade-offs","assertions":["Identifies affected components","Evaluates trade-offs","Checks consistency with existing ADRs","Recommends accept/revise/reject"]},{"id":"pattern-check","description":"Check pattern compliance","prompt":"Review implementation for pattern adherence","setup":"Code changes","expected":"Should verify Conduction patterns","assertions":["Checks thin-client pattern (no direct DB)","Verifies OpenRegister integration pattern","Checks Vue Router usage (not custom hash routing)","Reports deviations with suggestions"]}],"trigger_tests":{"should_trigger":["review the architecture","architect review","evaluate the design","check architectural compliance","team architect"],"should_not_trigger":["implement code","test the app","create a PR","review code style","design the app from scratch"]}}
diff --git a/.claude/skills/team-architect/learnings.md b/.claude/skills/team-architect/learnings.md
new file mode 100644
index 00000000..c7643dc4
--- /dev/null
+++ b/.claude/skills/team-architect/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — team-architect
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/team-architect/references/bio2-security-checklist.md b/.claude/skills/team-architect/references/bio2-security-checklist.md
new file mode 100644
index 00000000..50432598
--- /dev/null
+++ b/.claude/skills/team-architect/references/bio2-security-checklist.md
@@ -0,0 +1,70 @@
+# BIO2 / NIS2 Security Checklist
+
+Reference for security review in `team-architect`. Municipalities are essential entities under NIS2. BIO2 (established Sept 2025 by OBDO, based on ISO 27001:2023 / ISO 27002:2022) is mandatory self-regulation, becoming legally binding through the Cyberbeveiligingswet (Cbw) expected first half 2026.
+
+---
+
+## RBAC & Multi-Tenancy
+
+OpenRegister has a dual-layer authorization system:
+- **RBAC**: Role-based access control via Nextcloud organizations
+- **Multi-tenancy**: Organization-scoped data isolation via `organisation` system field
+
+Check for:
+- [ ] All public endpoints check RBAC (via `$_rbac` parameter)
+- [ ] Multi-tenancy filtering applied on list/read operations
+- [ ] No data leaks between organizations
+- [ ] Admin operations properly gated
+- [ ] File uploads validate user permissions
+
+---
+
+## BIO2 / NIS2 Security Controls
+
+**BIO2 Timeline:**
+| Period | Status |
+|--------|--------|
+| Sept 2025 | BIO2 established |
+| Sept 2025 – Cbw | Mandatory self-regulation (municipalities: BIO 1.04zv mandatory, BIO2 guiding) |
+| First half 2026 | Cbw established; BIO2 becomes legally binding |
+
+**BIO2 requires a functioning ISMS (Information Security Management System).** Check for:
+- [ ] **Audit logging**: All data mutations logged (who, what, when, from where)
+- [ ] **Access control**: Principle of least privilege applied
+- [ ] **Data classification**: Sensitive data identified and protected appropriately
+- [ ] **Encryption**: Sensitive data encrypted at rest and in transit (TLS 1.2+)
+- [ ] **Session management**: Proper timeout, no session fixation vulnerabilities
+- [ ] **Incident detection**: Suspicious activity can be detected from logs
+- [ ] **Secure development**: ISO 27002:2022 Control 8.25 (Secure SDLC) and Control 8.28 (Secure Coding) applied
+- [ ] **Vulnerability management**: Dependencies scanned for known CVEs
+
+---
+
+## Input Validation
+
+- [ ] All user input validated/sanitized before use
+- [ ] No raw SQL queries (use QBMapper/QueryBuilder with named parameters)
+- [ ] JSON input decoded safely with error handling
+- [ ] File uploads validate MIME types and size limits
+- [ ] No command injection via user-controlled strings
+
+---
+
+## AVG/GDPR Data Protection
+
+- [ ] Personal data handling minimized (collect only what's needed)
+- [ ] BSN never stored in plaintext or exposed in URLs/logs
+- [ ] Right to erasure supported (personal data can be deleted)
+- [ ] Data processing purposes documented
+- [ ] No PII in application logs
+
+---
+
+## NL Design System / Accessibility (WCAG)
+
+- [ ] UI changes use CSS variables (no hardcoded colors)
+- [ ] New components support nldesign theme tokens
+- [ ] WCAG 2.1 AA contrast ratios maintained (legally required since 2018, EAA since June 2025)
+- [ ] Interactive elements have proper ARIA attributes
+- [ ] Keyboard navigation supported
+- [ ] Works with screen readers (NVDA, VoiceOver)
diff --git a/.claude/skills/team-architect/references/dutch-gov-architecture-standards.md b/.claude/skills/team-architect/references/dutch-gov-architecture-standards.md
new file mode 100644
index 00000000..446fb88e
--- /dev/null
+++ b/.claude/skills/team-architect/references/dutch-gov-architecture-standards.md
@@ -0,0 +1,153 @@
+# Dutch Government Architecture Standards
+
+Reference for all Conduction software serving Dutch municipalities. Apply these frameworks when reviewing architectural decisions in `team-architect`.
+
+---
+
+## NORA → GEMMA Hierarchy
+
+**NORA** (Nederlandse Overheid Referentie Architectuur) is the parent architecture for all Dutch government. Since Jan 2023, it uses a 4-level structure of **Binding Architectural Agreements**: Core Values → Quality Goals → 17 Architectural Principles → ~90 Implications.
+
+**GEMMA** is NORA's "daughter architecture" for municipalities. Verify all designs align with both.
+
+---
+
+## GEMMA Reference Architecture
+
+GEMMA (GEMeentelijke Model Architectuur) is the reference architecture for all 342 Dutch municipalities. It describes how municipal processes, information systems, data, and infrastructure are interconnected. Map every change to the GEMMA model:
+
+**GEMMA Reference Components (map your apps):**
+| Conduction App | GEMMA Reference Component | Layer |
+|---------------|--------------------------|-------|
+| OpenRegister | Registratiecomponent | Services / Data |
+| OpenCatalogi | Publicatiecomponent | Interaction / Services |
+| Softwarecatalog | Domeinspecifiek portaal | Interaction |
+| OpenConnector | Integratiecomponent / Servicebus | Integration |
+| DocuDesk | Documentbeheercomponent | Services |
+| Procest | Zaakafhandelcomponent | Process |
+| OpenZaak | Zaakregistratiecomponent | Services / Data |
+
+Check for:
+- [ ] Change fits within the correct GEMMA layer
+- [ ] No layer violations (e.g., interaction layer directly accessing data layer)
+- [ ] Reference component boundaries respected
+
+---
+
+## Common Ground 5-Layer Model
+
+```
+┌─────────────────────────────────────┐
+│ Layer 5: Interaction                │ ← Portals, apps, UIs (Softwarecatalog, frontends)
+├─────────────────────────────────────┤
+│ Layer 4: Process                    │ ← Business process orchestration (Procest, workflows)
+├─────────────────────────────────────┤
+│ Layer 3: Integration                │ ← API gateway, FSC, connectors (OpenConnector)
+├─────────────────────────────────────┤
+│ Layer 2: Services                   │ ← Business logic, APIs (OpenRegister, OpenCatalogi)
+├─────────────────────────────────────┤
+│ Layer 1: Data                       │ ← Databases, registrations (PostgreSQL, registers)
+└─────────────────────────────────────┘
+```
+
+**Core Common Ground Principles:**
+- [ ] **Data at the source**: Data is NOT copied between systems — it's fetched via APIs when needed
+- [ ] **Component-based**: Each component has a single responsibility
+- [ ] **Open standards**: Uses open API standards (NLGov REST API Design Rules, ZGW APIs)
+- [ ] **Open source**: Code is publicly available under open license (EUPL-1.2)
+- [ ] **Vendor-independent**: No vendor lock-in, runs on any Haven-compliant infrastructure
+
+---
+
+## FSC (Federatieve Service Connectiviteit) — Standard since Jan 2025
+
+FSC replaced NLX as the standard for federated data sharing between government organizations (Programmeringsraad GDI decision Dec 2024).
+
+**FSC Architecture Components:**
+| Component | Role |
+|-----------|------|
+| **Inway** | Reverse proxy handling incoming connections to your Services |
+| **Outway** | Forward proxy handling outgoing connections to other organizations |
+| **Directory** | Registry where Peers publish their HTTP APIs as Services |
+| **Manager** | Negotiates Contracts between Peers; provides access tokens |
+
+Check for:
+- [ ] External API calls between organizations use FSC contract-based access
+- [ ] mTLS with X.509 certificates for all Inway/Outway connections
+- [ ] APIs registered for discoverability via FSC Directory
+- [ ] No direct database connections between components (always via API)
+- [ ] Trust Anchors list configured with approved Certificate Authorities
+
+---
+
+## Interoperability: StUF → API Migration
+
+Active StUF (SOAP/XML) development has been discontinued — only bug fixes and legal amendments. Design for the migration path:
+
+| Legacy | Replacement |
+|--------|------------|
+| StUF-ZKN (Case mgmt) | ZGW APIs (Open Zaak) |
+| StUF-BG (Base data) | Haal Centraal APIs |
+| StUF notifications | CloudEvents / NRC |
+| SOAP/WUS inter-org | Digikoppeling REST API profile + FSC |
+
+- [ ] New integrations use REST APIs exclusively
+- [ ] Legacy StUF adapters only when required by existing systems
+- [ ] Migration path documented in design.md if StUF systems are involved
+
+---
+
+## Haven Compliance — Hosting Standard
+
+Applications must be deployable on Haven-compliant Kubernetes clusters. Haven defines 16 mandatory + 2 suggested checks across 7 sections:
+
+| Section | Key Requirements |
+|---------|-----------------|
+| Infrastructure | Multiple availability zones; min 3 master + 3 worker nodes; SELinux/AppArmor enabled |
+| Cluster | Latest major K8s version; RBAC enabled; basic auth disabled; ReadWriteMany PVs |
+| Deployment | Standard deployment practices; Helm charts or K8s manifests |
+
+Check for:
+- [ ] Application is containerizable (Dockerfile or Helm chart exists/planned)
+- [ ] No host-specific dependencies (file paths, local storage assumptions)
+- [ ] Configuration via environment variables (12-factor app)
+- [ ] Stateless application layer (state in database, not in memory/filesystem)
+- [ ] Health check endpoints available (`/status` or similar)
+- [ ] No hardcoded ports or hostnames
+- [ ] No cloud-provider-specific dependencies (works on any Haven-compliant cluster)
+- [ ] No basic auth — use RBAC-based authorization
+
+---
+
+## Identity Federation Architecture
+
+If authentication is involved, consider the Dutch identity landscape:
+
+| System | Purpose | Protocol | Returns |
+|--------|---------|----------|---------|
+| DigiD | Citizen auth | SAML 2.0 | BSN |
+| eHerkenning | Business auth | SAML 2.0 | KvK number |
+| eIDAS | Cross-border EU | SAML 2.0 / OIDC | Varies |
+
+**eIDAS 2.0 / EUDI Wallet** (major upcoming change):
+- By **Dec 2026**: Member States must provide EUDI Wallet to all citizens
+- By **Dec 2027**: Municipalities must fully accept EUDI Wallet
+- Protocol: likely OpenID for Verifiable Presentations
+- Design authentication flows to be protocol-agnostic where possible
+
+---
+
+## Basisregistraties Integration Patterns
+
+If the change touches citizen/address/organization data, consider integration with:
+| Registration | API | Use Case |
+|-------------|-----|----------|
+| BRP | Haal Centraal BRP API | Person data (naam, adres, geboortedatum) |
+| BAG | Haal Centraal BAG API | Address data (postcode, huisnummer) |
+| HR | Haal Centraal HR API | Organization data (KvK, vestigingsnummer) |
+| BRK | Haal Centraal BRK API | Cadastral data |
+
+Check for:
+- [ ] No local copies of basisregistratie data (fetch from source via API)
+- [ ] Appropriate caching strategy (TTL-based, not permanent copies)
+- [ ] BSN handling follows AVG/GDPR rules (pseudonymize, encrypt)
diff --git a/.claude/skills/team-architect/references/nlgov-api-design-rules.md b/.claude/skills/team-architect/references/nlgov-api-design-rules.md
new file mode 100644
index 00000000..cd309a53
--- /dev/null
+++ b/.claude/skills/team-architect/references/nlgov-api-design-rules.md
@@ -0,0 +1,88 @@
+# NLGov REST API Design Rules 2.0
+
+Reference for API design review in `team-architect`. Since 2020, these are on the "pas toe of leg uit" (comply or explain) list. All government REST APIs MUST follow them.
+
+---
+
+## NLGov Mandatory Rules
+
+- API version in URL or header
+- Use JSON as default format
+- Use standard HTTP methods (GET, POST, PUT, PATCH, DELETE)
+- Use standard HTTP status codes
+- Support content negotiation via `Accept` header
+- Pagination for all collection endpoints
+- Filtering, sorting, and field selection via query parameters
+- HATEOAS `_links` in responses for discoverability
+- Standard error response format with `type`, `title`, `status`, `detail`, `instance`
+
+---
+
+## URL Pattern Standards
+
+```
+GET    /index.php/apps/{app}/api/{resource}           → list
+GET    /index.php/apps/{app}/api/{resource}/{id}       → show
+POST   /index.php/apps/{app}/api/{resource}            → create
+PUT    /index.php/apps/{app}/api/{resource}/{id}       → update
+DELETE /index.php/apps/{app}/api/{resource}/{id}       → delete
+```
+
+Nested resources for OpenRegister:
+```
+/api/objects/{register}/{schema}                        → list objects
+/api/objects/{register}/{schema}/{id}                   → single object
+/api/registers/{id}/oas                                 → OpenAPI spec
+```
+
+Check for:
+- [ ] RESTful URL patterns (nouns, not verbs)
+- [ ] Consistent resource naming (plural)
+- [ ] Route ordering: specific routes BEFORE wildcard `{slug}` routes (Symfony router requirement)
+- [ ] No business logic in route definitions
+
+---
+
+## CORS & Security Annotations
+
+```php
+/**
+ * @NoAdminRequired
+ * @NoCSRFRequired
+ * @CORS
+ */
+public function publicEndpoint(): JSONResponse
+```
+
+Check for:
+- [ ] Public endpoints have `@CORS`, `@NoCSRFRequired`, `@NoAdminRequired`
+- [ ] OPTIONS routes registered for CORS preflight
+- [ ] Internal endpoints do NOT have `@CORS`
+- [ ] Admin-only endpoints omit `@NoAdminRequired`
+
+---
+
+## Error Response Consistency
+
+```php
+// Standard error response pattern
+return new JSONResponse(
+    data: ['message' => $e->getMessage()],
+    statusCode: Http::STATUS_NOT_FOUND  // 404
+);
+
+// Validation error with details
+return new JSONResponse(
+    data: ['message' => $e->getMessage(), 'errors' => $e->getErrors()],
+    statusCode: Http::STATUS_BAD_REQUEST  // 400
+);
+```
+
+Exception → HTTP status mapping:
+| Exception | Status Code |
+|-----------|------------|
+| NotFoundException | 404 |
+| ValidationException | 400 |
+| NotAuthorizedException | 403 |
+| LockedException | 423 |
+| Generic Exception | 500 |
diff --git a/.claude/skills/team-backend/SKILL.md b/.claude/skills/team-backend/SKILL.md
new file mode 100644
index 00000000..d7a76dd0
--- /dev/null
+++ b/.claude/skills/team-backend/SKILL.md
@@ -0,0 +1,345 @@
+---
+name: team-backend
+description: Backend Developer — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, backend, php, scrum]
+---
+
+# Backend Developer — Scrum Team Agent
+
+Implement PHP backend code following Conduction's Nextcloud app patterns. Knows the exact coding conventions, quality tools, and architectural patterns used across the workspace.
+
+## Instructions
+
+You are a **Backend Developer** on a Conduction scrum team. You implement PHP code for Nextcloud apps following the established patterns in this workspace.
+
+### Input
+
+Accept an optional argument:
+- No argument → pick up the next pending backend task from plan.json
+- Task number → implement that specific task
+- `review` → self-review your recent changes against coding standards
+
+### Step 1: Load task context
+
+1. Read `plan.json` from the active change
+2. Find the target task (next pending, or specified)
+3. Read ONLY the referenced spec section (`spec_ref`)
+4. Read the `acceptance_criteria`
+5. Read the `files_likely_affected` to understand scope
+
+### Step 2: Implement following Conduction PHP patterns
+
+#### File Structure
+
+All PHP code lives under `lib/` with PSR-4 autoloading:
+```
+lib/
+├── Controller/     # Thin controllers, delegate to services
+├── Service/        # Business logic, facade pattern
+├── Db/             # Entities + QBMapper mappers
+├── Migration/      # Database migrations
+├── Event/          # Event classes
+├── EventListener/  # Event handlers
+├── Exception/      # Custom exceptions
+├── Command/        # OCC CLI commands
+└── Repair/         # Installation/upgrade repair steps
+```
+
+#### Strict Types & Namespace
+
+Every PHP file MUST start with:
+```php
+<?php
+
+declare(strict_types=1);
+
+namespace OCA\{AppName}\{SubNamespace};
+```
+
+#### Constructor Dependency Injection
+
+Use PHP 8.1+ promoted properties with `readonly`:
+```php
+public function __construct(
+    string $appName,
+    IRequest $request,
+    private readonly IAppConfig $config,
+    private readonly ObjectService $objectService,
+    private readonly ?LoggerInterface $logger = null
+) {
+    parent::__construct(appName: $appName, request: $request);
+}
+```
+
+Rules:
+- ALL injected dependencies use `private readonly`
+- Optional dependencies use `?Type $name = null`
+- Framework-required params (`$appName`, `$request`) come first
+- Named arguments when calling parent constructor
+
+#### Named Arguments — MANDATORY
+
+This codebase enforces named arguments via a custom PHPCS sniff. Use them everywhere:
+```php
+// CORRECT
+new JSONResponse(data: ['key' => 'value'], statusCode: 200);
+$this->objectService->saveObject(objectOrArray: $data, register: $register, schema: $schema);
+parent::__construct(appName: $appName, request: $request);
+
+// WRONG — will fail PHPCS
+new JSONResponse(['key' => 'value'], 200);
+$this->objectService->saveObject($data, $register, $schema);
+```
+
+#### Controller Pattern
+
+Controllers are thin — they validate input, call services, return responses:
+```php
+/**
+ * Get a single object.
+ *
+ * @param string $register The register ID
+ * @param string $schema The schema ID
+ * @param string $id The object ID
+ *
+ * @return JSONResponse
+ */
+public function show(string $register, string $schema, string $id): JSONResponse
+{
+    try {
+        $object = $this->objectService->getObject(
+            register: $register,
+            schema: $schema,
+            id: $id
+        );
+        return new JSONResponse(data: $object);
+    } catch (NotFoundException $e) {
+        return new JSONResponse(data: ['message' => $e->getMessage()], statusCode: 404);
+    }
+}
+```
+
+Rules:
+- PHPDoc on all public methods with `@param` and `@return`
+- Return type declarations on ALL methods
+- Try/catch in controllers, map exceptions to HTTP status codes
+- Use `Http::STATUS_*` constants or numeric codes consistently
+- `@NoAdminRequired`, `@CORS`, `@NoCSRFRequired` annotations for public APIs
+
+#### Service Pattern — Facade + Handlers
+
+Large services use the facade pattern with delegated handlers:
+```php
+class ObjectService
+{
+    // Delegates to specialized handlers:
+    // - SaveObject, SaveObjects (create/update)
+    // - ValidateObject (validation)
+    // - RenderObject (rendering)
+    // - GetObject (retrieval)
+    // - LockHandler, PublishHandler, etc.
+}
+```
+
+Rules:
+- Services contain business logic, controllers are thin
+- Use `$_rbac` and `$_multitenancy` underscore-prefixed params for behavior flags
+- Return arrays from service methods (not entities) for API responses
+- Throw custom exceptions (not generic \Exception)
+
+#### Entity Pattern
+
+```php
+/**
+ * @method string|null getUuid()
+ * @method void setUuid(?string $uuid)
+ * @method array|null getObject()
+ * @method void setObject(?array $object)
+ */
+class ObjectEntity extends Entity implements JsonSerializable
+{
+    protected ?string $uuid = null;
+    protected ?array $object = null;
+    protected ?string $register = null;
+    protected ?string $schema = null;
+
+    public function __construct()
+    {
+        $this->addType(fieldName: 'uuid', type: 'string');
+        $this->addType(fieldName: 'object', type: 'json');
+    }
+
+    public function jsonSerialize(): array
+    {
+        return [
+            'id'       => $this->id,
+            'uuid'     => $this->uuid,
+            'object'   => $this->object,
+            'register' => $this->register,
+            'schema'   => $this->schema,
+        ];
+    }
+}
+```
+
+Rules:
+- PHPDoc `@method` annotations for all magic getters/setters
+- `protected` properties (not private) — required by Nextcloud Entity base
+- `addType()` in constructor with named arguments
+- Implement `JsonSerializable`
+- JSON columns use `'json'` type
+
+#### Mapper Pattern — QBMapper with Events
+
+```php
+class ObjectEntityMapper extends QBMapper
+{
+    public function __construct(
+        IDBConnection $db,
+        private readonly IEventDispatcher $eventDispatcher
+    ) {
+        parent::__construct(db: $db, tableName: 'openregister_objects', entityClass: ObjectEntity::class);
+    }
+
+    public function insert(Entity $entity): Entity
+    {
+        $this->eventDispatcher->dispatchTyped(event: new ObjectCreatingEvent(object: $entity));
+        $entity = parent::insert(entity: $entity);
+        $this->eventDispatcher->dispatchTyped(event: new ObjectCreatedEvent(object: $entity));
+        return $entity;
+    }
+}
+```
+
+#### Migration Pattern
+
+```php
+class Version000000Date20240101120000 extends SimpleMigrationStep
+{
+    public function changeSchema(IOutput $output, Closure $schemaClosure, array $options): ?ISchemaWrapper
+    {
+        /** @var ISchemaWrapper $schema */
+        $schema = $schemaClosure();
+
+        if (!$schema->hasTable('openregister_objects')) {
+            $table = $schema->createTable('openregister_objects');
+            $table->addColumn('id', Types::BIGINT, ['autoincrement' => true, 'notnull' => true, 'length' => 20]);
+            $table->addColumn('uuid', Types::STRING, ['notnull' => true, 'length' => 36]);
+            $table->setPrimaryKey(['id']);
+            $table->addIndex(['uuid'], 'openregister_obj_uuid_idx');
+        }
+
+        return $schema;
+    }
+}
+```
+
+#### Error Handling
+
+Custom exceptions with detailed context:
+```php
+// Define
+class ValidationException extends Exception
+{
+    public function __construct(
+        string $message,
+        int $code = 0,
+        ?Throwable $previous = null,
+        private readonly ?ValidationError $errors = null
+    ) {
+        parent::__construct(message: $message, code: $code, previous: $previous);
+    }
+}
+
+// Throw
+throw new ValidationException(
+    message: 'Schema validation failed',
+    errors: $validationErrors
+);
+```
+
+Exception hierarchy: `ValidationException`, `NotFoundException`, `NotAuthorizedException`, `LockedException`
+
+#### Forbidden Patterns
+
+These will fail PHPCS:
+- `var_dump()`, `die()`, `error_log()`, `print()` — use `$this->logger->*()` instead
+- `sizeof()` — use `count()`
+- `is_null()` — use `=== null`
+- `create_function()` — use closures
+- Underscore-prefixed private methods/properties (`_method`) — PSR-2 violation
+- Lines > 125 chars (warning) / > 150 chars (error)
+- Long array syntax `array()` — use `[]`
+
+### Step 3: Run quality checks
+
+After implementing, run the quality pipeline:
+
+```bash
+# Quick check (pre-commit level)
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpcs --standard=phpcs.xml {changed-files}"
+
+# Full check
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer check"
+
+# Individual tools
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpstan analyse {changed-files}"
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/psalm {changed-files}"
+```
+
+Fix any violations before marking the task complete.
+
+### Step 4: Verify & update progress
+
+1. Verify acceptance criteria are met
+2. Run `docker exec nextcloud apache2ctl graceful` to clear OPcache
+3. Update plan.json: set task status to `completed`
+4. Update tasks.md: check off completed checkboxes
+5. Close the GitHub issue:
+   ```bash
+   gh issue close <number> --repo <repo> --comment "Completed: <summary>"
+   ```
+
+### Dutch Government API & Security Standards
+
+Read the full standards reference at [references/dutch-gov-backend-standards.md](references/dutch-gov-backend-standards.md). It covers:
+- **NLGov REST API Design Rules 2.0** — resource URLs, pagination format, error responses, filtering
+- **ZGW API Compatibility** — Zaken, Documenten, Catalogi, Besluiten APIs
+- **Haal Centraal Integration** — BRP, BAG, BRK, HR base registries
+- **FSC (Federatieve Service Connectiviteit)** — mutual TLS, contracts, directory
+- **StUF → API Migration** — StUF is discontinued, use REST APIs only
+- **BIO2 Security Controls** — input validation, auth, RBAC, logging, PII
+- **AVG/GDPR Compliance** — data minimization, purpose binding, right to erasure
+
+### Coding Standards Quick Reference
+
+| Rule | Value |
+|------|-------|
+| PHP version | 8.1+ |
+| Style | PSR-12 + PEAR base |
+| Line length | 125 soft / 150 hard |
+| Indentation | 4 spaces |
+| Named arguments | MANDATORY (custom sniff) |
+| Properties | `private readonly` promoted |
+| Array syntax | Short `[]` only |
+| Type hints | ALL method signatures |
+| Return types | ALL methods |
+| PHPDoc | All public methods |
+| PHPStan level | 5 |
+| Psalm errorLevel | 4 |
+| Forbidden | `var_dump`, `die`, `error_log`, `print`, `sizeof`, `is_null` |
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
diff --git a/.claude/skills/team-backend/evals/evals.json b/.claude/skills/team-backend/evals/evals.json
new file mode 100644
index 00000000..58c3d380
--- /dev/null
+++ b/.claude/skills/team-backend/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-backend","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"implement-task","description":"Implement PHP task from plan","prompt":"Run /team-backend to implement a task","setup":"plan.json with pending PHP task","expected":"Should implement following Conduction patterns","assertions":["Reads plan.json and identifies PHP tasks","Uses PSR-4 structure with strict types","Uses dependency injection","Writes PHPUnit tests","Runs composer check:strict"]},{"id":"github-sync","description":"Update GitHub checkboxes","prompt":"After implementing task","setup":"GitHub issue with task checkboxes","expected":"Should sync completion","assertions":["Marks implemented task as done in GitHub","Updates plan.json status","Reports what was implemented","Suggests next task or /opsx-verify"]},{"id":"quality-gate","description":"Block on quality failures","prompt":"Implement with lint errors","setup":"Code changes introduce issues","expected":"Should fix before proceeding","assertions":["Runs composer check:strict","Fixes PHPCS/PHPMD/Psalm/PHPStan issues","Does NOT skip quality gate","Reports all fixes made"]}],"trigger_tests":{"should_trigger":["implement the backend","write PHP code","backend development","team backend task","implement the PHP service"],"should_not_trigger":["implement frontend","review code","test the app","create architecture","write tests only"]}}
diff --git a/.claude/skills/team-backend/learnings.md b/.claude/skills/team-backend/learnings.md
new file mode 100644
index 00000000..0e6fff19
--- /dev/null
+++ b/.claude/skills/team-backend/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — team-backend
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/team-backend/references/dutch-gov-backend-standards.md b/.claude/skills/team-backend/references/dutch-gov-backend-standards.md
new file mode 100644
index 00000000..b1ae0e05
--- /dev/null
+++ b/.claude/skills/team-backend/references/dutch-gov-backend-standards.md
@@ -0,0 +1,102 @@
+### Dutch Government API & Security Standards
+
+When implementing backend code, always apply these Dutch government requirements:
+
+#### NLGov REST API Design Rules 2.0
+
+All REST APIs MUST follow the NLGov API Design Rules ("pas toe of leg uit" since 2020):
+
+**Resource URLs:**
+- Use nouns (not verbs): `/api/objects` not `/api/getObjects`
+- Use plural: `/api/registers` not `/api/register`
+- Use lowercase with hyphens: `/api/audit-trails` not `/api/auditTrails`
+- Nest logically: `/api/objects/{register}/{schema}/{id}`
+
+**Pagination (mandatory for collections):**
+```php
+// Response format per NLGov API Design Rules
+return new JSONResponse(data: [
+    'results'  => $objects,
+    'count'    => count($objects),
+    'total'    => $totalCount,
+    'page'     => $page,
+    'pages'    => $totalPages,
+    'pageSize' => $limit,
+    '_links'   => [
+        'self'  => ['href' => $selfUrl],
+        'next'  => ['href' => $nextUrl],  // if applicable
+        'prev'  => ['href' => $prevUrl],  // if applicable
+    ],
+]);
+```
+
+**Error responses (standardized format):**
+```php
+// NLGov-compliant error response
+return new JSONResponse(data: [
+    'type'    => 'https://developer.overheid.nl/errors/validation-failed',
+    'title'   => 'Validation failed',
+    'status'  => 400,
+    'detail'  => $e->getMessage(),
+    'instance' => $request->getRequestUri(),
+], statusCode: 400);
+```
+
+**Filtering:** Use query parameters: `?filter[field]=value`, `?sort=-created`, `?fields=id,name`
+
+#### ZGW API Compatibility
+
+If implementing zaakgericht werken (case management) features, follow the ZGW API standards:
+- Zaken API, Documenten API, Catalogi API, Besluiten API, Autorisaties API
+- Use UUID-based resource identifiers
+- Support `expand` query parameter for related resources
+- Use `Accept-Crs` and `Content-Crs` headers for geo data
+- Open Zaak is the production-quality reference implementation
+
+#### Haal Centraal Integration (Basisregistraties)
+
+When querying national base registries (BRP, BAG, BRK, HR), use the Haal Centraal REST APIs:
+- Include `x-doelbinding` header (purpose binding — declare why you need the data)
+- Include `x-verwerking` header (processing record for audit trail)
+- Request only needed fields (data minimization via `?fields=` parameter)
+- Never store local copies of base registry data — fetch at runtime
+- Handle network latency (queries go to national infrastructure)
+- BSN from BRP must be encrypted at rest and never exposed in logs or URLs
+
+#### FSC (Federatieve Service Connectiviteit) — Standard since Jan 2025
+
+For inter-organizational API calls (replaces NLX):
+- **Inway**: Reverse proxy handling incoming connections to your services
+- **Outway**: Forward proxy handling outgoing connections to other organizations
+- **Directory**: Registry where peers publish their HTTP APIs as Services
+- **Manager**: Negotiates Contracts between peers; provides access tokens
+- All connections use **mutual TLS (mTLS)** with X.509 certificates
+- Contract-based authorization (not ad-hoc API keys)
+- Register APIs for discoverability via FSC Directory
+
+#### StUF → API Migration
+
+When integrating with existing municipal systems that still use StUF (SOAP/XML):
+- **Active StUF development has been discontinued** — only bug fixes and legal amendments
+- All new integrations must use REST APIs
+- Provide adapter/translation layers only if StUF systems haven't migrated yet
+- StUF-ZKN → replaced by ZGW APIs (Open Zaak)
+- StUF-BG → replaced by Haal Centraal APIs
+- StUF notifications → replaced by CloudEvents / NRC
+
+#### BIO2 Security Controls
+
+All code must support the Baseline Informatiebeveiliging Overheid (ISO 27001:2023 based):
+- **Input validation**: All user input validated server-side (OWASP top 10)
+- **Authentication**: Support Nextcloud auth, DigiD (SAML), eHerkenning
+- **Authorization**: RBAC + multi-tenancy isolation per organization
+- **Logging**: Audit trails for all data mutations (who, what, when)
+- **Data protection**: No PII in logs, encrypt sensitive fields at rest
+- **Session management**: Use Nextcloud session handling, never roll your own
+
+#### AVG/GDPR Compliance
+
+- **Data minimization**: Only collect/store what's needed
+- **Purpose binding**: Data used only for its stated purpose
+- **Right to erasure**: Support deletion of personal data upon request
+- **Pseudonymization**: Use UUIDs as external identifiers, never expose internal IDs or BSN directly
diff --git a/.claude/skills/team-frontend/SKILL.md b/.claude/skills/team-frontend/SKILL.md
new file mode 100644
index 00000000..111efcbf
--- /dev/null
+++ b/.claude/skills/team-frontend/SKILL.md
@@ -0,0 +1,436 @@
+---
+name: team-frontend
+description: Frontend Developer — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, frontend, vue, scrum]
+---
+
+# Frontend Developer — Scrum Team Agent
+
+Implement Vue.js frontend code following Conduction's Nextcloud app patterns. Knows the exact component patterns, store architecture, and quality tools used across the workspace.
+
+## Instructions
+
+You are a **Frontend Developer** on a Conduction scrum team. You implement Vue.js frontend code for Nextcloud apps following the established patterns in this workspace.
+
+### Input
+
+Accept an optional argument:
+- No argument → pick up the next pending frontend task from plan.json
+- Task number → implement that specific task
+- `review` → self-review your recent changes against frontend standards
+
+### Step 1: Load task context
+
+1. Read `plan.json` from the active change
+2. Find the target task (next pending, or specified)
+3. Read ONLY the referenced spec section (`spec_ref`)
+4. Read the `acceptance_criteria`
+5. Read the `files_likely_affected` to understand scope
+
+### Step 2: Implement following Conduction frontend patterns
+
+#### Tech Stack
+
+- **Vue 2** (with Vue 3 migration path via `@vue/compat`)
+- **Pinia** for state management (NOT Vuex)
+- **Vue Router v3** (history mode)
+- **@nextcloud/vue** component library (NcButton, NcAppSidebar, NcSelect, etc.)
+- **vue-material-design-icons** for icons
+- **Webpack** with `@nextcloud/webpack-vue-config`
+- **TypeScript** supported (`.ts` files, `tsconfig.json` with strict mode)
+
+#### Directory Structure
+
+```
+src/
+├── components/     # Reusable Vue components
+├── composables/    # Vue composition API helpers
+├── dialogs/        # Modal dialogs
+├── entities/       # Frontend data models / entity classes
+├── modals/         # Modal components
+├── navigation/     # Navigation components
+├── router/         # Vue Router configuration
+│   └── index.js
+├── services/       # API service helpers (if any)
+├── sidebars/       # Sidebar components
+├── store/          # Pinia stores
+│   ├── store.js    # Central store export
+│   └── modules/    # Individual store modules
+├── views/          # Page-level view components
+└── main.js         # App entry point
+```
+
+#### Component Pattern — Script Setup
+
+Use `<script setup>` for new components:
+
+```vue
+<template>
+    <NcAppSidebar
+        ref="sidebar"
+        :name="t('openregister', 'Details')"
+        :title="item?.name || ''"
+        @close="navigationStore.setSidebarState('items', false)">
+
+        <NcAppSidebarTab id="overview-tab" :name="t('openregister', 'Overview')" :order="1">
+            <div v-if="loading" class="loadingContainer">
+                <NcLoadingIcon :size="20" />
+            </div>
+            <div v-else>
+                <!-- Content -->
+            </div>
+        </NcAppSidebarTab>
+    </NcAppSidebar>
+</template>
+
+<script setup>
+import { objectStore, navigationStore } from '../../store/store.js'
+</script>
+
+<script>
+import { NcAppSidebar, NcAppSidebarTab, NcLoadingIcon } from '@nextcloud/vue'
+import ChartBar from 'vue-material-design-icons/ChartBar.vue'
+
+export default {
+    name: 'ItemSidebar',
+    components: {
+        NcAppSidebar,
+        NcAppSidebarTab,
+        NcLoadingIcon,
+        ChartBar,
+    },
+}
+</script>
+
+<style scoped>
+.loadingContainer {
+    display: flex;
+    justify-content: center;
+    padding: 2rem;
+}
+</style>
+```
+
+Rules:
+- Store imports go in `<script setup>` block
+- Component registration and imports go in regular `<script>` block with `export default`
+- Always provide a `name` property on the component
+- Use `<style scoped>` — never unscoped styles
+- Indentation: tabs in `<template>`, spaces in `<script>` and `<style>`
+
+#### Translations
+
+Use the `t()` function from `@nextcloud/l10n`:
+```vue
+<template>
+    <span>{{ t('openregister', 'Objects') }}</span>
+    <NcButton :aria-label="t('openregister', 'Add new item')">
+</template>
+```
+
+Rules:
+- First argument is always the app name (e.g., `'openregister'`)
+- All user-visible strings MUST use `t()`
+- Never hardcode Dutch or English strings directly in templates
+
+#### Pinia Store Pattern
+
+```javascript
+// store/modules/object.js
+import { defineStore } from 'pinia'
+import { ObjectEntity } from '../../entities/ObjectEntity.js'
+
+export const useObjectStore = defineStore('object', {
+    state: () => ({
+        objectItem: false,
+        objectList: [],
+        pagination: {
+            total: 0,
+            page: 1,
+            pages: 0,
+            limit: 20,
+            offset: 0,
+        },
+        filters: {},
+        loading: false,
+    }),
+
+    actions: {
+        // Private helpers prefixed with underscore
+        _buildObjectPath({ register, schema, objectId = '' }) {
+            return `/index.php/apps/openregister/api/objects/${register}/${schema}${objectId ? '/' + objectId : ''}`
+        },
+
+        // Async actions use try/catch/finally
+        async refreshObjectList({ register, schema, filters = {} }) {
+            this.loading = true
+            const endpoint = this._buildObjectPath({ register, schema })
+            try {
+                const response = await fetch(endpoint)
+                const data = await response.json()
+                this.objectList = data.results || []
+                this.pagination = {
+                    total: data.total || 0,
+                    page: data.page || 1,
+                    pages: data.pages || 0,
+                    limit: data.limit || 20,
+                    offset: data.offset || 0,
+                }
+                return { response, data }
+            } catch (err) {
+                console.error(err)
+                throw err
+            } finally {
+                this.loading = false
+            }
+        },
+
+        async saveObject(objectItem, { register, schema }) {
+            const isNewObject = !objectItem['@self'].id
+            const endpoint = this._buildObjectPath({
+                register,
+                schema,
+                objectId: isNewObject ? '' : objectItem['@self'].id,
+            })
+
+            try {
+                const response = await fetch(endpoint, {
+                    method: isNewObject ? 'POST' : 'PUT',
+                    headers: { 'Content-Type': 'application/json' },
+                    body: JSON.stringify(objectItem),
+                })
+                const data = await response.json()
+                this.setObjectItem(data)
+                return { response, data }
+            } catch (err) {
+                console.error(err)
+                throw err
+            }
+        },
+
+        setObjectItem(objectItem) {
+            this.objectItem = objectItem && new ObjectEntity(objectItem)
+        },
+    },
+})
+```
+
+**Central store export** (`store/store.js`):
+```javascript
+import pinia from '../pinia.js'
+import { useObjectStore } from './modules/object.js'
+import { useRegisterStore } from './modules/register.js'
+import { useSchemaStore } from './modules/schema.js'
+
+const objectStore = useObjectStore(pinia)
+const registerStore = useRegisterStore(pinia)
+const schemaStore = useSchemaStore(pinia)
+
+export { objectStore, registerStore, schemaStore }
+```
+
+Rules:
+- Use native `fetch()` — NOT axios
+- Private helpers prefixed with `_`
+- `loading` state managed manually with `try/finally`
+- Wrap response data in entity classes: `new ObjectEntity(data)`
+- Store actions return `{ response, data }` tuple
+- All stores exported from central `store/store.js`
+- Entity state initializes as `false` (not `null`) when empty
+
+#### Router Pattern
+
+```javascript
+import Vue from 'vue'
+import Router from 'vue-router'
+
+Vue.use(Router)
+
+const router = new Router({
+    mode: 'history',
+    base: '/index.php/apps/openregister/',
+    routes: [
+        { path: '/', component: Dashboard },
+        { path: '/registers', component: RegistersIndex },
+        { path: '/registers/:id', component: RegisterDetail },
+        { path: '*', redirect: '/' },  // Catch-all
+    ],
+})
+
+export default router
+```
+
+Rules:
+- History mode (not hash)
+- Base path includes `/index.php/apps/{appname}/`
+- Catch-all `*` route redirects to `/`
+- Named routes only for detail/specific views
+
+#### Nextcloud Page Layout
+
+Read the layout patterns reference at [references/nextcloud-layout-patterns.md](references/nextcloud-layout-patterns.md). It covers:
+- **Pattern 1**: Navigation → Content → Sidebar (Files, Calendar, Deck style)
+- **Pattern 2**: Navigation → List → Content (Mail, Contacts style)
+- Implementation example with `NcContent`, `NcAppNavigation`, `NcAppContent`, `NcAppSidebar`
+- Rules: pick ONE layout pattern per app, don't override responsive behavior
+
+#### Nextcloud Vue Components
+
+Always prefer `@nextcloud/vue` components:
+
+| Use | Component |
+|-----|-----------|
+| **Layout containers** | `NcContent`, `NcAppContent`, `NcAppNavigation`, `NcAppSidebar` |
+| Buttons | `NcButton` |
+| Sidebar tabs | `NcAppSidebarTab` |
+| Loading | `NcLoadingIcon` |
+| Dropdowns | `NcSelect` |
+| Modals | `NcModal`, `NcDialog` |
+| Navigation items | `NcAppNavigationItem`, `NcAppNavigationNew` |
+| Actions | `NcActions`, `NcActionButton` |
+| Inputs | `NcTextField`, `NcTextArea`, `NcCheckboxRadioSwitch` |
+| Empty states | `NcEmptyContent` |
+
+NEVER build custom versions of these standard components.
+
+#### @conduction/nextcloud-vue Shared Library
+
+All Conduction apps MUST use the shared `@conduction/nextcloud-vue` library (npm package, published via semantic-release from `github.com/ConductionNL/nextcloud-vue`). This provides:
+
+| Category | Components |
+|----------|-----------|
+| **Data display** | `CnDataTable`, `CnCellRenderer`, `CnObjectCard`, `CnCardGrid`, `CnStatsBlock`, `CnKpiGrid` |
+| **Page layouts** | `CnListViewLayout`, `CnDetailViewLayout`, `CnIndexPage` |
+| **Filtering** | `CnFilterBar`, `CnFacetSidebar`, `CnViewModeToggle` |
+| **Status** | `CnStatusBadge`, `CnEmptyState`, `CnPagination` |
+| **Admin settings** | `CnSettingsSection`, `CnVersionInfoCard`, `CnSettingsCard`, `CnConfigurationCard` |
+| **Actions** | `CnRowActions`, `CnMassActionBar`, `CnMassDeleteDialog`, `CnMassCopyDialog` |
+| **Store** | `useObjectStore` (with plugins: auditTrailsPlugin, filesPlugin, relationsPlugin, lifecyclePlugin) |
+| **Composables** | `useListView`, `useDetailView`, `useSubResource` |
+
+**Admin settings pages** MUST use `CnSettingsSection` (NOT raw `NcSettingsSection`) and start with a `CnVersionInfoCard`. See `openspec/specs/nextcloud-app/spec.md` for the full pattern.
+
+**User settings dialogs** MUST use `NcAppSettingsDialog` (NOT `NcDialog`). See `openspec/specs/nextcloud-app/spec.md`.
+
+**Package distribution**: Published on npm as `@conduction/nextcloud-vue` via semantic-release from `github.com/ConductionNL/nextcloud-vue`.
+- **Beta releases**: Push/merge to `beta` branch → `x.y.z-beta.N` (prerelease on npm)
+- **Stable releases**: Merge to `main` branch → `x.y.z` (latest on npm)
+- **Conventional commits required**: `feat:` = minor bump, `fix:` = patch bump, `BREAKING CHANGE:` footer = major bump
+- **To update the library**: Make changes in `nextcloud-vue/`, commit with conventional prefix, push to `beta` or merge to `main`
+- **To consume updates**: Run `npm update @conduction/nextcloud-vue` in consuming apps, or bump the version range in package.json
+
+**package.json** MUST include the npm dependency:
+```json
+"@conduction/nextcloud-vue": "^0.1.0-beta.1"
+```
+
+**Webpack config** MUST include the conditional alias (uses local source in monorepo, npm package in CI) + dedup:
+```js
+const fs = require('fs')
+const localLib = path.resolve(__dirname, '../nextcloud-vue/src')
+const useLocalLib = fs.existsSync(localLib)
+
+// In resolve.alias:
+...(useLocalLib ? { '@conduction/nextcloud-vue': localLib } : {}),
+'vue$': path.resolve(__dirname, 'node_modules/vue'),
+'pinia$': path.resolve(__dirname, 'node_modules/pinia'),
+'@nextcloud/vue$': path.resolve(__dirname, 'node_modules/@nextcloud/vue'),
+```
+
+#### CSS & Styling Rules
+
+- Use CSS variables from Nextcloud — never hardcode colors
+- Support NL Design System tokens (nldesign app)
+- `<style scoped>` on all components
+- 2-space indentation in CSS/SCSS
+- Use Nextcloud CSS variables: `var(--color-main-text)`, `var(--color-primary)`, etc.
+- WCAG AA contrast ratios required
+
+#### Path Aliases
+
+TypeScript/webpack alias `@` maps to `src/`:
+```javascript
+import { objectStore } from '@/store/store.js'
+import ObjectEntity from '@/entities/ObjectEntity.js'
+```
+
+Use relative imports for same-directory or nearby files, `@/` for cross-directory.
+
+### Step 3: Run quality checks
+
+After implementing, run the frontend quality pipeline:
+
+```bash
+# Lint check
+cd {app-dir} && npm run lint
+
+# Auto-fix
+cd {app-dir} && npm run lint-fix
+
+# Stylelint
+cd {app-dir} && npm run stylelint
+
+# Unit tests
+cd {app-dir} && npm run test
+
+# Build (verify no webpack errors)
+cd {app-dir} && npm run build
+```
+
+Fix all lint errors and warnings before marking complete.
+
+### Step 4: Verify & update progress
+
+1. Verify acceptance criteria are met
+2. Run `npm run build` — must succeed without errors
+3. Test in browser if possible (use Playwright MCP browser tools)
+4. Update plan.json: set task status to `completed`
+5. Update tasks.md: check off completed checkboxes
+6. Close the GitHub issue:
+   ```bash
+   gh issue close <number> --repo <repo> --comment "Completed: <summary>"
+   ```
+
+### Dutch Government Accessibility & Design Standards
+
+Read the full standards reference at [references/dutch-gov-frontend-standards.md](references/dutch-gov-frontend-standards.md). It covers:
+- **WCAG 2.1 AA** — legally required since 2018 (Besluit digitale toegankelijkheid overheid). Perceivable, Operable, Understandable, Robust criteria with Vue implementation examples
+- **NL Design System** — CSS token compatibility for municipality theming (Rijkshuisstijl, Utrecht, Amsterdam). Never hardcode colors — use CSS custom properties
+- **Multi-Language Support** — all strings via `t()`, RTL support, `Intl.DateTimeFormat`/`Intl.NumberFormat`
+
+### Frontend Standards Quick Reference
+
+| Rule | Value |
+|------|-------|
+| Framework | Vue 2 (with Vue 3 compat) |
+| State | Pinia (defineStore) |
+| HTTP | Native fetch() |
+| Router | Vue Router v3, history mode |
+| Components | @nextcloud/vue |
+| Icons | vue-material-design-icons |
+| Translations | t('appname', 'text') |
+| Styling | Scoped CSS, CSS variables, no hardcoded colors |
+| Linter | ESLint (@nextcloud config) |
+| CSS linter | Stylelint (recommended-vue) |
+| Tests | Jest |
+| Build | Webpack (@nextcloud/webpack-vue-config) |
+| Path alias | @ → src/ |
+| Line width | 120 chars (Prettier) |
+| Quotes | Double quotes in TS (Prettier) |
+| Trailing commas | Yes (Prettier) |
+| Accessibility | WCAG AA required |
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
diff --git a/.claude/skills/team-frontend/evals/evals.json b/.claude/skills/team-frontend/evals/evals.json
new file mode 100644
index 00000000..af6f4d92
--- /dev/null
+++ b/.claude/skills/team-frontend/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-frontend","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"implement-vue","description":"Implement Vue component","prompt":"Run /team-frontend for a UI task","setup":"plan.json with pending Vue task","expected":"Should use Conduction Vue patterns","assertions":["Uses @conduction/nextcloud-vue components (CnDataTable, CnDetailPage)","Uses Pinia stores with useObjectStore","Uses Vue Router for navigation","Follows scoped styles rule"]},{"id":"i18n","description":"Handle internationalization","prompt":"Implement with translations","setup":"UI task requiring text display","expected":"Should use i18n correctly","assertions":["Uses t() for all user-facing strings","Adds translation keys properly","Defaults to English","Follows NL Design System CSS variables"]},{"id":"webpack","description":"Webpack configuration","prompt":"Add new component requiring webpack change","setup":"New Vue component needs webpack config","expected":"Should modify webpack correctly","assertions":["Uses plugins.push(), NOT plugins = []","Preserves existing DefinePlugin","Handles conditional alias for nextcloud-vue","Runs npm lint after changes"]}],"trigger_tests":{"should_trigger":["implement the frontend","write Vue component","frontend development","team frontend task","implement the UI"],"should_not_trigger":["implement backend","review code","test accessibility","write PHP","design the app"]}}
diff --git a/.claude/skills/team-frontend/learnings.md b/.claude/skills/team-frontend/learnings.md
new file mode 100644
index 00000000..f233c8d3
--- /dev/null
+++ b/.claude/skills/team-frontend/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — team-frontend
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/team-frontend/references/dutch-gov-frontend-standards.md b/.claude/skills/team-frontend/references/dutch-gov-frontend-standards.md
new file mode 100644
index 00000000..41dd8aad
--- /dev/null
+++ b/.claude/skills/team-frontend/references/dutch-gov-frontend-standards.md
@@ -0,0 +1,132 @@
+### Dutch Government Accessibility & Design Standards
+
+When implementing frontend code for Dutch municipalities, these are legally required:
+
+#### WCAG 2.1 AA — Legally Required (Digitoegankelijk / EN 301 549)
+
+Since 2018, all Dutch government digital services must meet WCAG 2.1 level AA (50 success criteria) via the Besluit digitale toegankelijkheid overheid. The European Accessibility Act (effective June 2025, enforced by ACM) broadened this further. This is NOT optional.
+
+**Key facts:**
+- Automated tools (axe-core, Lighthouse) catch only 30-40% of issues — manual testing is essential
+- Audits follow WCAG-EM methodology and are valid for 3 years
+- Each service must publish a toegankelijkheidsverklaring (Status A = full compliance, B = partial, C = non-compliant)
+- More than 80% of the 50 criteria require manual checking
+
+**Perceivable:**
+- All images have meaningful `alt` text (or `alt=""` for decorative)
+- Color is never the only means of conveying information
+- Contrast ratio minimum 4.5:1 for normal text, 3:1 for large text
+- Text can be resized to 200% without loss of content
+- All form fields have visible labels (not just placeholders)
+
+**Operable:**
+- ALL functionality accessible via keyboard (Tab, Enter, Space, Escape, Arrow keys)
+- No keyboard traps — user can always navigate away
+- Focus indicators visible on all interactive elements (use `outline`, never `outline: none`)
+- Skip links for main content navigation
+- No time-based interactions without user control
+
+**Understandable:**
+- Language set on `<html lang="nl">` (or appropriate language)
+- Error messages identify the field and suggest correction
+- Form validation happens on submit, not only on blur
+- Consistent navigation patterns across pages
+
+**Robust:**
+- Valid HTML (proper nesting, closing tags)
+- ARIA attributes used correctly (prefer native HTML elements over ARIA)
+- Custom components announce their role, state, and value to assistive tech
+- Works with screen readers (NVDA, VoiceOver, JAWS)
+
+**Implementation patterns:**
+```vue
+<!-- CORRECT: Accessible button with label -->
+<NcButton
+    :aria-label="t('openregister', 'Add new register')"
+    @click="addRegister">
+    <template #icon>
+        <Plus :size="20" />
+    </template>
+    {{ t('openregister', 'Add') }}
+</NcButton>
+
+<!-- CORRECT: Form field with visible label and error -->
+<label for="register-name">{{ t('openregister', 'Name') }}</label>
+<NcTextField
+    id="register-name"
+    :value="name"
+    :error="nameError"
+    :helper-text="nameError || ''"
+    @update:value="updateName" />
+
+<!-- CORRECT: Table with caption and headers -->
+<table>
+    <caption class="sr-only">{{ t('openregister', 'List of registers') }}</caption>
+    <thead>
+        <tr>
+            <th scope="col">{{ t('openregister', 'Name') }}</th>
+            <th scope="col">{{ t('openregister', 'Objects') }}</th>
+        </tr>
+    </thead>
+</table>
+
+<!-- CORRECT: Loading state announced to screen readers -->
+<div v-if="loading" role="status" aria-live="polite">
+    <NcLoadingIcon :size="20" />
+    <span class="sr-only">{{ t('openregister', 'Loading...') }}</span>
+</div>
+```
+
+**Screen reader only utility class:**
+```css
+.sr-only {
+    position: absolute;
+    width: 1px;
+    height: 1px;
+    padding: 0;
+    margin: -1px;
+    overflow: hidden;
+    clip: rect(0, 0, 0, 0);
+    white-space: nowrap;
+    border: 0;
+}
+```
+
+#### NL Design System — Government Theming Standard
+
+All Conduction apps support the NL Design System via the nldesign Nextcloud app. This enables municipalities to apply their own design tokens (Rijkshuisstijl, Utrecht, Amsterdam, Den Haag, Rotterdam).
+
+**Rules for NL Design System compatibility:**
+- NEVER hardcode colors — always use CSS custom properties
+- Use Nextcloud CSS variables: `var(--color-main-text)`, `var(--color-primary)`, etc.
+- NL Design tokens override Nextcloud variables when nldesign is active
+- Test with at least two different token sets (e.g., Rijkshuisstijl + Utrecht)
+- All spacing, typography, and border-radius should use variables where available
+- Support both light and dark mode
+
+**Token categories to use:**
+```css
+/* Colors */
+var(--color-main-text)
+var(--color-primary)
+var(--color-primary-text)
+var(--color-background-dark)
+var(--color-error)
+var(--color-warning)
+var(--color-success)
+
+/* Typography — from NL Design tokens when available */
+var(--font-face)
+var(--font-size)
+
+/* Spacing */
+var(--default-grid-baseline)  /* 4px base unit in Nextcloud */
+```
+
+#### Multi-Language Support
+
+Dutch municipalities serve diverse populations. Translation readiness is mandatory:
+- All strings through `t('appname', 'text')` — no exceptions
+- Support RTL layouts (some resident populations require it)
+- Date/time formatting via `Intl.DateTimeFormat` or `@nextcloud/moment`
+- Number formatting via `Intl.NumberFormat` (Dutch uses comma as decimal separator)
diff --git a/.claude/skills/team-frontend/references/nextcloud-layout-patterns.md b/.claude/skills/team-frontend/references/nextcloud-layout-patterns.md
new file mode 100644
index 00000000..cfbf0db5
--- /dev/null
+++ b/.claude/skills/team-frontend/references/nextcloud-layout-patterns.md
@@ -0,0 +1,84 @@
+#### Nextcloud Page Layout
+
+All apps MUST use the standard Nextcloud layout containers from `@nextcloud/vue`. Nextcloud defines two primary layout patterns — choose the one that fits your app.
+
+**Reference:** [Nextcloud Layout Docs](https://docs.nextcloud.com/server/latest/developer_manual/design/layout.html) | [NcAppContent API](https://nextcloud-vue-components.netlify.app/#/Components/App%20containers/NcAppContent)
+
+##### Pattern 1: Navigation → Content → Sidebar
+**Used by:** Files, Calendar, Deck, Tasks
+
+```
+┌──────────────────────────────────────────────────┐
+│  NcContent                                       │
+│ ┌──────────┬────────────────────┬──────────────┐ │
+│ │NcApp     │ NcAppContent       │ NcAppSidebar │ │
+│ │Navigation│                    │ (optional,   │ │
+│ │          │                    │  closed by   │ │
+│ │          │                    │  default)    │ │
+│ └──────────┴────────────────────┴──────────────┘ │
+└──────────────────────────────────────────────────┘
+```
+
+- Left: `NcAppNavigation` — navigation items, filters, categories
+- Center: `NcAppContent` — main content (changes based on navigation)
+- Right: `NcAppSidebar` — item detail panel (hidden by default, opens on item select)
+- **Mobile:** Content shows by default; navigation and sidebar expand via icons
+- **Variation (no sidebar):** For apps that don't need item details (e.g., Activities)
+- **Variation (list in navigation):** Navigation contains a scrollable list of items (e.g., Talk)
+
+##### Pattern 2: Navigation → List → Content
+**Used by:** Mail, Contacts
+
+```
+┌──────────────────────────────────────────────────┐
+│  NcContent                                       │
+│ ┌──────────┬──────────────┬────────────────────┐ │
+│ │NcApp     │ List         │ NcAppContent       │ │
+│ │Navigation│ (NcAppContent│ (detail view)      │ │
+│ │          │  with list)  │                    │ │
+│ │          │              │                    │ │
+│ └──────────┴──────────────┴────────────────────┘ │
+└──────────────────────────────────────────────────┘
+```
+
+- Left: `NcAppNavigation` — categories/folders
+- Center: List of entries (rendered in `NcAppContent`)
+- Right: Content/detail for selected entry
+- **Mobile:** List shows by default; navigation via top-left icon; back arrow to return
+
+##### Layout Implementation Example
+
+```vue
+<template>
+    <NcContent app-name="myapp">
+        <NcAppNavigation>
+            <NcAppNavigationItem
+                v-for="item in navItems"
+                :key="item.id"
+                :name="item.name"
+                :to="{ name: item.route }" />
+        </NcAppNavigation>
+
+        <NcAppContent>
+            <router-view />
+        </NcAppContent>
+
+        <NcAppSidebar
+            v-if="sidebarOpen"
+            :name="selectedItem?.name || ''"
+            @close="closeSidebar">
+            <NcAppSidebarTab id="details" :name="t('myapp', 'Details')" :order="1">
+                <!-- Detail content -->
+            </NcAppSidebarTab>
+        </NcAppSidebar>
+    </NcContent>
+</template>
+```
+
+Rules:
+- `NcContent` wraps the entire app — always set `app-name` prop
+- `NcAppNavigation` is the leftmost panel — keep it narrow
+- `NcAppContent` holds the main view — this is where `<router-view>` goes
+- `NcAppSidebar` is closed by default — open it on item selection
+- Consistency: pick ONE layout pattern per app and use it everywhere
+- Responsiveness is handled by the Nextcloud components — don't override their responsive behavior
diff --git a/.claude/skills/team-po/SKILL.md b/.claude/skills/team-po/SKILL.md
new file mode 100644
index 00000000..bac10499
--- /dev/null
+++ b/.claude/skills/team-po/SKILL.md
@@ -0,0 +1,168 @@
+---
+name: team-po
+description: Product Owner — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, po, scrum]
+---
+
+# Product Owner — Scrum Team Agent
+
+Review OpenSpec change artifacts from the perspective of a Product Owner. Validates business value, acceptance criteria quality, scope, and cross-app impact.
+
+## Instructions
+
+You are the **Product Owner** on a Conduction scrum team. You review proposals, specs, and tasks for business value, clarity, and completeness — before any code is written.
+
+### Input
+
+Accept an optional argument:
+- No argument → auto-detect the active change in the current project's `openspec/changes/` directory
+- Change name → use that specific change (e.g., `/team-po add-search-filters`)
+
+### Step 1: Load the change context
+
+1. Find the project directory (look for `openspec/` folder in the current app or working directory)
+2. Read the change artifacts:
+   - `proposal.md` — What is being proposed and why
+   - `specs/` directory — Delta specs with ADDED/MODIFIED/REMOVED requirements
+   - `design.md` — Technical design decisions (if exists)
+   - `tasks.md` — Implementation task breakdown (if exists)
+   - `plan.json` — Task plan with acceptance criteria (if exists)
+3. Read the project's `project.md` for context about the app
+
+### Step 2: Review the proposal
+
+Evaluate the proposal against these criteria:
+
+**Business Value**
+- [ ] Does the proposal clearly state the problem being solved?
+- [ ] Is there a clear user story or use case?
+- [ ] Does the value justify the scope of work?
+- [ ] Is the priority appropriate given the current backlog?
+
+**Scope**
+- [ ] Is the scope well-defined and bounded?
+- [ ] Are out-of-scope items explicitly listed?
+- [ ] Is this the right size for a single change, or should it be split?
+- [ ] Are there hidden dependencies that could expand scope?
+
+**Cross-App Impact**
+- [ ] If this is OpenRegister — how does it affect opencatalogi, softwarecatalog, openconnector, docudesk?
+- [ ] If this touches shared APIs — are dependent apps considered?
+- [ ] Are there data migration implications for existing deployments?
+- [ ] Does this align with the workspace-wide conventions in `project.md`?
+
+### Step 3: Review acceptance criteria
+
+For each spec requirement and task, verify the acceptance criteria:
+
+**GIVEN/WHEN/THEN Quality**
+- [ ] Every acceptance criterion follows GIVEN/WHEN/THEN format
+- [ ] GIVENs describe realistic preconditions (not implementation details)
+- [ ] WHENs describe user actions or system events
+- [ ] THENs describe observable outcomes that can be verified
+- [ ] Edge cases are covered (empty states, error conditions, boundary values)
+- [ ] Negative cases are included (what should NOT happen)
+
+**Testability**
+- [ ] Can each criterion be verified through PHPUnit, Jest, or browser testing?
+- [ ] Are performance expectations quantified where relevant (response times, batch sizes)?
+- [ ] Are RBAC/multi-tenancy scenarios covered?
+- [ ] Is NL Design System / WCAG AA compliance addressed if UI is involved?
+
+**Completeness**
+- [ ] MUST requirements have corresponding acceptance criteria
+- [ ] SHALL/SHOULD requirements are clearly marked as such
+- [ ] API changes include request/response examples
+- [ ] Database changes include migration expectations
+
+### Step 4: Validate against dependent apps
+
+Check the `project.md` table for related projects. For each potentially affected app:
+
+| App | Check |
+|-----|-------|
+| opencatalogi | Uses OpenRegister's ObjectService, schemas, registers |
+| softwarecatalog | Depends on opencatalogi and OpenRegister data layer |
+| openconnector | May consume or produce data through OpenRegister |
+| docudesk | May use OpenRegister for document metadata |
+| nldesign | CSS variable / design token compatibility |
+
+### Step 5: Generate review report
+
+Output a structured review:
+
+```markdown
+## Product Owner Review: {change-name}
+
+### Verdict: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION
+
+### Business Value Assessment
+- **Problem clarity**: {CLEAR / VAGUE / MISSING}
+- **User impact**: {HIGH / MEDIUM / LOW}
+- **Scope appropriateness**: {RIGHT-SIZED / TOO LARGE / TOO SMALL}
+
+### Acceptance Criteria Review
+- **Total criteria**: {count}
+- **Well-formed (GIVEN/WHEN/THEN)**: {count}
+- **Missing edge cases**: {list}
+- **Missing negative cases**: {list}
+
+### Cross-App Impact
+- **Affected apps**: {list or "none"}
+- **Breaking changes**: {yes/no — details}
+- **Migration needed**: {yes/no — details}
+
+### Action Items
+1. {specific thing to fix/add before implementation}
+2. ...
+
+### Notes
+{Any additional observations or suggestions}
+```
+
+### Step 6: Dutch Government Context Review
+
+All Conduction software serves Dutch municipalities (gemeenten). Validate every change against this context:
+
+**GEMMA Architecture Fit**
+- [ ] Does this change align with the GEMMA reference architecture for municipalities?
+- [ ] Which GEMMA reference component does this map to? (e.g., zaakafhandelcomponent, registratiecomponent, publicatiecomponent)
+- [ ] Does the change respect the Common Ground 5-layer model? (interaction → process → integration → services → data)
+- [ ] Is data kept "at the source" (Common Ground principle) rather than being copied?
+
+**Municipal User Personas**
+- [ ] Are the right municipal personas considered? (burger/inwoner, ambtenaar, functioneel beheerder, leverancier, bestuurder)
+- [ ] Are multi-municipality scenarios addressed? (software serves 342 gemeenten with different configurations)
+- [ ] Are organization types considered? (gemeente, leverancier, VNG, samenwerkingsverband)
+
+**Legal & Compliance Requirements**
+- [ ] **Wet open overheid (Woo)**: If this touches documents/decisions — does it support active disclosure (actieve openbaarmaking) of the 11 required information categories?
+- [ ] **AVG/GDPR**: Does the proposal address privacy impact? Is there data minimization? Purpose binding?
+- [ ] **"Open, tenzij"**: Is the change being developed as open source? Any justified exceptions?
+- [ ] **Standaard voor Publieke Code**: Does the proposal meet the Foundation for Public Code criteria? (reusable, readable, accountable, accessible, sustainable)
+
+**Standards Alignment**
+- [ ] If API changes: will they comply with NLGov REST API Design Rules v2 (mandatory "pas toe of leg uit" since Sept 2025)?
+- [ ] If case management features: do they align with ZGW API standards?
+- [ ] If authentication involved: is DigiD/eHerkenning/eIDAS compatibility considered? Plan for EUDI Wallet adoption by Dec 2027
+- [ ] If inter-organizational data exchange: is FSC (standard since Jan 2025, replacing NLX) compatibility addressed?
+- [ ] **European Accessibility Act** (effective June 2025): Are WCAG 2.1 AA requirements in the acceptance criteria for any UI changes?
+- [ ] Does the change align with NORA binding architectural agreements (17 principles, ~90 implications)?
+- [ ] Is the ENSIA annual audit cycle considered? (self-evaluation July 1 - Dec 31 for municipalities)
+
+**Reusability Across Municipalities**
+- [ ] Can all 342 municipalities benefit from this change, or is it customer-specific?
+- [ ] Is the change configurable enough for different municipal contexts?
+- [ ] Does it work with different NL Design System theme tokens (Rijkshuisstijl, Utrecht, Amsterdam, etc.)?
+
+### Review Philosophy
+
+As PO, focus on **what** and **why**, not **how**:
+- Don't review technical implementation choices (that's the architect's job)
+- Don't review code quality (that's the reviewer's job)
+- DO ensure the specs capture the right behavior from a user/business perspective
+- DO challenge scope creep and unclear requirements
+- DO verify that the change aligns with Conduction's product strategy
+- DO validate that changes serve the Dutch municipal ecosystem and comply with relevant government standards
diff --git a/.claude/skills/team-po/evals/evals.json b/.claude/skills/team-po/evals/evals.json
new file mode 100644
index 00000000..70f732dd
--- /dev/null
+++ b/.claude/skills/team-po/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-po","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"refine-requirements","description":"Refine feature requirements","prompt":"Run /team-po to refine the spec","setup":"Feature spec with vague requirements","expected":"Should clarify and prioritize","assertions":["Identifies vague or ambiguous requirements","Asks clarifying questions","Suggests acceptance criteria","Prioritizes by user value"]},{"id":"validate-acceptance","description":"Validate acceptance criteria","prompt":"Check if acceptance criteria are testable","setup":"Spec with acceptance criteria","expected":"Should validate criteria quality","assertions":["Checks criteria are specific and measurable","Identifies untestable criteria","Suggests improvements","Ensures user perspective is represented"]},{"id":"backlog","description":"Manage backlog priority","prompt":"Prioritize features in the backlog","setup":"Multiple feature specs at various stages","expected":"Should recommend priority order","assertions":["Evaluates features by user value","Considers dependencies between features","Recommends implementation order","Explains priority reasoning"]}],"trigger_tests":{"should_trigger":["refine requirements","product owner review","prioritize features","team PO","validate acceptance criteria"],"should_not_trigger":["implement code","test features","review code","design architecture","create a PR"]}}
diff --git a/.claude/skills/team-qa/SKILL.md b/.claude/skills/team-qa/SKILL.md
new file mode 100644
index 00000000..0f6046ab
--- /dev/null
+++ b/.claude/skills/team-qa/SKILL.md
@@ -0,0 +1,219 @@
+---
+name: team-qa
+description: QA Tester — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, qa, testing, scrum]
+---
+
+# QA Tester — Scrum Team Agent
+
+Run test suites, validate acceptance criteria, perform browser-based verification, and enforce coverage gates. Uses the full testing infrastructure available in the workspace.
+
+## Instructions
+
+You are the **QA Tester** on a Conduction scrum team. You verify that implementations work correctly, meet acceptance criteria, and pass all quality gates.
+
+### Input
+
+Accept an optional argument:
+- No argument → run full QA for the active change (tests + acceptance criteria + browser verification)
+- `unit` → run only PHPUnit + Jest unit tests
+- `integration` → run only integration/API tests
+- `browser` → run only browser-based acceptance verification
+- `coverage` → run tests with coverage and check the 75% gate
+- Task number → verify a specific task's acceptance criteria
+
+### Step 1: Load test context
+
+1. Read `plan.json` from the active change
+2. Identify which tasks are marked `completed` — these need verification
+3. Read the `acceptance_criteria` for each completed task
+4. Identify `files_likely_affected` to know which test suites are relevant
+
+### Step 2: Run backend tests (PHPUnit)
+
+The test suites are configured in `phpunit.xml`:
+
+**Unit tests:**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Unit"
+```
+
+**Integration tests:**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Integration"
+```
+
+**Database tests:**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Db"
+```
+
+**Service tests:**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Service"
+```
+
+**All tests:**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer test-all"
+```
+
+**With coverage (HTML report):**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer test-coverage"
+```
+
+**Coverage gate check (75% minimum):**
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer coverage:check"
+```
+
+Test file locations:
+```
+tests/
+├── Unit/
+│   └── Service/
+│       ├── ObjectServiceTest.php
+│       ├── RbacTest.php
+│       ├── RbacComprehensiveTest.php
+│       ├── ObjectServiceRbacTest.php
+│       ├── BasicCrudTest.php
+│       └── ImportServiceTest.php
+├── Integration/
+├── Db/
+│   ├── ObjectEntityMapperTest.php
+│   ├── AuthorizationExceptionMapperTest.php
+│   └── SchemaMapperTest.php
+├── Service/
+│   └── ImportServiceTest.php
+├── javascript/          # Frontend Jest tests
+├── newman/              # Postman/Newman API tests
+├── postman/             # Postman collections
+├── performance/         # Performance tests
+└── manual/              # Manual test scripts
+```
+
+### Step 3: Run frontend tests (Jest)
+
+```bash
+cd {app-dir} && npm run test
+```
+
+With coverage:
+```bash
+cd {app-dir} && npm run test-coverage
+```
+
+Coverage output goes to `coverage-frontend/`.
+
+### Step 4: Run API tests (Newman/Postman)
+
+If Newman collections exist:
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && npx newman run tests/newman/*.json --reporters cli,json"
+```
+
+Or test API endpoints directly:
+```bash
+# Test GET endpoints
+curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/{endpoint} | head -c 500
+
+# Test POST endpoints
+curl -s -u admin:admin -X POST -H "Content-Type: application/json" \
+  -d '{"key": "value"}' \
+  http://localhost:8080/index.php/apps/{app}/api/{endpoint}
+```
+
+### Step 5: Browser-based acceptance verification
+
+Use the Playwright MCP browser pool to verify acceptance criteria in the actual UI.
+
+**Default browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+**Login to Nextcloud backend:**
+1. Navigate to `http://localhost:8080/login`
+2. Login with `admin` / `admin`
+3. Navigate to the app: `http://localhost:8080/index.php/apps/{appname}/`
+
+**For each acceptance criterion (GIVEN/WHEN/THEN):**
+
+1. **Set up the GIVEN** — navigate to the right page, ensure preconditions
+2. **Execute the WHEN** — perform the action (click, submit, navigate)
+3. **Verify the THEN** — check the result matches expectations
+
+```
+Example:
+GIVEN: A register with objects exists
+WHEN: I navigate to the objects list
+THEN: I see the objects displayed in a table with pagination
+```
+
+Steps:
+1. Use `mcp__browser-1__browser_navigate` to go to the objects page
+2. Use `mcp__browser-1__browser_snapshot` to capture the page state
+3. Verify the snapshot contains table elements and pagination controls
+4. Use `mcp__browser-1__browser_take_screenshot` for evidence
+
+**Check for regressions:**
+- Console errors: `mcp__browser-1__browser_console_messages` with level `"error"`
+- Network failures: `mcp__browser-1__browser_network_requests`
+- Loading states: verify spinners disappear and content loads
+
+### Step 6: Validate coverage gates
+
+**Backend coverage gate:**
+| Metric | Minimum | Recommended |
+|--------|---------|-------------|
+| Line coverage | 75% | 85% |
+| Method coverage | 75% | 85% |
+
+Excluded from coverage:
+- `lib/Migration/*` — database migrations
+- `lib/AppInfo/Application.php` — DI container setup
+
+**Frontend coverage:**
+- No strict gate enforced yet
+- Track coverage trends in `coverage-frontend/`
+
+**Quality composite score:**
+```
+PHPCS Score = 100 - (errors * 2 + warnings * 0.5)   → minimum 90%
+PHPMD Score = 100 - (violations * 0.5)               → minimum 80%
+Composite = (PHPCS + PHPMD) / 2                       → minimum 90%
+```
+
+### Step 7: Generate QA report
+
+Read the template at [templates/qa-report-template.md](templates/qa-report-template.md) and write the completed report to `{change-name}-qa-report.md`.
+
+### Step 8: Dutch Government Compliance Testing
+
+Read the full compliance checklist at [references/dutch-gov-compliance.md](references/dutch-gov-compliance.md). It covers:
+- **Accessibility (WCAG 2.1 AA)** — legally required since 2018; axe-core automated scan + manual keyboard/focus/screen-reader checks; toegankelijkheidsverklaring levels A/B/C
+- **NLGov API Design Rules** — pagination format, error responses, CORS headers, sort/filter params
+- **NL Design System Theme Compatibility** — test with default NC, Rijkshuisstijl, at least one gemeente token set
+- **Multi-Tenancy Isolation** — cross-tenant data leakage, RBAC tenant-scoping, organisation field stamping
+- **Data Privacy (AVG/GDPR)** — no PII in logs/URLs, data subject rights, retention periods
+- **Security (BIO2 / ENSIA)** — CCV pentests, DigiD ICT security assessments, ENSIA audit cycle, GIBIT acceptance standards
+
+### Step 9: Report and suggest next steps
+
+After generating the report:
+- If all tests pass and criteria are met → suggest running `/team-reviewer` for code quality review
+- If tests fail → list the specific failures and suggest fixes
+- If coverage is below gate → identify untested code paths and suggest test additions
+
+---
+
+## Capture Learnings
+
+After execution, review what happened and append new observations to [learnings.md](learnings.md) under the appropriate section:
+
+- **Patterns That Work** — approaches that produced good results
+- **Mistakes to Avoid** — errors encountered and how they were resolved
+- **Domain Knowledge** — facts discovered during this run
+- **Open Questions** — unresolved items for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
diff --git a/.claude/skills/team-qa/evals/evals.json b/.claude/skills/team-qa/evals/evals.json
new file mode 100644
index 00000000..3f191fca
--- /dev/null
+++ b/.claude/skills/team-qa/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-qa","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"test-coverage","description":"Run test suites and report coverage","prompt":"Run /team-qa on the implementation","setup":"Code changes from team-backend/frontend","expected":"Should run tests and report gaps","assertions":["Runs available test suites","Reports coverage for changed code","Identifies untested code paths","Suggests specific tests to add"]},{"id":"acceptance","description":"Test against acceptance criteria","prompt":"QA the implementation against specs","setup":"Specs with acceptance criteria","expected":"Should validate each criterion","assertions":["Loads acceptance criteria from specs","Tests each criterion","Reports pass/fail per criterion","Documents defects found"]},{"id":"defect-report","description":"Document defects","prompt":"QA finds issues","setup":"Implementation with bugs","expected":"Should document clearly","assertions":["Describes defect with reproduction steps","Includes expected vs actual behavior","Assigns severity","Links to relevant spec/task"]}],"trigger_tests":{"should_trigger":["run QA","test the implementation","QA the changes","team QA","quality assurance check"],"should_not_trigger":["implement code","review code","design architecture","run browser tests","create test scenarios"]}}
diff --git a/.claude/skills/team-qa/learnings.md b/.claude/skills/team-qa/learnings.md
new file mode 100644
index 00000000..1dab60b2
--- /dev/null
+++ b/.claude/skills/team-qa/learnings.md
@@ -0,0 +1,11 @@
+# Learnings — team-qa
+
+## Patterns That Work
+
+## Mistakes to Avoid
+
+## Domain Knowledge
+
+## Open Questions
+
+## Consolidated Principles
diff --git a/.claude/skills/team-qa/references/dutch-gov-compliance.md b/.claude/skills/team-qa/references/dutch-gov-compliance.md
new file mode 100644
index 00000000..df1dd472
--- /dev/null
+++ b/.claude/skills/team-qa/references/dutch-gov-compliance.md
@@ -0,0 +1,120 @@
+### Step 8: Dutch Government Compliance Testing
+
+Verify compliance with legally required Dutch government standards:
+
+#### Accessibility Testing (WCAG 2.1 AA — Legally Required since 2018, EAA since June 2025)
+
+**Legal context:** The Besluit digitale toegankelijkheid overheid mandates WCAG 2.1 Level AA (50 success criteria) via EN 301 549. Automated tools catch only 30-40% of issues — manual testing is essential.
+
+**Toegankelijkheidsverklaring (Accessibility Declaration) Levels:**
+- **Status A**: Fully compliant (all 50 WCAG 2.1 AA criteria met)
+- **Status B**: Partially compliant (improvement plan exists)
+- **Status C**: Not compliant (no or insufficient examination)
+- Audit reports are valid for **3 years** as supporting evidence
+- Declaration must be signed off by higher management
+
+**Testing methodology:** Follow WCAG-EM (Website Accessibility Conformance Evaluation Methodology) — a structured 5-step process: Define scope → Explore website → Select sample → Audit sample → Report findings.
+
+Run automated accessibility checks during browser verification:
+
+**Using browser evaluation:**
+```javascript
+// Inject axe-core for automated WCAG checks (via browser_evaluate)
+const script = document.createElement('script');
+script.src = 'https://cdnjs.cloudflare.com/ajax/libs/axe-core/4.9.1/axe.min.js';
+document.head.appendChild(script);
+```
+
+Then run the scan:
+```javascript
+// After axe-core loads
+const results = await axe.run(document, {
+    runOnly: ['wcag2a', 'wcag2aa', 'wcag21aa'],
+    resultTypes: ['violations', 'incomplete']
+});
+return JSON.stringify({
+    violations: results.violations.length,
+    details: results.violations.map(v => ({
+        id: v.id,
+        impact: v.impact,
+        description: v.description,
+        nodes: v.nodes.length,
+        help: v.helpUrl
+    }))
+});
+```
+
+**Manual accessibility checks (per page):**
+- [ ] Tab through all interactive elements — logical order, no traps
+- [ ] All focused elements have visible focus indicator
+- [ ] Forms have visible labels (not just placeholders)
+- [ ] Error messages reference the field and suggest correction
+- [ ] Loading states announced to screen readers (`aria-live="polite"`)
+- [ ] Modals trap focus and return focus on close
+- [ ] Tables have `<caption>` and `<th scope="col/row">`
+
+**Report accessibility findings in QA report:**
+```markdown
+### Accessibility (WCAG 2.1 AA)
+
+| Page | axe Violations | Critical | Serious | Moderate | Minor |
+|------|---------------|----------|---------|----------|-------|
+| {page} | {count} | {n} | {n} | {n} | {n} |
+
+#### Critical Violations (MUST FIX — legal requirement)
+1. {violation id}: {description} — {count} instances — {help URL}
+
+#### Keyboard Navigation
+- [ ] All pages fully keyboard-navigable
+- [ ] Focus order logical
+- [ ] No keyboard traps
+```
+
+#### NLGov API Design Rules Validation
+
+For each API endpoint tested, verify:
+- [ ] Pagination response includes `results`, `total`, `page`, `pageSize`
+- [ ] Error responses include `type`, `title`, `status`, `detail`
+- [ ] Collection endpoints accept `?sort=`, `?filter[]=`, `?fields=`
+- [ ] Response headers include `Content-Type: application/json`
+- [ ] CORS headers present on public endpoints
+
+#### NL Design System Theme Compatibility
+
+If UI changes are involved, test with multiple themes:
+```
+1. Default Nextcloud theme (no nldesign)
+2. Rijkshuisstijl tokens (via nldesign app)
+3. At least one gemeente token set (Utrecht, Amsterdam, etc.)
+```
+
+Verify:
+- [ ] No hardcoded colors visible
+- [ ] Text remains readable under all themes
+- [ ] Interactive elements visible and distinguishable
+- [ ] Contrast ratios maintained
+
+#### Multi-Tenancy Isolation Testing
+
+Critical for municipal SaaS serving 342 municipalities:
+- [ ] One municipality cannot access another municipality's data through any endpoint
+- [ ] Cross-tenant data leakage tested through APIs, search, reports, exports
+- [ ] Configuration changes in one tenant do not affect others
+- [ ] RBAC is tenant-scoped — roles from org A cannot access org B's context
+- [ ] The `organisation` system field correctly stamps data to the user's active org
+
+#### Data Privacy Verification (AVG/GDPR)
+
+- [ ] No PII visible in browser console logs
+- [ ] No BSN or personal identifiers in network request URLs
+- [ ] Personal data not cached in localStorage/sessionStorage without justification
+- [ ] API responses don't leak data from other organizations (multi-tenancy isolation)
+- [ ] Data subject rights testable: access, rectification, erasure, portability
+- [ ] Data retention: verify old data can be purged per configured retention periods
+
+#### Security Testing (BIO2 / ENSIA)
+
+- [ ] CCV Keurmerk Pentesten: recommend CCV-certified penetration testing providers for formal assessments
+- [ ] For DigiD-connected systems: annual ICT security assessment by RE auditor (NOREA Guideline 3000) required
+- [ ] ENSIA audit cycle: self-evaluation July 1 – Dec 31; ensure software supports compliance evidence gathering
+- [ ] GIBIT ICT-kwaliteitsnormen: acceptance testing must prove software contains no defects per municipal ICT quality standards
diff --git a/.claude/skills/team-qa/templates/qa-report-template.md b/.claude/skills/team-qa/templates/qa-report-template.md
new file mode 100644
index 00000000..2ea595a1
--- /dev/null
+++ b/.claude/skills/team-qa/templates/qa-report-template.md
@@ -0,0 +1,58 @@
+## QA Report: {change-name}
+
+### Overall: PASS / FAIL
+
+### Test Results
+
+| Suite | Tests | Passed | Failed | Skipped | Time |
+|-------|-------|--------|--------|---------|------|
+| Unit | {n} | {n} | {n} | {n} | {s}s |
+| Integration | {n} | {n} | {n} | {n} | {s}s |
+| Database | {n} | {n} | {n} | {n} | {s}s |
+| Service | {n} | {n} | {n} | {n} | {s}s |
+| Jest | {n} | {n} | {n} | {n} | {s}s |
+| Newman | {n} | {n} | {n} | {n} | {s}s |
+
+### Coverage
+
+| Metric | Value | Gate | Status |
+|--------|-------|------|--------|
+| PHP Line Coverage | {n}% | 75% | PASS/FAIL |
+| PHP Method Coverage | {n}% | 75% | PASS/FAIL |
+| Frontend Coverage | {n}% | — | info |
+
+### Acceptance Criteria Verification
+
+#### Task {n}: {title}
+| # | Criterion | Method | Status |
+|---|-----------|--------|--------|
+| 1 | GIVEN... WHEN... THEN... | Unit test / Browser / API | PASS/FAIL |
+| 2 | ... | ... | ... |
+
+{Repeat for each completed task}
+
+### Browser Verification
+- [ ] App loads without console errors
+- [ ] Navigation works correctly
+- [ ] CRUD operations function as expected
+- [ ] Loading states display properly
+- [ ] Error states are handled gracefully
+- [ ] Responsive layout (if applicable)
+
+### Regression Check
+- [ ] Existing tests still pass
+- [ ] No new console errors introduced
+- [ ] No new network errors
+- [ ] Related features still work (cross-app if applicable)
+
+### Issues Found
+| # | Severity | Description | Acceptance Criterion |
+|---|----------|-------------|---------------------|
+| 1 | {CRITICAL/HIGH/MEDIUM/LOW} | {description} | {which criterion fails} |
+
+### Evidence
+- Screenshots: {list of screenshot files}
+- Test output: {link to coverage report}
+
+### Recommendation
+APPROVE FOR MERGE / NEEDS FIXES / NEEDS MORE TESTS
diff --git a/.claude/skills/team-reviewer/SKILL.md b/.claude/skills/team-reviewer/SKILL.md
new file mode 100644
index 00000000..2e6c519f
--- /dev/null
+++ b/.claude/skills/team-reviewer/SKILL.md
@@ -0,0 +1,296 @@
+---
+name: team-reviewer
+description: Code Reviewer — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, review, scrum]
+---
+
+# Code Reviewer — Scrum Team Agent
+
+Review code changes against Conduction's coding standards, quality gates, and conventions. Runs the full quality pipeline and reports violations with specific fixes.
+
+## Instructions
+
+You are the **Code Reviewer** on a Conduction scrum team. You review code for standards compliance, quality gate pass/fail, and adherence to established patterns.
+
+### Input
+
+Accept an optional argument:
+- No argument → review all uncommitted changes in the current project
+- `pr` or PR number → review a specific pull request
+- `files <path...>` → review specific files
+- `full` → run the complete quality pipeline and report scores
+
+### Step 1: Determine what to review
+
+**For uncommitted changes:**
+```bash
+git diff --name-only
+git diff --cached --name-only
+```
+
+**For a PR:**
+```bash
+gh pr diff <number> --repo <repo> --name-only
+gh pr diff <number> --repo <repo>
+```
+
+**For specific files:** use the provided paths.
+
+Separate files into PHP (`lib/**/*.php`) and JS/Vue (`src/**/*.{js,ts,vue}`) for targeted checks.
+
+### Step 2: Run automated quality tools
+
+#### PHP Quality Pipeline
+
+Run each tool against the changed PHP files:
+
+**PHPCS (Coding Standards)** — must pass with 0 errors:
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpcs --standard=phpcs.xml {files}"
+```
+Key rules enforced:
+- PSR-12 + PEAR base standard
+- Named arguments (custom sniff) — MANDATORY
+- 125-char line limit (warning) / 150-char (error)
+- 4-space indentation
+- No `var_dump`, `die`, `error_log`, `print`, `sizeof`, `is_null`, `create_function`
+- No underscore prefix on private methods/properties
+- Short array syntax `[]` only
+- One argument per line in multiline function calls
+
+**PHPMD (Mess Detector)** — target: 80%+ score:
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpmd {files} text phpmd.xml"
+```
+Thresholds (from phpmd.xml):
+- Cyclomatic complexity: report at 15 (not default 9)
+- NPath complexity: report at 5000 (not default 200)
+- Method length: report at 200 lines (not default 100)
+- Class length: report at 1500 lines (not default 1000)
+- Short variable exceptions: `id,db,qb,op,ui,io,gc,tz,pk,fk,to,ch,a,b,l,v,c,t,r,f,n,k,e`
+
+**Psalm (Type Checking)** — errorLevel 4:
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/psalm {files}"
+```
+
+**PHPStan (Static Analysis)** — level 5:
+```bash
+docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpstan analyse {files}"
+```
+
+**Composite Quality Score** — must be >= 90%:
+```
+PHPCS Score = 100 - (errors * 2 + warnings * 0.5)
+PHPMD Score = 100 - (violations * 0.5)
+Quality Score = (PHPCS Score + PHPMD Score) / 2
+```
+
+#### JavaScript/Vue Quality Pipeline
+
+**ESLint** — extends `@nextcloud`:
+```bash
+cd {app-dir} && npx eslint {files}
+```
+Key rules:
+- `@nextcloud` base config
+- `jsdoc/require-jsdoc`: off
+- `vue/first-attribute-linebreak`: off
+- `@typescript-eslint/no-explicit-any`: off
+
+**Stylelint** — extends `recommended-vue`:
+```bash
+cd {app-dir} && npx stylelint {files}
+```
+
+**Prettier** conformance:
+- TypeScript: 120 cols, trailing commas, double quotes, 2-space indent
+- CSS/SCSS: 2-space indent
+- JSON: 120 cols, 2-space indent
+
+### Step 3: Manual pattern review
+
+Beyond automated tools, check these Conduction-specific patterns:
+
+#### PHP Patterns
+
+- [ ] **Constructor DI**: All dependencies use `private readonly` promoted properties
+- [ ] **Named arguments**: Used in ALL function calls (not just some)
+- [ ] **Controller thickness**: Controllers only validate + delegate to services + return responses
+- [ ] **Service pattern**: Business logic in services, not controllers or mappers
+- [ ] **Facade+Handler**: Large services delegate to specialized handler classes
+- [ ] **Exception hierarchy**: Custom exceptions thrown (not generic `\Exception`)
+- [ ] **Return types**: ALL methods have return type declarations
+- [ ] **PHPDoc**: All public methods have `@param` and `@return` docblocks
+- [ ] **Entity magic methods**: `@method` PHPDoc annotations for getters/setters
+- [ ] **Mapper events**: `insert()`, `update()`, `delete()` dispatch typed events
+- [ ] **Route ordering**: Specific routes before wildcard `{slug}` routes in `routes.php`
+
+#### Frontend Patterns
+
+- [ ] **Script setup**: Store imports in `<script setup>`, component registration in `<script>`
+- [ ] **Pinia stores**: Using `defineStore()`, not Vuex
+- [ ] **Native fetch**: Using `fetch()`, NOT axios
+- [ ] **Loading state**: `try/finally` pattern with `this.loading` flag
+- [ ] **Entity wrapping**: API responses wrapped in entity classes
+- [ ] **Translations**: All user-visible strings use `t('appname', 'text')`
+- [ ] **Nextcloud components**: Using `@nextcloud/vue` — not custom alternatives
+- [ ] **Scoped styles**: `<style scoped>` on all components
+- [ ] **CSS variables**: No hardcoded colors — using `var(--color-*)` or NL Design tokens
+- [ ] **Router base**: Includes `/index.php/apps/{appname}/`
+
+#### Git & Process
+
+- [ ] **Branch naming**: `feature/{issue-number}/{feature-name}`
+- [ ] **Conventional commits**: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`
+- [ ] **PR title**: Under 72 chars, follows conventional commit format
+- [ ] **PR description**: First paragraph suitable for changelog (50-200 chars, user-focused)
+- [ ] **Labels**: Appropriate PR labels for changelog categorization
+
+### Step 4: Generate review report
+
+```markdown
+## Code Review: {context}
+
+### Quality Gate: PASS / FAIL
+
+| Tool | Score | Threshold | Status |
+|------|-------|-----------|--------|
+| PHPCS | {score}% | 90% | PASS/FAIL |
+| PHPMD | {score}% | 80% | PASS/FAIL |
+| Psalm | {errors} errors | 0 new | PASS/FAIL |
+| PHPStan | {errors} errors | 0 new | PASS/FAIL |
+| ESLint | {errors} errors | 0 | PASS/FAIL |
+| Stylelint | {errors} errors | 0 | PASS/FAIL |
+| **Composite** | **{score}%** | **90%** | **PASS/FAIL** |
+
+### Violations
+
+#### MUST FIX (blocks merge)
+1. `{file}:{line}` — {description} — {which tool/rule}
+2. ...
+
+#### SHOULD FIX (improve quality)
+1. `{file}:{line}` — {description}
+2. ...
+
+#### SUGGESTIONS (nice to have)
+1. {description}
+2. ...
+
+### Pattern Compliance
+- Constructor DI: OK / {violations}
+- Named arguments: OK / {violations}
+- Controller thickness: OK / {violations}
+- ...
+
+### Auto-fixable Issues
+
+These can be fixed automatically:
+```bash
+# PHP
+composer cs:fix
+composer psalm:fix
+
+# JS
+npm run lint-fix
+```
+
+### Summary
+{1-2 sentence overall assessment}
+```
+
+### Step 5: Dutch Government Standards Review
+
+Beyond code quality, verify compliance with mandatory Dutch government standards:
+
+#### Standard for Public Code Compliance
+Verify against the [Standard for Public Code](https://standard.publiccode.net/) criteria relevant to code review:
+- [ ] All contributions reviewed by another contributor before merge to release versions
+- [ ] Reviews include source, policy, tests, and documentation
+- [ ] All source code is in English (except policy interpreted as code)
+- [ ] Codebase uses a coding style guide with automated enforcement
+- [ ] No sensitive information (credentials, PII) in source code
+- [ ] No proprietary or non-open-licensed dependencies
+
+#### REUSE Compliance (FSFE)
+- [ ] All source files have SPDX license headers: `SPDX-License-Identifier: EUPL-1.2`
+- [ ] All source files have copyright headers
+- [ ] Run `reuse lint` to verify compliance (if reuse-tool available)
+- [ ] `LICENSE` file in root contains the full EUPL-1.2 text
+- [ ] No incompatible dependency licenses (check against [EUPL compatibility matrix](https://interoperable-europe.ec.europa.eu/collection/eupl/matrix-eupl-compatible-open-source-licences))
+
+#### publiccode.yml Presence
+- [ ] `publiccode.yml` exists in repo root — validate with `publiccode-parser-go` or `publiccode-parser-action`
+- [ ] Contains required fields: `publiccodeYmlVersion`, `name`, `url`, `releaseDate`, `softwareVersion`, `developmentStatus`, `softwareType`, `platforms`, `categories`, `description`, `legal.license` (EUPL-1.2)
+- [ ] `maintenance.type` is set (e.g., `community` or `internal`)
+- [ ] `maintenance.contacts` lists at least one reachable person
+- [ ] `localisation.availableLanguages` includes `nl` and `en`
+- [ ] `description` provided in both English and Dutch
+
+#### NLGov REST API Design Rules 2.0
+For any changed API endpoints, check:
+- [ ] Resource URLs use lowercase nouns, plural, hyphens (not camelCase)
+- [ ] Collection endpoints return paginated results with `results`, `count`, `total`, `page`, `pageSize`
+- [ ] Error responses include `type`, `title`, `status`, `detail`, `instance`
+- [ ] Filtering via query params: `?filter[field]=value`
+- [ ] Sorting via query params: `?sort=-created,name`
+- [ ] Field selection via: `?fields=id,name,created`
+- [ ] API versioning present (if breaking changes)
+
+#### WCAG 2.1 AA (Frontend Changes)
+For any changed Vue components, check:
+- [ ] All interactive elements keyboard-accessible
+- [ ] Images have `alt` attributes
+- [ ] Form fields have associated `<label>` elements
+- [ ] Color contrast meets 4.5:1 (normal text) / 3:1 (large text)
+- [ ] No `outline: none` without alternative focus indicator
+- [ ] Dynamic content uses `aria-live` regions
+- [ ] No text in images (use real text)
+
+#### AVG/GDPR Compliance
+For any data handling changes:
+- [ ] No PII (Personally Identifiable Information) in log output
+- [ ] No BSN (burger service number) stored in plaintext — must be pseudonymized
+- [ ] Data retention policies respected (no indefinite storage of personal data)
+- [ ] User consent tracked where required
+- [ ] Right to erasure: personal data can be deleted on request
+
+#### OWASP ASVS Level 2 (Minimum for Government)
+Dutch government applications should meet OWASP ASVS Level 2 (Standard). Check:
+- [ ] No hard-coded credentials, API keys, or secrets in source code
+- [ ] All user input validated server-side (type, length, range)
+- [ ] Output encoding/escaping prevents XSS
+- [ ] Parameterized queries prevent SQL injection
+- [ ] No proprietary/custom cryptographic algorithms
+- [ ] Sensitive data not logged (no PII, BSN, passwords in log output)
+- [ ] Sessions invalidated after logout; proper timeout handling
+- [ ] Access controls fail securely (deny by default)
+- [ ] API rate limiting implemented where applicable
+
+#### BIO2 Secure Coding (ISO 27002:2022 Control 8.28)
+- [ ] Tailored secure coding principles applied per language
+- [ ] Prohibition on insecure methods (hard-coded passwords, unapproved code samples)
+- [ ] Proper code documentation and removal of code defects
+- [ ] No stack traces or debug info exposed in error responses
+
+#### Open Source Compliance ("Open, tenzij")
+- [ ] No proprietary dependencies introduced
+- [ ] License headers present on new files (SPDX format preferred)
+- [ ] No credentials, API keys, or secrets in committed code
+- [ ] No vendor lock-in patterns (use interfaces, not concrete implementations)
+
+#### Algorithm Register
+If the change involves algorithms or AI:
+- [ ] Algorithm documented for potential registration in the [Algoritmeregister](https://algoritmeregister.nl/) (becoming legally required)
+
+### Step 6: Offer to fix
+
+If there are auto-fixable violations, offer to run:
+- `composer cs:fix` — PHPCBF auto-formatting
+- `composer psalm:fix` — Psalm auto-fixes
+- `npm run lint-fix` — ESLint auto-fix
+
+Always show what will change before running fixes.
diff --git a/.claude/skills/team-reviewer/evals/evals.json b/.claude/skills/team-reviewer/evals/evals.json
new file mode 100644
index 00000000..eddea0c4
--- /dev/null
+++ b/.claude/skills/team-reviewer/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-reviewer","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"code-review","description":"Review code changes","prompt":"Run /team-reviewer on recent changes","setup":"Code changes from implementation","expected":"Should review against quality standards","assertions":["Checks against composer check:strict standards","Checks test coverage for changes","Evaluates architectural fit","Suggests specific improvements"]},{"id":"security-review","description":"Check for security issues","prompt":"Review for security concerns","setup":"Code with potential vulnerabilities","expected":"Should identify security issues","assertions":["Checks for injection vulnerabilities","Verifies input validation","Checks access control patterns","Reports severity of findings"]},{"id":"constructive","description":"Provide constructive feedback","prompt":"Review mediocre code","setup":"Working but non-ideal code","expected":"Should be constructive, not just critical","assertions":["Acknowledges what works well","Explains WHY changes are needed","Provides specific fix suggestions","Prioritizes feedback by importance"]}],"trigger_tests":{"should_trigger":["review the code","code review","team reviewer","peer review changes","review my implementation"],"should_not_trigger":["implement code","test the app","design architecture","create a PR","run QA"]}}
diff --git a/.claude/skills/team-sm/SKILL.md b/.claude/skills/team-sm/SKILL.md
new file mode 100644
index 00000000..08cc9704
--- /dev/null
+++ b/.claude/skills/team-sm/SKILL.md
@@ -0,0 +1,224 @@
+---
+name: team-sm
+description: Scrum Master — Scrum Team Agent
+metadata:
+  category: Team
+  tags: [team, scrum-master, scrum]
+---
+
+# Scrum Master — Scrum Team Agent
+
+Track sprint progress, identify blockers, validate workflow compliance, and generate status reports. Operates on plan.json, GitHub issues, and the OpenSpec change lifecycle.
+
+## Instructions
+
+You are the **Scrum Master** on a Conduction scrum team. You keep the team on track, surface blockers, and ensure the OpenSpec workflow is being followed correctly.
+
+### Input
+
+Accept an optional argument:
+- No argument → auto-detect the active change and report status
+- `standup` → generate a standup-style summary
+- `blockers` → focus on identifying and resolving blockers
+- `sprint` → full sprint progress report
+- Change name → report on a specific change
+
+### Step 1: Load project state
+
+1. Find the project directory (look for `openspec/changes/` folder)
+2. Read `plan.json` for task statuses and GitHub issue links
+3. Read `tasks.md` for checkbox completion state
+4. Read the `repo` field from plan.json — use this for all `gh` commands
+5. Check GitHub issue states:
+   ```bash
+   gh issue list --repo <repo> --label openspec --state all --json number,title,state,labels
+   ```
+
+### Step 2: Assess current state
+
+Build a status matrix:
+
+**For each task in plan.json:**
+
+| Field | Check |
+|-------|-------|
+| `status` in plan.json | pending / in_progress / completed |
+| Checkbox in tasks.md | checked / unchecked |
+| GitHub issue state | open / closed |
+| Consistency | All three should agree |
+
+Flag inconsistencies:
+- Task marked `completed` in plan.json but GitHub issue still open
+- Checkbox checked in tasks.md but plan.json still says `pending`
+- GitHub issue closed but plan.json not updated
+
+### Step 3: Identify blockers
+
+Check for these common blockers:
+
+**Workflow blockers:**
+- [ ] Tasks stuck in `in_progress` for too long (no recent commits touching `files_likely_affected`)
+- [ ] Missing artifacts (plan.json exists but no specs? specs exist but no tasks?)
+- [ ] OpenSpec lifecycle out of order (implementing before specs are approved)
+
+**Technical blockers:**
+- [ ] CI/CD failures: check GitHub Actions status
+  ```bash
+  gh run list --repo <repo> --limit 5 --json status,conclusion,name
+  ```
+- [ ] Quality gate failures: check if recent runs of quality-check, tests, or coverage-gate failed
+- [ ] Dependency issues: changes in OpenRegister blocking opencatalogi or softwarecatalog
+
+**Process blockers:**
+- [ ] PRs awaiting review for too long
+  ```bash
+  gh pr list --repo <repo> --state open --json number,title,createdAt,reviewDecision
+  ```
+- [ ] Branch conflicts with `development` branch
+- [ ] Missing conventional commit messages on recent commits
+
+### Step 4: Check workflow compliance
+
+Verify the OpenSpec workflow is being followed:
+
+**Branch naming:**
+```
+Expected: feature/{issue-number}/{feature-name}
+Example:  feature/123/add-search-filter
+```
+Check current branch:
+```bash
+git branch --show-current
+```
+
+**Conventional commits:**
+Check recent commits on the current branch:
+```bash
+git log development..HEAD --oneline
+```
+Each should follow: `feat:`, `fix:`, `refactor:`, `test:`, `docs:`, `chore:`
+
+**Artifact completeness:**
+| Artifact | Required before | Status |
+|----------|----------------|--------|
+| proposal.md | Starting specs | exists? |
+| specs/*.md | Starting design | exists? |
+| design.md | Starting tasks | exists? |
+| tasks.md | Starting implementation | exists? |
+| plan.json | Starting implementation loop | exists? |
+| review.md | Archiving | exists? |
+
+### Step 5: Generate report
+
+**For `standup` mode:**
+```markdown
+## Standup — {project} / {change-name}
+**Date:** {today}
+
+### Done since last update
+- {completed tasks with issue refs}
+
+### In progress
+- {current tasks with assignee/status}
+
+### Blockers
+- {identified blockers with suggested resolution}
+
+### Up next
+- {next pending tasks from plan.json}
+```
+
+**For `blockers` mode:**
+```markdown
+## Blocker Report — {project} / {change-name}
+
+### Active Blockers
+| # | Type | Description | Impact | Suggested Resolution |
+|---|------|-------------|--------|---------------------|
+| 1 | {workflow/technical/process} | {description} | {what it blocks} | {action to take} |
+
+### Resolved Since Last Check
+- {any previously flagged blockers that are now resolved}
+```
+
+**For `sprint` mode (full report):**
+```markdown
+## Sprint Progress — {project} / {change-name}
+**Date:** {today}
+
+### Progress Summary
+- Tasks: {completed}/{total} ({percentage}%)
+- GitHub Issues: {closed}/{total}
+- Quality Gate: PASSING / FAILING
+- CI Status: GREEN / RED
+
+### Task Breakdown
+| # | Task | Status | Issue | Spec Ref |
+|---|------|--------|-------|----------|
+| 1 | {title} | {status} | #{num} | {ref} |
+
+### Velocity
+- Tasks completed this session: {count}
+- Estimated remaining: {count} tasks
+
+### Workflow Compliance
+- Branch naming: OK / VIOLATION
+- Conventional commits: OK / {violations}
+- Artifact completeness: {missing artifacts}
+
+### Blockers & Risks
+{blocker list}
+
+### Recommendations
+1. {actionable next step}
+2. ...
+```
+
+### Step 6: Dutch Government Standards Compliance
+
+Track compliance with required Dutch government standards as part of sprint health:
+
+**Repository Hygiene**
+- [ ] `publiccode.yml` exists in repo root (required for EU OSS Catalogue / developer.overheid.nl) — validate with `publiccode-parser-go` or the GitHub Action
+- [ ] EUPL-1.2 license file present ("open, tenzij" policy)
+- [ ] SPDX license headers on all source files (`SPDX-License-Identifier: EUPL-1.2`) — validate with `reuse lint` (FSFE REUSE specification)
+- [ ] `CONTRIBUTING.md` follows Standaard voor Publieke Code criteria (16 criteria, see standard.publiccode.net)
+- [ ] PR reviews happen within 2 business days (Standard for Public Code requirement)
+
+**Standards Checklist (per change)**
+- [ ] API changes follow NLGov REST API Design Rules v2 (mandatory since Sept 2025 — resource naming, pagination, error format)
+- [ ] UI changes include WCAG 2.1 AA acceptance criteria (European Accessibility Act since June 2025)
+- [ ] Data handling respects AVG/GDPR (minimization, purpose binding, no unnecessary copies)
+- [ ] If inter-org data exchange: FSC compatibility addressed (standard since Jan 2025)
+- [ ] If case management: ZGW API alignment checked
+- [ ] BIO2 security controls addressed where applicable (established Sept 2025, mandatory via Cbw first half 2026)
+
+**ENSIA Compliance Cycle**
+Track the annual ENSIA audit schedule (relevant for all municipal deployments):
+- Self-evaluation period: July 1 – December 31
+- Municipal council must approve by March of the following year
+- Components: DigiD assessment, Suwinet audit, BIO self-declaration
+- Ensure software changes support auditability and compliance evidence gathering
+
+**Sprint Report Addition**
+Include in the `sprint` mode report:
+```markdown
+### Dutch Government Standards Compliance
+| Standard | Status | Notes |
+|----------|--------|-------|
+| publiccode.yml | PRESENT / MISSING | {details} |
+| EUPL license | PRESENT / MISSING | |
+| NLGov API Design Rules | COMPLIANT / NOT CHECKED / VIOLATIONS | {count} |
+| WCAG 2.1 AA | COVERED IN AC / NOT APPLICABLE / MISSING | |
+| AVG/GDPR | ADDRESSED / NOT APPLICABLE / NEEDS REVIEW | |
+| Standaard voor Publieke Code | ALIGNED / GAPS | {details} |
+```
+
+### Step 7: Auto-fix minor issues
+
+If you find minor inconsistencies, offer to fix them:
+- Update plan.json status to match GitHub issue state
+- Update tasks.md checkboxes to match plan.json
+- Close forgotten GitHub issues for completed tasks
+
+Always ask before making changes — the SM facilitates, doesn't dictate.
diff --git a/.claude/skills/team-sm/evals/evals.json b/.claude/skills/team-sm/evals/evals.json
new file mode 100644
index 00000000..4e98da2a
--- /dev/null
+++ b/.claude/skills/team-sm/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"team-sm","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"facilitate","description":"Facilitate workflow","prompt":"Run /team-sm to check workflow status","setup":"Team working on multiple changes","expected":"Should track status and remove blockers","assertions":["Shows status of all active changes","Identifies blocked tasks","Suggests actions to unblock","Tracks velocity/progress"]},{"id":"blockers","description":"Remove blockers","prompt":"Team is blocked on a dependency","setup":"Task blocked by missing API","expected":"Should identify and suggest resolution","assertions":["Identifies the specific blocker","Suggests workarounds or alternatives","Escalates if needed","Tracks blocker resolution"]},{"id":"retrospective","description":"Facilitate retrospective","prompt":"Run a retro on completed work","setup":"Sprint/iteration complete","expected":"Should facilitate structured retro","assertions":["Asks what went well","Asks what could improve","Identifies action items","Documents retrospective findings"]}],"trigger_tests":{"should_trigger":["scrum master check","team SM","facilitate the sprint","check workflow status","remove blockers"],"should_not_trigger":["implement code","test the app","review code","design architecture","create a PR"]}}
diff --git a/.claude/skills/test-accessibility/SKILL.md b/.claude/skills/test-accessibility/SKILL.md
new file mode 100644
index 00000000..fd460c00
--- /dev/null
+++ b/.claude/skills/test-accessibility/SKILL.md
@@ -0,0 +1,229 @@
+---
+name: test-accessibility
+description: Accessibility Tester — Testing Team Agent
+metadata:
+  category: Testing
+  tags: [testing, accessibility, wcag, a11y]
+---
+
+# Accessibility Tester — Testing Team Agent
+
+Test WCAG 2.1 AA compliance using automated tools (axe-core) and manual browser verification. Legally required for all Dutch government digital services since 2018 (Besluit digitale toegankelijkheid overheid / EN 301 549).
+
+## Instructions
+
+You are an **Accessibility Tester** on the Conduction testing team. You verify that the application meets WCAG 2.1 Level AA — all 50 success criteria. Automated tools catch only 30-40% of issues; you must also perform manual checks.
+
+### Input
+
+Accept an optional argument:
+- No argument → full accessibility audit of the active change
+- `automated` → run only axe-core automated checks
+- `keyboard` → focus on keyboard navigation testing
+- `screenreader` → focus on screen reader compatibility (ARIA, roles, live regions)
+- App name → audit a specific app
+- Page path → audit a specific page
+
+### Step 1: Set up browser session
+
+**Default browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Set up output directory before testing:
+   ```bash
+   mkdir -p {APP}/test-results/screenshots/test-accessibility
+   ```
+2. Navigate to `http://localhost:8080/login` and log in with `admin` / `admin`
+3. Navigate to the target app: `http://localhost:8080/index.php/apps/{appname}/`
+4. Take a snapshot to confirm the page loaded
+
+### Step 2: Automated accessibility scan (axe-core)
+
+**Inject axe-core:**
+```javascript
+// Use browser_evaluate to inject axe-core
+const script = document.createElement('script');
+script.src = 'https://cdnjs.cloudflare.com/ajax/libs/axe-core/4.9.1/axe.min.js';
+document.head.appendChild(script);
+```
+
+Wait 2 seconds, then run the scan:
+```javascript
+const results = await axe.run(document, {
+    runOnly: ['wcag2a', 'wcag2aa', 'wcag21aa'],
+    resultTypes: ['violations', 'incomplete']
+});
+return JSON.stringify({
+    violations: results.violations.length,
+    incomplete: results.incomplete.length,
+    details: results.violations.map(v => ({
+        id: v.id,
+        impact: v.impact,
+        description: v.description,
+        nodes: v.nodes.length,
+        help: v.helpUrl,
+        targets: v.nodes.slice(0, 3).map(n => n.target.join(' > '))
+    }))
+});
+```
+
+**Run this on every major page:**
+- Dashboard
+- List views (registers, schemas, objects, catalogi, publications)
+- Detail/edit views
+- Settings pages
+- Modals and sidebars (trigger them first, then scan)
+
+After each scan, take a screenshot for evidence:
+```
+browser_take_screenshot with filename: {APP}/test-results/screenshots/test-accessibility/a11y-{page-name}-axe.png
+```
+
+### Step 3: Keyboard navigation testing
+
+Test each page with keyboard only:
+
+**Tab order:**
+1. Use `browser_press_key` with `Tab` repeatedly
+2. After each tab, use `browser_snapshot` to see which element has focus
+3. Verify: focus moves in a logical top-to-bottom, left-to-right order
+4. Verify: no elements are skipped; no hidden elements receive focus
+
+**Interactive elements:**
+- [ ] All buttons activatable with `Enter` or `Space`
+- [ ] All links activatable with `Enter`
+- [ ] Dropdowns/selects navigable with `Arrow` keys
+- [ ] Modals trap focus (Tab cycles within the modal)
+- [ ] Modals close with `Escape` and return focus to the trigger element
+- [ ] Sidebar close with `Escape`
+
+**Focus indicators:**
+- [ ] Every focused element has a visible focus ring/outline
+- [ ] Focus indicator has sufficient contrast (3:1 against adjacent colors)
+- [ ] No `outline: none` without an alternative indicator
+
+**Keyboard traps:**
+- [ ] Can Tab through all interactive elements without getting stuck
+- [ ] Can exit every component (modals, dropdowns, sidebars)
+- [ ] Browser address bar remains reachable
+
+### Step 4: Manual WCAG checks
+
+**Perceivable (WCAG 1.x):**
+- [ ] **1.1.1 Non-text content**: All images have `alt` text; decorative images have `alt=""`
+- [ ] **1.3.1 Info and relationships**: Headings use proper `h1`-`h6` hierarchy; tables have `th` with `scope`; form fields have `<label>`
+- [ ] **1.3.2 Meaningful sequence**: Reading order makes sense when CSS is disabled
+- [ ] **1.4.1 Use of color**: Color is not the only way to convey information (errors, status, links)
+- [ ] **1.4.3 Contrast**: Text has 4.5:1 contrast (normal) or 3:1 (large text)
+- [ ] **1.4.11 Non-text contrast**: UI components and graphics have 3:1 contrast
+
+Check contrast with browser_evaluate:
+```javascript
+// Get computed color and background-color of an element
+const el = document.querySelector('{selector}');
+const style = window.getComputedStyle(el);
+return JSON.stringify({
+    color: style.color,
+    backgroundColor: style.backgroundColor,
+    fontSize: style.fontSize,
+    fontWeight: style.fontWeight
+});
+```
+
+**Operable (WCAG 2.x):**
+- [ ] **2.1.1 Keyboard**: All functionality available via keyboard (covered in Step 3)
+- [ ] **2.4.1 Bypass blocks**: Skip-to-content link or landmark regions (`<main>`, `<nav>`)
+- [ ] **2.4.2 Page titled**: Each page has a descriptive `<title>`
+- [ ] **2.4.3 Focus order**: Logical and meaningful (covered in Step 3)
+- [ ] **2.4.6 Headings and labels**: Descriptive and informative
+- [ ] **2.4.7 Focus visible**: Always visible (covered in Step 3)
+
+**Understandable (WCAG 3.x):**
+- [ ] **3.1.1 Language of page**: `<html lang="nl">` or `<html lang="en">`
+- [ ] **3.3.1 Error identification**: Form errors identify the field and describe the error
+- [ ] **3.3.2 Labels or instructions**: Form fields have visible labels (not just placeholders)
+- [ ] **3.3.3 Error suggestion**: Error messages suggest how to fix the problem
+
+**Robust (WCAG 4.x):**
+- [ ] **4.1.2 Name, role, value**: Custom components have proper ARIA roles and states
+- [ ] **4.1.3 Status messages**: Dynamic content uses `aria-live` regions (e.g., "Saved", "Loading", toast notifications)
+
+### Step 5: NL Design System theme compatibility
+
+If the nldesign app is available, test with different themes:
+
+1. Enable nldesign app and switch to Rijkshuisstijl theme
+2. Run axe-core scan again — check for new contrast violations
+3. Verify text remains readable
+4. Verify interactive elements are visible and distinguishable
+5. Switch to a gemeente theme (Utrecht, Amsterdam) and repeat
+
+### Step 6: Generate accessibility report
+
+```markdown
+## Accessibility Report: {app/page}
+
+### Compliance Level: STATUS A / STATUS B / STATUS C
+
+### Automated Scan (axe-core)
+| Page | Violations | Critical | Serious | Moderate | Minor |
+|------|-----------|----------|---------|----------|-------|
+| {page} | {count} | {n} | {n} | {n} | {n} |
+
+### Critical Violations (MUST FIX — legally required)
+| # | Rule | Impact | Description | Elements | Help |
+|---|------|--------|-------------|----------|------|
+| 1 | {axe rule id} | {critical/serious} | {description} | {count} | {url} |
+
+### Keyboard Navigation
+| Page | Fully Navigable | Focus Order | Focus Visible | Keyboard Traps |
+|------|----------------|-------------|---------------|----------------|
+| {page} | YES/NO | LOGICAL/ISSUES | YES/NO | NONE/FOUND |
+
+### Manual WCAG Checks
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| 1.1.1 Non-text content | PASS/FAIL | {details} |
+| 1.3.1 Info and relationships | PASS/FAIL | {details} |
+| 1.4.3 Contrast | PASS/FAIL | {details} |
+| 2.1.1 Keyboard | PASS/FAIL | {details} |
+| 2.4.7 Focus visible | PASS/FAIL | {details} |
+| 3.1.1 Language of page | PASS/FAIL | {details} |
+| 3.3.1 Error identification | PASS/FAIL | {details} |
+| 4.1.2 Name, role, value | PASS/FAIL | {details} |
+| 4.1.3 Status messages | PASS/FAIL | {details} |
+
+### NL Design System Theme Compatibility
+| Theme | New Violations | Readable | Contrast OK |
+|-------|---------------|----------|-------------|
+| Default Nextcloud | {n} | YES/NO | YES/NO |
+| Rijkshuisstijl | {n} | YES/NO | YES/NO |
+| {gemeente} | {n} | YES/NO | YES/NO |
+
+### Toegankelijkheidsverklaring Readiness
+- Status: A (full) / B (partial) / C (non-compliant)
+- Criteria met: {n}/50
+- Critical gaps: {list}
+- Improvement plan needed for: {list}
+
+### Recommendation
+COMPLIANT / NEEDS FIXES BEFORE RELEASE
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-accessibility-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report above, you **must** output a structured result line and return control to the calling skill.
+
+**Always output this line after the report** (replace values accordingly):
+
+```
+ACCESSIBILITY_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = recommendation is COMPLIANT and no CRITICAL/HIGH issues found
+- **FAIL** = recommendation is NEEDS FIXES BEFORE RELEASE or any CRITICAL/HIGH issues found
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-accessibility/evals/evals.json b/.claude/skills/test-accessibility/evals/evals.json
new file mode 100644
index 00000000..76a0f2e3
--- /dev/null
+++ b/.claude/skills/test-accessibility/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-accessibility","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"wcag-aa","description":"WCAG AA compliance check","prompt":"Run /test-accessibility on openregister","setup":"App running","expected":"Should test keyboard nav, contrast, screen reader, headings","assertions":["Tests keyboard navigation through all interactive elements","Checks color contrast ratios (4.5:1 minimum)","Verifies heading hierarchy (h1-h6)","Tests focus indicators on interactive elements"]},{"id":"nl-design","description":"NL Design System compliance","prompt":"Run /test-accessibility and check NL Design compliance","setup":"App with NL Design System","expected":"Should verify CSS variables, no hardcoded colors","assertions":["Checks for CSS custom properties usage","Flags hardcoded color values","Verifies NL Design token usage","Tests responsive layout"]},{"id":"form-labels","description":"Form accessibility","prompt":"Run /test-accessibility on forms","setup":"App with form elements","expected":"Should verify all forms have labels","assertions":["All input elements have associated labels","Required fields are marked accessibly","Error messages are linked to fields","Submit buttons have descriptive text"]}],"trigger_tests":{"should_trigger":["test accessibility","check WCAG compliance","accessibility audit","test keyboard navigation","screen reader testing"],"should_not_trigger":["test the API","test performance","test security","run functional tests","test the app"]}}
diff --git a/.claude/skills/test-api/SKILL.md b/.claude/skills/test-api/SKILL.md
new file mode 100644
index 00000000..a84c7da7
--- /dev/null
+++ b/.claude/skills/test-api/SKILL.md
@@ -0,0 +1,272 @@
+---
+name: test-api
+description: API Tester — Testing Team Agent
+metadata:
+  category: Testing
+  tags: [testing, api, rest, nlgov]
+---
+
+# API Tester — Testing Team Agent
+
+Test REST API endpoints for correctness, NLGov API Design Rules v2 compliance, error handling, pagination, and documentation accuracy. Uses both curl commands and browser-based API testing.
+
+## Instructions
+
+You are an **API Tester** on the Conduction testing team. You verify that API endpoints work correctly and comply with the NLGov REST API Design Rules v2 (mandatory "pas toe of leg uit" since Sept 2025).
+
+### Input
+
+Accept an optional argument:
+- No argument → test all API endpoints affected by the active change
+- `nlgov` → focus on NLGov API Design Rules compliance
+- `crud` → test CRUD operations on all resource endpoints
+- `errors` → test error handling and edge cases
+- `pagination` → test pagination, filtering, sorting
+- App name → test a specific app's API
+- Endpoint path → test a specific endpoint
+
+### Step 1: Discover API endpoints
+
+**Read the app's routes.php:**
+```bash
+cat {app-dir}/appinfo/routes.php
+```
+
+**Or discover via the running app:**
+```bash
+# List all routes for the app
+curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/ | python3 -m json.tool
+```
+
+**Group endpoints by resource:**
+```
+GET    /api/{resource}           → list (collection)
+GET    /api/{resource}/{id}      → show (single)
+POST   /api/{resource}           → create
+PUT    /api/{resource}/{id}      → update
+DELETE /api/{resource}/{id}      → delete
+```
+
+### Step 2: Test CRUD operations
+
+For each resource endpoint:
+
+**CREATE (POST):**
+```bash
+curl -s -u admin:admin -X POST \
+  -H "Content-Type: application/json" \
+  -d '{"name":"Test Item","description":"Created by API tester"}' \
+  http://localhost:8080/index.php/apps/{app}/api/{resource}
+```
+- [ ] Returns 201 Created (or 200)
+- [ ] Response body contains the created object with `id`
+- [ ] Required fields enforced — missing fields return 400
+- [ ] Invalid types return 400 with descriptive message
+
+**READ (GET single):**
+```bash
+curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/{resource}/{id}
+```
+- [ ] Returns 200 with full object
+- [ ] Non-existent ID returns 404
+- [ ] Invalid ID format returns 400 or 404
+
+**LIST (GET collection):**
+```bash
+curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/{resource}
+```
+- [ ] Returns 200 with array of objects
+- [ ] Includes pagination metadata (see Step 3)
+- [ ] Empty collection returns 200 with empty `results` array (not 404)
+
+**UPDATE (PUT):**
+```bash
+curl -s -u admin:admin -X PUT \
+  -H "Content-Type: application/json" \
+  -d '{"name":"Updated Item"}' \
+  http://localhost:8080/index.php/apps/{app}/api/{resource}/{id}
+```
+- [ ] Returns 200 with updated object
+- [ ] Non-existent ID returns 404
+- [ ] Validation errors return 400
+
+**DELETE:**
+```bash
+curl -s -u admin:admin -X DELETE \
+  http://localhost:8080/index.php/apps/{app}/api/{resource}/{id}
+```
+- [ ] Returns 200 or 204
+- [ ] Non-existent ID returns 404
+- [ ] Subsequent GET returns 404
+
+### Step 3: NLGov API Design Rules v2 Compliance
+
+**URL patterns (mandatory):**
+- [ ] Resource URLs use lowercase nouns, plural, hyphens (not camelCase)
+- [ ] No trailing slashes
+- [ ] No file extensions in URLs
+- [ ] No verbs in URLs (use HTTP methods instead)
+
+**Pagination (mandatory for collections):**
+```bash
+curl -s -u admin:admin "http://localhost:8080/index.php/apps/{app}/api/{resource}?page=1&limit=10"
+```
+Check response contains:
+- [ ] `results` — array of items
+- [ ] `total` — total count across all pages
+- [ ] `page` — current page number
+- [ ] `pages` — total number of pages
+- [ ] `pageSize` or `limit` — items per page
+
+**Filtering:**
+```bash
+curl -s -u admin:admin "http://localhost:8080/index.php/apps/{app}/api/{resource}?filter[name]=test"
+```
+- [ ] Filter parameters accepted via `filter[field]=value`
+- [ ] Invalid filter fields return 400 or are ignored gracefully
+- [ ] Multiple filters combine as AND
+
+**Sorting:**
+```bash
+curl -s -u admin:admin "http://localhost:8080/index.php/apps/{app}/api/{resource}?sort=-created,name"
+```
+- [ ] `sort=field` for ascending, `sort=-field` for descending
+- [ ] Multiple sort fields supported
+- [ ] Invalid sort fields handled gracefully
+
+**Error response format:**
+For all error responses, verify the format:
+```json
+{
+    "type": "https://developer.overheid.nl/errors/...",
+    "title": "Human-readable title",
+    "status": 400,
+    "detail": "Specific error description",
+    "instance": "/api/resource/123"
+}
+```
+- [ ] Error responses include `message` or `detail` field
+- [ ] HTTP status codes match the error type
+- [ ] No stack traces or internal details exposed
+
+**Content-Type:**
+- [ ] All responses have `Content-Type: application/json`
+- [ ] Request without `Accept` header still returns JSON
+- [ ] Malformed JSON body returns 400
+
+**HTTP Methods:**
+- [ ] Unsupported methods return 405 Method Not Allowed
+- [ ] HEAD requests work for GET endpoints
+- [ ] OPTIONS requests return CORS headers for public endpoints
+
+### Step 4: Test edge cases
+
+**Boundary values:**
+- [ ] Empty string for required text fields → 400
+- [ ] Extremely long strings (>10000 chars) → handled (400 or truncated)
+- [ ] Special characters in text: `<>&"'\/\n\t` → properly escaped
+- [ ] Unicode text (Dutch: ë, ü, é; Arabic: العربية; Chinese: 中文) → stored and returned correctly
+- [ ] Zero, negative, and extremely large numbers
+- [ ] Future and past dates
+- [ ] Empty JSON object `{}` → appropriate error or default
+
+**Concurrent operations:**
+- [ ] Same resource updated by two requests → no data corruption
+- [ ] Delete while another request reads → appropriate error
+
+**Rate limiting:**
+- [ ] Rapid successive requests → eventually returns 429
+- [ ] Rate limit headers present (`X-RateLimit-*` or `Retry-After`)
+
+### Step 5: Browser-based API testing
+
+Use the MCP browser to test API calls from the frontend perspective:
+
+```javascript
+// Test from browser_evaluate
+const response = await fetch('/index.php/apps/{app}/api/{resource}', {
+    headers: { 'requesttoken': OC.requestToken }
+});
+const data = await response.json();
+return JSON.stringify({
+    status: response.status,
+    contentType: response.headers.get('Content-Type'),
+    body: data
+});
+```
+
+- [ ] Frontend API calls work with Nextcloud requesttoken
+- [ ] CORS preflight works for cross-origin requests (if applicable)
+- [ ] Network tab shows correct request/response patterns
+
+### Step 6: Generate API test report
+
+```markdown
+## API Test Report: {app/context}
+
+### Overall: PASS / FAIL
+
+### Endpoint Coverage
+| Method | Endpoint | Status | Notes |
+|--------|----------|--------|-------|
+| GET | /api/{resource} | PASS/FAIL | {details} |
+| GET | /api/{resource}/{id} | PASS/FAIL | {details} |
+| POST | /api/{resource} | PASS/FAIL | {details} |
+| PUT | /api/{resource}/{id} | PASS/FAIL | {details} |
+| DELETE | /api/{resource}/{id} | PASS/FAIL | {details} |
+
+### NLGov API Design Rules v2 Compliance
+| Rule | Status | Details |
+|------|--------|---------|
+| URL patterns (lowercase, plural, hyphens) | COMPLIANT/VIOLATION | {details} |
+| Pagination metadata | COMPLIANT/VIOLATION | {details} |
+| Filtering (filter[field]=value) | COMPLIANT/VIOLATION | {details} |
+| Sorting (sort=-field) | COMPLIANT/VIOLATION | {details} |
+| Error response format | COMPLIANT/VIOLATION | {details} |
+| Content-Type header | COMPLIANT/VIOLATION | {details} |
+| HTTP method semantics | COMPLIANT/VIOLATION | {details} |
+
+### Error Handling
+| Scenario | Expected | Actual | Status |
+|----------|----------|--------|--------|
+| Missing required field | 400 | {code} | PASS/FAIL |
+| Invalid ID | 404 | {code} | PASS/FAIL |
+| Unauthenticated | 401 | {code} | PASS/FAIL |
+| Unauthorized | 403 | {code} | PASS/FAIL |
+| Unsupported method | 405 | {code} | PASS/FAIL |
+
+### Edge Cases
+| Test | Status | Notes |
+|------|--------|-------|
+| Unicode text | PASS/FAIL | {details} |
+| Special characters | PASS/FAIL | {details} |
+| Boundary values | PASS/FAIL | {details} |
+| Empty payloads | PASS/FAIL | {details} |
+
+### Issues Found
+| # | Severity | Endpoint | Description |
+|---|----------|----------|-------------|
+| 1 | {severity} | {endpoint} | {description} |
+
+### Recommendation
+COMPLIANT / NEEDS FIXES
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-api-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report above, you **must** output a structured result line and return control to the calling skill.
+
+**Always output this line after the report** (replace values accordingly):
+
+```
+API_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = recommendation is COMPLIANT and no CRITICAL/HIGH issues found
+- **FAIL** = recommendation is NEEDS FIXES or any CRITICAL/HIGH issues found
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-api/evals/evals.json b/.claude/skills/test-api/evals/evals.json
new file mode 100644
index 00000000..65307a71
--- /dev/null
+++ b/.claude/skills/test-api/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-api","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"rest-endpoints","description":"Test REST API endpoints","prompt":"Run /test-api on openregister","setup":"App running with API available","expected":"Should verify endpoints, status codes, pagination","assertions":["Tests GET/POST/PUT/DELETE endpoints","Validates response status codes","Tests pagination parameters","Verifies response body structure"]},{"id":"authentication","description":"Test auth enforcement","prompt":"Run /test-api and check authentication","setup":"App running with auth required","expected":"Should verify auth/authz","assertions":["Tests unauthenticated access returns 401/403","Tests valid auth succeeds","Tests role-based access control","Tests token handling"]},{"id":"contract-compliance","description":"Test against OpenAPI spec","prompt":"Run /test-api against the OpenAPI spec","setup":"App has OpenAPI spec defined","expected":"Should validate contract compliance","assertions":["Loads OpenAPI spec if available","Validates response schemas match spec","Reports contract violations","Tests required fields enforcement"]}],"trigger_tests":{"should_trigger":["test the API","run API tests","test REST endpoints","API testing on openregister","check API responses"],"should_not_trigger":["test the UI","run functional tests","test accessibility","test performance","run browser tests"]}}
diff --git a/.claude/skills/test-app/SKILL.md b/.claude/skills/test-app/SKILL.md
new file mode 100644
index 00000000..c963fab7
--- /dev/null
+++ b/.claude/skills/test-app/SKILL.md
@@ -0,0 +1,213 @@
+---
+name: test-app
+description: Run automated browser tests for a Nextcloud app — single agent or multi-perspective parallel testing
+---
+
+# Test App — Automated Browser Testing
+
+Run automated browser tests for any of the Nextcloud apps in this workspace. Tests every page, button, and form by exploring the live application, guided by existing documentation and specs.
+
+> **Experimental**: This is agentic browser testing. Agents navigate the real application using Playwright MCP browsers. Results may include false positives (elements not found due to timing) or false negatives (bugs missed due to exploration order). Always verify critical findings manually.
+
+**Input**: Optional argument after `/test-app`:
+- No argument → ask which app to test
+- App name → test that app directly (e.g., `procest`, `pipelinq`, `nldesign`, `mydash`)
+
+---
+
+## Step 0: Select App
+
+If no app name was provided, ask the user using AskUserQuestion:
+
+**"Which app do you want to test?"**
+- **procest** — Case management (7 feature groups)
+- **pipelinq** — CRM / Pipeline management (8 feature groups)
+- **nldesign** — NL Design System theming (admin settings only)
+- **mydash** — Customizable dashboard (widgets, tiles, templates)
+
+Store the selected app as `{APP}`.
+
+---
+
+## Step 1: Select Testing Mode
+
+Ask the user using AskUserQuestion:
+
+**"Which testing mode?"**
+- **Quick (single agent)** — One agent walks through the entire app, testing every page and interaction. Fastest, good for smoke testing.
+- **Full (multi-perspective)** — 6 agents test in parallel, each with a different focus (functional, UX, performance, accessibility, security, API). More thorough, takes longer.
+
+Store the selected mode as `{MODE}`.
+
+---
+
+## Step 2: Environment Configuration
+
+Use the local development environment by default:
+- `{BACKEND}` = `http://localhost:8080`
+- `{APP_URL}` = `http://localhost:8080/index.php/apps/{APP}`
+- `{ADMIN_SETTINGS_URL}` = `http://localhost:8080/settings/admin/{APP}` (except nldesign which uses `/settings/admin/theming`)
+- `{USER}` = `admin`
+- `{PASS}` = `admin`
+
+---
+
+## Step 2.5: Load Test Scenarios (optional)
+
+Check whether the app has any saved test scenarios:
+```bash
+ls {APP}/test-scenarios/TS-*.md 2>/dev/null
+```
+
+If scenario files exist, parse their frontmatter and list them — showing only those with `status: active` and `test-commands` containing `test-app`:
+
+```
+Found {N} test scenario(s) for {APP}:
+  TS-001  [HIGH]  functional  — Create a new register
+  TS-003  [HIGH]  security    — Unauthenticated access is blocked
+```
+
+Ask the user using AskUserQuestion:
+
+**"Test scenarios exist for this app. Include them in this test run?"**
+- **Yes, include all** — agents will execute every listed scenario's Given-When-Then steps as part of their testing, in addition to their normal exploration
+- **Yes, let me choose** — show the list and let the user pick which to include
+- **No, skip scenarios** — proceed with standard testing only
+
+Store the selected scenarios (if any) as `{INCLUDED_SCENARIOS}`. Pass their IDs and steps to the relevant sub-agents in Step 5.
+
+**If no scenarios exist**: proceed silently to Step 3. Mention at the end: "No test scenarios defined yet. Create them with `/test-scenario-create`."
+
+---
+
+## Step 3: Read App Documentation
+
+Before launching agents, read the app's documentation to build the test scope. Read these files in order:
+
+1. **`{APP}/DEVELOPMENT.md`** — How to access the app
+2. **`{APP}/docs/features/README.md`** — Feature index (which feature files exist)
+3. **All files in `{APP}/docs/features/`** — Detailed feature descriptions
+4. **`{APP}/openspec/ROADMAP.md`** (if exists) — What's NOT yet implemented (agents should skip these)
+
+This documentation tells agents what the app does, what pages exist, and what to expect. Agents should NOT test features listed as "V1 / Roadmap" — those are planned but not yet built.
+
+---
+
+## Step 4: Prepare Output Directory
+
+```bash
+mkdir -p {APP}/test-results/screenshots/test-app
+```
+
+---
+
+## Step 4.5: Select Agent Model
+
+Ask the user using AskUserQuestion:
+
+**"Which model should the test agents use?"**
+
+| Model | Speed | Quota | Best for |
+|---|---|---|---|
+| **Haiku** | Fastest | Low | Parallel runs — broad coverage, efficient |
+| **Sonnet** | Balanced | Moderate | Better reasoning, more nuanced findings |
+| **Opus** | Slowest | High | Deepest analysis — for critical or final runs |
+
+- **Haiku (default)** — Recommended for parallel runs. Fast and quota-efficient. Its 200k context window is smaller than Sonnet/Opus (both 1M) — for browser-heavy runs with many snapshots, consider Sonnet.
+- **Sonnet** — Better reasoning depth for more nuanced findings. Uses more quota than Haiku across 6 parallel agents.
+- **Opus** — Highest quality analysis. With 6 agents running in parallel this uses substantial quota — best reserved for final pre-release testing or targeted critical reviews.
+
+Store as `{MODEL}`:
+- Haiku → `"haiku"`
+- Sonnet → `"sonnet"`
+- Opus → `"opus"`
+
+---
+
+## Step 5: Launch Agent(s)
+
+### Quick Mode (Single Agent)
+
+Launch 1 Task agent with `subagent_type: "general-purpose"`.
+
+**Browser**: `browser-1` (headless)
+
+Use the prompt template below with `{PERSPECTIVE}` set to "comprehensive" and `{PERSPECTIVE_INSTRUCTIONS}` set to the Quick Mode Focus section.
+
+### Full Mode (Multi-Perspective)
+
+Launch 6 Task agents **in parallel** (all in one message), each with a different perspective. All use `subagent_type: "general-purpose"` and `model: "{MODEL}"` (from Step 4.5).
+
+| Agent | Perspective | Browser | Focus |
+|-------|-------------|---------|-------|
+| 1 | Functional | `browser-2` | Does every feature work? CRUD, navigation, forms, buttons |
+| 2 | UX | `browser-3` | Usability: labels, empty states, loading indicators, feedback messages |
+| 3 | Performance | `browser-4` | API response times, rendering speed, network requests |
+| 4 | Accessibility | `browser-5` | Keyboard navigation, contrast, focus indicators, screen reader hints |
+| 5 | Security | `browser-7` | Auth boundaries, URL manipulation, console errors, XSS vectors |
+| 6 | API | `browser-1` | All API endpoints via fetch(), error responses, data integrity |
+
+---
+
+## Sub-Agent Prompt Template
+
+Read the full prompt template at [templates/agent-prompt-template.md](templates/agent-prompt-template.md).
+
+Replace all `{VARIABLES}` in the template before sending to the sub-agent:
+- `{APP}` — app name
+- `{PERSPECTIVE}` — agent's perspective (e.g., "functional", "accessibility")
+- `{APP_URL}`, `{ADMIN_SETTINGS_URL}`, `{BACKEND}`, `{USER}`, `{PASS}` — environment values
+- `{N}` — browser number (2-7)
+- `{PERSPECTIVE_INSTRUCTIONS}` — paste the matching block from [templates/perspective-instructions.md](templates/perspective-instructions.md)
+- `{INCLUDED_SCENARIOS}` — list of TS-NNN IDs and steps, or empty string
+- `{MODEL}` — model name from Step 4.5
+
+### Perspective-Specific Instructions
+
+Read [templates/perspective-instructions.md](templates/perspective-instructions.md) for the full instruction block for each perspective. Copy the matching block as `{PERSPECTIVE_INSTRUCTIONS}` into the sub-agent prompt template.
+
+---
+
+## Step 6: Generate Summary Report
+
+After all agents complete, read all result files from `{APP}/test-results/` and generate a summary.
+
+Read the summary report template at [templates/summary-report-template.md](templates/summary-report-template.md) and write the completed summary to `{APP}/test-results/README.md`.
+
+---
+
+## Step 7: Report to User
+
+Display a concise summary:
+- Total features tested
+- PASS/FAIL/PARTIAL/CANNOT_TEST counts
+- Top critical findings (FAILs)
+- Link to full report: `{APP}/test-results/README.md`
+
+---
+
+## Capture Learnings
+
+After testing completes, review what happened and append any new observations to [learnings.md](learnings.md):
+
+- **Patterns That Work** — test approaches that found real bugs (e.g., "testing navigation before login catches auth redirect issues")
+- **Mistakes to Avoid** — false positives or testing errors (e.g., "element not found due to loading delay, not actual bug")
+- **Domain Knowledge** — facts about the app's behavior discovered during testing
+- **Open Questions** — unresolved testing challenges
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+## Returning to caller
+
+After generating the report and summary, output a structured result line and return control:
+
+```
+APP_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = no FAIL-level findings
+- **FAIL** = any FAIL-level findings
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-app/evals/evals.json b/.claude/skills/test-app/evals/evals.json
new file mode 100644
index 00000000..7a6fdc30
--- /dev/null
+++ b/.claude/skills/test-app/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-app","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"single-perspective","description":"Single-agent test on an app","prompt":"Run /test-app on openregister in single mode","setup":"App running at localhost","expected":"Should test basic functionality as single agent","assertions":["Tests navigation and page loading","Tests core CRUD operations","Produces structured pass/fail report","Does NOT spawn parallel agents in single mode"]},{"id":"multi-perspective","description":"Multi-perspective parallel test","prompt":"Run /test-app on openregister with all perspectives","setup":"App running at localhost","expected":"Should spawn 6 parallel agents","assertions":["Spawns functional, UX, performance, accessibility, security, API agents","Agents run in parallel (not sequential)","Each agent produces independent findings","Synthesizes results into unified report"]},{"id":"with-scenarios","description":"Test with existing test scenarios","prompt":"Run /test-app on an app that has test scenarios defined in openspec/","setup":"App has TS-001.md through TS-005.md in test scenarios","expected":"Should load and execute existing scenarios","assertions":["Loads test scenarios from openspec/","Executes GIVEN-WHEN-THEN steps","Reports pass/fail per scenario","Includes scenario ID in results"]}],"trigger_tests":{"should_trigger":["test the app","run browser tests on openregister","test all perspectives","run app tests","check if the app works"],"should_not_trigger":["test the API only","run unit tests","test the counsel personas","create a test scenario","verify app config"]}}
diff --git a/.claude/skills/test-app/learnings.md b/.claude/skills/test-app/learnings.md
new file mode 100644
index 00000000..04f70493
--- /dev/null
+++ b/.claude/skills/test-app/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — test-app
+
+## Patterns That Work
+<!-- Testing approaches and configurations that consistently find real bugs -->
+
+## Mistakes to Avoid
+<!-- Testing errors and false positives encountered -->
+
+## Domain Knowledge
+<!-- Facts about Nextcloud app testing, browser automation, or test infrastructure -->
+
+## Open Questions
+<!-- Unresolved testing challenges for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/test-app/templates/agent-prompt-template.md b/.claude/skills/test-app/templates/agent-prompt-template.md
new file mode 100644
index 00000000..2ebb59bf
--- /dev/null
+++ b/.claude/skills/test-app/templates/agent-prompt-template.md
@@ -0,0 +1,159 @@
+You are a testing agent for the **{APP}** Nextcloud app, testing from a **{PERSPECTIVE}** perspective.
+
+> **Important**: This is experimental agentic testing. Be thorough but pragmatic. If an element is not found or an action fails, note it as CANNOT_TEST with the reason rather than retrying endlessly.
+
+## Browser
+Use `browser-{N}` tools (`mcp__browser-{N}__*`) for all browser interactions. This is a headless browser.
+
+## Environment
+- **App URL**: {APP_URL}
+- **Admin Settings**: {ADMIN_SETTINGS_URL}
+- **Login**: {USER} / {PASS}
+
+## Step 1: Understand What to Test
+
+Read these files to understand the app's features:
+1. `{APP}/docs/features/README.md` — Feature index
+2. All files listed in the README's feature table — read each one
+3. `{APP}/openspec/ROADMAP.md` (if it exists) — Features listed here are NOT yet implemented. Skip them.
+
+These docs describe what the app should do. Your job is to verify whether it actually works.
+
+## CRITICAL: Screenshot File Paths
+
+> **All screenshots MUST be saved inside the app's test-results folder within apps-extra.**
+> Always use the FULL relative path starting with `{APP}/test-results/screenshots/test-app/`.
+> Never use just a bare filename like `screenshot.png` — that saves to the wrong directory.
+>
+> **Correct:** `{APP}/test-results/screenshots/test-app/{PERSPECTIVE}-dashboard.png`
+> **Wrong:** `dashboard.png` or `{PERSPECTIVE}-dashboard.png`
+
+## Step 2: Set Viewport & Login
+
+1. **Resize the browser** to a desktop resolution FIRST, before navigating anywhere:
+   - Use `browser_resize` with `width: 1920` and `height: 1080`
+   - This ensures screenshots are taken at full HD resolution
+2. Navigate to `{BACKEND}/index.php/apps/{APP}`
+3. If redirected to login:
+   - Use `browser_evaluate` to run `localStorage.clear()` first
+   - Fill username: `{USER}`
+   - Fill password: `{PASS}`
+   - Submit the form
+4. Wait for the app to load
+5. Take a screenshot with filename: `{APP}/test-results/screenshots/test-app/{PERSPECTIVE}-login-complete.png`
+
+## Step 2.5: Execute Test Scenarios (if included)
+
+If `{INCLUDED_SCENARIOS}` is non-empty and this scenario's category matches your perspective, execute each scenario before free exploration:
+
+For each scenario provided:
+1. Verify preconditions are met
+2. Follow the Given-When-Then steps exactly
+3. Screenshot each step: `{APP}/test-results/screenshots/test-app/{PERSPECTIVE}-{SCENARIO_ID}-step-{N}.png`
+4. Check each acceptance criterion — record PASS / FAIL / PARTIAL
+5. Note any console errors or unexpected behaviour
+
+Record results in your report under a **"## Test Scenario Results"** section.
+
+---
+
+## Step 3: Systematic Testing
+
+Work through every feature described in the docs. For EACH page/feature:
+
+### 3a. Navigate & Observe
+- Navigate to the page
+- `browser_snapshot` — read the DOM structure
+- `browser_take_screenshot` with `filename` parameter set to the FULL relative path inside `apps-extra/{APP}/test-results/`: `{APP}/test-results/screenshots/test-app/{PERSPECTIVE}-{page-name}.png`
+  - Use descriptive filenames like `{PERSPECTIVE}-dashboard.png`, `{PERSPECTIVE}-clients-list.png`, `{PERSPECTIVE}-new-client-form.png`, `{PERSPECTIVE}-admin-settings.png`
+  - ALWAYS include the full path — NEVER use just a bare filename without the `{APP}/test-results/screenshots/test-app/` prefix
+
+### 3b. Test Interactions
+- Click every button that has a visible action
+- Open every dropdown/select
+- Fill and submit forms (use test data like "Test Item", "test@example.com")
+- Test edge cases: empty submissions, special characters
+
+### 3c. Monitor Health
+- `browser_console_messages` (level: "error") — record any errors
+- `browser_network_requests` — note any failed requests (4xx/5xx)
+
+### 3d. Record Results
+For each feature/interaction, record:
+- **Status**: PASS / PARTIAL / FAIL / CANNOT_TEST
+- **What was tested**: Brief description
+- **Evidence**: Screenshot filename
+- **Notes**: What worked, what didn't, any errors
+
+{PERSPECTIVE_INSTRUCTIONS}
+
+## Step 4: Test Admin Settings
+
+Navigate to the admin settings page ({ADMIN_SETTINGS_URL}) and test all settings controls:
+- Toggle checkboxes, change dropdowns, save settings
+- Verify settings persist after page reload
+- Take screenshots of the settings page
+
+## Step 5: Write Results
+
+Write your results to: `{APP}/test-results/{PERSPECTIVE}-results.md`
+
+Save all screenshots to: `{APP}/test-results/screenshots/test-app/` (inside the apps-extra directory — always use the full relative path as filename, e.g. `{APP}/test-results/screenshots/test-app/{PERSPECTIVE}-page.png`)
+
+Use this format:
+
+```markdown
+# {APP} — {PERSPECTIVE} Test Results
+
+**Date:** {today's date}
+**Perspective:** {PERSPECTIVE}
+**Environment:** {BACKEND}
+**Browser:** browser-{N} (headless)
+**Login:** {USER}
+
+> Experimental agentic testing — results should be verified manually for critical findings.
+
+## Summary
+
+| Status | Count |
+|--------|-------|
+| PASS | {n} |
+| PARTIAL | {n} |
+| FAIL | {n} |
+| CANNOT_TEST | {n} |
+
+## Results by Feature
+
+### {Feature Group Name} (from docs/features/)
+
+#### {Specific Feature}
+- **Status**: PASS / PARTIAL / FAIL / CANNOT_TEST
+- **Tested**: {what was tested}
+- **Screenshot**: {filename.png}
+- **Console errors**: {any errors, or "None"}
+- **Notes**: {details}
+
+{repeat for each feature}
+
+## Admin Settings
+
+### {Setting Name}
+- **Status**: PASS / PARTIAL / FAIL / CANNOT_TEST
+- **Tested**: {what was tested}
+- **Notes**: {details}
+
+## Console Errors Summary
+- Pages checked: {n}
+- Pages with errors: {n}
+- Unique errors: {list}
+
+## Network Errors Summary
+- Failed requests (4xx/5xx): {list or "None"}
+```
+
+## Step 6: Update Feature Documentation
+
+For each feature file in `{APP}/docs/features/`, if you found useful information during testing:
+- Add or update a "## Screenshots" section at the bottom with references to your screenshots
+- Add brief descriptions of what each screenshot shows
+- Do NOT modify the existing feature descriptions — only append screenshot sections
diff --git a/.claude/skills/test-app/templates/perspective-instructions.md b/.claude/skills/test-app/templates/perspective-instructions.md
new file mode 100644
index 00000000..8960ea00
--- /dev/null
+++ b/.claude/skills/test-app/templates/perspective-instructions.md
@@ -0,0 +1,104 @@
+# Perspective-Specific Instructions
+
+Include the matching block as `{PERSPECTIVE_INSTRUCTIONS}` in the sub-agent prompt template.
+
+---
+
+### Quick Mode (comprehensive)
+
+```
+## Your Focus: Comprehensive Smoke Test
+Test everything breadth-first. Visit every page, click every major button, submit every form.
+Prioritize coverage over depth — make sure nothing is completely broken.
+For forms: test with valid data (happy path) and one empty submission (validation).
+```
+
+---
+
+### Functional
+
+```
+## Your Focus: Functional Correctness
+Test every CRUD operation: Create, Read, Update, Delete.
+Verify navigation between pages works correctly.
+Test form validations — required fields, invalid input.
+Check that data persists after creation (navigate away and back).
+Test search/filter functionality if present.
+Verify status changes, assignments, and workflows.
+```
+
+---
+
+### UX
+
+```
+## Your Focus: User Experience
+Check every page for: meaningful empty states, loading indicators, success/error feedback.
+Verify labels and descriptions are clear and in proper language.
+Check button labels match their actions.
+Look for confusing navigation or dead ends.
+Test that modals/dialogs have proper close buttons and cancel options.
+Check for consistent styling and spacing.
+```
+
+---
+
+### Performance
+
+```
+## Your Focus: Performance
+After every navigation, check `browser_network_requests`:
+- Flag API calls >500ms as SLOW
+- Flag API calls >1000ms as PERFORMANCE_FAIL
+Time how long pages take to become interactive.
+Test with search/filter operations — do results appear promptly?
+Check if large lists have pagination.
+Record a performance summary at the end.
+```
+
+---
+
+### Accessibility
+
+```
+## Your Focus: Accessibility
+Test keyboard navigation: Tab through every page, check focus indicators.
+Check that all interactive elements are reachable via keyboard.
+Verify all images/icons have alt text or aria-labels.
+Check color contrast of text and interactive elements.
+Verify form fields have associated labels.
+Check that error messages are accessible (not just color-coded).
+Test that modals trap focus correctly.
+```
+
+---
+
+### Security
+
+```
+## Your Focus: Security
+Check `browser_console_messages` for errors on every page — look for leaked data.
+Try accessing admin URLs as a non-admin user (if multiple accounts available).
+Check for sensitive data in network responses that shouldn't be there.
+Look for XSS vectors in text fields (try entering `<script>alert(1)</script>`).
+Verify that CSRF tokens are present on forms.
+Check that navigation doesn't expose internal IDs in exploitable ways.
+```
+
+---
+
+### API
+
+````
+## Your Focus: API Quality
+Use `browser_evaluate` to test API endpoints directly via fetch():
+```javascript
+const r = await fetch(url, { headers: { requesttoken: OC.requestToken } });
+return { status: r.status, body: await r.json() };
+```
+Test all CRUD endpoints for the app's resources.
+Verify error responses have proper status codes and messages.
+Test with invalid/missing data — does the API return helpful errors?
+Check pagination parameters (_limit, _offset, _page).
+Verify that list endpoints return consistent data structures.
+````
diff --git a/.claude/skills/test-app/templates/summary-report-template.md b/.claude/skills/test-app/templates/summary-report-template.md
new file mode 100644
index 00000000..917fc998
--- /dev/null
+++ b/.claude/skills/test-app/templates/summary-report-template.md
@@ -0,0 +1,74 @@
+# {APP} — Test Results Summary
+
+**Date:** {today's date}
+**Environment:** {BACKEND}
+**Mode:** {Quick / Full (6 perspectives)}
+**Method:** Automated browser testing with Playwright MCP (headless)
+
+> Experimental agentic testing — results should be verified manually for critical findings.
+
+---
+
+## Overall Results
+
+| Status | Count | Percentage |
+|--------|-------|------------|
+| **PASS** | {n} | {pct}% |
+| **PARTIAL** | {n} | {pct}% |
+| **FAIL** | {n} | {pct}% |
+| **CANNOT_TEST** | {n} | {pct}% |
+
+---
+
+## FAIL Issues (Requires Attention)
+
+| Feature | Perspective | Summary | Severity |
+|---------|-------------|---------|----------|
+| {feature} | {perspective} | {one-line summary} | HIGH/MEDIUM/LOW |
+
+---
+
+## PARTIAL Issues (Needs Investigation)
+
+| Feature | Perspective | What Works | What Doesn't |
+|---------|-------------|------------|--------------|
+| {feature} | {perspective} | {working parts} | {broken parts} |
+
+---
+
+## CANNOT_TEST (Blocked)
+
+| Feature | Perspective | Reason |
+|---------|-------------|--------|
+| {feature} | {perspective} | {why it couldn't be tested} |
+
+---
+
+## Results by Perspective
+
+### {Perspective Name}
+- **PASS**: {n} | **PARTIAL**: {n} | **FAIL**: {n} | **CANNOT_TEST**: {n}
+- **Key findings**: {2-3 bullet points}
+
+{repeat for each perspective}
+
+---
+
+## Console Errors (Across All Perspectives)
+
+| Error | Occurrences | Pages |
+|-------|-------------|-------|
+| {error} | {n} | {pages} |
+
+---
+
+## Recommendations
+
+### High Priority
+{numbered list of FAIL items}
+
+### Medium Priority
+{numbered list of PARTIAL items}
+
+### For Next Test Run
+{improvements to testing approach}
diff --git a/.claude/skills/test-counsel/SKILL.md b/.claude/skills/test-counsel/SKILL.md
new file mode 100644
index 00000000..ffdc17b4
--- /dev/null
+++ b/.claude/skills/test-counsel/SKILL.md
@@ -0,0 +1,469 @@
+---
+name: test-counsel
+description: Test a project's features from 8 persona perspectives using browser, API, and documentation testing
+---
+
+# Test Counsel — Multi-Persona Feature Testing
+
+Test a project's implemented features from 8 persona perspectives using browser interaction, API testing, and documentation review — all driven by the project's OpenSpec specifications.
+
+**Input**: Optional argument after `/test-counsel`:
+- No argument → ask which project to test
+- Project name → test that project directly (e.g., `opencatalogi`, `openregister`)
+
+**Available projects**: Any directory under apps-extra with an `openspec/` folder.
+
+---
+
+## Personas
+
+The Test Counsel uses 8 personas representing the full spectrum of Dutch public sector users. Each persona card is stored in `.claude/personas/`:
+
+| Persona | File | Testing Focus |
+|---------|------|---------------|
+| Henk Bakker | `henk-bakker.md` | Readability, text size, Dutch language, simple navigation, elderly UX |
+| Fatima El-Amrani | `fatima-el-amrani.md` | Visual clarity, icon usage, mobile viewport, text density, literacy barriers |
+| Sem de Jong | `sem-de-jong.md` | Performance, keyboard nav, dark mode, console errors, modern UX patterns |
+| Noor Yilmaz | `noor-yilmaz.md` | Security controls, audit trails, RBAC, org isolation, data leaks, BIO2 |
+| Annemarie de Vries | `annemarie-de-vries.md` | API standards, NLGov compliance, GEMMA mapping, OpenAPI spec, publiccode.yml |
+| Mark Visser | `mark-visser.md` | Business workflows, CRUD efficiency, form clarity, status indicators, Dutch terms |
+| Priya Ganpat | `priya-ganpat.md` | API quality via browser fetch(), DX, error responses, pagination, integration |
+| Jan-Willem van der Berg | `janwillem-van-der-berg.md` | Plain language, jargon-free, findability, 3-click rule, contact info, help |
+
+---
+
+## Steps
+
+### Step -1: Environment Configuration
+
+Ask the user about the target environment using AskUserQuestion:
+
+**"Which environment do you want to test against?"**
+- **Local development** — Backend: localhost:8080, Frontend: localhost:3000 (if separate UI), Admin: admin/admin
+- **Custom environment** — I'll provide URLs and credentials
+
+If **Custom**, ask follow-up questions one at a time:
+1. "What is the backend URL?"
+2. "What is the frontend URL? (or same as backend if no separate UI)"
+3. "What are the test user credentials? (format: username:password)"
+
+Store as `{BACKEND}`, `{FRONTEND}`, `{TEST_USER}`, `{TEST_PASS}`.
+
+For **Local development**, use:
+- `{BACKEND}` = `http://localhost:8080`
+- `{FRONTEND}` = `http://localhost:8080` (or `http://localhost:3000` if project has separate UI)
+- `{TEST_USER}` = `admin`
+- `{TEST_PASS}` = `admin`
+
+### Step 0: Determine the Project
+
+If no project was provided as argument, use AskUserQuestion to ask:
+
+**"Which project would you like the Test Counsel to test?"**
+
+List the available projects by checking which directories have `openspec/` folders.
+
+Store the chosen project as `{PROJECT}`.
+
+### Step 1: Read the Project's Specs and Understand What to Test
+
+Read the following files:
+
+1. `{PROJECT}/project.md` — Project context, URLs, architecture
+2. `{PROJECT}/openspec/specs/` — All spec files (what was specified)
+3. `{PROJECT}/openspec/changes/` — Active changes (recently added features)
+4. `openspec/specs/` — Shared specs (api-patterns, nl-design, nextcloud-app)
+
+Build a test plan:
+- What features exist and should be testable?
+- What URLs/pages should be visited?
+- What API endpoints should be tested?
+- What documentation should exist?
+
+### Step 1.5a: Load Test Scenarios (optional)
+
+Check whether the project has saved test scenarios:
+```bash
+ls {PROJECT}/test-scenarios/TS-*.md 2>/dev/null
+```
+
+If scenario files exist, parse their frontmatter. Filter to those with `status: active` and `test-commands` containing `test-counsel`.
+
+Group them by persona relevance using the `personas` frontmatter field:
+
+```
+Found {N} test scenario(s) for {PROJECT}:
+
+Relevant to all personas:
+  TS-001  [HIGH]  functional  — Create a new register
+
+Relevant to specific personas:
+  TS-002  [MED]   api         — API returns paginated results   → Priya Ganpat, Annemarie de Vries
+  TS-003  [HIGH]  security    — Unauthenticated access blocked  → Noor Yilmaz
+  TS-004  [LOW]   accessibility — Form labels are readable      → Henk Bakker, Fatima El-Amrani
+```
+
+Ask the user using AskUserQuestion:
+
+**"Test scenarios exist for this project. Include them in this test run?"**
+- **Yes, include all** — each persona agent receives the scenarios relevant to their persona (matched by persona slug in frontmatter), plus any scenario with no specific persona
+- **Yes, let me choose** — show the list and let the user select which to include
+- **No, skip scenarios** — proceed with standard testing only
+
+Store `{INCLUDED_SCENARIOS}` — a mapping of persona slug → list of relevant scenario objects (id, title, steps, preconditions, acceptance criteria).
+
+Each persona sub-agent will receive only the scenarios matching their persona slug (or all scenarios if the user chose "include all" and no persona filter is set).
+
+**If no scenarios exist**: proceed silently. Note at the end: "No test scenarios defined yet. Create them with `/test-scenario-create`."
+
+---
+
+### Step 1.5: Select Agent Model
+
+Ask the user using AskUserQuestion:
+
+**"Which model should the persona agents use?"**
+
+| Model | Speed | Quota | Best for |
+|---|---|---|---|
+| **Haiku** | Fastest | Low | Parallel runs — broad coverage, efficient |
+| **Sonnet** | Balanced | Moderate | Better reasoning, more nuanced findings |
+| **Opus** | Slowest | High | Deepest analysis — for critical or final runs |
+
+- **Haiku (default)** — Recommended for parallel runs. Fast and quota-efficient. Its 200k context window is smaller than Sonnet/Opus (both 1M) — for browser-heavy runs with many snapshots, consider Sonnet.
+- **Sonnet** — Better reasoning depth for more nuanced findings. Uses more quota than Haiku across 8 parallel agents.
+- **Opus** — Highest quality analysis. With 8 agents running in parallel this uses substantial quota — best reserved for final pre-release testing or targeted critical reviews.
+
+Store as `{MODEL}`:
+- Haiku → `"haiku"`
+- Sonnet → `"sonnet"`
+- Opus → `"opus"`
+
+### Step 2: Launch Persona Test Agents in Parallel
+
+Launch 8 Task agents in parallel (all in a single message), one per persona. Each agent tests the live application from their persona's perspective. Use `subagent_type: "general-purpose"` and `model: "{MODEL}"` (from Step 1.5).
+
+**Browser assignment** — each agent gets its own browser to avoid conflicts:
+
+| Agent | Persona | Browser |
+|-------|---------|---------|
+| 1 | Henk Bakker | `browser-2` |
+| 2 | Fatima El-Amrani | `browser-3` |
+| 3 | Sem de Jong | `browser-4` |
+| 4 | Noor Yilmaz | `browser-5` |
+| 5 | Annemarie de Vries | `browser-7` |
+| 6 | Mark Visser | `browser-1` |
+| 7 | Priya Ganpat | `browser-2` (sequential after Henk) |
+| 8 | Jan-Willem van der Berg | `browser-3` (sequential after Fatima) |
+
+**Note**: With 7 browsers and 8 agents, launch the first 6 in parallel, then the remaining 2 after the first batch completes. Or launch all 8 and let 2 share browsers sequentially.
+
+**Sub-agent prompt template** (replace variables):
+
+```
+You are a Test Counsel agent testing the **{PROJECT}** application as **{PERSONA_NAME}**.
+
+## Your Persona
+Read the persona card at `.claude/personas/{PERSONA_FILE}` to understand your character completely. Stay fully in character throughout all testing.
+
+## Browser
+Use `browser-{N}` tools (`mcp__browser-{N}__*`) for all browser interactions.
+
+## Environment
+- **Backend**: {BACKEND}
+- **Frontend**: {FRONTEND}
+- **Login**: {TEST_USER} / {TEST_PASS}
+
+## What to Test
+Read the project specs to understand what features should exist:
+1. `{PROJECT}/project.md`
+2. All files in `{PROJECT}/openspec/specs/`
+
+## Test Scenarios for Your Persona
+
+{IF INCLUDED_SCENARIOS for this persona is non-empty:}
+The following test scenarios were defined specifically for your persona. Execute these **first**, before free exploration — they represent the highest-priority flows to verify:
+
+{For each scenario: ID, title, preconditions, Given-When-Then steps, acceptance criteria}
+
+For each scenario:
+1. Set up the preconditions
+2. Follow the Given-When-Then steps exactly as written, using the provided test data
+3. Verify each acceptance criterion — record PASS / FAIL / PARTIAL / BLOCKED
+4. Screenshot each step: `{PROJECT}/test-results/screenshots/personas/{PERSONA_SLUG}/{SCENARIO_ID}-step-{N}.png`
+5. Check `browser_console_messages` after each action
+
+Include a **"## Test Scenario Results"** section in your report with a table:
+| Scenario | Title | Criterion | Status | Observed |
+|---|---|---|---|---|
+
+{END IF}
+
+---
+
+## Testing Approach
+
+### 1. Browser Testing (UI)
+Log in and navigate through the application as your persona would:
+- Navigate to {FRONTEND} (or {BACKEND}/index.php/apps/{PROJECT} for Nextcloud apps)
+- Log in with the test credentials
+- Visit every major page/section mentioned in the specs
+- For each page:
+  - `browser_snapshot` — observe the page from your persona's perspective
+  - Test interactions your persona would attempt
+  - Check `browser_console_messages` for errors
+  - Note anything that doesn't match your persona's needs/expectations
+
+### 2. API Testing (from browser)
+Use `browser_evaluate` to test API endpoints mentioned in the specs:
+```javascript
+const response = await fetch('{BACKEND}/index.php/apps/{app}/api/{resource}', {
+    headers: { 'requesttoken': OC.requestToken }
+});
+return JSON.stringify({
+    status: response.status,
+    headers: Object.fromEntries(response.headers.entries()),
+    body: await response.json()
+}, null, 2);
+```
+Test from your persona's perspective:
+- Can your persona's role access these endpoints?
+- Do the responses make sense for your persona?
+- Are errors helpful and understandable?
+
+### 3. Documentation Testing
+Check if documentation exists and serves your persona:
+- Is there in-app help?
+- Are API docs accessible if relevant to your persona?
+- Is the documentation in Dutch where needed?
+- Does it match the actual behavior?
+
+### 4. Spec Compliance Testing
+For each feature in the specs, verify:
+- Is it implemented?
+- Does it work as specified?
+- Does it serve your persona's needs?
+
+## {PERSONA_TESTING_FOCUS}
+
+## Output Format
+
+Write your results as a structured report:
+
+```markdown
+# Test Counsel Report: {PERSONA_NAME} — {PROJECT}
+
+**Date:** {today's date}
+**Environment:** {BACKEND}
+**Persona:** {PERSONA_NAME} ({one-line description})
+**Browser:** browser-{N}
+
+## Summary
+- **Features tested**: {count}
+- **PASS**: {count}
+- **PARTIAL**: {count}
+- **FAIL**: {count}
+- **NOT IMPLEMENTED**: {count}
+
+## Feature Test Results
+
+### {Spec Section / Feature Name}
+| Aspect | Status | Notes |
+|--------|--------|-------|
+| Implemented? | YES/NO/PARTIAL | {details} |
+| Works as specified? | YES/NO/PARTIAL | {details} |
+| Serves {PERSONA_NAME}'s needs? | YES/NO/PARTIAL | {persona perspective} |
+
+**{PERSONA_NAME}'s reaction**: "{in-character quote}"
+
+{repeat for each feature}
+
+## API Test Results (if applicable)
+| Endpoint | Method | Status | Response | Persona Notes |
+|----------|--------|--------|----------|--------------|
+| /api/{resource} | GET | {code} | {summary} | {persona perspective} |
+
+## Console Errors
+| Page | Error | Severity |
+|------|-------|----------|
+| {page} | {error} | HIGH/MEDIUM/LOW |
+
+## Persona-Specific Findings
+
+### {PERSONA_FOCUS_AREA} Assessment
+| Criterion | Status | Evidence | {PERSONA_NAME} would say... |
+|-----------|--------|----------|----------------------------|
+| {criterion} | PASS/FAIL | {what was observed} | "{in-character quote}" |
+
+## Top Issues
+| # | Issue | Severity | Category | Recommendation |
+|---|-------|----------|----------|----------------|
+| 1 | {issue} | CRITICAL/HIGH/MEDIUM/LOW | {category} | {suggestion} |
+
+## {PERSONA_NAME}'s Verdict
+"{A paragraph from the persona summarizing their overall experience testing this application}"
+```
+```
+
+**Persona-specific testing focus:**
+
+| Persona | Testing Focus Instructions |
+|---------|--------------------------|
+| Henk | Check text size (>=16px body), button size (>=44px), Dutch labels, simple navigation, clear errors, breadcrumbs, contrast ratios |
+| Fatima | Set viewport to 375x812 mobile, check icon clarity, text density, visual hierarchy, color-coded status, touch targets, scrolling discovery |
+| Sem | Measure page load time, test Tab/Escape/Enter/arrow keys, check dark mode, inspect console, monitor network requests, verify URL state management |
+| Noor | Navigate to settings first, look for audit logs, test RBAC boundaries, try URL manipulation for org isolation, check PII in URLs, verify session controls |
+| Annemarie | Test API endpoints for NLGov compliance, check pagination format, verify OpenAPI spec availability, look for publiccode.yml, assess GEMMA alignment |
+| Mark | Test CRUD workflows for efficiency (count clicks), check form field clarity, verify status indicators, test search, check Dutch business terminology |
+| Priya | Use browser_evaluate for API calls, test all CRUD via fetch(), verify error response format, check pagination/filtering/sorting, assess OpenAPI accuracy |
+| Jan-Willem | Check for jargon on every page, test search with plain Dutch terms, count clicks to complete tasks, find contact info, verify B1 language level |
+
+### Step 3: Synthesize Test Results
+
+After all agents complete, read their reports and create a synthesized Test Counsel report.
+
+**Write the synthesis to**: `{PROJECT}/test-results/test-counsel-report.md`
+
+```markdown
+# Test Counsel Report: {PROJECT}
+
+**Date:** {today's date}
+**Environment:** {BACKEND} / {FRONTEND}
+**Method:** 8-persona browser, API, and documentation testing against OpenSpec specifications
+**Personas:** Henk Bakker, Fatima El-Amrani, Sem de Jong, Noor Yilmaz, Annemarie de Vries, Mark Visser, Priya Ganpat, Jan-Willem van der Berg
+
+---
+
+## Overall Results
+
+| Persona | Features Tested | PASS | PARTIAL | FAIL | Not Implemented |
+|---------|----------------|------|---------|------|-----------------|
+| Henk Bakker | {n} | {n} | {n} | {n} | {n} |
+| Fatima El-Amrani | {n} | {n} | {n} | {n} | {n} |
+...{all 8 personas}
+| **Total** | {n} | {n} | {n} | {n} | {n} |
+
+---
+
+## Critical Issues (found by 3+ personas)
+
+| # | Issue | Severity | Found by | Recommendation |
+|---|-------|----------|----------|----------------|
+| 1 | {issue} | CRITICAL/HIGH | {persona names} | {recommendation} |
+
+---
+
+## Spec vs Implementation Gap Analysis
+
+| Spec Feature | Implemented? | Working? | Persona Feedback |
+|-------------|-------------|---------|-----------------|
+| {feature from spec} | YES/NO/PARTIAL | YES/NO | {summary of persona reactions} |
+
+---
+
+## Per-Persona Highlights
+
+### Henk Bakker (Elderly Citizen)
+- **Can Henk use this?** YES/WITH DIFFICULTY/NO
+- **Top blocker**: {issue}
+- **Quote**: "{in-character Dutch quote}"
+
+### Fatima El-Amrani (Low-Literate Migrant)
+...{repeat for all 8}
+
+---
+
+## Testing Categories
+
+### Accessibility & Readability
+| Issue | Severity | Personas | Spec Reference |
+|-------|----------|----------|---------------|
+| {issue} | {severity} | {who found it} | {spec section} |
+
+### Security & Compliance
+| Issue | Severity | Personas | Standard |
+|-------|----------|----------|----------|
+| {issue} | {severity} | {who found it} | {BIO2/AVG/etc} |
+
+### API Quality & Standards
+| Issue | Severity | Personas | NLGov Rule |
+|-------|----------|----------|-----------|
+| {issue} | {severity} | {who found it} | {rule} |
+
+### UX & Performance
+| Issue | Severity | Personas | Notes |
+|-------|----------|----------|-------|
+| {issue} | {severity} | {who found it} | {details} |
+
+### Language & Content
+| Issue | Severity | Personas | Notes |
+|-------|----------|----------|-------|
+| {issue} | {severity} | {who found it} | {details} |
+
+---
+
+## Console Errors Summary
+
+| Error | Occurrences | Pages | Severity |
+|-------|-------------|-------|----------|
+| {error} | {count} | {pages} | {severity} |
+
+---
+
+## Recommendations
+
+### CRITICAL (fix immediately)
+1. {recommendation + which personas affected}
+
+### HIGH (fix before next release)
+1. {recommendation + which personas affected}
+
+### MEDIUM (improve when possible)
+1. {recommendation + which personas affected}
+
+---
+
+## Suggested OpenSpec Changes
+
+| Change Name | Description | Related Issues | Personas Affected |
+|-------------|-------------|---------------|------------------|
+| {name} | {description} | {issue numbers from above} | {personas} |
+```
+
+### Step 4: Report to User
+
+Display a concise summary:
+- Total features tested across all personas
+- Overall pass/fail rates per persona
+- Top 5 critical issues
+- Any spec features that are not yet implemented
+- Link to the full report: `{PROJECT}/test-results/test-counsel-report.md`
+- Offer to create OpenSpec changes for any gaps found
+
+---
+
+## Capture Learnings
+
+After testing completes, review what happened and append any new observations to [learnings.md](learnings.md):
+
+- **Patterns That Work** — multi-persona approaches that found meaningful cross-cutting issues
+- **Mistakes to Avoid** — false consensus, persona overlap, or synthesis errors
+- **Domain Knowledge** — facts about cross-persona testing patterns or Dutch government accessibility
+- **Open Questions** — unresolved testing challenges
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+## Returning to caller
+
+After generating the report and summary, output a structured result line and return control:
+
+```
+COUNSEL_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = no CRITICAL issues found across all personas
+- **FAIL** = any CRITICAL issues found
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT offer to create OpenSpec changes, do NOT ask what to do next.
diff --git a/.claude/skills/test-counsel/evals/evals.json b/.claude/skills/test-counsel/evals/evals.json
new file mode 100644
index 00000000..2e12c9ef
--- /dev/null
+++ b/.claude/skills/test-counsel/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-counsel","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"multi-persona","description":"Spawn 8 persona agents","prompt":"Run /test-counsel on openregister","setup":"App running, specs defined in openspec/","expected":"Should spawn 8 persona agents in parallel","assertions":["Spawns all 8 personas (Henk, Fatima, Sem, Noor, Annemarie, Mark, Priya, Jan-Willem)","Each persona tests from their specific perspective","Personas run in parallel","Each produces independent findings"]},{"id":"synthesize","description":"Synthesize cross-persona results","prompt":"Run /test-counsel and check the synthesis","setup":"All 8 personas have completed testing","expected":"Should produce consensus findings","assertions":["Identifies issues found by multiple personas","Highlights persona-specific unique findings","Ranks issues by severity and cross-persona agreement","Produces structured test-counsel-report.md"]},{"id":"report-format","description":"Report includes per-persona and cross-persona sections","prompt":"Check the test-counsel report format","setup":"Testing complete","expected":"Should have structured report","assertions":["Has per-persona findings sections","Has cross-persona patterns section","Has overall pass/fail rates","Offers to create OpenSpec changes for gaps"]}],"trigger_tests":{"should_trigger":["test from all personas","run counsel tests","test with personas","run test counsel on openregister","multi-persona testing"],"should_not_trigger":["test the app","run functional tests","test as Henk specifically","create test scenarios","run the API tests"]}}
diff --git a/.claude/skills/test-counsel/learnings.md b/.claude/skills/test-counsel/learnings.md
new file mode 100644
index 00000000..ffd00b6d
--- /dev/null
+++ b/.claude/skills/test-counsel/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — test-counsel
+
+## Patterns That Work
+<!-- Multi-persona testing approaches that find the most meaningful issues -->
+
+## Mistakes to Avoid
+<!-- Cross-persona testing errors, synthesis failures, false consensus -->
+
+## Domain Knowledge
+<!-- Facts about persona-driven testing, Dutch government accessibility, cross-persona patterns -->
+
+## Open Questions
+<!-- Unresolved testing challenges for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/test-functional/SKILL.md b/.claude/skills/test-functional/SKILL.md
new file mode 100644
index 00000000..b8b94398
--- /dev/null
+++ b/.claude/skills/test-functional/SKILL.md
@@ -0,0 +1,176 @@
+---
+name: test-functional
+description: Functional Tester — Testing Team Agent
+metadata:
+  category: Testing
+  tags: [testing, functional, browser, acceptance-criteria]
+---
+
+# Functional Tester — Testing Team Agent
+
+Verify that features work correctly by testing acceptance criteria through browser-based interaction. Follows GIVEN/WHEN/THEN scenarios as an authenticated user.
+
+## Instructions
+
+You are a **Functional Tester** on the Conduction testing team. You verify that implemented features work correctly by executing acceptance criteria in the actual application using the MCP browser.
+
+### Input
+
+Accept an optional argument:
+- No argument → test all completed tasks from the active change's plan.json
+- Task number → test a specific task's acceptance criteria
+- `smoke` → quick smoke test of core app functionality
+- App name → smoke test a specific app (openregister, opencatalogi, softwarecatalog)
+
+### Step 1: Load test context
+
+1. Read `plan.json` from the active change
+2. Identify completed tasks and their `acceptance_criteria`
+3. Read `files_likely_affected` to understand what changed
+4. Determine which app(s) to test
+
+### Step 2: Set up browser session
+
+**Default browser**: Use `browser-1` tools (`mcp__browser-1__*`). If assigned a different browser by the orchestrator, use that instead.
+
+**Login to Nextcloud:**
+1. `mcp__browser-1__browser_navigate` to `http://localhost:8080/login`
+2. `mcp__browser-1__browser_snapshot` to see the login form
+3. Fill in credentials: `admin` / `admin` (or test user if specified)
+4. Navigate to the target app: `http://localhost:8080/index.php/apps/{appname}/`
+5. `mcp__browser-1__browser_snapshot` to confirm the app loaded
+
+### Step 3: Execute acceptance criteria
+
+For each GIVEN/WHEN/THEN criterion:
+
+**1. Set up the GIVEN (preconditions)**
+- Navigate to the correct page
+- Ensure required data exists (create test data if needed via the UI)
+- Verify the starting state matches the precondition
+
+**2. Execute the WHEN (action)**
+- Perform the described user action
+- Use `browser_click`, `browser_type`, `browser_fill_form`, `browser_press_key`
+- Wait for responses: `browser_wait_for` or check `browser_network_requests`
+
+**3. Verify the THEN (expected outcome)**
+- `browser_snapshot` to capture the resulting state
+- Check that the expected elements/text/state are present
+- `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/functional/{change-name}/{criterion-slug}.png`
+- Check `browser_console_messages` for errors (level `"error"`)
+
+**Test execution pattern:**
+```
+For each acceptance criterion:
+1. Navigate → snapshot → verify precondition
+2. Act → wait for network → snapshot
+3. Assert → screenshot → log result
+4. Clean up if needed (delete test data)
+```
+
+### Step 4: Test common user flows
+
+Beyond specific acceptance criteria, test these standard flows:
+
+**CRUD Operations:**
+- [ ] Create a new item → verify it appears in the list
+- [ ] Read/view an existing item → verify details are correct
+- [ ] Update an item → verify changes persist after reload
+- [ ] Delete an item → verify it's removed from the list
+
+**Navigation:**
+- [ ] All sidebar navigation items load without errors
+- [ ] Browser back/forward buttons work correctly
+- [ ] Direct URL navigation works (deep linking)
+- [ ] Page refreshes preserve state
+
+**Forms:**
+- [ ] Required fields show validation errors when empty
+- [ ] Form submission shows success feedback
+- [ ] Cancel/close discards unsaved changes (or warns)
+- [ ] Long text inputs are handled correctly
+
+**Loading & Error States:**
+- [ ] Loading indicators appear during data fetches
+- [ ] Empty states show helpful messages
+- [ ] Error states are user-friendly (not raw error dumps)
+- [ ] Network failures are handled gracefully
+
+### Step 5: Check for regressions
+
+After testing the new feature:
+- [ ] Navigate to other app sections — do they still work?
+- [ ] Check `browser_console_messages` for any new errors
+- [ ] Check `browser_network_requests` for failed API calls (4xx/5xx)
+- [ ] Verify sidebar/navigation still functions
+
+### Step 6: Generate test report
+
+```markdown
+## Functional Test Report: {change-name}
+
+### Overall: PASS / FAIL
+
+### Acceptance Criteria Results
+| Task | Criterion | Action | Result | Evidence |
+|------|-----------|--------|--------|----------|
+| #{n} | GIVEN... WHEN... THEN... | {what was done} | PASS/FAIL | screenshot_{n} |
+
+### User Flow Tests
+| Flow | Status | Notes |
+|------|--------|-------|
+| CRUD - Create | PASS/FAIL | {details} |
+| CRUD - Read | PASS/FAIL | {details} |
+| CRUD - Update | PASS/FAIL | {details} |
+| CRUD - Delete | PASS/FAIL | {details} |
+| Navigation | PASS/FAIL | {details} |
+| Forms | PASS/FAIL | {details} |
+| Loading states | PASS/FAIL | {details} |
+
+### Console Errors
+{list of console errors found, or "None"}
+
+### Network Errors
+{list of failed API calls, or "None"}
+
+### Issues Found
+| # | Severity | Description | Steps to Reproduce |
+|---|----------|-------------|-------------------|
+| 1 | CRITICAL/HIGH/MEDIUM/LOW | {description} | {steps} |
+
+### Recommendation
+APPROVE / NEEDS FIXES
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-functional-results.md`. Use the change name or app name in the filename where relevant.
+
+## Capture Learnings
+
+After testing completes, review what happened and append any new observations to [learnings.md](learnings.md):
+
+- **Patterns That Work** — functional testing approaches that reliably verify acceptance criteria
+- **Mistakes to Avoid** — testing errors, flaky interactions, or false pass/fail results
+- **Domain Knowledge** — facts about Nextcloud app UX patterns, browser automation quirks, or test infrastructure
+- **Open Questions** — unresolved testing challenges for future investigation
+
+Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.
+
+---
+
+## Returning to caller
+
+After generating the test report above, you **must** output a structured result line and return control to the calling skill.
+
+**Always output this line after the report** (replace values accordingly):
+
+```
+FUNCTIONAL_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = recommendation is APPROVE and no CRITICAL/HIGH issues found
+- **FAIL** = recommendation is NEEDS FIXES or any CRITICAL/HIGH issues found
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-functional/evals/evals.json b/.claude/skills/test-functional/evals/evals.json
new file mode 100644
index 00000000..32603c23
--- /dev/null
+++ b/.claude/skills/test-functional/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-functional","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"crud-workflow","description":"Test CRUD operations","prompt":"Run /test-functional on openregister","setup":"App running with test data","expected":"Should verify create, read, update, delete","assertions":["Tests create operation with valid data","Tests read/list with pagination","Tests update and verifies changes persist","Tests delete and verifies removal"]},{"id":"acceptance-criteria","description":"Test against spec acceptance criteria","prompt":"Run /test-functional against spec acceptance criteria","setup":"App has specs with acceptance criteria defined","expected":"Should validate each criterion","assertions":["Loads acceptance criteria from specs","Tests each criterion individually","Reports pass/fail per criterion","Maps failures to specific spec requirements"]},{"id":"error-handling","description":"Test error states","prompt":"Run /test-functional and check error handling","setup":"App running","expected":"Should verify graceful error states","assertions":["Tests invalid input handling","Tests empty state displays","Tests permission denied scenarios","Verifies user-friendly error messages"]}],"trigger_tests":{"should_trigger":["run functional tests","test the features","test the workflows","functional testing on openregister","test if features work"],"should_not_trigger":["run API tests","test accessibility","test performance","test security","create a test scenario"]}}
diff --git a/.claude/skills/test-functional/learnings.md b/.claude/skills/test-functional/learnings.md
new file mode 100644
index 00000000..d7da5b4b
--- /dev/null
+++ b/.claude/skills/test-functional/learnings.md
@@ -0,0 +1,16 @@
+# Learnings — test-functional
+
+## Patterns That Work
+<!-- Functional testing approaches that reliably verify acceptance criteria -->
+
+## Mistakes to Avoid
+<!-- Testing errors, flaky interactions, or false pass/fail results -->
+
+## Domain Knowledge
+<!-- Facts about Nextcloud app UX patterns, browser automation quirks, or test infrastructure -->
+
+## Open Questions
+<!-- Unresolved testing challenges for future investigation -->
+
+## Consolidated Principles
+<!-- Promoted from patterns after 3+ confirmations — these become standing rules -->
diff --git a/.claude/skills/test-performance/SKILL.md b/.claude/skills/test-performance/SKILL.md
new file mode 100644
index 00000000..5cb3e66a
--- /dev/null
+++ b/.claude/skills/test-performance/SKILL.md
@@ -0,0 +1,227 @@
+---
+name: test-performance
+description: Performance Tester — Testing Team Agent
+metadata:
+  category: Testing
+  tags: [testing, performance, load, timing]
+---
+
+# Performance Tester — Testing Team Agent
+
+Test application performance: page load times, API response times, database query efficiency, and behavior under load. Uses browser timing APIs and sequential API testing.
+
+## Instructions
+
+You are a **Performance Tester** on the Conduction testing team. You verify that the application performs well under realistic conditions and identify bottlenecks.
+
+### Input
+
+Accept an optional argument:
+- No argument → full performance test for the active change
+- `pages` → test page load times across the app
+- `api` → test API response times
+- `load` → test behavior under sequential rapid requests
+- App name → test a specific app
+
+### Step 1: Set up browser session
+
+**Default browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in to `http://localhost:8080/login` with `admin` / `admin`
+2. Navigate to the target app
+
+### Step 2: Page load performance
+
+For each major page, measure load times:
+
+```javascript
+// Use browser_evaluate to get performance timing
+const timing = performance.getEntriesByType('navigation')[0];
+const resources = performance.getEntriesByType('resource');
+return JSON.stringify({
+    // Page timing
+    dnsLookup: timing.domainLookupEnd - timing.domainLookupStart,
+    tcpConnect: timing.connectEnd - timing.connectStart,
+    ttfb: timing.responseStart - timing.requestStart,
+    contentDownload: timing.responseEnd - timing.responseStart,
+    domParse: timing.domInteractive - timing.responseEnd,
+    domReady: timing.domContentLoadedEventEnd - timing.navigationStart,
+    fullLoad: timing.loadEventEnd - timing.navigationStart,
+    // Resource summary
+    totalResources: resources.length,
+    totalTransferSize: resources.reduce((sum, r) => sum + (r.transferSize || 0), 0),
+    slowestResources: resources
+        .sort((a, b) => b.duration - a.duration)
+        .slice(0, 5)
+        .map(r => ({ name: r.name.split('/').pop(), duration: Math.round(r.duration), size: r.transferSize }))
+});
+```
+
+**Test these pages:**
+- [ ] Dashboard / landing page
+- [ ] List views with data (registers, schemas, objects, catalogi, publications)
+- [ ] Detail views
+- [ ] Settings page
+- [ ] Search results page
+
+**Performance budgets:**
+| Metric | Target | Acceptable | Poor |
+|--------|--------|------------|------|
+| Time to First Byte (TTFB) | < 200ms | < 500ms | > 1000ms |
+| DOM Ready | < 1000ms | < 2000ms | > 3000ms |
+| Full Page Load | < 2000ms | < 3000ms | > 5000ms |
+| API Response (simple) | < 200ms | < 500ms | > 1000ms |
+| API Response (complex) | < 500ms | < 1000ms | > 2000ms |
+
+### Step 3: API response time testing
+
+Test each API endpoint response time:
+
+```bash
+# Measure response time with curl
+curl -s -o /dev/null -w "%{time_total}" -u admin:admin \
+  http://localhost:8080/index.php/apps/{app}/api/{resource}
+```
+
+**Test with varying data sizes:**
+```bash
+# Small collection (< 20 items)
+curl -s -o /dev/null -w "%{time_total}" -u admin:admin \
+  "http://localhost:8080/index.php/apps/{app}/api/{resource}?limit=10"
+
+# Medium collection (100 items)
+curl -s -o /dev/null -w "%{time_total}" -u admin:admin \
+  "http://localhost:8080/index.php/apps/{app}/api/{resource}?limit=100"
+
+# Large single object
+curl -s -o /dev/null -w "%{time_total}" -u admin:admin \
+  http://localhost:8080/index.php/apps/{app}/api/{resource}/{id-of-large-object}
+```
+
+### Step 4: Sequential load testing
+
+Test behavior under rapid sequential requests (not a DDoS — just checking degradation):
+
+```bash
+# 20 sequential requests to the same endpoint
+for i in $(seq 1 20); do
+  curl -s -o /dev/null -w "%{time_total}\n" -u admin:admin \
+    http://localhost:8080/index.php/apps/{app}/api/{resource}
+done
+```
+
+Check for:
+- [ ] Response times remain consistent (no progressive slowdown)
+- [ ] No 500 errors under repeated requests
+- [ ] Rate limiting kicks in appropriately (429)
+- [ ] Memory/CPU doesn't spike (check container stats)
+
+**Container resource usage:**
+```bash
+docker stats nextcloud --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}"
+```
+
+### Step 5: Database query analysis
+
+Check for common performance issues:
+
+**Slow query detection:**
+```bash
+# Enable slow query logging (PostgreSQL)
+docker exec -u root nextcloud bash -c "cat /var/www/html/data/nextcloud.log | grep -i 'slow\|query\|performance' | tail -20"
+```
+
+**N+1 query detection:**
+Monitor network requests during a list page load:
+```javascript
+// From browser_evaluate during page load
+const entries = performance.getEntriesByType('resource')
+    .filter(r => r.name.includes('/api/'))
+    .map(r => ({ url: r.name, duration: Math.round(r.duration) }));
+return JSON.stringify({
+    apiCalls: entries.length,
+    totalDuration: entries.reduce((sum, e) => sum + e.duration, 0),
+    calls: entries
+});
+```
+- [ ] List pages make 1-2 API calls (not N+1 per item)
+- [ ] Detail pages make 1 primary + minimal supplementary calls
+
+### Step 6: Frontend performance
+
+```javascript
+// Check JavaScript bundle sizes
+const scripts = Array.from(document.querySelectorAll('script[src]'))
+    .map(s => {
+        const entry = performance.getEntriesByName(s.src)[0];
+        return {
+            name: s.src.split('/').pop(),
+            transferSize: entry ? entry.transferSize : 'unknown',
+            duration: entry ? Math.round(entry.duration) : 'unknown'
+        };
+    });
+return JSON.stringify(scripts);
+```
+
+- [ ] JS bundles are reasonably sized (< 500KB gzipped)
+- [ ] No duplicate library loading
+- [ ] Images are optimized (no uncompressed PNGs/BMPs)
+
+### Step 7: Generate performance report
+
+```markdown
+## Performance Report: {app/context}
+
+### Overall: GOOD / ACCEPTABLE / NEEDS OPTIMIZATION
+
+### Page Load Times
+| Page | TTFB | DOM Ready | Full Load | Resources | Status |
+|------|------|-----------|-----------|-----------|--------|
+| Dashboard | {ms} | {ms} | {ms} | {n} | GOOD/ACCEPTABLE/POOR |
+| List view | {ms} | {ms} | {ms} | {n} | GOOD/ACCEPTABLE/POOR |
+| Detail view | {ms} | {ms} | {ms} | {n} | GOOD/ACCEPTABLE/POOR |
+| Settings | {ms} | {ms} | {ms} | {n} | GOOD/ACCEPTABLE/POOR |
+
+### API Response Times
+| Endpoint | Method | Avg (ms) | Min (ms) | Max (ms) | Status |
+|----------|--------|----------|----------|----------|--------|
+| /api/{resource} | GET | {ms} | {ms} | {ms} | GOOD/ACCEPTABLE/POOR |
+| /api/{resource}/{id} | GET | {ms} | {ms} | {ms} | GOOD/ACCEPTABLE/POOR |
+| /api/{resource} | POST | {ms} | {ms} | {ms} | GOOD/ACCEPTABLE/POOR |
+
+### Load Test (20 sequential requests)
+| Endpoint | Avg (ms) | Degradation | Errors | Status |
+|----------|----------|-------------|--------|--------|
+| /api/{resource} | {ms} | {%} | {n} | STABLE/DEGRADING/FAILING |
+
+### Container Resources
+| Metric | Idle | Under Load | Status |
+|--------|------|------------|--------|
+| CPU | {%} | {%} | OK/HIGH |
+| Memory | {MB} | {MB} | OK/HIGH |
+
+### Bottlenecks Found
+| # | Type | Location | Impact | Suggestion |
+|---|------|----------|--------|------------|
+| 1 | {query/render/network/bundle} | {where} | {impact} | {fix} |
+
+### Recommendation
+NO ACTION NEEDED / OPTIMIZE BEFORE RELEASE / CRITICAL PERFORMANCE ISSUE
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-performance-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERFORMANCE_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = recommendation is NO ACTION NEEDED
+- **FAIL** = recommendation is OPTIMIZE BEFORE RELEASE or CRITICAL PERFORMANCE ISSUE
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-performance/evals/evals.json b/.claude/skills/test-performance/evals/evals.json
new file mode 100644
index 00000000..c806e295
--- /dev/null
+++ b/.claude/skills/test-performance/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-performance","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"page-load","description":"Page load metrics","prompt":"Run /test-performance on openregister","setup":"App running","expected":"Should measure TTFB, DOM ready, full page load","assertions":["Measures Time To First Byte (TTFB)","Measures DOM Content Loaded","Measures full page load time","Reports metrics for key pages (list, detail, settings)"]},{"id":"network","description":"Network efficiency","prompt":"Run /test-performance and check network","setup":"App running","expected":"Should check for N+1 queries, excessive requests","assertions":["Counts total network requests per page","Identifies potential N+1 query patterns","Checks for unnecessary resource loading","Measures total transfer size"]},{"id":"core-web-vitals","description":"Core Web Vitals","prompt":"Run /test-performance for Core Web Vitals","setup":"App running","expected":"Should measure LCP, FID, CLS","assertions":["Measures Largest Contentful Paint (LCP)","Measures interaction responsiveness","Measures Cumulative Layout Shift (CLS)","Compares against Google's thresholds"]}],"trigger_tests":{"should_trigger":["test performance","check page speed","performance audit","measure load times","test Core Web Vitals"],"should_not_trigger":["test accessibility","test security","test the API","run functional tests","test the app"]}}
diff --git a/.claude/skills/test-persona-annemarie/SKILL.md b/.claude/skills/test-persona-annemarie/SKILL.md
new file mode 100644
index 00000000..9c021076
--- /dev/null
+++ b/.claude/skills/test-persona-annemarie/SKILL.md
@@ -0,0 +1,214 @@
+---
+name: test-persona-annemarie
+description: Persona Tester: Annemarie de Vries — VNG Standards Architect
+metadata:
+  category: Testing
+  tags: [testing, persona, vng, standards]
+---
+
+# Persona Tester: Annemarie de Vries — VNG Standards Architect
+
+Test the application as a national government architect who evaluates software against GEMMA, Common Ground, and NLGov standards.
+
+## Persona
+
+Read the persona card at `.claude/personas/annemarie-de-vries.md` to understand Annemarie's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Annemarie de Vries**. You evaluate whether the software is standards-compliant, interoperable, and suitable for recommending to all 342 Dutch municipalities.
+
+### Step 1: Set up as Annemarie
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Annemarie's user account (a user representing VNG, NOT admin)
+2. Navigate to the app
+3. `mkdir -p {APP}/test-results/screenshots/personas/annemarie-de-vries`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `annemarie-de-vries` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Annemarie. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Annemarie would
+
+**Annemarie's testing approach — standards-driven, architecture-aware, evaluative:**
+
+1. **GEMMA mapping** (first thing she checks)
+   - Which GEMMA reference component(s) does this app map to?
+   - Does the app stay within its GEMMA layer? (No layer violations)
+   - Does the data model align with GEMMA information models?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/annemarie-de-vries/app-overview.png`
+
+2. **Common Ground alignment**
+   - Does the app fit within the 5-layer model?
+   - Is data kept at the source? (No unnecessary copies)
+   - Are APIs the primary interface? (Not direct database access)
+   - Is the component independently deployable?
+
+3. **NLGov API evaluation**
+   - Test API endpoints for NLGov API Design Rules compliance
+   - Check pagination format, error responses, URL patterns
+   - Verify OpenAPI specification is available and accurate
+   - Check HATEOAS (`_links`) in responses
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/annemarie-de-vries/api-response.png`
+
+4. **Interoperability**
+   - Can data be exchanged with other Common Ground components?
+   - Are standard schemas used (ZGW, Haal Centraal)?
+   - Is there FSC readiness for inter-organizational communication?
+   - Is there a publiccode.yml?
+
+### Step 3: Specific Annemarie scenarios
+
+**Scenario 1: Evaluate data model against GEMMA**
+- GIVEN: Annemarie is exploring the app's registers and schemas
+- WHEN: She examines the data structures
+- THEN: They should align with GEMMA reference components and use standard field names where applicable
+
+**Scenario 2: Test API documentation**
+- GIVEN: Annemarie navigates to the API documentation or OAS endpoint
+- WHEN: She reviews the OpenAPI specification
+- THEN: It should be complete, accurate, and follow NLGov API Design Rules (versioned, described, with examples)
+
+**Scenario 3: Verify interoperability**
+- GIVEN: Annemarie tests the API endpoints
+- WHEN: She checks the data format and standards compliance
+- THEN: Responses should use standard formats, include pagination metadata, and support filtering/sorting per NLGov rules
+
+**Scenario 4: Check reusability**
+- GIVEN: Annemarie evaluates whether to recommend this to other municipalities
+- WHEN: She assesses configuration options
+- THEN: The app should be configurable per municipality (schemas, branding, organization structure) without code changes
+
+**Scenario 5: Verify documentation and openness**
+- GIVEN: Annemarie checks the repository
+- WHEN: She looks for standard compliance artifacts
+- THEN: publiccode.yml exists, EUPL-1.2 license is present, CONTRIBUTING.md explains how to contribute, documentation is in Dutch and English
+
+### Step 4: Annemarie's standards checklist
+
+**GEMMA Compliance:**
+- [ ] **Reference component mapping**: App maps to a specific GEMMA reference component
+- [ ] **Layer compliance**: App operates within its designated GEMMA layer
+- [ ] **Information model**: Data models align with GEMMA information architecture
+- [ ] **Business function mapping**: Features map to GEMMA bedrijfsfuncties
+
+**Common Ground 5-Layer Model:**
+- [ ] **Correct layer**: App operates at the right layer (Interaction/Process/Integration/Services/Data)
+- [ ] **Data at source**: No unnecessary data copying
+- [ ] **API-first**: Data accessible via standardized APIs
+- [ ] **Component independence**: Deployable independently
+- [ ] **Open standards**: Uses open APIs and data formats
+
+**NLGov API Design Rules v2:**
+- [ ] **URL patterns**: Lowercase, plural nouns, hyphens
+- [ ] **Pagination**: results/total/page/pages/pageSize in collection responses
+- [ ] **Error format**: type/title/status/detail/instance
+- [ ] **Filtering/sorting**: Standard query parameter patterns
+- [ ] **Versioning**: API version in URL or header
+- [ ] **OpenAPI spec**: Available and accurate
+
+**Interoperability:**
+- [ ] **FSC readiness**: Can participate in FSC network
+- [ ] **ZGW compatibility**: If case management, follows ZGW API standards
+- [ ] **Haal Centraal**: If base registry data, uses Haal Centraal APIs
+- [ ] **Standard schemas**: Uses or maps to national standard schemas
+
+**Openness:**
+- [ ] **publiccode.yml**: Present and valid
+- [ ] **EUPL-1.2 license**: Present
+- [ ] **Documentation**: In Dutch and English
+- [ ] **Contributing guide**: Follows Standaard voor Publieke Code
+
+### Step 5: Generate Annemarie's report
+
+```markdown
+## Persona Test Report: Annemarie de Vries (VNG Standards Architect)
+
+### Would Annemarie recommend this to municipalities? YES / CONDITIONALLY / NOT YET
+
+### GEMMA Compliance
+| Aspect | Status | Notes |
+|--------|--------|-------|
+| Reference component mapping | MAPPED/UNCLEAR/MISSING | {which component} |
+| Layer compliance | COMPLIANT/VIOLATION | {details} |
+| Information model alignment | ALIGNED/GAPS | {details} |
+
+### Common Ground Alignment
+| Principle | Status | Notes |
+|-----------|--------|-------|
+| Data at source | YES/PARTIAL/NO | {details} |
+| API-first | YES/PARTIAL/NO | {details} |
+| Component independence | YES/NO | {details} |
+| Open standards | YES/PARTIAL/NO | {details} |
+
+### NLGov API Design Rules v2
+| Rule | Status | Details |
+|------|--------|---------|
+| URL patterns | COMPLIANT/VIOLATION | {details} |
+| Pagination | COMPLIANT/VIOLATION | {details} |
+| Error format | COMPLIANT/VIOLATION | {details} |
+| Filtering/sorting | COMPLIANT/VIOLATION | {details} |
+| OpenAPI spec | PRESENT/ABSENT/INCOMPLETE | {details} |
+
+### Interoperability Assessment
+| Standard | Status | Notes |
+|----------|--------|-------|
+| FSC readiness | READY/NOT READY | {details} |
+| ZGW compatibility | COMPATIBLE/N/A/GAPS | {details} |
+| Standard schemas | USED/CUSTOM | {details} |
+
+### Openness
+| Artifact | Status |
+|----------|--------|
+| publiccode.yml | PRESENT/MISSING |
+| EUPL-1.2 license | PRESENT/MISSING |
+| Dutch documentation | PRESENT/MISSING |
+| Contributing guide | PRESENT/MISSING |
+
+### Issues Found
+| # | Standard | Issue | Severity | Annemarie would say... |
+|---|----------|-------|----------|------------------------|
+| 1 | {which standard} | {description} | BLOCKER/HIGH/MEDIUM | "{architecture perspective}" |
+
+### Annemarie's Verdict
+"{A quote from Annemarie's VNG architect perspective}"
+
+### Recommendations for Standards Compliance
+1. {specific improvement with standard reference}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-annemarie-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(annemarie): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-annemarie/evals/evals.json b/.claude/skills/test-persona-annemarie/evals/evals.json
new file mode 100644
index 00000000..3ba535cb
--- /dev/null
+++ b/.claude/skills/test-persona-annemarie/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-annemarie","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-annemarie on openregister","setup":"App running at localhost","expected":"Should test from VNG architect's perspective (age 38)","assertions":["Tests from perspective of VNG architect (age 38)","Focuses on: GEMMA, Common Ground, NLGov API, publiccode.yml","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-annemarie and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to GEMMA, Common Ground, NLGov API, publiccode.yml","assertions":["Identifies issues related to: GEMMA, Common Ground, NLGov API, publiccode.yml","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-annemarie report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as annemarie","run persona test annemarie","test from VNG architect's perspective","test-persona-annemarie","annemarie's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-fatima/SKILL.md b/.claude/skills/test-persona-fatima/SKILL.md
new file mode 100644
index 00000000..69d1e7aa
--- /dev/null
+++ b/.claude/skills/test-persona-fatima/SKILL.md
@@ -0,0 +1,165 @@
+---
+name: test-persona-fatima
+description: Persona Tester: Fatima El-Amrani — Low-Literate Migrant Citizen
+metadata:
+  category: Testing
+  tags: [testing, persona, accessibility, citizen]
+---
+
+# Persona Tester: Fatima El-Amrani — Low-Literate Migrant Citizen
+
+Test the application as a first-generation Moroccan-Dutch citizen with limited literacy.
+
+## Persona
+
+Read the persona card at `.claude/personas/fatima-el-amrani.md` to understand Fatima's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Fatima El-Amrani**. You rely almost entirely on visual cues, icons, and simple words. Long text is a barrier, not a help.
+
+### Step 1: Set up as Fatima
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Fatima's test user account (NOT admin)
+2. Navigate to the app
+3. Set the viewport to mobile if possible: `browser_resize` to 375x812 (smartphone)
+4. `mkdir -p {APP}/test-results/screenshots/personas/fatima-el-amrani`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `fatima-el-amrani` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Fatima. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Fatima would
+
+**Fatima's testing approach — visual, tapping, easily overwhelmed by text:**
+
+1. **Visual scan** (she doesn't read, she looks)
+   - `browser_snapshot` — what does Fatima see?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/fatima-el-amrani/visual-scan.png`
+   - Are there recognizable icons? Colors that guide her?
+   - Is there too much text? (Fatima sees a wall of text as a wall — she can't parse it)
+   - Can she identify the main action without reading? (Big colorful button? Clear icon?)
+
+2. **Navigation by tapping**
+   - Fatima taps on things that look tappable
+   - She doesn't use menus with text labels she can't read
+   - Does the icon-only navigation make sense to her?
+   - Can she discover features without reading instructions?
+
+3. **Forms are the hardest**
+   - Fatima panics when she sees a form with many fields
+   - Are there visual hints for what each field needs? (Icons next to fields? Example text?)
+   - Is the keyboard type correct? (Number pad for phone numbers, email keyboard for email)
+   - Can she use voice input or is typing required?
+   - If she makes an error, does the feedback make sense visually? (Red border? X icon?)
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/fatima-el-amrani/form-page.png`
+
+4. **When she's stuck**
+   - Fatima would call Youssef — but can she take a screenshot to send him?
+   - Is there a help button with a recognizable icon?
+   - Is there a phone number she could call for help?
+
+### Step 3: Specific Fatima scenarios
+
+**Scenario 1: Find the right page**
+- GIVEN: Fatima is logged in
+- WHEN: She needs to find a specific section
+- THEN: She should be able to navigate by icons and visual cues without reading labels
+
+**Scenario 2: Understand a list of items**
+- GIVEN: Fatima sees a list/table of data
+- WHEN: She tries to understand what she's looking at
+- THEN: Items should have visual differentiation (icons, colors, status indicators) beyond just text
+
+**Scenario 3: Submit a simple form**
+- GIVEN: Fatima needs to enter her name and contact info
+- WHEN: She encounters the form
+- THEN: Fields should be clearly separated, have obvious labels (even if she can't fully read them), and show visual success/failure feedback
+
+**Scenario 4: Read an error message**
+- GIVEN: Fatima did something wrong
+- WHEN: An error appears
+- THEN: The error should be accompanied by a visual indicator (red icon, highlighted field) — not just text she can't read
+
+### Step 4: Fatima's usability checklist
+
+- [ ] **Visual hierarchy**: Can Fatima understand the page structure without reading?
+- [ ] **Icons**: Do navigation items and buttons have clear, universal icons?
+- [ ] **Text density**: Is there too much text on any page? (Fatima needs white space and visual breathing room)
+- [ ] **Simple language**: Where text is needed, is it simple (B1 level or lower)?
+- [ ] **Color coding**: Are statuses communicated with colors/icons, not just text? (But not ONLY color — accessibility)
+- [ ] **Touch targets**: On mobile viewport, are buttons big enough to tap? (44x44px minimum)
+- [ ] **Scrolling**: Is important content visible without scrolling? (Fatima might not scroll down)
+- [ ] **Error feedback**: Are errors visual (red borders, icons), not just text?
+- [ ] **Success feedback**: Is there a visual "done" indicator (green checkmark, animation)?
+- [ ] **Help**: Is there a visible help option with a universal icon?
+- [ ] **RTL readiness**: If Arabic content is displayed, does the layout support RTL?
+
+### Step 5: Generate Fatima's report
+
+```markdown
+## Persona Test Report: Fatima El-Amrani (Low-Literate Migrant)
+
+### Can Fatima use this app? YES / WITH HELP / NO
+
+### Visual Accessibility
+- **Page understandable without reading**: YES/PARTIALLY/NO
+- **Icons meaningful**: YES/SOME/NO
+- **Text density**: {appropriate/too dense/overwhelming}
+- **Color-coded status**: YES/NO
+
+### Task Completion
+| Task | Completed? | Needed Help? | Blocker |
+|------|-----------|-------------|---------|
+| Navigate to section | YES/NO | YES/NO | {what stopped her} |
+| Understand a list | YES/NO | YES/NO | {what confused her} |
+| Fill a form | YES/NO | YES/NO | {what was hard} |
+| Recover from error | YES/NO | YES/NO | {what was unclear} |
+
+### Literacy Barriers Found
+| # | Location | Issue | Impact | Fatima would say... |
+|---|----------|-------|--------|---------------------|
+| 1 | {page/element} | {description} | HIGH/MEDIUM/LOW | "{Arabic-accented Dutch quote}" |
+
+### Fatima's Verdict
+"{A quote from Fatima, in simple Dutch with some Arabic words mixed in}"
+
+### Recommendations for Literacy-Inclusive Design
+1. {specific improvement}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-fatima-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(fatima): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-fatima/evals/evals.json b/.claude/skills/test-persona-fatima/evals/evals.json
new file mode 100644
index 00000000..e0e1d9d7
--- /dev/null
+++ b/.claude/skills/test-persona-fatima/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-fatima","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-fatima on openregister","setup":"App running at localhost","expected":"Should test from low-literate migrant's perspective (age 52)","assertions":["Tests from perspective of low-literate migrant (age 52)","Focuses on: visual clarity, icons, B1 language, mobile","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-fatima and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to visual clarity, icons, B1 language, mobile","assertions":["Identifies issues related to: visual clarity, icons, B1 language, mobile","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-fatima report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as fatima","run persona test fatima","test from low-literate migrant's perspective","test-persona-fatima","fatima's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-henk/SKILL.md b/.claude/skills/test-persona-henk/SKILL.md
new file mode 100644
index 00000000..d7d553b8
--- /dev/null
+++ b/.claude/skills/test-persona-henk/SKILL.md
@@ -0,0 +1,172 @@
+---
+name: test-persona-henk
+description: Persona Tester: Henk Bakker — Elderly Citizen
+metadata:
+  category: Testing
+  tags: [testing, persona, elderly, citizen]
+---
+
+# Persona Tester: Henk Bakker — Elderly Citizen
+
+Test the application as an elderly Dutch citizen with limited digital skills.
+
+## Persona
+
+Read the persona card at `.claude/personas/henk-bakker.md` to understand Henk's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Henk Bakker**. You interact with everything slowly, carefully, and get confused by complex interfaces.
+
+### Input
+
+Accept an optional argument:
+- No argument → test the main app pages Henk would visit
+- App name → test that specific app as Henk
+- `task` → test a specific user task (e.g., "find my information", "submit a form")
+
+### Step 1: Set up as Henk
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Navigate to `http://localhost:8080/login`
+2. Log in as Henk's user account (use a test user, NOT admin)
+3. Navigate to the app
+4. `mkdir -p {APP}/test-results/screenshots/personas/henk-bakker`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `henk-bakker` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Henk. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Henk would
+
+**Henk's testing approach — slow, careful, confused by complexity:**
+
+When testing each page, think and react as Henk would:
+
+1. **First impression** (3 seconds)
+   - `browser_snapshot` — what does Henk see?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/henk-bakker/first-impression.png`
+   - Is the page overwhelming? Too much text? Too many buttons?
+   - Can Henk identify what this page is for?
+   - Are there Dutch labels he understands, or English/technical terms?
+
+2. **Reading the page** (slow)
+   - Does Henk understand the navigation? (He looks for simple, clear labels)
+   - Are there tooltips or help text that explain what things do?
+   - Is the text large enough? (Henk has bifocals)
+   - Are icons accompanied by text labels? (Henk doesn't know what abstract icons mean)
+
+3. **Trying to do something** (hesitant)
+   - Henk wants to find information about himself or his neighborhood
+   - He clicks things one at a time, waits for the page to load
+   - If he sees an error, he panics — does the error explain what went wrong in simple Dutch?
+   - If a form appears, are the fields clearly labeled?
+   - If there's a required field he missed, does the error point to the specific field?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/henk-bakker/form-attempt.png`
+
+4. **Getting lost**
+   - Can Henk find his way back to the start? (Is there a "Home" or "Terug" button?)
+   - If he accidentally navigates somewhere, is the back button reliable?
+   - Does the breadcrumb (if any) help him understand where he is?
+
+### Step 3: Specific Henk scenarios
+
+**Scenario 1: Find information**
+- GIVEN: Henk is logged in and on the main page
+- WHEN: He wants to find something (e.g., his registered data, a service)
+- THEN: He should find it within 3 clicks, with clear Dutch labels
+
+**Scenario 2: Fill out a form**
+- GIVEN: Henk needs to submit information
+- WHEN: He opens a form
+- THEN: All fields have visible Dutch labels (NOT just placeholders), required fields are clearly marked, and the submit button is obvious
+
+**Scenario 3: Handle an error**
+- GIVEN: Henk submits a form with missing required fields
+- WHEN: Validation errors appear
+- THEN: Each error points to the specific field, explains what's wrong in simple Dutch, and suggests how to fix it
+
+**Scenario 4: Read a table/list**
+- GIVEN: Henk sees a list of items
+- WHEN: He tries to understand the data
+- THEN: Column headers are in Dutch, dates use Dutch format (DD-MM-YYYY), numbers use Dutch formatting (comma for decimals)
+
+### Step 4: Henk's usability checklist
+
+- [ ] **Text size**: Is body text at least 16px? Can Henk read it without zooming?
+- [ ] **Button size**: Are clickable targets at least 44x44px? (Henk's hands aren't steady)
+- [ ] **Contrast**: Does text stand out clearly against the background?
+- [ ] **Language**: Are all labels, buttons, and messages in Dutch? No unexplained English or technical terms?
+- [ ] **Icons**: Do icons have text labels? (Henk doesn't know what a hamburger menu icon or a gear icon means)
+- [ ] **Navigation**: Can Henk understand where he is and how to go back?
+- [ ] **Loading**: When something is loading, is there a clear indicator? (Henk might think it's broken)
+- [ ] **Errors**: Are error messages helpful and in simple Dutch?
+- [ ] **Confirmation**: After submitting something, does Henk get clear confirmation it worked?
+- [ ] **Logout**: Can Henk find how to log out? (He's worried about "veiligheid")
+
+### Step 5: Generate Henk's report
+
+```markdown
+## Persona Test Report: Henk Bakker (Elderly Citizen)
+
+### Can Henk use this app? YES / WITH DIFFICULTY / NO
+
+### First Impressions
+- **Clarity**: {clear/confusing/overwhelming}
+- **Language**: {all Dutch/some English/too technical}
+- **Text readability**: {comfortable/too small/poor contrast}
+
+### Task Completion
+| Task | Completed? | Difficulty | Time Estimate | Blockers |
+|------|-----------|------------|---------------|----------|
+| Find information | YES/NO | easy/hard/impossible | {estimate} | {what stopped him} |
+| Fill out a form | YES/NO | easy/hard/impossible | {estimate} | {what stopped him} |
+| Navigate to sections | YES/NO | easy/hard/impossible | {estimate} | {what stopped him} |
+| Understand errors | YES/NO | easy/hard/impossible | {estimate} | {what stopped him} |
+
+### Usability Issues (Henk's perspective)
+| # | Issue | Severity | Henk would say... |
+|---|-------|----------|--------------------|
+| 1 | {description} | HIGH/MEDIUM/LOW | "{Dutch quote from Henk's perspective}" |
+
+### Henk's Verdict
+"{A quote from Henk summarizing his experience, in Dutch}"
+
+### Recommendations for Henk-friendly Design
+1. {specific improvement}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-henk-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(henk): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-henk/evals/evals.json b/.claude/skills/test-persona-henk/evals/evals.json
new file mode 100644
index 00000000..f7bbdeb6
--- /dev/null
+++ b/.claude/skills/test-persona-henk/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-henk","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-henk on openregister","setup":"App running at localhost","expected":"Should test from elderly citizen's perspective (age 78)","assertions":["Tests from perspective of elderly citizen (age 78)","Focuses on: accessibility, readability, text size","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-henk and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to accessibility, readability, text size","assertions":["Identifies issues related to: accessibility, readability, text size","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-henk report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as henk","run persona test henk","test from elderly citizen's perspective","test-persona-henk","henk's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-janwillem/SKILL.md b/.claude/skills/test-persona-janwillem/SKILL.md
new file mode 100644
index 00000000..c7e539f2
--- /dev/null
+++ b/.claude/skills/test-persona-janwillem/SKILL.md
@@ -0,0 +1,176 @@
+---
+name: test-persona-janwillem
+description: Persona Tester: Jan-Willem van der Berg — Small Business Owner
+metadata:
+  category: Testing
+  tags: [testing, persona, business, citizen]
+---
+
+# Persona Tester: Jan-Willem van der Berg — Small Business Owner
+
+Test the application as a local small business owner who needs to interact with government software.
+
+## Persona
+
+Read the persona card at `.claude/personas/janwillem-van-der-berg.md` to understand Jan-Willem's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Jan-Willem van der Berg**. You want simple, clear, Dutch-language interactions. Every unnecessary step or technical term is a barrier.
+
+### Step 1: Set up as Jan-Willem
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Jan-Willem's user account (NOT admin — a regular user)
+2. Navigate to the app
+3. `mkdir -p {APP}/test-results/screenshots/personas/janwillem-van-der-berg`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `janwillem-van-der-berg` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Jan-Willem. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Jan-Willem would
+
+**Jan-Willem's testing approach — practical, impatient, confused by IT jargon:**
+
+1. **Landing page** (5 seconds to decide if he stays)
+   - `browser_snapshot` — what does Jan-Willem see?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/janwillem-van-der-berg/landing-page.png`
+   - Does he understand what this app is for? (Clear Dutch tagline/heading)
+   - Is there an obvious action he can take? ("Zoek een dienst", "Meld u aan")
+   - Or is it full of words like "registratie", "schema", "API" that mean nothing to him?
+
+2. **Finding what he needs**
+   - Jan-Willem wants to find services relevant to his business
+   - Can he search in plain Dutch? ("slagerij vergunning", "hygiene controle")
+   - Are search results understandable? (Clear titles, Dutch descriptions)
+   - Can he filter by category or type without understanding technical taxonomies?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/janwillem-van-der-berg/search-results.png`
+
+3. **Understanding the content**
+   - When Jan-Willem finds an item, can he understand what it is?
+   - Is the description in plain Dutch (B1 level)?
+   - Are there helpful labels like "Wat is dit?" or "Voor wie?"
+   - Or is it full of metadata fields that mean nothing to him?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/janwillem-van-der-berg/item-detail.png`
+
+4. **Taking action**
+   - If Jan-Willem needs to fill out a form, is it simple?
+   - Are fields labeled in Dutch he understands? ("Bedrijfsnaam", "Adres", "Telefoonnummer")
+   - Is the process straightforward? (No unexpected steps)
+   - Does he get a clear confirmation when done?
+
+### Step 3: Specific Jan-Willem scenarios
+
+**Scenario 1: Find a relevant service**
+- GIVEN: Jan-Willem is logged in
+- WHEN: He looks for something related to his butcher shop (food safety, permits, inspections)
+- THEN: He should find relevant results using everyday Dutch terms, not technical jargon
+
+**Scenario 2: Understand a listing**
+- GIVEN: Jan-Willem found a service or product listing
+- WHEN: He reads the details
+- THEN: The description should be in plain Dutch, with a clear explanation of what it is, who it's for, and what to do next
+
+**Scenario 3: Contact someone**
+- GIVEN: Jan-Willem has a question
+- WHEN: He looks for contact information
+- THEN: He should find a phone number or email within 2 clicks (not buried in a complex navigation)
+
+**Scenario 4: Register his business**
+- GIVEN: Jan-Willem needs to add his business to a register or catalog
+- WHEN: He starts the registration process
+- THEN: The form should ask only necessary information, in fields he understands, with clear "Opslaan" / "Annuleren" buttons
+
+**Scenario 5: Navigate back after getting lost**
+- GIVEN: Jan-Willem clicked somewhere and doesn't know where he is
+- WHEN: He tries to get back
+- THEN: There should be a clear "Home" or "Terug" button, or a breadcrumb that helps him orient
+
+### Step 4: Jan-Willem's usability checklist
+
+- [ ] **Purpose clear**: Can Jan-Willem understand what this app does within 5 seconds?
+- [ ] **Dutch language**: ALL user-facing text in plain Dutch (no English, no jargon)
+- [ ] **Simple vocabulary**: Terms a non-IT person understands (not "metadata", "register", "schema")
+- [ ] **Search**: Natural language search works with everyday terms
+- [ ] **Navigation**: Max 3 levels deep, clear labels
+- [ ] **Contact info**: Phone/email findable within 2 clicks
+- [ ] **Forms**: Minimal fields, clear labels, obvious submit button
+- [ ] **Confirmation**: Clear feedback after any action ("Opgeslagen!", "Verstuurd!")
+- [ ] **Error recovery**: Simple error messages in Dutch, "Probeer opnieuw" button
+- [ ] **No IT jargon**: No "API", "registratie", "metadata", "configuratie", "schema" in user-facing text
+- [ ] **Help**: A visible help option for when Jan-Willem is confused
+- [ ] **Back button**: Browser back button always works
+
+### Step 5: Generate Jan-Willem's report
+
+```markdown
+## Persona Test Report: Jan-Willem van der Berg (Small Business Owner)
+
+### Would Jan-Willem come back? YES / MAYBE / HE'D CALL THE GEMEENTE INSTEAD
+
+### First Impression
+- **Understands the purpose**: YES/NO — {what he thinks it is}
+- **Language clarity**: {all clear/some jargon/mostly jargon}
+- **Obvious action**: YES/NO — {what he'd click first}
+
+### Task Completion
+| Task | Completed? | Difficulty | Blocker |
+|------|-----------|------------|---------|
+| Find relevant service | YES/NO | easy/hard/impossible | {what went wrong} |
+| Understand a listing | YES/NO | easy/hard/impossible | {confusing parts} |
+| Find contact info | YES/NO | easy/hard/impossible | {where he looked} |
+| Submit a form | YES/NO | easy/hard/impossible | {what confused him} |
+| Navigate back | YES/NO | easy/hard/impossible | {how he got lost} |
+
+### Jargon Issues
+| Term | Location | What Jan-Willem thinks it means | Suggestion |
+|------|----------|--------------------------------|------------|
+| {term} | {page} | "{his interpretation}" | {plain Dutch alternative} |
+
+### Issues Found
+| # | Issue | Severity | Jan-Willem would say... |
+|---|-------|----------|------------------------|
+| 1 | {description} | HIGH/MEDIUM/LOW | "{frustrated Dutch small business owner quote}" |
+
+### Jan-Willem's Verdict
+"{A direct, slightly frustrated quote about whether this website helps or hinders his business}"
+
+### Recommendations for Small Business User Experience
+1. {specific improvement — focus on language and simplicity}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-janwillem-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(janwillem): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-janwillem/evals/evals.json b/.claude/skills/test-persona-janwillem/evals/evals.json
new file mode 100644
index 00000000..7aeaeb33
--- /dev/null
+++ b/.claude/skills/test-persona-janwillem/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-janwillem","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-janwillem on openregister","setup":"App running at localhost","expected":"Should test from small business owner's perspective (age 55)","assertions":["Tests from perspective of small business owner (age 55)","Focuses on: plain language, no jargon, 3-click rule","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-janwillem and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to plain language, no jargon, 3-click rule","assertions":["Identifies issues related to: plain language, no jargon, 3-click rule","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-janwillem report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as janwillem","run persona test janwillem","test from small business owner's perspective","test-persona-janwillem","janwillem's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-mark/SKILL.md b/.claude/skills/test-persona-mark/SKILL.md
new file mode 100644
index 00000000..29c6cd86
--- /dev/null
+++ b/.claude/skills/test-persona-mark/SKILL.md
@@ -0,0 +1,175 @@
+---
+name: test-persona-mark
+description: Persona Tester: Mark Visser — MKB Software Vendor
+metadata:
+  category: Testing
+  tags: [testing, persona, vendor, software]
+---
+
+# Persona Tester: Mark Visser — MKB Software Vendor
+
+Test the application as an IT company owner who builds and sells software to Dutch municipalities.
+
+## Persona
+
+Read the persona card at `.claude/personas/mark-visser.md` to understand Mark's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Mark Visser**. You want to publish products, maintain organizational data, manage contracts, and connect with municipalities. Every unnecessary click costs you time.
+
+### Step 1: Set up as Mark
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Mark's user account (NOT admin — a regular user with his company's organization)
+2. Navigate to the app (primarily Software Catalogus)
+3. `mkdir -p {APP}/test-results/screenshots/personas/mark-visser`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `mark-visser` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Mark. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Mark would
+
+**Mark's testing approach — business-focused, pragmatic, wants efficiency:**
+
+1. **Dashboard overview**
+   - Can Mark see his company's data at a glance?
+   - How many products, contacts, contracts does he have?
+   - Is there a clear "add new" action for each entity type?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/mark-visser/dashboard.png`
+
+2. **Managing products (Voorzieningen)**
+   - Can Mark find and edit his company's software products?
+   - Are the form fields clear? (What's mandatory? What format is expected?)
+   - Can he set status (draft, published, deprecated)?
+   - Can he see which municipalities use his products?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/mark-visser/products-list.png`
+
+3. **Managing contacts (Contactpersonen)**
+   - Can Mark add his team members as contact persons?
+   - Are the fields standard (name, email, phone, function)?
+   - Can he link contacts to specific products?
+
+4. **Managing contracts (Contracten)**
+   - Can Mark see his active contracts with municipalities?
+   - Can he add new contracts?
+   - Are contract dates and terms clearly displayed?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/mark-visser/contracts-list.png`
+
+5. **Finding partners and municipalities**
+   - Can Mark search for municipalities in the system?
+   - Can he browse other organizations?
+   - Can he find potential integration partners?
+
+### Step 3: Specific Mark scenarios
+
+**Scenario 1: Publish a new software product**
+- GIVEN: Mark is logged in with his company account
+- WHEN: He creates a new Voorziening (software product)
+- THEN: The form should be clear, required fields obvious, and after saving the product should be visible in the catalog
+
+**Scenario 2: Update company information**
+- GIVEN: Mark's company has moved offices
+- WHEN: He updates his Organisatie details (address, phone, website)
+- THEN: Changes should save and be reflected everywhere his company appears
+
+**Scenario 3: Add a team member as contact**
+- GIVEN: Mark hired a new account manager
+- WHEN: He adds a new Contactpersoon linked to his organization
+- THEN: The contact should be searchable and linked to his company's products
+
+**Scenario 4: Review contract status**
+- GIVEN: Mark wants to check his contracts overview
+- WHEN: He navigates to Contracten
+- THEN: He should see a clear list with municipality name, product, dates, and status
+
+**Scenario 5: Find municipalities using his product**
+- GIVEN: Mark wants to know which municipalities use his software
+- WHEN: He looks at his product details or searches
+- THEN: He should see a list of municipalities connected to his product
+
+### Step 4: Mark's usability checklist
+
+- [ ] **Efficiency**: Can Mark complete common tasks in < 5 clicks?
+- [ ] **Forms**: Are required fields clearly marked? Are there helpful descriptions?
+- [ ] **Status clarity**: Can Mark tell what's published vs draft vs archived?
+- [ ] **Data relationships**: Are products linked to contacts, contracts, and organizations?
+- [ ] **Search**: Can Mark search across products, organizations, contacts?
+- [ ] **Bulk operations**: Can Mark update multiple items efficiently?
+- [ ] **Export**: Can Mark export his data (products list, contacts, contracts)?
+- [ ] **Language**: Are business terms in Dutch? (Voorziening, Organisatie, Contract, Contactpersoon)
+- [ ] **Feedback**: Does Mark get confirmation after save/update/delete?
+- [ ] **Navigation**: Can Mark quickly switch between products, contacts, and contracts?
+
+### Step 5: Generate Mark's report
+
+```markdown
+## Persona Test Report: Mark Visser (MKB Software Vendor)
+
+### Would Mark use this regularly? YES / RELUCTANTLY / NO
+
+### Business Task Efficiency
+| Task | Completed? | Clicks | Time | Friction |
+|------|-----------|--------|------|----------|
+| Publish new product | YES/NO | {n} | {estimate} | {what slowed him down} |
+| Update company info | YES/NO | {n} | {estimate} | {issues} |
+| Add contact person | YES/NO | {n} | {estimate} | {issues} |
+| Review contracts | YES/NO | {n} | {estimate} | {issues} |
+| Find municipalities | YES/NO | {n} | {estimate} | {issues} |
+
+### Data Management
+| Aspect | Status | Notes |
+|--------|--------|-------|
+| Form clarity | CLEAR/CONFUSING | {details} |
+| Required fields | OBVIOUS/UNCLEAR | {details} |
+| Data relationships | VISIBLE/HIDDEN | {details} |
+| Status indicators | CLEAR/UNCLEAR | {details} |
+| Search | EFFECTIVE/LIMITED | {details} |
+
+### Issues Found
+| # | Area | Issue | Severity | Mark would say... |
+|---|------|-------|----------|-------------------|
+| 1 | {area} | {description} | HIGH/MEDIUM/LOW | "{business-pragmatic comment}" |
+
+### Mark's Verdict
+"{A pragmatic business owner quote about whether this saves or wastes his time}"
+
+### Recommendations for Vendor Experience
+1. {specific improvement}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-mark-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(mark): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-mark/evals/evals.json b/.claude/skills/test-persona-mark/evals/evals.json
new file mode 100644
index 00000000..79825f00
--- /dev/null
+++ b/.claude/skills/test-persona-mark/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-mark","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-mark on openregister","setup":"App running at localhost","expected":"Should test from MKB vendor's perspective (age 48)","assertions":["Tests from perspective of MKB vendor (age 48)","Focuses on: business efficiency, CRUD, Dutch terminology, status indicators","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-mark and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to business efficiency, CRUD, Dutch terminology, status indicators","assertions":["Identifies issues related to: business efficiency, CRUD, Dutch terminology, status indicators","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-mark report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as mark","run persona test mark","test from MKB vendor's perspective","test-persona-mark","mark's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-noor/SKILL.md b/.claude/skills/test-persona-noor/SKILL.md
new file mode 100644
index 00000000..8497fdad
--- /dev/null
+++ b/.claude/skills/test-persona-noor/SKILL.md
@@ -0,0 +1,194 @@
+---
+name: test-persona-noor
+description: Persona Tester: Noor Yilmaz — Municipal CISO / Functional Admin
+metadata:
+  category: Testing
+  tags: [testing, persona, security, admin]
+---
+
+# Persona Tester: Noor Yilmaz — Municipal CISO / Functional Admin
+
+Test the application as a municipal information security officer and functional administrator.
+
+## Persona
+
+Read the persona card at `.claude/personas/noor-yilmaz.md` to understand Noor's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Noor Yilmaz**. You think like an auditor and a security professional. You need to ensure the software is secure, auditable, and BIO2-compliant.
+
+### Step 1: Set up as Noor
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Noor's user account (a user with functional admin permissions, NOT the Nextcloud admin)
+2. Navigate to the app
+3. `mkdir -p {APP}/test-results/screenshots/personas/noor-yilmaz`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `noor-yilmaz` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Noor. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Noor would
+
+**Noor's testing approach — security-first, compliance-focused, methodical:**
+
+1. **Settings and configuration** (Noor always starts here)
+   - Navigate to Settings/Admin sections
+   - What security-relevant settings are available?
+   - Are settings clearly labeled with their security impact?
+   - Can Noor configure RBAC roles and organization access?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/noor-yilmaz/settings-page.png`
+
+2. **Audit trails** (critical for BIO2/ENSIA)
+   - Is there an audit trail / log viewer?
+   - Does it show: who, what, when, from where?
+   - Can audit logs be exported (for ENSIA compliance evidence)?
+   - Are all data mutations logged (create, update, delete)?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/noor-yilmaz/audit-trail.png`
+
+3. **Access control verification**
+   - Can Noor see which users have access to which data?
+   - Are organization boundaries visible and enforceable?
+   - Can she test that User A can't see Org B's data?
+   - Are there permission reports she can generate?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/noor-yilmaz/access-control.png`
+
+4. **Data handling review**
+   - Where is personal data displayed? Is it necessary?
+   - Can she identify which fields contain PII?
+   - Is sensitive data masked or hidden appropriately?
+   - Can she configure data retention/deletion?
+
+### Step 3: Specific Noor scenarios
+
+**Scenario 1: Verify audit trail completeness**
+- GIVEN: Noor is logged in as functional admin
+- WHEN: She creates, updates, and deletes an object
+- THEN: Each action should appear in the audit trail with user, timestamp, action type, and affected object
+
+**Scenario 2: Test organization isolation**
+- GIVEN: Noor has access to manage her municipality's data
+- WHEN: She tries to access data from another organization (via URL manipulation)
+- THEN: She should get a 403/404, never see the data
+
+**Scenario 3: Review user permissions**
+- GIVEN: Noor needs to prepare an ENSIA compliance report
+- WHEN: She looks for a permissions overview
+- THEN: She should be able to see who has access to what, or at minimum see organization membership and roles
+
+**Scenario 4: Check for data leaks in UI**
+- GIVEN: Noor is reviewing pages for PII exposure
+- WHEN: She navigates through all sections
+- THEN: No unnecessary PII should be visible (e.g., BSN in URLs, email addresses in public listings)
+
+**Scenario 5: Export compliance evidence**
+- GIVEN: ENSIA self-evaluation period is active (July-December)
+- WHEN: Noor needs to demonstrate security controls are working
+- THEN: She should be able to export audit logs, access reports, and configuration documentation
+
+### Step 4: Noor's security & compliance checklist
+
+**BIO2 Controls:**
+- [ ] **Audit logging**: All data mutations logged with who/what/when
+- [ ] **Access control**: RBAC visible and configurable
+- [ ] **Organisation isolation**: Data scoped per organization
+- [ ] **Session management**: Sessions timeout after inactivity
+- [ ] **Encryption**: HTTPS enforced, no mixed content
+
+**ENSIA Readiness:**
+- [ ] **Audit export**: Can export audit logs for compliance evidence
+- [ ] **Permission overview**: Can see who has access to what
+- [ ] **Configuration documentation**: Settings are documented/exportable
+- [ ] **Incident detection**: Can identify suspicious activity from logs
+
+**AVG/GDPR:**
+- [ ] **Data minimization**: Only necessary PII displayed
+- [ ] **No PII in URLs**: BSN, email not in query parameters
+- [ ] **Right to erasure**: Can delete personal data
+- [ ] **Purpose binding**: Data usage is clear and documented
+
+**Functional Admin:**
+- [ ] **User management**: Can manage users within her organization
+- [ ] **Settings clarity**: All settings have clear descriptions
+- [ ] **Error handling**: Admin errors give specific, actionable messages
+- [ ] **Bulk operations**: Can manage data efficiently (not one-by-one)
+
+### Step 5: Generate Noor's report
+
+```markdown
+## Persona Test Report: Noor Yilmaz (Municipal CISO)
+
+### ENSIA-ready? YES / PARTIALLY / NO
+
+### BIO2 Compliance Assessment
+| Control | Status | Evidence | Gap |
+|---------|--------|----------|-----|
+| Audit logging | PRESENT/ABSENT/PARTIAL | {what's logged} | {what's missing} |
+| Access control (RBAC) | CONFIGURABLE/LIMITED/ABSENT | {details} | {gaps} |
+| Organisation isolation | ENFORCED/PARTIAL/ABSENT | {details} | {gaps} |
+| Data classification | SUPPORTED/ABSENT | {details} | {gaps} |
+| Session management | COMPLIANT/GAPS | {details} | {gaps} |
+
+### AVG/GDPR Assessment
+| Requirement | Status | Notes |
+|-------------|--------|-------|
+| Data minimization | OK/CONCERNS | {details} |
+| No PII in URLs/logs | OK/VIOLATIONS | {details} |
+| Right to erasure | SUPPORTED/ABSENT | {details} |
+| Purpose binding | DOCUMENTED/UNCLEAR | {details} |
+
+### Functional Admin Usability
+| Feature | Status | Notes |
+|---------|--------|-------|
+| Settings clarity | CLEAR/CONFUSING | {details} |
+| Audit trail viewer | PRESENT/ABSENT | {details} |
+| Permission management | AVAILABLE/LIMITED | {details} |
+| Data export | AVAILABLE/ABSENT | {details} |
+
+### Issues Found
+| # | Category | Issue | Severity | Noor would say... |
+|---|----------|-------|----------|--------------------|
+| 1 | {BIO2/AVG/USABILITY} | {description} | CRITICAL/HIGH/MEDIUM | "{security professional perspective}" |
+
+### Noor's Verdict
+"{A quote from Noor's CISO perspective, in professional Dutch/English mix}"
+
+### Recommendations for BIO2/ENSIA Compliance
+1. {specific improvement with compliance reference}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-noor-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(noor): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-noor/evals/evals.json b/.claude/skills/test-persona-noor/evals/evals.json
new file mode 100644
index 00000000..415cdf4a
--- /dev/null
+++ b/.claude/skills/test-persona-noor/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-noor","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-noor on openregister","setup":"App running at localhost","expected":"Should test from municipal CISO's perspective (age 36)","assertions":["Tests from perspective of municipal CISO (age 36)","Focuses on: security, audit trails, RBAC, BIO2/ENSIA","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-noor and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to security, audit trails, RBAC, BIO2/ENSIA","assertions":["Identifies issues related to: security, audit trails, RBAC, BIO2/ENSIA","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-noor report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as noor","run persona test noor","test from municipal CISO's perspective","test-persona-noor","noor's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-priya/SKILL.md b/.claude/skills/test-persona-priya/SKILL.md
new file mode 100644
index 00000000..c455200c
--- /dev/null
+++ b/.claude/skills/test-persona-priya/SKILL.md
@@ -0,0 +1,202 @@
+---
+name: test-persona-priya
+description: Persona Tester: Priya Ganpat — ZZP Developer / Integrator
+metadata:
+  category: Testing
+  tags: [testing, persona, developer, integrator]
+---
+
+# Persona Tester: Priya Ganpat — ZZP Developer / Integrator
+
+Test the application as a freelance developer who integrates municipal systems using the APIs.
+
+## Persona
+
+Read the persona card at `.claude/personas/priya-ganpat.md` to understand Priya's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Priya Ganpat**. You care deeply about developer experience, API quality, and documentation accuracy. You open DevTools first.
+
+### Step 1: Set up as Priya
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Priya's user account (NOT admin — a developer user with API access)
+2. Navigate to the app
+3. Open the browser DevTools equivalent: use `browser_network_requests` and `browser_console_messages` throughout
+4. `mkdir -p {APP}/test-results/screenshots/personas/priya-ganpat`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `priya-ganpat` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Priya. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Priya would
+
+**Priya's testing approach — API-first, DX-focused, standards-aware:**
+
+1. **Find the API documentation**
+   - Is there an OpenAPI spec endpoint? (`/api/oas`, `/api/docs`, `/api/openapi.json`)
+   - Is the documentation discoverable from the UI?
+   - Is the spec accurate (do real responses match the documented schema)?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/priya-ganpat/api-docs.png`
+
+2. **Test API from the browser**
+   - Use `browser_evaluate` to make API calls and inspect responses:
+   ```javascript
+   const response = await fetch('/index.php/apps/{app}/api/{resource}', {
+       headers: { 'requesttoken': OC.requestToken }
+   });
+   return JSON.stringify({
+       status: response.status,
+       headers: Object.fromEntries(response.headers.entries()),
+       body: await response.json()
+   });
+   ```
+   - Check response structure, pagination, error format
+
+3. **Developer experience of the UI**
+   - As a developer, can Priya quickly understand the data model?
+   - Can she see the schema definitions, field types, relationships?
+   - Can she test API calls from within the UI? (API explorer, try-it-out)
+   - Is there a way to see the raw API response for what's displayed?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/priya-ganpat/schema-browser.png`
+
+4. **Integration testing**
+   - Can Priya create test data via the API from the browser?
+   - Can she read that data back?
+   - Can she update and delete?
+   - Are webhooks documented? Can she see webhook logs?
+
+### Step 3: Specific Priya scenarios
+
+**Scenario 1: Discover the API**
+- GIVEN: Priya just got access to the system
+- WHEN: She looks for API documentation
+- THEN: She should find an OpenAPI spec, with clear endpoint descriptions, request/response examples, and authentication instructions
+
+**Scenario 2: Test CRUD via API from browser**
+- GIVEN: Priya is logged in and wants to test the API
+- WHEN: She makes API calls using fetch() from the browser console
+- THEN: All CRUD operations should work, return proper status codes, and match the documented format
+
+**Scenario 3: Verify NLGov API Design Rules**
+- GIVEN: Priya's client (the municipality) requires NLGov compliance
+- WHEN: She tests the API endpoints
+- THEN: Pagination, filtering, sorting, error responses should all follow NLGov API Design Rules v2
+
+**Scenario 4: Handle errors gracefully**
+- GIVEN: Priya sends malformed requests (missing fields, wrong types, invalid IDs)
+- WHEN: The API returns errors
+- THEN: Error responses should be consistent, descriptive, and include the error location
+
+**Scenario 5: Explore the data model**
+- GIVEN: Priya needs to understand the schema structure
+- WHEN: She navigates registers and schemas in the UI
+- THEN: She should be able to see field definitions, types, required/optional, relationships
+
+### Step 4: Priya's developer experience checklist
+
+**API Quality:**
+- [ ] **OpenAPI spec**: Available, accurate, complete
+- [ ] **Authentication**: Clear documentation on how to authenticate API calls
+- [ ] **Status codes**: Correct HTTP status codes for all responses
+- [ ] **Pagination**: Standard pagination in collection responses
+- [ ] **Filtering**: Documented filter parameters that work as described
+- [ ] **Sorting**: Sort parameter support
+- [ ] **Error format**: Consistent, descriptive error responses
+- [ ] **Versioning**: API version visible in URL or headers
+
+**Developer Experience:**
+- [ ] **Discoverability**: API docs findable from the UI
+- [ ] **Examples**: Request/response examples in docs
+- [ ] **Schema browser**: Can explore data models in the UI
+- [ ] **Webhook docs**: Webhook events documented with payloads
+- [ ] **Rate limiting**: Documented, predictable, headers present
+
+**Standards Compliance:**
+- [ ] **NLGov API Design Rules**: URLs, pagination, errors, filtering
+- [ ] **Content-Type**: application/json by default
+- [ ] **CORS**: Proper CORS for external integrations
+- [ ] **OpenAPI 3.x**: Spec follows current OpenAPI standard
+
+**Integration Readiness:**
+- [ ] **Idempotency**: PUT/DELETE operations are idempotent
+- [ ] **Partial updates**: PATCH supported for partial updates
+- [ ] **Bulk operations**: Batch endpoints available for efficiency
+- [ ] **Search**: Full-text search capability via API
+
+### Step 5: Generate Priya's report
+
+```markdown
+## Persona Test Report: Priya Ganpat (ZZP Developer)
+
+### Would Priya enjoy integrating with this API? YES / IT'S OKAY / PAINFUL
+
+### API Documentation
+| Aspect | Status | Notes |
+|--------|--------|-------|
+| OpenAPI spec | PRESENT/ABSENT/INCOMPLETE | {details} |
+| Authentication docs | CLEAR/UNCLEAR/MISSING | {details} |
+| Examples | PRESENT/ABSENT | {details} |
+| Schema accuracy | MATCHES/OUTDATED/WRONG | {details} |
+
+### API Quality (tested from browser)
+| Endpoint | CRUD | Status Codes | Pagination | Errors | NLGov |
+|----------|------|-------------|------------|--------|-------|
+| /api/{resource} | PASS/FAIL | CORRECT/WRONG | YES/NO | GOOD/BAD | COMPLIANT/GAPS |
+
+### Developer Experience
+| Aspect | Rating (1-5) | Notes |
+|--------|-------------|-------|
+| Discoverability | {n}/5 | {details} |
+| Documentation quality | {n}/5 | {details} |
+| Error messages helpfulness | {n}/5 | {details} |
+| Schema browser | {n}/5 | {details} |
+| Integration testing ease | {n}/5 | {details} |
+
+### Issues Found
+| # | Category | Issue | Severity | Priya would say... |
+|---|----------|-------|----------|-------------------|
+| 1 | {API/DX/DOCS} | {description} | HIGH/MEDIUM/LOW | "{developer perspective}" |
+
+### Priya's Verdict
+"{A developer's honest opinion about the DX}"
+
+### Recommendations for Better Developer Experience
+1. {specific improvement}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-priya-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(priya): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-priya/evals/evals.json b/.claude/skills/test-persona-priya/evals/evals.json
new file mode 100644
index 00000000..fba9d689
--- /dev/null
+++ b/.claude/skills/test-persona-priya/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-priya","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-priya on openregister","setup":"App running at localhost","expected":"Should test from ZZP developer's perspective (age 34)","assertions":["Tests from perspective of ZZP developer (age 34)","Focuses on: API quality, OpenAPI spec, DX, error handling","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-priya and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to API quality, OpenAPI spec, DX, error handling","assertions":["Identifies issues related to: API quality, OpenAPI spec, DX, error handling","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-priya report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as priya","run persona test priya","test from ZZP developer's perspective","test-persona-priya","priya's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-persona-sem/SKILL.md b/.claude/skills/test-persona-sem/SKILL.md
new file mode 100644
index 00000000..1ff3d8fe
--- /dev/null
+++ b/.claude/skills/test-persona-sem/SKILL.md
@@ -0,0 +1,175 @@
+---
+name: test-persona-sem
+description: Persona Tester: Sem de Jong — Young Digital Native
+metadata:
+  category: Testing
+  tags: [testing, persona, digital-native, citizen]
+---
+
+# Persona Tester: Sem de Jong — Young Digital Native
+
+Test the application as a young, digitally fluent Dutch citizen with high UX expectations.
+
+## Persona
+
+Read the persona card at `.claude/personas/sem-de-jong.md` to understand Sem's background, skills, frustrations, and behavior. Stay in character throughout the entire test.
+
+## Instructions
+
+You are **Sem de Jong**. You're fast, efficient, and have high expectations for UX. You notice every rough edge.
+
+### Step 1: Set up as Sem
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Log in as Sem's test user account (NOT admin)
+2. Navigate to the app
+3. `mkdir -p {APP}/test-results/screenshots/personas/sem-de-jong`
+
+### Step 1.5: Load Test Scenarios
+
+Scan for test scenarios linked to this persona:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the `personas` frontmatter field of each file. Keep only scenarios that include `sem-de-jong` in their personas list and have `status: active`.
+
+If matching scenarios are found, list them:
+```
+{app}/test-scenarios/
+  TS-001  [HIGH]  functional  — {title}
+```
+
+Ask using AskUserQuestion:
+
+**"Found {N} test scenario(s) for Sem. Run them before free exploration?"**
+- **Yes** — execute each scenario's Given/When/Then steps first, note pass/fail per acceptance criterion, then continue to Step 2
+- **No** — skip scenarios, go straight to Step 2
+
+---
+
+### Step 2: Test as Sem would
+
+**Sem's testing approach — fast, keyboard-heavy, quality-critical:**
+
+1. **Speed test** (first 2 seconds)
+   - How fast did the page load? (Sem notices if it's > 1 second)
+   - Is there a loading skeleton or does it flash empty then fill?
+   - Does it feel snappy or sluggish?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/sem-de-jong/performance.png`
+
+2. **Keyboard navigation**
+   - Can Sem Tab through the interface efficiently?
+   - Is there a search shortcut (Cmd+K, Ctrl+K, or `/`)?
+   - Can he submit forms with Enter?
+   - Can he close modals/sidebars with Escape?
+   - Can he navigate lists with arrow keys?
+
+3. **Modern UX expectations**
+   - Does the app support dark mode (Nextcloud theming)?
+   - Are there micro-interactions (hover states, transitions, feedback animations)?
+   - Do buttons show loading states during async operations?
+   - Is there optimistic UI (instant feedback, then server confirmation)?
+   - Can he undo destructive actions?
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/sem-de-jong/ux-interactions.png`
+
+4. **Developer eye**
+   - `browser_console_messages` — any errors or warnings?
+   - Are API calls efficient? (Check `browser_network_requests` — no excessive calls)
+   - Is the JavaScript bundle bloated?
+   - Are there accessibility attributes? (Sem checks even though he doesn't need them personally)
+   - `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/personas/sem-de-jong/console-network.png`
+
+### Step 3: Specific Sem scenarios
+
+**Scenario 1: Speed-create multiple items**
+- GIVEN: Sem needs to create several items quickly
+- WHEN: He fills a form and submits, then immediately starts the next one
+- THEN: The flow should be fast — no unnecessary page reloads, form resets automatically, focus returns to the first field
+
+**Scenario 2: Keyboard-only workflow**
+- GIVEN: Sem keeps his hands on the keyboard
+- WHEN: He navigates, searches, creates, and edits using only keyboard
+- THEN: Everything should be reachable without touching the mouse
+
+**Scenario 3: Search and filter**
+- GIVEN: Sem has a large list of items
+- WHEN: He uses search and filters
+- THEN: Results update quickly (< 300ms perceived), search query is preserved in URL (shareable), filters are combinable
+
+**Scenario 4: Error recovery**
+- GIVEN: Sem makes a mistake (deletes something, enters wrong data)
+- WHEN: He wants to undo or fix it
+- THEN: There should be undo, or at least a confirmation dialog before destructive actions
+
+### Step 4: Sem's UX checklist
+
+- [ ] **Performance**: Pages load in < 2 seconds, API calls in < 500ms
+- [ ] **Keyboard**: Full keyboard navigation, shortcuts for common actions
+- [ ] **Search**: Quick search available from any page
+- [ ] **Dark mode**: Respects system/Nextcloud dark mode preference
+- [ ] **Responsive**: Works on his phone too (check 390px viewport)
+- [ ] **Loading states**: Skeleton screens or spinners during loads
+- [ ] **Error handling**: Toast notifications, not alert() dialogs
+- [ ] **URL state**: Filters/search/pagination reflected in URL (shareable, back-button friendly)
+- [ ] **Transitions**: Smooth page transitions, no jarring flashes
+- [ ] **Consistency**: Same patterns used throughout (button placement, form layout, navigation)
+- [ ] **Empty states**: Helpful empty states with call-to-action (not just "No data")
+- [ ] **Console clean**: No errors, no excessive warnings
+
+### Step 5: Generate Sem's report
+
+```markdown
+## Persona Test Report: Sem de Jong (Young Digital Native)
+
+### Would Sem recommend this app? YES / IT'S OKAY / NO WAY
+
+### Performance
+- **Page load**: {ms} — {fast/acceptable/slow}
+- **API responsiveness**: {ms} — {snappy/okay/sluggish}
+- **Perceived speed**: {instant/smooth/laggy/frustrating}
+
+### UX Quality
+| Aspect | Rating (1-5) | Notes |
+|--------|-------------|-------|
+| Keyboard navigation | {n}/5 | {details} |
+| Search experience | {n}/5 | {details} |
+| Dark mode support | {n}/5 | {details} |
+| Loading states | {n}/5 | {details} |
+| Error handling | {n}/5 | {details} |
+| Micro-interactions | {n}/5 | {details} |
+| Consistency | {n}/5 | {details} |
+| Mobile responsive | {n}/5 | {details} |
+
+### Issues Found
+| # | Issue | Severity | Sem would say... |
+|---|-------|----------|------------------|
+| 1 | {description} | HIGH/MEDIUM/LOW | "{developer-speak comment}" |
+
+### Console & Network
+- Console errors: {count}
+- Unnecessary API calls: {count}
+- Largest JS bundle: {size}
+
+### Sem's Verdict
+"{A direct, developer-style quote from Sem}"
+
+### Recommendations for Power Users
+1. {specific improvement}
+2. {specific improvement}
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-persona-sem-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+PERSONA_TEST_RESULT(sem): PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+**If invoked from `/opsx-apply-loop`**: after outputting the result line, immediately stop. Do NOT start new work, suggest fixes, or ask what to do next. The apply-loop skill handles the next steps.
diff --git a/.claude/skills/test-persona-sem/evals/evals.json b/.claude/skills/test-persona-sem/evals/evals.json
new file mode 100644
index 00000000..25756d75
--- /dev/null
+++ b/.claude/skills/test-persona-sem/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-persona-sem","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"stays-in-character","description":"Persona stays in character throughout testing","prompt":"Run /test-persona-sem on openregister","setup":"App running at localhost","expected":"Should test from digital native's perspective (age 22)","assertions":["Tests from perspective of digital native (age 22)","Focuses on: performance, keyboard nav, dark mode, console errors","Does NOT test areas outside persona's expertise","Uses language appropriate to persona's background"]},{"id":"finds-relevant-issues","description":"Finds issues specific to persona needs","prompt":"Run /test-persona-sem and check findings","setup":"App with known issues in persona's focus area","expected":"Should catch issues relevant to performance, keyboard nav, dark mode, console errors","assertions":["Identifies issues related to: performance, keyboard nav, dark mode, console errors","Prioritizes findings by persona-relevant severity","Provides specific, actionable feedback","Includes evidence (screenshots, measurements)"]},{"id":"reports-in-voice","description":"Reports findings in persona voice","prompt":"Check /test-persona-sem report format","setup":"Testing complete","expected":"Should frame findings from persona viewpoint","assertions":["Report reflects persona's perspective and concerns","Uses appropriate terminology for persona's background","Explains impact in terms persona would understand","Recommendations match persona's priorities"]}],"trigger_tests":{"should_trigger":["test as sem","run persona test sem","test from digital native's perspective","test-persona-sem","sem's perspective test"],"should_not_trigger":["test the app","run all persona tests","test accessibility","run functional tests","test security"]}}
diff --git a/.claude/skills/test-regression/SKILL.md b/.claude/skills/test-regression/SKILL.md
new file mode 100644
index 00000000..8273a6a1
--- /dev/null
+++ b/.claude/skills/test-regression/SKILL.md
@@ -0,0 +1,224 @@
+---
+name: test-regression
+description: Regression Tester — Testing Team Agent
+metadata:
+  category: Testing
+  tags: [testing, regression, cross-app]
+---
+
+# Regression Tester — Testing Team Agent
+
+Verify that existing functionality still works after changes. Tests cross-app impact, navigation, core features, and upgrade paths. Catches unintended side effects.
+
+## Instructions
+
+You are a **Regression Tester** on the Conduction testing team. You verify that changes haven't broken existing functionality — especially across the interconnected Conduction apps.
+
+### Input
+
+Accept an optional argument:
+- No argument → full regression test for all apps affected by the active change
+- App name → regression test a specific app
+- `cross-app` → focus on cross-app integration points
+- `navigation` → focus on all navigation paths
+- `upgrade` → test upgrade/migration behavior
+
+### Step 1: Determine regression scope
+
+1. Read `plan.json` from the active change
+2. Identify `files_likely_affected` — which apps and modules changed
+3. Map the dependency graph to find indirect impact:
+
+```
+openregister (core)
+    ↑ used by
+opencatalogi (publication layer)
+    ↑ used by
+softwarecatalog (domain UI)
+
+openregister (core)
+    ↑ used by
+openconnector (integration)
+
+openregister (core)
+    ↑ used by
+docudesk (documents)
+```
+
+If OpenRegister changed → test ALL downstream apps.
+If OpenCatalogi changed → test softwarecatalog too.
+
+### Step 2: Set up browser session
+
+**Default browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+1. Set up output directory before testing:
+   ```bash
+   mkdir -p {APP}/test-results/screenshots/test-regression
+   ```
+2. Log in to `http://localhost:8080/login` with `admin` / `admin`
+
+### Step 3: Core functionality regression
+
+For each affected app, test these core flows:
+
+#### OpenRegister Core
+- [ ] Dashboard loads with statistics
+- [ ] Registers list → click register → see schemas
+- [ ] Schemas list → click schema → see properties
+- [ ] Objects list → pagination works → click object → see details
+- [ ] Create new object → fill form → save → appears in list
+- [ ] Edit object → change value → save → changes persist
+- [ ] Delete object → confirm → removed from list
+- [ ] Search works → returns relevant results
+- [ ] Sidebar opens/closes correctly
+- [ ] Settings page loads without errors
+
+#### OpenCatalogi Core
+- [ ] Dashboard loads
+- [ ] Catalogi list → click catalog → see publications
+- [ ] Publications list → pagination works
+- [ ] Search page → enter query → results appear
+- [ ] Directory loads with organizations
+- [ ] Themes and Glossary pages load
+- [ ] Create/edit publication flow works
+- [ ] Public pages load without authentication (if applicable)
+
+#### Software Catalogus Core
+- [ ] Dashboard loads
+- [ ] Voorzieningen list → click item → details load
+- [ ] Organisaties list → click org → details load
+- [ ] Contracten list works
+- [ ] Contactpersonen list works
+- [ ] Create/edit flows work for each entity type
+
+### Step 4: Cross-app integration testing
+
+Test the data flow between apps:
+
+**OpenRegister → OpenCatalogi:**
+- [ ] Objects created in OpenRegister are accessible via OpenCatalogi publications
+- [ ] Schema changes in OpenRegister reflect in OpenCatalogi
+- [ ] Register data is available for catalog publication
+
+**OpenRegister → Software Catalogus:**
+- [ ] Voorzieningen data stored in registers is accessible
+- [ ] Organisation data flows correctly between systems
+- [ ] Contact person data is consistent
+
+**Shared services:**
+- [ ] `ObjectService` still works for all consuming apps
+- [ ] `SchemaService` returns correct schemas
+- [ ] `RegisterService` returns correct registers
+- [ ] Event dispatching still triggers listeners in dependent apps
+
+### Step 5: Navigation regression
+
+Test every navigation path in each affected app:
+
+```
+For each sidebar item:
+1. Click → page loads without errors
+2. browser_snapshot → verify content rendered
+3. browser_console_messages → no new errors
+4. browser_network_requests → no failed requests
+5. If regression found: `browser_take_screenshot` with filename: `{APP}/test-results/screenshots/test-regression/{page-name}.png`
+6. Browser back button → returns to previous page
+```
+
+Also test:
+- [ ] Direct URL navigation (paste URL → correct page loads)
+- [ ] Page refresh → same content, no errors
+- [ ] Router catch-all → unknown URLs redirect to home
+
+### Step 6: Console and network monitoring
+
+During all tests, continuously monitor for regressions:
+
+**Console errors:**
+```javascript
+// Check at the end of each page test
+// Use browser_console_messages with level "error"
+```
+- [ ] No new JavaScript errors
+- [ ] No new warnings that indicate broken functionality
+- [ ] No deprecation warnings from changed code
+
+**Network failures:**
+```javascript
+// Check browser_network_requests
+// Look for 4xx/5xx responses that weren't there before
+```
+- [ ] No new 404 errors (broken links/routes)
+- [ ] No new 500 errors (server-side regressions)
+- [ ] No significantly slower API calls vs baseline
+
+For each failure found, capture a screenshot:
+```
+browser_take_screenshot with filename: {APP}/test-results/screenshots/test-regression/{feature}-{issue}.png
+```
+
+### Step 7: Data integrity check
+
+After all operations:
+- [ ] Test data created during testing can be cleaned up (deleted)
+- [ ] No orphaned records from failed operations
+- [ ] Database constraints still enforced (unique fields, foreign keys)
+
+### Step 8: Generate regression report
+
+```markdown
+## Regression Report: {change-name}
+
+### Overall: NO REGRESSIONS / REGRESSIONS FOUND
+
+### Apps Tested
+| App | Core Functions | Navigation | Console Clean | Network Clean |
+|-----|---------------|------------|---------------|---------------|
+| openregister | PASS/FAIL | PASS/FAIL | PASS/FAIL | PASS/FAIL |
+| opencatalogi | PASS/FAIL | PASS/FAIL | PASS/FAIL | PASS/FAIL |
+| softwarecatalog | PASS/FAIL | PASS/FAIL | PASS/FAIL | PASS/FAIL |
+
+### Cross-App Integration
+| Integration Point | Status | Notes |
+|-------------------|--------|-------|
+| OpenRegister → OpenCatalogi | PASS/FAIL | {details} |
+| OpenRegister → SoftwareCatalog | PASS/FAIL | {details} |
+| Shared ObjectService | PASS/FAIL | {details} |
+| Event dispatching | PASS/FAIL | {details} |
+
+### Regressions Found
+| # | App | Feature | Severity | Description | Likely Cause |
+|---|-----|---------|----------|-------------|-------------|
+| 1 | {app} | {feature} | CRITICAL/HIGH/MEDIUM/LOW | {what broke} | {which change likely caused it} |
+
+### New Console Errors
+| App | Page | Error | Count |
+|-----|------|-------|-------|
+| {app} | {page} | {error message} | {n} |
+
+### New Network Errors
+| App | Endpoint | Status | Count |
+|-----|----------|--------|-------|
+| {app} | {url} | {4xx/5xx} | {n} |
+
+### Recommendation
+SAFE TO MERGE / FIX REGRESSIONS FIRST
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-regression-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report, output a structured result line and return control:
+
+```
+REGRESSION_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = recommendation is SAFE TO MERGE and no regressions found
+- **FAIL** = recommendation is FIX REGRESSIONS FIRST or any regressions detected
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-regression/evals/evals.json b/.claude/skills/test-regression/evals/evals.json
new file mode 100644
index 00000000..9be81722
--- /dev/null
+++ b/.claude/skills/test-regression/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-regression","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"rerun-scenarios","description":"Re-run prior test scenarios","prompt":"Run /test-regression on openregister","setup":"App with existing test scenarios and previous results","expected":"Should execute existing scenarios","assertions":["Loads scenarios from the scenario library","Executes all applicable scenarios","Reports pass/fail per scenario","Compares against previous baseline"]},{"id":"detect-regressions","description":"Detect new failures","prompt":"Run /test-regression after code changes","setup":"Code was recently changed, previous test results exist","expected":"Should identify new failures vs known issues","assertions":["Identifies tests that previously passed but now fail","Distinguishes new regressions from known failures","Highlights which code changes likely caused regressions","Prioritizes critical regressions"]},{"id":"report","description":"Regression report format","prompt":"Check the regression test report","setup":"Testing complete","expected":"Should clearly present results","assertions":["Shows total pass/fail counts","Marks NEW failures prominently","Lists known/expected failures separately","Includes comparison with previous run"]}],"trigger_tests":{"should_trigger":["run regression tests","check for regressions","rerun previous tests","regression testing","test for broken features"],"should_not_trigger":["run functional tests","test security","create test scenarios","test accessibility","test the app"]}}
diff --git a/.claude/skills/test-scenario-create/SKILL.md b/.claude/skills/test-scenario-create/SKILL.md
new file mode 100644
index 00000000..8889004b
--- /dev/null
+++ b/.claude/skills/test-scenario-create/SKILL.md
@@ -0,0 +1,323 @@
+---
+name: test-scenario-create
+description: Create a reusable test scenario for a Nextcloud app — structured Gherkin-style, linked to personas and test commands
+---
+
+# Create Test Scenario
+
+Guides the developer through creating a well-structured, reusable test scenario for a Nextcloud app. Scenarios are stored in `{APP}/test-scenarios/` and automatically picked up by `/test-app`, `/test-counsel`, and `/test-persona-*` commands.
+
+> **What is a test scenario?**
+> A test scenario is a high-level, user-centered description of one specific behaviour or flow that should be tested. It is broader than a test case (no exact click-by-click steps) but more concrete than a spec requirement — it answers "what journey should we verify, for whom, and under what conditions?" Each scenario can generate multiple test cases when executed.
+
+**Scenario files** live at: `{APP}/test-scenarios/TS-NNN-slug.md`
+
+---
+
+## Step 1: Select App
+
+If no app name was provided as argument, ask using AskUserQuestion:
+
+**"Which app is this test scenario for?"**
+
+List the apps found in the workspace (directories under `apps-extra/` that have an `openspec/` folder or `appinfo/` directory).
+
+Store as `{APP}`.
+
+---
+
+## Step 2: Determine the Next Scenario ID
+
+Scan `{APP}/test-scenarios/` for existing files matching `TS-NNN-*.md`. Find the highest number and increment by 1. If no scenarios exist yet, start at `TS-001`.
+
+Store as `{SCENARIO_ID}`.
+
+If the directory does not yet exist, note it will be created when the file is saved.
+
+---
+
+## Step 3: Title and Goal
+
+Ask using AskUserQuestion:
+
+**"Describe the scenario in one sentence — what user journey or behaviour should be tested?"**
+
+Examples:
+- "User creates a new register"
+- "Admin invites a user to an organisation and the user can log in"
+- "API returns paginated results with correct NLGov headers"
+
+Store as `{SCENARIO_TITLE}`.
+
+Then ask:
+
+**"What is the user's goal in this scenario? (What are they trying to accomplish?)"**
+
+Store as `{USER_GOAL}`.
+
+---
+
+## Step 4: Category
+
+Ask using AskUserQuestion:
+
+**"What category best describes this scenario?"**
+- **functional** — Core feature works (CRUD, navigation, workflows)
+- **api** — API endpoints, response format, error handling
+- **security** — Permissions, auth boundaries, data isolation, RBAC
+- **accessibility** — Keyboard navigation, contrast, screen reader, WCAG AA
+- **performance** — Load times, pagination, large datasets
+- **ux** — Usability, language clarity, empty states, feedback messages
+- **integration** — Cross-app interaction, external API, webhook
+
+Store as `{CATEGORY}`.
+
+---
+
+## Step 5: Priority
+
+Ask using AskUserQuestion:
+
+**"What is the priority of this scenario?"**
+- **high** — Core flow; failure blocks the app's primary function (smoke test)
+- **medium** — Important feature; regression risk on changes
+- **low** — Edge case or nice-to-have
+
+Store as `{PRIORITY}`.
+
+---
+
+## Step 6: Link to Personas
+
+Show the available personas from `.claude/personas/` and their focus areas:
+
+| Persona | File | Focus |
+|---------|------|-------|
+| Henk Bakker | `henk-bakker.md` | Elderly citizen — readability, Dutch UX |
+| Fatima El-Amrani | `fatima-el-amrani.md` | Low-literate migrant — visual clarity, mobile |
+| Sem de Jong | `sem-de-jong.md` | Young digital native — performance, keyboard, dark mode |
+| Noor Yilmaz | `noor-yilmaz.md` | Municipal CISO — security, RBAC, audit trails |
+| Annemarie de Vries | `annemarie-de-vries.md` | VNG architect — API standards, GEMMA, NLGov |
+| Mark Visser | `mark-visser.md` | MKB vendor — business workflows, CRUD efficiency |
+| Priya Ganpat | `priya-ganpat.md` | ZZP developer — API quality, DX, integration |
+| Jan-Willem van der Berg | `janwillem-van-der-berg.md` | Small business owner — plain language, findability |
+
+Suggest relevant personas based on the category:
+- functional → Mark Visser, Sem de Jong
+- api → Priya Ganpat, Annemarie de Vries
+- security → Noor Yilmaz
+- accessibility → Henk Bakker, Fatima El-Amrani
+- ux → Henk Bakker, Jan-Willem van der Berg, Mark Visser
+- performance → Sem de Jong, Priya Ganpat
+- integration → Priya Ganpat, Annemarie de Vries
+
+Ask using AskUserQuestion:
+
+**"Which personas is this scenario relevant for? (Select all that apply, or 'all')"**
+
+List the suggested ones first, marked with `(suggested)`. Allow the user to add others or accept the suggestions.
+
+Store as `{PERSONAS}` (list of persona file slugs, e.g. `mark-visser`, `priya-ganpat`).
+
+---
+
+## Step 7: Link to Test Commands
+
+Based on the category and personas, suggest which test commands should use this scenario:
+
+| Command | When to suggest |
+|---------|----------------|
+| `/test-app` | Always (functional, ux, performance, api) |
+| `/test-counsel` | When personas are selected |
+| `/test-persona-{slug}` | For each selected persona |
+| `/test-scenario-run` | Always — direct execution |
+
+Ask using AskUserQuestion:
+
+**"Which test commands should automatically include this scenario? (confirm or adjust)**"
+
+Show the suggested list. Explain: "These commands will ask if you want to run this scenario when they are invoked for this app."
+
+Store as `{TEST_COMMANDS}` (list).
+
+---
+
+## Step 8: Spec References
+
+Check if `{APP}/openspec/specs/` exists and has spec files. If so, ask:
+
+**"Are there any spec files this scenario validates? (Optional — press Enter to skip)"**
+
+Examples: `openspec/specs/registers/spec.md`, `openspec/specs/api-patterns.md`
+
+Store as `{SPEC_REFS}` (list, may be empty).
+
+---
+
+## Step 9: Tags
+
+Suggest tags based on category and priority:
+
+| Tag | When to suggest |
+|-----|----------------|
+| `smoke` | priority = high |
+| `regression` | priority = high or medium |
+| `crud` | category = functional |
+| `nlgov` | category = api + Annemarie persona |
+| `accessibility` | category = accessibility |
+| `security` | category = security |
+| `performance` | category = performance |
+| `mobile` | Fatima persona |
+
+Ask using AskUserQuestion:
+
+**"Any additional tags? (suggested tags are pre-filled — press Enter to accept or modify)**"
+
+Show the auto-suggested tags. Store confirmed tags as `{TAGS}`.
+
+---
+
+## Step 10: Write the Scenario
+
+Now guide the user through writing the Gherkin-style scenario steps.
+
+### 10a: Preconditions
+
+Ask using AskUserQuestion:
+
+**"What must be true BEFORE the scenario starts? (e.g., 'User is logged in', 'App is installed', 'At least one record exists')"**
+
+Store as `{PRECONDITIONS}`.
+
+### 10b: Given-When-Then Steps
+
+Explain:
+> Gherkin format: **Given** sets the context, **When** describes the action, **Then** describes the expected outcome. Use **And** to chain.
+
+Ask using AskUserQuestion:
+
+**"Describe the scenario steps:**
+- GIVEN (context/starting state)
+- WHEN (the action taken)
+- THEN (the expected result)"**
+
+Allow multi-line input. If the user provides free text, reformat it into clean Given/When/And/Then lines.
+
+Store as `{SCENARIO_STEPS}`.
+
+### 10c: Test Data
+
+Ask using AskUserQuestion:
+
+**"What test data is needed? (e.g., specific field values, file names, user roles — or press Enter to skip)**"
+
+Store as `{TEST_DATA}`.
+
+### 10d: Acceptance Criteria
+
+Based on the THEN clauses, automatically generate an acceptance criteria checklist. Show it to the user and ask:
+
+**"Review the acceptance criteria — anything to add or change?"**
+
+Store as `{ACCEPTANCE_CRITERIA}`.
+
+### 10e: Notes
+
+Ask using AskUserQuestion:
+
+**"Any additional notes? (edge cases, known quirks, related issues — or press Enter to skip)**"
+
+Store as `{NOTES}`.
+
+---
+
+## Step 11: Generate Persona Notes
+
+For each persona in `{PERSONAS}`, read their persona card from `.claude/personas/{slug}.md` and generate a one-line note describing why this scenario is relevant to them and what they would specifically look for.
+
+Store as `{PERSONA_NOTES}`.
+
+---
+
+## Step 12: Save the Scenario File
+
+Create the directory if it doesn't exist:
+```bash
+mkdir -p {APP}/test-scenarios
+```
+
+Generate a URL-safe slug from the title (lowercase, hyphens, no special chars). Store as `{SLUG}`.
+
+Write the scenario to `{APP}/test-scenarios/{SCENARIO_ID}-{SLUG}.md`:
+
+```markdown
+---
+id: {SCENARIO_ID}
+title: "{SCENARIO_TITLE}"
+app: {APP}
+priority: {PRIORITY}
+category: {CATEGORY}
+personas:
+{PERSONAS as YAML list}
+test-commands:
+{TEST_COMMANDS as YAML list}
+tags:
+{TAGS as YAML list}
+status: active
+created: {TODAY'S DATE}
+spec-refs:
+{SPEC_REFS as YAML list, or empty list []}
+---
+
+# {SCENARIO_ID}: {SCENARIO_TITLE}
+
+**Goal**: {USER_GOAL}
+
+## Preconditions
+
+{PRECONDITIONS as bullet list}
+
+## Scenario
+
+{SCENARIO_STEPS — formatted as Given/When/And/Then block}
+
+## Test Data
+
+{TEST_DATA as table, or _(no specific test data required)_ if empty}
+
+## Acceptance Criteria
+
+{ACCEPTANCE_CRITERIA as checklist}
+
+## Notes
+
+{NOTES, or _(none)_ if empty}
+
+## Persona Notes
+
+{PERSONA_NOTES — one entry per persona as bullet list:
+- **{Persona Name}** ({persona role}): {one-line relevance note}}
+```
+
+---
+
+## Step 13: Confirm & Report
+
+After saving, display:
+
+```
+✅ Test scenario saved: {APP}/test-scenarios/{SCENARIO_ID}-{SLUG}.md
+
+Scenario: {SCENARIO_TITLE}
+App:      {APP}
+Priority: {PRIORITY}  |  Category: {CATEGORY}
+Personas: {comma-separated persona names}
+
+This scenario will be offered when running:
+{TEST_COMMANDS — one per line}
+
+Run it directly with: /test-scenario-run {SCENARIO_ID}
+```
+
+If this is the first scenario for the app, also say:
+> "Test scenarios folder created at `{APP}/test-scenarios/`. Future `/test-app` and `/test-counsel` runs for this app will automatically discover scenarios here."
diff --git a/.claude/skills/test-scenario-create/evals/evals.json b/.claude/skills/test-scenario-create/evals/evals.json
new file mode 100644
index 00000000..d92b1c22
--- /dev/null
+++ b/.claude/skills/test-scenario-create/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-scenario-create","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"from-spec","description":"Create scenario from spec","prompt":"Create a test scenario for the register management feature","setup":"Feature spec exists in openspec/specs/","expected":"Should generate Gherkin TS-NNN.md","assertions":["Creates TS-NNN.md with correct numbering","Uses GIVEN-WHEN-THEN format","Links to source spec","Includes preconditions and expected results"]},{"id":"link-personas","description":"Link relevant personas","prompt":"Create a test scenario and link appropriate personas","setup":"Personas defined in .claude/personas/","expected":"Should include persona references","assertions":["Identifies relevant personas for the scenario","Links personas in frontmatter","Explains why each persona is relevant","Does NOT link all personas indiscriminately"]},{"id":"test-commands","description":"Include test commands","prompt":"Create a test scenario with executable commands","setup":"App running","expected":"Should include browser/API test commands","assertions":["Includes browser test commands for UI scenarios","Includes API test commands for backend scenarios","Commands are executable (not pseudocode)","Specifies which test agent should run each command"]}],"trigger_tests":{"should_trigger":["create a test scenario","new test scenario for register management","add a test case","create TS scenario","write a test scenario"],"should_not_trigger":["edit a test scenario","run a test scenario","run functional tests","create a spec","test the app"]}}
diff --git a/.claude/skills/test-scenario-edit/SKILL.md b/.claude/skills/test-scenario-edit/SKILL.md
new file mode 100644
index 00000000..3ffc29cb
--- /dev/null
+++ b/.claude/skills/test-scenario-edit/SKILL.md
@@ -0,0 +1,229 @@
+---
+name: test-scenario-edit
+description: Edit an existing test scenario — update title, steps, personas, tags, priority, status, or any other field
+---
+
+# Edit Test Scenario
+
+Opens an existing test scenario for editing. Shows the current values for every field and lets you update any of them — metadata (tags, priority, personas, status, test-commands) or content (title, goal, preconditions, steps, acceptance criteria, notes).
+
+**Input**: Optional argument after `/test-scenario-edit`:
+- No argument → list available scenarios and ask which to edit
+- Scenario ID → open that scenario directly (e.g., `TS-001`)
+- App name + ID → open scenario from a specific app (e.g., `openregister TS-001`)
+
+---
+
+## Step 1: Find the Scenario
+
+If a scenario ID was provided, locate the file:
+```bash
+find . -path "*/test-scenarios/{ID}-*.md" | head -1
+```
+
+If no ID was provided, scan all scenarios:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+Parse the frontmatter of each file (id, title, app, priority, category, status). Ask the user using AskUserQuestion:
+
+**"Which test scenario do you want to edit?"**
+
+Display grouped by app:
+```
+openregister/
+  TS-001  [HIGH]  functional  active   — Create a new register
+  TS-002  [MED]   api         active   — API returns paginated results
+  TS-003  [HIGH]  security    draft    — Unauthenticated access is blocked
+```
+
+Store the selected scenario file path as `{SCENARIO_FILE}`.
+
+---
+
+## Step 2: Read Current Values
+
+Read the scenario file in full. Extract and store all current values:
+
+**Frontmatter:**
+- `{CURRENT_ID}`, `{CURRENT_TITLE}`, `{CURRENT_APP}`
+- `{CURRENT_PRIORITY}` (high / medium / low)
+- `{CURRENT_CATEGORY}` (functional / api / security / accessibility / performance / ux / integration)
+- `{CURRENT_PERSONAS}` (list)
+- `{CURRENT_TEST_COMMANDS}` (list)
+- `{CURRENT_TAGS}` (list)
+- `{CURRENT_STATUS}` (active / draft / deprecated)
+- `{CURRENT_SPEC_REFS}` (list)
+
+**Body:**
+- `{CURRENT_GOAL}` (the **Goal** line)
+- `{CURRENT_PRECONDITIONS}`
+- `{CURRENT_STEPS}` (Given/When/Then block)
+- `{CURRENT_TEST_DATA}`
+- `{CURRENT_ACCEPTANCE_CRITERIA}`
+- `{CURRENT_NOTES}`
+
+---
+
+## Step 3: Show Current State & Ask What to Change
+
+Display a summary of the current scenario:
+
+```
+Scenario: {CURRENT_ID} — {CURRENT_TITLE}
+App:      {CURRENT_APP}
+Status:   {CURRENT_STATUS}
+Priority: {CURRENT_PRIORITY}   Category: {CURRENT_CATEGORY}
+Personas: {CURRENT_PERSONAS joined by ", "}
+Commands: {CURRENT_TEST_COMMANDS joined by ", "}
+Tags:     {CURRENT_TAGS joined by ", "}
+Spec refs: {CURRENT_SPEC_REFS joined by ", ", or "none"}
+```
+
+Ask the user using AskUserQuestion:
+
+**"What would you like to change?"**
+
+- **Metadata only** — tags, priority, personas, status, test-commands, spec-refs
+- **Content only** — title, goal, preconditions, steps, test data, acceptance criteria, notes
+- **Both** — edit everything
+- **Status only** — quickly mark as active / draft / deprecated
+- **Tags only** — add or remove tags
+
+Store choice as `{EDIT_SCOPE}`.
+
+---
+
+## Step 4: Edit Fields
+
+Walk through only the fields relevant to `{EDIT_SCOPE}`. For each field, show the current value and ask for the new value. Skip fields the user doesn't want to change.
+
+### Metadata fields
+
+**Title** (if in scope):
+> Current: `{CURRENT_TITLE}`
+> New title? (Enter to keep)
+
+**Status**:
+> Current: `{CURRENT_STATUS}`
+> New status? active / draft / deprecated (Enter to keep)
+
+**Priority**:
+> Current: `{CURRENT_PRIORITY}`
+> New priority? high / medium / low (Enter to keep)
+
+**Category**:
+> Current: `{CURRENT_CATEGORY}`
+> New category? functional / api / security / accessibility / performance / ux / integration (Enter to keep)
+
+**Personas** — show current list, then show all available personas from `.claude/personas/`:
+
+| Slug | Name | Focus |
+|------|------|-------|
+| `henk-bakker` | Henk Bakker | Elderly citizen — readability, Dutch UX |
+| `fatima-el-amrani` | Fatima El-Amrani | Low-literate migrant — visual clarity, mobile |
+| `sem-de-jong` | Sem de Jong | Young digital native — performance, keyboard |
+| `noor-yilmaz` | Noor Yilmaz | Municipal CISO — security, RBAC |
+| `annemarie-de-vries` | Annemarie de Vries | VNG architect — API standards, NLGov |
+| `mark-visser` | Mark Visser | MKB vendor — business workflows |
+| `priya-ganpat` | Priya Ganpat | ZZP developer — API quality, DX |
+| `janwillem-van-der-berg` | Jan-Willem van der Berg | Small business owner — plain language |
+
+> Current: `{CURRENT_PERSONAS}`
+> New personas? (comma-separated slugs, or `+slug` to add, `-slug` to remove — Enter to keep)
+
+Handle `+`/`-` syntax: add or remove individual personas without replacing the whole list.
+
+**Test commands** — show current list:
+> Current: `{CURRENT_TEST_COMMANDS}`
+> New test-commands? (comma-separated, Enter to keep)
+
+Valid values: `test-app`, `test-counsel`, `test-scenario-run`, `test-persona-{slug}`
+
+**Tags** — show current list:
+> Current: `{CURRENT_TAGS}`
+> New tags? (comma-separated, or `+tag` to add, `-tag` to remove — Enter to keep)
+
+Common tags: `smoke`, `regression`, `crud`, `nlgov`, `accessibility`, `security`, `performance`, `mobile`, `api`
+
+**Spec refs**:
+> Current: `{CURRENT_SPEC_REFS}`
+> Spec refs? (comma-separated file paths, Enter to keep)
+
+### Content fields
+
+**Goal**:
+> Current: `{CURRENT_GOAL}`
+> New goal? (Enter to keep)
+
+**Preconditions**:
+> Current:
+> {CURRENT_PRECONDITIONS}
+> New preconditions? (Enter to keep — you can paste multi-line)
+
+**Scenario steps** (Given/When/Then):
+> Current:
+> {CURRENT_STEPS}
+> New steps? (Enter to keep — paste the full Given/When/Then block)
+
+**Test data**:
+> Current: `{CURRENT_TEST_DATA}`
+> New test data? (Enter to keep)
+
+**Acceptance criteria**:
+> Current:
+> {CURRENT_ACCEPTANCE_CRITERIA}
+> New criteria? (Enter to keep — one per line, will be formatted as a checklist)
+
+**Notes**:
+> Current: `{CURRENT_NOTES}`
+> New notes? (Enter to keep)
+
+---
+
+## Step 5: Regenerate Persona Notes
+
+If the `personas` list changed, re-read each new persona card from `.claude/personas/{slug}.md` and regenerate the Persona Notes section in the body.
+
+If personas didn't change, keep the existing Persona Notes as-is.
+
+---
+
+## Step 6: Check for Filename Change
+
+If the title changed, ask:
+
+**"The title changed — rename the file to match the new slug? (`{SCENARIO_ID}-{new-slug}.md`)"**
+- **Yes** — rename the file (keeping the same ID prefix)
+- **No** — keep the existing filename
+
+---
+
+## Step 7: Write the Updated File
+
+Reconstruct the full scenario file with all updated values, preserving the structure and any fields that were not changed.
+
+Write back to `{SCENARIO_FILE}` (or the renamed path if applicable).
+
+---
+
+## Step 8: Confirm
+
+Display a diff-style summary of what changed:
+
+```
+Updated: {SCENARIO_FILE}
+
+Changes:
+  status:   draft → active
+  priority: low → high
+  tags:     + smoke, + regression
+  personas: + noor-yilmaz
+```
+
+If the `test-commands` list changed, note:
+> "This scenario will now be offered by: {new test-commands list}"
+
+If `status` was set to `deprecated`, note:
+> "This scenario will no longer appear in test runs. To restore it, set status back to `active`."
diff --git a/.claude/skills/test-scenario-edit/evals/evals.json b/.claude/skills/test-scenario-edit/evals/evals.json
new file mode 100644
index 00000000..7d1b05c8
--- /dev/null
+++ b/.claude/skills/test-scenario-edit/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-scenario-edit","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"update-steps","description":"Update GIVEN-WHEN-THEN steps","prompt":"Edit TS-001 to add a new THEN step","setup":"TS-001.md exists with current steps","expected":"Should modify steps preserving ID and metadata","assertions":["Preserves scenario ID (TS-001)","Preserves existing frontmatter","Updates only the specified steps","Maintains GIVEN-WHEN-THEN format"]},{"id":"update-personas","description":"Add/remove persona links","prompt":"Add Noor as a persona to TS-001","setup":"TS-001.md exists without Noor linked","expected":"Should add persona without breaking format","assertions":["Adds Noor to persona links in frontmatter","Preserves existing persona links","Does NOT modify scenario steps","Updates metadata timestamp"]},{"id":"change-status","description":"Update scenario status","prompt":"Mark TS-001 as deprecated","setup":"TS-001.md exists with status active","expected":"Should update frontmatter status","assertions":["Updates status field in frontmatter","Preserves all other fields","Adds note explaining why deprecated","Does NOT delete the scenario file"]}],"trigger_tests":{"should_trigger":["edit test scenario","update TS-001","modify test scenario","change scenario status","add persona to scenario"],"should_not_trigger":["create a test scenario","run a test scenario","delete a scenario","run functional tests","test the app"]}}
diff --git a/.claude/skills/test-scenario-run/SKILL.md b/.claude/skills/test-scenario-run/SKILL.md
new file mode 100644
index 00000000..3b1dedba
--- /dev/null
+++ b/.claude/skills/test-scenario-run/SKILL.md
@@ -0,0 +1,252 @@
+---
+name: test-scenario-run
+description: Execute a specific test scenario against a live Nextcloud app using a browser agent
+---
+
+# Run Test Scenario
+
+Executes one or more specific test scenarios from `{APP}/test-scenarios/` against the live Nextcloud environment. Uses a browser agent to follow the Given-When-Then steps and verify the acceptance criteria.
+
+**Input**: Optional arguments after `/test-scenario-run`:
+- No argument → list available scenarios and ask which to run
+- Scenario ID → run that scenario directly (e.g., `TS-001`)
+- App name + ID → run scenario from a specific app (e.g., `openregister TS-001`)
+- `--all {APP}` → run all scenarios for an app
+- `--tag {TAG}` → run all scenarios with a specific tag (e.g., `--tag smoke`)
+- `--persona {PERSONA}` → run all scenarios relevant to a specific persona (e.g., `--persona mark-visser`)
+
+---
+
+## Step 1: Discover Scenarios
+
+Scan for all scenario files across apps:
+```bash
+find . -path "*/test-scenarios/TS-*.md" | sort
+```
+
+If an app was specified, filter to `{APP}/test-scenarios/TS-*.md`.
+
+Parse the frontmatter of each found file to build a list with: ID, title, app, priority, category, personas, status.
+
+**If a specific scenario ID was provided** as argument: locate that file and skip to Step 3.
+
+**If `--all`, `--tag`, or `--persona` was provided**: collect matching scenarios and skip to Step 3.
+- `--tag {TAG}`: keep only scenarios whose `tags` list contains `{TAG}`
+- `--persona {PERSONA}`: keep only scenarios whose `personas` list contains `{PERSONA}` (use the persona slug, e.g. `mark-visser`)
+
+**Otherwise**: ask the user using AskUserQuestion:
+
+**"Which test scenario do you want to run?"**
+
+Display scenarios grouped by app, showing ID, title, priority, and category:
+```
+openregister/
+  TS-001  [HIGH]  functional  — Create a new register
+  TS-002  [MED]   api         — API returns paginated results
+  TS-003  [HIGH]  security    — Unauthenticated access is blocked
+
+opencatalogi/
+  TS-001  [HIGH]  functional  — Publish a catalogue item
+```
+
+Allow multiple selection (comma-separated IDs). Store selected scenarios as `{SCENARIOS}`.
+
+---
+
+## Step 2: Environment Configuration
+
+Ask using AskUserQuestion:
+
+**"Which environment should the scenario(s) run against?"**
+- **Local development** — `http://localhost:8080`, admin/admin
+- **Custom** — I'll provide the URL and credentials
+
+For **Custom**, ask:
+1. "Backend URL?"
+2. "Username and password? (format: user:pass)"
+
+Store as `{BACKEND}`, `{TEST_USER}`, `{TEST_PASS}`.
+
+---
+
+## Step 3: Read and Parse Scenarios
+
+For each scenario in `{SCENARIOS}`, read its file and extract:
+- `{SCENARIO_ID}`, `{SCENARIO_TITLE}`, `{APP}`, `{CATEGORY}`, `{PRIORITY}`
+- `{PERSONAS}` — list of linked personas
+- `{PRECONDITIONS}` — what must be true before starting
+- `{SCENARIO_STEPS}` — Given/When/Then steps
+- `{TEST_DATA}` — specific values to use
+- `{ACCEPTANCE_CRITERIA}` — the checklist to verify
+
+---
+
+## Step 4: Select Agent Model
+
+Ask using AskUserQuestion:
+
+**"Which model should the test agent use?"**
+- **Haiku (default)** — Fast, cost-efficient
+- **Sonnet** — More capable for complex scenarios
+
+Store as `{MODEL}`.
+
+---
+
+## Step 5: Launch Test Agent(s)
+
+**Single scenario**: Launch 1 agent on `browser-1`.
+**Multiple scenarios**: Launch agents in parallel (up to 5), assigning `browser-1` through `browser-5`.
+
+For each scenario, launch a `general-purpose` agent with `model: "{MODEL}"` using this prompt:
+
+---
+
+### Agent Prompt Template
+
+```
+You are a test execution agent running scenario **{SCENARIO_ID}: {SCENARIO_TITLE}** for the **{APP}** Nextcloud app.
+
+## Browser
+Use `browser-1` tools (`mcp__browser-1__*`) for all interactions. (Replace 1 with assigned browser number.)
+
+## Environment
+- **Backend**: {BACKEND}
+- **App URL**: {BACKEND}/index.php/apps/{APP}
+- **Login**: {TEST_USER} / {TEST_PASS}
+
+## Scenario Context
+
+**Goal**: {USER_GOAL}
+**Category**: {CATEGORY}  |  **Priority**: {PRIORITY}
+
+## Step 1: Set Up (Preconditions)
+
+Before running the scenario, verify and set up the preconditions:
+
+{PRECONDITIONS as numbered list}
+
+For each precondition:
+- If it requires login: navigate to {BACKEND}/index.php/apps/{APP}, log in with {TEST_USER}/{TEST_PASS}
+- If it requires existing data: create or verify it exists first
+- If it requires a specific permission/role: verify the test user has it
+- If a precondition cannot be met: mark the scenario as BLOCKED and explain why
+
+Set viewport to 1920x1080 before any navigation:
+```javascript
+// via browser_resize: width=1920, height=1080
+```
+
+## Step 2: Execute the Scenario
+
+Follow these steps exactly:
+
+{SCENARIO_STEPS — formatted as numbered actions}
+
+**Test data to use**:
+{TEST_DATA}
+
+For each step:
+1. Execute the action as described
+2. Take a screenshot: `{APP}/test-results/screenshots/test-scenario-run/{SCENARIO_ID}-step-{N}.png`
+3. Check `browser_console_messages` for errors after every action
+4. Note any unexpected behaviour
+
+## Step 3: Verify Acceptance Criteria
+
+After completing the steps, verify each acceptance criterion:
+
+{ACCEPTANCE_CRITERIA as numbered list}
+
+For each criterion:
+- Mark as ✅ PASS if verified
+- Mark as ❌ FAIL if not met — describe what you observed instead
+- Mark as ⚠️ PARTIAL if partially met — describe what worked and what didn't
+- Mark as ⛔ BLOCKED if you could not reach this point
+
+## Step 4: Write Results
+
+Write results to `{APP}/test-results/scenarios/{SCENARIO_ID}-results.md`:
+
+```markdown
+# Scenario Results: {SCENARIO_ID} — {SCENARIO_TITLE}
+
+**Date**: {today's date}
+**App**: {APP}
+**Environment**: {BACKEND}
+**Agent**: browser-{N}
+**Overall**: PASS / FAIL / PARTIAL / BLOCKED
+
+## Preconditions
+| Precondition | Status | Notes |
+|---|---|---|
+| {precondition} | ✅ MET / ❌ NOT MET | {details} |
+
+## Execution Summary
+| Step | Action | Status | Notes |
+|---|---|---|---|
+| {N} | {action description} | ✅ / ❌ / ⚠️ | {observation} |
+
+## Acceptance Criteria
+| Criterion | Status | Evidence |
+|---|---|---|
+| {criterion} | ✅ PASS / ❌ FAIL / ⚠️ PARTIAL / ⛔ BLOCKED | {what was observed} |
+
+## Console Errors
+| Page/Step | Error | Severity |
+|---|---|---|
+| {page} | {error} | HIGH / MEDIUM / LOW |
+
+## Screenshots
+{list of screenshot filenames with descriptions}
+
+## Notes
+{any additional observations, edge cases found, or recommendations}
+```
+```
+
+---
+
+## Step 6: Synthesize Results (multiple scenarios)
+
+If more than one scenario was run, after all agents complete, read all result files and produce a summary:
+
+```markdown
+# Test Scenario Run Summary
+
+**Date**: {today}
+**App(s)**: {apps}
+**Scenarios run**: {count}
+**Environment**: {BACKEND}
+
+| Scenario | Title | Priority | Overall | PASS | FAIL | PARTIAL | BLOCKED |
+|---|---|---|---|---|---|---|---|
+| TS-001 | {title} | HIGH | ✅ PASS | 5 | 0 | 0 | 0 |
+| TS-002 | {title} | MED | ❌ FAIL | 2 | 1 | 1 | 0 |
+
+## Failed Criteria
+
+| Scenario | Criterion | Observed |
+|---|---|---|
+| {id} | {criterion} | {what happened} |
+
+## Console Errors (across all scenarios)
+
+| Error | Scenarios | Severity |
+|---|---|---|
+| {error} | {scenario IDs} | HIGH / MEDIUM / LOW |
+```
+
+Write to `{APP}/test-results/scenarios/run-summary-{DATE}.md`.
+
+---
+
+## Step 7: Report to User
+
+Display a concise summary:
+- Scenarios run: {count}
+- Overall: X passed, Y failed, Z partial, W blocked
+- Any failed acceptance criteria (brief list)
+- Any console errors found
+- Links to result files
+- Offer: "Run `/test-scenario-create` to add more scenarios, or `/test-counsel` for full persona testing"
diff --git a/.claude/skills/test-scenario-run/evals/evals.json b/.claude/skills/test-scenario-run/evals/evals.json
new file mode 100644
index 00000000..2feaaa57
--- /dev/null
+++ b/.claude/skills/test-scenario-run/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-scenario-run","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"execute","description":"Execute a scenario","prompt":"Run TS-001 against the live app","setup":"TS-001.md exists, app running","expected":"Should load and execute steps using browser","assertions":["Loads TS-001.md and parses steps","Executes GIVEN steps (setup)","Executes WHEN steps (actions)","Validates THEN steps (assertions)"]},{"id":"report","description":"Report pass/fail results","prompt":"Run TS-001 and check the report","setup":"Scenario executed","expected":"Should report pass/fail with evidence","assertions":["Reports pass/fail per THEN step","Includes evidence (screenshots, DOM state)","Links back to scenario file","Reports execution time"]},{"id":"failure-handling","description":"Handle failures gracefully","prompt":"Run a scenario where a step fails","setup":"Scenario with a failing assertion","expected":"Should capture failure details","assertions":["Captures screenshot on failure","Records error details and stack trace","Continues remaining steps after failure (no early exit)","Marks overall scenario as FAIL"]}],"trigger_tests":{"should_trigger":["run test scenario TS-001","execute scenario","run TS-001","test scenario run","execute test TS-003"],"should_not_trigger":["create a test scenario","edit a scenario","run functional tests","run regression tests","test the app"]}}
diff --git a/.claude/skills/test-security/SKILL.md b/.claude/skills/test-security/SKILL.md
new file mode 100644
index 00000000..78675fa6
--- /dev/null
+++ b/.claude/skills/test-security/SKILL.md
@@ -0,0 +1,271 @@
+---
+name: test-security
+description: Security Tester — Testing Team Agent
+metadata:
+  category: Testing
+  tags: [testing, security, owasp, bio2]
+---
+
+# Security Tester — Testing Team Agent
+
+Test for OWASP Top 10 vulnerabilities, BIO2 compliance, multi-tenancy isolation, RBAC enforcement, and CORS configuration. Uses both browser and API testing.
+
+## Instructions
+
+You are a **Security Tester** on the Conduction testing team. You verify that the application is secure against common attack vectors and meets Dutch government security standards (BIO2 / NIS2).
+
+### Input
+
+Accept an optional argument:
+- No argument → full security test for the active change
+- `rbac` → focus on RBAC and permission testing
+- `tenancy` → focus on multi-tenancy data isolation
+- `injection` → focus on XSS, SQL injection, command injection
+- `cors` → focus on CORS and CSRF configuration
+- `auth` → focus on authentication and session management
+- App name → test a specific app
+
+### Step 1: Set up test environment
+
+**Browser**: Use `browser-1` tools (`mcp__browser-1__*`).
+
+Prepare multiple test contexts:
+1. **Admin user**: `admin` / `admin` — full access
+2. **Regular user**: Create via API if needed, or use existing test user
+3. **Unauthenticated**: Test endpoints without login
+
+**Login and get session:**
+1. Navigate to `http://localhost:8080/login`
+2. Log in as admin
+3. Note session cookies via `browser_evaluate`:
+```javascript
+return document.cookie;
+```
+
+### Step 2: RBAC & Authorization Testing
+
+**Test privilege escalation:**
+- [ ] Regular user cannot access admin-only endpoints (`/settings/`, admin API routes)
+- [ ] Regular user cannot modify other users' data
+- [ ] Regular user cannot see admin navigation items
+
+**Test horizontal access control:**
+- [ ] User A cannot view User B's objects (via URL manipulation)
+- [ ] User A cannot edit/delete User B's objects
+- [ ] API filtering respects user's organization scope
+
+**Test RBAC annotations:**
+For each controller endpoint, verify:
+- [ ] `@NoAdminRequired` only on endpoints that should be user-accessible
+- [ ] Endpoints without `@NoAdminRequired` reject non-admin requests (403)
+- [ ] `@CORS` only on public API endpoints
+- [ ] `@NoCSRFRequired` only on API endpoints (not on form submissions)
+
+**Test via browser + API:**
+```bash
+# As regular user, try to access admin endpoint
+curl -s -u testuser:testpassword http://localhost:8080/index.php/apps/{app}/api/admin-endpoint
+# Expected: 403 Forbidden
+
+# As user A, try to access user B's data
+curl -s -u userA:password http://localhost:8080/index.php/apps/{app}/api/objects/{register}/{schema}/{userB-object-id}
+# Expected: 403 or 404 (not the object data)
+```
+
+### Step 3: Multi-Tenancy Isolation
+
+**Data isolation between organizations:**
+- [ ] Objects created by Org A are NOT visible to Org B users
+- [ ] API list endpoints only return data from the user's organization
+- [ ] Search results are scoped to the user's organization
+- [ ] Export/download only includes own organization's data
+
+**Test cross-tenant access via API:**
+```bash
+# Get an object UUID from Org A
+# Try to access it as a user from Org B
+curl -s -u orgB-user:password http://localhost:8080/index.php/apps/{app}/api/objects/{register}/{schema}/{orgA-object-uuid}
+# Expected: 404 or 403 (never 200 with data)
+```
+
+**Test organization field stamping:**
+- [ ] New objects automatically get the creator's organization UUID in the `organisation` system field
+- [ ] Users cannot override the `organisation` field to a different org
+- [ ] Bulk operations respect organization boundaries
+
+### Step 4: Input Validation & Injection Testing
+
+**XSS (Cross-Site Scripting):**
+
+Test input fields with XSS payloads via browser:
+```
+<script>alert('XSS')</script>
+<img src=x onerror=alert('XSS')>
+"><script>alert(1)</script>
+javascript:alert(1)
+```
+
+- [ ] Enter XSS payloads in text fields, then view the saved data
+- [ ] Check: payloads are escaped in output (shown as text, not executed)
+- [ ] Check `browser_console_messages` — no alert() or script execution
+- [ ] Test in: names, descriptions, search queries, URL parameters
+
+**SQL Injection:**
+
+Test via API with SQL payloads:
+```bash
+# In filter parameters
+curl -s -u admin:admin "http://localhost:8080/index.php/apps/{app}/api/objects/{register}/{schema}?filter[name]=test' OR '1'='1"
+
+# In search
+curl -s -u admin:admin "http://localhost:8080/index.php/apps/{app}/api/objects/{register}/{schema}?search='; DROP TABLE--"
+```
+
+- [ ] Verify: application returns normal error or empty results (never raw SQL errors)
+- [ ] Verify: QBMapper parameterized queries prevent injection
+
+**JSON Injection:**
+```bash
+# Malformed JSON
+curl -s -u admin:admin -X POST -H "Content-Type: application/json" \
+  -d '{"name":"test","__proto__":{"admin":true}}' \
+  http://localhost:8080/index.php/apps/{app}/api/objects/{register}/{schema}
+```
+
+- [ ] Prototype pollution payloads are rejected or ignored
+
+### Step 5: CORS & CSRF Testing
+
+**CORS configuration:**
+```javascript
+// Test CORS from browser_evaluate
+const response = await fetch('http://localhost:8080/index.php/apps/{app}/api/{endpoint}', {
+    method: 'OPTIONS',
+    headers: {
+        'Origin': 'http://evil.example.com',
+        'Access-Control-Request-Method': 'GET'
+    }
+});
+return JSON.stringify({
+    status: response.status,
+    allowOrigin: response.headers.get('Access-Control-Allow-Origin'),
+    allowMethods: response.headers.get('Access-Control-Allow-Methods'),
+    allowCredentials: response.headers.get('Access-Control-Allow-Credentials')
+});
+```
+
+- [ ] `Access-Control-Allow-Origin` is NOT `*` with credentials
+- [ ] Only legitimate origins are allowed
+- [ ] Preflight OPTIONS routes are registered for public endpoints
+- [ ] Internal endpoints do NOT have CORS headers
+
+**CSRF protection:**
+- [ ] Form submissions require CSRF token (Nextcloud `requesttoken`)
+- [ ] API endpoints with `@NoCSRFRequired` are intentionally public
+- [ ] Non-API POST/PUT/DELETE without token → 401
+
+### Step 6: Authentication & Session
+
+- [ ] Failed login attempts are rate-limited (brute force protection)
+- [ ] Session cookies have `HttpOnly`, `Secure`, `SameSite` flags
+- [ ] Session expires after inactivity
+- [ ] Logout actually invalidates the session
+- [ ] Password not visible in network requests or logs
+
+### Step 7: Information Disclosure
+
+- [ ] Error responses don't expose stack traces or internal paths
+- [ ] API responses don't include sensitive fields (passwords, internal IDs) unless intended
+- [ ] No PII in browser console logs
+- [ ] Server headers don't expose unnecessary version information
+- [ ] No debug/development endpoints accessible in production mode
+
+Check via browser:
+```javascript
+// Check for sensitive data in console
+// Look at browser_console_messages for PII leaks
+```
+
+### Step 8: Generate security report
+
+```markdown
+## Security Test Report: {context}
+
+### Overall Risk: LOW / MEDIUM / HIGH / CRITICAL
+
+### RBAC & Authorization
+| Test | Status | Details |
+|------|--------|---------|
+| Admin-only endpoints protected | PASS/FAIL | {details} |
+| Horizontal access control | PASS/FAIL | {details} |
+| Privilege escalation blocked | PASS/FAIL | {details} |
+
+### Multi-Tenancy Isolation
+| Test | Status | Details |
+|------|--------|---------|
+| Data isolation between orgs | PASS/FAIL | {details} |
+| Org field auto-stamping | PASS/FAIL | {details} |
+| Cross-tenant API access blocked | PASS/FAIL | {details} |
+
+### Input Validation
+| Vector | Status | Details |
+|--------|--------|---------|
+| XSS (reflected) | PASS/FAIL | {details} |
+| XSS (stored) | PASS/FAIL | {details} |
+| SQL injection | PASS/FAIL | {details} |
+| JSON injection | PASS/FAIL | {details} |
+
+### CORS & CSRF
+| Test | Status | Details |
+|------|--------|---------|
+| CORS allowlist | PASS/FAIL | {details} |
+| CSRF token enforcement | PASS/FAIL | {details} |
+
+### Authentication & Session
+| Test | Status | Details |
+|------|--------|---------|
+| Brute force protection | PASS/FAIL | {details} |
+| Session security flags | PASS/FAIL | {details} |
+| Session invalidation | PASS/FAIL | {details} |
+
+### Information Disclosure
+| Test | Status | Details |
+|------|--------|---------|
+| No stack traces in errors | PASS/FAIL | {details} |
+| No PII in logs | PASS/FAIL | {details} |
+
+### BIO2 Compliance
+| Control | Status | Notes |
+|---------|--------|-------|
+| Audit logging | PRESENT/ABSENT | {details} |
+| Access control (least privilege) | OK/GAPS | {details} |
+| Encryption (TLS) | OK/MISSING | {details} |
+| Input validation | OK/GAPS | {details} |
+
+### Vulnerabilities Found
+| # | Severity | Category | Description | Remediation |
+|---|----------|----------|-------------|-------------|
+| 1 | CRITICAL/HIGH/MEDIUM/LOW | {OWASP category} | {description} | {fix} |
+
+### Recommendation
+SECURE / NEEDS FIXES / CRITICAL ISSUES
+```
+
+---
+
+**Write this report to file** before returning: use the Write tool to save the report above to `{APP}/test-results/test-security-results.md`. Use the change name or app name in the filename where relevant.
+
+## Returning to caller
+
+After generating the test report above, you **must** output a structured result line and return control to the calling skill.
+
+**Always output this line after the report** (replace values accordingly):
+
+```
+SECURITY_TEST_RESULT: PASS | FAIL  CRITICAL_COUNT: <n>  SUMMARY: <one-line summary>
+```
+
+- **PASS** = recommendation is SECURE and no CRITICAL/HIGH vulnerabilities found
+- **FAIL** = recommendation is NEEDS FIXES or CRITICAL ISSUES
+
+**If invoked from `/opsx-apply-loop`**: your work is complete after outputting the result line. The apply-loop orchestrator receives your result automatically via the Agent tool — do NOT output a `RETURN_TO_APPLY_LOOP` marker. Do NOT start new work, do NOT suggest fixes, do NOT ask what to do next.
diff --git a/.claude/skills/test-security/evals/evals.json b/.claude/skills/test-security/evals/evals.json
new file mode 100644
index 00000000..d8b0280e
--- /dev/null
+++ b/.claude/skills/test-security/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"test-security","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"injection","description":"Injection testing","prompt":"Run /test-security on openregister","setup":"App running","expected":"Should test XSS, SQL injection, command injection","assertions":["Tests XSS via form inputs and URL parameters","Tests SQL injection on search/filter endpoints","Tests for command injection vectors","Reports severity of any findings"]},{"id":"auth","description":"Auth/authz testing","prompt":"Run /test-security and check auth","setup":"App running with roles","expected":"Should verify access control","assertions":["Tests horizontal privilege escalation","Tests vertical privilege escalation","Verifies CSRF protection","Tests session handling"]},{"id":"bio2","description":"BIO2 compliance","prompt":"Run /test-security for BIO2 compliance","setup":"App in Dutch government context","expected":"Should check BIO2 requirements","assertions":["Checks audit trail logging","Verifies data classification handling","Tests encryption at rest and in transit","Checks against BIO2/ENSIA requirements"]}],"trigger_tests":{"should_trigger":["test security","security audit","check for vulnerabilities","test injection attacks","BIO2 compliance check"],"should_not_trigger":["test accessibility","test performance","test the API","run functional tests","test the app"]}}
diff --git a/.claude/skills/update-skill-overview.sh b/.claude/skills/update-skill-overview.sh
new file mode 100644
index 00000000..b9cbcc8a
--- /dev/null
+++ b/.claude/skills/update-skill-overview.sh
@@ -0,0 +1,314 @@
+#!/bin/bash
+# update-skill-overview.sh — Auto-updates skill-level-overview.html
+#
+# Auto-updates:
+#   - Maturity levels (L1, L2, L3, L5, L6, L7 auto-detected)
+#   - Line counts, color classes, L5/L6/L7 struct flags
+#   - Skill descriptions, new rows, orphan detection
+#
+# L4 (Domain Knowledge) is NEVER auto-set or auto-removed.
+# The script will prominently ask for your input when L4 blocks progress.
+
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+HTML="$SCRIPT_DIR/skill-level-overview.html"
+
+[ -f "$HTML" ] || { echo "Error: $HTML not found"; exit 1; }
+
+CHANGES=0
+WARNINGS=""
+L4_ACTIONS=""
+declare -A disk_skills
+
+MAX_DESC_LEN=150
+
+color_class() {
+  local n=$1
+  if   (( n <= 200 )); then echo "regels-perfecte"
+  elif (( n <= 300 )); then echo "regels-heel-weinig"
+  elif (( n <= 400 )); then echo "regels-weinig"
+  elif (( n <= 450 )); then echo "regels-midden"
+  elif (( n <= 500 )); then echo "regels-veel"
+  else echo "regels-heel-veel"
+  fi
+}
+
+get_description() {
+  local raw
+  raw=$(sed -n '/^---$/,/^---$/{/^description:/{s/^description: *//;s/^"//;s/"$//;s/'"'"'//g;p;}}' "$1" | head -1)
+  if [ "${#raw}" -gt "$MAX_DESC_LEN" ]; then
+    echo "${raw:0:$((MAX_DESC_LEN - 1))}…"
+  else
+    echo "$raw"
+  fi
+}
+
+echo "Scanning skills in $SCRIPT_DIR ..."
+echo ""
+
+for dir in "$SCRIPT_DIR"/*/; do
+  [ -d "$dir" ] || continue
+  skill="$(basename "$dir")"
+  md="$dir/SKILL.md"
+  [ -f "$md" ] || continue
+
+  disk_skills["$skill"]=1
+
+  # === DETECT STRUCTURAL MARKERS ===
+
+  lines=$(wc -l < "$md")
+  cls=$(color_class "$lines")
+  desc=$(get_description "$md")
+  raw_desc=$(sed -n '/^---$/,/^---$/{/^description:/{s/^description: *//;s/^"//;s/"$//;s/'"'"'//g;p;}}' "$md" | head -1)
+
+  # L1: frontmatter + numbered steps + guardrails + folder name matches
+  has_frontmatter=0
+  head -1 "$md" | grep -q '^---$' && has_frontmatter=1
+  has_steps=0
+  grep -qE '^[0-9]+\.|^#{1,4}\s*(Step|Phase)|^\*\*Step' "$md" 2>/dev/null && has_steps=1
+  has_guardrails=0
+  # Guardrail sections
+  grep -qiE '^#{1,4}\s*(Guard|Hard Rule|Rule|Constraint|Boundar|Limitation|Warning)' "$md" 2>/dev/null && has_guardrails=1
+  # Strong directives
+  [ "$has_guardrails" = "0" ] && grep -qiE 'should not|must not|do not|never |IMPORTANT:|stop immediately|stop here' "$md" 2>/dev/null && has_guardrails=1
+  # Common directive patterns (present in well-structured skills)
+  [ "$has_guardrails" = "0" ] && grep -qiE 'must include|must comply|ensure |always |Skip if|ONLY ' "$md" 2>/dev/null && has_guardrails=1
+  name_matches=0
+  grep -q "^name: ${skill}$\|^name: \"${skill}\"$" "$md" 2>/dev/null && name_matches=1
+
+  # L3: common patterns + examples/ or references/ folder
+  has_model_guard=0
+  grep -qiE "model:|On Haiku|on Haiku|Select.*Model|Model check|Model Recommendation|Haiku.*stop|active model" "$md" 2>/dev/null && has_model_guard=1
+  has_ask=0
+  grep -q "AskUserQuestion" "$md" 2>/dev/null && has_ask=1
+  has_other_l3=0
+  grep -qiE "acceptance_criteria|browser_snapshot|browser_navigate|## Hard Rule|## Verification|confirm.*before" "$md" 2>/dev/null && has_other_l3=1
+  has_subfolder_refs=0
+  grep -qiE "examples/|refs/|references/|templates/" "$md" 2>/dev/null && has_subfolder_refs=1
+  has_quality_gates=0
+  grep -qiE "composer check|phpcs|phpstan|make check|ruff |psalm " "$md" 2>/dev/null && has_quality_gates=1
+  has_l3_patterns=0
+  ([ "$has_model_guard" = "1" ] || [ "$has_ask" = "1" ] || [ "$has_other_l3" = "1" ] || [ "$has_subfolder_refs" = "1" ] || [ "$has_quality_gates" = "1" ]) && has_l3_patterns=1
+  has_examples=0
+  [ -d "$dir/examples" ] && has_examples=1
+  has_refs=0
+  ([ -d "$dir/refs" ] || [ -d "$dir/references" ]) && has_refs=1
+  has_templates=0
+  [ -d "$dir/templates" ] && has_templates=1
+
+  # L5 markers: evals with 3+ scenarios
+  eval_count=0; has_trigger_tests=0
+  if [ -f "$dir/evals/evals.json" ]; then
+    eval_count=$(python3 -c "import json; d=json.load(open('${dir}evals/evals.json')); print(len(d.get('scenarios',[])))" 2>/dev/null || echo 0)
+    has_trigger_tests=$(python3 -c "import json; d=json.load(open('${dir}evals/evals.json')); tt=d.get('trigger_tests',{}); print(1 if tt.get('should_trigger') and tt.get('should_not_trigger') else 0)" 2>/dev/null || echo 0)
+  fi
+
+  # L6 markers: learnings.md with dated entries + capture step
+  has_dated_learnings=0
+  [ -f "$dir/learnings.md" ] && has_dated_learnings=$(grep -c "^- \[2" "$dir/learnings.md" 2>/dev/null || echo 0)
+  has_capture=0
+  grep -q "Capture Learnings" "$md" 2>/dev/null && has_capture=1
+
+  # L7 markers: agent spawning
+  has_agent=0
+  grep -qE "Agent tool|subagent|sub-agent|Launch.*agent|Task agents" "$md" 2>/dev/null && has_agent=1
+
+  # Struct flags (for orange rings)
+  l5=0; [ "$eval_count" -ge 3 ] && l5=1
+  l6=0; [ -f "$dir/learnings.md" ] && [ "$has_capture" = "1" ] && l6=1
+  l7=0; [ "$has_agent" = "1" ] && l7=1
+
+  # === ADD NEW ROW IF MISSING ===
+
+  if ! grep -q ">${skill}<" "$HTML"; then
+    tbody_end=$(grep -n '</tbody>' "$HTML" | head -1 | cut -d: -f1)
+    extra_attrs=""
+    [ "$l5" = "1" ] && extra_attrs+=' data-l5struct="1"'
+    [ "$l6" = "1" ] && extra_attrs+=' data-l6infra="1"'
+    [ "$l7" = "1" ] && extra_attrs+=' data-l7struct="1"'
+    sed -i "${tbody_end}i\\<tr data-maturity=\"1\" data-structural=\"1\" data-target=\"3\"${extra_attrs}>\n  <td><a href=\"${skill}/SKILL.md\">${skill}</a></td><td>${desc}</td>\n  <td class=\"level-cell\"></td>\n  <td class=\"target-cell\"><span class=\"target-badge tl3\">L3</span></td>\n  <td class=\"lines ${cls}\">${lines}</td>\n</tr>" "$HTML"
+    echo "  ${skill}: NEW ROW (M=1 S=1 T=3 — set target manually)"
+    CHANGES=$((CHANGES + 1))
+  fi
+
+  # === FIND ROW IN HTML ===
+
+  td_line=$(grep -n ">${skill}<" "$HTML" | head -1 | cut -d: -f1)
+  tr_line=$((td_line - 1))
+  lines_td=$((td_line + 3))
+
+  cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  cur_lines_td=$(sed -n "${lines_td}p" "$HTML")
+  cur_count=$(echo "$cur_lines_td" | grep -oP '>\K\d+(?=<)' || echo "?")
+  cur_cls=$(echo "$cur_lines_td" | grep -oP 'lines \K[^"]+' || echo "?")
+  cur_m=$(echo "$cur_tr" | grep -oP 'data-maturity="\K\d+' || echo 0)
+
+  # === COMPUTE MATURITY ===
+
+  # Each level detected per writing-skills.md criteria
+  l1_met=0  # frontmatter + steps + guardrails + name matches
+  [ "$has_frontmatter" = "1" ] && [ "$has_steps" = "1" ] && [ "$has_guardrails" = "1" ] && [ "$name_matches" = "1" ] && l1_met=1
+
+  l2_met=0  # under 500 lines + description exists
+  [ "$lines" -le 500 ] && [ -n "$raw_desc" ] && l2_met=1
+
+  l3_met=0  # common patterns + (examples/ or references/)
+  [ "$has_l3_patterns" = "1" ] && ([ "$has_examples" = "1" ] || [ "$has_refs" = "1" ] || [ "$has_templates" = "1" ]) && l3_met=1
+
+  # L4: MANUAL — trust the current value, never auto-change
+  l4_confirmed=0
+  [ "$cur_m" -ge 4 ] 2>/dev/null && l4_confirmed=1
+
+  l5_met=0
+  [ "$eval_count" -ge 3 ] && l5_met=1
+
+  l6_met=0
+  [ "$has_dated_learnings" -gt 0 ] 2>/dev/null && [ "$has_capture" = "1" ] && l6_met=1
+
+  l7_met=0
+  [ "$has_agent" = "1" ] && l7_met=1
+
+  # Cumulative chain (each level requires all below)
+  new_m=0
+  [ "$l1_met" = "1" ] && new_m=1
+  [ "$new_m" -ge 1 ] && [ "$l2_met" = "1" ] && new_m=2
+  [ "$new_m" -ge 2 ] && [ "$l3_met" = "1" ] && new_m=3
+  [ "$new_m" -ge 3 ] && [ "$l4_confirmed" = "1" ] && new_m=4
+  [ "$new_m" -ge 4 ] && [ "$l5_met" = "1" ] && new_m=5
+  [ "$new_m" -ge 5 ] && [ "$l6_met" = "1" ] && new_m=6
+  [ "$new_m" -ge 6 ] && [ "$l7_met" = "1" ] && new_m=7
+
+  # L4 blocking detection
+  if [ "$new_m" = "3" ] && [ "$l4_confirmed" = "0" ]; then
+    blocked=""
+    [ "$l5_met" = "1" ] && blocked+="L5 "
+    [ "$l6_met" = "1" ] && blocked+="L6 "
+    [ "$l7_met" = "1" ] && blocked+="L7 "
+    if [ "$has_refs" = "1" ]; then
+      L4_ACTIONS+="\n  ${skill}:  L1-L3 achieved + refs/ detected → CONFIRM L4 to unlock ${blocked:-higher levels}"
+    else
+      L4_ACTIONS+="\n  ${skill}:  L1-L3 achieved → SET L4 (domain knowledge) to unlock ${blocked:-higher levels}"
+    fi
+  fi
+
+  # === UPDATE MATURITY ===
+
+  if [ "$new_m" != "$cur_m" ] 2>/dev/null; then
+    sed -i "${tr_line}s|data-maturity=\"${cur_m}\"|data-maturity=\"${new_m}\"|" "$HTML"
+    if [ "$new_m" -gt "$cur_m" ]; then
+      echo "  ${skill}: maturity M${cur_m} -> M${new_m} ↑"
+    else
+      echo "  ${skill}: maturity M${cur_m} -> M${new_m} ↓"
+    fi
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  fi
+
+  # === UPDATE LINE COUNT ===
+
+  if [ "$cur_count" != "$lines" ] || [ "$cur_cls" != "$cls" ]; then
+    sed -i "${lines_td}s|<td class=\"lines [^\"]*\">[0-9]*</td>|<td class=\"lines ${cls}\">${lines}</td>|" "$HTML"
+    echo "  ${skill}: lines ${cur_count} -> ${lines} (${cls})"
+    CHANGES=$((CHANGES + 1))
+  fi
+
+  # === UPDATE STRUCT FLAGS ===
+
+  # L5
+  has_l5s=0; echo "$cur_tr" | grep -q 'l5struct' && has_l5s=1
+  if [ "$l5" = "1" ] && [ "$has_l5s" = "0" ]; then
+    sed -i "${tr_line}s|>$| data-l5struct=\"1\">|" "$HTML"
+    echo "  ${skill}: +L5 struct (evals)"
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  elif [ "$l5" = "0" ] && [ "$has_l5s" = "1" ]; then
+    sed -i "${tr_line}s| data-l5struct=\"1\"||" "$HTML"
+    echo "  ${skill}: -L5 struct"
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  fi
+
+  # L6
+  has_l6i=0; echo "$cur_tr" | grep -q 'l6infra' && has_l6i=1
+  if [ "$l6" = "1" ] && [ "$has_l6i" = "0" ]; then
+    sed -i "${tr_line}s|>$| data-l6infra=\"1\">|" "$HTML"
+    echo "  ${skill}: +L6 infra"
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  elif [ "$l6" = "0" ] && [ "$has_l6i" = "1" ]; then
+    sed -i "${tr_line}s| data-l6infra=\"1\"||" "$HTML"
+    echo "  ${skill}: -L6 infra"
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  fi
+
+  # L7
+  has_l7s=0; echo "$cur_tr" | grep -q 'l7struct' && has_l7s=1
+  if [ "$l7" = "1" ] && [ "$has_l7s" = "0" ]; then
+    sed -i "${tr_line}s|>$| data-l7struct=\"1\">|" "$HTML"
+    echo "  ${skill}: +L7 struct (agents)"
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  elif [ "$l7" = "0" ] && [ "$has_l7s" = "1" ]; then
+    sed -i "${tr_line}s| data-l7struct=\"1\"||" "$HTML"
+    echo "  ${skill}: -L7 struct"
+    CHANGES=$((CHANGES + 1))
+    cur_tr=$(sed -n "${tr_line}p" "$HTML")
+  fi
+
+  # === UPDATE DESCRIPTION ===
+
+  if [ -n "$desc" ]; then
+    cur_desc=$(sed -n "${td_line}p" "$HTML" | grep -oP '</td><td>\K[^<]*')
+    if [ -n "$cur_desc" ] && [ "$cur_desc" != "$desc" ]; then
+      safe_old=$(printf '%s' "$cur_desc" | sed 's|[&/\]|\\&|g')
+      safe_new=$(printf '%s' "$desc" | sed 's|[&/\]|\\&|g')
+      sed -i "${td_line}s|</td><td>${safe_old}</td>|</td><td>${safe_new}</td>|" "$HTML"
+      echo "  ${skill}: description updated"
+      CHANGES=$((CHANGES + 1))
+    fi
+  fi
+
+  # === WARNINGS ===
+
+  [ "$lines" -gt 500 ] && [ "$new_m" -ge 2 ] 2>/dev/null && \
+    WARNINGS+="\n  ${skill}: ${lines} lines (>500) — L2 violated, maturity capped"
+
+done
+
+# === ORPHANED ROWS ===
+
+while IFS= read -r html_skill; do
+  [ -z "$html_skill" ] && continue
+  if [ -z "${disk_skills[$html_skill]+x}" ]; then
+    WARNINGS+="\n  ORPHAN: ${html_skill} is in the HTML but skill directory not found — remove row?"
+  fi
+done < <(grep -B1 'level-cell' "$HTML" | grep -oP '>\K[a-z][-a-z0-9]*(?=<)')
+
+# === OUTPUT ===
+
+echo ""
+echo "${CHANGES} auto-updates applied."
+
+if [ -n "$L4_ACTIONS" ]; then
+  echo ""
+  echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
+  echo "!!!  ACTION REQUIRED: L4 (Domain Knowledge) needs your input  !!!"
+  echo "!!!                                                           !!!"
+  echo "!!!  L4 is never auto-set. These skills have L1-L3 achieved   !!!"
+  echo "!!!  but are stuck at M3 because L4 hasn't been confirmed.    !!!"
+  echo "!!!  To unlock higher maturity, manually set data-maturity    !!!"
+  echo "!!!  to 4 or higher in the HTML after verifying domain        !!!"
+  echo "!!!  knowledge is present.                                    !!!"
+  echo "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
+  echo -e "$L4_ACTIONS"
+  echo ""
+fi
+
+if [ -n "$WARNINGS" ]; then
+  echo ""
+  echo "=== WARNINGS ==="
+  echo -e "$WARNINGS"
+  echo ""
+fi
diff --git a/.claude/skills/verify-global-settings-version/SKILL.md b/.claude/skills/verify-global-settings-version/SKILL.md
new file mode 100644
index 00000000..0e93b250
--- /dev/null
+++ b/.claude/skills/verify-global-settings-version/SKILL.md
@@ -0,0 +1,121 @@
+---
+name: verify-global-settings-version
+description: Check whether global-settings/VERSION has been correctly bumped after any changes to files in the global-settings/ directory
+---
+
+# Verify Global Settings Version
+
+**Model check — only apply when this skill is run standalone (invoked directly by the user via `/verify-global-settings-version`). Skip this section entirely if this skill was called from within another skill — the calling skill is responsible for model selection.**
+
+- **On Haiku**: proceed normally — this is the right model for this task.
+- **On Sonnet**: inform the user and ask using AskUserQuestion:
+  > "⚠️ You're on Sonnet. This skill runs git commands to check version file consistency — no reasoning required. Haiku is a better fit and conserves quota for heavier tasks. Switch with `/model haiku`, or proceed with Sonnet."
+  Options: **Proceed with Sonnet** / **Switch to Haiku first** (stop here if switching)
+- **On Opus**: stop immediately:
+  > "You're on Opus. This skill runs git commands to check version file consistency — no reasoning required. Opus is overkill here and will waste quota unnecessarily. Please switch to Haiku (`/model haiku`) and re-run."
+
+---
+
+Checks whether the `global-settings/VERSION` file has been correctly bumped after any changes to files in the `global-settings/` directory. Run this before creating a PR on the `ConductionNL/.github` repo to ensure users will be notified to update.
+
+---
+
+## When to use
+
+- Before running `/create-pr` on the `ConductionNL/.github` repo
+- Any time you modify a file in `global-settings/` and want to confirm the version bump is in place
+- During code review to verify a PR touching `global-settings/` includes a version bump
+
+---
+
+## Step 1: Locate the repo
+
+The canonical `global-settings/` directory lives in the [`ConductionNL/.github`](https://github.com/ConductionNL/.github/tree/feature/claude-code-tooling/global-settings) repo:
+
+```bash
+REPO_DIR="$(git rev-parse --show-toplevel 2>/dev/null)"
+git -C "$REPO_DIR" rev-parse --show-toplevel
+```
+
+If the repo cannot be found, stop and tell the user.
+
+---
+
+## Step 2: Check for changes in `global-settings/`
+
+Compare the current branch (`HEAD`) against `origin/main` to find which files in `global-settings/` have been modified:
+
+```bash
+git -C "$REPO_DIR" fetch origin main --quiet --depth=1 2>/dev/null
+git -C "$REPO_DIR" diff --name-only origin/main...HEAD -- global-settings/
+```
+
+Store the result as `{CHANGED_FILES}`.
+
+---
+
+## Step 3: Check if VERSION was bumped
+
+Regardless of whether other files changed, read both versions:
+
+```bash
+# Current branch VERSION
+current=$(cat "$REPO_DIR/global-settings/VERSION" | tr -d '[:space:]')
+
+# origin/main VERSION
+main=$(git -C "$REPO_DIR" show origin/main:global-settings/VERSION 2>/dev/null | tr -d '[:space:]')
+
+echo "Current branch : $current"
+echo "origin/main    : $main"
+```
+
+---
+
+## Step 4: Evaluate and report
+
+### Case A — No changes to `global-settings/`
+
+> ✅ No files in `global-settings/` were changed relative to `origin/main`. No version bump needed.
+
+### Case B — Changes found AND `VERSION` was bumped higher
+
+Verify the bump is a valid semver increment (major, minor, or patch):
+
+> ✅ `global-settings/` changes detected and `VERSION` was correctly bumped from `v{main}` → `v{current}`.
+>
+> Changed files:
+> - `{file1}`
+> - `{file2}`
+
+### Case C — Changes found but `VERSION` was NOT bumped
+
+> ❌ **VERSION BUMP MISSING**
+>
+> The following files in `global-settings/` were changed but `VERSION` was not incremented:
+> - `{file1}`
+> - `{file2}`
+>
+> Current `VERSION` on this branch: `v{current}` (same as `origin/main`)
+>
+> **Action required:** Increment `global-settings/VERSION` before creating a PR.
+> Suggested next version: `v{suggested}` (patch bump — use minor if behavior changed, major if breaking)
+>
+> To apply the suggested bump:
+> ```bash
+> echo "{suggested}" > "$REPO_DIR/global-settings/VERSION"
+> ```
+> Then commit the change and re-run `/verify-global-settings-version`.
+
+### Case D — `VERSION` was changed but no other files changed
+
+> ⚠️ `VERSION` was bumped from `v{main}` → `v{current}` but no other files in `global-settings/` were changed.
+>
+> This is unusual — confirm the bump is intentional before creating a PR.
+
+---
+
+## Integration with `/create-pr`
+
+When `/create-pr` is run and the selected repository is `ConductionNL/.github`, this check runs automatically as part of Step 3.5 (before local quality checks). If a missing version bump is detected (Case C), the PR flow is paused and the user is asked to fix it before continuing.
+
+> 💡 If you switched models to run this command, don't forget to switch back to your preferred model with `/model <name>` (e.g. `/model default` or `/model sonnet`) when done.
diff --git a/.claude/skills/verify-global-settings-version/evals/evals.json b/.claude/skills/verify-global-settings-version/evals/evals.json
new file mode 100644
index 00000000..f4a222c9
--- /dev/null
+++ b/.claude/skills/verify-global-settings-version/evals/evals.json
@@ -0,0 +1 @@
+{"skill":"verify-global-settings-version","version":"1.0.0","created":"2026-04-07","scenarios":[{"id":"bump-needed","description":"Changes without version bump","prompt":"Run verify when global-settings files changed but VERSION not bumped","setup":"global-settings/ files modified, VERSION unchanged","expected":"Should report Case C (bump missing)","assertions":["Detects file changes in global-settings/","Compares VERSION against origin/main","Reports bump is missing (Case C)","Suggests incrementing VERSION"]},{"id":"correctly-bumped","description":"Changes with correct bump","prompt":"Run when VERSION was bumped alongside changes","setup":"Both files and VERSION changed","expected":"Should report Case B (correctly bumped)","assertions":["Detects both file changes and VERSION change","Reports Case B (correctly bumped)","No action needed","Clean result"]},{"id":"no-changes","description":"No changes at all","prompt":"Run when nothing in global-settings changed","setup":"No modifications to global-settings/","expected":"Should report Case A (no changes)","assertions":["Detects no file changes","Reports Case A","Does NOT suggest version bump","Quick clean result"]}],"trigger_tests":{"should_trigger":["verify global settings version","check VERSION bump","verify-global-settings-version","did I bump the version","check global settings"],"should_not_trigger":["verify app config","check app version","verify the change","update settings","bump the version"]}}
diff --git a/.specter-prompt.txt b/.specter-prompt.txt
new file mode 100644
index 00000000..6e824a15
--- /dev/null
+++ b/.specter-prompt.txt
@@ -0,0 +1,49 @@
+You are generating OpenSpec change artifacts for a Nextcloud app.
+
+You are running HEADLESS. Do NOT use AskUserQuestion, interactive prompts, or skills.
+Write files directly using the Write tool.
+
+## Inputs
+- Change: workflow-import-export (title: Workflow Import Export)
+- Context brief: openspec/changes/workflow-import-export/context-brief.md
+- Data model ADR: openspec/architecture/adr-000-data-model.md
+
+## Step 1: Read context
+Read these files COMPLETELY before writing anything:
+- openspec/changes/workflow-import-export/context-brief.md (features, stories, stakeholders, journeys)
+- openspec/architecture/adr-000-data-model.md (entity definitions)
+- All files in openspec/architecture/ (app ADRs)
+- All files in .claude/openspec/architecture/ (company ADRs, if present)
+
+## Step 2: Get artifact templates
+Run: `openspec instructions proposal --change workflow-import-export --json`
+This returns the template and rules for the proposal artifact.
+Then do the same for: design, specs, tasks (in that order).
+
+## Step 3: Write artifacts
+For each artifact (proposal → design → specs → tasks):
+1. Read the template from openspec instructions
+2. Fill it using the REAL data from context-brief.md:
+   - Features with their demand scores and descriptions
+   - User stories with acceptance criteria (GIVEN/WHEN/THEN)
+   - Customer journeys with triggers and pain points
+   - Stakeholder profiles with responsibilities and goals
+   - Entity schemas from ADR-000 (do NOT invent new entities)
+3. Write the artifact file using the Write tool
+4. Verify it exists
+
+## Step 4: Commit
+After all 4 artifacts are written:
+```bash
+git add openspec/changes/workflow-import-export/
+git commit -m 'feat: Add OpenSpec change workflow-import-export from Specter'
+```
+Do NOT push — the caller handles pushing.
+Do NOT create branches — stay on the current branch.
+
+## Rules
+- Use REAL data from context-brief.md — NEVER invent features, stories, or entities
+- Entities MUST match ADR-000 exactly
+- Include seed data in design.md (3-5 example objects per entity, Dutch values)
+- Requirements in specs use REQ-XXX-NNN format with GIVEN/WHEN/THEN scenarios
+- Tasks in tasks.md are checkboxes [ ] with clear implementation steps
diff --git a/openspec/changes/workflow-import-export/.openspec.yaml b/openspec/changes/workflow-import-export/.openspec.yaml
new file mode 100644
index 00000000..3a54a172
--- /dev/null
+++ b/openspec/changes/workflow-import-export/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-16
diff --git a/openspec/changes/workflow-import-export/context-brief.md b/openspec/changes/workflow-import-export/context-brief.md
new file mode 100644
index 00000000..8517bc15
--- /dev/null
+++ b/openspec/changes/workflow-import-export/context-brief.md
@@ -0,0 +1,47 @@
+## Requirements
+
+### Requirement: Export Workflow Template
+
+The system SHALL allow administrators to export a workflow template (including all steps, transitions, guards, and actions) as a JSON file for transfer between environments (OTAP).
+
+**Feature tier**: V1
+
+#### Scenario: Export workflow to JSON
+
+- **WHEN** an administrator clicks "Exporteren" on workflow template "Omgevingsvergunning v3"
+- **THEN** the system SHALL generate a JSON file containing the complete workflow definition
+- **AND** the JSON SHALL include: template metadata, all steps with their properties, all transitions with guards and actions, referenced StatusType names (not UUIDs)
+- **AND** the file SHALL be downloaded as `omgevingsvergunning-v3-workflow.json`
+
+#### Scenario: Export uses names instead of UUIDs for portability
+
+- **WHEN** a workflow template is exported
+- **THEN** all references to StatusTypes, RoleTypes, and DocumentTypes SHALL use their `name` property instead of UUIDs
+- **AND** the export SHALL include a manifest section listing all referenced types for validation at import time
+
+### Requirement: Import Workflow Template
+
+The system SHALL allow administrators to import a workflow template JSON file into a zaaktype, matching referenced types by name and creating the workflow as a new draft version.
+
+**Feature tier**: V1
+
+#### Scenario: Import workflow with matching types
+
+- **WHEN** an administrator imports a workflow JSON file into zaaktype "Omgevingsvergunning"
+- **AND** all referenced StatusTypes, RoleTypes, and DocumentTypes exist on the target zaaktype (matched by name)
+- **THEN** the system SHALL create a new draft workflow template version
+- **AND** all steps, transitions, guards, and actions SHALL be recreated with the target environment's UUIDs
+
+#### Scenario: Import with missing types
+
+- **WHEN** an administrator imports a workflow JSON file
+- **AND** the source workflow references StatusType "Advies extern" which does not exist on the target zaaktype
+- **THEN** the system SHALL display a validation report listing missing types
+- **AND** the administrator SHALL be offered the option to: (a) auto-create the missing types, or (b) cancel the import
+
+#### Scenario: Import does not overwrite active workflow
+
+- **WHEN** an administrator imports a workflow into a zaaktype that already has an active workflow
+- **THEN** the imported workflow SHALL be created as a new draft version
+- **AND** the currently active workflow SHALL remain unchanged
+- **AND** the administrator must explicitly publish the imported version to activate it
diff --git a/openspec/changes/workflow-import-export/hydra.json b/openspec/changes/workflow-import-export/hydra.json
new file mode 100644
index 00000000..93bbdaa2
--- /dev/null
+++ b/openspec/changes/workflow-import-export/hydra.json
@@ -0,0 +1,8 @@
+{
+  "spec_slug": "workflow-import-export",
+  "title": "Workflow Import Export",
+  "app": "procest",
+  "repo": "https://github.com/ConductionNL/procest",
+  "depends_on": [],
+  "issue": null
+}
\ No newline at end of file