# UpdateCompanyHoliday

## Permission Scope

`holidayCalendar`

## Overview

Corrects a previously registered holiday's `name` or `holidayKind` in place. Because `CompanyHoliday` is a plain dated fact rather than an effective-dated series, a correction edits the existing record directly instead of closing a generation and inserting a new one.

## Business Rules

- The correction edits the existing `CompanyHoliday` fact in place; it never creates a new generation (the model is not effective-dated)
- `holidayKind`, if changed, must remain one of `STATUTORY` / `PRESCRIBED`; any other value is rejected
- If `holidayDate` is changed, the new date must still be unique **within the holiday's calendar** (`(calendarId, holidayDate)`); the collision check is scoped to that calendar, so a date already used in a different calendar is not a conflict
- `name` is a display label only and carries no calculation semantics; changing it has no effect on holiday classification or premium determination, which bind to `holidayKind`

## Process Flow

```mermaid
flowchart TD
    A[Receive holiday id and corrected fields] --> B{Holiday exists?}
    B -- No --> C[Reject: HOLIDAY_NOT_FOUND]
    B -- Yes --> D{holidayKind provided and valid?}
    D -- No --> E[Reject: INVALID_HOLIDAY_KIND]
    D -- Yes --> F{holidayDate changed and now duplicate within the holiday's calendar?}
    F -- Yes --> G[Reject: DUPLICATE_HOLIDAY_DATE]
    F -- No --> H[Edit CompanyHoliday fact in place]
    H --> I[Scheduling and calculation read the corrected fact]
```

## External Dependencies

- [time-tracking::CompanyHoliday](../model/CompanyHoliday.md) model — the entity this command mutates

## Error Scenarios

- **HOLIDAY_NOT_FOUND**: no `CompanyHoliday` exists for the given id
- **INVALID_HOLIDAY_KIND**: `holidayKind` is not one of `STATUTORY` / `PRESCRIBED`
- **DUPLICATE_HOLIDAY_DATE**: a holiday is already registered for the given holidayDate within the same calendar

## Test Cases

- correcting a holiday edits the fact in place rather than creating a new generation
- `holidayKind` accepts only `STATUTORY` / `PRESCRIBED` on update (rejects unknown values)
- calculation resolves holiday treatment via the corrected `holidayKind`, not via `name`
- updating a non-existent holiday id is rejected
- rejects a `holidayDate` change that collides with another holiday registered in the same calendar
- a `holidayDate` change to a date used only in a different calendar is accepted