76 lines
4.0 KiB
Markdown
76 lines
4.0 KiB
Markdown
---
|
|
agent: agent
|
|
description: Split Date Wizard JSON persistence into a fixed config directory, store complete structured bookings, and skip the name step when no names are configured.
|
|
---
|
|
|
|
Implement or review the Date Wizard configuration and booking persistence layout. Preserve the existing Go server, authenticated admin behavior, public booking flow, German user-facing language, and Docker deployment conventions.
|
|
|
|
## Fixed config directory
|
|
|
|
All JSON data files belong under one project config directory:
|
|
|
|
- `config/appsettings.json`: admin password and optional configured names.
|
|
- `config/activities.json`: activity definitions.
|
|
- `config/dates_available.json`: available date definitions.
|
|
- `config/dates_booked.json`: structured booking records.
|
|
|
|
The application must use these fixed paths and must not require one environment variable per JSON file. Do not add or retain `ACTIVITIES_FILE`, `AVAILABLE_DATES_FILE`, or `BOOKED_DATES_FILE` configuration requirements. The runtime paths should resolve to `/app/config/...` in the container and `config/...` during local execution.
|
|
|
|
Keep legacy read compatibility where practical for existing deployments, but new writes must use the new fixed files and names. The old root-level JSON files should not remain as the active project data source.
|
|
|
|
## Docker Compose deployment
|
|
|
|
The Compose deployment must expose one persistent volume only:
|
|
|
|
```yaml
|
|
volumes:
|
|
- /docker/data/date:/app/config
|
|
```
|
|
|
|
The container must not require individual file mounts or data-file environment variables. Startup must provision missing files from image defaults when the mounted config directory is empty. Preserve the existing `.env` usage for server and SMTP settings.
|
|
|
|
The Dockerfile must include the config templates in the image, and the startup script must initialize the four files beneath `/app/config` without overwriting existing host data.
|
|
|
|
Document the host initialization and migration process, including migration from the old `booked_dates.json` format.
|
|
|
|
## Structured booking records
|
|
|
|
When a booking is submitted, record one object per booked date in `config/dates_booked.json` with:
|
|
|
|
- `bookedAt`: UTC booking timestamp in a machine-readable format.
|
|
- `date`: the selected date.
|
|
- `dateType`: the selected date duration/type.
|
|
- `name`: the selected person name, or empty when the name step was skipped.
|
|
- `activities`: every selected activity with its `name`, `icon`, and `type`.
|
|
|
|
Do not persist `customDescription` in the booked activity records. Custom descriptions may remain transient in the submission payload and may still be used for the notification email and generated iCalendar content.
|
|
|
|
Avoid duplicate booking records for the same date. Existing date-only booked-date consumers may continue receiving a list of date strings through the public API. Preserve booked-date protection in the admin date editor.
|
|
|
|
## Name page shortcut
|
|
|
|
When `appsettings.json` contains an empty `names` array:
|
|
|
|
- Skip the name-selection page entirely after activity selection.
|
|
- Store an empty selected name and navigate directly to checkout.
|
|
- Checkout must accept an empty name and display a clear fallback such as `Nicht angegeben`.
|
|
|
|
When names are configured, preserve the existing name-selection page and selection behavior.
|
|
|
|
## Validation
|
|
|
|
Before editing, inspect the current settings model, file paths, booking submission payload, name-page navigation, Dockerfile, Compose file, startup script, and existing prompt conventions.
|
|
|
|
After editing:
|
|
|
|
1. Run `gofmt` on changed Go files.
|
|
2. Run the available Go test/build command.
|
|
3. Run JavaScript syntax checks for changed frontend scripts.
|
|
4. Validate all config JSON files.
|
|
5. Check diagnostics and whitespace errors.
|
|
6. Smoke-test the public settings and booked-date APIs with the fixed local config paths.
|
|
7. Verify that Compose has one config-directory volume and no per-file data environment variables.
|
|
8. Do not overwrite user-edited config data or unrelated fixtures.
|
|
|
|
When reporting the result, summarize the fixed paths, Docker contract, booking JSON shape, name-page behavior, migration compatibility, and validation results.
|