# UpdateHolidayCalendar

## Permission Scope

`holidayCalendar`

## Overview

Corrects a holiday calendar's `key` or `name` in place. Because HolidayCalendar is master data 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 `HolidayCalendar` record in place; it never creates a new generation (the model is not effective-dated)
- If `key` is changed, the new `key` must remain unique across all calendars; a value already used by another calendar is rejected
- `name` is a human-facing label only; changing it has no effect on holiday scoping or classification
- The correction never re-scopes the `CompanyHoliday` entries or `WorkRule` references already pointing at this calendar — they continue to resolve by the calendar's id

## Process Flow

```mermaid
flowchart TD
    A[Receive calendar id and corrected key/name] --> B{Calendar exists?}
    B -- No --> C[Reject: HOLIDAY_CALENDAR_NOT_FOUND]
    B -- Yes --> D{key changed and now used by another calendar?}
    D -- Yes --> E[Reject: DUPLICATE_CALENDAR_KEY]
    D -- No --> F[Edit HolidayCalendar record in place]
    F --> G[Existing CompanyHoliday / WorkRule references resolve unchanged by id]
```

## External Dependencies

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

## Error Scenarios

- **HOLIDAY_CALENDAR_NOT_FOUND**: no HolidayCalendar exists for the given id
- **DUPLICATE_CALENDAR_KEY**: a calendar is already registered with the given key

## Test Cases

- correcting a calendar edits the record in place rather than creating a new generation
- updating a non-existent calendar id is rejected
- rejects a `key` change that collides with another calendar's `key`
- renaming `name` leaves existing `CompanyHoliday` and `WorkRule` references intact