Use shared calendar context and harden execution tests

.agents/skills/test-driven-change/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: test-driven-change
+description: Deliver observable behavior changes through a verified Red–Green–Refactor cycle. Use for new features, bug fixes, domain logic, permission changes, API behavior, data changes, and contract changes; do not use automatically for documentation-only, formatting, generated-file, or mechanical changes without testable behavior.
+---
+
+# Deliver a test-driven change
+
+## Establish the proof
+
+Before writing the test, record:
+
+- the domain invariant;
+- the observable target behavior;
+- the defect or regression the test must detect;
+- the chosen test level;
+- what the test proves and what it does not prove;
+- relevant negative and boundary cases.
+
+Choose the lowest level that proves the real contract without replacing
+observable behavior with implementation detail. Use a higher integration,
+contract, smoke, or end-to-end level when the lower level cannot exercise the
+relevant boundary truthfully. For a bug fix, make the smallest proof a
+regression test.
+
+## Red
+
+1. Write the smallest meaningful test before changing production code.
+2. Run that test and record the command, exit code, and concrete failure or
+   assertion difference.
+3. Confirm that it fails for the expected domain reason: the target behavior
+   is missing or wrong.
+4. Do not proceed to Green when:
+   - the test is immediately green and is not an explicitly justified
+     characterization test;
+   - it fails only because of infrastructure, syntax, fixture, or configuration
+     defects;
+   - it does not reach the target behavior;
+   - it checks only a mock call although observable behavior can be checked
+     meaningfully.
+
+Repair a defective test environment without adding the target production
+behavior, then repeat Red. An immediately green test can preserve known
+behavior as a characterization test, but is not evidence of a TDD Red step.
+
+## Green
+
+1. Make only the smallest production-code change needed to satisfy the test.
+2. Add no speculative abstraction or unrelated refactoring.
+3. Run the new test again.
+4. Run the relevant existing regression suite.
+
+## Cover risk-specific evidence
+
+For permission changes, verify at least:
+
+- unauthorized access is rejected;
+- authorized access succeeds;
+- a foreign or manipulated object ID grants no access and causes no data
+  change;
+- a rejected request changes no data;
+- UI visibility is never used as a substitute for server-side access control.
+
+For database or migration changes, verify at least:
+
+- fresh installation on an empty schema;
+- upgrade from at least the immediately relevant prior version;
+- preservation or correct migration of existing data;
+- required constraints and indexes exist and preserve integrity;
+- no incomplete state after failure.
+
+For shared libraries or contracts, verify:
+
+- relevant provider and consumer contract tests;
+- every affected dependent app;
+- backward compatibility or an explicitly documented break.
+
+For write operations, verify:
+
+- the return value or HTTP result;
+- the persisted state;
+- absence of unwanted side effects;
+- repeated execution when idempotency is relevant.
+
+These checks supplement applicable repository stop gates. They do not authorize
+database, permission, cross-repository, or production changes.
+
+## Refactor
+
+Refactor only after the new test and relevant regression suite are green.
+Change no domain behavior. Run the new test and relevant existing tests again
+after refactoring.
+
+## Handle non-behavioral changes and deviations
+
+For documentation-only, formatting, generated-file, or mechanical changes
+without meaningfully testable behavior, use the suitable deterministic syntax,
+contract, generation, layout, link, or structure check instead of an artificial
+TDD cycle.
+
+State and justify every deviation from the test-driven workflow. Do not treat a
+test that was never observed red as TDD evidence.
+
+## Report
+
+Include:
+
+- the protected invariant and chosen test level;
+- the initially red test and expected failure reason;
+- the minimal implementation;
+- executed focused, regression, and contract tests as applicable;
+- concrete commands, results, and exit codes;
+- remaining untested risks;
+- justified deviations.

.agents/skills/work-in-nextcloud-app/SKILL.md

@@ -52,15 +52,23 @@ Stop immediately if production systems, Git history rewriting, new production de
 
 ## Test-first and coverage
 
-- New development and bug fixes normally follow Red – Green – Refactor. Start a bug fix with a regression test and a refactoring with characterization tests. Develop domain logic, permissions, hierarchies, conflicts, and validation test-first.
+- Use the locally available sibling skill `test-driven-change` for every new feature, bug fix, domain rule, permission change, API behavior, data change, or contract change. It is the sole detailed Red–Green–Refactor workflow; this section adds only Nextcloud-app test selection and coverage requirements.
 - API changes cover success, validation failure, and typical Allow/Deny cases. Cross-app contracts have provider and consumer contract tests. Use integration/DDEV tests for migrations and repository behavior when unit tests cannot represent the real contract.
 - Develop executable UI logic test-first; additionally cover layout, accessibility, and Nextcloud integration with suitable smoke or browser checks.
-- Permitted test-first entry exceptions are time-boxed exploratory spikes, purely declarative text/metadata or trivial presentation changes, and hard-to-isolate Nextcloud integration where a broader integration test is more truthful. Discard spike code or characterize it before adoption; give declarative changes appropriate syntax, contract, layout, or visibility checks.
+- Treat a time-boxed exploratory spike or hard-to-isolate Nextcloud integration as an explicitly justified deviation. Discard spike code or characterize it before adoption; choose the truthful broader integration level when isolation would hide the real contract.
 - Use the local fast entries named by `AGENTS.md`, normally `php tests/run.php` and `node tests/run-js.mjs`; dependency-light PHP smokes run in isolated processes. Run LocalBase and every affected consumer contract/smoke suite after a LocalBase contract change.
 - In local pre-production, app tests may use shared LocalBase test helpers through relative repository paths. Add heavier packaging/autoload structure or a larger test framework only when path handling, runners, assertions, mocks, or fixtures are materially duplicated or impair readability.
 - Known overall and app coverage must not decline unnoticed. Aim for at least 85 percent line coverage for new or materially changed executable code, report PHP and JavaScript separately, and fully cover security invariants regardless of percentages. Coverage is a warning and delivery indicator, not a substitute for meaningful assertions.
 - Do not prepare a commit or release with red relevant fast tests, contract tests, security checks, coverage gates, or delivery gates.
 
+## Persistent state and migrations
+
+- Before implementing a feature that changes persistent domain objects, determine the complete state model: allowed and forbidden starting states, preconditions, target state, side effects, error states, retry or repetition behavior, and relevant concurrency conflicts.
+- Do not expose unrestricted generic setters for status changes governed by domain transition rules. Encapsulate allowed transitions in the domain model or one clearly responsible application service and cover positive, negative, and failure cases.
+- Before a database change that can encounter existing data, document the old and new schema, transformation rules, known existing-data variants, integrity conditions, transaction boundary, resumability, and rollback limits.
+- Such a database change requires at least a fresh-install test, an upgrade test from the relevant previous version with synthetic existing data, domain data- and relationship-integrity checks, handling of invalid or contradictory legacy data, and an application test on the migrated schema.
+- Never modify a published migration after the fact. Correct it with a new migration.
+
 ## DDEV, Nextcloud, and hosting safety
 
 - Prefer local PHP/Node checks and batch DDEV checks. Control the shared DDEV project only from its documented `nextcloud-dev` root when that separate Parent workspace is actually available.

.github/workflows/tests.yml

@@ -46,11 +46,24 @@ jobs:
         uses: shivammathur/setup-php@v2
         with:
           php-version: ${{ matrix.php-version }}
-          coverage: none
+          coverage: ${{ matrix.php-version == '8.3' && 'xdebug' || 'none' }}
           tools: none
       - name: PHP-Tests
+        if: matrix.php-version == '8.5'
         working-directory: app
         run: php tests/run.php
+      - name: PHP-Coverage-Tooling installieren
+        if: matrix.php-version == '8.3'
+        run: composer install --working-dir=localbase/tests/coverage --no-interaction --no-progress --prefer-dist
+      - name: PHP-Coverage
+        if: matrix.php-version == '8.3'
+        working-directory: app
+        run: |
+          mkdir -p "$RUNNER_TEMP/php-coverage"
+          PHP_COVERAGE_COMMAND="$GITHUB_WORKSPACE/localbase/tests/coverage/vendor/bin/phpcov" \
+          PHP_COVERAGE_OUTPUT_DIR="$RUNNER_TEMP/php-coverage" \
+          php tests/run.php
+          php "$GITHUB_WORKSPACE/localbase/tests/coverage/merge-clover.php" adroom "$RUNNER_TEMP/php-coverage" 44.05
 
   javascript:
     name: JavaScript
@@ -82,6 +95,14 @@ jobs:
         with:
           node-version: 24
           package-manager-cache: false
-      - name: JavaScript-Tests
+      - name: JavaScript-Coverage-Tooling installieren
+        run: npm ci --prefix localbase/tests/coverage --ignore-scripts
+      - name: JavaScript-Tests mit Coverage
         working-directory: app
-        run: node tests/run-js.mjs
+        run: |
+          ../localbase/tests/coverage/node_modules/.bin/c8 \
+            --all \
+            '--include=js/**/*.js' \
+            --check-coverage \
+            --lines=25.03 \
+            node tests/run-js.mjs

AGENTS.md

@@ -24,14 +24,16 @@ Die priorisierte Produktplanung und offene Entscheidungen stehen in `ROADMAP.md`
 - Alle angemeldeten Nutzer*innen duerfen Raeume und Buchungen lesen sowie eigene Buchungen anlegen, bearbeiten, in andere Raeume verschieben und loeschen.
 - Nextcloud-Admins duerfen alle Buchungen und die Raumliste verwalten.
 - Raumloeschungen loeschen die zugehoerigen Buchungen. Die UI muss diese Auswirkung vor der Aktion deutlich bestaetigen.
-- Samstage, Sonntage und gesetzliche Feiertage in Berlin werden in der Monatsansicht textlich und optisch gekennzeichnet.
+- Samstage, Sonntage und die gesetzlichen Feiertage der zentral in LocalBase konfigurierten Organisationsregion werden in der Monatsansicht textlich und optisch gekennzeichnet. Ohne abweichende Administration gilt Berlin.
+- Buchungszeiten und Monatsgrenzen verwenden die zentral konfigurierte fachliche Organisationszeitzone. Persönliche Nextcloud-Zeitzonen verändern nur die individuelle Anzeige, nicht den fachlichen Buchungskontext.
 - Der WordPress-Raumplaner ist nur fachliche Referenz. WordPress-IDs, Capabilities, Nonces, Shortcodes und Tabellen werden nicht uebernommen.
 - WordPress-Bestandsdaten werden nicht importiert. Der app-eigene Adminabschnitt installiert neutrale Räume und Buchungen ausschließlich als manuell bestätigten synthetischen Demo-Pack.
 - Beispielbuchungen gehören einem explizit registrierten lokalen Demokonto; ein vorhandenes fremdes oder LDAP-verwaltetes Konto wird niemals dafür wiederverwendet.
 
 ## Architektur und Sicherheit
 
 - Controller bleiben duenn. Validierung und Kollisionspruefung liegen im `BookingService`, Rechte im `RoomAccessService`, Datenzugriff in Repositories.
+- `HolidayService` ist nur ein app-spezifischer Projektionsadapter auf den gemeinsamen, zwischengespeicherten LocalBase-Feiertagskalender; AD Raumplaner pflegt keine eigene Feiertagsquelle oder Regionstabelle.
 - Deny by default: Jede schreibende API prueft die angemeldete Person und die Zielbuchung serverseitig.
 - Der Browser uebermittelt bei eigenen Buchungen keine vertrauenswuerdige Besitzer-UID; der Server setzt die UID aus der Session.
 - GET-Routen sind CSRF-frei, schreibende Routen behalten den Nextcloud-CSRF-Schutz.

README.md

@@ -17,6 +17,8 @@ AD Raumplaner funktioniert einzeln; Buchungen bleiben ohne Kalender oder Assiste
 
 Räume werden nach der Aktivierung im eigenen Nextcloud-Adminabschnitt `AD Raumplaner` eingerichtet. `adroom:demo:seed` ist ausschließlich für synthetische Testdaten bestimmt.
 
+Feiertage, Buchungszeiten und Monatsgrenzen richten sich nach dem gemeinsamen Kalenderkontext der AD-Suite. Land, Region und fachliche Zeitzone werden zentral durch die Administration gepflegt; ohne Änderung gilt Deutschland/Berlin.
+
 ## Roadmap
 
 Geplante Erweiterungen und offene Produktentscheidungen stehen in der [Roadmap](ROADMAP.md).

ROADMAP.md

@@ -5,7 +5,7 @@ Diese Datei bündelt geplante Erweiterungen und offene Produktentscheidungen. Ve
 ## Aktueller Fokus
 
 - Monatsansicht, Kollisionsschutz, eigene Buchungsrechte und administrative Raumverwaltung auf einem realitätsnahen Staging fachlich abnehmen.
-- Löschbestätigung, Zeitraster, Wochenenden und Berliner Feiertage sichtbar und barrierefrei prüfen.
+- Löschbestätigung, Zeitraster, Wochenenden und die Feiertage der administrativ gewählten Organisationsregion sichtbar und barrierefrei prüfen.
 
 ## Geplante Erweiterungen
 

appinfo/info.xml

@@ -5,7 +5,7 @@
     <name>AD Raumplaner</name>
     <summary>Monatliche Raumbelegung und kollisionsfreie Raumbuchungen.</summary>
     <description>Verwaltet Räume und eigene beziehungsweise administrative Buchungen in einer kompakten Monatsmatrix.</description>
-    <version>0.9.0-rc.3</version>
+    <version>0.10.0-rc.1</version>
     <licence>agpl</licence>
     <author>Simon</author>
     <website>https://github.com/Filzmann/ad-suite</website>

lib/Service/BookingService.php

@@ -10,6 +10,7 @@
 use OCA\AdRoom\Model\Booking;
 use OCA\AdRoom\Model\Room;
 use OCA\AdRoom\Repository\BookingRepository;
+use OCA\LocalBase\Calendar\CalendarContextSettingsService;
 use OCP\IUserManager;
 
 /**
@@ -25,8 +26,9 @@ public function __construct(
         private RoomService $rooms,
         private IUserManager $users,
         private HolidayService $holidays,
+        CalendarContextSettingsService $contexts,
     ) {
-        $this->localTimezone = new DateTimeZone('Europe/Berlin');
+        $this->localTimezone = $contexts->context()->timezone();
         $this->utc = new DateTimeZone('UTC');
     }
 

lib/Service/HolidayService.php

@@ -5,27 +5,50 @@
 namespace OCA\AdRoom\Service;
 
 use DateTimeImmutable;
-use DateTimeZone;
+use OCA\LocalBase\Calendar\HolidayCalendarService as SharedHolidayCalendarService;
 
-/** Zweck: Liefert die fuer Berlin geltenden Feiertage ohne externen Laufzeitdienst. */
+/** Zweck: Projiziert die gemeinsamen regionalen Feiertage auf den angefragten Monat. */
 final class HolidayService {
+    public function __construct(private SharedHolidayCalendarService $calendars) {}
+
     /** @return array<string,string> */
     public function forMonth(int $year, int $month): array {
-        $tz = new DateTimeZone('Europe/Berlin');
-        $easter = (new DateTimeImmutable(sprintf('%04d-03-21',$year),$tz))->modify('+' . easter_days($year) . ' days');
-        $dates = [
-            sprintf('%04d-01-01',$year)=>'Neujahr',
-            sprintf('%04d-03-08',$year)=>'Internationaler Frauentag',
-            $easter->modify('-2 days')->format('Y-m-d')=>'Karfreitag',
-            $easter->modify('+1 day')->format('Y-m-d')=>'Ostermontag',
-            sprintf('%04d-05-01',$year)=>'Tag der Arbeit',
-            $easter->modify('+39 days')->format('Y-m-d')=>'Christi Himmelfahrt',
-            $easter->modify('+50 days')->format('Y-m-d')=>'Pfingstmontag',
-            sprintf('%04d-10-03',$year)=>'Tag der Deutschen Einheit',
-            sprintf('%04d-12-25',$year)=>'1. Weihnachtstag',
-            sprintf('%04d-12-26',$year)=>'2. Weihnachtstag',
-        ];
-        return array_filter($dates,static fn(string $name,string $date): bool => (int)substr($date,5,2)===$month,ARRAY_FILTER_USE_BOTH);
+        if ($month < 1 || $month > 12) {
+            throw new \InvalidArgumentException('Monat ist ungültig.');
+        }
+
+        $monthPrefix = sprintf('%04d-%02d-', $year, $month);
+        $dates = [];
+        foreach ($this->calendars->forYear($year)->toArray()['publicHolidays'] ?? [] as $period) {
+            if (!is_array($period)) {
+                continue;
+            }
+
+            $name = trim((string)($period['name'] ?? ''));
+            $start = $this->parseDate($period['startDate'] ?? null);
+            $end = $this->parseDate($period['endDate'] ?? null);
+            if ($name === '' || $start === null || $end === null || $end < $start) {
+                continue;
+            }
+
+            for ($date = $start; $date <= $end; $date = $date->modify('+1 day')) {
+                $key = $date->format('Y-m-d');
+                if (str_starts_with($key, $monthPrefix)) {
+                    $dates[$key] = $name;
+                }
+            }
+        }
+
+        ksort($dates);
+        return $dates;
     }
-}
 
+    private function parseDate(mixed $value): ?DateTimeImmutable {
+        if (!is_string($value)) {
+            return null;
+        }
+
+        $date = DateTimeImmutable::createFromFormat('!Y-m-d', $value);
+        return $date !== false && $date->format('Y-m-d') === $value ? $date : null;
+    }
+}

lib/Service/RoomDemoPackService.php

@@ -5,13 +5,18 @@
 namespace OCA\AdRoom\Service;
 
 use DateTimeImmutable;
-use DateTimeZone;
 use OCA\AdRoom\Exception\BookingConflictException;
+use OCA\LocalBase\Calendar\CalendarContextSettingsService;
 use OCA\LocalBase\Service\DemoAccountProvisioningService;
 
 /** Zweck: Installiert neutrale Räume und Beispielbuchungen unter einem registrierten lokalen Demokonto. */
 final class RoomDemoPackService {
-    public function __construct(private DemoAccountProvisioningService $accounts, private RoomService $rooms, private BookingService $bookings) {}
+    public function __construct(
+        private DemoAccountProvisioningService $accounts,
+        private RoomService $rooms,
+        private BookingService $bookings,
+        private CalendarContextSettingsService $contexts,
+    ) {}
 
     /** @return array{accounts:array,rooms:int,createdBookings:int,skippedBookings:int} */
     public function install(): array {
@@ -29,7 +34,7 @@ public function install(): array {
             if (!isset($existing[$definition['name']])) $existing[$definition['name']] = $this->rooms->save(null, $definition['name'], $definition['description'], $definition['sortOrder']);
         }
 
-        $day = new DateTimeImmutable('next monday', new DateTimeZone('Europe/Berlin'));
+        $day = new DateTimeImmutable('next monday', $this->contexts->context()->timezone());
         $samples = [
             ['Besprechungsraum Nord', '10:00', '11:00', 'AT', 'ASN Team A'],
             ['Besprechungsraum Süd', '12:00', '13:30', 'Sitzung', 'Büroteam Süd'],