# GovOPlaN Scheduling

GovOPlaN Scheduling owns meeting scheduling and `Terminfindung`: finding
suitable times across people, resources, calendars, constraints, and scheduling
polls.

This repository is currently a tag-only scaffold. It should gain package
metadata, a backend manifest, and a WebUI package together when the first
implementation slice is designed.

The core boundary decision register is in
`/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.

## Scope

Scheduling owns:

- meeting scheduling polls and proposals
- participant availability collection
- time-window and resource constraints
- candidate-slot ranking and conflict explanation
- scheduling state, reminders, and decision handoff
- optional links to external calendar/groupware systems through capabilities
- organizer permissions and poll administration semantics

Scheduling does not own:

- calendar primitives such as events, recurrence, availability storage, resources, and calendar adapters; those belong in `govoplan-calendar`
- fixed-slot public or internal appointment booking; that belongs in `govoplan-appointments`
- tasks, case work, approvals, and generic workflow state; those belong in `govoplan-tasks`, `govoplan-cases`, and `govoplan-workflow`
- mail delivery or notifications; those belong in `govoplan-mail` and `govoplan-notifications`

## Poll Audience Decision

Scheduling polls should support both internal and external/public
participation, but the first implementation may start internal-only.

- Internal polls use Access/IDM identities, groups, permissions, and calendar
  free/busy capability lookups.
- External/public polls use signed participation links through Portal, minimal
  participant identity, and explicit retention/privacy settings.
- Mixed polls are allowed only when the organizer has permission to invite
  external participants and the poll explains which participant data is visible.

## Privacy, Retention, And Audit

Participant availability is sensitive operational data. Scheduling must record:

- poll creator, tenant, organizer, invited participants, and access scope
- what each participant can see about other participants
- retention deadline for availability responses and poll links
- audit events for poll creation, invite send, response update, decision,
  cancellation, and handoff
- trace IDs for mail/notification/portal handoff

Availability responses should be removable or redacted after the poll decision
unless a configured process requires longer evidence retention.

## Candidate Capabilities

- `scheduling.polls`
- `scheduling.availabilityCollector`
- `scheduling.candidateSlots`
- `scheduling.decisionHandoff`
- `scheduling.portalParticipation`

## Expected Integrations

- `govoplan-calendar`: availability, calendars, resources, rooms, recurrence, Open-Xchange/calendar adapters
- `govoplan-appointments`: conversion from a selected meeting time into a booked appointment where appropriate
- `govoplan-access` and `govoplan-idm`: participants, groups, directory lookup, permissions
- `govoplan-mail` and `govoplan-notifications`: invitations, reminders, confirmations
- `govoplan-portal`: external participant scheduling flows
- `govoplan-workflow` and `govoplan-tasks`: follow-up work after a time is selected

## First Package Scaffold Decision

The first scaffold should include both backend and WebUI package metadata once
implementation starts:

- backend manifest, permissions, DTOs, and APIs for internal polls
- WebUI route contribution for poll creation and response collection
- capability contracts for calendar free/busy, access/IDM lookup,
  mail/notification sending, portal participation links, appointment handoff,
  and workflow/task follow-up

The active backlog lives in Gitea issues.