Add the in-app update concept for 1.50

Captures the agreed design so it can be handed over later: extended
update feed with per-artifact metadata, a build-time package-type
marker, a testable check service replacing the blocking call in the
ChatController constructor, a non-modal hint suppressed while connected
to ON4KST, verified downloads and platform-specific execution.

Concept only, nothing implemented yet. Line anchors were verified
against this branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HT8R7zTMoQnmJj6dGbaqqf

.agents/skills/kst4contest-change/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: kst4contest-change
+description: Analyze or implement KST4Contest Java/JavaFX changes, bug fixes, refactorings, protocol handling, contest workflow behaviour, callsign/band logic, AirScout/logging/rotor/DXCluster integrations, threading and state management. Use current code as source of truth and follow the mandatory concept-and-question gate before edits.
+---
+
+# KST4Contest change workflow
+
+Read the relevant reference files before proposing a concept.
+
+## Phase 1: read-only analysis
+
+- Inspect the current code and tests.
+- Identify the current data flow and thread ownership.
+- Identify user-visible and protocol-visible behaviour.
+- Check relevant `docs/PROJECT_CONTEXT.md` sections when they exist.
+- Check whether the task overlaps a known invariant in the references.
+- Do not modify files.
+
+## Phase 2: report understanding in German
+
+Explain:
+
+- what Marc wants changed;
+- what must remain unchanged;
+- which components appear affected;
+- what evidence in the current code supports that understanding;
+- any conflict between current code and historical project context.
+
+Never resolve a conflict by guessing.
+
+## Phase 3: questions and final concept in German
+
+Before finalizing the concept:
+
+- identify all material implementation choices;
+- ask Marc questions that are not already answered by code, project instructions or prior confirmed decisions;
+- wait for answers when needed.
+
+Then present:
+
+- intended data/control flow;
+- exact behavioural changes;
+- compatibility impact;
+- thread/UI impact;
+- persistence impact;
+- test strategy;
+- likely documentation impact;
+- likely durable project-context impact;
+- related-project impact when relevant.
+
+Ask for explicit concept approval and wait before editing.
+
+## Phase 4: implementation
+
+After approval:
+
+- implement the smallest coherent change;
+- preserve unrelated behaviour;
+- keep comments/Javadoc in English;
+- add/update focused tests;
+- keep external protocol parsing defensive;
+- avoid hidden defaulting for unknown values.
+
+## Phase 5: verification and documentation impact
+
+Run focused checks, then appropriate broader checks.
+
+Because KST4Contest build configuration may ignore failures/findings, inspect summaries and reports rather than only command exit status.
+
+Then use `$software-project-context`:
+
+- do a low-cost documentation-impact classification;
+- inspect only likely affected manual/README/website sections;
+- update targeted documentation when clearly required by the approved implementation;
+- update `docs/PROJECT_CONTEXT.md` for significant durable technical decisions/state changes;
+- do not perform a full manual audit unless there is a specific trigger.
+
+## Phase 6: report
+
+Report in German:
+
+- files changed;
+- implementation summary;
+- tests/checks;
+- warnings/findings;
+- documentation-impact result;
+- documentation/context updates or why none were required;
+- related-project impact when relevant;
+- unresolved issues;
+- no Git publication action unless explicitly requested.

.agents/skills/kst4contest-change/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "KST4Contest Change"
+  short_description: "Plan and implement KST4Contest changes safely"
+  default_prompt: "Analyze the requested KST4Contest change, explain your understanding and concept in German, ask implementation questions, and wait for approval before editing."
+
+policy:
+  allow_implicit_invocation: true

.agents/skills/kst4contest-change/references/architecture.md

@@ -0,0 +1,102 @@
+# Architecture context
+
+## Current package shape
+
+The repository currently contains major packages under `src/main/java/kst4contest/` including:
+
+- `controller`
+- `locatorUtils`
+- `logic`
+- `model`
+- `service`
+- `test`
+- `utils`
+- `view`
+
+Do not treat package names alone as proof of clean MVC boundaries. Inspect actual dependencies.
+
+## Preferred message/member data flow
+
+The established target architecture for active chat members is:
+
+```text
+ON4KST / network
+        |
+        v
+MessageBusManagementThread
+        |
+        v
+ChatController
+        |
+        v
+thread-safe active-member domain state
+(ConcurrentMap; identity includes callsign + category)
+        |
+        v
+JavaFX ObservableList UI mirror
+        |
+        v
+FilteredList / SortedList / TableView / selection
+```
+
+Key rule:
+
+`ObservableList` is a JavaFX UI projection, not the canonical store for worker-thread logic.
+
+`MessageBusManagementThread` must not directly read or modify the UI list.
+
+## JavaFX boundary
+
+UI-visible mutations belong on the JavaFX Application Thread.
+
+Prefer controller-owned helpers such as an existing `runOnFxThread` abstraction when available; otherwise use `Platform.runLater` consistently.
+
+Do not move business/data access into the FX thread merely to silence a threading problem.
+
+## Parser/service separation
+
+For protocol receivers, the preferred direction is:
+
+```text
+Receiver (I/O only)
+    -> Parser (wire data -> DTO)
+    -> Service (domain/persistence logic)
+    -> Controller (UI coordination)
+    -> Observable UI model
+    -> View
+```
+
+A previous concrete example for UCXLog was:
+
+```text
+UcxUdpReceiver
+    -> UcxPacketParser
+    -> DTO
+    -> UcxLogService
+    -> ChatController
+    -> UI projection
+```
+
+This is architectural guidance, not permission for a broad refactor. Apply only when it is in scope and approved.
+
+## DTO preference
+
+Prefer explicit DTO classes over records when introducing protocol/transport data structures in this project, unless the approved concept intentionally changes that convention.
+
+## Null safety
+
+Chat members can be incomplete, especially:
+
+- fallback members;
+- historic message senders;
+- server-derived partial members.
+
+Values such as QRB and QTF can be absent.
+
+Rules:
+
+- absence stays absence;
+- do not map `null` to numeric zero;
+- UI must render unavailable state safely;
+- sorting/filtering/calculation code must tolerate missing values;
+- unexpected missing values must not terminate worker or UI threads.

.agents/skills/kst4contest-change/references/automation-and-messaging.md

@@ -0,0 +1,42 @@
+# Automated messaging, beacons and skeds
+
+## General
+
+Automated replies/beacons must be conservative because they interact with the live ON4KST service.
+
+## Established safety behaviour
+
+Historical confirmed rules include:
+
+- beacon/autoanswer scheduling shares controlled timing rather than spawning uncontrolled independent timers;
+- minimum interval has been tightened to avoid spam;
+- automated text length is bounded;
+- invalid or incomplete replies are rejected before transmission;
+- a cooldown is not consumed unless a complete valid reply enters the TX queue;
+- QRG/frequency requests take precedence where the current implementation defines that;
+- automated-message markers are ignored to prevent response loops.
+
+Recent logic used a two-minute cooldown keyed by complete callsign plus chat category and ignored the project's own automated-message marker.
+
+Treat exact marker strings and timing constants as current-code facts to verify, not values to recreate from memory.
+
+## Monitoring
+
+Station monitoring is intentionally base-call-wide:
+
+Entering a variant such as:
+
+```text
+DN9APW-2
+DN9APW-70
+```
+
+monitors:
+
+```text
+DN9APW
+```
+
+This reduces manual configuration for sked monitoring.
+
+Keep this separate from chat-member identity, which may require full suffix + category.

.agents/skills/kst4contest-change/references/domain-and-callsigns.md

@@ -0,0 +1,87 @@
+# Domain, callsigns and bands
+
+## Chat-member identity
+
+Full callsign variants can be distinct chat identities.
+
+Examples:
+
+```text
+DN9APW
+DN9APW-2
+DN9APW-70
+```
+
+Do not globally strip suffixes when identifying chat members.
+
+Category is also part of identity. A practical key is conceptually equivalent to:
+
+```text
+FULL_CALLSIGN|CATEGORY
+```
+
+Do not allow messages from one category to attach to a same-looking member in another category.
+
+## Base-call operations
+
+Some features intentionally operate on the base callsign.
+
+Confirmed examples:
+
+### Worked state
+
+Worked status is shared across suffix variants of the same base call.
+
+If the base station has been worked on the relevant basis, variants such as `CALL-2`, `CALL-70`, `CALL-144`, `CALL-432` should not become independent worked identities merely because of the suffix.
+
+### Monitoring
+
+Monitoring a station entered as `DN9APW-2` or `DN9APW-70` should monitor the base call `DN9APW`.
+
+This is intentional: a user monitoring another station's skeds should not have to create one monitor entry per SSID.
+
+Do not extend base-call matching to unrelated features without approval.
+
+## Suffix semantics
+
+Do not assume a suffix always means a band or category.
+
+Historical examples have shown the same base calls with different suffix conventions in different chat categories.
+
+Therefore:
+
+- preserve exact full-call identity where needed;
+- normalize only for explicitly approved base-call features;
+- never infer missing band/category semantics from the suffix alone.
+
+## Categories
+
+KST4Contest's central VHF/UHF usage focuses on ON4KST categories 2 and 3.
+
+However, other categories can occur.
+
+Rules:
+
+- unsupported/uninteresting categories must be ignored or handled safely;
+- they must not produce index, switch or null errors;
+- do not let their values contaminate category-2/category-3 band logic.
+
+## Band availability
+
+Band activity can be derived from several signals including name/text parsing and explicit/manual information.
+
+Confirmed invariant:
+
+`NOT-QRV` overrides positive availability indications.
+
+Known-active-band and `B+` handling should use one consistent interpretation across the program.
+
+Do not implement separate slightly different parsers in multiple UI/features if a shared existing mechanism is available.
+
+## Current QRG
+
+Features that depend on propagation/band/frequency should use the current relevant QRG or the approved band calculation.
+
+Never silently reintroduce a universal hardcoded 144 MHz fallback.
+
+When a frequency is ambiguous and no approved fallback exists, ask rather than guessing.

.agents/skills/kst4contest-change/references/known-edge-cases.md

@@ -0,0 +1,115 @@
+# Known edge cases and regression patterns
+
+This file is a regression-awareness list. Reproduce/inspect current code before deciding a historical bug still exists.
+
+## Incomplete ChatMember
+
+Known failure pattern:
+
+```text
+Cannot invoke "java.lang.Double.intValue()" because
+ChatMember.getQrb() is null
+```
+
+Lesson:
+
+- QRB can be absent;
+- UI/calculation code must not blindly unbox/convert;
+- unavailable is not zero.
+
+Apply the same reasoning to QTF and other server/fallback-derived fields.
+
+## Callsign suffix collisions
+
+A historical issue caused messages/identity problems between:
+
+```text
+DN9APW
+DN9APW-2
+```
+
+The corrective model is not "strip all suffixes".
+
+Instead:
+
+- keep full-call chat identities distinct;
+- include category;
+- use base call only for explicitly base-call-wide features such as worked state/monitoring.
+
+## Unsupported chat categories
+
+The ON4KST ecosystem can expose categories outside the two central ones.
+
+A parser/switch/filter must not throw because the category is irrelevant to KST4Contest.
+
+Safe ignore/fallback beats fake band assignment.
+
+## AirScout higher-band queries
+
+A historical observation showed aircraft visible in AirScout while API results for a 432 MHz case were empty.
+
+Potential causes included frequency-string formatting.
+
+Lesson:
+
+- verify the exact upstream contract;
+- compare request produced by KST4Contest with a known-working request;
+- do not "fix" by guessing a string format or falling back to an unrelated band.
+
+## Second airplane-scatter result / missing aircraft
+
+A known UI failure involved missing/partial airplane-scatter data and a `TextInputControl` range error (`start must be <= end`).
+
+Lesson:
+
+- empty/partial AP results must be validated before text-range highlighting/selection;
+- second-result paths need the same null/range checks as primary results.
+
+## Historic/unknown user message
+
+A user/message record can refer to a callsign not present in the current member list.
+
+Do not require current login membership to render or classify historic messages.
+
+## UM3-style handling
+
+Historical message handling included cases that should be ignored safely if the user is not in the chat/member state.
+
+Lesson:
+
+- external message types must tolerate missing member references.
+
+## CR/LF and disconnect suspicion
+
+Do not treat line endings as harmless text formatting in socket code.
+
+When diagnosing a disconnect:
+
+- inspect transmitted bytes;
+- inspect server response/EOF;
+- compare Windows versions only after proving the application sends different bytes;
+- avoid duplicated LF/CRLF terminators.
+
+## Filter reset
+
+A reset button that clears control values but leaves predicates active is not a valid reset.
+
+Verify final predicate composition, not only UI state.
+
+## Map render flicker
+
+Leaflet/WebView render fragmentation under Java 21 was mitigated by:
+
+```text
+window.L_DISABLE_3D = true
+```
+
+before Leaflet load.
+
+Do not remove as "obsolete CSS cleanup" without a visual regression check.
+
+## Network start/reconnect loop
+
+Initial connection failure must not spin indefinitely or block controlled recovery.
+
+Connection state must be based on actual I/O lifecycle rather than only `Socket.isConnected()`-style historical state.

.agents/skills/kst4contest-change/references/project-behavior-catalog.md

@@ -0,0 +1,183 @@
+# Project behaviour catalog
+
+This catalog summarizes behaviour established during prior KST4Contest work. It is context for analysis, not permission to overwrite newer code. Always inspect the current implementation before modifying a listed area.
+
+## Core purpose
+
+KST4Contest is an ON4KST-oriented desktop client optimized for VHF/UHF/microwave contest workflows.
+
+Core areas developed over time include:
+
+- simultaneous ON4KST chat handling;
+- priority candidates;
+- sked workflow and timeline;
+- worked-state synchronization;
+- logging integrations;
+- DXCluster;
+- AirScout / airplane-scatter assistance;
+- rotor/control integrations;
+- map/path visualization;
+- automated replies/beacons;
+- user filtering and reachability;
+- documentation and website/update-feed integration.
+
+## Two chat categories
+
+The application is designed around two simultaneous relevant chat categories in normal operation.
+
+Important consequences:
+
+- same-looking calls in different categories are not automatically the same chat identity;
+- category is part of message/member identity;
+- category-specific QRG/band settings must not leak into the other category;
+- unsupported categories must not crash shared logic.
+
+## Priority candidates
+
+Priority scoring has included factors such as:
+
+- QTF match;
+- recent activity;
+- message count;
+- positive signal indications;
+- sked rate.
+
+Do not change weighting/meaning as collateral work. Treat it as user-facing contest logic.
+
+## Timeline / skeds
+
+The sked timeline has used 30-minute lanes and visualized airplane-scatter probability windows.
+
+Known historical AP strength levels:
+
+- 100%;
+- 75%;
+- 50%.
+
+Sked reminder presets have covered short contest-relevant lead times.
+
+Do not hardcode historical display constants into new code without verifying the current view/model.
+
+## Worked state
+
+Worked state is loaded from persistence and updated live from supported logging inputs.
+
+The simplified UI meaning has been "worked any" where the locator/worked indicator is concerned.
+
+Worked state is base-call-wide across suffix variants where established.
+
+When changing persistence or logging synchronization, verify:
+
+- startup DB load;
+- live update;
+- suffix/base-call mapping;
+- band mapping;
+- 50/70 MHz support where applicable;
+- UI projection.
+
+## Known active bands / B+
+
+Known-active-band information is derived consistently across the application from available hints.
+
+Historical work unified:
+
+- band mentions in user names;
+- band mentions in text;
+- manual/global band information;
+- `B+`-style availability.
+
+Explicit `NOT-QRV` overrides positive hints.
+
+Avoid introducing a second parser with different semantics.
+
+## Selection and send workflow
+
+Established fast-workflow behaviour includes:
+
+- selecting a new station prefills `/cq callsign`;
+- send text is geared toward minimal contest interaction;
+- if no target chat category is selected, Main is the established fallback.
+
+These are intentional workflow decisions, not incidental UI details.
+
+## DXCluster
+
+DXCluster support has included:
+
+- integrated display;
+- copyable lines;
+- `/cq` workflow support;
+- beacon monitoring;
+- QTF/bearing-related presentation.
+
+Preserve locator semantics and avoid sender/receiver field confusion.
+
+## Map / path view
+
+Map work has included:
+
+- Leaflet 1.9.4 in JavaFX WebView;
+- terrain/path information;
+- airplane-scatter integration;
+- target-station selection;
+- path-analysis visibility;
+- station-count/status information;
+- target reset that does not reset zoom.
+
+A persistent right-side station-information panel has been reduced/removed in favour of more compact presentation in later UI work.
+
+Before changing layout, inspect the current version because this area has been actively iterated.
+
+## Reachability and filters
+
+Filter work has separated reachability concerns from generic filters.
+
+A Reset Filter control must reset the actual filter predicates, not just visual controls.
+
+UI sorting/filtering must remain stable when backing data changes.
+
+## Autoanswer and beacons
+
+Automated messaging exists to reduce repetitive contest chat work without creating spam or feedback loops.
+
+Important principles:
+
+- conservative timing;
+- bounded text;
+- no loop on own automated markers;
+- only consume cooldown after a valid queued reply;
+- category/callsign-safe identity;
+- QRG requests handled with the intended precedence.
+
+## Connection handling
+
+Network reliability is contest-critical.
+
+Work has explicitly targeted:
+
+- accurate connected/disconnected state;
+- server disconnect detection;
+- reconnect behaviour on unstable links;
+- no infinite loop on initial connection failure;
+- visible connection-state indication in the UI.
+
+Do not regress connection state into "socket object exists therefore connected".
+
+## Historic messages
+
+Historic/non-current chat senders may not have a complete live `ChatMember`.
+
+Highlighting, display and parsing must tolerate users not currently logged in.
+
+## Website and documentation
+
+The application repository also contains:
+
+- bilingual manual content;
+- documentation images;
+- automated documentation PDF build;
+- Eleventy website;
+- download/update metadata generation;
+- release-oriented website automation.
+
+A user-visible feature change may therefore affect more than Java source.

.agents/skills/kst4contest-change/references/protocols-and-integrations.md

@@ -0,0 +1,101 @@
+# Protocols and external integrations
+
+This file records stable rules plus historical context. For exact current wire formats, ports and frequency strings, inspect the current code and authoritative upstream documentation.
+
+## ON4KST
+
+KST4Contest depends on long-lived server communication where malformed commands or framing can lead to disconnects.
+
+Rules:
+
+- preserve exact protocol framing;
+- treat CR/LF changes as protocol changes, not formatting cleanup;
+- do not append extra line terminators without verification;
+- detect actual socket/server disconnects reliably;
+- initial connection failure must not create an uncontrolled infinite loop;
+- reconnect logic must tolerate unstable Internet access;
+- the UI should make disconnected state clearly visible where implemented.
+
+If Windows-specific behaviour is suspected, do not assume Win10/Win11 line-ending semantics explain it without reproducing or tracing the bytes.
+
+## UCXLog / DXLog UDP XML
+
+`contactreplace` must be handled equivalently to `contactinfo` for whole-log broadcasts where applicable.
+
+Historical raw-packet XML start detection included:
+
+```text
+<?xml
+<contactinfo
+<contactreplace
+<RadioInfo
+```
+
+DOM handling also included a fallback to `contactreplace`.
+
+Before changing this path, inspect the current parser because the code may have been refactored since this behaviour was introduced.
+
+Preferred layering:
+
+```text
+UDP receiver -> parser -> DTO -> service/domain/DB -> controller -> UI
+```
+
+## Win-Test
+
+Historical integration uses UDP port 8721 for Win-Test information.
+
+Do not hardcode this fact into unrelated logic. Verify current configuration before changing listener setup or band mapping.
+
+Changes involving 50/70 MHz, worked state or frequency mapping must be consistent with other logging inputs.
+
+## AirScout
+
+KST4Contest integrates with AirScout path/airplane-scatter information.
+
+Stable principles:
+
+- propagation/path queries must reflect the current relevant frequency/band;
+- do not fall back to 144 MHz merely because older code did;
+- unsupported chat categories must fail safely;
+- frequency-string formatting is an external API contract and must be checked, not guessed.
+
+Historical work included a temporary 430 MHz approximation for ambiguous higher-band handling. Treat that as historical context, not a permanent invariant. Inspect the current implementation before using or changing it.
+
+## PSTRotator
+
+The integration has evolved.
+
+Historical project notes mention more than one control approach, and recent work included UDP control/feedback behaviour around a configurable control port and feedback on the next port, including SPID movement retry logic.
+
+Therefore:
+
+- inspect the current implementation before assuming TCP vs UDP;
+- inspect current settings/defaults;
+- do not copy an old port/transport assumption into new code;
+- preserve asynchronous JavaFX-safe handling;
+- preserve any verified retry sequence only if it still exists in current code/tests.
+
+If current code and historical notes conflict, ask Marc after showing the conflict.
+
+## DXCluster
+
+DXCluster is integrated into the contest workflow.
+
+Preserve:
+- copyable/usable cluster lines;
+- correct sender/receiver locator semantics;
+- safe handling of missing locator data.
+
+A historical bug copied sender and receiver locators as equal; do not reintroduce that behaviour.
+
+## Protocol-wide error handling
+
+External data is not trusted to be complete.
+
+Rules:
+
+- validate before dereferencing;
+- unknown categories/bands/tags should degrade safely;
+- malformed packets must not kill long-running receiver/management threads;
+- logging should make the rejected input diagnosable without flooding normal operation.

.agents/skills/kst4contest-change/references/roadmap.md

@@ -0,0 +1,22 @@
+# Deferred and roadmap context
+
+This file is background only. Do not implement these items merely because they are mentioned here.
+
+## Propagation model
+
+After the manual audit, Marc intends to revisit and improve KST4Contest propagation modelling.
+
+Exploration areas include:
+
+- higher-density Copernicus GLO-30 terrain sampling;
+- Fresnel-zone analysis;
+- diffraction modelling;
+- simplified ray tracing / multi-segment paths;
+- VHF/UHF/microwave contest applicability, including around 1296 MHz and above;
+- practical contest-oriented prediction rather than academic complexity for its own sake.
+
+This requires a fresh concept before implementation.
+
+## Rule
+
+Roadmap context must never silently enlarge the scope of a current task.

.agents/skills/kst4contest-change/references/settings-and-data.md

@@ -0,0 +1,80 @@
+# Settings and data context
+
+Inspect `Config`/settings classes and current UI before using these names; this list records important settings/concepts encountered during prior work.
+
+## Band / station settings
+
+Important concepts have included:
+
+- `MYQRGFirstCat`;
+- `MYQRGSecondCat`;
+- manual station band information;
+- current/actual QTF;
+- known-active bands;
+- selected/current QRG.
+
+Band-dependent features must use the correct category/station context.
+
+## Antenna / path settings
+
+Important concepts have included:
+
+- `actualQTF`;
+- `antennaBeamWidthDeg`;
+- maximum QRB;
+- AirScout/path-analysis settings.
+
+Missing QRB/QTF must remain unknown, not numeric zero.
+
+## UI settings
+
+Persisted UI behaviour has included:
+
+- dark mode;
+- map/path-analysis visibility;
+- filters/reachability controls;
+- column visibility;
+- divider/layout state where implemented.
+
+Do not reset persisted user choices as an incidental effect of a feature change.
+
+## Logging / worked persistence
+
+Worked information is persisted and updated through multiple input paths.
+
+Before changing one path, compare semantics across:
+
+- DB load on startup;
+- simple/manual log integration where present;
+- UCXLog/DXLog;
+- Win-Test;
+- other current logging inputs.
+
+The goal is one worked-state interpretation regardless of source.
+
+## Chat/message automation
+
+Configuration has included:
+
+- beacon/autoanswer enablement;
+- beacon defaults;
+- message limits/timers;
+- category-specific communication.
+
+Do not duplicate timers or create per-feature scheduling that bypasses the shared safety model.
+
+## Connection state
+
+Connection-state UI must reflect actual ON4KST connection lifecycle.
+
+Any new state enum/property should have a clear owner and thread boundary.
+
+## Persistence rule
+
+Do not change persisted keys/schema/semantics simply to make new code easier.
+
+If a schema/key migration is required:
+
+1. explain current and new format;
+2. describe backward compatibility;
+3. ask for approval before implementing.

.agents/skills/kst4contest-change/references/testing-build-release.md

@@ -0,0 +1,100 @@
+# Build, tests, static analysis and release safety
+
+## Maven
+
+Use the repository Maven wrapper.
+
+Windows:
+
+```text
+.\mvnw.cmd test
+.\mvnw.cmd package
+```
+
+Run narrower tests first when possible.
+
+## Important Surefire behaviour
+
+The project has used:
+
+```xml
+<testFailureIgnore>true</testFailureIgnore>
+```
+
+Therefore an exit code of zero is not sufficient evidence that all tests passed.
+
+Always inspect:
+
+- test counts;
+- failures;
+- errors;
+- skipped tests;
+- Surefire report output when necessary.
+
+State exact results in the completion report.
+
+## PMD and SpotBugs
+
+PMD and SpotBugs are integrated, but their findings have historically not always failed the build.
+
+Do not say "static analysis clean" unless the relevant reports/output were actually checked.
+
+## Packaging
+
+The build contains packaging/module-list consistency logic.
+
+Changes involving modules, JavaFX modules, jpackage or `module-info.java` must check:
+
+- `pom.xml`;
+- `packaging/` helpers;
+- module requirements;
+- packaging verification output.
+
+Do not manually update only one copy of a generated/synchronized module list.
+
+## Website
+
+The website is Eleventy-based and has Node tests.
+
+Inspect `website/package.json`, `website/test/` and current scripts before choosing exact commands.
+
+Historical website validation included Node tests for generated version/update information.
+
+## Documentation build
+
+GitHub Actions generates documentation/PDF and site artefacts.
+
+A local code build does not prove documentation/site CI will pass.
+
+## Versioning
+
+Do not change project version, semantic version, update feed, tag or release metadata unless explicitly requested.
+
+## Git
+
+Each of these needs separate authorization:
+
+- stage;
+- commit;
+- push;
+- PR;
+- merge;
+- tag;
+- release.
+
+When asked to commit, use a concise English commit message.
+
+Do not stage unrelated files.
+
+## Release communication
+
+When a release is explicitly in scope, check:
+
+- current changelog;
+- GitHub release/tag;
+- website download/update feed;
+- documentation;
+- HamRadioOnline download/manual destinations;
+- any SourceForge publication workflow currently used.
+
+Do not assume an older deployment pipeline is still active.

.agents/skills/kst4contest-change/references/threading-and-state.md

@@ -0,0 +1,73 @@
+# Threading and state management
+
+## Canonical state vs UI state
+
+Use a thread-safe canonical state for data consumed by worker/network threads.
+
+The active-member UI list is only a projection.
+
+Preferred conceptual model:
+
+```text
+ConcurrentMap<MemberKey, ChatMember> activeMembers
+        |
+        | FX-thread projection/update
+        v
+ObservableList<ChatMember> activeMembersUi
+```
+
+`MemberKey` semantics must preserve full callsign plus category unless the specific operation is intentionally base-call-wide.
+
+## MessageBusManagementThread
+
+Do not:
+
+- iterate JavaFX `ObservableList` from the worker thread;
+- add/remove JavaFX-list entries directly from the worker thread;
+- use the FX thread as a substitute for proper domain state ownership.
+
+Do:
+
+- pass domain events/data to the controller/service boundary;
+- modify canonical thread-safe state outside UI code as appropriate;
+- project changes to JavaFX state on the FX thread.
+
+## Controller boundary
+
+`ChatController` is the preferred coordination boundary for UI-visible state.
+
+Keep view-specific operations out of protocol receiver code.
+
+## External receiver design
+
+For receiver refactors, separate:
+
+- socket/UDP/TCP I/O;
+- parsing;
+- DTO;
+- domain/persistence;
+- UI coordination.
+
+## Error containment
+
+Long-running threads must survive:
+
+- malformed server records;
+- incomplete members;
+- unknown bands/categories;
+- missing locators;
+- null QRB/QTF;
+- temporary socket failure.
+
+Catch errors at meaningful boundaries and include enough context in English diagnostic logs/comments to trace the input and stage of failure.
+
+Do not swallow errors silently.
+
+## JavaFX selection/sorting
+
+When updating backing data:
+
+- preserve current selection where the feature expects it;
+- avoid invalidating `FilteredList`/`SortedList` assumptions;
+- do not create recursive UI updates;
+- avoid accessing control state from worker threads.

.agents/skills/kst4contest-change/references/ui-behavior.md

@@ -0,0 +1,65 @@
+# UI behaviour and workflow invariants
+
+These are known user-experience decisions. Verify the current implementation before changing them.
+
+## Selection and send text
+
+A new station selection should prefill the established command form:
+
+```text
+/cq callsign
+```
+
+This behaviour is deliberate even when prior input text existed, according to the established workflow.
+
+If no category is selected for sending, the established fallback is the Main category.
+
+Do not change either behaviour as a side effect of unrelated refactoring.
+
+## Map view
+
+Known decisions:
+
+- reset clears the target/station selection;
+- reset does not change the current zoom level;
+- selected-station information was moved toward the compact status line rather than requiring a persistent right-side detail panel;
+- path-analysis visibility is user-controllable and should not become undiscoverable;
+- map controls must remain usable in dark/light modes.
+
+## Leaflet / JavaFX WebView
+
+With Leaflet 1.9.4 under Java 21, fragmented rendering/flicker was fixed by disabling Leaflet CSS 3D transforms before Leaflet loads:
+
+```text
+window.L_DISABLE_3D = true
+```
+
+Do not remove/reorder this workaround without reproducing the rendering problem and proving the replacement.
+
+## Filters
+
+Known UI direction:
+
+- Reset Filter must actually clear relevant filter predicates;
+- reachability controls are conceptually separate from generic filter controls;
+- reset control should remain visually discoverable;
+- truncated text should remain accessible through tooltips where implemented;
+- clickable links should remain functional in both themes.
+
+## Priority / timeline
+
+The contest workflow includes:
+- priority candidate presentation;
+- sked timeline;
+- activity/AP windows;
+- sked reminders.
+
+Avoid UI changes that damage quick contest operation merely to make layout code simpler.
+
+## Null display
+
+Missing data is not `0`.
+
+For QRB/QTF/locator/derived values, follow the current UI convention for unavailable/empty state.
+
+Do not show a plausible-looking number when the model value is actually unknown.

.agents/skills/kst4contest-documentation/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: kst4contest-documentation
+description: Perform targeted KST4Contest documentation-impact checks and update affected German/English manuals, README, website feature text, changelog, release notes and durable project context. Avoid full audits by default; keep documentation aligned with implemented behaviour and use the praktimarc-writing-style skill.
+---
+
+# KST4Contest documentation workflow
+
+Use `$software-project-context` and `$praktimarc-writing-style`.
+
+## Default behaviour
+
+Do not read the complete manual or website after every code change.
+
+Start with a documentation-impact classification and search for the affected feature, setting, UI label, protocol/integration or operational concept.
+
+Escalate to a broader audit only when:
+
+- Marc explicitly requests it;
+- a major release is being prepared;
+- the change is broad across UI/workflows;
+- multiple targeted checks reveal wider drift.
+
+## Before editing documentation
+
+1. Inspect the actual implementation or approved specification.
+2. Explain in German what documentation is probably affected.
+3. Ask only unresolved behaviour/scope questions.
+4. If documentation updates are already part of an approved implementation concept, no second approval is required for obvious synchronisation.
+5. If documentation reveals a new material product decision, stop and ask Marc.
+
+## Manuals
+
+When user-facing behaviour is affected:
+
+- search English and German manual content under `github_docs/` for the relevant feature/labels first;
+- inspect surrounding sections only;
+- keep both language versions semantically equivalent;
+- do not translate mechanically; English must be idiomatic;
+- preserve exact UI labels, values, callsigns, ports and protocol terminology;
+- document current behaviour only;
+- if code and manual disagree and it is unclear which behaviour is intended, report the conflict;
+- identify outdated/missing screenshots explicitly.
+
+## README / website
+
+Check only when the changed feature, installation, configuration, capability or compatibility is represented there or should reasonably be represented there.
+
+- Keep feature descriptions concise.
+- Explain real contest/operating benefit, not marketing slogans.
+- Avoid duplicating large manual sections on the website.
+- Keep the main manual/download destinations consistent with the current site strategy.
+
+## Durable project context
+
+Update `docs/PROJECT_CONTEXT.md` for significant:
+
+- architectural decisions;
+- threading/state ownership;
+- callsign/category semantics;
+- protocol/integration contracts;
+- persistence/configuration changes;
+- durable workarounds;
+- deployment/website relationships;
+- cross-project dependencies;
+- planned propagation/API architecture when it becomes concrete.
+
+Keep current-state sections current rather than using the file as a raw changelog.
+
+## Changelog / release notes
+
+- Compact factual bullets.
+- Include user-visible changes and important reliability/compatibility fixes.
+- Do not invent version scope; derive it from actual commits/changelog/release context.
+- Keep release posts short and operationally relevant.

.agents/skills/kst4contest-documentation/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "KST4Contest Documentation"
+  short_description: "Keep KST4Contest manuals, website and release text aligned"
+  default_prompt: "Review the implemented KST4Contest behaviour, explain the documentation impact in German, propose a concept, ask questions, and wait for approval before editing."
+
+policy:
+  allow_implicit_invocation: true

.agents/skills/kst4contest-documentation/references/current-feature-context.md

@@ -0,0 +1,26 @@
+# User-facing feature context
+
+This is a documentation coverage reminder, not a canonical feature list. Verify each item in current code before documenting it.
+
+Areas repeatedly documented or changed include:
+
+- simultaneous ON4KST chat categories;
+- priority candidates;
+- sked timeline/reminders;
+- known active bands / B+ / NOT-QRV;
+- worked indicators;
+- DXCluster;
+- AirScout integration;
+- map/path analysis;
+- filtering and reachability;
+- PSTRotator/rotor integration;
+- UCXLog/DXLog and Win-Test log synchronization;
+- beacon/autoanswer behaviour;
+- connection status/reconnect behaviour;
+- dark/light UI behaviour;
+- QTF/bearing workflow;
+- download/update behaviour.
+
+When one of these changes, search both language manuals and website copy for affected references.
+
+Do not specialize documentation beyond actual behaviour. A useful example from prior work is callsign monitoring: entering an SSID-style variant can intentionally monitor the base call rather than requiring every suffix to be configured individually.

.agents/skills/kst4contest-documentation/references/manual-and-website.md

@@ -0,0 +1,47 @@
+# Manual and website context
+
+## Manual location
+
+KST4Contest documentation is maintained in `github_docs/` with English and German Markdown pages plus screenshots.
+
+The documentation build is automated through repository workflows.
+
+## Audit workflow established with Marc
+
+The normal review method is:
+
+1. compare documentation with actual code/behaviour;
+2. propose exact changes;
+3. note missing/outdated screenshots and their intended repo location;
+4. if code must change to match the manual, stop and confirm that code change first;
+5. keep German and English content aligned;
+6. prefer one thorough update over many cosmetic iterations.
+
+With Codex editing locally, the old copy/paste insertion-guide step is replaced by direct edits, but the approval logic remains.
+
+## Examples and easter eggs
+
+Deliberate examples/test strings must not be "cleaned up" merely because they are informal.
+
+A known example uses:
+
+```text
+DO5AMF
+Testing DXC-Spot: Congrats, you donated $100!
+```
+
+Preserve such deliberate easter eggs unless Marc explicitly asks to remove or replace them.
+
+## Website
+
+The website under `website/` uses Eleventy/Nunjucks.
+
+Style direction:
+
+- modern and concise;
+- technically focused;
+- no promotional tone;
+- English primary where appropriate;
+- documentation remains the detailed source; website text should not duplicate entire manual sections.
+
+Current website architecture/scripts must be inspected before changes.

.agents/skills/kst4contest-documentation/references/release-communications.md

@@ -0,0 +1,35 @@
+# Release communications
+
+## Changelog
+
+Write concise English change descriptions.
+
+Prioritize:
+
+- behaviour users notice;
+- contest workflow impact;
+- protocol/integration compatibility;
+- bug/reliability fixes;
+- documentation improvements.
+
+Avoid internal refactor trivia unless it materially changes reliability or maintainability relevant to the release.
+
+## Social release post
+
+Use `$praktimarc-writing-style`.
+
+Typical structure:
+
+- version;
+- short statement of what the release contains;
+- compact highlights;
+- operational context where relevant, e.g. preparation for a VUSHF contest or planned use at DM5M;
+- one clear download/manual destination.
+
+Do not oversell.
+
+## Download/manual direction
+
+Marc has preferred routing users to the HamRadioOnline/KST4Contest download/manual pages rather than scattering multiple download links.
+
+Before publishing new text, inspect the current website URLs and release setup instead of copying an old link.

.agents/skills/kst4contest-review/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: kst4contest-review
+description: Review current KST4Contest local changes or a proposed diff before commit. Check regressions, null safety, JavaFX threading, callsign/category semantics, band handling, protocol compatibility, tests, targeted documentation impact, durable project context and unintended scope. Report findings in German and do not modify files unless explicitly asked after the review.
+---
+
+# KST4Contest review
+
+Review first; do not edit during the review.
+
+Read the relevant KST4Contest change references.
+
+## Review priorities
+
+1. Behaviour matches the approved concept.
+2. No unrelated changes.
+3. Full callsign/category identity remains correct.
+4. Base-call normalization is used only where intended.
+5. Null/unknown values are not converted to fake defaults.
+6. Worker threads do not manipulate JavaFX UI collections.
+7. FX-thread boundaries are correct.
+8. Protocol framing, CR/LF, XML and frequency formatting are unchanged unless explicitly intended.
+9. External malformed input cannot kill long-running threads.
+10. Tests cover the changed behaviour.
+11. Maven test output was interpreted correctly despite ignored-failure settings.
+12. A documentation-impact assessment was performed.
+13. Any likely affected manual/README/website sections match the implementation.
+14. `docs/PROJECT_CONTEXT.md` is updated when the change introduces a durable architectural/protocol/state/operational/integration decision.
+15. Comments/Javadoc are English.
+16. No unintended dependency/version/release changes.
+
+Do not demand a full manual audit for an internal-only change when the impact assessment reasonably concludes there is no documentation effect.
+
+## Report format
+
+Report in German, ordered by severity.
+
+For each finding include:
+
+- affected file/location;
+- concrete problem;
+- consequence;
+- recommended correction.
+
+Then include:
+
+- verification gaps;
+- documentation-impact result;
+- durable-context gaps;
+- related-project gaps when relevant;
+- overall assessment.
+
+Do not fix findings until Marc explicitly asks for implementation and the normal concept gate has been satisfied for the fixes.

.agents/skills/kst4contest-review/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "KST4Contest Review"
+  short_description: "Review KST4Contest diffs before commit"
+  default_prompt: "Review the current KST4Contest changes only. Report findings in German and do not edit files."
+
+policy:
+  allow_implicit_invocation: true

.agents/skills/kst4contest-review/references/review-checklist.md

@@ -0,0 +1,61 @@
+# Review checklist
+
+## Scope
+
+- Is every changed file necessary?
+- Did unrelated formatting or refactoring slip in?
+- Were user-authored local changes preserved?
+
+## Architecture/threading
+
+- Is canonical state owned outside JavaFX controls/lists?
+- Does worker code avoid `ObservableList` access?
+- Are UI mutations routed to the FX thread?
+- Are parser/I/O/domain/UI responsibilities clearer or at least not more coupled?
+
+## Domain
+
+- Full callsign + category identity preserved?
+- Base-call matching restricted to worked/monitoring or another explicitly approved feature?
+- Unknown category/band values safe?
+- NOT-QRV precedence preserved?
+- Missing QRB/QTF remains unavailable rather than zero?
+
+## Protocols
+
+- ON4KST framing unchanged unless approved?
+- CR/LF exact?
+- UCX `contactreplace` compatibility preserved?
+- Frequency strings verified rather than guessed?
+- PSTRotator/AirScout transport/API assumptions checked against current code?
+- Malformed input contained?
+
+## UI
+
+- Selection/focus/zoom/sorting preserved?
+- `/cq callsign` prefill behaviour preserved where relevant?
+- Main send-category fallback preserved where relevant?
+- map WebView workaround preserved?
+- null values displayed safely?
+
+## Tests/build
+
+- Focused regression test added or updated?
+- Test summary checked?
+- Ignored failures explicitly reported?
+- PMD/SpotBugs output considered?
+- packaging/module-list checks considered if modules changed?
+
+## Documentation
+
+- DE and EN manual both checked?
+- website/README/changelog checked if user-visible?
+- screenshot impact reported?
+- writing style applied?
+- no undocumented implementation or documented-but-unimplemented behaviour?
+
+## Git/release
+
+- No version bump unless requested?
+- No generated release/update-feed changes by accident?
+- No staging/commit/push without explicit authorization?

.codex/config.toml

@@ -0,0 +1,4 @@
+model_reasoning_effort = "high"
+approval_policy = "on-request"
+sandbox_mode = "workspace-write"
+web_search = "live"

.github/workflows/aur-publish.yml

@@ -16,8 +16,12 @@ on:
         options: ["false", "true"]
         default: "false"
 
+permissions:
+  contents: read
+
 env:
   FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+  AUR_SSH_DIR: /tmp/aur-ssh
 
 jobs:
   publish-aur:
@@ -38,6 +42,11 @@ jobs:
         uses: actions/checkout@v4.1.7
         with:
           fetch-depth: 0
+          ssh-key: ${{ secrets.WEBSITE_DEPLOY_KEY }}
+
+      - name: Mark workspace as safe Git directory
+        run: |
+          git config --global --add safe.directory "$GITHUB_WORKSPACE"
 
       - name: Resolve release version
         id: ver
@@ -118,52 +127,74 @@ jobs:
             cat "packaging/aur/${pkg}/.SRCINFO"
           done
 
-      - name: Commit updated PKGBUILDs to repo
-        if: inputs.dry_run != 'true'
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
-          git config user.name "github-actions[bot]"
-          git remote set-url origin "https://x-access-token:${GITHUB_TOKEN}@github.com/${{ github.repository }}.git"
-          git add packaging/aur/
-          git diff --cached --quiet && echo "No PKGBUILD changes to commit." && exit 0
-          git commit -m "chore: update AUR packages to ${{ steps.ver.outputs.tag }} [skip ci]"
-          git push
-
       - name: Set up AUR SSH
         if: inputs.dry_run != 'true'
         env:
           AUR_SSH_PRIVATE_KEY: ${{ secrets.AUR_SSH_PRIVATE_KEY }}
         run: |
-          mkdir -p ~/.ssh
-          printf '%s\n' "${AUR_SSH_PRIVATE_KEY}" > ~/.ssh/aur_ed25519
-          chmod 600 ~/.ssh/aur_ed25519
-          ssh-keyscan -t ed25519 aur.archlinux.org >> ~/.ssh/known_hosts
-          cat >> ~/.ssh/config << 'EOF'
-          Host aur.archlinux.org
-            IdentityFile ~/.ssh/aur_ed25519
-            User aur
-          EOF
+          mkdir -p "${AUR_SSH_DIR}"
+
+          printf '%s\n' "${AUR_SSH_PRIVATE_KEY}" \
+            > "${AUR_SSH_DIR}/aur_ed25519"
+
+          sed -i 's/\r$//' "${AUR_SSH_DIR}/aur_ed25519"
+          chmod 600 "${AUR_SSH_DIR}/aur_ed25519"
+
+          ssh-keygen -y \
+            -f "${AUR_SSH_DIR}/aur_ed25519" \
+            > /dev/null
+
+          ssh-keyscan \
+            -T 10 \
+            -t ed25519 \
+            aur.archlinux.org \
+            > "${AUR_SSH_DIR}/known_hosts"
+
+          if [ ! -s "${AUR_SSH_DIR}/known_hosts" ]; then
+            echo "::error::No SSH host key was received from aur.archlinux.org."
+            exit 1
+          fi
+
+          echo "Received AUR host-key fingerprint:"
+          ssh-keygen -lf "${AUR_SSH_DIR}/known_hosts"
+
+          if ! ssh-keygen -lf "${AUR_SSH_DIR}/known_hosts" \
+            | grep -Fq "SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4"; then
+            echo "::error::The AUR SSH host-key fingerprint does not match the official fingerprint."
+            exit 1
+          fi
+
+          printf '%s\n' \
+            "Host aur.archlinux.org" \
+            "  HostName aur.archlinux.org" \
+            "  User aur" \
+            "  IdentityFile ${AUR_SSH_DIR}/aur_ed25519" \
+            "  IdentitiesOnly yes" \
+            "  StrictHostKeyChecking yes" \
+            "  UserKnownHostsFile ${AUR_SSH_DIR}/known_hosts" \
+            > "${AUR_SSH_DIR}/config"
+
+          chmod 600 "${AUR_SSH_DIR}/config"
+          chmod 600 "${AUR_SSH_DIR}/known_hosts"
 
       - name: Push to AUR
         if: inputs.dry_run != 'true'
         env:
           TAG: ${{ steps.ver.outputs.tag }}
+          GIT_SSH_COMMAND: ssh -F /tmp/aur-ssh/config
         run: |
           git config --global user.email "philipp@wagnersnetz.de"
           git config --global user.name "Philipp Wagner"
 
+          mkdir -p /tmp/aur
+
           push_to_aur() {
             local pkg="$1"
             local msg="$2"
             local aur_dir="/tmp/aur/${pkg}"
 
-            git clone "ssh://aur@aur.archlinux.org/${pkg}.git" "${aur_dir}" 2>/dev/null || {
-              mkdir -p "${aur_dir}"
-              git -C "${aur_dir}" init
-              git -C "${aur_dir}" remote add origin "ssh://aur@aur.archlinux.org/${pkg}.git"
-            }
+            git -c init.defaultBranch=master clone \
+              "ssh://aur@aur.archlinux.org/${pkg}.git" "${aur_dir}"
 
             cp "packaging/aur/${pkg}/PKGBUILD" "${aur_dir}/"
             cp "packaging/aur/${pkg}/.SRCINFO" "${aur_dir}/"
@@ -179,3 +210,19 @@ jobs:
           push_to_aur kst4contest     "Update to ${TAG}"
           push_to_aur kst4contest-git \
             "Update pkgver to $(grep '^pkgver=' packaging/aur/kst4contest-git/PKGBUILD | cut -d= -f2)"
+
+      - name: Commit updated PKGBUILDs to repo
+        if: inputs.dry_run != 'true'
+        run: |
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git config user.name "github-actions[bot]"
+          git add packaging/aur/
+          git diff --cached --quiet && echo "No PKGBUILD changes to commit." && exit 0
+          git commit -m "chore: update AUR packages to ${{ steps.ver.outputs.tag }} [skip ci]"
+
+          if ! git push; then
+            echo "::warning::PKGBUILD bookkeeping commit could not be pushed to main."
+            echo "The AUR packages were published; only the in-repo copy stays behind."
+            echo "Check that WEBSITE_DEPLOY_KEY still has write access and may bypass"
+            echo "the branch ruleset, or commit packaging/aur/ by hand."
+          fi

.github/workflows/docs-pdf.yml

@@ -65,6 +65,7 @@ jobs:
             github_docs/en-Home.md \
             github_docs/en-Installation.md \
             github_docs/en-Configuration.md \
+            github_docs/en-Contest-Workflow.md \
             github_docs/en-Features.md \
             github_docs/en-User-Interface.md \
             github_docs/en-Macros-and-Variables.md \
@@ -91,6 +92,7 @@ jobs:
             github_docs/de-Home.md \
             github_docs/de-Installation.md \
             github_docs/de-Konfiguration.md \
+            github_docs/de-Contest-Workflow.md \
             github_docs/de-Funktionen.md \
             github_docs/de-Benutzeroberflaeche.md \
             github_docs/de-Makros-und-Variablen.md \

.github/workflows/nightly-artifacts.yml

@@ -551,6 +551,9 @@ jobs:
     name: Publish Flatpak OSTree Repo (nightly)
     runs-on: ubuntu-latest
     needs: build-flatpak
+    concurrency:
+      group: flatpak-repo-publish
+      cancel-in-progress: false
 
     steps:
       - name: Install Flatpak tooling

.github/workflows/tagged-release.yml

@@ -646,6 +646,9 @@ jobs:
     name: Publish Flatpak OSTree Repo (${{ github.ref_name }})
     runs-on: ubuntu-latest
     needs: build-flatpak
+    concurrency:
+      group: flatpak-repo-publish
+      cancel-in-progress: false
 
     steps:
       - name: Install Flatpak tooling
@@ -787,44 +790,44 @@ jobs:
             release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-en.pdf,
             release-assets/docs/KST4Contest-${{ github.ref_name }}-manual-de.pdf
 
-            # The update feed is generated only after GitHub has published the
-            # release. Otherwise the Releases API cannot return the release notes
-            # belonging to the tag which triggered this workflow.
-            - name: Set up Node.js for website build
-              uses: actions/setup-node@v4
-              with:
-                node-version: "24"
-                cache: npm
-                cache-dependency-path: website/package-lock.json
+      # The update feed is generated only after GitHub has published the
+      # release. Otherwise the Releases API cannot return the release notes
+      # belonging to the tag which triggered this workflow.
+      - name: Set up Node.js for website build
+        uses: actions/setup-node@v4
+        with:
+          node-version: "24"
+          cache: npm
+          cache-dependency-path: website/package-lock.json
 
-            - name: Build and validate website after release publication
-              working-directory: website
-              run: |
-                npm ci
-                npm test
-                npm run build
-              env:
-                GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: Build and validate website after release publication
+        working-directory: website
+        run: |
+          npm ci
+          npm test
+          npm run build
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
-            - name: Verify Stable release in update feed
-              if: ${{ !startsWith(github.ref_name, 'beta-') }}
-              working-directory: website
-              run: npm run validate:version-info
-              env:
-                EXPECTED_STABLE_VERSION: ${{ github.ref_name }}
+      - name: Verify Stable release in update feed
+        if: ${{ !startsWith(github.ref_name, 'beta-') }}
+        working-directory: website
+        run: npm run validate:version-info
+        env:
+          EXPECTED_STABLE_VERSION: ${{ github.ref_name }}
 
-            - name: Attach verified version info to tagged release
-              run: >-
-                gh release upload "${GITHUB_REF_NAME}"
-                website/_site/kst4ContestVersionInfo.xml
-                --clobber
-              env:
-                GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: Attach verified version info to tagged release
+        run: >-
+          gh release upload "${GITHUB_REF_NAME}"
+          website/_site/kst4ContestVersionInfo.xml
+          --clobber
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
-            - name: Upload verified website artifact
-              uses: actions/upload-artifact@v4.3.4
-              with:
-                name: kst4contest-website-${{ github.ref_name }}
-                path: website/_site/
-                if-no-files-found: error
-                retention-days: 14
+      - name: Upload verified website artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: kst4contest-website-${{ github.ref_name }}
+          path: website/_site/
+          if-no-files-found: error
+          retention-days: 14

AGENTS.md

@@ -0,0 +1,180 @@
+# KST4Contest agent instructions
+
+These project instructions extend Marc's global Codex working agreements.
+
+## Project identity
+
+KST4Contest is a Java/JavaFX desktop client for ON4KST chat with contest-oriented workflows and integrations including logging software, AirScout, rotor control, DXCluster and local persistence.
+
+Primary repository areas:
+
+- `src/main/java/kst4contest/`
+- `src/test/` where present;
+- `github_docs/`
+- `website/`
+- `docs/`
+- `packaging/`
+- `.github/`
+- `pom.xml`
+
+Inspect the current tree before assuming an exact class/path still exists.
+
+## Mandatory interaction rule
+
+For every planned code or documentation implementation:
+
+1. inspect first;
+2. explain the task understanding in German;
+3. identify and ask all relevant implementation questions;
+4. wait for answers when needed;
+5. present the final concept in German;
+6. state what must remain unchanged;
+7. request explicit concept approval;
+8. wait;
+9. implement only after approval.
+
+If an answer is uncertain, do not interpolate it. Check current code/tests/docs/project context first and ask Marc when the uncertainty can affect behaviour.
+
+## Language
+
+- Communicate with Marc in German.
+- Write source-code comments and Javadoc exclusively in English.
+- Keep log/protocol/API literals in their canonical form.
+- Commit messages are concise English when a commit is explicitly requested.
+- User-facing DE/EN documentation follows `$praktimarc-writing-style`.
+
+## Java and JavaFX architecture
+
+- Preserve or improve separation between network/parsing/service/controller/UI responsibilities.
+- Do not solve architecture problems by letting worker/model code directly manipulate JavaFX UI collections.
+- Active chat-member domain state is conceptually thread-safe state; JavaFX `ObservableList` data is a UI projection, not the canonical worker-thread store.
+- `MessageBusManagementThread` must not directly read or mutate the JavaFX `ObservableList` used by the UI.
+- Route UI-visible mutations through the controller and the JavaFX Application Thread (`Platform.runLater` or the project's equivalent helper).
+- Prefer explicit DTOs over records when introducing transport/parser DTOs in this codebase unless the approved concept says otherwise.
+- Handle incomplete external/historical data defensively.
+- `qrb`, QTF and related external values can be absent. `null` means unavailable, not zero.
+- Unexpected input must not terminate message-processing or UI threads.
+
+## Callsign and category identity
+
+- Preserve full callsign variants as distinct chat-member identities where the server exposes them separately.
+- Category is part of chat identity. Do not merge messages across categories.
+- Base-call normalization may be used only for explicitly base-call-wide features such as worked status or monitoring rules.
+- Worked status is shared across suffix variants of the same base call.
+- Monitoring a callsign variant such as `DN9APW-2` or `DN9APW-70` is intended to monitor the base call `DN9APW`, so users do not need to enter every SSID.
+- Do not generalize suffix semantics beyond behaviour explicitly established by the current code/specification.
+
+## Bands and availability
+
+- ON4KST categories 2 and 3 are central to the normal VHF/UHF workflow, but other category values can occur and must fail safely.
+- Do not let unsupported categories produce exceptions.
+- Known-active-band logic and `B+` interpretation must remain consistent across the application.
+- Band information parsed from names/text must respect explicit `NOT-QRV` information; NOT-QRV overrides positive availability hints.
+- Do not silently fall back to a fixed band/frequency when a required decision is ambiguous unless an approved fallback exists.
+- Manual band settings and actual current QRG must remain consistent with features that depend on frequency.
+
+## External protocols and integrations
+
+Before changing ON4KST, AirScout, UCXLog/DXLog, Win-Test, PSTRotator or DXCluster handling:
+
+- inspect the current implementation;
+- preserve exact framing and compatibility;
+- inspect current tests;
+- check authoritative upstream documentation when the protocol detail is uncertain;
+- ask Marc if more than one behaviour is plausible.
+
+Specific invariants and historical context are in `$kst4contest-change` references.
+
+Never change CR/LF, XML framing, callsign normalization, frequency formatting or port/transport assumptions casually.
+
+## UI behaviour
+
+- Preserve contest workflow speed and discoverability.
+- Do not change zoom, selection, focus, sorting, tab choice or prefilled text as an incidental side effect.
+- Map reset behaviour should clear the selected target without changing the zoom unless a new task explicitly changes this.
+- New station selection should preserve the established `/cq callsign` prefill behaviour.
+- If no send category is selected, preserve the established Main-category fallback unless explicitly changed.
+- Null/unknown data must render as unavailable/empty according to current UI conventions, not as fake zero values.
+
+## WebView / map compatibility
+
+- The Leaflet WebView workaround that disables problematic CSS 3D transforms before Leaflet loads is a known Java 21 stability measure. Do not remove or reorder it without reproducing and understanding the original rendering/flicker problem.
+
+## Autoanswer / beacon safety
+
+- Prevent automated-message loops.
+- Respect the established minimum interval/cooldown logic.
+- Do not consume a cooldown for a reply that is rejected before a complete valid TX item is queued.
+- Preserve priority of frequency/QRG requests where established.
+- Cooldown identity must not accidentally collapse unrelated callsign/category identities.
+- Treat the current implementation/tests as the source of truth for exact message markers and timer details.
+
+## Build and verification
+
+Use the Maven wrapper.
+
+Windows:
+
+```text
+.\mvnw.cmd ...
+```
+
+Read the current `pom.xml` before relying on version numbers.
+
+At the package creation snapshot the project uses Java 21 / JavaFX 21.x and JUnit 5/Mockito, with PMD and SpotBugs integrated.
+
+Important: Maven/Surefire configuration has historically allowed test failures to be ignored, and static-analysis findings may not fail the build. Therefore:
+
+- inspect the Maven test summary;
+- inspect Surefire results when needed;
+- do not infer "all tests passed" from exit code 0;
+- report PMD/SpotBugs findings that are visible in the relevant build.
+
+Run focused tests first, then normally the relevant broader test/build command for the scope.
+
+## Documentation and durable project context
+
+Use `$software-project-context`, `$kst4contest-documentation`, and `$praktimarc-writing-style` as relevant.
+
+Do not perform a full manual or website audit after every implementation.
+
+After a completed change:
+
+1. perform a short documentation-impact classification;
+2. if user-visible behaviour is plausibly affected, search only the relevant German and English manual sections under `github_docs/`;
+3. keep both language versions semantically aligned when an update is required;
+4. check README and website feature text only when the changed feature/configuration is represented there or is likely to need representation;
+5. identify screenshots that are likely stale instead of fabricating replacements;
+6. update `docs/PROJECT_CONTEXT.md` for significant architectural, protocol, state/persistence, operational, integration, deployment, workaround, or long-lived behavioural decisions;
+7. keep `Related Projects / Integration Points` current when KST4Contest, its website, hamradioonline infrastructure or planned propagation services affect one another.
+
+A full documentation audit is reserved for explicit audit requests, major release preparation, broad UI/workflow changes, or evidence that documentation is broadly stale.
+
+## Website
+
+The repository contains an Eleventy-based website under `website/` with its own tests/build logic.
+
+Do not assume website deployment/update-feed details; inspect current scripts/workflows before changing them.
+
+## Change scope and Git
+
+- No unrelated refactoring.
+- No production dependency without prior approval.
+- No automatic version bump.
+- No commit/push/merge/tag/release/deploy without separate explicit authorization.
+- Preserve deliberate test data and easter eggs unless explicitly changed.
+- Never overwrite unrelated working-tree changes.
+
+## Completion
+
+After implementation, report in German:
+
+- understanding fulfilled;
+- changed files;
+- important design decisions;
+- tests/builds and exact results;
+- documentation-impact classification;
+- manual/website/README/context updates made or why none were necessary;
+- related-project impact when relevant;
+- remaining uncertainty;
+- suggested next action, without performing it automatically.

docs/CONCEPT_IN_APP_UPDATE.md

@@ -0,0 +1,306 @@
+# Konzept: In-App-Update für KST4Contest
+
+> Status: Konzept, noch nicht umgesetzt. Zielrelease **1.50**. Alle Zeilenanker beziehen sich auf `nextMajorRelease/version1_50` (Version 1.50.0) und wurden gegen den Branch verifiziert.
+
+## Ziel
+
+Stable-Updates werden nach Zustimmung des Nutzers heruntergeladen. KST4Contest beendet sich danach kontrolliert und startet den plattformspezifischen Aktualisierungsvorgang. Updates dürfen den Programmstart nicht blockieren und während eines Contests nicht erzwungen werden.
+
+## Ausgangslage
+
+Der vorhandene Mechanismus erfüllt das nicht:
+
+- `UpdateChecker.downloadLatestVersionInfoXML()` (`src/main/java/kst4contest/controller/UpdateChecker.java:54-71`) benutzt `new URL(...).openStream()` + `Files.copy(..., REPLACE_EXISTING)` **direkt auf die Zieldatei** — ohne Timeouts, ohne HTTP-Statusprüfung, ohne temporäre Datei. Ein Fehlschlag beschädigt zusätzlich die lokale Feed-Kopie.
+- Der Aufruf steht **synchron im Konstruktor** von `ChatController` (`ChatController.java:2937-2941`); `ChatController` wird in `Kst4ContestApplication.start(Stage)` erzeugt (`Kst4ContestApplication.java:6971`, `start` ab `:6914`). Der Netzwerkaufruf läuft damit unbegrenzt **auf dem JavaFX-Application-Thread während des Starts** — genau der Punkt „darf den Programmstart nicht blockieren".
+- `parseUpdateXMLFile()` (`UpdateChecker.java:73-236`) liest Kindelemente **positionsabhängig** über einen Zähler in `String[7]` bzw. `String[3]` (`:144-145`, `:182-183`). Ein achtes Kindelement in `<changeLog>` erzeugt eine `ArrayIndexOutOfBoundsException` und killt den gesamten Check.
+- Die Anzeige ist ein eigenes `Stage` mit `setAlwaysOnTop(true)` (`Kst4ContestApplication.java:9162`), inline in `start()` aufgebaut (`:9152-9294`) und beim Start automatisch geöffnet (`:9280`). Es gibt **keinen Menüpunkt** zum erneuten Prüfen. Ein Catch-All bei `:9289-9292` schaltet die Funktion stillschweigend ab, sobald der Feed fehlt oder nicht passt.
+- Toter Code: `main()` (`:27-34`) und ein Testdatenblock (`:208-234`).
+
+## Bestätigte Festlegungen
+
+| Punkt | Entscheidung |
+|---|---|
+| Contest-Schutz | Hinweis wird unterdrückt, solange eine ON4KST-Verbindung besteht |
+| Update-Starter | Kein eigenes Starter-Programm; Installer/Paketverwaltung wird direkt gestartet, danach beendet sich KST4Contest |
+| Flatpak | Nur Hinweis mit Update-Befehl, kein Download, kein Artefakt |
+| AppImage | Kontrollierter Dateiaustausch, kein `AppImageUpdate` |
+| Kanal | Ausschließlich Stable |
+| Feed-Auslieferung | Bleibt wie bisher: der Webserver zieht das Repo alle 5 Minuten per Git und baut die Website selbst |
+| Zuschnitt | Drei Stufen |
+| Signatur | SignPath Foundation, als **optionaler additiver** CI-Schritt; unsigniert bleibt lauffähig |
+| Windows-ZIP | Bleibt als portable Alternative |
+
+## Was unverändert bleibt
+
+1. **Alte Clients (≤ 1.44) am erweiterten Feed.** `UpdateChecker` sucht per `getElementsByTagName` nach `latestVersion`, `versionNumber`, `semanticVersion`, `adminMessage`, `majorChanges`, `latestVersionPathOnWebserver`, `changeLog`, `bug`. Das ist eine **Descendant-Suche** — deshalb kommt der neue Block als *Geschwister* neben `<latestVersion>` und benutzt ausschließlich neue Elementnamen.
+2. **`<changeLog>` behält exakt seine 7 Kinder** (`changedVersionNumber, date, description, added, changed, fixed, removed`) in unveränderter Reihenfolge, `<bug>` seine Struktur. `<needUpdateSinceLastVersion>`, `<roadmap>`, `<bugsReported>` bleiben unangetastet.
+3. **`~/.praktiKST/`** — nur ein neues Unterverzeichnis `updates/`. `kst4ContestVersionInfo.xml` behält Name und Ort, damit ein Downgrade auf 1.44 funktioniert.
+4. **Windows-ZIP als Portable** — die App verändert ihr eigenes Verzeichnis nie und führt für diesen Typ keinen Installer aus.
+5. **Kein Eingriff** in Flatpak-, AUR-, DEB-, RPM- oder Arch-Installationen; **kein `sudo`/`pkexec`** aus der Anwendung heraus.
+6. **Offlinebetrieb** — ein fehlgeschlagener Check ist stumm (nur `java.util.logging`), der Programmstart ist davon vollständig entkoppelt.
+7. **Legacy-Vergleich** — `APPLICATION_CURRENTVERSIONNUMBER` und `<versionNumber>` bleiben als Fallback; `VersionUtils.compareStableVersions` wird wiederverwendet und nicht verändert.
+8. **Bei unbekannter Installationsart** wird ausschließlich die Downloadseite geöffnet.
+
+---
+
+## Stufe 1 — Feed, Paketkennzeichnung, Prüfdienst, Hinweis-UI
+
+Kein Download, kein Installationsstart.
+
+### 1a. Installationsart zur Buildzeit kennzeichnen
+
+Es existiert heute **keinerlei** Build-Metadatum: kein `--java-options`, keine `.properties` unter `src`, kein Resource-Filtering in `pom.xml`, keine Manifest-Einträge.
+
+**Gewählter Mechanismus:** jpackage-Flag `--java-options -Dkst4contest.packageType=<typ>`.
+
+| Alternative | Warum nicht |
+|---|---|
+| Gefilterte `.properties`-Resource | **Alle Pakettypen entstehen aus demselben Maven-Artefakt**; die Unterscheidung fällt erst im jpackage-Aufruf. Lokale Builds und Tests bekämen einen falschen Marker. |
+| Manifest-Eintrag | Gleiches JAR-Problem, mehr Bewegungsteile. |
+| Verzeichnis-/Prozessheuristik | Laut Zielbild ausdrücklich ausgeschlossen; bei ZIP-Portable ohnehin frei verschiebbar. |
+| Reines Env-Sniffing | Erkennt Flatpak und AppImage, aber nicht deb/rpm/arch/zip/msi. |
+
+Vorteile: keine Auswirkung auf `mvn`/Tests/lokale Entwicklung (Property fehlt → `UNKNOWN` → sicherer Fallback); der Wert landet in `lib/app/<Name>.cfg` des app-image und wird dadurch vom AUR-`-bin`-Repack (`packaging/aur/kst4contest-bin/PKGBUILD` macht nur `cp -a usr`) und vom Flatpak-Build (bindet das app-image als `type: dir`-Source ein) **automatisch mitkopiert**.
+
+Werte: `windows-zip`, `windows-msi`, `macos-dmg`, `linux-appimage`, `flatpak`, `linux-deb`, `linux-rpm`, `linux-arch`.
+
+**15 Aufrufstellen:**
+
+| Datei | Zeilen | Wert |
+|---|---|---|
+| `.github/workflows/tagged-release.yml` | 53 / 104 / 184 / 238 / 292 / 403 | `windows-zip` / `linux-appimage` / `linux-deb` / `linux-rpm` / `linux-arch` / `flatpak` |
+| `.github/workflows/nightly-artifacts.yml` | 69 / 127 / 214 / 275 / 338 / 458 | dieselbe Reihenfolge |
+| `packaging/macos/build-signed-dmg.sh` | 72 | `macos-dmg` |
+| `packaging/aur/kst4contest/PKGBUILD` | 44 | `linux-arch` |
+| `packaging/aur/kst4contest-git/PKGBUILD` | 37 | `linux-arch` |
+
+`packaging/aur/kst4contest-bin/PKGBUILD` erbt korrekt — **keine Änderung**.
+
+PowerShell-Syntax (tagged-release:53, nightly:69) braucht einfache Anführungszeichen, sonst frisst PowerShell das `-D`:
+`--java-options '-Dkst4contest.packageType=windows-zip'`
+
+**Auflösung zur Laufzeit** (`RuntimePackageTypeResolver`), bewusst konservativ:
+
+1. `System.getProperty("kst4contest.packageType")`; unbekannter Wert → weiter.
+2. `/.flatpak-info` vorhanden **oder** `FLATPAK_ID` gesetzt → `FLATPAK`. Diese Prüfung **überschreibt** die Property — eine Fehlklassifikation richtet ausgerechnet im Flatpak den größten Schaden an (Download in eine Sandbox, die den Host nie aktualisieren kann).
+3. `APPIMAGE` gesetzt → `LINUX_APPIMAGE`.
+4. sonst `UNKNOWN`.
+
+### 1b. Feed erweitern
+
+Der Feed wird **von der Website** erzeugt (`website/src/_data/versionInfo.js`, ausgeliefert über `website/src/version-info.njk`), gespeist aus der GitHub-Releases-API — nicht aus den Build-Jobs. Der Webserver zieht das Repository alle 5 Minuten per Git und baut selbst; eine geänderte `versionInfo.js` wird dadurch automatisch wirksam, **ohne** Upload-Schritt in den Workflows.
+
+**Platzierung: neues Top-Level-Element als Geschwister von `<latestVersion>`.** Ein Kindelement *innerhalb* `<latestVersion>` wäre riskant, weil der alte Parser dort per Descendant-Suche liest; als Geschwister ist jede Kollision strukturell ausgeschlossen.
+
+```xml
+<updatePackages formatVersion="1" semanticVersion="1.45.0">
+    <updatePackage>
+        <packageType>linux-deb</packageType>
+        <operatingSystem>linux</operatingSystem>
+        <architecture>x86_64</architecture>
+        <fileName>KST4Contest-v1.45.0-debian-amd64.deb</fileName>
+        <downloadUrl>https://github.com/praktimarc/kst4contest/releases/download/v1.45.0/…</downloadUrl>
+        <fileSizeBytes>142335488</fileSizeBytes>
+        <sha256>9f2c…</sha256>                      <!-- 64 hex, klein -->
+        <signatureState>unsigned</signatureState>    <!-- unsigned | authenticode | apple-notarized | gpg-repo -->
+        <releaseNotesUrl>…/releases/tag/v1.45.0</releaseNotesUrl>
+        <installHint>package-manager</installHint>   <!-- run | package-manager | portable | hint-only -->
+    </updatePackage>
+    <updatePackage>
+        <packageType>flatpak</packageType>
+        <operatingSystem>linux</operatingSystem>
+        <architecture>x86_64</architecture>
+        <signatureState>gpg-repo</signatureState>
+        <releaseNotesUrl>…/releases/tag/v1.45.0</releaseNotesUrl>
+        <installHint>hint-only</installHint>
+        <hintCommand>flatpak update de.x08.KST4Contest</hintCommand>
+        <!-- bewusst ohne downloadUrl/sha256 -->
+    </updatePackage>
+</updatePackages>
+```
+
+**Datenherkunft in `versionInfo.js`:**
+
+- `fileName`, `downloadUrl`, `fileSizeBytes` stehen **bereits in der vorhandenen `/releases`-Antwort** (`release.assets[]` mit `name`, `browser_download_url`, `size`) — kein zusätzlicher API-Aufruf. Aktuell werden die Assets weggeworfen.
+- `packageType`/`operatingSystem`/`architecture` über einen deterministischen Klassifikator auf die Assetnamen, die die Workflows fest vergeben (`tagged-release.yml:783-791`): `-windows-x64.zip`, `-linux-x86_64.AppImage`, `-debian-amd64.deb`, `-fedora-x86_64.rpm`, `-archlinux-*.pkg.tar.zst`, `-macos-*.dmg`. `.flatpakref` erzeugt keinen Download, sondern den synthetischen Hint-Eintrag. Manuals und der Feed selbst werden übersprungen.
+- **`sha256` muss der Release-Workflow erzeugen.** Im Job `release-tag` liegen alle Artefakte bereits unter `release-assets/*`, bevor `ncipollo/release-action` läuft. Dort nach den `download-artifact`-Schritten und **vor** „Create tagged release":
+  ```yaml
+  - name: Compute release asset checksums
+    run: |
+      cd release-assets
+      find . -type f ! -name SHA256SUMS.txt -print0 \
+        | xargs -0 sha256sum | sed 's#\./##' > SHA256SUMS.txt
+  ```
+  und `release-assets/SHA256SUMS.txt` in die `artifacts:`-Liste (`:783-791`) aufnehmen. Die bestehende Reihenfolge (Release zuerst, dann Website-Build, `:771-825`) bleibt korrekt — die Summen liegen zum Zeitpunkt des Website-Builds bereits am Release. `versionInfo.js` lädt die Datei **nur für das neueste Stable-Release** und baut daraus eine `filename → sha256`-Map; das ist ein Download-URL-Abruf und belastet das API-Ratelimit nicht.
+- `signatureState` aus einer statischen Tabelle je packageType (`macos-dmg → apple-notarized`, `flatpak → gpg-repo`, Rest `unsigned`). In Stufe 3 wird `windows-msi` nur dann auf `authenticode` gesetzt, wenn ein signiertes Asset tatsächlich existiert — der Feed darf nicht lügen, wenn der SignPath-Schritt übersprungen wurde.
+
+**Robustheit:** Weil der Server unabhängig vom Release-Workflow baut, kann er einen Feed erzeugen, bevor `SHA256SUMS.txt` am Release hängt. Fehlt `<sha256>`, gilt das Artefakt als **nicht automatisch ladbar** — der Client öffnet nur die Downloadseite. Ein Artefakt ohne Prüfsumme wird nie geladen und nie gestartet. Die bestehende `try/catch`-Klammer in `versionInfo.js` bricht den Website-Build bei einem unvollständigen Feed ab; die neue Sektion darf **nicht** so scharf sein — bei Problemen wird `<updatePackages>` weggelassen, der Rest des Feeds bleibt gültig.
+
+**Mitzuziehen:**
+- `website/scripts/validate-version-info.js` — bekannter `packageType`; `sha256` matcht `^[0-9a-f]{64}$`; `downloadUrl` beginnt mit `https://github.com/praktimarc/kst4contest/releases/download/`; `fileSizeBytes` numerisch > 0. **Zusätzlich neu und wichtig:** `<changeLog>` muss weiterhin exakt die 7 Kinder in der Altreihenfolge haben — das nagelt die Alt-Client-Kompatibilität fest.
+- `website/test/version-info.test.js` — Klassifikator, SHA256SUMS-Parsing, „Release ohne Assets".
+
+**Warnung, nicht Teil dieser Umsetzung:** `.github/workflows/test-publish-version-xml.yml` (ungetrackt, nur `workflow_dispatch`) erzeugt mit einem eigenen Python-Generator einen konkurrierenden Feed **ohne** `<semanticVersion>` und lädt ihn per WebDAV hoch. Würde er ausgelöst, fielen alle Clients auf den kaputten Double-Vergleich (`1.41.1` → `1.411`) zurück.
+
+### 1c. Prüfdienst neu bauen
+
+Neues Package `kst4contest.service.update` (konsistent zum vorhandenen `kst4contest/service/path/`).
+
+| Datei | Verantwortung |
+|---|---|
+| `model/PackageType.java` | Enum + `feedId()`, `fromFeedId()` (null/unbekannt → `UNKNOWN`, wirft nie), `updateStrategy()` |
+| `model/UpdatePackageInfo.java` | Transport-DTO, **explizite Klasse, kein Record** (AGENTS.md) |
+| `model/UpdateCheckResult.java` | Ergebnis-DTO inkl. `resultSource` (`NETWORK`/`CACHE`/`NONE`) |
+| `service/update/UpdateFeedParser.java` | **Reiner Parser**, kein IO, kein Netz |
+| `service/update/UpdateFeedClient.java` | **Nur HTTP**, injizierbarer `HttpClient` + Timeouts |
+| `service/update/UpdateCheckService.java` | Orchestrierung, injizierbare Abhängigkeiten + `Clock` |
+| `service/update/RuntimePackageTypeResolver.java` | Installationsart, Test-Konstruktor für Property/Env/Pfad |
+
+Muster: `OpenMeteoTerrainProfileProvider.java:76-88` (injizierbarer Client, konfigurierbare Timeouts), `TerrainPackageDownloader.java:107-145` (Temp-Datei → Statusprüfung → `Files.move`).
+
+Verhalten:
+
+- Aufruf **asynchron im Daemon-Thread, erst nach `primaryStage.show()`** — nie vorher. `ChatController.java:2937-2941` entfällt.
+- Ergebnis über eine `ObjectProperty<UpdateCheckResult>` im `ChatController`, gesetzt via `Platform.runLater`. Muster: `lastUiReminderEvent` (`ChatController.java:4236-4243`). Der Worker fasst **keine** `ObservableList` an.
+- Versionsvergleich über `VersionUtils.compareStableVersions`. **Achtung:** `parseVersion` wirft bei leerem oder nicht-numerischem Input (`IllegalArgumentException`/`NumberFormatException`) — der Dienst muss das fangen und auf den Double-Pfad zurückfallen. Heute ist das in der View (`:9266-9278`) nicht abgesichert.
+- Ausschließlich Stable. Fehlende Verbindung erzeugt **keine** Meldung, nur einen Logeintrag über `java.util.logging` statt `System.out`. Höchstens eine Meldung je Sitzung. Bei Netzfehler Rückfall auf die zuvor gecachte Datei.
+
+**Positionales Parsing entschärfen:** Primärpfad namensbasiert (`readChildText(element, "changedVersionNumber")` …), Ergebnis weiterhin als `String[7]` in derselben Reihenfolge, damit der TreeView-Aufbau im Update-Fenster unverändert bleibt. Kompatibilitätspfad für uralte Feeds behält den positionalen Walk, aber mit `if (counter >= entry.length) break;`. Präfixe (`"Date: "`, `"Desc: "`) exakt erhalten. Bei `<bug>` ist `aChangeLogEntry[2]` heute uninitialisiert → explizit `""`.
+
+`UpdateChecker.java` wird durch den Dienst ersetzt.
+
+### 1d. Hinweis-UI
+
+Wiederverwendet wird das etablierte Muster `initSkedWarnIndicatorButton()` (`Kst4ContestApplication.java:5790-5807`) und `initBandUpgradeIndicatorButton()` (`:5965`): versteckt per Default, `managedProperty().bind(visibleProperty())`, eingehängt in `flwpne_StatusBar` (Aufbau `:7158`, `setTop` `:7161`, Indicator-Buttons `:7163`, `:7166`, `:7189`).
+
+Abweichung: **nicht** `setMouseTransparent(true)` — der Button ist klickbar und öffnet ein `ContextMenu`.
+
+- Text: `KST4Contest 1.x.y is available`
+- Aktionen: Änderungen anzeigen · Update herunterladen (Stufe 1: deaktiviert bzw. „Release-Seite öffnen") · für diese Sitzung schließen
+- **Contest-Regel:** `visible = updateAvailable && !dismissedForSession && Verbindungszustand != ONLINE`. `onConnectionStateChanged(...)` (`:12566`) ruft zusätzlich `refreshUpdateHintVisibility()` im vorhandenen `Platform.runLater`-Block — der Hinweis verschwindet beim Login in den Chat und kommt beim Trennen zurück.
+- FX-Thread-Guard-Idiom aus `:5833` übernehmen.
+- **Neuer Menüpunkt** im Info-Menü (Info-Menü, `helpMenu.getItems().addAll(...)` `:5774`): „Check for updates…" und „Show update details…". Damit existiert erstmals ein manueller Re-Check.
+- Das bestehende `stage_updateStage` wird aus `start()` in eine eigene, **lazy** aufgerufene Methode herausgezogen; gespeicherte Fenstergröße (`getGUIstage_updateStage_SceneSizeHW`, `:9253-9260`) bleibt. Das Auto-`show()` (`:9280`) entfällt, `setAlwaysOnTop(true)` (`:9162`) wird entfernt — ein Always-on-Top-Fenster über einem laufenden Contest ist genau das, was das Ziel verbietet.
+
+### 1e. Versionsdrift absichern
+
+`pom.xml:9` und `ApplicationConstants.APPLICATION_CURRENT_VERSION` werden **von Hand gepflegt, ohne jede Prüfung**. Für einen Mechanismus, der genau diese Zeichenkette vergleicht, ist das die riskanteste Stelle. Analog zu `packaging/AddModules.java --verify-pom` (an `validate` gebunden, `pom.xml:219-240`) einen `--verify-version`-Wächter ergänzen. Kein Auto-Bump.
+
+`docs/PROJECT_CONTEXT.md:198` beschreibt zusätzlich die Kodierung von `APPLICATION_CURRENTVERSIONNUMBER` (`1.43.1` → `1.431`) — beim Bump mitführen, solange das Legacy-Feld existiert. Auf 1.50 stehen die Werte in `ApplicationConstants.java:23` und `:30`.
+
+### 1f. `--app-version` nachziehen
+
+Außer im macOS-Skript (`build-signed-dmg.sh:75`) setzt **kein** jpackage-Aufruf `--app-version`. DEB und RPM tragen dadurch intern die Vorgabeversion `1.0`; ein `apt install ./KST4Contest-v1.45.0.deb` wäre für dpkg **kein Upgrade**. Vor Stufe 3 zwingend, sinnvollerweise überall — dieselbe `sed`-Ableitung wie `build-signed-dmg.sh:59-65`. Nebenwirkung: bestehende DEB/RPM-Installationen springen einmalig von `1.0` auf die echte Version.
+
+---
+
+## Stufe 2 — Gesicherter Download
+
+Erst nach „Update herunterladen".
+
+| Datei | Verantwortung |
+|---|---|
+| `service/update/UpdateDownloadPolicy.java` | Reine Validierung, kein IO |
+| `service/update/UpdateDownloadService.java` | Download + Verifikation |
+| `service/update/UpdateStorage.java` | `~/.praktiKST/updates/`, Aufräumen verwaister Dateien |
+| `model/UpdateDownloadResult.java` | Ergebnis-DTO |
+
+**Ablauf** (Muster `TerrainPackageDownloader.java:93-165`):
+
+1. Download nach `<fileName>.download`;
+2. Prüfung von Dateigröße **und** SHA-256 (`computeSha256`, `:175-187`, 8-KiB-Puffer + `HexFormat`);
+3. `Files.move` erst nach erfolgreicher Prüfung;
+4. bei Abbruch oder falscher Prüfsumme temporäre Datei löschen, verständliche Meldung;
+5. **niemals** ein ungeprüftes Artefakt starten.
+
+Empfehlung: `BodyHandlers.ofInputStream()` + `DigestInputStream` statt `ofFile` — ein Durchlauf statt zwei, und ein Fortschrittsbalken ist bei 150-MB-Dateien Pflicht. Short-circuit, wenn die Zieldatei bereits mit passendem Hash existiert.
+
+**Sicherheitsschranke — nicht optional:** SHA-256 aus dem Feed beweist nur, dass die Datei zum Feed passt. Da der Feed über einen selbst gebauten Host ausgeliefert wird, ist eine **Host-Allowlist** (`github.com`, `objects.githubusercontent.com`) die eigentliche Schutzschicht: selbst ein manipulierter Feed kann keine beliebige URL unterschieben. `UpdateDownloadPolicy` prüft zusätzlich: Schema `https`; `sha256` matcht `^[0-9a-fA-F]{64}$`; `fileName` ohne `/`, `\`, `..`; `fileSizeBytes` > 0 und < 1 GiB; ausreichend Plattenplatz; `packageType` erlaubt Download.
+
+Stufe 2 führt **nichts** aus. Nach Erfolg: „Jetzt beenden und aktualisieren" / „Später installieren". Flatpak erhält gar keinen Download-Pfad, sondern den Hinweistext aus `<hintCommand>`.
+
+---
+
+## Stufe 3 — Plattformausführung, Windows-Installer, Signatur
+
+### 3a. Windows-Installer
+
+`--type msi` mit **dauerhaft konstanter** `--win-upgrade-uuid`, dazu `--win-menu --win-shortcut --win-dir-chooser`. `choco install wixtoolset` steht bereits in beiden Workflows (`tagged-release.yml:33-35`, `nightly-artifacts.yml:49-51`) und wird bisher **nicht genutzt** — die Voraussetzung ist vorhanden. Der ZIP-Build bleibt bestehen.
+
+Die GUID muss dokumentiert werden (z. B. `packaging/windows/README.md`) — ändert sie sich, sind MSI-Upgrades dauerhaft kaputt. Asset in die `artifacts:`-Liste und in den SHA256SUMS-Schritt aufnehmen.
+
+### 3b. Ausführung je Installationsart
+
+| Installation | Verhalten |
+|---|---|
+| `windows-msi` | `msiexec /i "<datei>" /qb` detached, danach beenden |
+| `windows-zip` | Keine Ausführung. Installer laden, Ordner öffnen, Benutzerdaten bleiben. **Hinweis nötig**, dass der alte ZIP-Ordner bestehen bleibt und künftig der Installer-Eintrag zu starten ist — sonst startet der Nutzer weiter die alte `praktiKST.exe` und sieht nie wieder ein Update |
+| `macos-dmg` | `open "<dmg>"`, danach beenden; der Nutzer zieht selbst. Ein laufendes `.app` kann sich ohne separates Updater-Binary nicht ersetzen |
+| `linux-appimage` | Neues AppImage neben `$APPIMAGE` ablegen, `chmod +x`, Ordner öffnen, beenden. Kein In-Place-Overwrite einer laufenden Datei |
+| `flatpak` | Nur Verweis auf `flatpak update de.x08.KST4Contest`; keine Datei im Paket anfassen |
+| `linux-deb/rpm/arch` | `xdg-open "<datei>"` → GNOME Software / Discover / gdebi übernehmen inkl. Rechteabfrage. **Bewusst kein `pkexec`/`sudo`** aus der Anwendung heraus |
+| AUR | Verweis auf den vorhandenen AUR-Helper |
+| `UNKNOWN` | Ausschließlich Downloadseite öffnen |
+
+Kein eigener Update-Starter. Der kontrollierte Ausstieg: Verbindung prüfen und ggf. bestätigen lassen → ON4KST sauber trennen → Layout/Preferences flushen → DB schließen → Installer starten → `Platform.exit()` + `System.exit(0)`. Kein `Runtime.halt`. Der vorhandene Weg über `Kst4ContestApplication.stop()` (`disconnect("CLOSEALL")` + `System.exit(0)`) bleibt die Basis.
+
+### 3c. SignPath
+
+Eigener Step im MSI-Job, gegated über das Vorhandensein des Secrets. Fehlt es (bis zur Foundation-Freigabe), läuft die Pipeline unverändert durch und liefert ein unsigniertes MSI. Signiertes Ergebnis unter eigenem Namen hochladen; `versionInfo.js` setzt `signatureState` nur, wenn dieses Asset existiert.
+
+**Vorbedingung für die Abhängigkeitsprüfung:** `module-info.java:14-15` deklariert `requires org.junit.jupiter.api;` und `requires org.mockito;`, weil Testklassen unter `src/main/java/` liegen (u. a. `controller/On4KstProtocolTest.java`, `controller/On4KstSocketThreadTest.java`, `controller/ReadUDPByWintestThreadTest.java`, `test/MockKstServer.java`, `view/map/mapTest.java`). `pom.xml` deklariert `junit-jupiter-api` und `mockito-core` deshalb mit `<scope>compile</scope>`, und JUnit, Mockito, ByteBuddy und Objenesis landen im ausgelieferten Runtime-Image — im Flatpak in `lib/app/` nachgewiesen. Ausgerechnet ByteBuddy/Mockito (Bytecode-Manipulation, Agent) in einem signierten Produktionsbinary ist für so eine Prüfung ungünstig. Als **eigener, abgegrenzter Commit vor dem Antrag** bereinigen: Klassen nach `src/test/java/`, `requires` entfernen, Scopes zurück auf `test`.
+
+---
+
+## Tests
+
+Alle neuen Tests unter `src/test/java/kst4contest/service/update/` bzw. `.../model/`, Fixtures unter `src/test/resources/update/`. **Nichts Neues unter `src/main/java`** — die dort liegenden Testklassen sind Altlast, keine Vorlage.
+
+| Testklasse | Assertions |
+|---|---|
+| `UpdateFeedParserTest` | Legacy-Feed 1.44 ohne `<updatePackages>` parst korrekt; erweiterter Feed, Reihenfolge irrelevant; `<changeLog>` mit 8 Kindern → **keine** `ArrayIndexOutOfBoundsException`; kaputtes XML → leeres Ergebnis statt Exception; XXE-Payload wird nicht expandiert; `sha256` in Großbuchstaben wird normalisiert |
+| `UpdateFeedClientTest` | 200 → Zieldatei ersetzt; 404/500 → Temp gelöscht und **vorhandene Zieldatei unverändert** (die konkrete Regression gegenüber `UpdateChecker:54-71`); Timeout → `success=false`, kein Throw; leerer Body verworfen |
+| `UpdateCheckServiceTest` | 1.44.0/1.44.0 → kein Update; /1.45.0 → Update; /1.4.4 → kein Update; /1.44.1 → Update; kaputte `semanticVersion` → Double-Fallback statt Exception; Netz down + Cache → `CACHE`; ohne Cache → `NONE`; Paketauswahl je Typ; `UNKNOWN` → kein Paket; injizierte `Clock` für den Prüfrhythmus |
+| `RuntimePackageTypeResolverTest` | Property gewinnt; unbekannter Wert → `UNKNOWN`; `/.flatpak-info` → `FLATPAK` **auch gegen** widersprechende Property; `APPIMAGE` → AppImage; alles `null` → kein NPE |
+| `UpdateDownloadPolicyTest` | `http://` abgelehnt; fremder Host abgelehnt; fehlende/zu kurze/nicht-hex `sha256` abgelehnt; `fileName` mit `../` abgelehnt; Größe ≤ 0 abgelehnt; `FLATPAK`/`UNKNOWN` abgelehnt |
+| `UpdateDownloadServiceTest` | Ohne Netz über `com.sun.net.httpserver.HttpServer` auf Port 0 (JDK-only, keine neue Dependency): Hash-Mismatch → Temp gelöscht, Ziel **nicht** angelegt; Match → Bytes identisch; Non-2xx → Temp gelöscht; bereits gültige Datei → kein HTTP-Call; Progress monoton bis `totalBytes`; Abbruch → Temp gelöscht |
+| `UpdateLauncher*Test` (Stufe 3) | Injizierter `ProcessStarter` fängt die Kommandozeile: MSI → `[msiexec, /i, <abs>, /qb]`; deb/rpm/arch → `[xdg-open, <abs>]`; dmg → `[open, <abs>]`; **kein Kommando enthält `sudo` oder `pkexec`** (explizite Assertion); `FLATPAK`/`UNKNOWN`/`WINDOWS_ZIP` → `ProcessStarter` nie aufgerufen |
+| `website/test/version-info.test.js` | Klassifikator für alle Namensmuster; SHA256SUMS-Parsing inkl. Doppelspace; Release ohne Assets → Feed bleibt valide; erzeugter Feed hat weiterhin exakt 7 `<changeLog>`-Kinder |
+
+Versionsvergleich: bestehende `VersionUtils`-Abdeckung um nicht-numerische Eingaben ergänzen.
+
+---
+
+## Dokumentation
+
+Nach jeder Stufe eine gezielte Einordnung, kein Voll-Audit (`AGENTS.md`):
+
+- `github_docs/de-Installation.md` und `github_docs/en-Installation.md` — Windows-Installer, Verhältnis zum ZIP, Update-Weg je Paketformat, Flatpak-Hinweis. Beide Sprachversionen semantisch gleichziehen.
+- Neuer Abschnitt zur Updatefunktion (Hinweis, Zustimmung, Contest-Regel, Verhalten je Installationsart) — DE und EN.
+- `docs/PROJECT_CONTEXT.md` — Abschnitt „Website / Deployment Relationship" (`:192-200`) um Feed-Format, Paketkennzeichnung, Host-Allowlist und die Entscheidung gegen ein Updater-Binary ergänzen.
+- `website/src/features/` prüfen, ob die Funktion dort dargestellt werden soll.
+- Screenshots des Hauptfensters veralten durch den Hinweisbereich — als veraltet markieren, nicht erfinden.
+
+## Verifikation
+
+1. `./mvnw -B test` — **Surefire-Berichte einzeln lesen**, nicht am Exit-Code messen (`AGENTS.md`: Testfehler brechen den Build nicht ab). Hinweis: auf Host-JDK 26 schlagen 8 Mockito-Tests umgebungsbedingt fehl; mit Temurin 21 prüfen.
+2. `cd website && npm test && npm run build && npm run validate:version-info` gegen einen erweiterten Beispiel-Feed.
+3. **Abwärtskompatibilität:** erweiterten Feed gegen den **alten** `UpdateChecker` laufen lassen und bestätigen, dass `<latestVersion>` und `<changeLog>` unverändert gelesen werden.
+4. **Startverhalten:** Anwendung mit nicht erreichbarer Feed-URL starten — die UI muss ohne Verzögerung und ohne Meldung hochkommen.
+5. **Contest-Regel:** mit ON4KST verbunden erscheint kein Hinweis; nach dem Trennen erscheint er.
+6. **Paketkennzeichnung:** je Artefakt einmal starten und die erkannte Installationsart prüfen. Der Flatpak lässt sich lokal testen — die Sandbox ist netzwerkseitig transparent (verifiziert).
+7. **Stufe 2:** Download mit absichtlich falscher Prüfsumme — es darf keine Zieldatei entstehen und nichts gestartet werden.
+
+## Offene Punkte
+
+1. **Zweite Feed-Quelle?** Wenn der serverseitige Build hinterherhinkt, sehen Clients einen veralteten Feed. Soll der Client hilfsweise `https://github.com/praktimarc/kst4contest/releases/latest/download/kst4ContestVersionInfo.xml` verwenden?
+2. **`test-publish-version-xml.yml`** bleibt vorerst unverändert, ist aber scharf (Feed ohne `<semanticVersion>`). Bei der späteren Umstellung auf GitHub Actions zusammenführen oder entfernen.
+3. **`--app-version` überall setzen** ändert die Paketversion bestehender DEB/RPM-Installationen einmalig von `1.0` auf die echte. Akzeptabel?
+4. **`UpdateChecker.java`** löschen oder als deprecated Fassade behalten? (`module-info.java` exportiert `kst4contest.controller`.)
+5. **MSI vs. ZIP** — soll MSI der empfohlene Windows-Weg werden? Beide Installationen können parallel existieren; ein MSI-Upgrade findet eine ZIP-Installation nicht.
+6. **Opt-out-Preference?** Soll `ChatPreferences` ein „Check for updates on start" bekommen? Der Abruf verrät IP und Version an den Feed-Host.
+7. **Prüfrhythmus** — einmal pro Start, oder höchstens alle 24 h über einen Zeitstempel in `~/.praktiKST/`?
+8. **Beta-Nutzer** — `1.46.0-beta` gegen Stable `1.45.0` ergibt „kein Update", weil `compareStableVersions` das Suffix abschneidet. Gewollt?
+9. **Signaturzustand** darf nur automatisch aus dem Build stammen, sonst driftet er.
+10. **Vertrauensmodell** — soll der Feed mittelfristig selbst signiert werden (Detached-Signatur + eingebauter Public Key)?
+11. **ZIP-Migration** — der Hinweistext für den Wechsel ZIP → Installer muss formuliert und in beiden Sprachversionen dokumentiert werden.

docs/PROJECT_CONTEXT.md

@@ -0,0 +1,256 @@
+# KST4Contest Project Context
+
+Last reviewed: 2026-09-03
+
+This file is the durable technical project context for KST4Contest. It is not a user manual and not a replacement for the changelog. Current code, tests and authoritative external specifications remain the source of truth when this document is stale or ambiguous.
+
+## Purpose
+
+KST4Contest is a Java/JavaFX desktop client for ON4KST chat focused on VHF/UHF/microwave contest workflows. It combines chat handling with contest-oriented station prioritisation, sked/timeline workflows and integrations with logging, aircraft-scatter, rotor and DX-cluster tooling.
+
+## Current Architecture
+
+- Java 21 / JavaFX desktop application built with Maven.
+- Main code is under `src/main/java/kst4contest/`.
+- Responsibilities are separated across controller, service, logic, model, utility and view areas.
+- Network/parser/service/controller/UI boundaries should remain explicit.
+- Long-running network/message processing must tolerate malformed or incomplete external input without terminating processing threads.
+- JavaFX `ObservableList` state is a UI projection, not the canonical worker-thread domain store.
+
+## Important Invariants
+
+### Chat identity
+
+- For remote chat participants, the complete visible callsign plus category forms the chat-member identity.
+- Full callsign variants can therefore be distinct chat-member identities.
+- Base-call normalization is permitted only for explicitly base-call-wide functions.
+- Worked status is shared across suffix variants of the same base call.
+- Monitoring a variant such as `DN9APW-2` or `DN9APW-70` intentionally monitors the base call `DN9APW`.
+- Suffixes must not be globally interpreted as a band/category/frequency.
+
+### Band and availability semantics
+
+- ON4KST categories 2 and 3 are the main operational categories, but unexpected category values must fail safely.
+- `NOT-QRV` overrides positive inferred band-availability hints.
+- Unknown/missing frequency, QRB, QTF or similar external data must remain unavailable rather than becoming a fabricated zero/default.
+- Features that depend on frequency should use the current/actual QRG according to current implemented rules; do not silently revert to a fixed 144 MHz default.
+- Complete digit-only frequencies use their final three digits as the kHz part and are accepted only when the resulting MHz value lies within a supported `Band` range. The same full-frequency parser is used for station names and public or directed chat messages. Relative QRG rules and bare three-digit context handling remain separate.
+
+### JavaFX/threading
+
+Conceptually:
+
+```text
+thread-safe canonical domain state
+        |
+        | projection on JavaFX Application Thread
+        v
+JavaFX ObservableList / UI state
+```
+
+`MessageBusManagementThread` must not directly iterate or mutate UI-bound JavaFX collections. UI-visible changes should cross the controller/UI boundary and run on the JavaFX Application Thread.
+
+## Configuration and Layout Persistence
+
+- Configuration and layout live in the `preferences.xml` of the **active operator profile**; see "Operator Profiles and Per-Profile Persistence" below. The current `preferences.xml` configuration version is 7. Version 6 introduced optional managed leaf-column widths below `guiOptions`, identified by stable table and column IDs. Parent-column widths remain derived from their leaf columns.
+- `GUIstationMapClusteringEnabled` is a layout preference below `guiOptions`. It defaults to `true`, is selectively autosaved and controls only screen-based clustering of nearby map markers. Missing or malformed values retain the enabled default for backward compatibility.
+- Stored widths take precedence. Without a usable entry, a managed column is sized once when meaningful table data first becomes available. Message and similar free-text columns use a flexible initial width instead of following the longest value.
+- Main-window and separate-monitor DXCluster/QSO tables use distinct layout IDs even though they share the underlying message stores.
+- Window sizes and positions, relevant divider positions and managed column widths are selectively autosaved after a short debounce. A pending write is flushed during application shutdown.
+- Selective layout writes update the XML already on disk, preserve unknown XML nodes and must not persist unconfirmed functional settings from the current UI. **Save Settings** remains the full settings writer and includes the current layout.
+- Full and selective writes are synchronized and replace `preferences.xml` atomically. Missing, unknown or malformed width entries do not prevent loading and fall back to initial sizing.
+- Older configuration files require no migration. Older KST4Contest versions can ignore the additional elements; a complete rewrite by such a version may discard column widths without invalidating the remaining file.
+
+## Operator Profiles and Per-Profile Persistence
+
+- One operator profile owns one `preferences.xml` and one worked-station database. Everything else under `~/.praktiKST/` stays global: CSS, audio files, DEM and terrain packages, the error log and the version-info feed.
+- The **root profile** is the historic flat installation: `preferences.xml` and `praktiKST.db` directly below the application directory. It is never moved, and it always uses the common station database, because that database is the installation's own.
+- Additional profiles live under `profiles/<profileId>/`. `profileId` is a stable, file-system-safe slug assigned once; renaming a profile changes only its display name and never moves a directory.
+- The registry `profiles.xml` is created lazily. An installation that has only the flat layout gets no registry and no `profiles/` directory; the root profile is synthesised in memory. Startup with no or exactly one profile therefore asks nothing and writes nothing, and a downgrade to an older release is a no-op.
+- The registry stores `profileId`, `displayName`, `rootProfile` and `sharedWorkedDatabase`, never a path. Both file names are derived in `OperatorProfilePaths` alone, so a stored path cannot drift apart from the flag that produced it.
+- `sharedWorkedDatabase` resolves to a path, not to a schema change: a sharing profile points at the flat `praktiKST.db`, an owning profile at its own file. There is no owner column, and no SQL statement in `DBController` knows about profiles.
+- A profile database is created **empty**. The bundled `/praktiKST.db` resource carries several thousand foreign callsigns and `user_version = 0`; seeding an additional profile from it would show a new operator foreign data and trigger the full callsign-normalization rebuild. Only the root installation is seeded from the resource. `preferences.xml` of a new profile *is* seeded from `/praktiKSTpreferences.xml`, because its defaults are what a first installation gets.
+- Worked-state semantics are unchanged and now apply per database file: normalized base callsign as key, worked state shared across suffix variants, three-day expiry, manual reset.
+- `stn_loginCallSign` and `stn_loginCallSignRaw` default to empty. The preferences reader treats an empty element as "not set" and falls back to the field default, so a non-empty default would make a profile created without credentials come up carrying a compiled-in callsign.
+- Passwords remain plaintext per profile. Profiles separate configuration; they are explicitly not an access-control boundary. This is documented in both manuals.
+
+### Runtime profile switching
+
+- A switch tears the current runtime down through `Kst4ContestApplication.shutdownRuntime()` and builds a **new** `Kst4ContestApplication` instance. Reusing the instance is not possible: many controls are inline-initialised instance fields, so a second `start()` would re-parent mounted nodes and register every listener twice. The approach is only sound because the class holds no mutable static state.
+- `Platform.setImplicitExit(false)` is required, because closing every window during a switch would otherwise end the process. All exits therefore run through `ApplicationRuntimeLauncher.exitApplication()`, including the main window's close handler; JavaFX calls `stop()` only on the instance it launched itself.
+- `shutdownRuntime()` is idempotent and must release everything that outlives a disconnect: the ON4KST supervisor thread, the sked reminder scheduler, the reachability executor, the PSTRotator retry scheduler, the map tile proxy, the station map bridge listeners and its coalescing animation, both view timers and every owned stage. Several of these were real leaks before; they only became visible once a second runtime could exist.
+- `ApplicationConstants.sessionRuntimeUniqueId` must not be regenerated during a switch, so UDP readers started earlier still recognise their own poison pill.
+- The layout autosave is flushed and then cancelled before a switch, so a pending debounced write cannot land after the profile changed.
+
+## External Interfaces
+
+Treat current implementation/tests and authoritative upstream documentation as source of truth before modifying any interface.
+
+Known integration areas include:
+
+- ON4KST chat;
+- AirScout;
+- UCXLog / DXLog UDP XML (`contactinfo`, `contactreplace`);
+- Win-Test UDP;
+- PSTRotator TCP;
+- DXCluster;
+- local SQLite persistence.
+
+CR/LF framing, XML framing, ports/transports, callsign normalization and frequency formatting are protocol behaviour and must not be changed as incidental cleanup.
+
+### Local DX Cluster output
+
+- Local spots use a fixed 75-character, DXSpider-compatible payload line followed by two BEL characters and CRLF.
+- The DX callsign begins in column 27 and occupies up to 12 characters. The 30-character comment begins in column 40, and the five-character UTC time begins in column 71.
+- Spotter and frequency padding is calculated dynamically so frequencies from 50 MHz through 24 GHz do not shift the following fields.
+- Comments are padded or truncated to exactly 30 characters. Automatic AirScout comments retain the locator first and use the compact form `JO51HK AP 1m/100%;4m/75%`.
+- A DX callsign longer than 12 characters is rejected and logged rather than truncated.
+- Trigger conditions, QRG recognition and normalisation, login, keepalive, multi-client delivery and the local-only trust boundary remain separate from line formatting.
+
+### Logging and Worked-state persistence
+
+- The Simplelogfile interpreter reads the selected text file after connection startup and then once per minute using a fixed built-in callsign pattern.
+- Simplelogfile callsigns are normalized to base callsigns and set only the global Worked state for every active variant. They do not create per-band Worked or grid-square state.
+- Simplelogfile-derived Worked state is not persisted in SQLite. The selected file is the durable source and is read again in each application session.
+- The interpreter only adds positive runtime marks. It does not remove existing marks during the current session and does not reset automatically when a new contest starts. A database reset does not modify the file; callsigns contained in it are marked as worked again during the next periodic evaluation.
+- A missing selected file is created. Read, path and creation failures are contained so the periodic timer remains alive; successful creation triggers a one-time, non-blocking UI notice with the exact path and setup/contest checks.
+- Network-derived and manually assigned Worked, NOT-QRV and worked-grid state continues to use SQLite with its established lifetime and reset behaviour.
+- Each completed initial ON4KST user list loads one SQLite Worked/NOT-QRV snapshot. `ChatController` applies that snapshot by normalized base callsign to every new category and suffix variant before the completed category is published. The same event-driven path runs again after a reconnect; startup synchronization does not depend on a fixed-delay timer.
+- Automatic QRG updates require both an enabled source and valid incoming `RadioInfo` or Win-Test `STATUS` data. Merely enabling a source does not provide or validate a current QRG.
+- UCXLog-compatible QSO packets and Win-Test `ADDQSO` packets are converted into one validated external-QSO state. Logger-specific numeric, metre and centimetre values and Win-Test band IDs are normalised once; the resolved band is then the sole source for per-band Worked and worked-grid state.
+- A missing or unknown logger band sets only the global Worked state. Worked-grid state requires both a recognised project band and a valid locator; no band or locator is inferred. Packets without a usable callsign are discarded without terminating the listener.
+- External logger threads do not read or mutate the JavaFX user-list projection. `ChatController` applies global and per-band Worked state to every active variant of the base callsign on the JavaFX Application Thread before evaluating a band-upgrade notice.
+- The established Win-Test handling for 24, 47 and 76 GHz remains unchanged. Their Worked flags are retained, while only frequencies represented by the project `Band` model can create worked-grid state.
+
+### Win-Test log recovery
+
+- Win-Test only broadcasts new QSOs. A listener started later never sees the earlier ones, so KST4Contest pulls them with the Win-Test `IHAVE` / `NEEDQSO` protocol, ported from the wtKST `WtLogSync` implementation. The answers are ordinary `ADDQSO` packets and reuse the established Worked path; the recovery itself never touches database or UI.
+- The recovery is not configurable. It is bound to the existing Win-Test network listener, runs automatically once a station is detected through `HELLO` or `STATUS`, and stays active so gaps caused by lost broadcasts are refetched.
+- The station-name filter remains a QRG-sync setting. Log recovery covers every station in the network, because each band station of a multi-station setup keeps its own log and contributes per-band Worked state.
+- A QSO is identified by `StationName@LogUniqueID` plus the Win-Test QSO number. That identity deduplicates the answers of overlapping requests, so a recovered log is written once instead of once per resend.
+- Win-Test framing must be resolved on the raw datagram bytes: the checksum byte is not valid ASCII and would otherwise corrupt the trailing fields, which carry the log ID of `ADDQSO` and the run-length inventory of `IHAVE`. A broken checksum discards `IHAVE` only; the established handling of the other message types is unchanged and still does not verify checksums.
+- Win-Test answers broadcasts only; an identical unicast request to the same station stays unanswered (verified against Win-Test). Outgoing Win-Test packets therefore derive their broadcast address from the source address of received Win-Test packets, with the configured address as fallback for a station behind a router. A configured address pointing at a non-existent network raises no send error, so it silently disabled both log recovery and SKED handover before. Only genuine Win-Test message types update that address; internal control packets such as the poison pill must not redirect outgoing traffic.
+- `IHAVE` inventories are run-length encoded and may be split, so the announced first row is honoured instead of assuming that an inventory starts at QSO number one. A station that never sends a usable inventory is served by a blind block fallback starting at QSO number one.
+
+### Terrain data providers
+
+- The active terrain profile provider is Open-Meteo using Copernicus GLO-90 data.
+- The terrain profile cache lives in its own global database `~/.praktiKST/terrainprofilecache.db`. It is deliberately not part of an operator profile: terrain profiles are pure geometry derived from two locators and a sample count, and at a multi operator station both operators share one location, so a per-profile copy would only double the traffic against the terrain service.
+- Cached entries are separated by owner identity through the primary key (`owner_callsign_raw` + `owner_locator6`). Earlier versions stored a single owner identity in a meta table and dropped the whole cache whenever the configured callsign or locator changed; with several operator profiles that would discard every computed profile on each switch. The old `TerrainProfileCache*` tables inside `praktiKST.db` are left in place and are still readable by older releases; the new file starts empty and refills itself.
+- `OfflineDemImportService` only prepares a local directory and copies manually selected Copernicus GLO-30 GeoTIFF files into it. Importing files does not activate an offline provider or change the active calculation chain.
+
+### ON4KST session and authentication
+
+- One KST4Contest connection authenticates one ON4KST TCP session with one local login callsign and one password.
+- The TCP session uses one common locator for both categories; the locator is not part of authentication.
+- The primary category is part of the initial login. A distinct second category is added to the same session through ON4KST Single Sign-on; it must not create a second TCP connection or local login.
+- **Name in Chat** is a visible category-specific name field, not a login callsign or message destination. Private messages to the local station are addressed to the local login callsign.
+- The visible **Name in Chat** field, message context, QRG and beacon configuration remain category-specific.
+
+### ON4KST session liveness
+
+- After 90 seconds without inbound data, the application keeps the established empty CRLF heartbeat.
+- At about 180 seconds of inbound idle time, the TCP session sends one `RDXQ|<main chat id>|` probe. The probe state belongs to the session, so a two-category session still sends only one probe per idle phase.
+- Any subsequent inbound server frame confirms the probe. `DXQ` is accepted as the expected internal response and is not published as chat content.
+- If no inbound frame arrives by about 210 seconds, the existing reconnect flow remains responsible for replacing the session.
+- Probe diagnostics contain the session id, main category, opcode and timing only. They must not include credentials, complete server frames or normal chat messages.
+
+## User Workflow / UI Invariants
+
+- Contest operating speed and low-friction interaction are primary goals.
+- Incidental code changes must not unexpectedly change selection, focus, sorting, tab state, map zoom or prefilled text.
+- Map reset clears the selected target without changing zoom unless explicitly redesigned.
+- **Group nearby stations** re-renders only the existing station-marker layer from JavaScript `stationData`. It must not reload the WebView, tiles or station data, request a new controller snapshot, or change zoom, viewport or selection.
+- Base-callsign aggregation into one geographical marker happens before screen-based clustering. Disabling clustering displays each resulting positionable map station individually but never splits active variants of the same normalised base callsign into separate geographical markers.
+- Station selection preserves the established `/cq callsign` prefill behaviour.
+- Sending without an explicitly selected send category preserves the established Main-category fallback unless explicitly changed.
+
+## Autoanswer / Beacon
+
+- Automated-message loops must be prevented.
+- Cooldown/minimum-interval rules must be preserved.
+- A reply rejected before a complete valid TX item is queued must not consume cooldown.
+- Current implementation/tests define the exact message markers and timer details.
+
+## Build / Verification
+
+- Use the repository Maven wrapper (`.\mvnw.cmd` on Windows).
+- The project uses Java 21 / JavaFX 21.x at this context snapshot.
+- JUnit 5/Mockito, PMD and SpotBugs are part of the verification environment.
+- Build/test configuration has historically allowed some test/static-analysis failures not to fail the process exit code. Always read actual summaries/reports.
+
+## Documentation Surfaces
+
+- German and English manuals under `github_docs/`.
+- Repository README.
+- Eleventy-based project website under `website/`.
+- Changelog/release communication.
+- This technical project context under `docs/PROJECT_CONTEXT.md`.
+
+After implementation use targeted documentation-impact checks. Do not run a complete manual audit unless explicitly requested, release preparation is broad, or targeted checks indicate systematic drift.
+
+## Website / Deployment Relationship
+
+The repository contains the KST4Contest website under `website/`, published separately from the desktop application build.
+
+Current website/deployment scripts and update-feed behaviour must be inspected before changes; do not rely on historical assumptions.
+
+- `APPLICATION_CURRENT_VERSION` is the user-visible semantic version and must use the dotted `major.minor.patch` form. `APPLICATION_CURRENTVERSIONNUMBER` is retained only for older feeds and encodes patch releases by appending the patch digit, for example `1.43.1` as `1.431`.
+- The tagged-release workflow creates the GitHub Release before building the website update feed. This ordering is required because `versionInfo.js` reads the published release body through the GitHub Releases API.
+- After publication, the workflow tests and builds the website, validates the expected Stable version, attaches `kst4ContestVersionInfo.xml` to the release and uploads the complete website build as a workflow artifact.
+
+## Important Decisions and Workarounds
+
+- Preserve full callsign/category identity while applying base-call normalisation only to specifically defined features.
+- Keep canonical worker-thread domain state separate from JavaFX UI projections.
+- Preserve the established JavaFX WebView/Leaflet workaround that avoids problematic CSS 3D transforms unless the original rendering/flicker issue has been reproduced and the replacement is validated.
+- Deliberate test data, comments and Easter eggs are preserved unless explicitly changed.
+
+## Planned Technical Direction
+
+These are planned directions, not necessarily implemented behaviour:
+
+- improve propagation/path modelling using higher-resolution terrain data, including Copernicus GLO-30;
+- increase terrain/path sampling through a dedicated service/API;
+- support high-precision station locations (e.g. extended Maidenhead locators or direct GPS coordinates) while preserving compatible standard display;
+- improve terrain/Fresnel/diffraction/refraction modelling for VHF/UHF/microwave use;
+- evaluate/implement richer tropospheric/scatter models;
+- continue integration of aircraft-scatter and propagation data into reachability/contest workflows.
+
+Before implementing planned items, re-check current decisions and obtain a fresh concept approval.
+
+## Known Limitations / Maintenance Notes
+
+- Historical project context is useful but may be stale; current code/tests win.
+- External service/API behaviour must be verified against current upstream documentation when uncertain.
+- Screenshots in manuals/website may need targeted replacement after visible UI changes; never fabricate them.
+- `station_map_path_analysis.png` and `station_map_reset.png` predate the **Group nearby stations** checkbox in the map header. Replace them with current screenshots when suitable source images are available; the website reuses `station_map_path_analysis.png` through `/manual/assets/`.
+
+## Recent Significant Changes
+
+### 2026-08-25 – Durable project context introduced
+
+- Added a persistent technical context layer so future agents/developers can understand architecture, invariants and cross-project dependencies without replaying chat history.
+- Documentation maintenance uses targeted impact assessment rather than a full audit after every implementation.
+
+## Related Projects / Integration Points
+
+### KST4Contest website
+
+- Source is maintained inside this repository under `website/`.
+- User-facing feature/configuration changes may require a targeted website check.
+
+### hamradioonline.de
+
+- Serves as the broader amateur-radio umbrella site/infrastructure context.
+- KST4Contest content/download/manual links and related knowledge content may intersect with the broader site strategy.
+
+### Webserver / hosting infrastructure
+
+- KST4Contest website and other hamradioonline services depend on the hosting environment.
+- Operational details should be maintained in a private infrastructure context rather than duplicated into this public project context when sensitive.
+
+### Planned propagation / terrain service
+
+- Intended to provide richer terrain/propagation data (including higher-resolution Copernicus GLO-30-based processing) to KST4Contest and potentially related hamradioonline tooling.
+- Interface contracts must be documented on both provider and consumer sides when they become concrete.

github_docs/de-AirScout-Integration.md

@@ -2,7 +2,7 @@
 
 > 🇬🇧 [English version](en-AirScout-Integration) | 🇩🇪 Du liest gerade die deutsche Version
 
-AirScout (von DL2ALF) ist ein Programm zur Erkennung von Flugzeugen für den Aircraft-Scatter-Betrieb. KST4Contest ist eng mit AirScout integriert und zeigt reflektierbare Flugzeuge direkt in der Benutzerliste an.
+AirScout (von DL2ALF) berechnet Aircraft-Scatter-Gelegenheiten anhand aktueller Flugzeugpositionen. KST4Contest übernimmt diese Ergebnisse und zeigt für die jeweilige Gegenstation geeignete Flugzeuge direkt in der Benutzerliste an.
 
 > **Aircraft Scatter** ermöglicht sehr weitreichende Verbindungen auf VHF und höher – auch für Stationen mit geringer Höhe über NN oder ungünstigen topografischen Verhältnissen.
 
@@ -15,9 +15,9 @@ Download von AirScout:
 
 ---
 
-## Flugzeugdaten-Feeds (ADSB)
+## Flugzeugdaten-Feeds (ADS-B)
 
-Öffentliche Flugzeugdaten-Feeds im Internet sind oft unzuverlässig und begrenzt nutzbar. Eine empfohlene Alternative bietet **OV3T (Thomas)** mit einem dedizierten ADSB-Feed-Dienst:
+Öffentliche Flugzeugdaten-Feeds im Internet sind oft unzuverlässig und nur eingeschränkt nutzbar. Eine empfohlene Alternative bietet **OV3T (Thomas)** mit einem dedizierten ADS-B-Feed-Dienst:
 
 - https://airscatter.dk/
 - https://www.facebook.com/groups/825093981868542
@@ -28,7 +28,7 @@ Für diesen Dienst ist ein Account erforderlich. Bitte eine Spende für Thomas i
 
 ## AirScout einrichten
 
-### Schritt 1: ADSB-Feed in AirScout konfigurieren
+### Schritt 1: ADS-B-Feed in AirScout konfigurieren
 
 1. AirScout starten.
 2. In den AirScout-Einstellungen den OV3T-Feed-Account eintragen (Benutzername, Passwort, URL).
@@ -85,32 +85,40 @@ Andernfalls kann es zu fehlerhaften AP-Daten kommen.
 
 ## AP-Spalte in der Benutzerliste
 
-Nach der Einrichtung erscheint in der Benutzerliste eine **AP-Spalte** mit bis zu zwei reflektierbaren Flugzeugen pro Station.
+Nach der Einrichtung erscheint in der Benutzerliste eine **AP-Spalte**. Sie zeigt für jede Station die Ankunftszeit und das von AirScout berechnete Reflexionspotenzial der ersten beiden geeigneten Flugzeuge.
 
 Beispiel-Darstellung:
 
 | Station | AP-Info |
 |---|---|
-| DF9QX | 2 Planes: 0 min / 0 min, je 100% |
-| F5DYD | 2 Planes: 14 min / 31 min, je 50% |
+| DF9QX | 0 (100 %) / 0 (100 %) |
+| F5DYD | 14 (50 %) / 31 (50 %) |
+
+Die Zahl vor der Klammer gibt die verbleibenden Minuten bis zur berechneten Gelegenheit an. Die Prozentzahl beschreibt das von AirScout gemeldete Reflexionspotenzial. Sie ist keine QSO-Wahrscheinlichkeit.
 
 Die AP-Informationen sind auch im **Privatnachrichten-Fenster** verfügbar.
 
-Die Prozentzahl gibt das Reflexionspotenzial an (Größe des Flugzeugs, Höhe, Entfernung).
+## Einfluss auf Priority Score und Timeline
+
+Mindestens ein von AirScout als erreichbar gemeldetes Flugzeug erhöht den Priority Score der Station. Eine unmittelbar bevorstehende Gelegenheit in null, einer oder zwei Minuten wird zusätzlich zeitabhängig gewichtet. AirScout ist dabei nur ein Faktor neben Worked-Status, verfügbaren Bändern, QRB, Antennenrichtung, Chat-Aktivität und Skeds.
+
+Die AP- und Sked-Timeline verwendet den Priority Score zur Auswahl interessanter Stationen und ordnet die nächste geeignete Aircraft-Scatter-Gelegenheit zeitlich ein. Das Reflexionspotenzial bestimmt zusätzlich die Darstellung des AP-Symbols. Die Timeline bleibt eine Vorschau; sie garantiert kein QSO.
 
 ---
 
 ## AP-Variablen in Nachrichten
 
-Die Flugzeugdaten können direkt in Nachrichten eingefügt werden:
+Die Flugzeugdaten der ausgewählten Station können direkt in Shortcuts, Snippets und andere stationsbezogene Nachrichten eingefügt werden:
 
 - `FIRSTAP` → z. B. `a very big AP in 1 min`
 - `SECONDAP` → z. B. `Next big AP in 9 min`
 
 Details: [Makros und Variablen](de-Makros-und-Variablen#variablen)
 
+Da die Werte eine ausgewählte Gegenstation benötigen, stehen `FIRSTAP` und `SECONDAP` nicht als globale Beacon-Variablen zur Verfügung.
+
 ---
 
 ## „Show Path in AirScout"-Button
 
-In der Benutzerliste gibt es einen Button mit einem Pfeil, der die Richtung (QTF) zur ausgewählten Station anzeigt. Ein Klick maximiert AirScout und zeigt den Pfad mit reflektierbaren Flugzeugen zum ausgewählten Gesprächspartner.
+In der Benutzerliste gibt es einen Button mit einem Pfeil, der die Richtung (QTF) zur ausgewählten Station anzeigt. Ein Klick maximiert das externe AirScout-Fenster und lässt dort den Pfad zur ausgewählten Gegenstation mit den berechneten Aircraft-Scatter-Gelegenheiten anzeigen. Die Schaltfläche startet keine eigene Gelände- oder Ausbreitungsberechnung in KST4Contest.

github_docs/de-Benutzeroberflaeche.md

@@ -4,7 +4,7 @@
 
 ## Verbinden mit dem Chat
 
-Vor dem ersten Verbindungsaufbau müssen im Einstellungsfenster mindestens Rufzeichen, Passwort, Locator und primäre Chat-Kategorie konfiguriert werden. Soll zusätzlich eine zweite Kategorie verwendet werden, muss auch deren Login aktiviert und vollständig eingerichtet sein.
+Vor dem ersten Verbindungsaufbau müssen im Einstellungsfenster das lokale Login-Rufzeichen und Passwort, der gemeinsame Locator der TCP-Sitzung sowie die primäre Chat-Kategorie konfiguriert werden. Soll zusätzlich eine zweite Kategorie verwendet werden, wird sie dort aktiviert und ausgewählt. KST4Contest meldet sich einmal an und ergänzt die zweite Kategorie per Single Sign-on innerhalb derselben TCP-Sitzung.
 
 Die Verbindung kann auf zwei Wegen aufgebaut werden:
 
@@ -21,8 +21,6 @@ Ob die Verbindung lediglich als TCP-Verbindung besteht oder bereits vollständig
 
 ---
 
----
-
 ## Hauptfenster-Überblick
 
 Das Hauptfenster besteht aus mehreren Bereichen:
@@ -56,11 +54,20 @@ Beide Hinweise blinken ungefähr zwölf Sekunden und verschwinden anschließend
 
 ### PM-Fenster (oben links)
 
-Das PM-Fenster zeigt die an die eigenen Chat-Logins gerichteten Privatnachrichten und die zugehörigen ausgehenden Antworten.
+Das PM-Fenster zeigt die an das lokale Login-Rufzeichen adressierten Privatnachrichten und die zugehörigen ausgehenden Antworten.
+
+Nicht selbst gesendete Nachrichten erscheinen dort zusätzlich, wenn ihr Text ohne Beachtung der Groß- und Kleinschreibung das konfigurierte eigene Login-Rufzeichen enthält. Das gilt für öffentliche Nachrichten an `ALL` ebenso wie für gerichtete Nachrichten zwischen anderen Chatteilnehmern. Gerade im zweiten Fall lässt sich dieses PM-Catching flapsig als **„Lästererkennung“** bezeichnen.
+
+Der tatsächliche Empfänger, der Nachrichtentext, die Chat-Kategorie und das Routing bleiben unverändert. Die Nachricht erhält lediglich eine zusätzliche Darstellung im PM-Fenster.
 
 Ist das [QSO-Monitoring](de-Funktionen#qso-monitoring-ab-v131) aktiviert, erscheinen dort zusätzlich die erfassten Nachrichten der überwachten Basisrufzeichen. Diese Einträge erhalten eine `Sniffed:`-Kennzeichnung mit dem vollständigen sichtbaren Absender und Empfänger.
 
-Neue Nachrichten werden zunächst auffällig dargestellt und wechseln anschließend schrittweise zur normalen Tabellenfarbe. Die farbliche Hervorhebung dient nur als zeitlicher Hinweis; sie verändert weder Inhalt noch Routing der Nachricht.
+Neue, nicht selbst gesendete Zeilen durchlaufen sechs grüne Altersstufen und kehren nach fünf Minuten zur normalen Tabellenfarbe zurück. Eigene Nachrichten behalten ihre separate Hervorhebung. Die farbliche Darstellung ist nur ein zeitlicher Hinweis; sie verändert weder Inhalt noch Routing der Nachricht.
+
+Die Auswahl einer eingehenden Zeile bereitet eine Antwort an den Absender vor. Bei einer eigenen ausgehenden Nachricht wird stattdessen der ursprüngliche Empfänger als Nachrichtenziel wiederhergestellt. Caught- und Monitoring-Zeilen lösen keine PM-Audioausgabe aus.
+
+Altersstufen: [Farbige PM-Zeilen](de-Funktionen#farbige-pm-zeilen-ab-v125). Erkennung und Grenzen: [PM-Abfang](de-Funktionen#pm-abfang-catching-personal-messages-ab-v11).
+
 ### Benutzerliste (Chat Members)
 
 Die zentrale Tabelle aller aktuell aktiven Chat-Nutzer. Spalten (je nach Konfiguration):
@@ -145,7 +152,15 @@ Der Wert beeinflusst unter anderem:
 
 ---
 
-## Nachrichtentabellen
+## Tabellenbreiten und gekürzte Zellinhalte
+
+Beim ersten brauchbaren Datenbestand richtet KST4Contest die Spalten der Benutzerliste, der Nachrichtenansichten, der DXCluster- und QSO-Tabellen sowie der Worked-Datenbank einmalig nach Überschrift und vorhandenem Inhalt aus. Bereits gespeicherte Breiten haben Vorrang. **Name**, **AP** und **NOT QRV @** werden dabei begrenzt, damit einzelne lange Werte nicht den restlichen Tabellenbereich verdrängen. **Message** und vergleichbare Freitextspalten bleiben flexibel und richten sich nicht nach der längsten Nachricht.
+
+Manuell geänderte Spaltenbreiten werden automatisch gespeichert und beim nächsten Start wiederhergestellt. Spätere Nachrichten oder Stationsaktualisierungen überschreiben diese Auswahl nicht.
+
+Passt ein normaler Textwert nicht vollständig in seine Zelle, zeigt ein Tooltip den vollständigen Wert. Der Tooltip erscheint nur bei tatsächlich gekürztem Text. Funktionale Tooltips, etwa für QRA-, Worked- oder Bandzustände, bleiben erhalten; bei gekürztem Zelltext stehen Volltext und Erklärung gemeinsam im Tooltip.
+
+### Nachrichtentext und Links
 
 KST4Contest zeigt Nachrichtentexte bewusst einzeilig an. So bleiben auch bei hohem Chat-Aufkommen viele Einträge gleichzeitig sichtbar. Der Nachteil liegt auf der Hand: Bei einer schmalen **Message**-Spalte passt nicht jede Nachricht vollständig in die Zeile.
 
@@ -320,7 +335,11 @@ Ein einzelner Stationsmarker kann direkt angeklickt werden. KST4Contest:
 3. aktualisiert den **Further Info**-Bereich und
 4. bereitet das vollständige sichtbare Rufzeichen als `/cq`-Empfänger vor.
 
-Marker, die bei der aktuellen Zoomstufe zu dicht beieinanderliegen, werden als Cluster mit einer Stationsanzahl dargestellt. Ein Klick auf einen Cluster vergrößert den betreffenden Kartenausschnitt. Erst ein anschließend sichtbarer einzelner Marker wählt eine konkrete Station aus.
+Ist **Group nearby stations** ausgewählt, werden Marker, die bei niedrigen Zoomstufen zu dicht beieinanderliegen, als Cluster mit einer Stationsanzahl dargestellt. Ein Klick auf einen Cluster vergrößert den betreffenden Kartenausschnitt. Erst ein anschließend sichtbarer einzelner Marker wählt eine konkrete Station aus. Wird die Checkbox ausgeschaltet, zeigt die Karte unabhängig von der Zoomstufe alle positionierbaren Stationen als einzelne Marker.
+
+Das Umschalten wirkt sofort und verändert weder Zoom noch Kartenausschnitt oder Stationsauswahl. Die Einstellung wird automatisch gespeichert und beim nächsten Programmstart wiederhergestellt. Ohne gespeicherte Einstellung bleibt **Group nearby stations** ausgewählt, damit bestehende Installationen zunächst das bisherige Verhalten behalten.
+
+Der Schalter betrifft nur die räumlichen Cluster auf dem Bildschirm. Aktive Chatvarianten desselben normalisierten Basisrufzeichens können weiterhin einen gemeinsamen geografischen Marker verwenden und bleiben unabhängig davon getrennte Nachrichtenziele.
 
 Die Kopfzeile ergänzt bei ausgewählter Station:
 
@@ -425,7 +444,7 @@ Zusätzlich öffnet KST4Contest das Fenster **Cluster & QSO of the other**. Es z
 
 ![Separates Cluster- und QSO-Monitorfenster](cluster_qso_monitor.png)
 
-Die Position des vertikalen Dividers sowie die Fenstergröße werden zusammen mit den übrigen UI-Einstellungen gespeichert. Nach einer Änderung **Save Settings** verwenden.
+Die Position des vertikalen Dividers sowie die Fenstergröße werden automatisch gespeichert. Die DXCluster- und QSO-Tabellen besitzen hier eigene Spaltenbreiten; Änderungen im Monitorfenster verändern daher nicht das Tabellenlayout der Hauptfenster-Tabs.
 
 Das Fenster lässt sich über das Menü aus- und wieder einblenden:
 
@@ -471,13 +490,13 @@ Die serverbezogenen Funktionen sind nur bei vollständig aufgebauter ON4KST-Verb
 
 ## Fenstergrößen und Divider
 
-Beim Klick auf **Save Settings** speichert KST4Contest die Größen der Programmfenster und die Positionen der relevanten Divider in der Konfigurationsdatei. Diese Werte werden beim nächsten Programmstart wiederverwendet.
+KST4Contest speichert Größen und Positionen der Programmfenster, die relevanten Divider sowie manuell geänderte Tabellenbreiten automatisch nach einer kurzen Verzögerung in der Konfigurationsdatei. Ein ausstehender Layoutstand wird beim Programmende noch geschrieben. **Save Settings** ist dafür nicht erforderlich, speichert aber weiterhin den vollständigen aktuellen Stand einschließlich Layout.
 
 Das Hauptfenster wird beim Start zusätzlich gegen den sichtbaren Bereich des primären Bildschirms geprüft. Ist die gespeicherte Größe zu groß, verkleinert und verschiebt KST4Contest das Fenster so, dass es wieder erreichbar bleibt. Die genaue Herleitung ist unter [Bildschirmgerechte Größe des Hauptfensters](de-Funktionen#bildschirmgerechte-größe-des-hauptfensters-ab-v141) beschrieben.
 
-Für die übrigen Programmfenster gilt diese zusätzliche Größenbegrenzung derzeit nicht. Wird beispielsweise das separate Monitorfenster nach einem Wechsel auf einen kleineren Bildschirm zu groß dargestellt, muss seine Größe manuell korrigiert und anschließend erneut mit **Save Settings** gespeichert werden.
+Für die übrigen Programmfenster gilt diese zusätzliche Größenbegrenzung derzeit nicht. Wird beispielsweise das separate Monitorfenster nach einem Wechsel auf einen kleineren Bildschirm zu groß dargestellt, genügt eine manuelle Korrektur; die neue Größe wird automatisch gespeichert.
 
-Bei einer ungünstigen Aufteilung sollten zuerst die Divider an eine brauchbare Position verschoben und die Einstellungen erneut gespeichert werden. Das Löschen der Konfigurationsdatei setzt zwar die UI-Werte zurück, entfernt aber auch die übrigen gespeicherten Programmeinstellungen und sollte deshalb nur verwendet werden, wenn sich die Oberfläche auf anderem Weg nicht mehr herstellen lässt.
+Bei einer ungünstigen Aufteilung sollten zuerst die Divider und Spaltenbreiten wieder an brauchbare Positionen verschoben werden. Das Löschen der Konfigurationsdatei setzt zwar die UI-Werte zurück, entfernt aber auch die übrigen gespeicherten Programmeinstellungen und sollte deshalb nur verwendet werden, wenn sich die Oberfläche auf anderem Weg nicht mehr herstellen lässt.
 
 ---
 

github_docs/de-Changelog.md

@@ -8,10 +8,110 @@ Die veröffentlichten Stable-Versionen und ihre Programmpakete stehen unter [Git
 
 ---
 
-## v1.42 – Nightly / in Entwicklung
+## v1.50 (in Entwicklung)
 
-> Stand dieses Abschnitts: 14. August 2026.  
-> v1.42 ist noch kein veröffentlichtes Stable-Release. Bis zur Freigabe können weitere Änderungen hinzukommen.
+**Operator-Profile**
+
+Mehrere Operateure an einem Rechner können jetzt eigene Rufzeichen, Locators und Layouts verwenden, ohne sich gegenseitig die Konfiguration zu überschreiben. Damit ist [Issue #57](https://github.com/praktimarc/kst4contest/issues/57) umgesetzt.
+
+### Neu
+
+- **Operator-Profile:** Jedes Profil hat seine eigene `preferences.xml` und damit eigene fachliche Einstellungen und einen eigenen Layoutstand. Verwaltet werden Profile im neuen Reiter **Profiles** des Einstellungsfensters: anlegen, duplizieren, umbenennen, löschen und aktivieren.
+
+- **Gemeinsame oder eigene gearbeitete Stationen:** Pro Profil wird entschieden, ob es eine eigene Worked-Datenbank bekommt oder die gemeinsame Stationsdatenbank benutzt. Eine Multi-OP-Station mit einem einzigen Stationslog teilt den Worked-Status, zwei OMs mit verschiedenen Rufzeichen an einem Rechner trennen ihn.
+
+- **Profilwahl beim Start:** Mit nur einem Profil fragt KST4Contest beim Start nichts und verhält sich unverändert. Ab zwei Profilen erscheint eine kleine Auswahl mit vorausgewähltem letzten Profil; Enter oder Doppelklick starten sofort. Der Aufrufparameter `--profile=<Name>` überspringt die Auswahl.
+
+- **Profilwechsel im laufenden Betrieb:** **File → Switch operator profile...** trennt die Verbindung und baut die Oberfläche mit den Einstellungen des gewählten Profils neu auf, ohne Programmneustart.
+
+### Geändert
+
+- **Zwischenspeicher der Geländeprofile getrennt:** Berechnete Geländeprofile liegen jetzt in der eigenen, gemeinsam genutzten Datei `terrainprofilecache.db` und werden nach Besitzer getrennt gespeichert. Bisher wurde der gesamte Zwischenspeicher gelöscht, sobald sich Rufzeichen oder Locator änderten; bei einem Profilwechsel wäre damit jedes berechnete Profil verloren gegangen.
+
+- **Rufzeichen-Vorgabe ist leer:** Fehlt in der `preferences.xml` ein Login-Rufzeichen, bleibt das Feld jetzt leer, statt auf ein im Programm hinterlegtes Rufzeichen zurückzufallen. Ein neu angelegtes Profil startet damit bewusst ohne Anmeldedaten.
+
+### Behoben
+
+- **Freigegebene Hintergrundressourcen:** Der ON4KST-Überwachungsthread, der Sked-Erinnerungs-Scheduler, der Reachability-Executor, der PSTRotator-Wiederholungs-Scheduler und der Kachel-Proxy der Karte werden beim Schließen des Chatcontrollers freigegeben. Bisher liefen sie bis zum Programmende weiter.
+
+### Hinweise zur Aktualisierung
+
+- Bestehende Installationen werden **nicht** verändert: `preferences.xml` und `praktiKST.db` bleiben genau dort liegen, wo sie sind, und werden zum Profil **Default**. Es wird keine Datei verschoben oder kopiert.
+- Eine Profil-Registry entsteht erst beim Anlegen des zweiten Profils. Wer nur ein Profil benutzt, merkt von der Änderung nichts.
+- Eine Rückkehr zu einer älteren KST4Contest-Version bleibt möglich; sie findet ihre Dateien unverändert vor.
+- Passwörter stehen weiterhin im Klartext in der `preferences.xml` des jeweiligen Profils. Profile trennen die Konfiguration, sie sind kein Zugriffsschutz.
+
+---
+
+## v1.43.1 (2026-09-03)
+
+**Korrigierte Versionsmetadaten**
+
+v1.43.1 enthält dieselben funktionalen Änderungen wie v1.43.0. Korrigiert wurden die Anwendungs- und Build-Metadaten für Anzeige, ON4KST-Kennung und Update-Vergleich. Ein Teil der Metadaten des ersten v1.43.0-Pakets wies den Build noch als Version 1.42 aus.
+
+### Behoben
+
+- **Einheitliche semantische Version:** Die sichtbare Anwendungsversion verwendet jetzt vollständig `1.43.1`. Der kompakte Wert `1.431` bleibt ausschließlich im veralteten numerischen Feld für die Kompatibilität mit älteren Update-Feeds erhalten.
+
+- **Update-Feed im Tagged-Release-Workflow:** Website-Build, Prüfung des Versionsfeeds und Upload der Artefakte laufen jetzt tatsächlich nach der Veröffentlichung des GitHub Releases. Diese Schritte waren zuvor versehentlich in die Artefaktliste der Release-Action eingerückt und wurden deshalb übersprungen.
+
+Wer v1.43.0 installiert hat, sollte v1.43.1 verwenden. Die Funktionen bleiben unverändert; korrigiert werden nur die Versionsmetadaten und der Release-Workflow.
+
+Die korrigierte Version ist als [Release v1.43.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.43.1) verfügbar.
+
+---
+
+## v1.43.0 (2026-09-03)
+
+**Zuverlässigere Log-Synchronisation, gespeicherte Tabellenlayouts und bessere DX-Cluster-Kompatibilität**
+
+v1.43 konzentriert sich auf die zuverlässige Verarbeitung externer Logdaten und den stabilen Betrieb während längerer Conteste. Hinzu kommen praktische Einstellmöglichkeiten für Tabellenlayouts und die Stationsgruppierung auf der Karte.
+
+### Neu
+
+- **Optionale Kartencluster:** **Group nearby stations** schaltet die räumliche Gruppierung bei niedrigen Zoomstufen unmittelbar ein oder aus. Die gespeicherte Auswahl verändert weder Kartenausschnitt noch Stationsauswahl; die Zusammenfassung aktiver Varianten desselben Basisrufzeichens bleibt davon unabhängig. Damit ist [Issue #79](https://github.com/praktimarc/kst4contest/issues/79) umgesetzt.
+
+- **Tabellenlayout automatisch gesichert:** Tabellen erhalten beim ersten brauchbaren Inhalt sinnvolle Breiten. Manuell geänderte Spaltenbreiten, Fenstergrößen und relevante Divider werden nach kurzer Verzögerung in `preferences.xml` geschrieben. Haupt- und Monitorfenster behalten getrennte Layouts für DXCluster und QSO of the other.
+
+- **Tooltips für gekürzte Tabellenwerte:** Normale Tabellenzellen zeigen ihren vollständigen Inhalt, wenn die sichtbare Spalte zu schmal ist. Funktionale Tooltips und anklickbare Links bleiben davon unberührt.
+
+- **Hinweis bei neu angelegtem Simplelogfile:** Fehlt die ausgewählte Datei, legt KST4Contest sie an und zeigt einen Hinweis mit Dateipfad, konkretem Testablauf und Link zum passenden Abschnitt des Handbuchs.
+
+### Geändert
+
+- **Robuste Simplelogfile-Auswertung:** Die ausgewählte Datei wird einmal pro Minute ausgewertet und nach jedem Durchlauf geschlossen, damit das Logprogramm sie ersetzen oder rotieren kann. Erkannte Rufzeichen setzen den globalen Worked-Status für alle aktiven Suffixvarianten des Basisrufzeichens. Bei deaktivierter Funktion findet kein Dateizugriff statt; Lese- oder Erstellungsfehler beenden die periodische Aufgabe nicht mehr.
+
+- **Einheitliche Bandwerte externer Logger:** UCXLog-kompatible Pakete und Win-Test-Ereignisse verwenden eine gemeinsame Bandnormalisierung. Numerische Werte, Meter- und Zentimeterangaben sowie die vorhandenen Win-Test-IDs setzen damit dieselben Worked-Markierungen und Worked-Großfelder. Insbesondere `2320`, `5760` und `10368` werden zuverlässig verarbeitet; bei fehlendem oder unbekanntem Band wird nur der globale Worked-Status gesetzt.
+
+- **Kompakte vollständige Frequenzen erkannt:** Vollständige Frequenzangaben ohne Dezimaltrenner werden auf allen unterstützten Bändern akzeptiert; die letzten drei Ziffern bilden den kHz-Anteil. Nackte dreistellige Zahlen benötigen weiterhin einen erkennbaren Frequenzkontext, damit Signalrapporte und andere Zahlen nicht als QRG behandelt werden.
+
+- **DXSpider-kompatibles Spotformat:** Lokale DX-Cluster-Spots verwenden eine feste 75-Zeichen-Nutzzeile mit dem DX-Rufzeichen ab Spalte 27, einem 30 Zeichen breiten Kommentarfeld und der UTC-Zeit ab Spalte 71. Das Format bleibt bis 24 GHz stabil. Überlange DX-Rufzeichen werden verworfen und protokolliert, statt unbemerkt abgeschnitten zu werden. Damit ist [Issue #86](https://github.com/praktimarc/kst4contest/issues/86) behoben.
+
+- **Aktive ON4KST-Verbindungsprüfung:** Ein ruhiger Chatserver wird mit einer expliziten, sitzungsweiten Abfrage geprüft, bevor die Verbindung als unterbrochen gilt. Heartbeat und Prüftelegramme behalten das erforderliche CR/LF-Framing.
+
+- **Zuverlässige Altersmarkierung privater Nachrichten:** Eingehende Privatnachrichten verwenden bis zu fünf Minuten lang die definierten grünen Altersstufen. Eigene Nachrichten behalten ihre separate Darstellung; leere oder wiederverwendete Tabellenzeilen kehren zum normalen Design zurück und behalten keine veraltete Hervorhebung.
+
+### Behoben
+
+- **Worked-Status nach dem Login:** Persistierte SQLite-Informationen werden vor der Veröffentlichung jeder initialen ON4KST-Benutzerliste geladen und angewendet. Erneute Verbindungen, beide Kategorien und alle aktiven Varianten eines Basisrufzeichens starten dadurch mit dem richtigen Status. Damit ist [Issue #85](https://github.com/praktimarc/kst4contest/issues/85) behoben.
+
+- **Fehlerhafte Trennung bei ruhigem Server:** Eine gültige ON4KST-Verbindung wird nicht mehr beendet, nur weil der Server gerade keine Aktivitätszeilen überträgt.
+
+### Dokumentation und Auslieferung
+
+- Das deutsche und englische Handbuch wurden mit der Implementierung abgeglichen und überarbeitet. Ein neues Kapitel zum Contest-Workflow verbindet die einzelnen Funktionen zu einem praktischen Betriebsablauf; außerdem wurden die Abschnitte zu Dual Chat, Privatnachrichten, QRG-Synchronisation, Simplelogfile-Auswertung und Konfiguration präzisiert.
+
+- Die Website beschreibt Band- und Richtungsgelegenheiten, Stationskarte, QRG-Verarbeitung, Filter, globale Nachrichtenansichten, Privatnachrichten und Log-Synchronisation jetzt ausführlicher.
+
+- Die AUR-Paketdefinitionen wurden auf v1.43.0 aktualisiert.
+
+Die vollständige Funktionalität von v1.43.0 steht im [Release v1.43.0](https://github.com/praktimarc/kst4contest/releases/tag/v1.43.0) bereit. Wegen der inkonsistenten eingebetteten Versionsmetadaten ist v1.43.1 der empfohlene Paketstand.
+
+---
+
+## v1.42.0 (2026-08-22)
+
+**Gemeinsamer Bandkontext, sitzungsbasierte ON4KST-Verbindung und signierte macOS-Pakete**
 
 v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen, Worked-Status, NOT-QRV-Markierungen, Rufzeichensuffixe und Frequenzen werden dadurch konsistenter in der Benutzerliste, der Stationskarte, der Prioritätsberechnung und den externen Schnittstellen verwendet.
 
@@ -35,6 +135,8 @@ v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen,
 
 - **Manuelle QTF-Eingabe:** Die aktuelle Antennenrichtung kann auch ohne PSTRotator direkt in KST4Contest geändert werden.
 
+- **Nachrichtenvariable `MYQTF`:** Die aktuelle Antennenrichtung kann als numerischer Winkel in Grad in Shortcuts, Snippets und andere unterstützte Nachrichtentexte eingesetzt werden.
+
 - **Filter zurücksetzen:** Ein eigener Reset-Button entfernt die aktiven Filterprädikate der Benutzerliste zuverlässig.
 
 - **Kartencluster:** Räumlich dicht beieinanderliegende Stationen werden bei niedrigen Zoomstufen zusammengefasst. Die ausgewählte Station und relevante Richtungsgelegenheiten bleiben einzeln sichtbar.
@@ -71,7 +173,7 @@ v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen,
 
 - **Exakte Sked-Ziele:** Timeline und automatische Erinnerungen verwenden das vollständige sichtbare KST-Rufzeichen. Ein Sked für `DN9APW-2` wird nicht versehentlich an eine andere Variante desselben Basisrufzeichens gesendet.
 
-- **Beacon und Autoantwort überarbeitet:** Beide Chat-Kategorien verwenden einen gemeinsamen Timer, behalten aber getrennte Aktivierungsschalter und Texte. Das zulässige Mindestintervall beträgt zwei Minuten; Nachrichtentexte sind auf 120 Zeichen begrenzt. Die gespeicherte Beacon-Aktivierung wird beim Start aus der Konfiguration übernommen.
+- **Beacon und Autoantwort überarbeitet:** Beide Chat-Kategorien verwenden einen gemeinsamen Timer, behalten aber getrennte Aktivierungsschalter und Texte. Das zulässige Mindestintervall beträgt eine Minute; Nachrichtentexte sind auf 120 Zeichen begrenzt. Die gespeicherte Beacon-Aktivierung wird beim Start aus der Konfiguration übernommen.
 
 - **Variablen zentral aufgelöst:** Nachrichtenvariablen für Beacons, Shortcuts, Snippets und andere automatisch erzeugte Texte werden über einen gemeinsamen Resolver verarbeitet.
 
@@ -81,6 +183,8 @@ v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen,
 
 - **DXLog-Gesamtlog übernommen:** Der UCXLog-kompatible UDP-Listener verarbeitet neben `contactinfo` auch `contactreplace`. Dadurch kann ein von DXLog.net als vollständiges Log ausgesendeter Datenbestand eingelesen werden.
 
+- **Automatische QRG-Übernahme abgesichert:** `MYQRG` wird nur von einer aktivierten Schnittstelle aktualisiert, die tatsächlich gültige `RadioInfo`- beziehungsweise Win-Test-`STATUS`-Pakete liefert. Eine aktivierte, aber nicht liefernde Quelle ersetzt die notwendige Funktionsprüfung oder manuelle QRG-Pflege nicht.
+
 - **Versionserkennung verbessert:** Versionsnummern werden semantisch verglichen, damit beispielsweise Patch-Versionen und Nightly-Stände nicht mehr durch eine einfache Fließkommazahl falsch eingeordnet werden.
 
 ### Behoben
@@ -139,6 +243,8 @@ v1.42 führt mehrere bisher getrennte Auswertungen zusammen. Bandinformationen,
 
 - Eine genauere Konfiguration von Stationshöhe, Frequenz und K-Faktor wird in [Issue #74](https://github.com/praktimarc/kst4contest/issues/74) weiterverfolgt.
 
+Die veröffentlichte Version ist als [Release v1.42.0](https://github.com/praktimarc/kst4contest/releases/tag/v1.42.0) verfügbar.
+
 ---
 
 ## v1.41.1 (2026-07-08)
@@ -410,7 +516,6 @@ Erste öffentlich veröffentlichte Version. Grundfunktionen:
 
 ## Geplante Features
 
-- `MYQTF`-Variable (eigene Antennenrichtung als Text)
 - ~~Lebensdauer für den Worked-Status (automatisches Zurücksetzen)~~ ✅ **Umgesetzt in v1.40** (3-Tage-Lebensdauer, kein manuelles Zurücksetzen mehr nötig)
 - Filterung des „Cluster & QSO der anderen"-Fensters auf eigenes QTF
 - Weitere Topografie-basierte Berechnungen für die Richtungswarnung

github_docs/de-Contest-Workflow.md

@@ -0,0 +1,292 @@
+# Contest-Workflow mit KST4Contest
+
+> [English version](en-Contest-Workflow) | Du liest gerade die deutsche Version
+
+KST4Contest fasst Chat, Stationsauswahl, bekannte QRGs, Worked-Status, Skeds, Aircraft-Scatter-Zeiten und weitere Stationsdaten in einer gemeinsamen Oberfläche zusammen. Der Nutzen entsteht nicht aus einer einzelnen Anzeige, sondern aus dem Zusammenspiel dieser Informationen während des laufenden Contests.
+
+Diese Seite beschreibt einen vollständigen Arbeitsablauf. Die einzelnen Funktionen und ihre technischen Grenzen werden weiterhin in den Kapiteln [Funktionen](de-Funktionen), [Benutzeroberfläche](de-Benutzeroberflaeche), [Log-Synchronisation](de-Log-Synchronisation) und [AirScout-Integration](de-AirScout-Integration) erläutert.
+
+---
+
+## Zweck und Grenzen
+
+KST4Contest soll die Zeit zwischen einer erkannten Möglichkeit und dem tatsächlichen QSO verkürzen.
+
+Das Programm kann unter anderem anzeigen:
+
+- welche Stationen aktiv sind,
+- auf welchen Bändern und QRGs sie zuletzt erkannt wurden,
+- welche Stationen bereits gearbeitet wurden,
+- welche zusätzlichen Bänder noch infrage kommen,
+- welche Kandidaten zur aktuellen Antennenrichtung passen,
+- wann ein Aircraft-Scatter-Fenster erwartet wird und
+- welche Station gerade in eine für die eigene Station brauchbare Richtung arbeitet.
+
+Diese Angaben bleiben Entscheidungshilfen. Ein hoher Prioritätsscore ist keine QSO-Wahrscheinlichkeit. Auch eine von AirScout mit 100 % bewertete Reflexionsgeometrie garantiert kein QSO. Ob eine QRG tatsächlich frei ist, die Gegenstation zuhört und der Funkweg unter den aktuellen Bedingungen funktioniert, muss der Operator weiterhin selbst beurteilen.
+
+---
+
+## Vor dem Contest
+
+Die wesentlichen Einstellungen sollten nicht erst unmittelbar vor dem ersten interessanten Sked geprüft werden.
+
+### Grundkonfiguration
+
+Prüfe mindestens:
+
+- eigenes Rufzeichen, Passwort und Locator,
+- primäre Chat-Kategorie,
+- Login und Einstellungen der zweiten Kategorie, falls sie verwendet wird,
+- lokal aktive Bänder,
+- Antennenöffnungswinkel,
+- maximale sinnvolle Entfernung,
+- `MYQRG` und gegebenenfalls `SECONDQRG`,
+- Log-Synchronisation und
+- benötigte Shortcuts, Snippets und Nachrichtenvariablen.
+
+Antennenöffnungswinkel und maximale Entfernung sind stationsabhängig. Bei DM5M wird die reale Antennenanlage beispielsweise mit einem Öffnungswinkel von 69° und einer maximalen Entfernung von 900 km abgebildet. Das sind keine allgemeinen Vorgabewerte.
+
+Speichere dauerhafte Änderungen mit **Save Settings**. Nach dem Verbindungsaufbau sollte der `LINK`-Indikator grün sein. Erst dann sind Anmeldung und Benutzerlistensynchronisation vollständig abgeschlossen.
+
+### Automatische Antworten
+
+Die automatische QRG-Antwort gehört zum aktiven Contest-Workflow. Sie beantwortet wiederkehrende QRG-Anfragen und nimmt dem Chatter damit einen Teil der Routinearbeit ab.
+
+Davon zu unterscheiden ist die allgemeine automatische Antwort. Sie kann auf sämtliche eingehenden Anfragen reagieren und ist vor allem dann sinnvoll, wenn die Station vorübergehend nicht QRV ist oder nicht am Sked-Betrieb teilnehmen möchte. Sie erspart sowohl der eigenen Station als auch den anfragenden Stationen unnötige Folgefragen.
+
+### Optionale Anbindungen
+
+Aktiviere nur die Schnittstellen, die tatsächlich verwendet und vorher getestet wurden:
+
+- Logprogramm beziehungsweise Simplelogfile,
+- TRX-Synchronisation,
+- AirScout,
+- PSTRotator,
+- Win-Test-Skedübergabe und
+- lokaler DX-Cluster-Server.
+
+Ein Contest ist ein ungünstiger Zeitpunkt, um gleichzeitig die Funkbedingungen und eine erstmals aktivierte Netzwerkschnittstelle zu untersuchen.
+
+Beim Simplelogfile sollte vor jedem Contest geprüft werden, ob das Logprogramm die aktuelle Contestdatei an den in KST4Contest ausgewählten Pfad schreibt. Ein Test-QSO muss innerhalb einer Minute als global gearbeitet erscheinen. KST4Contest setzt die aus dieser Datei abgeleiteten Worked-Markierungen beim Contestwechsel nicht automatisch zurück.
+
+---
+
+## Grundablauf während des Contests
+
+Der typische Ablauf wiederholt sich:
+
+1. CQ rufen oder einen vereinbarten Sked durchführen.
+2. Chat, Prioritätsliste, Karte und AP-Timeline beobachten.
+3. Einen geeigneten Kandidaten auswählen.
+4. Eigene oder fremde QRG festlegen.
+5. QSO versuchen.
+6. Erfolgreiches QSO sofort loggen.
+7. Eine weitere Bandmöglichkeit prüfen.
+8. Einen erfolglosen, aussagekräftigen Versuch mit **Sked fail** kennzeichnen.
+9. Zum CQ-Betrieb oder zum nächsten Kandidaten zurückkehren.
+
+KST4Contest hält die benötigten Informationen zwischen diesen Schritten zusammen. Das eigentliche Umschalten, Rufen, Hören und Entscheiden bleibt bewusst beim Operator.
+
+---
+
+## CQ-Betrieb
+
+Bei einer weitgehend festen CQ-QRG sollten `MYQRG` beziehungsweise `SECONDQRG` den tatsächlich verwendeten Frequenzen entsprechen. Eine aktivierte und tatsächlich liefernde TRX-Synchronisation kann `MYQRG` automatisch aktualisieren. Die Aktivierung allein reicht nicht: Vor dem Contest sollte mit einer realen Frequenzänderung geprüft werden, ob gültige Pakete ankommen. Ohne funktionierende automatische Quelle muss der Wert von Hand gepflegt werden.
+
+Der Beacon kann die aktuelle QRG, den Locator und die Antennenrichtung regelmäßig im Chat veröffentlichen. Seine Variablen werden bei jedem Sendedurchlauf erneut ausgewertet.
+
+Wird während des CQ-Betriebs über mehrere Frequenzen gescannt, sollte der Beacon deaktiviert werden. Eine automatisch veröffentlichte QRG ist nur hilfreich, solange sie noch stimmt.
+
+Shortcuts und Snippets sollten die regelmäßig benötigten Nachrichten abdecken, beispielsweise:
+
+- Bitte auf der eigenen QRG hören,
+- QRG der Gegenstation erfragen,
+- Wechsel zur QRG der Gegenstation ankündigen,
+- Antennenrichtung bestätigen und
+- einen Sked vorschlagen.
+
+Einzelheiten stehen unter [Makros und Variablen](de-Makros-und-Variablen).
+
+---
+
+## Kandidaten auswählen
+
+Die Benutzerliste kann mit QTF-, QRB-, Worked-, Band-, Aktivitäts-, New-Bands-, Tropo- und AirScout-Filtern auf den aktuellen Betriebszustand begrenzt werden.
+
+Die Prioritätsliste und die AP-Timeline ergänzen diese Auswahl:
+
+- Der Prioritätsscore fasst mehrere bekannte Kriterien zusammen.
+- Die AP-Timeline ordnet Skeds und erwartete Aircraft-Scatter-Möglichkeiten zeitlich ein.
+- Die Stationskarte zeigt die geografische Lage, Antennenrichtung und den Funkweg.
+- Der Worked- und Bandstatus verhindert unnötige Doppelarbeit.
+
+![Prioritätsliste und Bewertungsinformationen](priority_score_overview.png)
+
+Der Score ist eine Sortierhilfe. Prüfe vor einem Versuch weiterhin Rufzeichen, Kategorie, Band, QRG, Richtung, Entfernung und die Aktualität der zugrunde liegenden Informationen.
+
+Eine bewusste Auswahl in Benutzerliste, Prioritätsliste, Timeline oder Karte übernimmt den konkreten Chatmember. Dabei bleiben das vollständige sichtbare Rufzeichen und die zugehörige Chat-Kategorie erhalten. KST4Contest bereitet anschließend `/cq RUFZEICHEN` im Sendfeld vor.
+
+---
+
+## Eigene oder fremde QRG verwenden
+
+Wenn eine gute Ausbreitungsrichtung erkannt wird und ein passendes Flugzeug für einen Kandidaten vorhanden ist, wird die Gegenstation zunächst häufig auf die eigene QRG gebeten. Das ist besonders sinnvoll, wenn dort bereits CQ gerufen wird und die Station ohne weiteren Umbau sofort empfangen kann.
+
+Reagiert die Gegenstation nicht, ist ihre eigene QRG geeigneter oder kann sie die angefragte QRG nicht verwenden, wird gewechselt. KST4Contest hält die zuletzt erkannten QRGs bereit, damit der Operator nicht erneut den gesamten Chatverlauf durchsuchen muss.
+
+Auch ein gezielter Versuch auf der QRG eines Sked-Partners ist Teil des normalen Workflows. Entscheidend ist nicht, grundsätzlich auf der eigenen QRG zu bleiben, sondern die vorhandene Möglichkeit mit möglichst wenig Verzögerung zu nutzen.
+
+Vor dem Wechsel sollten mindestens geprüft werden:
+
+- korrektes Band,
+- vollständiges Zielrufzeichen,
+- QRG der Gegenstation,
+- Antennenrichtung,
+- erwartetes Aircraft-Scatter-Fenster und
+- Belegung der QRG.
+
+---
+
+## Richtungsgelegenheiten nutzen
+
+Eine gerichtete Nachricht zwischen zwei anderen Stationen kann zeigen, dass der Absender seine Antenne ungefähr in Richtung des Empfängers ausgerichtet hat. Passt diese Richtung auch zur eigenen Station, markiert KST4Contest den Absender vorübergehend grün und fett.
+
+![Grün und fett markierte Richtungsgelegenheit](direction_opportunity_highlight.png)
+
+Die Markierung erscheint in der Benutzerliste und den zugehörigen Ansichten. Bei geeigneter Cluster-Konfiguration und bekannter QRG kann die Gelegenheit zusätzlich über den lokalen DX-Cluster ausgegeben werden.
+
+Damit stehen im entscheidenden Moment bereits mehrere Informationen zur Verfügung:
+
+- vollständiges Rufzeichen,
+- Locator und Richtung,
+- zuletzt erkannte QRG,
+- Bandinformationen,
+- AirScout-Daten und
+- die aktuelle Reachability- beziehungsweise Tropo-Auswertung.
+
+Der Operator muss diese Daten nicht erst zusammensuchen. Er muss lediglich entscheiden, ob die Gelegenheit den laufenden CQ-Betrieb kurz unterbrechen darf.
+
+Bei DM5M lag die Erfolgsquote solcher opportunistischen Versuche nach der bisherigen praktischen Auswertung ungefähr bei 35–40 %. Dieser Wert beschreibt die Erfahrung einer konkreten Station. Er ist keine allgemeine Erfolgsprognose und hängt unter anderem von Band, Entfernung, Stationsausrüstung, Reaktionszeit und Ausbreitungsbedingungen ab.
+
+Nach dem Versuch kann unmittelbar weiter CQ gerufen oder mit dem nächsten Sked fortgefahren werden.
+
+---
+
+## Skeds planen und auswerten
+
+Ein Sked sollte mit dem tatsächlich vorgesehenen Band und einer realistischen Uhrzeit eingetragen werden. KST4Contest übernimmt ihn in die eigene Sked-Verwaltung und berücksichtigt ihn bei Erinnerungen, Timeline und Prioritätsberechnung.
+
+Die Skeds werden nur für die laufende Programmsitzung verwaltet. Sie sind kein dauerhafter Ersatz für Contestlog oder Notizen.
+
+Ist die Win-Test-Anbindung aktiviert, versucht KST4Contest den Sked zusätzlich an Win-Test zu übergeben. Fehlt eine verwendbare QRG oder passt das Band nicht, bleibt der interne Sked trotzdem erhalten. Lediglich die zusätzliche Übergabe kann dann entfallen.
+
+### Fehlgeschlagene 100-%-Airplane-Skeds
+
+Scheitert ein sorgfältig vorbereiteter Versuch trotz einer von AirScout mit 100 % bewerteten Reflexionsgeometrie, sollte die Station mit **Sked fail** gekennzeichnet werden.
+
+Die 100-%-Anzeige ist keine Erfolgswahrscheinlichkeit. Ein Fehlschlag unter diesen Bedingungen ist aber ein brauchbarer betrieblicher Hinweis darauf, dass der Funkweg mit der aktuellen Stationskonfiguration und den aktuellen Bedingungen nicht funktioniert hat.
+
+Die Kennzeichnung reduziert die Priorität der Station für den Rest der laufenden Sitzung. Dadurch können zunächst Kandidaten bearbeitet werden, für die noch keine vergleichbar deutliche negative Betriebserfahrung vorliegt.
+
+**Sked fail** darf nicht als dauerhafte Aussage verstanden werden, dass die Station grundsätzlich nicht erreichbar ist. Andere Bedingungen, ein anderes Band oder eine geänderte Stationskonfiguration können zu einem anderen Ergebnis führen. Die Kennzeichnung kann zurückgesetzt werden und bleibt nicht über einen Programmneustart erhalten.
+
+---
+
+## Nach jedem QSO: Log und weiteres Band
+
+Ein erfolgreiches QSO sollte sofort im angebundenen Logprogramm eingetragen werden. Nur dann können Worked-Status, Bandstatus, Filter und Prioritätsbewertung zeitnah aktualisiert werden.
+
+Welche Details übernommen werden können, hängt von der Logquelle ab. Einige Schnittstellen liefern Band, QRG und Locator, während einfachere Quellen nur einen globalen Worked-Status melden.
+
+Unmittelbar nach jedem Logeintrag sollte geprüft werden, ob für dieselbe Station ein weiteres gemeinsames, lokal aktiviertes und noch nicht gearbeitetes Band vorhanden ist. KST4Contest weist darauf mit `BAND+` und den Bandinformationen der Station hin, soweit die vorhandenen Daten eine solche Bewertung erlauben.
+
+Diese Prüfung ist in allen Multiband-Betriebsarten sinnvoll. Die Gegenstation kann direkt mit einer konkreten Band- und Frequenzangabe weiterkoordiniert werden, bevor sie ihre Antenne wieder wegdreht oder einen anderen Sked beginnt.
+
+Im Klartext: Das nächste mögliche QSO sollte geprüft werden, solange die Gegenstation noch erreichbar und der gemeinsame Kontext noch vorhanden ist.
+
+Ist die Station auf einem angezeigten Band tatsächlich nicht QRV, sollte das Band als NOT QRV markiert werden. Dadurch verschwindet die unbrauchbare Möglichkeit aus Filtern und Bewertung, statt bei jeder Aktualisierung erneut aufzutauchen.
+
+---
+
+## Mehrkategorien- und Multibandbetrieb
+
+Der Mehrkategorienbetrieb ist bei Multibandstationen keine Nebenfunktion. Sein wesentlicher Vorteil besteht darin, dass Informationen aus zwei Chat-Kategorien in einem gemeinsamen Arbeitsablauf ausgewertet werden.
+
+Besonders groß ist der Vorteil bei:
+
+- Einmann-Multibandstationen,
+- Multi-Operator-Multibandstationen mit einem zentralen Chat-Koordinator und
+- Stationen, die nach einem QSO regelmäßig direkt ein weiteres Band versuchen.
+
+Worked-Status, bekannte Bandaktivitäten und Band Opportunities können gemeinsam bewertet werden. Das konkrete Nachrichtenziel behält trotzdem sein vollständiges Rufzeichen und seine Chat-Kategorie.
+
+Dadurch kann der Chatter eine Station unmittelbar vom ersten QSO auf das nächste Band koordinieren, ohne Rufzeichen, QRG und Bandstatus erneut zusammensuchen zu müssen. Im praktischen Betrieb kann daraus eine sehr schnelle Folge nutzbarer QSO-Möglichkeiten entstehen. Genau an dieser Stelle entfaltet der Mehrkategorienbetrieb seinen größten Workflow-Vorteil.
+
+Auch im Einmannbetrieb bleibt diese Arbeitsweise wirksam. Der Operator muss den Bandwechsel zwar selbst durchführen, erhält aber die nächste sinnvolle Möglichkeit bereits vorbereitet.
+
+Multi-Multi-Stationen mit mehreren gleichzeitig arbeitenden Chattern profitieren ebenfalls. Dort müssen Zuständigkeiten, Bandwechsel und bereits laufende Anfragen allerdings klar koordiniert werden. Mehrere Chatter mit denselben Informationen sind hilfreich; mehrere widersprüchliche Sked-Anfragen an dieselbe Station eher nicht.
+
+---
+
+## Praxisbeispiele
+
+### DM5M: Erst CQ, später mehr Skeds
+
+Bei DM5M wird während der ersten vier bis fünf Stunden eines VHF-/UHF-Contests überwiegend CQ gerufen. Der Chat wird beobachtet, aber nur für wenige gezielte Eingriffe verwendet.
+
+Später nimmt der Sked-Betrieb deutlich zu. Gute Ausbreitungsrichtungen, passende Aircraft-Scatter-Fenster, noch nicht gearbeitete Stationen und zusätzliche Bandmöglichkeiten werden dann gezielt miteinander kombiniert.
+
+Eine geeignete Station wird zunächst auf die eigene QRG gebeten. Reagiert sie nicht oder ist die QRG bei der Gegenstation nicht verwendbar, wechselt DM5M auf deren QRG. Auch geplante Versuche direkt auf der QRG eines Sked-Partners gehören dazu.
+
+Eine grün und fett markierte Richtungsgelegenheit kann den CQ-Betrieb kurzfristig unterbrechen. Nach dem Versuch wird unmittelbar weitergerufen oder der nächste Sked bearbeitet.
+
+Dieser Ablauf ist ein Praxisbeispiel und keine verpflichtende Betriebsart. Andere Stationen können wesentlich früher skedden, dauerhaft zwischen QRGs wechseln oder den Chat von Beginn an intensiver nutzen.
+
+### G1YBB: Richtungsgelegenheiten systematisch abarbeiten
+
+G1YBB verwendet die Richtungsanzeige besonders konsequent. Grün markierte Stationen werden systematisch geprüft und nach Möglichkeit gearbeitet, während parallel der normale CQ-Betrieb weiterläuft.
+
+KST4Contest automatisiert dabei nicht das QSO. Der Vorteil besteht darin, dass QRG, Richtung, Aircraft-Scatter-Informationen und weitere Bewertungsdaten bereits vorliegen, wenn die Gelegenheit entsteht. Die verbleibende Aufgabe ist eine schnelle betriebliche Entscheidung.
+
+Eine weitere, besonders konsequente Betriebsweise nutzt die Stationskarte als geografische Arbeitsliste:
+
+1. Der **wkd**-Filter blendet bereits gearbeitete Rufzeichen aus der Benutzerliste und damit auch aus der Karte aus.
+2. G1YBB wählt eine interessante Station auf der Karte aus.
+3. **Trigger cluster spot** übergibt die bekannte QRG an Minos.
+4. Ein Klick auf den Spot wechselt in Minos auf diese QRG.
+5. Nach dem QSO wird der Kontakt geloggt.
+6. Die Log-Synchronisation aktualisiert den Worked-Status; der Filter entfernt die Station anschließend aus Benutzerliste und Karte.
+
+Die Karte wird so zu einer räumlichen Liste der noch abzuarbeitenden Stationen. Dieser Ablauf ist optional. Er setzt eine zuverlässig eingerichtete Log-Synchronisation und DX-Cluster-Verbindung voraus und ist vor allem für Operatoren interessant, die den Contest bewusst auf diese geografische Weise strukturieren möchten.
+
+[G1YBB zeigt diesen Workflow im Video.](https://www.youtube.com/watch?v=lMQZMiSHlUI)
+
+---
+
+## Optionale Schnittstellen im Workflow
+
+| Schnittstelle | Aufgabe im Contest |
+|---|---|
+| [Log-Synchronisation](de-Log-Synchronisation) | Aktualisiert Worked- und Bandstatus nach dem QSO |
+| [AirScout](de-AirScout-Integration) | Liefert Aircraft-Scatter-Kandidaten und erwartete Zeitfenster |
+| [PSTRotator](de-Konfiguration) | Übernimmt oder setzt die Antennenrichtung |
+| [Win-Test](de-Log-Synchronisation) | Kann angelegte Skeds zusätzlich an Win-Test übergeben |
+| [DX-Cluster-Server](de-DX-Cluster-Server) | Übergibt erkannte Möglichkeiten an verbundene Logprogramme |
+| [Stationskarte](de-Benutzeroberflaeche) | Zeigt Stationen, Richtungen, Auswahl und Funkweg |
+
+Keine dieser Schnittstellen ist für den grundlegenden Chatbetrieb zwingend erforderlich. Ihr Wert entsteht dann, wenn sie zuverlässig eingerichtet ist und eine konkrete manuelle Aufgabe verkürzt.
+
+---
+
+## Was KST4Contest nicht entscheidet
+
+KST4Contest entscheidet nicht:
+
+- ob eine QRG tatsächlich frei ist,
+- ob die Gegenstation gerade hören kann,
+- ob ein Flugzeug ein QSO ermöglicht,
+- ob eine berechnete Funkstrecke unter den aktuellen Bedingungen funktioniert,
+- ob ein laufender CQ-Ruf für eine Gelegenheit unterbrochen werden sollte oder
+- welcher Kandidat für die aktuelle Conteststrategie den größten Wert besitzt.
+
+Das Programm stellt die vorhandenen Informationen zusammen und hält sie aktuell. Die letzte Entscheidung bleibt beim Operator. Das ist keine Einschränkung des Workflows, sondern der Teil, für den weiterhin Funkbetrieb statt Tabellenkalkulation betrieben wird.

github_docs/de-DX-Cluster-Server.md

@@ -23,7 +23,7 @@ Im Klartext: Die Information muss nicht erst im Chat gefunden, gelesen, gemerkt
 
 ---
 
-## Wie wird eine Richtungsgelegenheit hergeleitet?
+## Automatische Spots aus Richtungsgelegenheiten
 
 Angenommen, Station A schreibt eine gerichtete Nachricht an Station B. KST4Contest verwendet die Richtung von A zu B als Näherung für die aktuelle Antennenrichtung von Station A. Anschließend wird geprüft, ob die eigene Station aus Sicht von A innerhalb des angenommenen Antennenkorridors liegt.
 
@@ -51,6 +51,22 @@ Das Verfahren berücksichtigt weder Gelände noch aktuelle Ausbreitungsbedingung
 
 ---
 
+## Manueller Spot für die ausgewählte Kartenstation
+
+Ein Spot kann auch bewusst ausgelöst werden. Wähle dazu eine Station auf der Stationskarte und verwende **Trigger cluster spot** im Detailbereich.
+
+Diese manuelle Auslösung benötigt keine zuvor erkannte gerichtete Nachricht. Auch maximaler QRB und Antennen-Öffnungswinkel entscheiden in diesem Fall nicht darüber, ob der Spot gesendet wird. Erforderlich sind:
+
+- ein aktivierter lokaler DX-Cluster-Server,
+- mindestens ein verbundener DX-Cluster-Client und
+- eine für die ausgewählte Kartenstation verwendbare QRG.
+
+Damit kann der Operator eine bereits ausgewählte Station gezielt in die Bandmap übernehmen, auch wenn die Bedingungen für einen automatischen Richtungs-Spot nicht vorliegen. Die Bedienung der Karte ist unter [Stationskarte](de-Benutzeroberflaeche#stationskarte) beschrieben.
+
+Automatische und manuelle Spots werden ausschließlich an die mit KST4Contest verbundenen Clients gesendet. Es erfolgt keine Weiterleitung an einen öffentlichen Internet-Cluster.
+
+---
+
 ## Welche Frequenz wird verwendet?
 
 Ein DX-Cluster-Spot benötigt eine eindeutige Frequenz. KST4Contest verwendet dafür dieselbe QRG-Erkennung wie die Benutzerliste und die übrigen bandbezogenen Funktionen.
@@ -147,7 +163,7 @@ Die Schaltfläche **Send test spot** erzeugt folgenden Testeintrag:
 
 ```text
 Spotted callsign: DO5AMF
-Comment: Testing DXC-Spot: Congrats, you donated $100!
+Comment: DXC test: You donated $100!
 Frequency: .300 des konfigurierten Fallback-Bandes
 ```
 
@@ -171,12 +187,21 @@ Ein Spot enthält:
 
 - das konfigurierte Spotter-Rufzeichen,
 - die normalisierte Frequenz,
-- das Rufzeichen der erkannten Station,
+- das vollständige sichtbare Rufzeichen der erkannten oder ausgewählten Station,
 - den Locator,
-- Flugzeug-Scatter-Informationen, falls vorhanden,
 - die aktuelle UTC-Zeit.
 
-Wenn für die Station aktuelle Aircraft-Scatter-Informationen vorliegen, kann KST4Contest diese als zusätzliche AP-Information in den Kommentar des Spots aufnehmen.
+Die Nutzzeile folgt einem festen, DXSpider-kompatiblen 75-Zeichen-Format. Das DX-Rufzeichen beginnt in Spalte 27, das Kommentarfeld umfasst genau 30 Zeichen und die UTC-Zeit beginnt in Spalte 71. Kurze Kommentare werden mit Leerzeichen aufgefüllt, längere kontrolliert auf 30 Zeichen begrenzt. Unterschiedlich lange Spotter-Rufzeichen und Frequenzen bis 24 GHz verschieben die nachfolgenden Felder nicht.
+
+Das vollständige DX-Rufzeichen wird nicht abgeschnitten. Ist es länger als zwölf Zeichen, verwirft KST4Contest den Spot stattdessen kontrolliert und protokolliert den Grund.
+
+Bei automatisch erzeugten Richtungs-Spots kann KST4Contest bis zu zwei aktuelle AirScout-Einträge als zusätzliche AP-Information in den Kommentar aufnehmen. Fehlende AirScout-Daten verhindern den Spot nicht. Ein manuell über die Stationskarte ausgelöster Spot verwendet den Locator der ausgewählten Station ohne diese optionale Ergänzung.
+
+Ein kompakter Kommentar mit AirScout-Information sieht beispielsweise so aus:
+
+```text
+JO51HK AP 1m/100%;4m/75%
+```
 
 ---
 
@@ -193,7 +218,7 @@ Prüfe:
 - Blockiert eine Firewall die Verbindung?
 - Ist im Logger das DX-Cluster-Fenster beziehungsweise die Bandmap aktiviert?
 
-### Testspot funktioniert, aber reale Spots fehlen
+### Testspot funktioniert, aber automatische Spots fehlen
 
 Dann funktioniert die Verbindung grundsätzlich. Für die betreffende Chat-Situation war wahrscheinlich mindestens eine fachliche Bedingung nicht erfüllt:
 
@@ -205,12 +230,34 @@ Dann funktioniert die Verbindung grundsätzlich. Für die betreffende Chat-Situa
 
 KST4Contest sendet absichtlich nicht jede gefundene Frequenz an den Logger. Andernfalls würde aus einer Arbeitserleichterung sehr schnell eine lokale Spot-Schleuder.
 
+### Manuell ausgelöster Spot fehlt
+
+Prüfe, ob auf der Karte eine Station ausgewählt ist und für sie eine verwendbare QRG vorliegt. Der lokale Server muss aktiviert und mindestens ein Client verbunden sein. Die Geometrie einer gerichteten Nachricht, maximaler QRB und Antennen-Öffnungswinkel sind für die manuelle Auslösung keine Voraussetzungen.
+
 ### Der Spot erscheint auf dem falschen Band
 
 Prüfe zuerst, welche Frequenzen für die betreffende Station innerhalb der letzten 30 Minuten erkannt wurden. Bei einer relativen Angabe hat dieser Stationskontext Vorrang vor dem globalen Fallback.
 
 Ist kein aktueller Stationskontext vorhanden, prüfe die Auswahl unter **Fallback band for relative QRG detection**. Das Fallback wird nur benötigt, wenn sich das Band weder aus einer vollständigen Frequenz noch aus dem aktuellen Kontext des Absenders ergibt.
 
+### Das Logprogramm läuft in einer eigenen Sandbox
+
+Ein Logprogramm, das als Flatpak oder über eine Wine-Umgebung wie Bottles gestartet wird, benutzt die Netzwerkrechte dieser Sandbox. Teilt die Sandbox das Netzwerk des Rechners nicht, ist `127.0.0.1` darin nicht das `127.0.0.1`, auf dem KST4Contest lauscht. Die Verbindung wird dann abgewiesen, obwohl KST4Contest den Port korrekt meldet.
+
+Bei einem Flatpak-Logprogramm lassen sich die Rechte so prüfen:
+
+```bash
+flatpak info --show-permissions <Anwendungs-ID>
+```
+
+Im Abschnitt `[Context]` muss `shared=network` stehen. Nachträglich vergeben lässt es sich mit:
+
+```bash
+flatpak override --user --share=network <Anwendungs-ID>
+```
+
+Das Gleiche gilt, wenn KST4Contest selbst als Flatpak läuft. Dessen veröffentlichtes Manifest enthält `--share=network` bereits, ein lauschender Port ist daher vom Rechner selbst und von anderen Anwendungen darauf erreichbar.
+
 ### Der Spot wird vom Logger ausgeblendet
 
 Verwende ein Spotter-Rufzeichen, das nicht mit dem eigenen Contest-Rufzeichen identisch ist. Abhängig vom Logger können eigene Spots gefiltert oder besonders behandelt werden.
@@ -223,5 +270,6 @@ Die Schnittstelle wurde mit folgenden Logprogrammen verwendet:
 
 - UCXLog
 - N1MM+
+- Minos
 
 Weitere Logger können funktionieren, wenn sie eine normale TCP-Verbindung zu einem DX-Cluster-Server unterstützen.

github_docs/de-Funktionen.md

@@ -23,6 +23,10 @@ Angenommen, Station A schreibt eine gerichtete Nachricht an Station B:
 
 Ein eingetragener Öffnungswinkel von `70°` ergibt damit einen angenommenen Korridor von jeweils `35°` links und rechts der Richtung von Station A zu Station B.
 
+![Geometrie der angenommenen Antennenkorridore](directional_opportunity_geometry.png)
+
+Im dargestellten Beispiel verläuft der grüne Korridor von F5FEN in Richtung DM5M. Sendet F5FEN eine gerichtete Nachricht an DM5M, prüft KST4Contest, ob die eigene Station innerhalb dieses Korridors liegt. Bei einer Antwort von DM5M an F5FEN wird die Richtung neu berechnet: Dann beginnt der blaue Korridor bei DM5M und zeigt in Gegenrichtung auf F5FEN. Bewertet wird also bei jeder Nachricht die angenommene Antennenrichtung des jeweiligen Absenders.
+
 | Beispiel | Ergebnis |
 |---|---|
 | Richtung A → B: `120°`, Richtung A → eigene Station: `145°` | Winkeldifferenz `25°`: Richtungsgelegenheit erkannt |
@@ -80,13 +84,15 @@ KST4Contest wertet deshalb den Text jeder öffentlichen und gerichteten Chat-Nac
 
 | Schreibweise | Beispiel | Verarbeitung |
 |---|---|---|
-| Vollständige Frequenz | `144.210`, `432,088`, `10368.100` | Das Band ergibt sich direkt aus der Frequenz. |
+| Vollständige Frequenz | `144.210`, `432,088`, `144307`, `10368100` | Das Band ergibt sich direkt aus der Frequenz. |
 | Relative Frequenz mit Punkt oder Komma | `.210`, `,088` | Das Band wird aus dem Stationskontext oder dem konfigurierten Fallback ergänzt. |
 | Dreistellige Frequenz mit Textkontext | `qrg 210`, `freq is 210`, `on 210`, `210 MHz` | Die Zahl wird als relative Frequenz behandelt. |
 | Dreistellige Zahl ohne Frequenzkontext | `210`, `599`, `144` | Die Zahl wird absichtlich nicht als QRG übernommen. |
 
 Die letzte Einschränkung verhindert plausible, aber falsche Ergebnisse. Mit einem Fallback von `144 MHz` ließe sich ein Signalrapport `599` technisch problemlos zu `144.599 MHz` zusammensetzen. Das Ergebnis wäre formal gültig und fachlich trotzdem Unsinn.
 
+Eine vollständige Frequenz kann auch ohne Punkt oder Komma geschrieben sein. KST4Contest behandelt dabei die letzten drei Ziffern als kHz-Anteil: `144307` im Namensfeld wird zu `144.307 MHz`, `10368100` in einer öffentlichen oder gerichteten Chatnachricht zu `10368.100 MHz`. Der Wert wird nur übernommen, wenn die daraus entstehende Frequenz innerhalb eines unterstützten Bandbereichs liegt.
+
 ### Wie wird das Band einer relativen QRG bestimmt?
 
 KST4Contest verwendet folgende Reihenfolge:
@@ -132,7 +138,7 @@ Diese Trennung ist notwendig. Ein bereits gearbeitetes Rufzeichen kann auf einem
 
 Die [Log-Synchronisation](de-Log-Synchronisation) übernimmt neue QSOs aus dem Logprogramm. Welche Informationen dabei zur Verfügung stehen, hängt von der verwendeten Schnittstelle ab:
 
-- Der dateibasierte Simplelogfile-Interpreter erkennt nur das Rufzeichen. Er kann deshalb lediglich den globalen Worked-Status setzen.
+- Der dateibasierte Simplelogfile-Interpreter liest die ausgewählte Textdatei einmal pro Minute mit einem festen Rufzeichenmuster. Treffer werden auf das Basisrufzeichen normalisiert und setzen für alle aktiven Varianten lediglich den globalen Worked-Status.
 - Die QSO-UDP-Schnittstellen und der Win-Test-Netzwerk-Listener können zusätzlich das Band übernehmen.
 - Enthält das Logpaket einen gültigen Locator, speichert KST4Contest außerdem das gearbeitete vierstellige Großfeld für dieses Band.
 
@@ -201,24 +207,12 @@ Im Klartext: Ein erkannter Hinweis bedeutet „wahrscheinlich auf diesem Band ak
 
 ### Speicherung und Lebensdauer
 
-Worked-, NOT-QRV- und Großfeldinformationen werden in der internen SQLite-Datenbank gespeichert und beim nächsten Start wieder geladen. Die Einträge laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist deshalb normalerweise nicht erforderlich.
+Worked-, NOT-QRV- und Großfeldinformationen aus den Netzwerkschnittstellen sowie manuelle Markierungen werden in der internen SQLite-Datenbank gespeichert und beim nächsten Start wieder geladen. Die Einträge laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist deshalb normalerweise nicht erforderlich.
+
+Simplelogfile-Treffer sind davon ausgenommen. Sie werden nicht in SQLite persistiert, sondern bei jedem Programmlauf aus der ausgewählten Datei abgeleitet. Die Datei ist damit die dauerhafte Quelle. Der Interpreter entfernt während der laufenden Sitzung keine bereits gesetzte Worked-Markierung und setzt den Zustand beim Wechsel zu einem neuen Contest nicht automatisch zurück. Ein manueller Datenbank-Reset verändert oder leert die Datei ebenfalls nicht. Darin enthaltene Rufzeichen werden bei der nächsten Auswertung innerhalb einer Minute erneut als gearbeitet markiert.
 
 Ein manueller Reset unter **Workedstn database** entfernt sämtliche Worked-Markierungen, NOT-QRV-Tags und gespeicherten Worked-Großfelder. Die bekannten Rufzeichenzeilen bleiben dabei in der Datenbank erhalten. Einzelheiten: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).
 
-
----
-
-## NOT-QRV-Tags (ab v1.2)
-
-Wenn eine Station mitteilt, dass sie auf einem bestimmten Band nicht QRV ist, kann dies manuell markiert werden:
-
-1. Station in der Benutzerliste auswählen.
-2. Rechtsklick → NOT-QRV für das entsprechende Band setzen.
-
-Diese Tags werden in der internen Datenbank gespeichert und bleiben nach einem Neustart von KST4Contest erhalten. Zurücksetzen über die Einstellungen möglich.
-
-**Nutzen**: Verhindert wiederholte Sked-Anfragen auf Bändern, auf denen die Station nicht QRV ist – schont sowohl die eigenen Nerven als auch die der Gegenstation.
-
 ---
 
 ## Richtungsfilter (Direction Filter)
@@ -247,19 +241,33 @@ Die Filter oberhalb der Benutzerliste greifen auf dieselben Informationen zurüc
 
 Mehrere aktivierte Filter werden gemeinsam angewendet. Eine Station bleibt nur sichtbar, wenn sie alle gewählten Bedingungen erfüllt. Die Filter reagieren unmittelbar auf neue Logeinträge und geänderte NOT-QRV-Markierungen.
 
-Bedienung und Aufbau der Filterleiste: [Benutzeroberfläche – Filter](de-Benutzeroberflaeche#filter).
+Bedienung und Aufbau der Filterleiste: [Benutzeroberfläche – Filter](de-Benutzeroberflaeche#filter-und-reachability-steuerung).
 
 ---
 
 ## Farbige PM-Zeilen (ab v1.25)
 
-Neue Privatnachrichten erscheinen in **Rot**. Die Farbe wechselt alle 30 Sekunden über Gelb bis Weiß – wie ein Regenbogen-Fade. So ist auf einen Blick erkennbar, wie aktuell eine Nachricht ist.
+Neue eingehende Privatnachrichten werden in mehreren grünen Altersstufen hervorgehoben. Mit zunehmendem Alter wird das Grün schrittweise gedämpfter:
+
+| Alter der Nachricht | Darstellung |
+|---|---|
+| bis einschließlich 30 Sekunden | erste grüne Stufe |
+| 31 bis 60 Sekunden | zweite grüne Stufe |
+| 61 bis 90 Sekunden | dritte grüne Stufe |
+| 91 bis 120 Sekunden | vierte grüne Stufe |
+| 121 bis 180 Sekunden | fünfte grüne Stufe |
+| 181 bis 300 Sekunden | sechste grüne Stufe |
+| ab 301 Sekunden | normale Tabellenfarbe |
+
+Die Tabelle aktualisiert die Altersdarstellung alle fünf Sekunden. Ein Grenzübergang kann deshalb erst beim nächsten Aktualisierungslauf sichtbar werden. Nach fünf Minuten bleibt keine Altersklasse an der Zeile haften; auch wiederverwendete oder leere Tabellenzeilen kehren zu ihrem normalen Stil zurück.
+
+Eigene Nachrichten erhalten weiterhin eine separate Hervorhebung und verwenden nicht die grüne Altersskala.
 
 *(Idee von IU3OAR, Gianluca Costantino – danke!)*
 
 ---
 
-## PM-Abfang (Catching Personal Messages)
+## PM-Abfang (Catching Personal Messages, ab v1.1)
 
 Manche Nutzer senden Direktnachrichten versehentlich öffentlich, z. B.:
 
@@ -267,7 +275,17 @@ Manche Nutzer senden Direktnachrichten versehentlich öffentlich, z. B.:
 (DM5M) pse ur qrg
 ```
 
-KST4Contest erkennt solche Nachrichten, die das eigene Rufzeichen enthalten, und sortiert sie automatisch in die **Privatnachrichten-Tabelle** ein. So gehen keine Nachrichten verloren.
+KST4Contest sucht im Text aller nicht selbst gesendeten Nachrichten ohne Beachtung der Groß- und Kleinschreibung nach dem konfigurierten eigenen Login-Rufzeichen. Ein Treffer erscheint zusätzlich in der **Privatnachrichten-Tabelle**. Das gilt sowohl für öffentliche Nachrichten an `ALL` als auch für gerichtete Nachrichten zwischen anderen Chatteilnehmern.
+
+Gerade bei einer fremden gerichteten Nachricht wirkt das etwas wie **„Lästererkennung“**. Das ist eine flapsige Nebenbezeichnung, kein formaler Funktionsname.
+
+Die ursprüngliche Nachricht bleibt unverändert: Der tatsächliche Empfänger bleibt `ALL` beziehungsweise der andere Chatteilnehmer; auch Text, Chat-Kategorie und Routing bleiben erhalten. PM-Catching ergänzt nur eine weitere Ansicht derselben Nachricht.
+
+Die Textsuche versteht keine Absicht. Ein Schreibfehler oder ein verkürztes Rufzeichen wird nicht erkannt. Umgekehrt kann eine bloße Erwähnung des vollständig geschriebenen Rufzeichens einen Treffer erzeugen, obwohl keine Antwort erwartet wird.
+
+Wird eine eingehende Zeile in der PM-Tabelle ausgewählt, bereitet KST4Contest eine Antwort an ihren Absender vor. Bei einer eigenen ausgehenden Nachricht wird stattdessen der ursprüngliche Empfänger als Ziel wiederhergestellt. Die Auswahl versendet noch keine Nachricht.
+
+Auch abgefangene Zeilen verwenden die normale Altersanzeige der PM-Tabelle. Sie lösen jedoch weder den einfachen PM-Hinweiston noch die CW- oder Sprachausgabe für ein eingehendes Rufzeichen aus. Dasselbe gilt für Nachrichten, die durch das QSO-Monitoring zusätzlich in der PM-Tabelle erscheinen.
 
 ---
 
@@ -294,21 +312,21 @@ Konfiguration, erkannte QRG-Anfragen und genaue Kategorienzuordnung: [Konfigurat
 
 ## Multi-Channel-Login (ab v1.26)
 
-Gleichzeitiger Login in **zwei Chat-Kategorien** (z. B. 144 MHz und 432 MHz). Beide Chats werden parallel überwacht.
+KST4Contest meldet sich mit einem lokalen Login-Rufzeichen und Passwort einmal bei ON4KST an. Ein gemeinsamer Locator gilt für die gesamte TCP-Sitzung. Eine zweite Chat-Kategorie (z. B. 144 MHz und 432 MHz) wird per Single Sign-on innerhalb derselben Sitzung ergänzt. Beide Kategorien werden parallel überwacht; das sichtbare kategoriebasierte Namensfeld, der Nachrichtenkontext, die QRG und der Beacon bleiben je Kategorie getrennt.
 
 ---
 
 ## Dark Mode (ab v1.26)
 
-Aktivierbar über: **Window → Use Dark Mode**
+Aktivierbar über **Windows → Use dark mode design**. Mit **Windows → Use default mode design** wird wieder auf das normale helle Farbschema umgeschaltet.
 
-Für individuelle Farbanpassungen: CSS-Datei bearbeiten (Pfad in den Programmunterlagen).
+Die grüne Altersskala der Privatnachrichten bleibt in beiden Darstellungen erhalten. Textfarbe, normale Tabellenfarbe und die separate Hervorhebung eigener Nachrichten folgen dem jeweils geladenen Standarddesign.
 
 ---
 
 ## Opposite Station Multi-Callsign Login-Tagging (ab v1.26)
 
-Unterstützung für Stationen, die mit mehreren Rufzeichen gleichzeitig im Chat aktiv sind (z. B. Expedition-Setups).
+Unterstützung für Gegenstationen, die mit mehreren vollständigen sichtbaren Rufzeichenvarianten gleichzeitig im Chat aktiv sind (z. B. Expedition-Setups). Vollständiges Rufzeichen und Chat-Kategorie bleiben getrennte Teilnehmeridentitäten; Worked-, Band- und Prioritätsdaten werden über das Basisrufzeichen gemeinsam ausgewertet.
 
 ---
 
@@ -320,7 +338,7 @@ Für ausgewählte Stationen in der Benutzerliste gibt es direkte Buttons, um das
 
 ## Skeds und Sked-Erinnerungen
 
-> Verfügbar ab v1.40; Band-, Rufzeichen- und Win-Test-Behandlung erweitert in Nightly / v1.42.
+> Verfügbar ab v1.40; Band-, Rufzeichen- und Win-Test-Behandlung erweitert in v1.42.
 
 Ein Sked ist mehr als eine Erinnerung an eine Uhrzeit. Er muss während des laufenden Contestbetriebs rechtzeitig sichtbar werden, die vereinbarte Station priorisieren und – sofern gewünscht – die Gegenstation noch einmal an den Termin erinnern.
 
@@ -424,7 +442,7 @@ Sniffed: (DN9APW-70 > 9A0BB-23) pse sked 19:30
 
 Das ist ein wichtiger Unterschied. Das Monitoring fasst die Varianten zusammen, damit keine Nachricht übersehen wird. Das Nachrichtenrouting fasst sie nicht zusammen, weil andernfalls nicht mehr eindeutig wäre, welcher Login tatsächlich angesprochen wurde.
 
-Das Basisrufzeichen wird außerdem unabhängig von der Chat-Kategorie ausgewertet. Ist KST4Contest gleichzeitig mit zwei Kategorien verbunden, gilt derselbe Monitoring-Eintrag für beide Nachrichtenströme. Die Kategorie der einzelnen Nachricht bleibt dabei erhalten.
+Das Basisrufzeichen wird außerdem unabhängig von der Chat-Kategorie ausgewertet. Sind in derselben ON4KST-Sitzung zwei Kategorien aktiv, gilt derselbe Monitoring-Eintrag für beide Nachrichtenströme. Die Kategorie der einzelnen Nachricht bleibt dabei erhalten.
 
 Erfasst werden:
 
@@ -507,7 +525,7 @@ UDP selbst bestätigt außerdem keine Paketzustellung. Bleibt die QTF unverände
 
 Im Klartext: KST4Contest liefert die Zielrichtung und verarbeitet die gemeldete Position. Die mechanische Realität bleibt Aufgabe des Rotators – und gelegentlich der Blick aus dem Fenster.
 
-Konfiguration und Portbelegung: [Konfiguration – PSTRotator-Einstellungen](de-Konfiguration#pstrotator-einstellungen-ab-v131-vollstaendig-konfigurierbar-ab-v140).
+Konfiguration und Portbelegung: [Konfiguration – PSTRotator-Einstellungen](de-Konfiguration#pstrotator-einstellungen-ab-v131-vollständig-konfigurierbar-ab-v140).
 
 ---
 
@@ -590,7 +608,7 @@ Die Bewertung wird für das normalisierte Basisrufzeichen vorgenommen. Ein Sked
 
 ### Wie werden mehrere SSIDs und Chat-Kategorien behandelt?
 
-Aktive Rufzeichen wie `9A0BB-2`, `9A0BB-70`, `9A0BB-23` und `9A0BB-13` bleiben getrennte Chatmember. Dadurch können Nachrichten weiterhin an das vollständige Rufzeichen und die richtige Chat-Kategorie adressiert werden.
+Aktive vollständige sichtbare Rufzeichenvarianten wie `9A0BB-2`, `9A0BB-70`, `9A0BB-23` und `9A0BB-13` bleiben getrennte Chatmember. Dadurch können Nachrichten weiterhin an das vollständige Rufzeichen und die richtige Chat-Kategorie adressiert werden.
 
 Worked-, Band-, NOT-QRV- und Score-Informationen beziehen sich dagegen auf das gemeinsame Basisrufzeichen `9A0BB`. Der Score wird deshalb einmal berechnet und auf alle aktiven Varianten übertragen. Die Benutzerliste kann mehrere getrennte Zeilen mit demselben Score enthalten; in der Prioritätsliste erscheint das Basisrufzeichen nur einmal.
 
@@ -689,7 +707,7 @@ Die Timeline ist eine Vorschau. AirScout-Daten können sich ändern, und ein ein
 
 KST4Contest kann wiederkehrende CQ-Nachrichten in den öffentlichen Chat senden. Der Beacon ist für längeres CQ-Rufen auf einer festen Frequenz gedacht: Die eigene QRG wird regelmäßig veröffentlicht, ohne dass derselbe Text von Hand wiederholt werden muss.
 
-Beide Chat-Kategorien verwenden ein gemeinsames Intervall, besitzen aber jeweils einen eigenen Aktivierungsschalter und Nachrichtentext. Der zweite Beacon wird nur gesendet, wenn auch der zweite Chat aktiviert und verbunden ist.
+Beide Chat-Kategorien verwenden ein gemeinsames Intervall, besitzen aber jeweils einen eigenen Aktivierungsschalter und Nachrichtentext. Der zweite Beacon wird nur gesendet, wenn die zweite Kategorie in derselben ON4KST-Sitzung aktiviert und vollständig synchronisiert ist.
 
 Globale Variablen wie `MYQRG`, `SECONDQRG`, `MYLOCATOR` oder `MYQTF` werden unmittelbar vor jeder Aussendung neu aufgelöst. Eine zwischenzeitlich vom Logprogramm aktualisierte QRG kann dadurch bereits im nächsten Beacon erscheinen.
 
@@ -704,7 +722,7 @@ Konfiguration, Timer-Verhalten und verfügbare Variablen: [Konfiguration – Bea
 
 ## Simplelogfile
 
-Details: [Log-Synchronisation](de-Log-Synchronisation#methode-1-universal-file-based-callsign-interpreter-simplelogfile).
+Der Simplelogfile-Interpreter liest einmal pro Minute Rufzeichen aus einer ausgewählten Textdatei. Fehlt die Datei, legt KST4Contest sie an und zeigt einen nicht blockierenden Hinweis mit Pfad, Funktionstest und Contestprüfung. Details: [Log-Synchronisation](de-Log-Synchronisation#methode-1-universal-file-based-callsign-interpreter-simplelogfile).
 
 ---
 
@@ -813,7 +831,11 @@ Die Bandangaben verwenden dieselbe Herleitung wie die Bandspalten, der Filter **
 
 Treffen mehrere Zustände gleichzeitig zu, hat die für den Betrieb wichtigere Markierung Vorrang. Eine ausgewählte Station bleibt deshalb orange; eine Richtungsgelegenheit wird grün dargestellt, auch wenn das Rufzeichen bereits gearbeitet wurde.
 
-Bei niedrigen Zoomstufen werden räumlich dicht beieinanderliegende Stationen zu einem Cluster zusammengefasst. Die Zahl im Cluster gibt die Anzahl der enthaltenen Stationen an. Ein Klick zoomt weiter hinein, wählt aber noch keine einzelne Station aus. Die aktuell ausgewählte Station und grün markierte Richtungsgelegenheiten bleiben auch bei niedriger Zoomstufe als einzelne Marker sichtbar.
+Mit der Checkbox **Group nearby stations** lässt sich die räumliche Gruppierung steuern. Ist sie ausgewählt, werden bei niedrigen Zoomstufen dicht beieinanderliegende Marker zu einem Bildschirm-Cluster zusammengefasst. Die Zahl im Cluster gibt die Anzahl der enthaltenen Stationen an. Ein Klick zoomt weiter hinein, wählt aber noch keine einzelne Station aus. Die aktuell ausgewählte Station und grün markierte Richtungsgelegenheiten bleiben auch bei niedriger Zoomstufe möglichst als einzelne Marker sichtbar.
+
+Ist **Group nearby stations** nicht ausgewählt, erscheinen alle positionierbaren Stationen unabhängig von der Zoomstufe als einzelne Marker. Die Änderung wirkt sofort, ohne Stationsdaten neu zu laden oder Zoom, Kartenausschnitt und Auswahl zu verändern. KST4Contest speichert die Einstellung automatisch und stellt sie beim nächsten Start wieder her. Bestehende Installationen beginnen mit aktivierter Gruppierung und behalten damit zunächst das bisherige Verhalten.
+
+Diese Bildschirm-Cluster sind nicht mit der Zusammenfassung von Chatvarianten zu verwechseln. Mehrere aktive Varianten desselben normalisierten Basisrufzeichens werden weiterhin zu einem geografischen Marker zusammengeführt. Das Ausschalten von **Group nearby stations** erzeugt daraus keine zusätzlichen Marker und verändert weder Chatidentitäten noch Filter oder Stationsdaten.
 
 ### Auswahl und geografische Hilfen
 

github_docs/de-Home.md

@@ -52,7 +52,7 @@ Download, unterstützte Betriebssysteme und Installationswege sind im Kapitel [I
 
 Dieses Handbuch unterscheidet zwischen der veröffentlichten Stable-Version und dem aktuellen Entwicklungsstand.
 
-Die derzeit veröffentlichte Stable-Version ist **v1.41.1**. Funktionen oder Änderungen, die erst im Entwicklungsstand für v1.42 enthalten sind, werden ausdrücklich als **Nightly / v1.42** gekennzeichnet. Fehlt eine solche Kennzeichnung, bezieht sich die Beschreibung auf die Stable-Version.
+Die derzeit veröffentlichte Stable-Version ist **v1.42.0**. Funktionen oder Änderungen, die erst mit einer bestimmten Version hinzugekommen sind, werden ausdrücklich als **ab v1.42** gekennzeichnet. Funktionen, die es nur im aktuellen Entwicklungsstand gibt, sind als **Nightly** gekennzeichnet. Fehlt eine solche Kennzeichnung, bezieht sich die Beschreibung auf die Stable-Version.
 
 - [Stable, Beta und Nightly herunterladen](https://kst4contest.hamradioonline.de/download/)
 - [Veröffentlichte GitHub Releases](https://github.com/praktimarc/kst4contest/releases)
@@ -68,6 +68,7 @@ Für einen Contest ist grundsätzlich die Stable-Version zu empfehlen. Nightly-B
 |---|---|
 | [Installation](de-Installation) | ON4KST-Account, Download, Installation und Updates |
 | [Konfiguration](de-Konfiguration) | Login, Station, Bänder, Benutzeroberfläche und externe Schnittstellen |
+| [Contest-Workflow](de-Contest-Workflow) | Vorstartprüfung, CQ-Betrieb, Kandidatenauswahl, Skeds, Logeintrag und Bandwechsel |
 | [Log-Synchronisation](de-Log-Synchronisation) | Simplelogfile, UCXLog, N1MM+, QARTest, DXLog.net und Win-Test |
 | [AirScout-Integration](de-AirScout-Integration) | Verbindung zu AirScout und Auswertung von Aircraft-Scatter-Zeiten |
 | [DX-Cluster-Server](de-DX-Cluster-Server) | Übergabe erkannter Möglichkeiten an das Logprogramm |

github_docs/de-Konfiguration.md

@@ -4,7 +4,7 @@
 
 Nach dem ersten Start öffnet sich das **Einstellungsfenster** – dieses ist der zentrale Ausgangspunkt für alle Konfigurationen. Es empfiehlt sich, das Einstellungsfenster während des Betriebs geöffnet zu lassen (z. B. um den Beacon schnell ein- und auszuschalten).
 
-> **Wichtig**: Nach jeder Änderung unbedingt **„Save Settings"** klicken! Die Einstellungen werden unter Linux in `~/.praktikst/preferences.xml` und unter Windows in `%USERPROFILE%\.praktikst\preferences.xml` (bzw. `C:\Users\<Benutzername>\.praktikst\preferences.xml`) gespeichert. Ab v1.21 werden auch Fenstergrößen und Divider-Positionen beim Speichern gesichert.
+> **Wichtig**: Fachliche Einstellungen mit **„Save Settings"** sichern, wenn sie beim nächsten Start wieder gelten sollen. Layoutänderungen wie Fenstergrößen, Divider-Positionen und Tabellenbreiten speichert KST4Contest automatisch. Die gemeinsame Datei liegt unter Linux und macOS in `~/.praktiKST/preferences.xml` und unter Windows in `%USERPROFILE%\.praktiKST\preferences.xml` (bzw. `C:\Users\<Benutzername>\.praktiKST\preferences.xml`).
 
 ---
 
@@ -14,14 +14,15 @@ Nach dem ersten Start öffnet sich das **Einstellungsfenster** – dieses ist de
 
 ### Login und Chat-Kategorien
 
-Hier werden die Zugangsdaten für den ON4KST-Chat eingetragen (Rufzeichen und Passwort).
-Zudem wird die **primäre Chat-Kategorie** (z. B. IARU Region 1 VHF/Microwave) ausgewählt.
+Hier werden das lokale Login-Rufzeichen und das Passwort für den ON4KST-Chat eingetragen. Zudem wird die **primäre Chat-Kategorie** (z. B. IARU Region 1 VHF/Microwave) ausgewählt.
 
-Mit der Option für einen **zweiten Chat** (Multi-Channel-Login) kann man sich gleichzeitig in eine weitere Kategorie (z. B. UHF/SHF) einloggen. Beide Chats werden dann parallel überwacht. Hier kann optional auch ein abweichender Login-Name für den zweiten Chat vergeben werden (nützlich für Opposite Station Multi-Callsign Logging).
+Mit der Option für einen **zweiten Chat** (Multi-Channel-Login) wird eine weitere Kategorie (z. B. UHF/SHF) per Single Sign-on in derselben ON4KST-TCP-Sitzung aktiviert. KST4Contest öffnet dafür keine zweite TCP-Verbindung und verwendet weder ein zweites lokales Login-Rufzeichen noch ein zweites Passwort.
+
+**Name in Chat 2** konfiguriert ausschließlich das sichtbare, kategoriebasierte Namensfeld der zweiten Kategorie. Es ist weder ein zweites Login noch ein Nachrichtenempfänger. Das sichtbare Namensfeld, der Nachrichtenkontext, die QRG und der Beacon bleiben für beide Kategorien getrennt. **Opposite Station Multi-Callsign Login-Tagging** bezieht sich dagegen ausschließlich auf Gegenstationen, die mit mehreren vollständigen sichtbaren Rufzeichenvarianten im Chat erscheinen.
 
 ### Rufzeichen und Locator
 
-Eigenes Rufzeichen und Maidenhead-Locator (6-stellig, z. B. `JN49IJ`) eintragen. Diese Werte werden für Distanz- und Richtungsberechnungen benötigt.
+Eigenes Rufzeichen und Maidenhead-Locator (6-stellig, z. B. `JN49IJ`) eintragen. Der Locator ist kein Bestandteil der Authentifizierung. ON4KST verwendet ihn gemeinsam für beide Kategorien der einen TCP-Sitzung; KST4Contest benötigt ihn außerdem für Distanz- und Richtungsberechnungen.
 
 ### Aktivierte Bänder
 
@@ -108,7 +109,9 @@ Drei Methoden stehen zur Verfügung, um gearbeitete Stationen automatisch zu mar
 
 ### Universal File Based Callsign Interpreter (Simplelogfile)
 
-Interpretiert beliebige Log-Dateien per Regex nach Rufzeichen-Mustern. Keine Bandinformation möglich. Geeignet als Fallback oder für nicht direkt unterstützte Logprogramme.
+Liest die ausgewählte Textdatei einmal pro Minute mit einem fest eingebauten Rufzeichenmuster. Die Treffer werden auf Basisrufzeichen normalisiert und setzen für alle aktiven Varianten nur den globalen Worked-Status. Band- und Locatorinformationen können daraus nicht abgeleitet werden. Die Funktion eignet sich als Fallback für Logprogramme ohne unterstützte Netzwerkschnittstelle. Vor der Verwendung sollte deshalb geprüft werden, ob das eingesetzte Logprogramm bereits eine der unterstützten Netzwerkschnittstellen bereitstellt.
+
+Existiert die ausgewählte Datei noch nicht, legt KST4Contest sie an und zeigt einmalig den vollständigen Pfad sowie Hinweise zum Funktions- und Contesttest. Die Datei ist selbst die dauerhafte Quelle; aus ihr abgeleitete Worked-Markierungen werden nicht in SQLite gespeichert und nicht automatisch für einen neuen Contest zurückgesetzt.
 
 ### Netzwerk-Listener für QSO-UDP-Broadcast
 
@@ -134,7 +137,7 @@ Die TRX-Synchronisation übernimmt die aktuelle Frequenz aus dem Logprogramm und
 | **Win-Test STATUS** | `Win-Test STATUS QRG Sync` | Verarbeitet die Haupt- oder Pass-Frequenz aus nativen Win-Test-`STATUS`-Paketen. Der Win-Test-Listener verwendet seinen separat konfigurierten Port, standardmäßig `9871`. |
 | **Manuelle Eingabe** | Beide automatischen QRG-Quellen deaktivieren | Die eigene QRG kann im Hauptfenster von Hand eingetragen werden. |
 
-Der allgemeine Listener ist für Logprogramme vorgesehen, die kompatible `RadioInfo`-Pakete senden. Dazu gehören – abhängig von deren jeweiliger Konfiguration – UCXLog, N1MM+, QARTest und DXLog.net. QSO- und `RadioInfo`-Pakete verwenden denselben unter **Log sync** konfigurierten Port. Dort wird jedoch getrennt festgelegt, ob KST4Contest QSO-Informationen, TRX-Informationen oder beide Paketarten verarbeitet.
+Der allgemeine Listener ist für Logprogramme vorgesehen, die kompatible `RadioInfo`-Pakete senden. Dazu gehören – abhängig von deren jeweiliger Konfiguration – UCXLog, N1MM+, QARTest und DXLog.net. QSO- und `RadioInfo`-Pakete verwenden denselben unter **Log sync** konfigurierten Port. Dort wird jedoch getrennt festgelegt, ob KST4Contest QSO-Informationen, TRX-Informationen oder beide Paketarten verarbeitet. Eine automatische QRG-Quelle muss aktiviert sein und tatsächlich gültige Pakete liefern; die Aktivierung allein aktualisiert `MYQRG` nicht.
 
 Wird der gemeinsame UDP-Port geändert, muss KST4Contest neu gestartet werden. Eine reine Änderung der Checkboxen wird dagegen sofort berücksichtigt.
 
@@ -144,7 +147,7 @@ Beide automatischen Quellen aktualisieren ausschließlich `MYQRG`. Das ist die e
 
 Bei aktiviertem zweiten Chat bleibt dessen QRG davon unabhängig. Sie wird nicht aus den empfangenen TRX-Paketen abgeleitet und steht als `SECONDQRG` zur Verfügung. Dadurch kann beispielsweise die erste Kategorie automatisch der Frequenz des Logprogramms folgen, während für die zweite Kategorie eine eigene QRG von Hand eingetragen wird.
 
-Sobald mindestens eine automatische QRG-Quelle aktiviert ist, wird das QRG-Feld der ersten Kategorie im Hauptfenster an den empfangenen Wert gebunden. Eine manuelle Eingabe in dieses Feld ist wieder möglich, wenn sowohl der allgemeine RadioInfo-Listener als auch die Win-Test-STATUS-Synchronisation deaktiviert sind.
+Sobald mindestens eine automatische QRG-Quelle aktiviert ist und einen gültigen Wert liefert, folgt das QRG-Feld der ersten Kategorie im Hauptfenster der empfangenen Frequenz. Bleiben die erwarteten Pakete aus, sollte die Schnittstelle vor dem Contest geprüft werden. Eine manuelle Eingabe in dieses Feld ist möglich, wenn sowohl der allgemeine RadioInfo-Listener als auch die Win-Test-STATUS-Synchronisation deaktiviert sind.
 
 ### Haupt- oder Pass-Frequenz aus Win-Test
 
@@ -332,6 +335,8 @@ Die drei Audiofunktionen arbeiten unabhängig voneinander:
 
 CW- und Sprachausgabe können gleichzeitig aktiviert werden. Das ist technisch möglich, im Contest aber nicht zwingend hilfreich. In der Praxis sollte nur die Ausgabe eingeschaltet werden, die im eigenen Stationsbetrieb tatsächlich wahrgenommen werden kann, ohne den Operator dauerhaft zu beschäftigen.
 
+Die PM-bezogenen Audioausgaben reagieren nur auf Nachrichten, die tatsächlich an das eigene Login-Rufzeichen gerichtet sind. Öffentliche Nachrichten, die durch PM-Catching zusätzlich in der PM-Tabelle erscheinen, und dort eingeblendete Monitoring-Nachrichten bleiben akustisch still.
+
 ### Fallback-Band für relative QRG-Erkennung
 
 Das Dropdown **Fallback band for relative QRG detection** legt fest, welches Band KST4Contest verwendet, wenn eine relative QRG keinem aktuellen Stationskontext zugeordnet werden kann.
@@ -374,12 +379,14 @@ Folgende Einstellungen und Schaltflächen gehören zur lokalen DX-Cluster-Ausgab
 
 ```text
 Spotted callsign: DO5AMF
-Comment: Testing DXC-Spot: Congrats, you donated $100!
+Comment: DXC test: You donated $100!
 Frequency: .300 des ausgewählten Fallback-Bandes
 ```
 
 Bei einem Fallback-Band von `144 MHz` wird daraus beispielsweise eine Frequenz von ungefähr `144.300 MHz`.
 
+Alle Spots verwenden eine feste, DXSpider-kompatible 75-Zeichen-Nutzzeile mit einem 30 Zeichen breiten Kommentarfeld. Längere Kommentare werden an dieser Protokollgrenze kontrolliert gekürzt; das DX-Rufzeichen wird dagegen nicht abgeschnitten. Rufzeichen mit mehr als zwölf Zeichen führen dazu, dass der betreffende Spot verworfen und protokolliert wird.
+
 Der Kommentar des Testspots ist ein bewusst beibehaltenes Easteregg. Er hat keine technische Bedeutung und löst – trotz seiner erfreulich konkreten Formulierung – keine Zahlung aus. Entscheidend ist, dass der Spot im verbundenen Logprogramm erscheint.
 
 Der Test funktioniert nur, wenn
@@ -472,7 +479,7 @@ Die Eingabe darf ein sichtbares KST-Suffix oder portable Bestandteile enthalten.
 
 Die Änderung der Liste wirkt sofort. Zum dauerhaften Speichern anschließend **Save Settings** verwenden. Die Basisrufzeichen werden in der `preferences.xml` gespeichert und beim nächsten Programmstart wiederhergestellt.
 
-> Die Zusammenführung der KST-Suffixe über das Basisrufzeichen ist im Nightly beziehungsweise ab v1.42 enthalten.
+> Die Zusammenführung der KST-Suffixe über das Basisrufzeichen ist ab v1.42 enthalten.
 
 Weitere Hintergründe und die Abgrenzung zum Nachrichtenrouting: [QSO-Monitoring](de-Funktionen#qso-monitoring-ab-v131).
 ---
@@ -574,7 +581,7 @@ KST4Contest verwendet einen gemeinsamen Timer für beide Chat-Kategorien. Aktivi
 - **Beacon message** enthält den öffentlichen Nachrichtentext dieser Kategorie.
 - **Shared beacon interval** legt das gemeinsame Intervall für beide Kategorien fest.
 
-Sind beide Beacons aktiviert, werden sie beim selben Timer-Lauf nacheinander in ihren jeweiligen Kategorien gesendet. Der zweite Beacon wird nur berücksichtigt, wenn auch der zweite Chat aktiviert und verbunden ist.
+Sind beide Beacons aktiviert, werden sie beim selben Timer-Lauf nacheinander in ihren jeweiligen Kategorien gesendet. Der zweite Beacon wird nur berücksichtigt, wenn die zweite Kategorie in derselben ON4KST-Sitzung aktiviert und vollständig synchronisiert ist.
 
 ### Intervall und Timer-Verhalten
 
@@ -857,6 +864,8 @@ Die interne SQLite-Datenbank speichert die contestbezogenen Zustände unabhängi
 - manuell gesetzte NOT-QRV-Tags pro Band und
 - gearbeitete vierstellige Großfelder pro Band.
 
+Eine Ausnahme bilden Worked-Markierungen des Simplelogfile-Interpreters. Sie werden nur aus der ausgewählten Datei in den laufenden Zustand übernommen und nicht in SQLite persistiert. Die Datei ist die dauerhafte Quelle und besitzt keinen automatischen Contest-Reset. Ein Datenbank-Reset verändert oder leert sie nicht; enthaltene Rufzeichen werden bei der nächsten periodischen Auswertung erneut als gearbeitet markiert.
+
 Als Schlüssel wird das normalisierte Rufzeichen ohne sichtbare Chat-Klammern oder Kategorieformatierung verwendet. Dadurch können aktive Varianten desselben Rufzeichens konsistent ausgewertet werden.
 
 Worked- und NOT-QRV-Informationen laufen drei Tage nach ihrer letzten Änderung automatisch ab. Gespeicherte Großfelder laufen drei Tage nach dem zugehörigen Logeintrag ab. Ein manuelles Zurücksetzen vor jedem Contest ist deshalb normalerweise nicht erforderlich.
@@ -869,16 +878,74 @@ Anzeige und Herleitung: [Gearbeitete Rufzeichen, neue Bänder und neue Großfeld
 
 ---
 
+## Operator-Profile (ab v1.50)
+
+Mehrere Operateure an einem Rechner brauchen unterschiedliche Rufzeichen, Locators und Layouts. Ein Operator-Profil bündelt genau das: **jedes Profil hat seine eigene `preferences.xml` und damit seine eigenen fachlichen Einstellungen und seinen eigenen Layoutstand.**
+
+### Wo die Profile liegen
+
+| Profil | Einstellungen | Gearbeitete Stationen |
+|---|---|---|
+| **Default** | `~/.praktiKST/preferences.xml` | `~/.praktiKST/praktiKST.db` |
+| weitere Profile | `~/.praktiKST/profiles/<Profil-ID>/preferences.xml` | je nach Einstellung gemeinsam oder `~/.praktiKST/profiles/<Profil-ID>/praktiKST.db` |
+
+Unter Windows entsprechend unterhalb von `%USERPROFILE%\.praktiKST\`.
+
+Alle übrigen Daten bleiben gemeinsam: Klangdateien, Farbschemata, DEM- und Terrainpakete, der Zwischenspeicher der Geländeprofile (`terrainprofilecache.db`), das Fehlerprotokoll und die Versionsinformationen.
+
+Das Profil **Default** benutzt weiterhin genau die Dateien, die eine bestehende Installation schon hat. **Bei der Aktualisierung auf v1.50 wird keine Datei verschoben, kopiert oder umgeschrieben.** Wer eine ältere KST4Contest-Version wieder installiert, findet seine Konfiguration und seine gearbeiteten Stationen unverändert vor.
+
+### Gemeinsame oder eigene gearbeitete Stationen
+
+Beim Anlegen eines Profils wird entschieden, woher dessen Worked-, NOT-QRV- und Großfeld-Daten kommen:
+
+- **Eigene gearbeitete Stationen** (Vorgabe): Das Profil bekommt eine eigene, zunächst leere Datenbank. Sinnvoll, wenn sich zwei OMs mit verschiedenen Rufzeichen einen Rechner teilen.
+- **Gemeinsame Stationsdatenbank**: Das Profil benutzt `~/.praktiKST/praktiKST.db`, also dieselbe Datenbank wie das Profil **Default**. Das ist der Fall der **Multi-OP-Station**: es gibt nur ein Stationslog, also soll auch der Worked-Status für alle Operateure derselbe sein.
+
+Ein Wechsel zwischen beiden Einstellungen verschiebt keine Daten. Bereits gesammelte Worked-Daten bleiben dort liegen, wo sie entstanden sind. Der Drei-Tage-Ablauf und die Reset-Schaltfläche wirken jeweils auf die Datenbank des gerade aktiven Profils.
+
+### Profile verwalten
+
+Der Reiter **Profiles** im Einstellungsfenster zeigt alle Profile mit Name, Art der Worked-Daten und letzter Benutzung.
+
+- **New profile...** legt ein Profil an. Es startet **ohne Rufzeichen und ohne Passwort**; beides wird anschließend im Reiter **Station** eingetragen.
+- **Duplicate...** übernimmt die komplette Konfiguration des gewählten Profils — Antenne, Locator, Layout, Beacon, Integrationen — **außer Rufzeichen und Passwort**. Gearbeitete Stationen werden nie mitkopiert.
+- **Rename...** ändert nur den angezeigten Namen. Verzeichnisse und Dateien bleiben unberührt.
+- **Delete...** entfernt das Profilverzeichnis endgültig. Das Profil **Default** und das gerade aktive Profil lassen sich nicht löschen. Bei einem Profil mit gemeinsamer Stationsdatenbank bleibt diese unangetastet.
+- **Change worked stations...** schaltet zwischen gemeinsamer und eigener Datenbank um.
+- **Switch to selected profile...** wechselt das Profil im laufenden Betrieb.
+
+### Profilwahl beim Start
+
+- Solange nur **ein** Profil existiert, fragt KST4Contest beim Start **nichts** und startet wie bisher. Es wird auch keine Profil-Registry angelegt. Erst das Anlegen des zweiten Profils erzeugt `~/.praktiKST/profiles.xml`.
+- Ab **zwei** Profilen erscheint beim Start eine kleine Auswahl. Das zuletzt benutzte Profil ist vorausgewählt, **Enter** oder ein Doppelklick starten sofort.
+- Der Aufrufparameter `--profile=<Name>` überspringt die Auswahl und startet direkt das genannte Profil. Erlaubt sind die Profil-ID und der angezeigte Name, Groß- und Kleinschreibung spielen keine Rolle. Ein unbekannter Name führt zu einem Hinweis und danach zur normalen Auswahl — der Start wird nie verweigert.
+
+### Profil im laufenden Betrieb wechseln
+
+**File → Switch operator profile...** oder die Schaltfläche im Reiter **Profiles** wechseln ohne Programmneustart. Nach einer Sicherheitsabfrage wird die ON4KST-Verbindung getrennt und die Oberfläche mit den Einstellungen und dem Layout des gewählten Profils neu aufgebaut. Der Layoutstand des bisherigen Profils wird vorher gesichert; noch nicht mit **Save Settings** bestätigte fachliche Änderungen gehen dabei verloren.
+
+Sobald mehr als ein Profil existiert, zeigt die Titelzeile des Hauptfensters zusätzlich den Profilnamen.
+
+### Hinweis zu Passwörtern
+
+Das ON4KST-Passwort steht wie bisher im Klartext in der `preferences.xml` des jeweiligen Profils. Auf einem gemeinsam genutzten Rechner kann jeder, der Zugriff auf das Benutzerkonto hat, die Passwörter aller Profile lesen. Profile trennen die Konfiguration, sie sind **kein** Zugriffsschutz.
+
+---
+
 ## Dark Mode (ab v1.26)
 
-Umschaltbar über das Menü: **Window → Use Dark Mode**. Die Farben können über CSS individuell angepasst werden.
+Der Dark Mode wird über **Windows → Use dark mode design** aktiviert. Mit **Windows → Use default mode design** wird wieder das normale helle Farbschema geladen.
 
 ---
 
 ## Einstellungen speichern
 
-Nach **jeder** Änderung **„Save Settings"** klicken! Ohne Speichern gehen alle Änderungen beim nächsten Start verloren.
+**Save Settings** speichert die fachlichen Einstellungen und den vollständigen aktuellen Layoutstand. Änderungen an Fenstergrößen und -positionen, relevanten Dividern, verwalteten Tabellenbreiten sowie der Karteneinstellung **Group nearby stations** werden zusätzlich automatisch mit kurzer Verzögerung gespeichert. Ein ausstehender Layoutstand wird beim Programmende noch geschrieben.
 
-- Speicherort: unter Linux `~/.praktikst/preferences.xml` und unter Windows `%USERPROFILE%\.praktikst\preferences.xml` (bzw. `C:\Users\<Benutzername>\.praktikst\preferences.xml`)
-- Ab v1.21: Fenstergrößen und Divider-Positionen werden ebenfalls gespeichert.
+- Speicherort: unter Linux und macOS `~/.praktiKST/preferences.xml` und unter Windows `%USERPROFILE%\.praktiKST\preferences.xml` (bzw. `C:\Users\<Benutzername>\.praktiKST\preferences.xml`)
+- Der automatische Layout-Writer übernimmt keine noch nicht mit **Save Settings** bestätigten fachlichen Änderungen.
+- Die Konfigurationsversion 6 ergänzt optionale Spaltenbreiten unter `guiOptions`. Ältere `preferences.xml`-Dateien bleiben lesbar; fehlen Breiten oder sind Einträge ungültig, ermittelt KST4Contest wieder brauchbare Anfangsbreiten.
+- Die Konfigurationsversion 7 ergänzt `GUIstationMapClusteringEnabled` unter `guiOptions`. Fehlt der Eintrag oder ist sein Wert unbrauchbar, bleibt die räumliche Kartengruppierung aktiviert.
+- Ältere Programmversionen ignorieren die zusätzlichen XML-Einträge. Wenn eine ältere Version die Datei vollständig neu speichert, können die Spaltenbreiten und die gespeicherte Auswahl für **Group nearby stations** verloren gehen.
 - Bei Problemen: Konfigurationsdatei löschen → KST4Contest erstellt eine neue mit Standardwerten.

github_docs/de-Log-Synchronisation.md

@@ -10,13 +10,15 @@ KST4Contest übernimmt gearbeitete Stationen aus dem Logprogramm und stellt dara
 
 ## Methode 1: Universal File Based Callsign Interpreter (Simplelogfile)
 
-KST4Contest liest eine Logdatei und sucht mit einem konfigurierbaren regulären Ausdruck nach Rufzeichen. Die Datei wird ausschließlich gelesen und nicht verändert. Auch binäre Logdateien können verwendet werden; nicht als Text interpretierbare Inhalte werden übersprungen.
+KST4Contest liest die ausgewählte Textdatei einmal pro Minute und sucht darin mit einem fest eingebauten regulären Ausdruck nach Rufzeichen. Jedes gefundene Rufzeichen wird auf sein Basisrufzeichen normalisiert. Der globale Worked-Status gilt dadurch für alle derzeit aktiven Chat-Varianten dieses Rufzeichens.
 
 Der Vorteil liegt in der breiten Kompatibilität: Die Funktion benötigt keine besondere Netzwerkschnittstelle des Logprogramms.
 
 Die Grenze ist ebenso eindeutig: Aus einem reinen Rufzeichentreffer lassen sich weder Band noch Locator zuverlässig ableiten. Der Simplelogfile-Interpreter kann deshalb nur den globalen Worked-Status setzen. Er erzeugt keine bandbezogene `X`-Markierung, kein Worked-Großfeld und keine belastbare Grundlage für den Band-Upgrade-Hinweis nach einem Logeintrag.
 
-Den Pfad der Logdatei und den regulären Ausdruck im Reiter **Log sync** eintragen. Für bandbezogene Auswertungen sollte nach Möglichkeit eine der Netzwerkschnittstellen verwendet werden.
+Den Pfad der Textdatei im Reiter **Log sync** auswählen. Fehlt die Datei, legt KST4Contest sie an und zeigt einmalig einen nicht blockierenden Hinweis mit dem Pfad und den nächsten Prüfschritten an. Lese- oder Erstellungsfehler werden protokolliert; die minütliche Auswertung läuft beim nächsten Termin weiter. Für bandbezogene Auswertungen sollte nach Möglichkeit eine der Netzwerkschnittstellen verwendet werden.
+
+Der aus dem Simplelogfile abgeleitete Worked-Status wird nicht in der internen SQLite-Datenbank gespeichert. Die ausgewählte Datei ist die dauerhafte Quelle und wird auch nach einem Neustart erneut eingelesen. Der Interpreter setzt nur positive Worked-Markierungen; er entfernt während der laufenden Programmsitzung keine bereits gesetzte Markierung und führt beim Wechsel zu einem neuen Contest keinen automatischen Reset durch. Auch ein manueller Datenbank-Reset ändert oder leert das Simplelogfile nicht. Darin enthaltene Rufzeichen werden bei der nächsten Auswertung innerhalb einer Minute erneut als gearbeitet markiert. Vor jedem Contest sollte deshalb geprüft werden, ob das Logprogramm genau die aktuelle Contestdatei beschreibt.
 
 ---
 
@@ -100,6 +102,24 @@ Die Band-IDs für 50 und 70 MHz werden ebenso verarbeitet wie die VHF-, UHF- und
 
 Die Daten werden in derselben internen Datenbank abgelegt wie Worked-Informationen aus den übrigen QSO-UDP-Schnittstellen und nach einem Neustart wiederhergestellt.
 
+#### Bereits geloggte QSOs nachladen
+
+Win-Test sendet jedes neue QSO als Broadcast. QSOs, die vor dem Start von KST4Contest geloggt wurden, sind darin nicht enthalten. KST4Contest fordert diese QSOs deshalb selbst an, sobald der Win-Test-Netzwerk-Listener eine Win-Test-Station im Netzwerk erkennt.
+
+Der Abgleich benötigt keine eigene Einstellung und keinen Bedienschritt:
+
+- Win-Test meldet mit `IHAVE`, welche QSO-Nummern welches Logs es führt.
+- KST4Contest fordert die fehlenden Bereiche mit `NEEDQSO` an, höchstens 50 QSOs pro Anfrage.
+- Win-Test beantwortet die Anfrage mit gewöhnlichen `ADDQSO`-Paketen. Sie werden genauso ausgewertet wie ein live geloggtes QSO.
+
+Bereits gearbeitete Stationen erscheinen dadurch auch dann als gearbeitet, wenn KST4Contest erst während des Contests gestartet wird. Der Abgleich bleibt anschließend aktiv und holt auch einzelne Pakete nach, die im laufenden Betrieb verloren gegangen sind. Bereits bekannte QSOs werden erkannt und nicht erneut gespeichert.
+
+Sind mehrere Win-Test-Stationen im Netzwerk aktiv, wird jedes Log abgeglichen. Damit sind die bandbezogenen Worked-Markierungen aller Bandstationen vollständig. Der Stationsnamensfilter wirkt weiterhin nur auf die QRG-Synchronisation und schränkt den Logabgleich nicht ein.
+
+Meldet eine erkannte Station kein auswertbares `IHAVE`, etwa bei einer älteren Win-Test-Version, fordert KST4Contest die QSOs blockweise ab QSO-Nummer 1 an, bis ein Block unbeantwortet bleibt.
+
+Voraussetzung ist ein aktiviertes Win-Test-Netzwerk. Ist das Win-Test-Netzwerk oder der Listener in KST4Contest deaktiviert, findet kein Abgleich statt.
+
 #### Skeds an Win-Test übergeben
 
 Mit **Create sked** wird zunächst ein interner KST4Contest-Sked angelegt. Ist der Win-Test-Netzwerk-Listener aktiviert, versucht KST4Contest anschließend automatisch, den Sked als `ADDSKED` an das Win-Test-Netzwerk zu übertragen.
@@ -152,7 +172,11 @@ Im Reiter **TRX sync**:
 - `Use pass frequency from Win-Test STATUS`
 - `Win-Test station name filter`
 
-Das Win-Test-Netzwerk muss in Win-Test aktiviert sein. Bei mehreren Computern muss die Broadcast-Adresse das betreffende lokale Netzwerk erreichen. Der Stationsname sollte die sendende KST4Contest-Instanz innerhalb des Win-Test-Netzwerks eindeutig erkennen lassen.
+Das Win-Test-Netzwerk muss in Win-Test aktiviert sein. Der Stationsname sollte die sendende KST4Contest-Instanz innerhalb des Win-Test-Netzwerks eindeutig erkennen lassen.
+
+Die Broadcast-Adresse ermittelt KST4Contest selbst: Aus der Absenderadresse der empfangenen Win-Test-Pakete wird das passende lokale Netzwerk bestimmt und dessen Broadcast-Adresse verwendet. Die eingetragene Adresse dient als Rückfallebene, wenn kein lokales Netzwerk zur Win-Test-Station passt, etwa wenn Win-Test hinter einem Router liegt.
+
+Das ist wichtig, weil Win-Test ausschließlich auf Broadcasts reagiert und eine Adresse in einem nicht vorhandenen Netzwerk keinen Fehler auslöst: Das Paket wird ohne Meldung weggeroutet. Eine veraltete Eintragung, etwa aus einem anderen Netzwerk, machte dadurch früher sowohl die Sked-Übergabe als auch den Logabgleich wirkungslos.
 
 Ausführliche Beschreibung der Einstellungen: [Win-Test-Netzwerk-Listener](de-Konfiguration#win-test-netzwerk-listener-ab-v131)
 
@@ -163,7 +187,7 @@ Neben der QSO-Synchronisation übertragen UCXLog und andere Programme auch die *
 
 ![FrequenzButtons](qrg_buttons.png)
 
-**Ergebnis**: Die eigene QRG muss im Chat nie mehr manuell eingegeben werden – ein Klick auf den MYQRG-Button oder die Verwendung der Variable im Beacon genügt.
+**Ergebnis**: Eine aktivierte Schnittstelle aktualisiert `MYQRG`, sobald sie tatsächlich gültige Frequenzpakete liefert. Das Aktivieren allein erzeugt noch keine QRG. Kommen keine passenden Pakete an, muss die Schnittstelle geprüft oder die QRG nach dem Deaktivieren beider automatischen Quellen manuell gepflegt werden.
 
 **Quellen für die eigene QRG (MYQRG):**
 - UCXLog, N1MM+, DXLog.net, QARTest via UDP-Port 12060
@@ -191,7 +215,7 @@ Für DM5M-typische Setups (2 Radios, 2 Computer, eine KST4Contest-Instanz oder z
 
 ## Interne Datenbank
 
-KST4Contest speichert Worked-, NOT-QRV- und Großfeldinformationen in einer eigenen SQLite-Datenbank. Sie ist von der Datenbank des Logprogramms unabhängig.
+KST4Contest speichert Worked-, NOT-QRV- und Großfeldinformationen aus den Netzwerkschnittstellen sowie manuelle Markierungen in einer eigenen SQLite-Datenbank. Sie ist von der Datenbank des Logprogramms unabhängig. Simplelogfile-Treffer sind davon ausgenommen und werden bei jeder Programmsitzung aus der ausgewählten Datei neu abgeleitet.
 
 Die Datenquellen liefern unterschiedlich genaue Informationen:
 
@@ -201,6 +225,6 @@ Die Datenquellen liefern unterschiedlich genaue Informationen:
 | QSO-UDP-Listener | ja | ja, wenn im Paket enthalten | ja, wenn Band und Locator enthalten sind |
 | Win-Test-Netzwerk-Listener | ja | ja | ja, wenn ein Locator enthalten ist |
 
-Die Daten werden beim Programmstart wieder geladen und bei neuen Logeinträgen während des Betriebs aktualisiert. Sie laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist daher normalerweise nicht erforderlich.
+Die in SQLite gespeicherten Daten werden beim Programmstart wieder geladen und bei neuen Logeinträgen während des Betriebs aktualisiert. Sie laufen nach drei Tagen automatisch ab. Ein Reset vor jedem Contest ist daher normalerweise nicht erforderlich. Für den Simplelogfile-Interpreter gilt diese Lebensdauer nicht: Seine Datei bleibt die dauerhafte Quelle und wird durch einen Datenbank-Reset weder geändert noch geleert. Enthaltene Rufzeichen setzt die nächste periodische Auswertung erneut auf den globalen Worked-Status.
 
 Ein vollständiger manueller Reset entfernt Worked-Markierungen, NOT-QRV-Tags und Worked-Großfelder gemeinsam. Weitere Einzelheiten: [Worked Station Database Settings](de-Konfiguration#worked-station-database-settings-gearbeitete-stationen-datenbank).

github_docs/de-Makros-und-Variablen.md

@@ -362,3 +362,9 @@ Dabei ist insbesondere zu beachten:
 - Der eingefügte Text wird nicht automatisch auf seine betriebliche Richtigkeit geprüft.
 
 Das Sendfeld bleibt deshalb nach dem Einfügen eines Shortcuts oder Snippets bearbeitbar. Die Variablen vermeiden wiederholte Eingaben; die abschließende Prüfung bleibt beim Operator.
+
+---
+
+## Verwendung im Contest
+
+Shortcuts, Snippets und Variablen sind einzelne Werkzeuge innerhalb des laufenden Betriebs. Ihr Zusammenspiel mit CQ-Betrieb, Stationsauswahl, Skeds, QRG-Wechseln und Log-Synchronisation ist unter [Contest-Workflow mit KST4Contest](de-Contest-Workflow) beschrieben.

github_docs/en-AirScout-Integration.md

@@ -2,7 +2,7 @@
 
 > 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-AirScout-Integration)
 
-AirScout (by DL2ALF) is a program for detecting aircraft for aircraft scatter operation. KST4Contest is tightly integrated with AirScout and shows reflectable aircraft directly in the user list.
+AirScout (by DL2ALF) calculates aircraft-scatter opportunities from current aircraft positions. KST4Contest receives these results and displays aircraft suitable for the path to each remote station directly in the user list.
 
 > **Aircraft Scatter** enables very long-distance communication on VHF and higher – even for stations with low altitude above sea level or unfavourable topographic conditions.
 
@@ -15,9 +15,9 @@ Download AirScout from:
 
 ---
 
-## Aircraft Data Feeds (ADSB)
+## Aircraft Data Feeds (ADS-B)
 
-Public aircraft data feeds on the internet are often unreliable and limited in use. A recommended alternative is the dedicated ADSB feed service provided by **OV3T (Thomas)**:
+Public aircraft data feeds on the internet are often unreliable and of limited use. A recommended alternative is the dedicated ADS-B feed service provided by **OV3T (Thomas)**:
 
 - https://airscatter.dk/
 - https://www.facebook.com/groups/825093981868542
@@ -28,7 +28,7 @@ An account is required for this service. Please consider donating to Thomas –
 
 ## Setting Up AirScout
 
-### Step 1: Configure the ADSB Feed in AirScout
+### Step 1: Configure the ADS-B Feed in AirScout
 
 1. Start AirScout.
 2. Enter your OV3T feed account details (username, password, URL) in the AirScout settings.
@@ -85,32 +85,40 @@ Otherwise, it may result in incorrect AP data.
 
 ## AP Column in the User List
 
-After setup, an **AP column** appears in the user list showing up to two reflectable aircraft per station.
+After setup, an **AP column** appears in the user list. For each station, it shows the arrival time and the AirScout reflection potential of the first two suitable aircraft.
 
 Example display:
 
 | Station | AP Info |
 |---|---|
-| DF9QX | 2 Planes: 0 min / 0 min, 100% each |
-| F5DYD | 2 Planes: 14 min / 31 min, 50% each |
+| DF9QX | 0 (100%) / 0 (100%) |
+| F5DYD | 14 (50%) / 31 (50%) |
+
+The number before the brackets is the number of minutes remaining until the calculated opportunity. The percentage is the reflection potential reported by AirScout. It is not a QSO probability.
 
 AP information is also available in the **private messages window**.
 
-The percentage indicates the reflection potential (aircraft size, altitude, distance).
+## Effect on the Priority Score and Timeline
+
+At least one aircraft reported as reachable by AirScout raises the station's Priority Score. An opportunity expected in zero, one or two minutes receives additional time-dependent weighting. AirScout is only one factor alongside Worked status, available bands, QRB, antenna direction, chat activity and skeds.
+
+The AP and sked timeline uses the Priority Score to select interesting stations and places the next suitable aircraft-scatter opportunity on the time axis. The reflection potential also controls how the AP marker is displayed. The timeline remains a preview and does not guarantee a QSO.
 
 ---
 
 ## AP Variables in Messages
 
-Aircraft data can be inserted directly into messages:
+Aircraft data for the selected station can be inserted directly into shortcuts, snippets and other station-specific messages:
 
 - `FIRSTAP` → e.g. `a very big AP in 1 min`
 - `SECONDAP` → e.g. `Next big AP in 9 min`
 
 Details: [Macros and Variables](en-Macros-and-Variables#variables)
 
+Because these values require a selected remote station, `FIRSTAP` and `SECONDAP` are not available as global beacon variables.
+
 ---
 
 ## "Show Path in AirScout" Button
 
-In the user list there is a button with an arrow showing the direction (QTF) to the selected station. Clicking it maximises AirScout and shows the path with reflectable aircraft to the selected contact.
+In the user list there is a button with an arrow showing the direction (QTF) to the selected station. Clicking it maximises the external AirScout window and displays the path to the selected remote station together with the calculated aircraft-scatter opportunities. The button does not start a separate terrain or propagation calculation in KST4Contest.

github_docs/en-Changelog.md

@@ -8,10 +8,110 @@ Published Stable versions and their application packages are available under [Gi
 
 ---
 
-## v1.42 – Nightly / in development
+## v1.50 (in development)
 
-> Status of this section: 14 August 2026.  
-> v1.42 is not a published Stable release yet. Further changes may be added before release.
+**Operator profiles**
+
+Several operators sharing one computer can now use their own callsigns, locators and layouts without overwriting each other's configuration. This implements [Issue #57](https://github.com/praktimarc/kst4contest/issues/57).
+
+### New
+
+- **Operator profiles:** every profile has its own `preferences.xml`, and therefore its own settings and its own window layout. Profiles are managed on the new **Profiles** tab of the settings window: create, duplicate, rename, delete and activate.
+
+- **Shared or own worked stations:** each profile decides whether it gets its own worked database or uses the common station database. A multi operator station with a single station log shares the worked state; two operators with different callsigns on one computer keep it apart.
+
+- **Choosing a profile at startup:** with only one profile, KST4Contest asks nothing at startup and behaves exactly as before. From two profiles on, a small selection appears with the last used profile preselected; Enter or a double click start immediately. The `--profile=<name>` argument skips the selection.
+
+- **Switching profiles while running:** **File > Switch operator profile...** closes the connection and rebuilds the user interface with the settings of the selected profile, without restarting the program.
+
+### Changed
+
+- **The terrain profile cache is separate:** computed terrain profiles now live in their own shared file `terrainprofilecache.db` and are stored per owner. Previously the whole cache was dropped whenever the callsign or locator changed, which would have discarded every computed profile on each profile switch.
+
+- **The default login callsign is empty:** if `preferences.xml` has no login callsign, the field now stays empty instead of falling back to a callsign compiled into the program. A newly created profile therefore deliberately starts without credentials.
+
+### Fixed
+
+- **Background resources are released:** the ON4KST supervisor thread, the sked reminder scheduler, the reachability executor, the PSTRotator retry scheduler and the map tile proxy are released when the chat controller is closed. They used to keep running until the program ended.
+
+### Upgrade notes
+
+- Existing installations are **not** modified: `preferences.xml` and `praktiKST.db` stay exactly where they are and become the **Default** profile. No file is moved or copied.
+- A profile registry only appears when the second profile is created. Anyone using a single profile will not notice the change.
+- Going back to an older KST4Contest release stays possible; it finds its files unchanged.
+- Passwords are still stored in clear text in each profile's `preferences.xml`. Profiles separate configuration; they are not an access control mechanism.
+
+---
+
+## v1.43.1 (2026-09-03)
+
+**Corrected version metadata**
+
+v1.43.1 contains the same functional changes as v1.43.0. It corrects the application and build metadata used for display, ON4KST identification and update comparison. Some metadata in the first v1.43.0 package set still identified the build as version 1.42.
+
+### Fixed
+
+- **Consistent semantic version:** The user-visible application version now uses the complete `1.43.1` form. The compact value `1.431` remains only in the deprecated numeric field required for compatibility with older update feeds.
+
+- **Tagged-release update feed:** The website build, version-feed validation and artifact upload now run as actual workflow steps after the GitHub Release has been published. They were previously indented into the release action's artifact list and therefore skipped.
+
+Users of v1.43.0 should install v1.43.1. The functionality is unchanged; the update only corrects the version metadata and release workflow.
+
+The corrected version is available as [Release v1.43.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.43.1).
+
+---
+
+## v1.43.0 (2026-09-03)
+
+**More reliable log synchronisation, persistent layouts and better DX Cluster compatibility**
+
+v1.43 concentrates on reliability around external log data and long-running contest operation. It also adds practical control over table layouts and station grouping on the map.
+
+### Added
+
+- **Optional map clustering:** **Group nearby stations** immediately enables or disables spatial grouping at lower zoom levels. The stored setting changes neither the viewport nor the selected station; aggregation of active variants sharing one base callsign remains independent. This implements [Issue #79](https://github.com/praktimarc/kst4contest/issues/79).
+
+- **Automatic table-layout persistence:** Tables receive useful widths when their first meaningful contents arrive. Manually changed column widths, window sizes and relevant dividers are written to `preferences.xml` after a short delay. The main and monitor windows keep separate DXCluster and QSO-of-the-other layouts.
+
+- **Tooltips for truncated table values:** Normal table cells expose their complete text when the visible column is too narrow, without replacing functional tooltips or clickable links.
+
+- **Simplelogfile creation notice:** When the selected file does not exist, KST4Contest creates it and displays a notice with the file path, a concrete test procedure and a link to the relevant manual section.
+
+### Changed
+
+- **Robust Simplelogfile evaluation:** The selected file is evaluated once per minute and closed after every pass so that the logging application can replace or rotate it. Detected callsigns apply the global Worked state to every active suffix variant of the base callsign. Disabling the function prevents any file access, while read or creation errors no longer terminate the periodic task.
+
+- **Consistent external logger bands:** UCXLog-compatible packets and Win-Test events use one shared band normalisation. Numeric values, metre and centimetre designators and the existing Win-Test IDs now set the same Worked flags and worked grid squares. Values including `2320`, `5760` and `10368` are handled reliably; a missing or unknown band sets only the global Worked state.
+
+- **Compact full-frequency recognition:** Complete frequencies without a decimal separator are accepted across the supported bands, with the final three digits interpreted as the kHz part. Bare three-digit numbers still require recognisable frequency context so that signal reports and unrelated numbers are not treated as QRGs.
+
+- **DXSpider-compatible spot format:** Local DX Cluster spots use a fixed 75-character payload line with the DX callsign in column 27, a 30-character comment field and UTC time in column 71. The format remains stable up to 24 GHz. Overlong DX callsigns are rejected and logged instead of being silently truncated. This resolves [Issue #86](https://github.com/praktimarc/kst4contest/issues/86).
+
+- **Active ON4KST connection probe:** A quiet chat server is checked with an explicit session-wide probe before the connection is treated as dead. Heartbeats and probe frames retain the required CR/LF framing.
+
+- **Reliable private-message age highlighting:** Incoming private messages use the defined green age levels for up to five minutes. Locally sent messages retain their separate style, and empty or reused table rows return to the normal design instead of keeping an obsolete highlight.
+
+### Fixed
+
+- **Worked state after login:** Persisted SQLite Worked information is loaded and applied before each initial ON4KST user list is published. Reconnects, both categories and all active variants of a base callsign therefore start with the correct state. This resolves [Issue #85](https://github.com/praktimarc/kst4contest/issues/85).
+
+- **False disconnect during quiet periods:** A valid ON4KST connection is no longer closed merely because the server currently has no activity lines to send.
+
+### Documentation and packaging
+
+- The German and English manuals were revised against the implementation. A new contest-workflow chapter connects the individual functions into a practical operating sequence, while the sections on dual chat, private-message handling, QRG synchronisation, Simplelogfile evaluation and configuration were clarified.
+
+- The website feature pages now describe band and direction opportunities, the station map, QRG handling, filters, global message views, private-message handling and logger synchronisation in more detail.
+
+- The AUR package definitions were updated for v1.43.0.
+
+The complete v1.43.0 functionality is available in [Release v1.43.0](https://github.com/praktimarc/kst4contest/releases/tag/v1.43.0). Because its embedded version metadata is inconsistent, v1.43.1 is the recommended package set.
+
+---
+
+## v1.42.0 (2026-08-22)
+
+**Shared band context, session-based ON4KST connection and signed macOS packages**
 
 v1.42 brings several previously separate calculations together. Band information, Worked status, NOT-QRV marks, callsign suffixes and frequencies are now used more consistently by the user list, station map, priority calculation and external interfaces.
 
@@ -35,6 +135,8 @@ v1.42 brings several previously separate calculations together. Band information
 
 - **Manual QTF input:** The current antenna direction can be changed directly in KST4Contest when PSTRotator is not being used.
 
+- **`MYQTF` message variable:** The current antenna direction can be inserted as a numeric angle in degrees into shortcuts, snippets and other supported message texts.
+
 - **Filter reset:** A dedicated reset button reliably removes the active user-list filter predicates.
 
 - **Map clustering:** Stations close to each other are grouped at lower zoom levels. The selected station and relevant direction opportunities remain individually visible.
@@ -71,7 +173,7 @@ v1.42 brings several previously separate calculations together. Band information
 
 - **Exact sked targets:** The timeline and automatic reminders use the complete visible KST callsign. A sked for `DN9APW-2` is not accidentally sent to another variant of the same base callsign.
 
-- **Reworked beacon and automatic replies:** Both chat categories use one shared timer while retaining separate enable switches and message texts. The minimum permitted interval is two minutes and message texts are limited to 120 characters. The stored beacon state is restored from the configuration at startup.
+- **Reworked beacon and automatic replies:** Both chat categories use one shared timer while retaining separate enable switches and message texts. The minimum permitted interval is one minute and message texts are limited to 120 characters. The stored beacon state is restored from the configuration at startup.
 
 - **Central variable resolution:** Message variables used by beacons, shortcuts, snippets and other generated text are processed by one shared resolver.
 
@@ -81,6 +183,8 @@ v1.42 brings several previously separate calculations together. Band information
 
 - **DXLog full-log import:** In addition to `contactinfo`, the UCXLog-compatible UDP listener processes `contactreplace`. This allows a complete log broadcast by DXLog.net to be imported.
 
+- **Guarded automatic QRG updates:** `MYQRG` is updated only by an enabled interface which actually supplies valid `RadioInfo` or Win-Test `STATUS` packets. An enabled source which provides no data does not remove the need for a functional check or manual QRG maintenance.
+
 - **Improved version comparison:** Versions are compared semantically so that patch releases and Nightly versions are not misclassified by conversion to a floating-point number.
 
 ### Fixed
@@ -93,6 +197,8 @@ v1.42 brings several previously separate calculations together. Band information
 
 - **Message-bus diagnostics:** Correctly processed ON4KST frames are no longer reported additionally as `Critical, detected unhandled Chatmessage`. Only genuinely unknown frames reach the fallback diagnostic branch.
 
+- **Password in diagnostic output:** The ON4KST password is no longer written in plain text to the console or error log during connection setup.
+
 - **Long-running station-selection failure:** Chat members managed by the message thread have been decoupled from the JavaFX view. Simultaneous data and table updates therefore no longer cause broken selection models or concurrent-modification problems after longer runtimes.
 
 - **No phantom chat members from UM3:** Historical or additional server messages no longer create user-list entries for stations which are not actually logged into the chat.
@@ -137,6 +243,8 @@ v1.42 brings several previously separate calculations together. Band information
 
 - More detailed configuration of station height, frequency and K factor is being tracked in [Issue #74](https://github.com/praktimarc/kst4contest/issues/74).
 
+The published version is available as [Release v1.42.0](https://github.com/praktimarc/kst4contest/releases/tag/v1.42.0).
+
 ---
 
 ## v1.41.1 (2026-07-08)
@@ -407,7 +515,6 @@ First publicly released version. Core features:
 
 ## Planned Features
 
-- `MYQTF` variable (own antenna direction as text)
 - ~~Lifetime for worked status (automatic reset)~~ ✅ **Implemented in v1.40** (3-day lifetime, no manual reset needed anymore)
 - Filtering the "Cluster & QSO of others" window to own QTF
 - Further topography-based calculations for direction warnings

github_docs/en-Configuration.md

@@ -4,7 +4,7 @@
 
 After the first start, the **settings window** opens – this is the central starting point for all configuration. It is recommended to keep the settings window open during operation (e.g. to quickly toggle the beacon on and off).
 
-> **Important**: Always click **"Save Settings"** after any change! Settings are stored in `~/.praktikst/preferences.xml` on Linux and in `%USERPROFILE%\.praktikst\preferences.xml` (or `C:\Users\<Username>\.praktikst\preferences.xml`) on Windows. From v1.21 onwards, window sizes and divider positions are also saved when you click Save.
+> **Important**: Use **Save Settings** for functional settings which should remain in effect after the next start. KST4Contest saves layout changes such as window sizes, divider positions and table-column widths automatically. The shared file is `~/.praktiKST/preferences.xml` on Linux and macOS and `%USERPROFILE%\.praktiKST\preferences.xml` (or `C:\Users\<Username>\.praktiKST\preferences.xml`) on Windows.
 
 ---
 
@@ -14,14 +14,15 @@ After the first start, the **settings window** opens – this is the central sta
 
 ### Login and Chat Categories
 
-Enter your ON4KST chat credentials here (callsign and password).
-Also, select the **primary chat category** (e.g., IARU Region 1 VHF/Microwave).
+Enter the one local login callsign and password used for the ON4KST chat. Also select the **primary chat category** (e.g. IARU Region 1 VHF/Microwave).
 
-With the option for a **second chat** (Multi-Channel Login), you can log in to another category simultaneously (e.g., UHF/SHF). Both chats will then be monitored in parallel. You can optionally specify a different login name for the second chat (useful for Opposite Station Multi-Callsign Logging).
+The **second chat** option (Multi-Channel Login) adds another category (e.g. UHF/SHF) to the same ON4KST TCP session through Single Sign-on. KST4Contest does not open a second TCP connection and does not use another local login callsign or password.
+
+**Name in Chat 2** configures only the visible, category-specific name field for the second category. It is neither another login nor a message destination. The visible name field, message context, QRG and beacon remain separate for each category. **Opposite Station Multi-Callsign Login Tagging**, by contrast, refers exclusively to remote stations which appear in the chat under several complete visible callsign variants.
 
 ### Callsign and Locator
 
-Enter your own callsign and Maidenhead locator (6 characters, e.g., `JN49IJ`). These values are needed for distance and direction calculations.
+Enter your own callsign and Maidenhead locator (6 characters, e.g. `JN49IJ`). The locator is not part of authentication. ON4KST shares it between both categories in the one TCP session, and KST4Contest also uses it for distance and direction calculations.
 
 ### Active Bands
 
@@ -40,13 +41,23 @@ After a change, click **Save Settings** and restart KST4Contest. Band columns an
 
 ### Antenna Beamwidth
 
-Enter a realistic value for your antenna's beamwidth (in degrees). This value is used for the [Sked Direction Highlighting](en-Features#sked-direction-highlighting). A test value of 50° has proven effective; DM5M uses quads with 69°.
+Enter the complete horizontal beamwidth of the local antenna in degrees. KST4Contest applies half of this value to either side of the selected or derived antenna direction. A configured value of `70°` therefore produces a corridor of `±35°`.
 
-> **Do not** enter fantasy values – the direction calculations will become useless.
+The value is used for:
+
+- the QTF filter in the user list;
+- the display of the local antenna corridor; and
+- the assumed beamwidth of a remote station when [deriving directional opportunities](en-Features#directional-opportunities-from-directed-messages).
+
+The final use is deliberately an approximation. ON4KST transmits neither the antenna being used nor its beamwidth. KST4Contest therefore uses the local value as a practical assumption for the remote station.
+
+Choose a realistic value for the actual station setup. A value which is too large produces many geometrical matches with little practical meaning. A value which is too small may hide useful directional opportunities.
 
 ### Default Maximum QRB
 
-Maximum distance (in km) for which direction warnings should be triggered. A realistic value for DM5M is 900 km. Stations farther away are ignored for highlighting purposes.
+Enter the maximum distance in kilometres within which KST4Contest should consider directional opportunities. The relevant distance is between the local station and the sender of the directed message, not between sender and receiver.
+
+If the sender is farther away, the situation is neither highlighted nor forwarded as an automatic directional opportunity to the local DX Cluster server, even if the calculated angle would match.
 
 ### Path Analysis and Link Budget
 
@@ -117,13 +128,15 @@ The **Log sync** tab selects the sources from which KST4Contest imports worked s
 | **General QSO UDP listener** | QSO packets from UCXLog, QARTest, N1MM+ and DXLog.net | global and per-band Worked status plus worked grid square where both band and locator are transmitted |
 | **Win-Test network listener** | native Win-Test network packets | global and per-band Worked status, locator information and, depending on the settings, QRG synchronisation and sked handover |
 
-The file-based interpreter is mainly useful when the logging application provides no supported network interface. A callsign match alone, however, contains neither a reliable band nor a locator. Use one of the network listeners wherever possible if per-band information is required.
+The file-based interpreter reads the selected text file once per minute using a fixed callsign pattern. Matches are normalised to base callsigns and set only the global Worked status for all active variants. It is mainly useful when the logging application provides no supported network interface. A callsign match alone contains neither a reliable band nor a locator, so use one of the network listeners wherever possible if per-band information is required.
+
+If the selected file does not exist, KST4Contest creates it and displays its full path together with checks for initial setup and the next contest. The file itself is the durable source; Worked marks derived from it are not stored in SQLite and are not reset automatically for a new contest.
 
 The general QSO UDP listener is the recommended interface for UCXLog, QARTest, N1MM+ and DXLog.net. QSO and `RadioInfo` packets use the same configurable UDP port; the default is `12060`. Separate options in **Log sync** and **TRX sync** determine whether the received QSO and frequency information is processed.
 
 Win-Test uses its own network protocol and therefore has a separate listener. Its default port is `9871`. If this port is changed while the listener is enabled, KST4Contest restarts the Win-Test listener on the new port. After changing the shared UDP port `12060`, KST4Contest must instead be restarted completely.
 
-All enabled input paths may be used in parallel. Their Worked information is merged into the same internal database; identical reports do not create separate Worked states. KST4Contest must be running when a QSO is saved unless the logging application can resend the existing log.
+All enabled input paths may be used in parallel and identical reports do not create separate Worked states. Network-derived Worked information is stored in the internal database. Simplelogfile marks remain runtime state derived from the selected file. Before using Simplelogfile, check whether the logging application already provides one of the supported network interfaces. KST4Contest must be running when a network QSO is transmitted unless the logging application can resend the existing log.
 
 Configuration of the individual logging applications, band and locator handling, and the Win-Test sked handover are described under [Log Synchronisation](en-Log-Sync).
 
@@ -143,7 +156,7 @@ TRX synchronisation imports the current frequency from the logging application a
 | **Win-Test STATUS** | `Win-Test STATUS QRG Sync` | Processes the main or pass frequency from native Win-Test `STATUS` packets. The Win-Test listener uses its separately configured port, which defaults to `9871`. |
 | **Manual entry** | Disable both automatic QRG sources | The local QRG can be entered manually in the main window. |
 
-The general listener is intended for logging applications which transmit compatible `RadioInfo` packets. Depending on their individual configuration, this includes UCXLog, N1MM+, QARTest and DXLog.net. QSO and `RadioInfo` packets use the same port configured under **Log sync**, but separate options determine whether KST4Contest processes QSO information, TRX information or both packet types.
+The general listener is intended for logging applications which transmit compatible `RadioInfo` packets. Depending on their individual configuration, this includes UCXLog, N1MM+, QARTest and DXLog.net. QSO and `RadioInfo` packets use the same port configured under **Log sync**, but separate options determine whether KST4Contest processes QSO information, TRX information or both packet types. An automatic QRG source must be enabled and actually supply valid packets; enabling it alone does not update `MYQRG`.
 
 Restart KST4Contest after changing the shared UDP port. Changes to the two QRG-sync checkboxes take effect immediately.
 
@@ -153,7 +166,7 @@ Both automatic sources update `MYQRG` only. This is the local QRG of the first o
 
 If a second chat is enabled, its QRG remains independent. It is not derived from incoming TRX packets and is available through `SECONDQRG`. The first category can therefore follow the logging application's frequency automatically while a separate QRG is entered manually for the second category.
 
-As soon as at least one automatic QRG source is enabled, the first category's QRG field in the main window is bound to the received value. Manual entry becomes available again when both the general RadioInfo listener and Win-Test STATUS synchronisation are disabled.
+When at least one automatic QRG source is enabled and supplies a valid value, the first category's QRG field in the main window follows the received frequency. If the expected packets do not arrive, verify the interface before the contest. Manual entry is available when both the general RadioInfo listener and Win-Test STATUS synchronisation are disabled.
 
 ### Main or Pass Frequency from Win-Test
 
@@ -363,11 +376,15 @@ AirScout setup, aircraft display and the meaning of the returned AP information
 
 ![Notifications, DX cluster output and QSO monitoring](client_settings_window_notification.png)
 
-Three notification types are available:
+The three audio functions work independently:
 
-1. **Simple sounds**: TADA sound for incoming messages, tick for sked direction detection, etc.
-2. **CW announcement**: The callsign of a station sending a private message is output as a CW signal.
-3. **Phonetic announcement**: The callsign is pronounced phonetically.
+1. **Simple sounds**: Plays short cues for new private messages, detected directional opportunities, sked reminders and `BAND+` hints.
+2. **CW announcement**: Spells the sender's callsign in CW for a new private message.
+3. **Phonetic announcement**: Speaks the sender's callsign phonetically for a new private message.
+
+Each function can be enabled separately. CW and phonetic output can also be active at the same time.
+
+PM-related audio output is triggered only by messages actually directed to the local login callsign. Messages shown additionally through PM Catching and messages added through QSO Monitoring remain silent.
 
 ### Fallback Band for Relative QRG Detection
 
@@ -411,12 +428,14 @@ The following settings and controls belong to the local DX cluster output:
 
 ```text
 Spotted callsign: DO5AMF
-Comment: Testing DXC-Spot: Congrats, you donated $100!
+Comment: DXC test: You donated $100!
 Frequency: .300 on the selected fallback band
 ```
 
 With `144 MHz` selected as the fallback band, the resulting frequency is approximately `144.300 MHz`.
 
+All spots use a fixed, DXSpider-compatible 75-character payload line with a 30-character comment field. Longer comments are deliberately truncated at this protocol boundary; the DX callsign is not. A callsign longer than twelve characters causes the affected spot to be rejected and logged.
+
 The comment is a deliberately retained Easter egg. It has no technical meaning and, despite being remarkably specific, does not initiate a payment. Its practical purpose is to make the test spot easy to identify in the logging software.
 
 The test works only if
@@ -562,7 +581,7 @@ KST4Contest uses one shared timer for both chat categories. Each category nevert
 - **Beacon message** contains the public message for that category.
 - **Shared beacon interval** sets the common interval used by both categories.
 
-When both beacons are enabled, they are sent one after the other in their respective categories during the same timer run. The second beacon is only considered while the second chat is enabled and connected.
+When both beacons are enabled, they are sent one after the other in their respective categories during the same timer run. The second beacon is only considered while the second category is enabled and fully synchronised in the same ON4KST session.
 
 ### Interval and timer behaviour
 
@@ -765,7 +784,7 @@ Data handling and QRG selection: [Log Synchronisation – Win-Test](en-Log-Sync#
 
 ---
 
-## PSTRotator Settings (from v1.31)## PSTRotator Settings (from v1.31, fully configurable from v1.40)
+## PSTRotator Settings (from v1.31, fully configurable from v1.40)
 
 KST4Contest can set an antenna direction through the PSTRotator UDP interface and use the current position reported by PSTRotator as the local QTF.
 
@@ -874,7 +893,7 @@ The entered value may contain a visible KST suffix or portable components. KST4C
 
 Changes to the list take effect immediately. Press **Save Settings** afterwards to retain them. The base callsigns are stored in `preferences.xml` and restored at the next program start.
 
-> Base-callsign monitoring across KST suffixes is included in Nightly / v1.42.
+> Base-callsign monitoring across KST suffixes is included from v1.42 onwards.
 
 Further background and the distinction from message routing: [QSO Sniffer](en-Features#qso-sniffer-from-v131).
 
@@ -902,6 +921,8 @@ The internal SQLite database stores contest-related state independently of the l
 - manually assigned NOT-QRV marks per band, and
 - worked four-character grid squares per band.
 
+Worked marks from the Simplelogfile interpreter are the exception. They are copied from the selected file into runtime state only and are not persisted in SQLite. The file is the durable source and has no automatic contest reset. A database reset does not change or empty it; callsigns contained in the file are marked as worked again during the next periodic evaluation.
+
 The normalised callsign, without visible chat brackets or category formatting, is used as the key. This allows active variants of the same callsign to be evaluated consistently.
 
 Worked and NOT-QRV information expires automatically three days after its most recent change. Stored grid squares expire three days after the corresponding log entry. A manual reset before every contest is therefore normally unnecessary.
@@ -914,16 +935,74 @@ Display and derivation: [Worked Callsigns, New Bands and New Grid Squares](en-Fe
 
 ---
 
+## Operator Profiles (from v1.50)
+
+Several operators sharing one computer need different callsigns, locators and layouts. An operator profile bundles exactly that: **every profile has its own `preferences.xml`, and therefore its own settings and its own window layout.**
+
+### Where the profiles live
+
+| Profile | Settings | Worked stations |
+|---|---|---|
+| **Default** | `~/.praktiKST/preferences.xml` | `~/.praktiKST/praktiKST.db` |
+| additional profiles | `~/.praktiKST/profiles/<profile ID>/preferences.xml` | shared, or `~/.praktiKST/profiles/<profile ID>/praktiKST.db` |
+
+On Windows the same files live below `%USERPROFILE%\.praktiKST\`.
+
+Everything else stays shared: audio files, colour schemes, DEM and terrain packages, the terrain profile cache (`terrainprofilecache.db`), the error log and the version information.
+
+The **Default** profile keeps using exactly the files an existing installation already has. **Upgrading to v1.50 moves, copies and rewrites nothing.** Anyone reinstalling an older KST4Contest release finds their configuration and their worked stations unchanged.
+
+### Shared or own worked stations
+
+When a profile is created you decide where its worked, NOT-QRV and grid data come from:
+
+- **Own worked stations** (default): the profile gets its own, initially empty database. This is what two operators with different callsigns sharing a private computer want.
+- **Common station database**: the profile uses `~/.praktiKST/praktiKST.db`, the same database as the **Default** profile. This is the **multi operator station** case: there is only one station log, so the worked state should be the same for every operator.
+
+Switching between the two settings moves no data. Worked data already collected stays where it was created. The three day expiry and the reset button always act on the database of the currently active profile.
+
+### Managing profiles
+
+The **Profiles** tab in the settings window lists all profiles with their name, the kind of worked data they use and when they were last used.
+
+- **New profile...** creates a profile. It starts **without callsign and password**; both are entered afterwards on the **Station** tab.
+- **Duplicate...** copies the complete configuration of the selected profile - antenna, locator, layout, beacon, integrations - **except callsign and password**. Worked stations are never copied.
+- **Rename...** changes the displayed name only. Folders and files are untouched.
+- **Delete...** removes the profile folder permanently. The **Default** profile and the currently active profile cannot be deleted. For a profile using the common station database, that database is left untouched.
+- **Change worked stations...** switches between the common and an own database.
+- **Switch to selected profile...** changes the profile while the application is running.
+
+### Choosing a profile at startup
+
+- As long as only **one** profile exists, KST4Contest asks **nothing** at startup and starts exactly as before. No profile registry is created either; only creating the second profile writes `~/.praktiKST/profiles.xml`.
+- From **two** profiles on, a small selection appears at startup. The last used profile is preselected, and **Enter** or a double click start immediately.
+- The `--profile=<name>` argument skips the selection and starts the named profile directly. Both the profile ID and the displayed name are accepted, case insensitively. An unknown name produces a note and then the normal selection - startup is never refused.
+
+### Switching profiles while running
+
+**File > Switch operator profile...**, or the button on the **Profiles** tab, switches without restarting the program. After a confirmation the ON4KST connection is closed and the user interface is rebuilt with the settings and layout of the selected profile. The layout of the previous profile is saved first; settings not yet confirmed with **Save Settings** are lost.
+
+Once more than one profile exists, the main window title also shows the profile name.
+
+### A note about passwords
+
+As before, the ON4KST password is stored in clear text in the `preferences.xml` of each profile. On a shared computer, anyone with access to the user account can read the passwords of all profiles. Profiles separate configuration; they are **not** an access control mechanism.
+
+---
+
 ## Dark Mode (from v1.26)
 
-Toggle via the menu: **Window → Use Dark Mode**. The colors can be individually customized via CSS.
+Enable Dark Mode through **Windows → Use dark mode design**. Use **Windows → Use default mode design** to restore the normal light colour scheme.
 
 ---
 
 ## Saving Settings
 
-Click **"Save Settings"** after **every** change! Without saving, all changes will be lost on the next start.
+**Save Settings** stores functional settings and the complete current layout. Changes to window sizes and positions, relevant dividers, managed table-column widths and the **Group nearby stations** map setting are also saved automatically after a short delay. Any pending layout update is written when the programme exits.
 
-- Storage location: `~/.praktikst/preferences.xml` on Linux and `%USERPROFILE%\.praktikst\preferences.xml` (or `C:\Users\<Username>\.praktikst\preferences.xml`) on Windows
-- From v1.21: Window sizes and divider positions are also saved.
+- Storage location: `~/.praktiKST/preferences.xml` on Linux and macOS and `%USERPROFILE%\.praktiKST\preferences.xml` (or `C:\Users\<Username>\.praktiKST\preferences.xml`) on Windows
+- The automatic layout writer does not copy functional changes which have not yet been confirmed with **Save Settings**.
+- Configuration version 6 adds optional column-width entries below `guiOptions`. Older `preferences.xml` files remain readable. Missing or invalid widths simply cause KST4Contest to calculate useful initial widths again.
+- Configuration version 7 adds `GUIstationMapClusteringEnabled` below `guiOptions`. If the entry is missing or unusable, spatial map clustering remains enabled.
+- Older programme versions ignore the additional XML entries. If an older version rewrites the complete file, column widths and the stored **Group nearby stations** choice may be lost.
 - If you encounter problems: delete the configuration file → KST4Contest will create a new one with default values.

github_docs/en-Contest-Workflow.md

@@ -0,0 +1,292 @@
+# Contest Workflow with KST4Contest
+
+> You are reading the English version | [Deutsche Version](de-Contest-Workflow)
+
+KST4Contest brings chat activity, station selection, known QRGs, worked status, skeds, aircraft scatter timing and other station data together in one interface. Its value does not come from one individual indicator, but from the way this information works together during an active contest.
+
+This page describes a complete operating workflow. Individual functions and their technical limitations remain documented under [Features](en-Features), [User Interface](en-User-Interface), [Log Synchronisation](en-Log-Sync) and [AirScout Integration](en-AirScout-Integration).
+
+---
+
+## Purpose and Limitations
+
+KST4Contest is intended to reduce the time between recognising an opportunity and attempting the actual QSO.
+
+The programme can show, among other things:
+
+- which stations are active,
+- on which bands and QRGs they were most recently detected,
+- which stations have already been worked,
+- which additional bands may still be available,
+- which candidates match the current antenna direction,
+- when an aircraft scatter window is expected, and
+- which station is currently working in a direction useful to the local station.
+
+These remain decision aids. A high priority score is not a QSO probability. An aircraft geometry rated at 100% by AirScout does not guarantee a contact either. The operator must still decide whether a QRG is actually clear, whether the remote station is listening and whether the path works under the current conditions.
+
+---
+
+## Before the Contest
+
+The important settings should be checked before the first interesting sked appears.
+
+### Basic Configuration
+
+Check at least:
+
+- the local callsign, password and locator,
+- the primary chat category,
+- login and settings for the second category if it is used,
+- locally enabled bands,
+- antenna beamwidth,
+- maximum useful distance,
+- `MYQRG` and, where applicable, `SECONDQRG`,
+- log synchronisation, and
+- the required shortcuts, snippets and message variables.
+
+Antenna beamwidth and maximum distance depend on the station. At DM5M, for example, the actual antenna system is represented by a beamwidth of 69° and a maximum distance of 900 km. These are not general recommended values.
+
+Use **Save Settings** for permanent changes. After connecting, the `LINK` indicator should be green. Only then have login and user-list synchronisation been completed.
+
+### Automatic Replies
+
+The automatic QRG reply is part of the active contest workflow. It answers repeated QRG requests and removes some routine work from the chat operator.
+
+This is different from the general automatic reply. The general reply can react to all incoming requests and is mainly useful while the station is temporarily not QRV or does not want to take part in sked operation. It avoids unnecessary follow-up work for both the local and requesting stations.
+
+### Optional Connections
+
+Enable only interfaces which are actually required and have already been tested:
+
+- logging software or Simplelogfile,
+- TRX synchronisation,
+- AirScout,
+- PSTRotator,
+- Win-Test sked handover, and
+- the local DX Cluster server.
+
+A contest is not an ideal time to investigate radio conditions and a newly enabled network interface at the same time.
+
+Before each contest, verify that the logging application writes the current contest file to the path selected for the Simplelogfile. A test QSO should appear as globally worked within one minute. KST4Contest does not reset Worked marks derived from this file automatically when the contest changes.
+
+---
+
+## Basic Contest Cycle
+
+The normal operating cycle repeats:
+
+1. Call CQ or run an agreed sked.
+2. Monitor chat activity, the priority list, map and AP timeline.
+3. Select a suitable candidate.
+4. Decide between the local and remote QRG.
+5. Attempt the QSO.
+6. Log a successful contact immediately.
+7. Check for another band opportunity.
+8. Mark a meaningful failed attempt with **Sked fail**.
+9. Return to CQ operation or continue with the next candidate.
+
+KST4Contest keeps the required information together between these steps. Changing frequency, calling, listening and making the actual decision deliberately remain operator tasks.
+
+---
+
+## CQ Operation
+
+During operation on a mainly fixed CQ frequency, `MYQRG` and `SECONDQRG` should match the frequencies actually in use. TRX synchronisation can update `MYQRG` automatically only when it is enabled and actually supplies valid packets. Before the contest, verify this with a real frequency change. Without a working automatic source, the value must be maintained manually.
+
+The beacon can publish the current QRG, locator and antenna direction in the chat at regular intervals. Its variables are evaluated again for every transmission.
+
+Disable the beacon while scanning across several frequencies. An automatically published QRG is useful only while it is still correct.
+
+Shortcuts and snippets should cover the messages required regularly, for example:
+
+- asking a station to listen on the local QRG,
+- asking for the remote QRG,
+- announcing a move to the remote QRG,
+- confirming antenna direction, and
+- proposing a sked.
+
+Further details are available under [Macros and Variables](en-Macros-and-Variables).
+
+---
+
+## Selecting Candidates
+
+The user list can be reduced to the current operating situation by combining QTF, QRB, Worked, band, activity, New Bands, Tropo and AirScout filters.
+
+The priority list and AP timeline add further context:
+
+- The priority score combines several known criteria.
+- The AP timeline arranges skeds and expected aircraft scatter opportunities by time.
+- The station map shows geographical position, antenna direction and radio path.
+- Worked and band status help prevent unnecessary duplicate work.
+
+![Priority list and evaluation information](priority_score_overview.png)
+
+The score is a sorting aid. Before attempting a contact, continue to check the callsign, category, band, QRG, direction, distance and age of the underlying information.
+
+A deliberate selection in the user list, priority list, timeline or map selects the concrete chat member. The complete visible callsign and its chat category are retained. KST4Contest then prepares `/cq CALLSIGN` in the send field.
+
+---
+
+## Using the Local or Remote QRG
+
+When a useful propagation direction is detected and a suitable aircraft is available for a candidate, the remote station is often first asked to listen on the local QRG. This is particularly useful while CQ operation is already running there and the station can receive immediately without another change.
+
+If the remote station does not respond, its own QRG is more suitable or it cannot use the requested frequency, the local station changes frequency. KST4Contest keeps the most recently detected QRGs available, so the operator does not have to search the complete chat history again.
+
+A deliberate attempt on the QRG of a sked partner is also part of the normal workflow. The objective is not to remain on the local QRG at all costs, but to use the available opportunity with as little delay as possible.
+
+Before changing frequency, check at least:
+
+- the correct band,
+- the complete target callsign,
+- the remote station’s QRG,
+- antenna direction,
+- the expected aircraft scatter window, and
+- whether the QRG is clear.
+
+---
+
+## Using Directional Opportunities
+
+A directed message between two other stations may indicate that the sender’s antenna is pointing approximately towards the receiver. If this direction is also useful for the local station, KST4Contest temporarily displays the sender in green and bold.
+
+![Directional opportunity displayed in green and bold](direction_opportunity_highlight.png)
+
+The indication appears in the user list and associated views. With an appropriate cluster configuration and a known QRG, the opportunity may additionally be made available through the local DX Cluster.
+
+Several relevant details are therefore already available when the opportunity appears:
+
+- complete callsign,
+- locator and direction,
+- most recently detected QRG,
+- band information,
+- AirScout data, and
+- the current Reachability or Tropo assessment.
+
+The operator does not have to collect this information first. The remaining decision is whether the opportunity justifies briefly interrupting ongoing CQ operation.
+
+At DM5M, practical evaluation of these opportunistic attempts has so far produced a success rate of approximately 35–40%. This value describes the experience of one particular station. It is not a general prediction and depends on factors such as band, distance, station equipment, response time and propagation conditions.
+
+CQ operation or the next sked can continue immediately after the attempt.
+
+---
+
+## Planning and Evaluating Skeds
+
+Enter a sked with the band actually intended for the contact and a realistic time. KST4Contest adds it to its internal sked management and takes it into account for reminders, the timeline and priority calculation.
+
+Skeds are maintained only for the current programme session. They are not a persistent replacement for the contest log or operating notes.
+
+If the Win-Test connection is enabled, KST4Contest additionally attempts to pass the sked to Win-Test. If no usable QRG exists or the band does not match, the internal sked remains available. Only the additional handover may be skipped.
+
+### Failed 100% Aircraft Skeds
+
+If a carefully prepared attempt fails despite an aircraft geometry rated at 100% by AirScout, mark the station with **Sked fail**.
+
+The 100% indication is not a probability of completing the QSO. A failure under these conditions is nevertheless useful operating evidence that the path did not work with the current station configuration and current conditions.
+
+The mark reduces that station’s priority for the remainder of the current session. This allows candidates without comparable negative operating evidence to be handled first.
+
+**Sked fail** must not be treated as a permanent statement that the station cannot be worked. Different conditions, another band or a changed station configuration may produce a different result. The mark can be reset and is not retained after restarting the programme.
+
+---
+
+## After Every QSO: Logging and the Next Band
+
+Enter a successful QSO in the connected logging programme immediately. Only then can worked status, band status, filters and priority evaluation be updated in time.
+
+The available detail depends on the log source. Some interfaces provide band, QRG and locator, while simpler sources report only a global worked state.
+
+Immediately after every log entry, check whether another common, locally enabled and unworked band is available for the same station. KST4Contest indicates this through `BAND+` and the station’s band information where the available data permits such an evaluation.
+
+This check is useful in every form of multiband operation. The remote station can be coordinated directly to another band with a specific band and frequency before it turns its antenna away or starts another sked.
+
+In plain terms: check the next possible QSO while the remote station is still available and the common context still exists.
+
+If the station is not actually QRV on an indicated band, mark that band as NOT QRV. This removes the unusable opportunity from filters and evaluation instead of allowing it to reappear after every update.
+
+---
+
+## Multi-Category and Multiband Operation
+
+Multi-category operation is not a secondary feature for multiband stations. Its main advantage is that information from two chat categories can be evaluated within one operating workflow.
+
+The benefit is particularly large for:
+
+- single-operator multiband stations,
+- multi-operator multiband stations using one central chat coordinator, and
+- stations which regularly attempt another band immediately after a QSO.
+
+Worked state, known band activity and band opportunities can be evaluated together. The concrete message target still retains its complete callsign and chat category.
+
+This allows the chat operator to coordinate a station directly from the first QSO to another band without searching again for callsign, QRG and band status. In practical operation, this can produce a very rapid sequence of usable QSO opportunities. This is where multi-category operation provides its greatest workflow advantage.
+
+The same approach remains effective in single-operator operation. The operator still has to change bands personally, but the next useful opportunity is already prepared.
+
+Multi-multi stations with several active chat operators benefit as well. Responsibilities, band changes and requests already in progress must then be coordinated clearly. Several operators having the same information is useful; several contradictory sked requests sent to the same station are not.
+
+---
+
+## Practical Examples
+
+### DM5M: CQ First, More Skeds Later
+
+During the first four to five hours of a VHF/UHF contest, DM5M operates mainly by calling CQ. The chat is monitored, but used only for a small number of deliberate interventions.
+
+Sked activity increases later. Useful propagation directions, suitable aircraft scatter windows, unworked stations and additional band opportunities are then combined deliberately.
+
+A suitable station is first asked to listen on the local QRG. If it does not respond or cannot use that QRG, DM5M moves to the remote station’s frequency. Planned attempts directly on a sked partner’s QRG are also part of the process.
+
+A green and bold directional opportunity may briefly interrupt CQ operation. Calling or sked operation continues immediately after the attempt.
+
+This is a practical example, not a required operating method. Other stations may start arranging skeds considerably earlier, change QRG continuously or make more intensive use of the chat from the beginning.
+
+### G1YBB: Working Directional Opportunities Systematically
+
+G1YBB uses the directional indication particularly consistently. Stations highlighted in green are checked systematically and worked where possible while normal CQ operation continues in parallel.
+
+KST4Contest does not automate the QSO. Its advantage is that QRG, direction, aircraft scatter information and other evaluation data are already available when the opportunity appears. The remaining task is a quick operating decision.
+
+Another particularly consistent operating method uses the station map as a geographical worklist:
+
+1. The **wkd** filter removes already worked callsigns from the user list and therefore from the map.
+2. G1YBB selects an interesting station on the map.
+3. **Trigger cluster spot** passes the known QRG to Minos.
+4. Selecting the spot moves Minos to that QRG.
+5. The completed QSO is logged.
+6. Log synchronisation updates the Worked state, and the filter removes the station from both the user list and the map.
+
+The map consequently becomes a spatial list of the stations still to be worked. This workflow is optional. It requires reliable log synchronisation and a working DX Cluster connection and is mainly useful for operators who deliberately want to organise the contest in this geographical way.
+
+[Watch G1YBB demonstrate this workflow.](https://www.youtube.com/watch?v=lMQZMiSHlUI)
+
+---
+
+## Optional Interfaces in the Workflow
+
+| Interface | Contest task |
+|---|---|
+| [Log Synchronisation](en-Log-Sync) | Updates worked and band status after a QSO |
+| [AirScout](en-AirScout-Integration) | Supplies aircraft scatter candidates and expected time windows |
+| [PSTRotator](en-Configuration) | Receives or sets the antenna direction |
+| [Win-Test](en-Log-Sync) | Can additionally pass entered skeds to Win-Test |
+| [DX Cluster Server](en-DX-Cluster-Server) | Passes detected opportunities to connected logging programmes |
+| [Station Map](en-User-Interface) | Shows stations, directions, selection and radio path |
+
+None of these interfaces is mandatory for basic chat operation. Their value appears when they are configured reliably and shorten a specific manual task.
+
+---
+
+## What KST4Contest Does Not Decide
+
+KST4Contest does not decide:
+
+- whether a QRG is actually clear,
+- whether the remote station can currently listen,
+- whether an aircraft will enable a QSO,
+- whether a calculated radio path works under the current conditions,
+- whether ongoing CQ operation should be interrupted for an opportunity, or
+- which candidate has the greatest value for the current contest strategy.
+
+The programme assembles the available information and keeps it current. The final decision remains with the operator. This is not a limitation of the workflow; it is the part for which we are still operating radios rather than spreadsheets.

github_docs/en-DX-Cluster-Server.md

@@ -2,99 +2,280 @@
 
 > 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-DX-Cluster-Server)
 
-From **version 1.23**, KST4Contest includes a built-in DX cluster server. It sends spots directly to the logging software whenever a direction warning is triggered.
+Since version 1.23, KST4Contest has included a local DX Cluster server. It forwards detected directional opportunities and their frequencies to the DX Cluster client of a logging programme.
 
-*(Idea by OM0AAO, Viliam Petrik – thank you!)*
+The idea came from OM0AAO, Viliam Petrik. Thank you!
 
 ---
 
-## What is the Built-in DX Cluster Server For?
+## Why Use a Local DX Cluster Server?
 
-When KST4Contest detects that a station is requesting a sked from your direction and a QRG is known, it **automatically generates a DX cluster spot** and feeds it directly to the logging software's cluster client / band map.
+Finding an interesting frequency in the chat is only the first step. During a contest, that information needs to reach the place where it can be used immediately: the logging programme and its bandmap.
 
-The logging software then displays the spot in the band map. Clicking the spot sets the transceiver's frequency and mode directly – without any manual typing.
+KST4Contest therefore combines two pieces of information it already has:
+
+1. A directed chat message can indicate the approximate direction in which the sending station may be pointing its antenna.
+2. A frequency for that station may be known from the same message or an earlier one.
+
+When both pieces fit, KST4Contest creates a local DX Cluster spot. The logger can display it in its bandmap and, depending on its own configuration, tune the transceiver to the frequency when the spot is clicked.
+
+In practical terms, the operator does not have to find the information in the chat, read it, remember it and enter it again in the logger. These small interruptions consume a surprising amount of attention during a contest.
 
 ---
 
-## Setup
+## Automatic Spots from Directional Opportunities
 
-### In KST4Contest
+Assume that station A sends a directed message to station B. KST4Contest uses the direction from A to B as an approximation of the current antenna direction of station A. It then checks whether the local station lies inside the assumed antenna corridor as seen from A.
 
-In Preferences → **DX Cluster Server Settings**:
+Two directions are compared:
 
-1. Enter the **port** of the internal server (e.g. 7300 or 8000 – must match the logging software).
-2. Enter a **spotter callsign** – **this must be a different callsign than your contest callsign!**
-   - Reason: Logging programs filter spots from your own callsign as "already worked". If the spotter uses the same callsign, the spots will not be displayed.
-3. Enter the **assumed MHz**: For frequency references like ".205" in the chat, KST4Contest needs to decide whether 144.205, 432.205 or 1296.205 is meant. For single-band contests, simply enter the corresponding band centre. Full frequency references like "144.205" or "1296.338" in the chat are always correctly identified.
+- the direction from station A to station B;
+- the direction from station A to the local station.
 
-### In UCXLog
+The **Antenna Beamwidth** configured under the Station settings is the complete angle. Half of that value is applied on either side of the direction A → B. A setting of `70°` therefore produces a corridor of `±35°`.
 
-- Configure a DX cluster server connection:
-  - Host: `127.0.0.1` (or IP of the KST4Contest computer)
-  - Port: As configured in KST4Contest
-  - Password: can be left empty
-- Use the **"Send a test message to your log"** button to test the connection.
+ON4KST does not supply antenna data for the remote station. KST4Contest therefore also uses the locally configured beamwidth as an approximation for station A. This is not a measurement of the station's actual antenna direction. It is a deliberately simple geometrical assumption.
 
-### In N1MM+
+An automatic DX Cluster spot is created only when all of the following conditions are met:
 
-Similar settings:
-- Host: `127.0.0.1` (or IP of the KST4Contest computer)
-- Port: As configured in KST4Contest
+1. A directed message between two other stations has been detected.
+2. Valid locators are known for the sender and receiver.
+3. The sender is within the configured **Default Maximum QRB** from the local station.
+4. The local station lies inside the assumed antenna corridor as seen from the sender.
+5. A usable frequency is known for the sender or detected in the current message.
+6. The local DX Cluster server is enabled.
+
+When these conditions are met, the spot is created while the message is processed. The green directional highlight shown in parallel remains visible for five minutes and may be extended or removed by later messages.
+
+The calculation does not consider terrain, current propagation or the station's actual operating intention. It identifies a plausible opportunity. The full derivation and a numerical example are available under [Directional Opportunities from Directed Messages](en-Features#directional-opportunities-from-directed-messages).
+
+---
+
+## Manual Spot for the Selected Map Station
+
+A spot can also be triggered deliberately. Select a station on the station map and use **Trigger cluster spot** in the detail panel.
+
+This manual action does not require a previously detected directed message. The maximum QRB and antenna beamwidth also do not decide whether the spot is sent. It requires:
+
+- the local DX Cluster server to be enabled;
+- at least one connected DX Cluster client; and
+- a usable QRG for the selected map station.
+
+This lets the operator send an already selected station to the bandmap even when the conditions for an automatic directional spot are not present. Map operation is described under [Station Map](en-User-Interface#station-map).
+
+Both automatic and manual spots are sent only to clients connected to KST4Contest. They are not forwarded to a public Internet cluster.
+
+---
+
+## Which Frequency Is Used?
+
+A DX Cluster spot needs an unambiguous frequency. KST4Contest uses the same QRG detection as the user list and the other band-related functions.
+
+Complete frequencies determine their band directly:
+
+```text
+144.205
+432,088
+1296.338
+10368.100
+```
+
+Relative values contain only the frequency part within a band:
+
+```text
+.205
+,205
+qrg 205
+freq is 205
+on 205
+205 MHz
+```
+
+A bare three-digit number such as `205` is not evaluated without frequency-related context. The same applies to `599`, `144` or text such as `worked 210 stations`. This prevents signal reports, band names or QSO totals from being stored as plausible-looking frequencies and later sent to the logger.
+
+For a relative QRG, KST4Contest determines the band in this order:
+
+1. It checks whether a suitable band context has been detected for the same sender during the previous 30 minutes.
+2. If several current bands are known, it uses the most recently updated plausible context.
+3. Only when no suitable station context exists does it use the band selected under **Fallback band for relative QRG detection**.
+
+Example:
+
+```text
+Global fallback: 144 MHz
+Most recent complete QRG for the station: 432.088 MHz
+New chat value from the same station: .100
+Detected QRG: 432.100 MHz
+DX Cluster frequency: 432100.0 kHz
+```
+
+Without the current 432 MHz context, the same value would use the global fallback and become `144.100 MHz`.
+
+QRG detection runs before the direction and spot checks. If a station mentions its frequency for the first time in the directed message which also triggers a directional opportunity, the resulting spot can already contain that frequency. A newly detected QRG replaces an older value for the station.
+
+The fallback band is a global QRG-detection setting. Its effect is not limited to the DX Cluster server. Configuration, supported bands and related behaviour are described under [Fallback Band for Relative QRG Detection](en-Configuration#fallback-band-for-relative-qrg-detection).
+
+---
+
+## Setting Up KST4Contest
+
+Open the **Notification** tab in Preferences.
+
+![Notification settings and local DX Cluster server](client_settings_window_notification.png)
+
+Configure the following:
+
+1. Enable **Enable the local DX Cluster server …**.
+2. Enter a free **TCP port**. The default is `8000`.
+3. Select the appropriate band under **Fallback band for relative QRG detection**.
+4. Enter a **Spotter callsign**.
+
+The spotter callsign should preferably differ from the contest callsign. Some loggers filter spots which appear to originate from the local station or handle them differently. Using the same callsign is not prohibited by KST4Contest, but it may make a correctly generated spot invisible in the bandmap.
+
+Changes to the enabled state and TCP port take effect immediately while KST4Contest is connected to the chat. Changing the port disconnects existing DX Cluster clients; the logger must reconnect to the new port.
+
+Use **Save Settings** to store the settings permanently in `preferences.xml`.
+
+---
+
+## Setting Up the Logging Programme
+
+Configure the logging programme as a DX Cluster client connected to KST4Contest.
+
+| Setting | KST4Contest and logger on the same computer | Logger on another computer |
+|---|---|---|
+| Host | `127.0.0.1` | IP address of the KST4Contest computer |
+| Port | TCP port configured in KST4Contest | TCP port configured in KST4Contest |
+| Login | Any callsign, if the logger requires one | Any callsign, if the logger requires one |
+| Password | Not required | Not required |
+
+KST4Contest does not use the login sent by the logger for authentication. The connection is intended for the local computer or a trusted station network.
+
+If the logger runs on another computer, its TCP connection must be allowed through the local firewall on the KST4Contest computer. Do not expose the port directly to the Internet without additional protection.
+
+Several DX Cluster clients can be connected at the same time. Every generated spot is sent to all clients which are currently connected.
 
 ---
 
 ## Testing the Connection
 
-After the logger's DX cluster client has connected, use **Send test spot** to generate the following entry:
+The **Send test spot** button creates the following test entry:
 
 ```text
 Spotted callsign: DO5AMF
-Comment: Testing DXC-Spot: Congrats, you donated $100!
+Comment: DXC test: You donated $100!
 Frequency: .300 on the configured fallback band
 ```
 
-With `144 MHz` selected as the fallback band, the spot appears at approximately `144.300 MHz`.
+With `144 MHz` selected as the fallback band, the spot therefore appears at approximately `144.300 MHz`.
 
-The comment is a deliberately retained Easter egg. It makes the test entry easy to identify but has no other function. In particular, no donation or other external action is triggered.
+The comment is a deliberately retained Easter egg. It only makes the test spot easy to recognise in the logger. No donation or other external action is triggered.
 
 Three conditions must be met before running the test:
 
 1. KST4Contest is connected to the ON4KST chat.
-2. The local DX cluster server is enabled.
-3. The logging software's DX cluster client is connected to KST4Contest.
+2. The local DX Cluster server is enabled.
+3. The logging programme's DX Cluster client is connected to KST4Contest.
 
 If no client is connected, KST4Contest displays a corresponding message. A successful test therefore confirms that at least one connected client received the generated spot.
 
 ---
 
-## How It Works
+## Content of a Generated Spot
 
-A spot is generated when **both** conditions are met:
+A spot contains:
 
-1. A **direction warning** has been triggered (station is making a sked in your direction).
-2. The **station's QRG is known** (read from the chat or manually entered).
+- the configured spotter callsign;
+- the normalised frequency;
+- the complete visible callsign of the detected or selected station;
+- the locator; and
+- the current UTC time.
 
-The generated spot contains:
-- Station's callsign
-- Frequency
-- Spot time
+The payload line uses a fixed, DXSpider-compatible 75-character format. The DX callsign starts in column 27, the comment field is exactly 30 characters wide and the UTC time starts in column 71. Short comments are padded with spaces; longer ones are deliberately limited to 30 characters. Different spotter-callsign lengths and frequencies up to 24 GHz do not move the following fields.
 
-The logging software can then display the spot in the band map and tune the TRX to that frequency with a mouse click.
+KST4Contest does not truncate the complete DX callsign. If it exceeds twelve characters, the spot is rejected in a controlled manner and the reason is logged.
+
+For automatically generated directional spots, KST4Contest can add up to two current AirScout entries to the comment. Missing AirScout data does not prevent the spot from being sent. A spot triggered manually from the station map uses the selected station's locator without this optional addition.
+
+An automatic comment with AirScout information may look like this:
+
+```text
+JO51HK AP 1m/100%;4m/75%
+```
 
 ---
 
-## Multi-Computer Setup
+## If No Spot Appears
 
-If KST4Contest runs on a separate computer (not the logging computer):
+### The Test Spot Does Not Reach the Logger
 
-- Host in the logging software: IP of the KST4Contest computer (not `127.0.0.1`)
-- Same configuration as for the QSO UDP broadcast packets (see [Log Synchronisation](en-Log-Sync))
+Check:
+
+- Is KST4Contest connected to the chat?
+- Is the local DX Cluster server enabled?
+- Does the logger use the same TCP port?
+- Does the logger use `127.0.0.1` when both programmes run locally?
+- Is a firewall blocking the connection?
+- Is the DX Cluster window or bandmap enabled in the logger?
+
+### The Test Works, but Automatic Spots Are Missing
+
+The TCP connection is then working in principle. At least one condition for the relevant chat situation was probably not met:
+
+- no directed message between two other stations;
+- missing locator;
+- sender outside the maximum QRB;
+- direction outside the configured beamwidth;
+- no detected frequency.
+
+KST4Contest deliberately does not send every frequency it finds to the logger. Otherwise, a feature intended to reduce distraction would quickly become a local spot generator with rather too much enthusiasm.
+
+### A Manually Triggered Spot Is Missing
+
+Check that a station is selected on the map and that it has a usable QRG. The local server must be enabled and at least one client must be connected. Directional-message geometry, maximum QRB and beamwidth are not prerequisites for the manual action.
+
+### The Spot Appears on the Wrong Band
+
+First check which frequencies were detected for the station during the previous 30 minutes. For a relative value, this station context takes priority over the global fallback.
+
+If no current station context exists, check **Fallback band for relative QRG detection**. The fallback is used only when the band cannot be determined from a complete frequency or the sender's current context.
+
+### The Logger Runs in Its Own Sandbox
+
+A logging programme started as a Flatpak, or through a Wine environment such as Bottles, uses the network permissions of that sandbox. If the sandbox does not share the host network, `127.0.0.1` inside it is not the `127.0.0.1` on which KST4Contest is listening, and the connection is refused even though KST4Contest reports the port correctly.
+
+For a Flatpak logger, check its permission with:
+
+```bash
+flatpak info --show-permissions <application id>
+```
+
+The `[Context]` section has to contain `shared=network`. It can be granted with:
+
+```bash
+flatpak override --user --share=network <application id>
+```
+
+The same applies when KST4Contest itself runs as a Flatpak. Its published manifest already contains `--share=network`, so a listening port is reachable from the host and from other applications on the same computer.
+
+### The Logger Hides the Spot
+
+Try a spotter callsign which differs from the contest callsign. Depending on the logger, spots from the local callsign may be filtered or handled specially. KST4Contest itself does not require the two callsigns to differ.
 
 ---
 
-## Tested Logging Software
+## Tested Logging Programmes
 
-- **UCXLog** ✓
-- **N1MM+** ✓
+The interface has been used with:
 
-Further test reports are welcome – please send by email to DO5AMF.
+- UCXLog
+- N1MM+
+- Minos
+
+Other loggers may work if they support a normal TCP connection to a DX Cluster server and accept conventional `DX de ...` spot lines.
+
+Related reference pages:
+
+- [User Interface](en-User-Interface)
+- [Features](en-Features)
+- [Configuration](en-Configuration)

github_docs/en-Features.md

@@ -6,45 +6,122 @@ Overview of all main features of KST4Contest.
 
 ---
 
-## Sked Direction Highlighting
+## Directional Opportunities from Directed Messages
 
-One of the core features: when a station makes a sked request **towards your direction**, it is highlighted **green and bold** in the user list.
+The ON4KST chat shows which station directs a message to which other station. It does not transmit the actual antenna direction. A directed message can nevertheless provide a useful indication during a contest: a station requesting, answering or preparing a sked will normally point its antenna at least approximately towards the station being addressed.
 
-### How does it work?
+KST4Contest therefore evaluates directed messages between two other stations. The message does not have to be explicitly identified as a sked request. The relevant information is the sender, receiver and their locators.
 
-The calculation is based on the following logic:
+### How Is the Direction Derived?
 
-- When station A sends a sked request to station B, it is assumed that A is pointing its antenna towards B.
-- If the resulting direction from A to your own station is within half the beamwidth of your own antenna, A is highlighted.
+Assume that station A sends a directed message to station B:
 
-**Example** (beamwidth 69°, half-angle 34.5°):
+1. KST4Contest calculates the direction from station A to station B.
+2. This direction is used as the likely antenna direction of station A.
+3. KST4Contest then calculates the direction from station A to the local station.
+4. The angular difference is compared with half of the configured antenna beamwidth.
+5. Station A must also be within the configured maximum QRB.
 
-| Situation | Result for DO5AMF in JN49 |
+A configured beamwidth of `70°` therefore produces an assumed corridor of `35°` on either side of the direction from station A to station B.
+
+![Geometry of the assumed antenna corridors](directional_opportunity_geometry.png)
+
+In the example, the green corridor runs from F5FEN towards DM5M. When F5FEN sends a directed message to DM5M, KST4Contest checks whether the local station lies inside this corridor. A reply from DM5M to F5FEN is calculated again in the opposite direction: the blue corridor then starts at DM5M and points towards F5FEN. Each message therefore evaluates the assumed antenna direction of its sender.
+
+| Example | Result |
 |---|---|
-| Sked from F5FEN → DM5M | ✅ Highlighted (F5FEN points towards DM5M, close to JN49) |
-| Sked from DM5M → F5FEN | ✅ Highlighted (DM5M replies towards F5FEN) |
-| F1DBN is uninvolved | ❌ No highlighting |
-| DO5AMF/P (different location) | ❌ No highlighting for sked reply |
+| Direction A → B: `120°`, direction A → local station: `145°` | Angular difference `25°`: directional opportunity detected |
+| Direction A → B: `120°`, direction A → local station: `165°` | Angular difference `45°`: outside the assumed corridor |
+| Locator of A or B is missing | Direction cannot be calculated |
+| A is outside the maximum QRB | No directional opportunity |
 
-The calculation does not include topographic path calculations – this is a deliberate simplification. It may be added in a future version.
+### What Is Shown in the User List?
 
-> Configuration: [Configuration – Antenna Beamwidth](en-Configuration#antenna-beamwidth)
+When a directional opportunity is detected, the sender's callsign appears in green and bold in the user list. Evening mode uses a lighter green. The receiver is not marked merely because it received the message; a reply in the opposite direction is evaluated as a separate message and therefore as a new case.
+
+![Detected directional opportunity in the user list](direction_opportunity_highlight.png)
+
+In the screenshot, DF0GEB sent a directed message to DN9APW and received a reply. KST4Contest detected the directional opportunity and highlighted DN9APW in the user list. The map is shown for context: the local station lies between the two stations and therefore receives the indication.
+
+The mark remains visible for five minutes after the most recent matching message. Another matching message from the same station restarts that period. If the station sends another directed message which no longer satisfies the direction conditions, the mark is removed immediately.
+
+If simple sound notifications are enabled, KST4Contest also plays a short indication when the directional opportunity is first detected. Further matching messages do not repeat the same sound while the station is already marked.
+
+### What Does the Mark Mean – and What Does It Not Mean?
+
+The calculation is a geometric derivation. It does not prove that station A is actually pointing its antenna towards station B. It also does not include terrain, current propagation, the real antenna pattern of the remote station or its rotator position.
+
+ON4KST does not provide the beamwidth of the remote station. KST4Contest therefore uses the value configured for the local antenna as an approximation for station A. A value which is too large produces more possible directional opportunities with less practical meaning. A value which is too small may hide useful situations.
+
+In plain terms: the green mark is a reasoned indication of a possible opportunity. It is neither a propagation forecast nor a guarantee of completing a QSO.
+
+Configuration:
+
+- [Antenna Beamwidth](en-Configuration#antenna-beamwidth)
+- [Default Maximum QRB](en-Configuration#default-maximum-qrb)
 
 ---
 
-## Sked Direction Spots (Built-in DX Cluster)
+## Forwarding as a DX Cluster Spot
 
-From **v1.23**: Direction warnings are forwarded as DX cluster spots to the logging software when a QRG is known. Details: [DX Cluster Server](en-DX-Cluster-Server).
+Since version 1.23, KST4Contest can forward a detected directional opportunity to the DX Cluster client of a logging programme. The local DX Cluster server must be enabled and a usable frequency must be known for the sender.
+
+The frequency may come from an earlier message or may be detected for the first time in the message which triggers the opportunity. In both cases it is available when KST4Contest checks whether it can create a spot. The programme therefore does not forward every QRG found in the chat. Automatic spots require a geometrically matching directed message.
+
+The five-minute user-list mark and the DX Cluster spot use the same direction calculation but have different lifetimes. The mark remains visible temporarily. The spot is generated immediately while the matching message is processed.
+
+Setup, frequency handling and limitations: [Built-in DX Cluster Server](en-DX-Cluster-Server).
 
 ---
 
-## QRG Detection (QRG Reading)
+## QRG Detection
 
-KST4Contest processes every line of text flowing through the channel and automatically extracts **frequency references**. These are displayed in the user list in the **QRG column**.
+Frequencies are rarely written in a consistent form in the ON4KST chat. A station may first mention `432.088`, later write only `.100`, and use `qrg 120` in another message. The context is usually obvious to a human reader. Software still has to distinguish whether `120` is a frequency, a time, a distance or something else entirely.
 
-Recognised formats: `144.205`, `432.088`, `.205` (with configured band assumption), etc.
+KST4Contest therefore evaluates the text of every public and directed chat message. A detected QRG is assigned to the sender and displayed in the user list's **QRG column**. The column shows the most recently detected frequency with at least three decimal places. A value stored internally as `144.21` is therefore displayed as `144.210`.
 
-**Benefit**: Without asking, you can directly look up a station's calling frequency and decide whether a contact is possible.
+### Which Formats Are Recognised?
+
+| Notation | Example | Processing |
+|---|---|---|
+| Complete frequency | `144.210`, `432,088`, `144307`, `10368100` | The frequency determines the band directly. |
+| Relative frequency with a dot or comma | `.210`, `,088` | The band is added from the station context or configured fallback. |
+| Three-digit frequency with text context | `qrg 210`, `freq is 210`, `on 210`, `210 MHz` | The number is treated as a relative frequency. |
+| Three-digit number without frequency context | `210`, `599`, `144` | The number is deliberately not accepted as a QRG. |
+
+The final restriction prevents plausible-looking but incorrect results. With a fallback of `144 MHz`, a signal report of `599` could easily be turned into `144.599 MHz`. The result would be formally valid and operationally useless.
+
+A complete frequency may also be written without a dot or comma. KST4Contest treats the final three digits as the kHz part: `144307` in a station name becomes `144.307 MHz`, while `10368100` in a public or directed chat message becomes `10368.100 MHz`. The value is accepted only if the resulting frequency falls within a supported band range.
+
+### How Is the Band of a Relative QRG Determined?
+
+KST4Contest uses the following order:
+
+1. If a suitable complete frequency has been detected for the same sender during the previous 30 minutes, KST4Contest uses its band.
+2. If several current bands are known, the most recently updated plausible band context is used.
+3. If no suitable station context exists, KST4Contest uses the band selected under **Fallback band for relative QRG detection**.
+
+Example: the global fallback is `144 MHz`. A station first mentions `432.088` and writes `.100` a few minutes later. KST4Contest does not add the global fallback. It uses the more recent station context, producing `432.100 MHz`. If another station without previous band information writes `.100`, the result is `144.100 MHz`.
+
+The fallback band really is the last resort. It is selected from the bands supported by KST4Contest and affects all QRG detection, not only the built-in DX Cluster server.
+
+### Where Is a Detected QRG Used?
+
+The most recently detected frequency appears in the user list. Its band context can also affect other functions, including:
+
+- detection of the station's active bands;
+- the chat-member score and priority lists;
+- band-upgrade hints after a log entry;
+- frequency selection for skeds; and
+- a DX Cluster spot generated from a directional opportunity.
+
+If the QRG first appears in the same message which triggers a directional opportunity, it is processed before the direction and spot checks. The resulting spot can therefore already use the frequency from that message.
+
+Detection remains a text-based process. KST4Contest cannot prove that the station is still using the stated frequency or that an ambiguous value belongs to a different context. This is precisely why bare three-digit numbers without frequency-related text are no longer accepted.
+
+Configuration and supported fallback bands: [Fallback Band for Relative QRG Detection](en-Configuration#fallback-band-for-relative-qrg-detection).
+
+Use in a logger bandmap: [Built-in DX Cluster Server](en-DX-Cluster-Server).
 
 ---
 
@@ -62,7 +139,7 @@ This distinction matters. A callsign already worked on one band may still be use
 
 [Log Synchronisation](en-Log-Sync) imports new QSOs from the logging application. The amount of information available depends on the interface being used:
 
-- The file-based Simplelogfile interpreter detects callsigns only. It can therefore set only the global Worked status.
+- The file-based Simplelogfile interpreter reads the selected text file once per minute using a fixed callsign pattern. Matches are normalised to the base callsign and set only the global Worked status for all active variants.
 - The QSO UDP interfaces and the Win-Test network listener can also provide the band.
 - If the log packet contains a valid locator, KST4Contest additionally stores the worked four-character grid square for that band.
 
@@ -131,7 +208,9 @@ In plain terms: an automatically detected hint means "probably active on this ba
 
 ### Storage and lifetime
 
-Worked, NOT-QRV and worked-grid information is stored in the internal SQLite database and restored on the next start. Entries expire automatically after three days, so a reset before every contest is normally unnecessary.
+Worked, NOT-QRV and worked-grid information received from network interfaces, together with manual marks, is stored in the internal SQLite database and restored on the next start. Entries expire automatically after three days, so a reset before every contest is normally unnecessary.
+
+Simplelogfile matches are excluded. They are not persisted in SQLite but are derived from the selected file during each application session. The file is therefore the durable source. The interpreter does not remove an existing Worked mark during the current session and does not reset the state automatically for a new contest. A manual database reset does not change or empty the file. Callsigns contained in it are marked as worked again when the file is next evaluated within one minute.
 
 A manual reset under **Workedstn database** removes all Worked marks, NOT-QRV marks and stored worked grid squares. The known callsign rows remain in the database. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for details.
 
@@ -161,19 +240,33 @@ The filters above the user list use the same information as the Worked columns:
 
 Several active filters are applied together. A station remains visible only if it satisfies every selected condition. The filters react immediately to new log entries and changed NOT-QRV marks.
 
-Operation and layout of the filter bar: [User Interface – Filters](en-User-Interface#filters).
+Operation and layout of the filter bar: [User Interface – Filters](en-User-Interface#filters-and-reachability-controls).
 
 ---
 
 ## Coloured PM Rows (from v1.25)
 
-New private messages appear in **red**. The colour fades every 30 seconds from yellow to white – like a rainbow fade. This makes it immediately clear how recent a message is.
+New incoming private messages use a series of green age highlights. The green becomes progressively more muted as the message gets older:
+
+| Message age | Display |
+|---|---|
+| up to and including 30 seconds | first green level |
+| 31 to 60 seconds | second green level |
+| 61 to 90 seconds | third green level |
+| 91 to 120 seconds | fourth green level |
+| 121 to 180 seconds | fifth green level |
+| 181 to 300 seconds | sixth green level |
+| from 301 seconds | normal table colour |
+
+The table refreshes the age display every five seconds, so a boundary may become visible only during the next refresh. No age class remains attached after five minutes; reused and empty table rows also return to their normal style.
+
+Messages sent by the local station retain their separate highlight and do not use the green age scale.
 
 *(Idea by IU3OAR, Gianluca Costantino – thank you!)*
 
 ---
 
-## PM Catching
+## PM Catching (from v1.1)
 
 Some users accidentally post direct messages publicly, e.g.:
 
@@ -181,7 +274,17 @@ Some users accidentally post direct messages publicly, e.g.:
 (DM5M) pse ur qrg
 ```
 
-KST4Contest detects such messages that contain your own callsign and automatically sorts them into the **private messages table**. No messages are missed this way.
+KST4Contest searches the text of every message not sent by the local station for the configured local login callsign without distinguishing upper- and lower-case letters. A match also appears in the **private messages table**. This applies to public messages addressed to `ALL` and to directed messages between other chat participants.
+
+A directed message between two other stations is where the slightly flippant description **“gossip detection”** fits best. It is a nickname, not the formal name of the function.
+
+The original message remains unchanged: its actual receiver remains `ALL` or the other chat participant; its text, chat category and routing are retained as well. PM Catching merely adds another view of the same message.
+
+The text search cannot infer intention. A typing error or shortened callsign is not recognised. Conversely, a simple mention of the complete callsign can produce a match even when no reply was expected.
+
+Selecting an incoming row in the PM table prepares a reply to its sender. For an outgoing message from the local station, the original receiver is restored as the target instead. Selecting the row does not send the message.
+
+Caught rows use the normal PM-table age display. They do not trigger the simple PM sound, CW callsign output or phonetic callsign output. The same applies to messages shown additionally through QSO Monitoring.
 
 ---
 
@@ -208,21 +311,21 @@ Configuration, recognised QRG requests and category handling: [Configuration –
 
 ## Multi-Channel Login (from v1.26)
 
-Simultaneous login to **two chat categories** (e.g. 144 MHz and 432 MHz). Both chats are monitored in parallel.
+KST4Contest signs in to ON4KST once with one local login callsign and password. One locator is shared by the entire TCP session. A second chat category (e.g. 144 MHz and 432 MHz) is added through Single Sign-on within the same session. Both categories are monitored in parallel, while the visible category-specific name field, message context, QRG and beacon remain separate for each category.
 
 ---
 
 ## Dark Mode (from v1.26)
 
-Toggle via: **Window → Use Dark Mode**
+Enable it through **Windows → Use dark mode design**. Use **Windows → Use default mode design** to return to the normal light colour scheme.
 
-For individual colour adjustments: edit the CSS file (path in the program settings).
+The green private-message age scale remains available in both designs. Text colour, normal table colour and the separate highlight for locally sent messages follow the selected built-in design.
 
 ---
 
 ## Opposite Station Multi-Callsign Login Tagging (from v1.26)
 
-Support for stations that are active in the chat with multiple callsigns simultaneously (e.g. expedition setups).
+Support for remote stations which are active in the chat under several complete visible callsign variants at the same time (e.g. expedition setups). The complete callsign and chat category remain separate participant identities, while Worked, band and priority data are shared through the base callsign.
 
 ---
 
@@ -234,7 +337,7 @@ For selected stations in the user list, there are direct buttons to open the **Q
 
 ## Skeds and Sked Reminders
 
-> Available from v1.40; band, callsign and Win-Test handling extended in Nightly / v1.42.
+> Available from v1.40; band, callsign and Win-Test handling extended in v1.42.
 
 A sked is more than a reminder tied to a particular time. During a contest, it must become visible early enough, move the agreed station up the priority list and – if required – remind the remote station as well.
 
@@ -338,7 +441,7 @@ Sniffed: (DN9APW-70 > 9A0BB-23) pse sked 19:30
 
 This distinction is intentional. Monitoring aggregates the variants so that their communication remains visible. Message routing does not aggregate them because the intended login would otherwise become ambiguous.
 
-The base callsign is evaluated across both connected chat categories. The category of each individual message remains unchanged.
+The base callsign is evaluated across both chat categories in the shared ON4KST session. The category of each individual message remains unchanged.
 
 The monitoring view includes:
 
@@ -503,7 +606,7 @@ The score is calculated for the normalised base callsign. A sked entered for an
 
 ### How are multiple suffixes and chat categories handled?
 
-Active callsigns such as `9A0BB-2`, `9A0BB-70`, `9A0BB-23` and `9A0BB-13` remain separate chat members. Messages can therefore still be addressed to the complete callsign in the correct chat category.
+Active complete visible callsign variants such as `9A0BB-2`, `9A0BB-70`, `9A0BB-23` and `9A0BB-13` remain separate chat members. Messages can therefore still be addressed to the complete callsign in the correct chat category.
 
 Worked, band, NOT-QRV and score information belongs to the common base callsign `9A0BB`. The score is calculated once and projected to all active variants. The user list may consequently contain several separate rows with the same score, while the priority list contains only one entry for the base station.
 
@@ -604,7 +707,7 @@ The timeline is a preview. AirScout data can change, and a stored sked guarantee
 
 KST4Contest can send recurring CQ messages to the public chat. The beacon is intended for longer periods of calling CQ on a fixed frequency: it publishes the local QRG regularly without requiring the operator to enter the same text again.
 
-Both chat categories use one shared interval, but each category has its own enable setting and message template. The second beacon is only sent while the second chat is enabled and connected.
+Both chat categories use one shared interval, but each category has its own enable setting and message template. The second beacon is only sent while the second category is enabled and fully synchronised in the shared ON4KST session.
 
 Global variables such as `MYQRG`, `SECONDQRG`, `MYLOCATOR` and `MYQTF` are resolved immediately before every transmission. A QRG updated by the logging software can therefore appear in the next beacon.
 
@@ -619,7 +722,7 @@ Configuration, timer behaviour and available variables: [Configuration – Beaco
 
 ## Simplelogfile
 
-File-based log evaluation using regex. Details: [Log Synchronisation](en-Log-Sync#method-1-universal-file-based-callsign-interpreter-simplelogfile).
+The Simplelogfile interpreter reads callsigns from a selected text file once per minute. If the file is missing, KST4Contest creates it and displays a non-blocking notice with its path and the initial setup and contest checks. Details: [Log Synchronisation](en-Log-Sync#method-1-universal-file-based-callsign-interpreter-simplelogfile).
 ---
 
 ## Global Message Views
@@ -717,12 +820,16 @@ Marker colours provide a compact status indication:
 |---|---|
 | Blue | Normal station marker |
 | Yellow | The callsign has already been worked on at least one band |
-| Green | The station is inside the current antenna sector and is relevant as a directional candidate |
+| Green | A directional opportunity has been derived for the station from directed chat messages |
 | Orange | Currently selected station |
 
 The selected state has the highest display priority, followed by the directional warning and Worked state. A selected station therefore remains orange even if it also meets one of the other conditions.
 
-At lower zoom levels, nearby markers are combined into screen-based clusters. This is a display function and does not merge the underlying chat members. Selected stations and important directional candidates remain individually visible where possible.
+The **Group nearby stations** checkbox controls spatial grouping. When selected, nearby markers are combined into screen-based clusters at lower zoom levels. The number inside a cluster shows how many stations it contains. Clicking a cluster zooms in but does not select an individual station. Selected stations and important directional candidates remain individually visible where possible.
+
+Clearing **Group nearby stations** displays every positionable station as an individual marker at every zoom level. The change takes effect immediately without reloading station data or changing the current zoom, viewport or selection. KST4Contest saves the setting automatically and restores it at the next start. Existing installations initially keep clustering enabled and therefore retain the previous behaviour.
+
+Screen-based clustering is separate from base-callsign aggregation. Active variants of the same normalised base callsign continue to share one geographical marker where applicable. Disabling **Group nearby stations** does not split that marker and does not change chat identities, filters or station data.
 
 Clicking a station marker selects the corresponding active chat member in the main window. KST4Contest scrolls to the entry in the user list, updates the **Further Info** panel and prepares the complete visible callsign as the message target. The chat suffix and category therefore remain relevant even though several variants may share one map marker.
 

github_docs/en-Home.md

@@ -52,6 +52,8 @@ Downloads, supported operating systems and installation methods are described in
 
 This manual describes the current stable release of KST4Contest.
 
+The currently published Stable version is **v1.42.0**.
+
 Functions that are only available in a Beta or Nightly build are marked accordingly. If no such note is present, the description applies to the stable release.
 
 - [Download Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
@@ -68,6 +70,7 @@ The stable release is normally the appropriate choice for contest operation. Bet
 |---|---|
 | [Installation](en-Installation) | ON4KST account, downloads, installation and updates |
 | [Configuration](en-Configuration) | Login, station, bands, user interface and external connections |
+| [Contest Workflow](en-Contest-Workflow) | Pre-start checks, CQ operation, candidate selection, skeds, logging and band changes |
 | [Log Synchronisation](en-Log-Sync) | Simplelogfile, UCXLog, N1MM+, QARTest, DXLog.net and Win-Test |
 | [AirScout Integration](en-AirScout-Integration) | Connecting AirScout and evaluating aircraft scatter timing |
 | [DX Cluster Server](en-DX-Cluster-Server) | Passing detected opportunities to logging software |

github_docs/en-Log-Sync.md

@@ -10,17 +10,19 @@ KST4Contest imports worked stations from the logging application and derives the
 
 ## Method 1: Universal File Based Callsign Interpreter (Simplelogfile)
 
-KST4Contest reads a log file and searches it for callsigns using a configurable regular expression. The file is read only and is never modified. Binary log files can also be used; content which cannot be interpreted as text is skipped.
+KST4Contest reads the selected text file once per minute and searches it for callsigns using a fixed built-in regular expression. Each match is normalised to its base callsign, so the global Worked status applies to every currently active chat variant of that callsign.
 
 The advantage is broad compatibility: no dedicated network interface is required from the logging application.
 
 The limitation is equally clear. A callsign match alone provides neither a reliable band nor a locator. The Simplelogfile interpreter can therefore set only the global Worked status. It does not create a per-band `X`, a worked-grid record or a reliable basis for the band-upgrade hint after a log entry.
 
-Configure the log-file path and regular expression in the **Log sync** tab. Use one of the network interfaces where possible if band-specific information is required.
+Select the text-file path in the **Log sync** tab. If the file is missing, KST4Contest creates it and displays a one-time, non-blocking notice with the path and the checks to perform next. Read or creation errors are logged; the scheduled task continues with its next one-minute pass. Use one of the network interfaces where possible if band-specific information is required.
+
+Worked status derived from the Simplelogfile is not stored in the internal SQLite database. The selected file is the durable source and is read again after every restart. The interpreter only adds positive Worked marks; it does not remove an existing mark during the current application session and does not reset automatically for a new contest. A manual database reset does not change or empty the Simplelogfile either. Callsigns contained in it are marked as worked again when the file is next evaluated within one minute. Before each contest, verify that the logging application is writing the current contest log to this exact file.
 
 ---
 
-# Method 2: Network Listener for QSO UDP Packets – Recommended
+## Method 2: Network Listener for QSO UDP Packets – Recommended
 
 UCXLog, QARTest, N1MM+ and DXLog.net can transmit a UDP packet when a QSO is saved. KST4Contest receives these packets on port `12060` by default and imports the callsign together with any band and locator information they contain.
 
@@ -100,6 +102,24 @@ Band IDs for 50 and 70 MHz are processed in the same way as the VHF, UHF and SHF
 
 The information is written to the same internal database as Worked data received through the other QSO UDP interfaces and is restored after a restart.
 
+#### Recovering QSOs logged earlier
+
+Win-Test broadcasts every new QSO. QSOs logged before KST4Contest was started are not part of those broadcasts. KST4Contest therefore requests them itself as soon as the Win-Test network listener detects a Win-Test station on the network.
+
+The recovery needs no dedicated setting and no operating step:
+
+- Win-Test announces with `IHAVE` which QSO numbers of which log it holds.
+- KST4Contest requests the missing ranges with `NEEDQSO`, at most 50 QSOs per request.
+- Win-Test answers with ordinary `ADDQSO` packets. They are processed exactly like a QSO logged live.
+
+Stations already worked therefore appear as worked even when KST4Contest is started during the contest. The recovery stays active afterwards and also picks up individual packets lost during operation. Known QSOs are recognised and not stored again.
+
+When several Win-Test stations are active on the network, every log is recovered. The per-band Worked marks of all band stations are then complete. The station name filter still applies to the QRG synchronisation only and does not restrict the log recovery.
+
+If a detected station sends no usable `IHAVE`, for example an older Win-Test version, KST4Contest requests the QSOs in blocks starting at QSO number 1 until a block remains unanswered.
+
+The Win-Test network must be enabled. No recovery takes place while the Win-Test network or the listener in KST4Contest is disabled.
+
 #### Handing skeds over to Win-Test
 
 Pressing **Create sked** first creates an internal KST4Contest sked. If the Win-Test network listener is enabled, KST4Contest then automatically attempts to send the sked to the Win-Test network as an `ADDSKED` packet.
@@ -152,7 +172,11 @@ In the **TRX sync** tab:
 - `Use pass frequency from Win-Test STATUS`
 - `Win-Test station name filter`
 
-The Win-Test network must be enabled in Win-Test. When several computers are used, the broadcast address must reach the relevant local network. The station name should identify the sending KST4Contest instance unambiguously within the Win-Test network.
+The Win-Test network must be enabled in Win-Test. The station name should identify the sending KST4Contest instance unambiguously within the Win-Test network.
+
+KST4Contest determines the broadcast address itself: the source address of the received Win-Test packets identifies the matching local network, and the broadcast address of that network is used. The configured address serves as the fallback when no local network matches the Win-Test station, for example when Win-Test is located behind a router.
+
+This matters because Win-Test only reacts to broadcasts, and an address in a network that does not exist raises no error: the packet is routed away silently. An outdated entry, for instance from a different network, therefore used to disable both the sked handover and the log recovery.
 
 Detailed settings: [Win-Test Network Listener](en-Configuration#win-test-network-listener-from-v131)
 
@@ -164,7 +188,7 @@ In addition to QSO synchronisation, UCXLog and other programs also transmit the
 
 ![Frequency Buttons](qrg_buttons.png)
 
-**Result**: Your own QRG never needs to be typed manually in the chat – clicking the MYQRG button or using the variable in the beacon is sufficient.
+**Result**: An enabled interface updates `MYQRG` when it actually supplies valid frequency packets. Enabling an interface does not create a QRG on its own. If no suitable packets arrive, check the interface or disable both automatic sources and maintain the QRG manually.
 
 **Sources for your own QRG (MYQRG):**
 - UCXLog, N1MM+, DXLog.net, QARTest via UDP port 12060
@@ -192,7 +216,7 @@ For DM5M-style setups (2 radios, 2 computers, one KST4Contest instance or two se
 
 ## Internal Database
 
-KST4Contest stores Worked, NOT-QRV and worked-grid information in its own SQLite database. This database is independent of the logging application's database.
+KST4Contest stores Worked, NOT-QRV and worked-grid information received from network interfaces, together with manual marks, in its own SQLite database. This database is independent of the logging application's database. Simplelogfile matches are excluded and are derived again from the selected file in each application session.
 
 The input sources provide different levels of detail:
 
@@ -202,6 +226,6 @@ The input sources provide different levels of detail:
 | QSO UDP listener | yes | yes, if included in the packet | yes, if both band and locator are available |
 | Win-Test network listener | yes | yes | yes, if a locator is available |
 
-The information is restored when KST4Contest starts and updated during operation when new log entries arrive. It expires automatically after three days, so a reset before every contest is normally unnecessary.
+The information stored in SQLite is restored when KST4Contest starts and updated during operation when new log entries arrive. It expires automatically after three days, so a reset before every contest is normally unnecessary. This lifetime does not apply to the Simplelogfile interpreter: its file remains the durable source and is neither changed nor emptied by a database reset. Callsigns contained in it set the global Worked status again during the next periodic evaluation.
 
 A complete manual reset removes Worked marks, NOT-QRV marks and worked grid squares together. See [Worked Station Database Settings](en-Configuration#worked-station-database-settings) for details.

github_docs/en-Macros-and-Variables.md

@@ -2,186 +2,371 @@
 
 > 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Makros-und-Variablen)
 
-KST4Contest offers a flexible system of text snippets, shortcuts and built-in variables that significantly speed up the chat workflow during contests.
+KST4Contest distinguishes between shortcut buttons, text snippets and variables. Shortcuts and snippets contain prepared text. Variables add information which may change during operation.
+
+Inserted text remains visible in the send field and can be checked or edited before transmission.
 
 ---
 
 ## Overview
 
-| Type | Access | Purpose |
+| Mechanism | Access | Use |
 |---|---|---|
-| **Shortcuts** | Button in the toolbar | Quick text insert into the send field |
-| **Snippets** | Right-click / Ctrl+1..0 | Text building blocks, optional PM sending |
-| **Variables** | Usable in all text fields | Dynamic values (QRG, locator, AP data) |
+| **Shortcut** | Button above the send field | Inserts configured text into the send field |
+| **Snippet** | Context menu or `Ctrl+1` through `Ctrl+0` | Prepares text for the selected station |
+| **Variable** | Placeholder within message text | Inserts current QRG, locator, direction, station or AirScout information |
+
+Shortcuts and snippets store text. Variables supply the corresponding current values.
+
+A shortcut such as
+
+```text
+pse sked?
+```
+
+always inserts the same text. A shortcut containing
+
+```text
+pse call me at MYQRGSHORT
+```
+
+instead uses the QRG stored in KST4Contest when the button is pressed.
 
 ---
 
-## Shortcuts (Quick-Access Buttons)
+## Shortcut Buttons
 
-Configurable in Preferences → **Shortcut Settings**.
+Shortcuts are configured under **Preferences → Shortcut Settings**.
 
-- Each configured text creates **one button** in the user interface.
-- Clicking a button inserts the text into the **send field**.
-- **All variables** can be used in shortcuts and are resolved immediately when inserted.
-- Longer texts are also possible.
+![Configuration of shortcut buttons and text snippets](client_settings_window_shortcuts.png)
 
-**Tip**: Set up frequently used abbreviations like "pse", "rrr", "tnx", "73" as shortcuts.
+Each entry creates one button in the main window. Pressing it appends the configured text to the existing contents of the send field. Text which has already been prepared is not removed.
+
+If a shortcut contains a variable, the variable is resolved when the text is inserted. For example,
+
+```text
+pse call me at MYQRGSHORT
+```
+
+may become:
+
+```text
+pse call me at 144.388
+```
+
+The exact entries `MYQRG` and `SECONDQRG` are highlighted as QRG buttons. They insert the current QRG of the first or second chat category respectively.
+
+The shortcut
+
+```text
+/SETNAME MYQRG
+```
+
+is highlighted as well. Pressing it resolves `MYQRG` and inserts the resulting server command into the send field. The command is not transmitted automatically.
+
+The order of the entries in the settings determines the button order in the main window. Editing, sorting and saving are described under [Configuration – Shortcut Settings](en-Configuration#shortcut-settings).
 
 ---
 
-## Snippets (Text Building Blocks)
+## Text Snippets
 
-Configurable in Preferences → **Snippet Settings**.
+Snippets are configured under **Preferences → Snippet Settings**. They are intended primarily for recurring messages to a particular station.
 
-### Access
+Snippets can be opened:
 
-- **Right-click** on a callsign in the user list
-- **Right-click** in the CQ message table
-- **Right-click** in the PM message table
-- **Keyboard shortcuts**: `Ctrl+1` to `Ctrl+0` for the first 10 snippets
+- by right-clicking a station in the user list,
+- by right-clicking a public message,
+- by right-clicking a private message, or
+- with `Ctrl+1` through `Ctrl+0` for the first ten entries in the snippet list.
 
-### Behaviour with a Selected Callsign
+### Using the Context Menu
 
-When a callsign is selected in the user list, the snippet is addressed as a **private message**:
+Selecting a station or message will normally have prepared the corresponding `/cq` destination in the send field. A snippet subsequently chosen from the context menu is appended to this text.
 
-```
-/CQ CALLSIGN <snippet text>
+Existing message text can therefore be extended deliberately.
+
+### Using the Keyboard
+
+A snippet invoked with `Ctrl+1` through `Ctrl+0` replaces the previous contents of the send field with a complete directed message:
+
+```text
+/cq CALLSIGN snippet text
 ```
 
-Then **Enter** can be pressed to send directly – even if the send field does not have focus.
+The complete visible callsign, including any suffix, is retained. Selecting `9A0BB-70` may therefore produce:
 
-### Hardware Macro Keyboard
+```text
+/cq 9A0BB-70 pse ur qrg?
+```
 
-*(Idea by IU3OAR, Gianluca Costantino)*
+KST4Contest also retains the selected station's chat category internally. A snippet for `9A0BB-70` is therefore not accidentally transmitted through the other active chat category.
 
-The key combinations `Ctrl+1` to `Ctrl+0` can be assigned to a programmable macro keyboard. One key press triggers the snippet, another press (mapped to Enter) sends it immediately. In contest operation this saves considerable time.
+If no station is selected, or no snippet exists for the selected key combination, nothing is inserted.
 
-### Predefined Default Snippets
+The prepared text is not sent automatically:
 
-On first start, some snippets are pre-configured, e.g.:
+- `Enter` or **TX** sends the message.
+- `Esc` clears the send field.
 
-- `Hi OM, try sked?`
-- `I am calling cq ur dir, pse lsn to me at MYQRG`
-- `pse ur qrg?`
-- `rrr, I move to your qrg nw, pse ant dir me`
+### Keyboard Mapping
 
-These can be customised or deleted in the Preferences.
+The mapping follows the order of the snippet list:
+
+| Key combination | Entry used |
+|---|---:|
+| `Ctrl+1` | first entry |
+| `Ctrl+2` | second entry |
+| … | … |
+| `Ctrl+9` | ninth entry |
+| `Ctrl+0` | tenth entry |
+
+The key combinations can also be assigned to a programmable macro keyboard. The idea for this method came from IU3OAR, Gianluca Costantino.
+
+KST4Contest does not define a mandatory set of default snippets. The useful texts depend on the station's own contest operation and operating method.
+
+Editing, sorting and saving are described under [Configuration – Snippet Settings](en-Configuration#snippet-settings).
 
 ---
 
 ## Variables
 
-Variables in written texts (snippets, shortcuts, beacon, send field) are replaced by their current values at runtime. Simply type the variable name in **uppercase** in the text.
+Variables are reserved placeholders within message text. They must be written in uppercase and are case-sensitive.
 
-### MYQRG
+Variables can be used in:
 
-Replaced by the current transceiver frequency.
+- shortcuts,
+- snippets,
+- beacon texts, and
+- message text entered or pasted directly into the send field.
 
-- Source: TRX sync via UDP from the logging software (if enabled)
-- Fallback: Manually entered value in the MYQRG text field to the right of the send button
-- Format: `144.388.03`
+Variables in a shortcut or snippet are resolved when the text is inserted into the send field. Variables entered or pasted directly into the send field are resolved immediately before the message is placed in the transmission queue.
 
-**Example**: `calling cq at MYQRG` → `calling cq at 144.388.03`
+Station-specific variables always use the currently selected station. KST4Contest does not derive this station from a `/cq` destination entered manually in the message text.
 
-### MYQRGSHORT
+---
 
-Like MYQRG, but only the first 7 characters.
+## Global Variables
 
-- Format: `144.388`
+Global variables do not require a selected remote station.
 
-**Example**: `qrg: MYQRGSHORT` → `qrg: 144.388`
+| Variable | Replacement value |
+|---|---|
+| `MYQRG` | current QRG of the first or primary chat category |
+| `MYQRGSHORT` | first seven characters of `MYQRG` |
+| `SECONDQRG` | current QRG of the second chat category |
+| `MYLOCATOR` | complete locator configured for the local station |
+| `MYLOCATORSHORT` | first four characters of the local locator |
+| `MYCALL` | configured local callsign |
+| `MYQTF` | current antenna direction as a numeric value in degrees |
 
-### MYLOCATOR
+For example,
 
-Replaced by your own Maidenhead locator (6 characters).
+```text
+cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
+```
 
-- Format: `JO51IJ`
+may be resolved to:
 
-**Example**: `my loc: MYLOCATOR` → `my loc: JO51IJ`
+```text
+cq at 144.388, qtf 135, loc JO51IJ
+```
 
-### MYLOCATORSHORT
+### QRG Variables
 
-Like MYLOCATOR, but only the first 4 characters.
+`MYQRG` contains the QRG of the first chat category. The value may come from TRX synchronisation with the logging software or from the manually edited QRG field.
 
-- Format: `JO51`
+`MYQRGSHORT` uses the same value, but limits it to the first seven characters:
 
-**Example**: `loc: MYLOCATORSHORT` → `loc: JO51`
+```text
+144.388.03 → 144.388
+```
+
+`SECONDQRG` contains the QRG of the second chat category. Selecting a station from the second chat does not change the meaning of `MYQRG`. Use `SECONDQRG` explicitly when the QRG of the second category is required.
+
+### Locator Variables
+
+`MYLOCATOR` inserts the complete configured locator of the local station:
+
+```text
+JO51IJ
+```
+
+`MYLOCATORSHORT` uses only the first four characters:
+
+```text
+JO51
+```
+
+### MYQTF
+
+`MYQTF` inserts the current antenna direction stored in KST4Contest as a numeric angle in degrees.
+
+For example,
+
+```text
+ant MYQTF deg
+```
+
+may become:
+
+```text
+ant 135 deg
+```
+
+The direction is not converted into compass terms such as `north`, `north-east` or `south-west`.
+
+---
+
+## Variables for the Selected Station
+
+These variables require a selected remote station:
+
+| Variable | Replacement value |
+|---|---|
+| `QRZNAME` | name of the selected station, or its complete callsign if no name is available |
+| `FIRSTAP` | description and arrival time of the first aircraft reported by AirScout |
+| `SECONDAP` | description and arrival time of the second aircraft reported by AirScout |
+
+For example,
+
+```text
+Hi QRZNAME, FIRSTAP, pse lsn at MYQRGSHORT
+```
+
+may become:
+
+```text
+Hi David, a very big AP in 2 min, pse lsn at 144.388
+```
 
 ### QRZNAME
 
-Replaced by the **name** of the currently selected station from the chat name field.
-
-**Example**: `Hi QRZNAME, sked?` → `Hi Gianluca, sked?`
+KST4Contest uses the name from the selected station's name field. If that field does not contain a usable name, the complete visible callsign is inserted instead.
 
 ### FIRSTAP
 
-Replaced by data of the first reflectable aircraft to the selected station (if available).
+If an AirScout candidate is available, `FIRSTAP` contains its description and the expected time until the reflection window.
 
-- Condition: AirScout is active and an aircraft is available.
-- Example format: `a very big AP in 1 min`
+For example:
 
-**Example**: `AP info: FIRSTAP` → `AP info: a very big AP in 1 min`
+```text
+a very big AP in 2 min
+```
+
+If no aircraft is available for the selected station, KST4Contest inserts:
+
+```text
+no ap available
+```
 
 ### SECONDAP
 
-Like FIRSTAP, but for the second available aircraft.
+`SECONDAP` uses the second available AirScout candidate.
 
-- Example format: `Next big AP in 9 min`
+For example:
 
-**Example**: `also: SECONDAP` → `also: Next big AP in 9 min`
+```text
+Next big AP in 9 min
+```
 
-### MYQTF *(planned for v1.3)*
+If there is no second candidate, `SECONDAP` is replaced with an empty string.
 
-Replaced by the current antenna direction in words (e.g. `north`, `north east`, `east`, …).
+Further information about the aircraft data is available under [AirScout Integration](en-AirScout-Integration#ap-variables-in-messages).
 
-- Source: Degree value in the MYQTF input field (to the right of the MYQRG field)
+### Behaviour Without a Selected Station
+
+If no station is selected, `QRZNAME`, `FIRSTAP` and `SECONDAP` remain visible in the text. KST4Contest does not remove these placeholders automatically.
+
+A visible unresolved placeholder is clearer than a formally complete message which silently lacks important information. Before transmission, check that the intended station is selected and that all required variables have been resolved.
 
 ---
 
 ## Variables in the Beacon
 
-A public beacon has no selected remote station. It can therefore make meaningful use only of variables which depend on the local station and its current configuration:
+A public beacon has no selected remote station. It can therefore use only global variables:
 
-| Variable | Value used in the beacon |
-|---|---|
-| `MYQRG` | current QRG of the primary chat category |
-| `MYQRGSHORT` | first seven characters of the primary QRG |
-| `SECONDQRG` | current QRG of the second chat category |
-| `MYLOCATOR` | complete configured locator of the local station |
-| `MYLOCATORSHORT` | four-character locator of the local station |
-| `MYCALL` | configured local callsign |
-| `MYQTF` | current antenna heading |
+- `MYQRG`
+- `MYQRGSHORT`
+- `SECONDQRG`
+- `MYLOCATOR`
+- `MYLOCATORSHORT`
+- `MYCALL`
+- `MYQTF`
 
-`QRZNAME`, `FIRSTAP` and `SECONDAP` require a selected remote station. They are therefore not resolved in a public beacon.
+`QRZNAME`, `FIRSTAP` and `SECONDAP` are not resolved in a beacon and should not be used there.
 
-A suitable configuration for the primary category is:
+A possible template for the first chat category is:
 
 ```text
 calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
 ```
 
-For the second category, use `SECONDQRG` if that category should publish a different frequency:
+If the second chat category uses a different QRG, its template must contain `SECONDQRG`:
 
 ```text
 calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
 ```
 
-Global variables are evaluated again on every timer run. A QRG updated by the logging software can therefore appear in the next beacon message.
+Global variables are evaluated again on every timer run. A QRG updated by the logging software can therefore already appear in the next beacon message.
 
-The completely resolved text must contain at least one valid character and must not exceed 120 characters. The protocol separator `|` and line breaks are not permitted. If the text is still empty or invalid when transmission is due, that beacon run is skipped.
+The fully resolved beacon text:
 
-The common interval and the behaviour of both chat categories are described under [Configuration – Beacon Settings](en-Configuration#beacon-settings).
+- must contain at least one valid character,
+- must not exceed 120 characters,
+- must not contain the protocol separator `|`, and
+- must not contain line breaks.
+
+If the text is empty or invalid when transmission is due, that beacon run is skipped.
+
+The interval, activation and behaviour of both categories are described under [Configuration – Beacon Settings](en-Configuration#beacon-settings).
 
 ---
 
+## Example Snippet Workflow
 
-## Example Contest Workflow with Macros
+For example, the first configured snippet may contain:
 
-1. Select a station in the user list → callsign is now pre-selected.
-2. Press `Ctrl+1` → Snippet "Hi OM, try sked?" is addressed as a PM.
-3. Press Enter → Message sent.
-4. Station replies with frequency → QRG column is automatically filled.
-5. Press `Ctrl+2` → Snippet "I am calling cq ur dir, pse lsn to me at 144.388" (MYQRG resolved).
-6. Press Enter → Sent.
+```text
+Hi QRZNAME, pse sked? I call at MYQRGSHORT
+```
 
-No manual typing, no errors, no interruption to CQ calling.
+The workflow can then look like this:
+
+1. Select `DL1ABC-432` in the user list.
+2. Press `Ctrl+1`.
+3. KST4Contest prepares the directed message and resolves its variables.
+4. Check the complete text in the send field.
+5. If the remote station has proposed another QRG, edit the text accordingly.
+6. Press `Enter` or **TX** to send the message.
+
+The result may be:
+
+```text
+/cq DL1ABC-432 Hi Peter, pse sked? I call at 432.088
+```
+
+The complete callsign determines the recipient. The selected chat category determines the transmission path. Variables reduce repeated typing, but they do not decide whether the inserted information still matches the current operating situation.
+
+---
+
+## Limits of Variable Resolution
+
+Variables reflect the information available to KST4Contest at the time they are resolved.
+
+In particular:
+
+- A QRG supplied by the logging software may have changed in the meantime.
+- A manually entered QRG remains active until it is changed again.
+- `MYQRG` remains the QRG of the primary category even if a station from the second category is selected.
+- The selected station may differ from a `/cq` destination entered manually.
+- AirScout may not provide current aircraft data for the path in question.
+- Station-specific variables remain visible when no station is selected.
+- Inserted text is not checked automatically for operational correctness.
+
+The send field therefore remains editable after a shortcut or snippet has been inserted. Variables avoid repeated input; the final check remains the operator's responsibility.
+
+---
+
+## Use During a Contest
+
+Shortcuts, snippets and variables are individual tools within the operating workflow. Their interaction with CQ operation, station selection, skeds, QRG changes and log synchronisation is described under [Contest Workflow with KST4Contest](en-Contest-Workflow).

github_docs/en-User-Interface.md

@@ -4,21 +4,69 @@
 
 ## Connecting to the Chat
 
-1. Select a **chat category** in the settings window (e.g. 144 MHz VHF, 432 MHz UHF, …).
-2. Click the **Connect** button.
-3. Wait for the connection to be established.
+Before connecting for the first time, configure the local login callsign and password, the locator shared by the TCP session, and the primary chat category in the settings window. If a second category is required, enable and select it there. KST4Contest signs in once and adds the second category through Single Sign-on within the same TCP session.
 
-> Disconnecting and reconnecting is only possible via the settings window. It is therefore recommended to keep the settings window open.
+The connection can be started in two ways:
+
+- **Connect to …** in the settings window applies the values currently entered there and starts the connection.
+- **File → Connect to …** uses the settings already applied in KST4Contest.
+
+Use **Save Settings** if changed values should also be available after the next programme start.
+
+An active connection can be terminated using **File → Disconnect** or **Disconnect** in the settings window. **Exit + disconnect** terminates the connection and then closes the programme.
+
+If an established connection is lost unexpectedly, KST4Contest waits for a limited period and then attempts a controlled reconnect to ON4KST. A failed initial connection attempt no longer blocks the user interface.
+
+The [`LINK` indicator](#status-bar-and-indicators) in the main window shows whether only the TCP connection exists or whether login and synchronisation have actually been completed.
 
 ---
 
+
 ## Main Window Overview
 
 The main window consists of several areas:
 
+### Status Bar and Indicators
+
+The status bar is located at the top of the main window next to the menu.
+
+![Status bar with ON4KST connection indicator](connection_status_indicator.png)
+
+The permanently visible `LINK` indicator shows the actual state of the ON4KST connection:
+
+| Indicator | Meaning |
+|---|---|
+| green `LINK` | Login and synchronisation of all configured chat categories have been completed |
+| yellow `LINK…` | Connection, login, user-list synchronisation or controlled shutdown is in progress |
+| red `LINK!` | No connection exists, or KST4Contest is waiting before an automatic reconnect |
+
+The tooltip contains the internal connection state and a more detailed description of the current step. The indicator is not a button.
+
+KST4Contest reports `ONLINE` only after login has been confirmed and the user lists of all configured categories have been received. The send field and **TX** remain disabled while the connection is still being established or resynchronised.
+
+Additional indicators appear temporarily after certain events:
+
+- `SKED` indicates that a sked reminder is due. The text contains the complete target callsign and the remaining time.
+- `BAND+` appears after a log entry if at least one common, locally enabled and unworked band has been detected for the worked station.
+
+Both indicators flash for approximately twelve seconds and then disappear. Their tooltip contains the complete message or derivation. Neither indicator is clickable.
+
+
 ### PM Window (top left)
 
-Shows all received **private messages** as well as intercepted public messages containing your own callsign. New messages appear in **red** and fade every 30 seconds from yellow to white.
+The PM window shows private messages addressed to the local login callsign and the corresponding outgoing replies.
+
+Messages not sent by the local station are also shown when their text contains the configured local login callsign, ignoring letter case. This applies to public messages addressed to `ALL` and to directed messages between other chat participants. The informal description **“gossip detection”** is particularly apt for the latter case.
+
+The actual receiver, message text, chat category and routing remain unchanged. The message merely gains an additional representation in the PM window.
+
+If [QSO Monitoring](en-Features#qso-sniffer-from-v131) is enabled, it additionally shows captured messages involving the monitored base callsigns. These entries receive a `Sniffed:` prefix containing the complete visible sender and receiver callsigns.
+
+New rows not sent by the local station pass through six green age levels and return to the normal table colour after five minutes. Messages sent by the local station retain their separate highlight. The colour only indicates message age; it does not change content or routing.
+
+Selecting an incoming row prepares a reply to the sender. For an outgoing message from the local station, the original receiver is restored as the message target instead. Caught and monitored rows do not trigger PM audio output.
+
+Age levels: [Coloured PM Rows](en-Features#coloured-pm-rows-from-v125). Recognition and limitations: [PM Catching](en-Features#pm-catching-from-v11).
 
 ### User List (Chat Members)
 
@@ -40,6 +88,11 @@ The central table of all currently active chat users. Columns (depending on conf
 | NOT QRV @ | Bands on which the station has manually been marked not QRV |
 | Category | Chat category of this entry |
 
+The QRG column shows the frequency most recently detected for a station. Missing trailing zeros are added for display purposes, so `144.21`, for example, is shown as `144.210`. If KST4Contest detects frequencies on several bands in succession, the column shows the latest match. The internal band information may still contain several current bands for that station.
+
+Relative frequency information is first combined with a band context from the same sender which is no more than 30 minutes old. Only if no such context exists does KST4Contest use the global fallback band. Detection rules, examples and limitations: [QRG Detection](en-Features#qrg-detection).
+
+
 ### Worked, band and grid-square status
 
 The subcolumns under **worked** use compact codes because several enabled bands leave little room for full descriptions. `X` marks a callsign worked on that band. `a` and `B+` identify an offered band which has not yet been worked. An appended `o` means that the four-character grid square has already been worked on this band.
@@ -52,39 +105,147 @@ Each status cell has a tooltip containing the legend and the state derived for t
 
 **Sorting**: Click column headers. QRB sorting is numerical (corrected in v1.22).
 
+A callsign displayed in green and bold indicates a directional opportunity derived from a directed message. The marker applies to the sender of that message and remains visible for no more than five minutes. Derivation and limitations: [Directional Opportunities from Directed Messages](en-Features#directional-opportunities-from-directed-messages).
+
+
 ### Send Field
 
-Text input for outgoing messages. After clicking a callsign in the user list, the send field automatically receives focus – start typing immediately without double-clicking (from v1.22).
+The send field contains the prepared text for the next outgoing message.
 
-### MYQRG Field
+When an operator deliberately selects a station in the user list using the mouse or keyboard, KST4Contest prepares a directed message:
 
-To the right of the send button. Shows the current own QRG, can also be entered manually.
+```text
+/cq CALLSIGN
+```
 
-### MYQTF Field *(for v1.3)*
+The complete visible callsign, including any suffix, and the chat category of the selected station are retained. A target such as `9A0BB-70` is not shortened to `9A0BB`.
 
-Input field for the current antenna direction. Used for the planned `MYQTF` variable.
+A background refresh, changed sorting order or filter update must not overwrite message text which has already been edited. Only an actual station selection by the operator prepares the `/cq` recipient again.
+
+- **TX** or `Enter` sends the prepared text.
+- `Esc` clears the send field.
+- The send field and **TX** remain disabled until KST4Contest is fully connected to ON4KST.
+
+Shortcuts, snippets and variables are described under [Macros and Variables](en-Macros-and-Variables).
+
+### MYQRG and SECONDQRG Fields
+
+The two QRG fields contain the local frequencies for the primary and secondary chat categories.
+
+`MYQRG` can be updated by an enabled TRX synchronisation interface or entered manually when no automatic QRG source is active. `SECONDQRG` remains independent and contains the frequency used for the second category.
+
+Selecting a station from the second chat does not change the meaning of these values: `MYQRG` continues to belong to the primary category and `SECONDQRG` to the secondary category.
+
+Further details: [TRX Sync Settings](en-Configuration#trx-sync-settings).
+
+### MYQTF Field
+
+The MYQTF field shows the current antenna direction as a numerical angle in degrees.
+
+If PSTRotator is enabled, the value is received automatically and the field cannot be edited manually. Without active rotator synchronisation, the antenna direction can be entered directly. The changed value is applied when the field loses focus.
+
+The value affects, among other things:
+
+- QTF filtering,
+- the antenna-sector display on the station map,
+- priority-score calculation,
+- the AP timeline, and
+- the `MYQTF` variable.
 
 ---
 
-## Filters
+## Table Widths and Truncated Cell Values
 
-The filter bar is located above the chat-member table and groups related controls:
+When useful data first becomes available, KST4Contest sizes the columns of the user list, message views, DXCluster and QSO tables, and Worked database once from their headings and existing contents. Stored widths take precedence. The initial widths of **Name**, **AP** and **NOT QRV @** are capped so that one long value cannot displace the rest of the table. **Message** and similar free-text columns remain flexible and do not follow the longest message.
 
-- **Show only QTF** limits the list to a selected antenna direction.
-- **Show only QRB [km] <=** sets a maximum distance.
-- **Find** searches for a callsign.
-- **wkd** hides callsigns which have already been worked on at least one band.
-- The individual band buttons hide a station if it has already been worked on that band or has been marked NOT QRV there. Only bands enabled for the local station are shown.
-- **Only new grids** shows only stations in four-character grid squares which have not been worked on any band.
-- **Grid color** is not a filter. It marks the QRA cell of an already worked grid square without hiding stations.
-- **New bands** shows stations with at least one detected, locally enabled and unworked band opportunity. NOT-QRV marks take precedence.
-- **Reachability**, **Tropo >=0dB** and **AS next 5m** limit the list according to the selected path or AirScout criteria.
+Manually changed column widths are saved automatically and restored at the next start. Later messages or station updates do not overwrite that choice.
 
-The filter bar has no fixed width. QTF, Worked and Reachability controls initially use the available space in their respective rows. When the horizontal divider is moved to the right and the chat-member area becomes narrower, controls wrap only when their actual required width no longer fits.
+If a normal text value does not fit in its cell, a tooltip shows the complete value. It appears only when the displayed text is actually truncated. Functional tooltips for QRA, Worked, band and similar states remain available. If such a cell is also truncated, the tooltip contains both the full value and the functional explanation.
+
+### Message Text and Links
+
+KST4Contest deliberately displays message text on a single line. This keeps a larger number of entries visible when chat activity is high. The disadvantage is obvious: if the **Message** column is narrow, not every message fits completely into its cell.
+
+If the message text is wider than the visible cell, moving the mouse over that **Message** cell displays the complete content in a tooltip. No additional full-text tooltip is shown if the message already fits into the column.
+
+Web addresses beginning with `http://`, `https://` or `www.` are displayed as links inside the message text. Clicking a link opens it in the operating system’s default browser. Other protocols are not treated as links.
+
+![Truncated message text with full-text tooltip and clickable link](message_tooltip_and_link.png)
+
+This avoids having to move the divider merely to read an individual long message. The divider can, of course, still be adjusted if a permanently wider message area is required.
+
+---
+
+## Filters and Reachability Controls
+
+The filter bar is located above the chat-member table. Filters can be combined; a station remains visible only if it satisfies every active condition.
 
 ![Wrapped filter bar in a narrow chat-member view](filter_bar_wrapped.png)
 
-In plain terms: the filters determine the table contents, but no longer enforce the minimum width of the entire right-hand side. The bar remains compact in the normal layout and uses additional height only when the view becomes genuinely narrow. Moving the divider back to the left immediately returns the controls to the available rows.
+### Station Filters
+
+| Control | Effect |
+|---|---|
+| **Show only QTF** | Shows only stations inside the selected antenna direction and configured beamwidth |
+| **Show only QRB [km] <=** | Limits the list to the entered maximum distance |
+| **Find** | Filters by a complete or partial callsign |
+| **wkd** | Hides base callsigns already worked on at least one supported band |
+| individual band buttons | Hide stations already worked on that band or marked NOT QRV there |
+| **Inactive stations** | Hides stations whose latest chat activity was more than 20 minutes ago |
+| **Only new grids** | Shows only stations in four-character grid squares not yet worked on any band |
+| **New bands** | Shows stations with at least one detected, locally enabled and unworked band opportunity |
+| **Tropo >=0dB** | Shows stations with a calculated non-negative SSB margin |
+| **AS next 5m** | Shows stations with a current AirScout window or one expected within the next five minutes |
+
+For **New bands**, KST4Contest evaluates current QRGs, band information in the name field and active callsign variants together. Manual NOT-QRV marks take precedence.
+
+The **Tropo >=0dB** filter removes only stations for which a completed calculation returned a negative margin. Stations with pending or failed calculations remain visible. Otherwise, a missing API result would incorrectly be treated as proof that the path is unsuitable.
+
+### Grid Color
+
+**Grid color** is not a filter. It only changes the presentation of the QRA cell and marks four-character grid squares which have already been worked.
+
+The station remains visible regardless of this colour marker. **Reset filters** therefore does not disable **Grid color**.
+
+### Reachability and Calc Selected
+
+The **Reachability** dropdown selects the band used by the Tropo column, the Tropo filter and an explicitly requested path calculation.
+
+- **Auto** derives the band from the station’s current QRG, band information in its name field and the supported chat category.
+- An explicitly selected band overrides this automatic choice for the Reachability calculation.
+
+Changing the dropdown does not start a calculation for the entire user list. With an online elevation-data source, that would be unnecessarily slow and multiply the number of external API requests.
+
+**Calc selected** calculates only the currently selected station, using either the explicitly selected or automatically derived band. The result is then used by the Tropo column and the associated views.
+
+### Resetting the Filters
+
+**Reset filters** clears:
+
+- the QTF filter,
+- the QRB filter,
+- the callsign search field,
+- all Worked and band filters,
+- **Inactive stations**,
+- **Only new grids**,
+- **New bands**,
+- **Tropo >=0dB**, and
+- **AS next 5m**.
+
+The internal filter predicates are explicitly cleared as well. Resetting only the visible toggle buttons would not be sufficient.
+
+The following settings are retained:
+
+- **Grid color**, because it is a display option, and
+- the **Reachability** selection, because it selects the calculation band rather than directly filtering the table.
+
+### Behaviour in a Narrow View
+
+The filter bar has no fixed width. QTF, Worked and Reachability controls initially use the available space in their respective rows.
+
+When the middle divider is moved to the right and the chat-member area becomes narrower, controls wrap only when their actual required width no longer fits. Widening the area causes them to rearrange immediately.
+
+In plain terms: the filters determine the table contents, but no longer enforce the minimum width of the entire right-hand side.
 
 ---
 
@@ -158,120 +319,195 @@ Calculation and limitations: [Priority Score and Priority List](en-Features#prio
 
 ## Station Map
 
-The station map is opened or closed through:
+The station map can be opened in two ways:
 
-**Windows → Show / hide station map**
+- **Windows → Show / hide station map** opens or closes the map window.
+- **Show on map** in the **Further Info** panel opens the map and focuses the selected station.
 
-The window uses the chat members currently visible in the filtered user list. Changing the QRB, QTF, Worked, band or Reachability filters can therefore also change the stations shown on the map.
+The map uses the stations which remain visible after applying the current user-list filters. Its header shows the number of displayed stations and indicates a filtered view with `filtered view active`.
 
-A station can additionally be opened directly from the **Further Info** panel using **Show on map**. This selects the station on the map and requests the associated path analysis.
+![Station map with a selected station and visible path analysis](station_map_path_analysis.png)
 
-Stations with the same normalised base callsign and position are combined into one marker. At lower zoom levels, nearby markers may additionally be displayed as clusters. These are display groups only; the individual chat logins remain separate message targets inside KST4Contest.
+### Selecting a Station
 
-Clicking a station marker:
+A single station marker can be selected directly. KST4Contest then:
 
 1. selects the corresponding chat member,
 2. scrolls the main user list to that entry,
 3. updates the **Further Info** panel, and
-4. prepares the complete visible callsign as the message target.
+4. prepares the complete visible callsign as the `/cq` recipient.
 
-The map details for the selected station include its locator, QRB, QTF, detected bands and available band opportunities. **Trigger cluster spot** sends a spot through the built-in local DX Cluster server so that connected logging software can receive the selected station and QRG.
+Chat logins with the same normalised base callsign and position may share one marker. They nevertheless remain separate message targets inside KST4Contest.
 
-The path-analysis section shows the terrain profile and the calculated route between both stations. Depending on the available data, it includes:
+When **Group nearby stations** is selected, markers which are too close together at lower zoom levels are displayed as a cluster containing the number of stations. Clicking the cluster zooms into that area. A concrete station is selected only after an individual marker becomes visible and is clicked. Clearing the checkbox displays every positionable station as an individual marker at every zoom level.
 
+The change takes effect immediately without changing the current zoom, viewport or station selection. It is saved automatically and restored at the next programme start. If no value has been stored yet, **Group nearby stations** remains selected so existing installations retain the previous behaviour.
+
+This switch controls only the spatial clusters on screen. Active chat variants of the same normalised base callsign may still share one geographical marker and remain separate message targets regardless of this setting.
+
+For a selected station, the header additionally shows:
+
+- the complete callsign,
+- locator,
+- QRB and QTF,
+- detected active bands,
+- any available `B+` band opportunity, and
+- the most recently known QRGs.
+
+Long header content is shortened. The complete text remains available in its tooltip.
+
+### Clearing the Selection with Reset View
+
+**Reset view** clears the selected station without changing the map position or zoom level.
+
+It:
+
+- clears the selected station,
+- clears the selection in the main user list,
+- removes the connection line to the remote station,
+- discards a pending analysis for the previous station, and
+- removes the right-hand analysis panel.
+
+The map itself remains at the previously selected position and zoom level. This function is therefore not a geographical reset to the local station.
+
+![Station map after Reset view without a selected station](station_map_reset.png)
+
+Selecting another individual marker restores the station selection and analysis panel.
+
+### Triggering a DX Cluster Spot
+
+**Trigger cluster spot** is visible only while a station is selected. It sends one spot to logging programmes connected to the built-in local DX Cluster server.
+
+This requires:
+
+- the local DX Cluster server to be enabled,
+- at least one connected cluster client, and
+- a usable QRG for the selected station.
+
+The spot is not sent to a public Internet cluster.
+
+### Path Analysis
+
+The terrain profile is displayed below the map. The right-hand analysis panel includes, among other things:
+
+- the data source and number of elevation samples,
 - the analysis frequency,
-- line-of-sight and horizon information,
+- the Earth-curvature or refraction model,
+- radio and terrain horizons,
 - Fresnel-zone clearance,
 - detected obstructions,
-- an estimated link budget,
-- received power and SSB margin, and
-- a short assessment of the path.
+- the link budget,
+- estimated received power, and
+- a summarised path assessment.
 
-Moving the mouse over the terrain profile highlights the corresponding geographical position on the map.
+The analysis uses the same centrally derived band as the Reachability functions. A band explicitly selected in the **Reachability** dropdown is taken into account.
 
-The analysis can be hidden using **Hide path analysis** when more space is required for the map. The compact state displays **Path analysis is hidden.** together with the **Show path analysis** button.
+These values remain technical estimates. Buildings, vegetation, local obstructions, current propagation conditions and unknown station parameters may substantially change the real result.
+
+### Hiding the Path Analysis
+
+**Hide path analysis** hides both the terrain profile and the right-hand analysis panel, leaving more space for the map.
 
 ![Station map with hidden path analysis](station_map_compact.png)
 
-The selected station and map contents remain available while the analysis panel is hidden. The setting is stored and restored at the next start.
+The **Path analysis is hidden** message and **Show path analysis** button remain visible, so the function can be restored directly.
 
-Calculation method and limitations: [Station Map and Path Analysis](en-Features#station-map-and-path-analysis-from-v141).
+If no station is selected when the analysis is shown again, no empty right-hand panel is displayed. It is recreated only after a specific station has been selected.
+
+The setting is stored and restored at the next programme start.
+
+The divider between the map and detail panel can be moved horizontally. Longer values wrap in a narrow detail panel; a vertical scrollbar appears if the available height is insufficient.
+
+Detailed derivation and limitations: [Station Map and Path Analysis](en-Features#station-map-and-path-analysis-from-v141).
 
 ---
 
 ## Global Message Tabs and Monitor Window
 
-Three global message tabs are located below the main user list. Unlike the **Further Info** panel, their contents do not depend on the station currently selected.
+The lower part of the main window contains three global message tabs. Their contents do not depend on the station currently selected in the user list.
 
-| Tab | Displayed messages |
+| Tab | Content |
 |---|---|
-| **Public messages** | All public chat messages, including CQ calls and beacons |
-| **DXCluster messages** | DX cluster messages received from the ON4KST server |
-| **QSO of the other** | Directed messages between chat logins other than the local station |
+| **Public messages** | Public chat messages, CQ calls and beacons |
+| **DXCluster messages** | DX cluster messages received through ON4KST |
+| **QSO of the other** | Directed messages between two other stations |
 
-The **Public messages** tab is selected by default.
+![Global message tabs in the main window](global_message_tabs.png)
 
-![Global message tabs below the main user list](global_message_tabs.png)
+In **QSO of the other**, sender and receiver are displayed separately. **Last QRG TX** and **Last QRG RX** contain the frequencies most recently known for the two stations. They do not necessarily represent the frequency discussed in the displayed conversation.
 
-The **DXCluster messages** table contains the time, reporting and reported stations, locators, QRG, message text and global Worked state where these values are available in the received message.
+**wkd TX?** and **wkd RX?** show the global Worked state of the two base callsigns. These values are not band-specific.
 
-The **QSO of the other** table contains:
+The **DXCluster messages** tab shows the reporting and reported stations, their locators, QRG, message text and the global Worked state of the reported station. Which fields are actually available depends on the message received from the ON4KST server.
 
-- the complete sender and receiver callsigns,
-- the latest QRG currently known for each station,
-- the global Worked state of each station,
-- the message text, and
-- the chat category.
+Message text remains on one line. If a cell is too narrow, its complete content is available in a tooltip. Web addresses in the message text are clickable.
 
-The displayed QRG is not necessarily the frequency on which the stations intend to make a contact. It is the latest QRG currently associated with the respective chat member. The Worked state is global and not specific to the displayed QRG or band.
+### Separate Monitor Window
 
-A directed chat message in this table does not prove that a radio QSO has taken place. The table also contains sked requests, frequency exchanges and other directed messages between third-party chat logins.
-
-### Separate monitor window
-
-The DX cluster and QSO-of-the-other tables can also be displayed together in a separate window.
+KST4Contest additionally opens the **Cluster & QSO of the other** window. It shows DX cluster messages in the upper table and directed messages between other stations in the lower table.
 
 ![Separate monitor window for DX cluster traffic and directed messages between other stations](cluster_qso_monitor.png)
 
-The separate window and the tabs use the same underlying messages. Hiding the window does not stop message processing or remove messages from the tabs.
+The vertical divider position and window size are saved automatically. The DXCluster and QSO tables use their own column widths in this window, so changing the monitor layout does not alter the corresponding main-window tabs.
 
-Use **Windows → Hide cluster / stranger QSOs** to hide the window and **Windows → Show cluster / stranger QSOs** to restore it.
+The window can be hidden and restored through:
 
-If a message is too long for its table cell, moving the mouse over the cell displays the complete text in a tooltip. Links beginning with `http://`, `https://` or `www.` can be opened in the system browser.
+```text
+Windows → Hide cluster / stranger QSOs
+Windows → Show cluster / stranger QSOs
+```
+
+The main-window tabs and separate monitor window use the same underlying data. Hiding the monitor window therefore neither stops message processing nor removes messages from the tabs.
+
+Derivation and limitations: [Global Message Views](en-Features#global-message-views).
 
 ---
 
 ## Menu
 
+### File
+
+- **Connect to …** starts the connection using the settings already applied in KST4Contest.
+- **Disconnect** terminates the current ON4KST connection without closing KST4Contest.
+- **Exit + disconnect** terminates the connection and then closes the programme.
+
+The Connect and Disconnect entries are enabled or disabled according to the current connection state.
+
+### Options
+
+- **Set QRG as name in Chat (main category)** sends `/SETNAME` containing the current `MYQRG` to the primary chat category.
+- **Show me as away in chat** sends `/AWAY`.
+- **Show me as active in chat** sends `/BACK`.
+- **Show options** shows or hides the settings window.
+
+Functions which communicate with the server are available only after the ON4KST connection has been established completely.
+
 ### Windows
 
-- **Hide cluster / stranger QSOs** hides the separate monitor window for DX cluster messages and directed messages between other stations.
-- **Show cluster / stranger QSOs** restores the monitor window.
-- **hide options** hides the settings window.
-- **show options** restores the settings window.
+- **Hide cluster / stranger QSOs** and **Show cluster / stranger QSOs** hide or restore the separate cluster and QSO monitor window.
+- **hide options** and **show options** hide or restore the settings window.
 - **Use dark mode design** activates the dark colour scheme.
-- **Use default mode design** restores the default colour scheme.
+- **Use default mode design** restores the standard light colour scheme.
 - **Show / hide station map** opens or closes the separate station-map and path-analysis window.
 
 ---
 
 ## Window Sizes and Dividers
 
-When **Save Settings** is clicked, KST4Contest stores the programme-window sizes and the positions of the relevant dividers in the configuration file. These values are reused at the next start.
+KST4Contest automatically stores programme-window sizes and positions, relevant dividers and manually changed table-column widths in the configuration file after a short delay. Any pending layout update is written when the programme exits. **Save Settings** is not required for these changes, but still stores the complete current state, including the layout.
 
 The main window is additionally checked against the visible area of the primary screen during startup. If the stored size is too large, KST4Contest reduces and moves the window so that it remains accessible. The complete process is described under [Screen-Aware Main Window Sizing](en-Features#screen-aware-main-window-sizing-from-v141).
 
-The other programme windows do not currently use this additional size restriction. If, for example, the separate monitor window appears too large after moving to a smaller screen, its size must be corrected manually and stored again using **Save Settings**.
+The other programme windows do not currently use this additional size restriction. If, for example, the separate monitor window appears too large after moving to a smaller screen, correcting it manually is sufficient; the new size is saved automatically.
 
-If the layout has become inconvenient, first move the dividers back to usable positions and save the settings again. Deleting the configuration file also resets the UI values, but it removes the other stored programme settings as well. It should therefore be used only when the interface cannot be restored in another way.
+If the layout has become inconvenient, first move the dividers and column widths back to usable positions. Deleting the configuration file also resets the UI values, but it removes the other stored programme settings as well. It should therefore be used only when the interface cannot be restored in another way.
 
 
 ---
 
 ## Operating Tips
 
-- **Keep the settings window open**: Quick access to enable/disable the beacon.
-- **Right-click in the user list**: Opens the snippet menu and other context actions.
-- **Mark a station NOT QRV**: Select the station and use the per-band controls in the **Further Info** panel.
-- **Enter from anywhere**: When text is in the send field, Enter sends directly – even if the focus is elsewhere.
-- **Stop the beacon**: Switch off the beacon while scanning frequencies to avoid flooding the chat with messages.
+- **Keep the settings window open**: This provides quick access to the beacon controls.
+- **Right-click in the user list**: Opens the snippet menu and additional actions, including QRZ.com profiles and NOT-QRV marks.
+- **Press Enter while working in the chat**: If the send field contains text, Enter sends it directly even when another control has focus.
+- **Stop the beacon while scanning**: Disable the beacon while moving through frequencies to avoid flooding the chat with unnecessary messages.

packaging/aur/kst4contest-bin/.SRCINFO

@@ -1,6 +1,6 @@
 pkgbase = kst4contest-bin
 	pkgdesc = ON4KST Chat Client for VHF/UHF contest operation (pre-built)
-	pkgver = 1.41.1
+	pkgver = 1.44.0
 	pkgrel = 1
 	url = https://github.com/praktimarc/kst4contest
 	arch = x86_64
@@ -10,7 +10,7 @@ pkgbase = kst4contest-bin
 	provides = kst4contest
 	conflicts = kst4contest
 	conflicts = kst4contest-git
-	source = KST4Contest-v1.41.1-archlinux-x86_64.pkg.tar.zst::https://github.com/praktimarc/kst4contest/releases/download/v1.41.1/KST4Contest-v1.41.1-archlinux-x86_64.pkg.tar.zst
-	sha256sums = 8e9a53ff832920c9ef2733635b90c5a4ffcd57a2958aaa251e92bd031142c614
+	source = KST4Contest-v1.44.0-archlinux-x86_64.pkg.tar.zst::https://github.com/praktimarc/kst4contest/releases/download/v1.44.0/KST4Contest-v1.44.0-archlinux-x86_64.pkg.tar.zst
+	sha256sums = 62688fabc25be32ebe71588eb90f0334cfb7ddde14ba1be6df9956ff4415ddf0
 
 pkgname = kst4contest-bin

packaging/aur/kst4contest-bin/PKGBUILD

@@ -1,6 +1,6 @@
 # Maintainer: Philipp Wagner <philipp@wagnersnetz.de>
 pkgname=kst4contest-bin
-pkgver=1.41.1
+pkgver=1.44.0
 pkgrel=1
 pkgdesc="ON4KST Chat Client for VHF/UHF contest operation (pre-built)"
 arch=('x86_64')
@@ -10,7 +10,7 @@ depends=('gst-plugins-base' 'gst-plugins-good')
 provides=('kst4contest')
 conflicts=('kst4contest' 'kst4contest-git')
 source=("KST4Contest-v${pkgver}-archlinux-${CARCH}.pkg.tar.zst::https://github.com/praktimarc/kst4contest/releases/download/v${pkgver}/KST4Contest-v${pkgver}-archlinux-${CARCH}.pkg.tar.zst")
-sha256sums=('8e9a53ff832920c9ef2733635b90c5a4ffcd57a2958aaa251e92bd031142c614')
+sha256sums=('62688fabc25be32ebe71588eb90f0334cfb7ddde14ba1be6df9956ff4415ddf0')
 
 package() {
     cp -a "${srcdir}/usr" "${pkgdir}/"

packaging/aur/kst4contest-git/.SRCINFO

@@ -1,6 +1,6 @@
 pkgbase = kst4contest-git
 	pkgdesc = ON4KST Chat Client for VHF/UHF contest operation (git)
-	pkgver = 1.42.0.r145.gd885924
+	pkgver = 1.44.0.r299.g08d65a0e
 	pkgrel = 1
 	url = https://github.com/praktimarc/kst4contest
 	arch = x86_64

packaging/aur/kst4contest-git/PKGBUILD

@@ -1,6 +1,6 @@
 # Maintainer: Philipp Wagner <philipp@wagnersnetz.de>
 pkgname=kst4contest-git
-pkgver=1.42.0.r145.gd885924
+pkgver=1.44.0.r299.g08d65a0e
 pkgrel=1
 pkgdesc="ON4KST Chat Client for VHF/UHF contest operation (git)"
 arch=('x86_64')

packaging/aur/kst4contest/.SRCINFO

@@ -1,7 +1,7 @@
 pkgbase = kst4contest
 	pkgdesc = ON4KST Chat Client for VHF/UHF contest operation
-	pkgver = 1.41.1
-	pkgrel = 2
+	pkgver = 1.44.0
+	pkgrel = 1
 	url = https://github.com/praktimarc/kst4contest
 	arch = x86_64
 	license = GPL-3.0-only
@@ -12,7 +12,7 @@ pkgbase = kst4contest
 	provides = kst4contest
 	conflicts = kst4contest-bin
 	conflicts = kst4contest-git
-	source = kst4contest-1.41.1.tar.gz::https://github.com/praktimarc/kst4contest/archive/refs/tags/v1.41.1.tar.gz
-	sha256sums = e96207a2d3fee19d35e34717f5312beb28bb087c040164e352337e749ce53b8d
+	source = kst4contest-1.44.0.tar.gz::https://github.com/praktimarc/kst4contest/archive/refs/tags/v1.44.0.tar.gz
+	sha256sums = e702df24a29e6f914a43934df0095bc4adbd00a9f02df3a632816c832272e914
 
 pkgname = kst4contest

packaging/aur/kst4contest/PKGBUILD

@@ -1,7 +1,7 @@
 # Maintainer: Philipp Wagner <philipp@wagnersnetz.de>
 pkgname=kst4contest
-pkgver=1.41.1
-pkgrel=2
+pkgver=1.44.0
+pkgrel=1
 pkgdesc="ON4KST Chat Client for VHF/UHF contest operation"
 arch=('x86_64')
 url="https://github.com/praktimarc/kst4contest"
@@ -11,7 +11,7 @@ makedepends=('java-environment=21' 'maven')
 provides=('kst4contest')
 conflicts=('kst4contest-bin' 'kst4contest-git')
 source=("${pkgname}-${pkgver}.tar.gz::https://github.com/praktimarc/kst4contest/archive/refs/tags/v${pkgver}.tar.gz")
-sha256sums=('e96207a2d3fee19d35e34717f5312beb28bb087c040164e352337e749ce53b8d')
+sha256sums=('e702df24a29e6f914a43934df0095bc4adbd00a9f02df3a632816c832272e914')
 
 build() {
     cd "${srcdir}/kst4contest-${pkgver}"

pom.xml

@@ -6,7 +6,7 @@
 
     <groupId>de.x08</groupId>
     <artifactId>praktiKST</artifactId>
-    <version>1.42.0-nightly</version>
+    <version>1.50.0-nightly</version>
 
     <name>praktiKST</name>
 

src/main/java/kst4contest/ApplicationConstants.java

@@ -20,14 +20,14 @@ public class ApplicationConstants {
     /**
      * Version shown to the user and used for semantic version comparison.
      */
-    public static final String APPLICATION_CURRENT_VERSION = "1.42";
+    public static final String APPLICATION_CURRENT_VERSION = "1.50.0";
 
     /**
      * Legacy numeric representation used only while older update feeds and
      * application versions still exist.
      */
     @Deprecated
-    public static final double APPLICATION_CURRENTVERSIONNUMBER = 1.42;
+    public static final double APPLICATION_CURRENTVERSIONNUMBER = 1.50;
 
     public static final String VERSIONINFOURLFORUPDATES_KST4CONTEST = "https://kst4contest.hamradioonline.de/kst4ContestVersionInfo.xml";
     public static final String VERSIONINFDOWNLOADEDLOCALFILE  = "kst4ContestVersionInfo.xml";

src/main/java/kst4contest/controller/ActiveOperatorProfile.java

@@ -0,0 +1,48 @@
+package kst4contest.controller;
+
+import kst4contest.model.OperatorProfileSelection;
+
+/**
+ * Holds the operator profile the current runtime works with.
+ *
+ * <p>The state is deliberately static, which is safe here for reasons that did not apply
+ * to the former static database connection: the value is immutable, it holds no live
+ * resource, and it is set on the JavaFX Application Thread before anything reads it -
+ * during startup, and again during a profile switch after the previous runtime has been
+ * shut down completely.</p>
+ */
+public final class ActiveOperatorProfile {
+
+    private static volatile OperatorProfileSelection currentSelection;
+
+    private ActiveOperatorProfile() {
+        // Utility class.
+    }
+
+    /**
+     * Returns the active profile selection.
+     *
+     * @return the active selection, or null when startup has not resolved one yet
+     */
+    public static OperatorProfileSelection get() {
+        return currentSelection;
+    }
+
+    /**
+     * Sets the active profile selection.
+     *
+     * @param selection selection to activate
+     */
+    public static void set(final OperatorProfileSelection selection) {
+        currentSelection = selection;
+    }
+
+    /**
+     * Returns whether a profile has already been resolved for this runtime.
+     *
+     * @return true if a selection is present
+     */
+    public static boolean isInitialized() {
+        return currentSelection != null;
+    }
+}

src/main/java/kst4contest/controller/ChatController.java

@@ -3,6 +3,7 @@ package kst4contest.controller;
 import java.net.*;
 import java.nio.ByteBuffer;
 import java.nio.channels.Selector;
+import java.nio.file.Path;
 import java.sql.SQLException;
 import java.time.OffsetDateTime;
 import java.time.ZoneOffset;
@@ -1082,9 +1083,35 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
 				rotatorClient.stop();
 				rotatorClient = null;
 			}
+
+			releaseBackgroundExecutors();
 		}
 	}
 
+	/**
+	 * Stops the background executors that live as long as this controller.
+	 *
+	 * <p>These are not bound to one ON4KST session, so disconnecting leaves them running
+	 * on purpose. When the controller itself is discarded they have to go, otherwise a
+	 * discarded controller stays reachable through its own threads.</p>
+	 */
+	private void releaseBackgroundExecutors() {
+
+		on4KstConnectionManager.shutdown();
+		skedReminderService.shutdown();
+
+		if (reachabilityService != null) {
+			reachabilityService.shutdown();
+		}
+
+		if (pendingRotatorRetry != null) {
+			pendingRotatorRetry.cancel(false);
+			pendingRotatorRetry = null;
+		}
+
+		rotatorCommandScheduler.shutdownNow();
+	}
+
 	private void cancelTimer(Timer timer) {
 		if (timer != null) {
 			timer.cancel();
@@ -1203,10 +1230,11 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
 					return;
 				}
 
-				InetAddress broadcastAddress = InetAddress.getByName(
-						chatPreferences
-								.getLogsynch_wintestNetworkBroadcastAddress()
-				);
+				InetAddress broadcastAddress =
+						winTestAddressResolver.resolveBroadcastAddress(
+								chatPreferences
+										.getLogsynch_wintestNetworkBroadcastAddress()
+						);
 
 				int port =
 						chatPreferences.getLogsynch_wintestNetworkPort();
@@ -1641,11 +1669,26 @@ public class ChatController implements ThreadStatusCallback, PstRotatorEventList
 //	private String hostname = "109.90.0.130";
     private String hostname;
 //	private String praktiKSTVersion = "praktiKST 1.0";
-	private String praktiKSTVersionInfo = "2022-10 - 2022-12\ndeveloped by DO5AMF, Marc\nContact: praktimarc@gmail.com\nDonations via paypal are welcome";
+	private String praktiKSTVersionInfo = "2022-10 - 2022-12\ndeveloped by DO5AMF, Marc and DN9APW, Philipp Wagner\nContact: praktimarc@gmail.com\nDonations via paypal are welcome";
 
 	private int port = 23001; // kst4contest.test 4 23001 //TODO: auslagern in Chatprefs
 	private ReadUDPbyUCXMessageThread readUDPbyUCXThread;
     private ReadUDPByWintestThread readUDPByWintestThread;
+
+	/**
+	 * Shared resolver for the Win-Test broadcast address. Win-Test only reacts
+	 * to broadcasts, so both the log synchronization and the SKED handover have
+	 * to reach the network the station was actually heard on.
+	 */
+	private final WinTestNetworkAddressResolver winTestAddressResolver =
+			new WinTestNetworkAddressResolver();
+
+	/**
+	 * @return resolver for outgoing Win-Test packets
+	 */
+	public WinTestNetworkAddressResolver getWinTestAddressResolver() {
+		return winTestAddressResolver;
+	}
 	private WriteThread writeThread;
 	private ReadThread readThread;
 	private InputReaderThread consoleReader;
@@ -1847,7 +1890,7 @@ private ObservableList<String>
 	 * assumption which one is the current run frequency. Therefore the legacy
 	 * frequency property is initialized only when exactly one explicit QRG exists.</p>
 	 */
-	private void initializeFrequencyFromStationNameIfUnambiguous(
+	/* package */ void initializeFrequencyFromStationNameIfUnambiguous(
 			ChatMember member
 	) {
 		if (member == null) {
@@ -1941,6 +1984,8 @@ private ObservableList<String>
 		int categoryNumber = category.getCategoryNumber();
 		List<ChatMember> safeMembers = completeMembers == null
 				? List.of() : new ArrayList<>(completeMembers);
+		Map<String, ChatMember> workedDataFromDatabase =
+				loadWorkedStateForInitialUserList(safeMembers);
 		for (ChatMember member : safeMembers) {
 			initializeFrequencyFromStationNameIfUnambiguous(member);
 		}
@@ -1965,10 +2010,48 @@ private ObservableList<String>
 					&& member.getChatCategory() != null
 					&& member.getChatCategory().getCategoryNumber() == categoryNumber);
 			lst_chatMemberList.addAll(safeMembers);
+			if (workedDataFromDatabase != null) {
+				getLst_DBBasedWkdCallSignList().setAll(
+						workedDataFromDatabase.values());
+			}
 			fireUserListUpdate("Complete ON4KST user list received");
 		});
 	}
 
+	/**
+	 * Loads one database snapshot for a completed initial ON4KST user list and
+	 * applies it before those members are published to the active model or UI.
+	 * Every callsign variant receives the state stored for its normalized base
+	 * callsign.
+	 *
+	 * @param initialMembers completed members of one chat category
+	 * @return loaded snapshot, or {@code null} when the database read failed
+	 */
+	/* package */ Map<String, ChatMember> loadWorkedStateForInitialUserList(
+			Collection<ChatMember> initialMembers
+	) {
+		if (dbHandler == null) {
+			LOGGER.warning(
+					"Cannot load Worked state for initial ON4KST user list: "
+							+ "database is not initialized");
+			return null;
+		}
+
+		try {
+			Map<String, ChatMember> workedDataFromDatabase =
+					dbHandler.fetchChatMemberWkdDataFromDB();
+			applyWorkedAndQrvStateFromDatabase(
+					initialMembers, workedDataFromDatabase);
+			return workedDataFromDatabase;
+		} catch (SQLException | RuntimeException exception) {
+			LOGGER.log(
+					Level.WARNING,
+					"Could not load Worked state for completed initial ON4KST user list",
+					exception);
+			return null;
+		}
+	}
+
 	/**
 	 * Resolves a member from the thread-safe active model. This avoids reading the
 	 * TableView backing list from MessageBusManagementThread.
@@ -2016,6 +2099,177 @@ private ObservableList<String>
 		return matchingMembers;
 	}
 
+	/**
+	 * Applies a QSO received from an external logger to all active callsign
+	 * variants. Active member objects back JavaFX views, so their state is changed
+	 * only on the JavaFX Application Thread. The band-upgrade hint is evaluated
+	 * afterwards and therefore sees the new Worked state.
+	 *
+	 * @param loggedQso validated external QSO
+	 */
+	public void applyExternalLoggedQso(ExternalLoggedQso loggedQso) {
+		if (loggedQso == null) {
+			return;
+		}
+
+		runOnFxThread(() -> {
+			int updatedMembers = markExternalLoggedQsoMembers(
+					activeChatMembersByCallAndCategory.values(), loggedQso);
+			if (updatedMembers == 0) {
+				return;
+			}
+
+			fireUserListUpdate("External logger Worked state updated");
+			try {
+				onExternalLogEntryReceived(loggedQso.getCallSign());
+			} catch (Exception exception) {
+				LOGGER.log(Level.WARNING,
+						"Band-upgrade hint failed after external logger update for "
+								+ loggedQso.getCallSign(), exception);
+			}
+		});
+	}
+
+	static int markExternalLoggedQsoMembers(
+			Collection<ChatMember> members,
+			ExternalLoggedQso loggedQso
+	) {
+		if (members == null || loggedQso == null) {
+			return 0;
+		}
+
+		String workedBaseCall = ChatMember.normalizeCallSignToBaseCallSign(
+				loggedQso.getCallSign());
+		if (workedBaseCall == null || workedBaseCall.isBlank()) {
+			return 0;
+		}
+
+		int updatedMembers = 0;
+		for (ChatMember member : members) {
+			if (member == null) {
+				continue;
+			}
+
+			String memberCall = member.getCallSignRaw() != null
+					? member.getCallSignRaw() : member.getCallSign();
+			String memberBaseCall = ChatMember.normalizeCallSignToBaseCallSign(memberCall);
+			if (memberBaseCall != null && memberBaseCall.equalsIgnoreCase(workedBaseCall)) {
+				loggedQso.applyToActiveMember(member);
+				updatedMembers++;
+			}
+		}
+		return updatedMembers;
+	}
+
+	/**
+	 * Applies the global Worked state from the Simplelogfile to every active
+	 * callsign variant with the same base callsign. UI-backed state is changed only
+	 * on the JavaFX Application Thread.
+	 *
+	 * @param workedBaseCalls normalized callsigns detected in the selected file
+	 */
+	public void applySimpleLogWorkedBaseCalls(Set<String> workedBaseCalls) {
+		Set<String> normalizedWorkedBaseCalls = normalizeWorkedBaseCalls(workedBaseCalls);
+		if (normalizedWorkedBaseCalls.isEmpty()) {
+			return;
+		}
+
+		runOnFxThread(() -> {
+			int changedMembers = markSimpleLogWorkedMembers(
+					activeChatMembersByCallAndCategory.values(), normalizedWorkedBaseCalls);
+			int changedClusterMessages = markSimpleLogWorkedClusterMessages(
+					lst_clusterMemberList, normalizedWorkedBaseCalls);
+
+			if (changedMembers > 0) {
+				fireUserListUpdate("Simplelogfile Worked status updated");
+			}
+
+			LOGGER.log(Level.FINE,
+					"Simplelogfile marked {0} active members and {1} cluster messages as worked.",
+					new Object[] { changedMembers, changedClusterMessages });
+		});
+	}
+
+	static int markSimpleLogWorkedMembers(
+			Collection<ChatMember> members,
+			Set<String> workedBaseCalls
+	) {
+		if (members == null || workedBaseCalls == null || workedBaseCalls.isEmpty()) {
+			return 0;
+		}
+
+		int changed = 0;
+		for (ChatMember member : members) {
+			if (member == null || member.isWorked()) {
+				continue;
+			}
+
+			String memberCall = member.getCallSignRaw() != null
+					? member.getCallSignRaw() : member.getCallSign();
+			String baseCall = ChatMember.normalizeCallSignToBaseCallSign(memberCall);
+			if (baseCall != null && workedBaseCalls.contains(baseCall.toUpperCase(Locale.ROOT))) {
+				member.setWorked(true);
+				changed++;
+			}
+		}
+		return changed;
+	}
+
+	static int markSimpleLogWorkedClusterMessages(
+			Collection<ClusterMessage> clusterMessages,
+			Set<String> workedBaseCalls
+	) {
+		if (clusterMessages == null || workedBaseCalls == null || workedBaseCalls.isEmpty()) {
+			return 0;
+		}
+
+		int changed = 0;
+		for (ClusterMessage clusterMessage : clusterMessages) {
+			if (clusterMessage == null || clusterMessage.isReceiverWkd()
+					|| clusterMessage.getReceiver() == null) {
+				continue;
+			}
+
+			ChatMember receiver = clusterMessage.getReceiver();
+			String receiverCall = receiver.getCallSignRaw() != null
+					? receiver.getCallSignRaw() : receiver.getCallSign();
+			String baseCall = ChatMember.normalizeCallSignToBaseCallSign(receiverCall);
+			if (baseCall != null && workedBaseCalls.contains(baseCall.toUpperCase(Locale.ROOT))) {
+				clusterMessage.setReceiverWkd(true);
+				changed++;
+			}
+		}
+		return changed;
+	}
+
+	private static Set<String> normalizeWorkedBaseCalls(Set<String> workedBaseCalls) {
+		if (workedBaseCalls == null || workedBaseCalls.isEmpty()) {
+			return Set.of();
+		}
+
+		Set<String> normalizedCalls = new HashSet<>();
+		for (String callSign : workedBaseCalls) {
+			String baseCall = ChatMember.normalizeCallSignToBaseCallSign(callSign);
+			if (baseCall != null && !baseCall.isBlank()) {
+				normalizedCalls.add(baseCall.toUpperCase(Locale.ROOT));
+			}
+		}
+		return Set.copyOf(normalizedCalls);
+	}
+
+	/**
+	 * Notifies the UI after a missing Simplelogfile was created successfully.
+	 *
+	 * @param filePath absolute path of the new file
+	 */
+	public void notifySimpleLogFileCreated(Path filePath) {
+		if (filePath == null || statusListener == null) {
+			return;
+		}
+
+		runOnFxThread(() -> statusListener.onSimpleLogFileCreated(filePath));
+	}
+
 	/**
 	 * Copies the band-specific NOT-QRV state to every active category variant of the
 	 * same base callsign. The database already uses callSignRaw as its key; applying
@@ -2638,9 +2892,35 @@ private ObservableList<String>
 	 * @param setOwnChatMemberObject
 	 */
 	public ChatController(ChatMember setOwnChatMemberObject,StatusUpdateListener listener) {
+		this(setOwnChatMemberObject,
+				listener,
+				ChatPreferences.PREFERENCES_FILE,
+				DBController.DATABASE_FILE,
+				true);
+	}
+
+	/**
+	 * Creates a chat controller bound to the files of one operator profile.
+	 *
+	 * <p>Both file names are resolved below the application directory. This is the only
+	 * place where the active operator profile enters the controller; everything below
+	 * works on the resulting {@link ChatPreferences} and {@link DBController} instances
+	 * without knowing about profiles at all.</p>
+	 *
+	 * @param setOwnChatMemberObject          chat member object representing the local station
+	 * @param listener                        callback for thread status updates
+	 * @param preferencesRelativeFileName     preferences file name relative to the application directory
+	 * @param workedDatabaseRelativeFileName  worked-station database file name relative to the application directory
+	 * @param seedWorkedDatabaseFromResource  true to seed a missing database from the bundled template
+	 */
+	public ChatController(ChatMember setOwnChatMemberObject,
+			StatusUpdateListener listener,
+			String preferencesRelativeFileName,
+			String workedDatabaseRelativeFileName,
+			boolean seedWorkedDatabaseFromResource) {
 		super();
 
-        chatPreferences = new ChatPreferences();
+        chatPreferences = new ChatPreferences(preferencesRelativeFileName);
         chatPreferences.readPreferencesFromXmlFile();
 //        this.statusListener = listener;
 		lstNotify_QSOSniffer_sniffedCallSignList =
@@ -2702,7 +2982,7 @@ private ObservableList<String>
 			}
 		});
 
-		dbHandler = new DBController();
+		dbHandler = new DBController(workedDatabaseRelativeFileName, seedWorkedDatabaseFromResource);
 		reachabilityService = new ReachabilityService(this);
 		rebuildWorkedGrossFieldCacheFromDatabase();
 
@@ -3682,15 +3962,6 @@ private ObservableList<String>
 
 		}
 
-		new Timer().schedule(new TimerTask() {
-
-			@Override
-			public void run() {
-				Thread.currentThread().setName("fetchWorkedFromDBTimer");
-				refreshWorkedStateAndDatabaseListFromDatabase();
-			}
-		}, 10000);
-
 //		new Timer().schedule(new TimerTask() {
 //			HashMap<String, ChatMember> getWorkedDataFromDb;
 //
@@ -3794,23 +4065,34 @@ private ObservableList<String>
 		HashMap<String, ChatMember> finalWorkedDataFromDatabase = workedDataFromDatabase;
 
 		Platform.runLater(() -> {
-			helper_applyWorkedAndQrvStateFromDatabase(finalWorkedDataFromDatabase);
+			applyWorkedAndQrvStateFromDatabase(
+					activeChatMembersByCallAndCategory.values(),
+					finalWorkedDataFromDatabase);
 			getLst_DBBasedWkdCallSignList().setAll(finalWorkedDataFromDatabase.values());
 			fireUserListUpdate("Worked database state refreshed");
 		});
 	}
 
 	/**
-	 * Applies the worked and not-QRV state from the database snapshot to all active
-	 * chatmember objects that are currently visible in the live chat list.
+	 * Applies the worked and not-QRV state from a database snapshot to chat members.
+	 * Database rows are keyed by normalized base callsign, so all active category
+	 * and suffix variants receive the same persisted state.
 	 *
+	 * @param chatMembers members that should receive persisted state
 	 * @param workedDataFromDatabase map keyed by normalized raw callsign
 	 */
-	private void helper_applyWorkedAndQrvStateFromDatabase(HashMap<String, ChatMember> workedDataFromDatabase) {
+	/* package */ static void applyWorkedAndQrvStateFromDatabase(
+			Collection<ChatMember> chatMembers,
+			Map<String, ChatMember> workedDataFromDatabase
+	) {
+		if (chatMembers == null || workedDataFromDatabase == null) {
+			return;
+		}
 
-		for (Iterator iterator = getLst_chatMemberList().iterator(); iterator.hasNext();) {
-
-			ChatMember activeChatMember = (ChatMember) iterator.next();
+		for (ChatMember activeChatMember : chatMembers) {
+			if (activeChatMember == null) {
+				continue;
+			}
 			ChatMember storedChatMemberState = workedDataFromDatabase.get(activeChatMember.getCallSignRaw());
 
 			if (storedChatMemberState == null) {

src/main/java/kst4contest/controller/DBController.java

@@ -6,9 +6,13 @@ import java.sql.PreparedStatement;
 import java.sql.ResultSet;
 import java.sql.SQLException;
 import java.sql.Statement;
+import java.io.IOException;
+import java.nio.file.Files;
+import java.nio.file.Path;
 import java.util.HashMap;
 import java.util.LinkedHashMap;
 import java.util.Map;
+import java.util.Objects;
 
 import kst4contest.ApplicationConstants;
 import kst4contest.model.ChatMember;
@@ -52,34 +56,128 @@ public class DBController {
 	 */
 	private static final long EXPIRATION_CLEANUP_MIN_INTERVAL_IN_MILLISECONDS = 60L * 1000L;
 
-	private static final DBController dbcontroller = new DBController();
-	private static Connection connection;
-	private static String DB_PATH = ApplicationFileUtils.getFilePath(ApplicationConstants.APPLICATION_NAME, DATABASE_FILE);
+	/**
+	 * Lazily created controller for the root installation database. It is created on
+	 * first use only, because an eagerly created instance would open a database file
+	 * before the application knows which operator profile is active.
+	 */
+	private static volatile DBController defaultInstance;
+
+	private Connection connection;
+
+	/**
+	 * File name of this database relative to the application directory, for example
+	 * "praktiKST.db" or "profiles/OP2/praktiKST.db".
+	 */
+	private final String databaseRelativeFileName;
+
+	/**
+	 * Absolute path of the database file, resolved once during construction.
+	 */
+	private final String databaseFilePath;
+
+	/**
+	 * True if a missing database file should be seeded from the shipped template.
+	 */
+	private final boolean seedFromResource;
+
+	/**
+	 * Shutdown hook of this instance. It is remembered so it can be deregistered when
+	 * the connection is closed. Without that, every operator profile switch would leave
+	 * another hook behind that keeps a dead connection alive until the process ends.
+	 */
+	private Thread databaseShutdownHook;
 
 	/**
 	 * Remembers the last timestamp at which the expiration cleanup had been executed.
 	 */
 	private long lastExpirationCleanupExecutionEpochMs = 0L;
 
+	/**
+	 * Creates a controller for the worked-station database of the root installation.
+	 */
 	public DBController() {
-		initDBConnection();
-	}
-
-	public static DBController getInstance() {
-		return dbcontroller;
+		this(DATABASE_FILE, true);
 	}
 
 	/**
-	 * Closes the database connection if it is still open.
+	 * Creates a controller for the worked-station database of one operator profile.
+	 *
+	 * @param databaseRelativeFileName file name relative to the application directory
+	 * @param seedFromResource         true to copy the shipped template database when the file
+	 *                                 does not exist yet, false to create an empty database and
+	 *                                 let the schema creation build all required tables
+	 */
+	public DBController(final String databaseRelativeFileName, final boolean seedFromResource) {
+		this.databaseRelativeFileName =
+				Objects.requireNonNull(databaseRelativeFileName, "databaseRelativeFileName");
+		this.seedFromResource = seedFromResource;
+		this.databaseFilePath = ApplicationFileUtils.getFilePath(
+				ApplicationConstants.APPLICATION_NAME,
+				databaseRelativeFileName
+		);
+
+		initDBConnection();
+	}
+
+	/**
+	 * Returns a controller for the root installation database, creating it on first use.
+	 *
+	 * @return the shared controller for the root installation database
+	 */
+	public static synchronized DBController getInstance() {
+
+		if (defaultInstance == null) {
+			defaultInstance = new DBController();
+		}
+
+		return defaultInstance;
+	}
+
+	/**
+	 * Returns the absolute path of the database file this controller works on.
+	 *
+	 * @return absolute database file path
+	 */
+	public String getDatabaseFilePath() {
+		return databaseFilePath;
+	}
+
+	/**
+	 * Closes the database connection if it is still open and deregisters the shutdown
+	 * hook of this instance.
 	 */
 	public synchronized void closeDBConnection() {
+
+		closeConnectionQuietly();
+
+		if (databaseShutdownHook != null) {
+			try {
+				Runtime.getRuntime().removeShutdownHook(databaseShutdownHook);
+			} catch (IllegalStateException shutdownAlreadyInProgress) {
+				// Expected while the JVM is shutting down; the hook is running anyway.
+			}
+
+			databaseShutdownHook = null;
+		}
+	}
+
+	/**
+	 * Closes the connection without touching the shutdown hook. This is also the body of
+	 * the shutdown hook itself.
+	 */
+	private synchronized void closeConnectionQuietly() {
+
 		try {
 			if (connection != null && !connection.isClosed()) {
 				connection.close();
+				System.out.println("Connection to Database closed: " + databaseFilePath);
 			}
 		} catch (SQLException e) {
 			e.printStackTrace();
 		}
+
+		connection = null;
 	}
 
 	/**
@@ -91,22 +189,17 @@ public class DBController {
 		System.out.println("DBH: initiate new db connection");
 
 		try {
-			ApplicationFileUtils.copyResourceIfRequired(
-					ApplicationConstants.APPLICATION_NAME,
-					DATABASE_RESOURCE,
-					DATABASE_FILE
-			);
-
 			if (connection != null && !connection.isClosed()) {
 				return;
 			}
 
+			prepareDatabaseFile();
+
 			System.out.println("Creating Connection to Database...");
 
-			DB_PATH = ApplicationFileUtils.getFilePath(ApplicationConstants.APPLICATION_NAME, DATABASE_FILE);
-			connection = DriverManager.getConnection("jdbc:sqlite:" + DB_PATH);
+			connection = DriverManager.getConnection("jdbc:sqlite:" + databaseFilePath);
 
-			System.out.println("[DBH, Info]: Path = " + DB_PATH);
+			System.out.println("[DBH, Info]: Path = " + databaseFilePath);
 
 			if (!connection.isClosed()) {
 				System.out.println("...Connection established");
@@ -115,25 +208,50 @@ public class DBController {
 			throw new RuntimeException(e);
 		}
 
-		Runtime.getRuntime().addShutdownHook(new Thread() {
-			public void run() {
-				try {
-					if (connection != null && !connection.isClosed()) {
-						connection.close();
-
-						if (connection.isClosed()) {
-							System.out.println("Connection to Database closed");
-						}
-					}
-				} catch (SQLException e) {
-					e.printStackTrace();
-				}
-			}
-		});
+		databaseShutdownHook = new Thread(this::closeConnectionQuietly,
+				"DBController-shutdown-" + databaseRelativeFileName);
+		Runtime.getRuntime().addShutdownHook(databaseShutdownHook);
 
 		ensureChatMemberTableCompatibility();
 	}
 
+	/**
+	 * Makes sure the database file can be opened.
+	 *
+	 * <p>The database of the root installation is seeded from the shipped template so
+	 * existing installations keep their historic content. A database that belongs to an
+	 * additional operator profile is created empty on purpose: the shipped template
+	 * carries several thousand foreign callsigns and an outdated schema version, which
+	 * would present a new operator with foreign data and trigger the full callsign
+	 * normalization rebuild. The required tables are created by
+	 * {@link #ensureChatMemberTableCompatibility()} in both cases.</p>
+	 */
+	private synchronized void prepareDatabaseFile() {
+
+		if (seedFromResource) {
+			ApplicationFileUtils.copyResourceIfRequired(
+					ApplicationConstants.APPLICATION_NAME,
+					DATABASE_RESOURCE,
+					databaseRelativeFileName
+			);
+
+			return;
+		}
+
+		Path parentDirectory = Path.of(databaseFilePath).getParent();
+
+		if (parentDirectory == null) {
+			return;
+		}
+
+		try {
+			Files.createDirectories(parentDirectory);
+		} catch (IOException e) {
+			throw new RuntimeException(
+					"[DBH, ERROR:] Could not create database directory " + parentDirectory, e);
+		}
+	}
+
 	/**
 	 * Ensures that the ChatMember table exists, that all required columns are
 	 * available for newer software versions, that existing old callsign keys are

src/main/java/kst4contest/controller/DXClusterSpotFormatter.java

@@ -0,0 +1,165 @@
+package kst4contest.controller;
+
+import java.nio.charset.StandardCharsets;
+import java.util.Locale;
+
+/**
+ * Formats local DX Cluster spots using the fixed-column layout emitted by
+ * DXSpider and accepted by common logging programs.
+ */
+final class DXClusterSpotFormatter {
+
+    /** Length of the DX Cluster line before BEL and CRLF framing. */
+    /* package */
+    static final int LINE_LENGTH = 75;
+    /** One-based column in which the spotted callsign starts. */
+    /* package */
+    static final int DX_CALL_COLUMN = 27;
+    /** Width of the fixed comment field. */
+    /* package */
+    static final int COMMENT_LENGTH = 30;
+    /** One-based column in which the UTC time starts. */
+    /* package */
+    static final int TIME_COLUMN = 71;
+
+    /** Zero-based exclusive end position of the frequency field. */
+    private static final int FREQUENCY_END = 24;
+    /** Maximum width of the spotted callsign field. */
+    private static final int DX_CALL_LENGTH = 12;
+    /** Required width of the HHMMZ time field. */
+    private static final int TIME_LENGTH = 5;
+    /** Minimum separator width between spotter and frequency. */
+    private static final int MIN_FREQUENCY_GAP = 1;
+    /** Wire framing appended to every formatted line. */
+    private static final String PAYLOAD_SUFFIX = "\u0007\u0007\r\n";
+
+    private DXClusterSpotFormatter() {
+    }
+
+    /** Builds the fixed 75-character payload line without wire framing. */
+    /* package */
+    static String formatLine(
+            final String spotterCallSign,
+            final String frequency,
+            final String dxCallSign,
+            final String comment,
+            final String time
+    ) {
+        final String spotter = requireValue(
+                spotterCallSign,
+                "spotter callsign"
+        )
+                .toUpperCase(Locale.ROOT);
+        final String frequencyValue = requireValue(frequency, "frequency");
+        final String dxCall = requireValue(dxCallSign, "DX callsign")
+                .toUpperCase(Locale.ROOT);
+        final String timeValue = requireValue(time, "time");
+
+        validateDxCall(dxCall);
+        validateTime(timeValue);
+
+        final String prefix = "DX de " + spotter + ":";
+        final int frequencyPadding = calculateFrequencyPadding(
+                prefix,
+                frequencyValue
+        );
+        final String normalizedComment = normalizeComment(comment);
+
+        final String line = prefix
+                + " ".repeat(frequencyPadding)
+                + frequencyValue
+                + "  "
+                + padRight(dxCall, DX_CALL_LENGTH)
+                + " "
+                + padRight(normalizedComment, COMMENT_LENGTH)
+                + " "
+                + timeValue;
+
+        if (line.length() != LINE_LENGTH) {
+            throw new IllegalStateException(
+                    "DX Cluster formatter produced "
+                            + line.length()
+                            + " characters instead of "
+                            + LINE_LENGTH
+            );
+        }
+
+        return line;
+    }
+
+    /** Builds one complete ASCII spot payload including BEL and CRLF framing. */
+    /* package */
+    static byte[] formatPayload(
+            final String spotterCallSign,
+            final String frequency,
+            final String dxCallSign,
+            final String comment,
+            final String time
+    ) {
+        return (formatLine(
+                spotterCallSign,
+                frequency,
+                dxCallSign,
+                comment,
+                time
+        ) + PAYLOAD_SUFFIX).getBytes(StandardCharsets.US_ASCII);
+    }
+
+    private static void validateDxCall(final String dxCall) {
+        if (dxCall.length() > DX_CALL_LENGTH) {
+            throw new IllegalArgumentException(
+                    "DX callsign exceeds 12 characters: " + dxCall
+            );
+        }
+    }
+
+    private static void validateTime(final String time) {
+        if (time.length() != TIME_LENGTH) {
+            throw new IllegalArgumentException(
+                    "DX Cluster time must contain exactly five characters"
+            );
+        }
+    }
+
+    private static int calculateFrequencyPadding(
+            final String prefix,
+            final String frequency
+    ) {
+        final int padding = FREQUENCY_END
+                - prefix.length()
+                - frequency.length();
+
+        if (padding < MIN_FREQUENCY_GAP) {
+            throw new IllegalArgumentException(
+                    "Spotter callsign and frequency do not fit the DX Cluster prefix"
+            );
+        }
+
+        return padding;
+    }
+
+    private static String normalizeComment(final String comment) {
+        final String normalized = comment == null ? "" : comment.trim();
+
+        return normalized.length() > COMMENT_LENGTH
+                ? normalized.substring(0, COMMENT_LENGTH)
+                : normalized;
+    }
+
+    private static String requireValue(
+            final String value,
+            final String fieldName
+    ) {
+        if (value == null || value.isBlank()) {
+            throw new IllegalArgumentException(
+                    "DX Cluster " + fieldName + " is missing"
+            );
+        }
+
+        return value.trim();
+    }
+
+    private static String padRight(final String value, final int length) {
+        return value + " ".repeat(length - value.length());
+    }
+}

src/main/java/kst4contest/controller/DXClusterThreadPooledServer.java

@@ -152,6 +152,7 @@ public class DXClusterThreadPooledServer implements Runnable {
     public boolean broadcastSingleDXClusterEntryToLoggers(
             ChatMember chatMember
     ) {
+        final byte[] clusterPayload;
         final String clusterMessage;
 
         try {
@@ -162,24 +163,27 @@ public class DXClusterThreadPooledServer implements Runnable {
                             .getNotify_optionalFrequencyPrefix()
             );
 
-            clusterMessage =
-                    "DX de "
-                            + chatController
+            clusterPayload = DXClusterSpotFormatter.formatPayload(
+                    chatController
                             .getChatPreferences()
                             .getNotify_DXCSrv_SpottersCallSign()
-                            .getValue()
-                            + ":   "
-                            + frequency
-                            + "  "
-                            + chatMember.getCallSign().toUpperCase()
-                            + "             "
-                            + chatMember.getQra().toUpperCase()
-                            + "  "
-                            + new Utils4KST()
+                            .getValue(),
+                    frequency,
+                    chatMember.getCallSign(),
+                    chatMember.getQra(),
+                    new Utils4KST()
                             .time_generateCurrenthhmmZTimeStringForClusterMessage()
-                            + ((char) 7)
-                            + ((char) 7)
-                            + "\r\n";
+            );
+            clusterMessage = new String(
+                    clusterPayload,
+                    StandardCharsets.US_ASCII
+            );
+        } catch (IllegalArgumentException exception) {
+            LOGGER.log(
+                    Level.WARNING,
+                    "DX Cluster spot rejected: " + exception.getMessage()
+            );
+            return false;
         } catch (Exception exception) {
             LOGGER.log(
                     Level.SEVERE,
@@ -204,11 +208,7 @@ public class DXClusterThreadPooledServer implements Runnable {
 
                 try {
                     OutputStream output = socket.getOutputStream();
-                    output.write(
-                            clusterMessage.getBytes(
-                                    StandardCharsets.US_ASCII
-                            )
-                    );
+                    output.write(clusterPayload);
                     output.flush();
                     deliveredClients++;
                 } catch (IOException exception) {

src/main/java/kst4contest/controller/DXClusterThreadPooledServerTest.java

@@ -1,44 +0,0 @@
-package kst4contest.controller;
-
-import javafx.beans.property.SimpleStringProperty;
-import kst4contest.model.ChatMember;
-import kst4contest.model.ChatPreferences;
-
-public class DXClusterThreadPooledServerTest {
-
-    public static void main(String[] args) {
-
-        ChatController client = new ChatController();
-        ChatPreferences testPreferences = new ChatPreferences();
-        testPreferences.setStn_loginCallSign("DM5M");
-
-        client.setChatPreferences(testPreferences);
-        DXClusterThreadPooledServer dxClusterServer = new DXClusterThreadPooledServer(8000, client, client);
-
-        new Thread(dxClusterServer).start();
-
-
-        try {
-            Thread.sleep(10 * 1000);
-            System.out.println(">>>>>>>>>>>>>>>>>>>>>>>>ready.....go!");
-        } catch (InterruptedException e) {
-            e.printStackTrace();
-        }
-
-        ChatMember test = new ChatMember();
-        test.setCallSign("DL5ASG");
-        test.setQra("JO51HK");
-        test.setFrequency(new SimpleStringProperty("144776.0"));
-
-        dxClusterServer.broadcastSingleDXClusterEntryToLoggers(test);
-
-
-//        try {
-//            Thread.sleep(20 * 3333);
-//        } catch (InterruptedException e) {
-//            e.printStackTrace();
-//        }
-//        System.out.println("Stopping Server");
-//        server.stop();
-    }
-}

src/main/java/kst4contest/controller/ExternalLoggedQso.java

@@ -0,0 +1,116 @@
+package kst4contest.controller;
+
+import java.util.Optional;
+
+import kst4contest.model.ChatMember;
+
+/**
+ * Validated QSO state shared by external logger listeners and the controller.
+ */
+public final class ExternalLoggedQso {
+	private final String callSign;
+	private final LoggedQsoBand band;
+	private final String locator;
+	private final String source;
+
+	private ExternalLoggedQso(
+			String callSign,
+			LoggedQsoBand band,
+			String locator,
+			String source
+	) {
+		this.callSign = callSign;
+		this.band = band;
+		this.locator = locator;
+		this.source = source;
+	}
+
+	/**
+	 * Creates a QSO only when the logger supplied a usable callsign. Missing band
+	 * and locator values remain unavailable and never receive guessed defaults.
+	 *
+	 * @param rawCallSign callsign received from the logger
+	 * @param band normalized band or {@code null}
+	 * @param rawLocator locator received from the logger or {@code null}
+	 * @param source logger name used for persistence diagnostics
+	 * @return validated QSO, or an empty value for a missing callsign
+	 */
+	public static Optional<ExternalLoggedQso> create(
+			String rawCallSign,
+			LoggedQsoBand band,
+			String rawLocator,
+			String source
+	) {
+		if (rawCallSign == null) {
+			return Optional.empty();
+		}
+
+		String normalizedCallSign = rawCallSign.trim();
+		if (normalizedCallSign.isEmpty()) {
+			return Optional.empty();
+		}
+		String normalizedLocator = WorkedGrossFieldCache.extractLocator6(rawLocator);
+		return Optional.of(new ExternalLoggedQso(
+				normalizedCallSign,
+				band,
+				normalizedLocator,
+				source
+		));
+	}
+
+	public String getCallSign() {
+		return callSign;
+	}
+
+	public LoggedQsoBand getBand() {
+		return band;
+	}
+
+	public String getLocator() {
+		return locator;
+	}
+
+	public String getSource() {
+		return source;
+	}
+
+	/**
+	 * Builds the database representation of this QSO.
+	 *
+	 * @return chat-member state with global and optional band Worked flags
+	 */
+	public ChatMember toWorkedChatMember() {
+		ChatMember workedCall = new ChatMember();
+		workedCall.setCallSign(callSign);
+		workedCall.setWorked(true);
+		if (band != null) {
+			band.applyWorkedFlag(workedCall);
+		}
+		if (locator != null) {
+			workedCall.setQra(locator);
+		}
+		return workedCall;
+	}
+
+	/**
+	 * Applies this QSO to one active callsign variant.
+	 *
+	 * @param member active variant with the same base callsign
+	 */
+	public void applyToActiveMember(ChatMember member) {
+		if (member == null) {
+			return;
+		}
+
+		member.setWorked(true);
+		if (band != null) {
+			band.applyWorkedFlag(member);
+		}
+		if (locator != null
+				&& (member.getQra() == null
+				|| member.getQra().isBlank()
+				|| "unknown".equalsIgnoreCase(member.getQra()))) {
+			member.setQra(locator);
+		}
+	}
+}

src/main/java/kst4contest/controller/LoggedQsoBand.java

@@ -0,0 +1,129 @@
+package kst4contest.controller;
+
+import java.util.Locale;
+
+import kst4contest.model.Band;
+import kst4contest.model.ChatMember;
+
+/**
+ * Normalized band of a QSO received from an external logger.
+ *
+ * <p>Logger protocols use different representations for the same amateur-radio
+ * band. UCXLog-compatible XML may contain a frequency-like number or a metre /
+ * centimetre label, while Win-Test uses its own numeric band IDs. Resolving the
+ * raw value once prevents the Worked flag and gross-field update from interpreting
+ * the same packet differently.</p>
+ */
+public enum LoggedQsoBand {
+	BAND_50(Band.B_50),
+	BAND_70(Band.B_70),
+	BAND_144(Band.B_144),
+	BAND_432(Band.B_432),
+	BAND_1296(Band.B_1296),
+	BAND_2320(Band.B_2320),
+	BAND_3400(Band.B_3400),
+	BAND_5760(Band.B_5760),
+	BAND_10G(Band.B_10G),
+	BAND_24G(Band.B_24G),
+	BAND_47G(null),
+	BAND_76G(null);
+
+	private final Band projectBand;
+
+	LoggedQsoBand(Band projectBand) {
+		this.projectBand = projectBand;
+	}
+
+	/**
+	 * Resolves aliases used by UCXLog, N1MM+, DXLog.net, QARTest and compatible
+	 * loggers. The input is trimmed and case-normalized exactly once here.
+	 *
+	 * @param rawBand band value received in the XML packet
+	 * @return normalized band, or {@code null} for a missing or unknown value
+	 */
+	public static LoggedQsoBand fromLoggerValue(String rawBand) {
+		if (rawBand == null) {
+			return null;
+		}
+
+		String normalizedBand = rawBand.trim().toLowerCase(Locale.ROOT);
+		return switch (normalizedBand) {
+			case "50", "6m" -> BAND_50;
+			case "70", "4m" -> BAND_70;
+			case "144", "2m" -> BAND_144;
+			case "432", "70cm" -> BAND_432;
+			case "1240", "1296", "23cm" -> BAND_1296;
+			case "2300", "2320", "13cm" -> BAND_2320;
+			case "3400", "9cm" -> BAND_3400;
+			case "5600", "5760", "6cm" -> BAND_5760;
+			case "10g", "10368", "3cm" -> BAND_10G;
+			default -> null;
+		};
+	}
+
+	/**
+	 * Resolves the established Win-Test ADDQSO band IDs. IDs 22 and 23 retain
+	 * their existing Worked flags even though the project Band enum has no 47 GHz
+	 * or 76 GHz value for gross-field storage.
+	 *
+	 * @param rawBandId Win-Test band ID
+	 * @return normalized band, or {@code null} for a missing or unknown ID
+	 */
+	public static LoggedQsoBand fromWinTestBandId(String rawBandId) {
+		if (rawBandId == null) {
+			return null;
+		}
+
+		String normalizedBandId = rawBandId.trim();
+		return switch (normalizedBandId) {
+			case "10" -> BAND_50;
+			case "11" -> BAND_70;
+			case "12" -> BAND_144;
+			case "14" -> BAND_432;
+			case "16" -> BAND_1296;
+			case "17" -> BAND_2320;
+			case "18" -> BAND_3400;
+			case "19" -> BAND_5760;
+			case "20" -> BAND_10G;
+			case "21" -> BAND_24G;
+			case "22" -> BAND_47G;
+			case "23" -> BAND_76G;
+			default -> null;
+		};
+	}
+
+	/**
+	 * Returns the common Band value used by worked-grid persistence.
+	 *
+	 * @return project band, or {@code null} where no matching Band value exists
+	 */
+	public Band getProjectBand() {
+		return projectBand;
+	}
+
+	/**
+	 * Applies the established per-band Worked flag to a chat member.
+	 *
+	 * @param member worked station or active callsign variant
+	 */
+	public void applyWorkedFlag(ChatMember member) {
+		if (member == null) {
+			return;
+		}
+
+		switch (this) {
+			case BAND_50 -> member.setWorked50(true);
+			case BAND_70 -> member.setWorked70(true);
+			case BAND_144 -> member.setWorked144(true);
+			case BAND_432 -> member.setWorked432(true);
+			case BAND_1296 -> member.setWorked1240(true);
+			case BAND_2320 -> member.setWorked2300(true);
+			case BAND_3400 -> member.setWorked3400(true);
+			case BAND_5760 -> member.setWorked5600(true);
+			case BAND_10G -> member.setWorked10G(true);
+			case BAND_24G -> member.setWorked24G(true);
+			case BAND_47G -> member.setWorked47G(true);
+			case BAND_76G -> member.setWorked76G(true);
+		}
+	}
+}

src/main/java/kst4contest/controller/MessageBusManagementThread.java

@@ -57,7 +57,7 @@ public class MessageBusManagementThread extends Thread {
 	/*
 	 * Frequency formats handled by the smart parser:
 	 *
-	 * Group 1: full frequencies, for example 144.210 or 10368.100
+	 * Group 1: full frequencies, for example 144.210, 144210 or 10368100
 	 * Group 2: relative frequencies with a separator, for example .210 or ,210
 	 * Group 3: bare three-digit values, for example 210
 	 *
@@ -66,7 +66,7 @@ public class MessageBusManagementThread extends Thread {
 	 * would be converted into plausible but incorrect frequencies.
 	 */
 	private static final Pattern SMART_FREQUENCY_PATTERN = Pattern.compile(
-			"(?<![\\d])(\\d{2,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?)(?![\\d])"
+			"(?<![A-Z0-9])(\\d{2,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?|\\d{5,8})(?![A-Z0-9])"
 					+ "|(?<![\\d])([.,]\\d{3}(?:[.,]\\d{1,3})?)(?![\\d])"
 					+ "|(?<=\\s|^)(\\d{3})(?=\\s|$)"
 	);
@@ -279,7 +279,7 @@ public class MessageBusManagementThread extends Thread {
 	 * @param message message whose text is inspected
 	 * @param prefs preferences containing the global fallback band
 	 */
-	private void smartFrequencyExtraction(ChatMessage message, ChatPreferences prefs) {
+	/* package */ void smartFrequencyExtraction(ChatMessage message, ChatPreferences prefs) {
 		if (message == null || message.getMessageText() == null) {
 			return;
 		}
@@ -877,6 +877,12 @@ public class MessageBusManagementThread extends Thread {
 				|| messageToProcess.getMessageText().isEmpty()) {
 			// No processable data.
 		} else {
+			if (On4KstProtocol.isConnectionProbeResponse(
+					messageToProcess.getMessageText())) {
+				// DXQ is the internal response to the active connection probe.
+				// Liveness was already recorded by the session manager.
+				return;
+			}
 
 			if (messageToProcess.getMessageText().startsWith(SRVR_LOGSTAT + "|")) {
 				String[] logstatMessage =
@@ -1841,14 +1847,14 @@ public class MessageBusManagementThread extends Thread {
 	 * @param sender station for which the DX Cluster spot is generated
 	 * @return locator with up to two optional AP entries
 	 */
-	private String buildDxClusterSpotComment(ChatMember sender) {
+	static String buildDxClusterSpotComment(ChatMember sender) {
 		if (sender == null) {
 			return "";
 		}
 
 		String locator = sender.getQra() == null
 				? ""
-				: sender.getQra().trim();
+				: sender.getQra().trim().toUpperCase(Locale.ROOT);
 
 		AirPlaneReflectionInfo reflectionInfo =
 				sender.getAirPlaneReflectInfo();
@@ -1876,7 +1882,7 @@ public class MessageBusManagementThread extends Thread {
 
 			aircraftComments.add(
 					aircraft.getArrivingDurationMinutes()
-							+ "min, "
+							+ "m/"
 							+ aircraft.getPotential()
 							+ "%"
 			);
@@ -1887,11 +1893,11 @@ public class MessageBusManagementThread extends Thread {
 		}
 
 		String apComment =
-				"AP: " + String.join("; ", aircraftComments);
+				"AP " + String.join(";", aircraftComments);
 
 		return locator.isEmpty()
 				? apComment
-				: locator + " , " + apComment;
+				: locator + " " + apComment;
 	}
 
 	/**
@@ -2177,8 +2183,11 @@ public class MessageBusManagementThread extends Thread {
 //								e.printStackTrace();
 //							}
 
-					System.out.println(messageTextRaw.getMessageText() + " <- RXed"); // Stdout at
-					// Console#######################################################TODO:Wichtig
+					if (!On4KstProtocol.isConnectionProbeResponse(
+							messageTextRaw.getMessageText())) {
+						System.out.println(messageTextRaw.getMessageText() + " <- RXed"); // Stdout at
+						// Console#######################################################TODO:Wichtig
+					}
 
 					try {
 						processRXMessage23001(messageTextRaw);

src/main/java/kst4contest/controller/On4KstConnectionManager.java

@@ -48,6 +48,8 @@ final class On4KstConnectionManager {
     static final long LOGIN_FALLBACK_MILLIS = 2_000L; //Login-Fallback
     static final long HANDSHAKE_TIMEOUT_MILLIS = 45_000L; //Handshake-Timeout
     static final long APPLICATION_HEARTBEAT_AFTER_MILLIS = 90_000L; //Application-Heartbeat
+    /** Idle duration after which the server is asked for current DX data. */
+    static final long CONNECTION_PROBE_AFTER_MILLIS = 180_000L; //Active connection probe
     static final long INBOUND_STALE_AFTER_MILLIS = 210_000L; //Stale-Timeout - time without rxed data
     static final List<Long> RECONNECT_DELAYS_MILLIS =
             List.of(2_000L, 5_000L, 10_000L, 20_000L, 30_000L); //Reconnect-Backoff if no connection possible
@@ -137,6 +139,20 @@ final class On4KstConnectionManager {
         scheduler.execute(() -> openConnection(token));
     }
 
+    /**
+     * Stops the supervisor thread of this manager for good.
+     *
+     * <p>{@link #stopByUser()} only ends the current ON4KST session; the periodic
+     * session monitor keeps running. That is correct while the application lives, but a
+     * manager belonging to a discarded runtime must release its thread, otherwise every
+     * operator profile switch would leave another supervisor behind holding the dead
+     * controller.</p>
+     */
+    void shutdown() {
+        scheduler.shutdownNow();
+        LOGGER.fine("ON4KST connection supervisor shut down");
+    }
+
     /**
      * Stops the current session and invalidates every scheduled callback or reconnect
      * belonging to it.
@@ -178,7 +194,19 @@ final class On4KstConnectionManager {
         session.lastInboundMillis.set(now);
         session.lastProgressMillis.set(now);
 
-        String opcode = opcode(line);
+        String opcode = On4KstProtocol.opcode(line);
+        long probeResponseMillis = session.connectionProbe.acknowledge(now);
+        if (probeResponseMillis >= 0L) {
+            LOGGER.log(Level.INFO,
+                    "ON4KST connection probe confirmed: session {0}, "
+                            + "received opcode {1}, response time {2} ms",
+                    new Object[] {
+                            sessionId,
+                            opcode,
+                            probeResponseMillis
+                    });
+        }
+
         if ("CK".equals(opcode)) {
             sendHeartbeat(session);
         }
@@ -244,7 +272,15 @@ final class On4KstConnectionManager {
                     new LinkedBlockingQueue<>();
             LinkedBlockingQueue<ChatMessage> transmitQueue =
                     new LinkedBlockingQueue<>();
-            Session session = new Session(token, socket, receiveQueue, transmitQueue);
+            int mainCategory = controller.getChatPreferences()
+                    .getLoginChatCategoryMain()
+                    .getCategoryNumber();
+            Session session = new Session(
+                    token,
+                    socket,
+                    receiveQueue,
+                    transmitQueue,
+                    mainCategory);
 
             ReadThread readThread = new ReadThread(
                     token, socket, receiveQueue, this::isActiveSession,
@@ -252,8 +288,7 @@ final class On4KstConnectionManager {
                     failure -> onConnectionFailure(token, failure));
             WriteThread writeThread = new WriteThread(
                     token, socket, transmitQueue,
-                    controller.getChatPreferences().getLoginChatCategoryMain()
-                            .getCategoryNumber(),
+                    mainCategory,
                     this::isActiveSession,
                     failure -> onConnectionFailure(token, failure),
                     controller::onOn4KstOutboundFrameRejected);
@@ -535,6 +570,29 @@ final class On4KstConnectionManager {
         session.transmitQueue.offer(heartbeat);
     }
 
+    private void sendConnectionProbe(
+            Session session,
+            long now,
+            long inboundIdle
+    ) {
+        if (session == null || !isActiveSession(session.id)
+                || !session.connectionProbe.tryStart(now)) {
+            return;
+        }
+
+        LOGGER.log(Level.INFO,
+                "Sending ON4KST connection probe: session {0}, main category "
+                        + "{1}, inbound idle {2} seconds",
+                new Object[] {
+                        session.id,
+                        session.mainCategory,
+                        inboundIdle / 1_000L
+                });
+        sendControl(
+                session,
+                On4KstProtocol.connectionProbe(session.mainCategory));
+    }
+
     private void onConnectionFailure(long sessionId, Throwable failure) {
         scheduler.execute(() -> failSession(sessionId, failure));
     }
@@ -634,18 +692,47 @@ final class On4KstConnectionManager {
                 return;
             }
 
-            long inboundIdle = now - session.lastInboundMillis.get();
-            if (inboundIdle > INBOUND_STALE_AFTER_MILLIS) {
-                failSession(session.id,
-                        new SocketException("No ON4KST data received for "
-                                + inboundIdle / 1_000L + " seconds"));
+            long lastInboundMillis = session.lastInboundMillis.get();
+            long inboundIdle = now - lastInboundMillis;
+            IdleAction idleAction = determineIdleAction(
+                    inboundIdle,
+                    session.lastHeartbeatMillis.get() >= lastInboundMillis,
+                    session.connectionProbe.isOutstanding());
+
+            if (session.lastInboundMillis.get() != lastInboundMillis) {
                 return;
             }
 
-            if (inboundIdle > APPLICATION_HEARTBEAT_AFTER_MILLIS
-                    && session.lastHeartbeatMillis.get()
-                    < session.lastInboundMillis.get()) {
-                sendHeartbeat(session);
+            switch (idleAction) {
+                case TIMEOUT -> {
+                    if (session.lastInboundMillis.get() != lastInboundMillis) {
+                        return;
+                    }
+                    long probeWaitMillis =
+                            session.connectionProbe.responseWaitMillis(now);
+                    if (probeWaitMillis >= 0L) {
+                        LOGGER.log(Level.WARNING,
+                                "ON4KST connection probe timed out: session "
+                                        + "{0}, main category {1}, no response "
+                                        + "for {2} ms, inbound idle {3} seconds; "
+                                        + "reconnecting",
+                                new Object[] {
+                                        session.id,
+                                        session.mainCategory,
+                                        probeWaitMillis,
+                                        inboundIdle / 1_000L
+                                });
+                    }
+                    failSession(session.id,
+                            new SocketException("No ON4KST data received for "
+                                    + inboundIdle / 1_000L + " seconds"));
+                }
+                case CONNECTION_PROBE ->
+                        sendConnectionProbe(session, now, inboundIdle);
+                case HEARTBEAT -> sendHeartbeat(session);
+                case NONE -> {
+                    // The session is active or already has the required idle action.
+                }
             }
         } catch (RuntimeException exception) {
             LOGGER.log(Level.WARNING,
@@ -653,6 +740,28 @@ final class On4KstConnectionManager {
         }
     }
 
+    /**
+     * Selects at most one maintenance action for the current inbound idle phase.
+     */
+    static IdleAction determineIdleAction(
+            long inboundIdleMillis,
+            boolean heartbeatSentForIdlePhase,
+            boolean probeOutstanding
+    ) {
+        if (inboundIdleMillis > INBOUND_STALE_AFTER_MILLIS) {
+            return IdleAction.TIMEOUT;
+        }
+        if (inboundIdleMillis >= CONNECTION_PROBE_AFTER_MILLIS
+                && !probeOutstanding) {
+            return IdleAction.CONNECTION_PROBE;
+        }
+        if (inboundIdleMillis > APPLICATION_HEARTBEAT_AFTER_MILLIS
+                && !heartbeatSentForIdlePhase) {
+            return IdleAction.HEARTBEAT;
+        }
+        return IdleAction.NONE;
+    }
+
     private void validateConfiguration() {
         ChatPreferences preferences = controller.getChatPreferences();
         On4KstProtocol.login(
@@ -782,15 +891,6 @@ final class On4KstConnectionManager {
         }
     }
 
-    private String opcode(String line) {
-        if (line == null) {
-            return "";
-        }
-        int separator = line.indexOf('|');
-        return (separator < 0 ? line : line.substring(0, separator))
-                .trim().toUpperCase(Locale.ROOT);
-    }
-
     private String describeFailure(Throwable failure) {
         if (failure == null) {
             return "unknown error";
@@ -808,12 +908,15 @@ final class On4KstConnectionManager {
         private final Socket socket;
         private final LinkedBlockingQueue<ChatMessage> receiveQueue;
         private final LinkedBlockingQueue<ChatMessage> transmitQueue;
+        private final int mainCategory;
         private final long connectedMillis = System.currentTimeMillis();
         private final AtomicLong lastInboundMillis =
                 new AtomicLong(connectedMillis);
         private final AtomicLong lastProgressMillis =
                 new AtomicLong(connectedMillis);
         private final AtomicLong lastHeartbeatMillis = new AtomicLong();
+        private final ConnectionProbeState connectionProbe =
+                new ConnectionProbeState();
         private final Map<Integer, Map<String, ChatMember>> initialMembers =
                 new ConcurrentHashMap<>();
 
@@ -831,12 +934,45 @@ final class On4KstConnectionManager {
                 long id,
                 Socket socket,
                 LinkedBlockingQueue<ChatMessage> receiveQueue,
-                LinkedBlockingQueue<ChatMessage> transmitQueue
+                LinkedBlockingQueue<ChatMessage> transmitQueue,
+                int mainCategory
         ) {
             this.id = id;
             this.socket = socket;
             this.receiveQueue = receiveQueue;
             this.transmitQueue = transmitQueue;
+            this.mainCategory = mainCategory;
+        }
+    }
+
+    /** Maintenance action selected by the session monitor. */
+    enum IdleAction {
+        NONE,
+        HEARTBEAT,
+        CONNECTION_PROBE,
+        TIMEOUT
+    }
+
+    /** Tracks one outstanding liveness probe for the complete TCP session. */
+    static final class ConnectionProbeState {
+        private final AtomicLong sentMillis = new AtomicLong();
+
+        boolean tryStart(long now) {
+            return now > 0L && sentMillis.compareAndSet(0L, now);
+        }
+
+        long acknowledge(long now) {
+            long sent = sentMillis.getAndSet(0L);
+            return sent == 0L ? -1L : Math.max(0L, now - sent);
+        }
+
+        boolean isOutstanding() {
+            return sentMillis.get() > 0L;
+        }
+
+        long responseWaitMillis(long now) {
+            long sent = sentMillis.get();
+            return sent == 0L ? -1L : Math.max(0L, now - sent);
         }
     }
 }

src/main/java/kst4contest/controller/On4KstProtocol.java

@@ -54,6 +54,27 @@ final class On4KstProtocol {
                 + "|0|";
     }
 
+    /** Builds the active liveness probe for the session's main chat. */
+    static String connectionProbe(int category) {
+        return "RDXQ|" + category(category) + "|";
+    }
+
+    /** Returns whether a server frame is the expected liveness-probe response. */
+    static boolean isConnectionProbeResponse(String frame) {
+        return "DXQ".equals(opcode(frame));
+    }
+
+    /** Extracts and normalizes the opcode without exposing the remaining frame. */
+    static String opcode(String frame) {
+        if (frame == null) {
+            return "";
+        }
+        int separator = frame.indexOf('|');
+        return (separator < 0 ? frame : frame.substring(0, separator))
+                .trim()
+                .toUpperCase(Locale.ROOT);
+    }
+
     /** Builds a category-qualified locator command after validating Maidenhead syntax. */
     static String setLocator(int category, String locator) {
         return command(category, "/SETLOC " + locator(locator));

src/main/java/kst4contest/controller/OperatorProfileManagementService.java

@@ -0,0 +1,312 @@
+package kst4contest.controller;
+
+import kst4contest.ApplicationConstants;
+import kst4contest.model.ChatPreferences;
+import kst4contest.model.OperatorProfile;
+import kst4contest.utils.ApplicationFileUtils;
+
+import java.io.IOException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.util.ArrayList;
+import java.util.Comparator;
+import java.util.LinkedHashSet;
+import java.util.List;
+import java.util.Set;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+import java.util.stream.Stream;
+
+/**
+ * Creates, renames, duplicates and removes operator profiles.
+ *
+ * <p>Kept free of user interface code so the behaviour can be tested without a JavaFX
+ * runtime. All methods work on the registry and on the files below the application
+ * directory.</p>
+ */
+public class OperatorProfileManagementService {
+
+    private static final Logger LOGGER =
+            Logger.getLogger(OperatorProfileManagementService.class.getName());
+
+    private final OperatorProfileStore profileStore;
+
+    public OperatorProfileManagementService() {
+        this(new OperatorProfileStore());
+    }
+
+    public OperatorProfileManagementService(final OperatorProfileStore profileStore) {
+        this.profileStore = profileStore;
+    }
+
+    /**
+     * Lists all profiles, including the implicit root profile of a plain installation.
+     *
+     * @return the known profiles, never empty
+     */
+    public List<OperatorProfile> listProfiles() {
+
+        List<OperatorProfile> knownProfiles = profileStore.loadProfiles();
+
+        if (knownProfiles.isEmpty()) {
+            knownProfiles = new ArrayList<>();
+            knownProfiles.add(profileStore.buildImplicitRootProfile());
+        }
+
+        return knownProfiles;
+    }
+
+    /**
+     * Creates a new operator profile with its own preferences file.
+     *
+     * <p>Creating the first additional profile is also the moment the registry appears:
+     * the root profile is written alongside, so both are selectable afterwards.</p>
+     *
+     * @param displayName          name entered by the operator
+     * @param sharedWorkedDatabase true to use the common station worked database
+     * @return the created profile, or null when it could not be stored
+     */
+    public OperatorProfile createProfile(final String displayName, final boolean sharedWorkedDatabase) {
+
+        List<OperatorProfile> knownProfiles = listProfiles();
+        Set<String> takenProfileIds = new LinkedHashSet<>();
+
+        for (OperatorProfile existingProfile : knownProfiles) {
+            takenProfileIds.add(existingProfile.getProfileId());
+        }
+
+        OperatorProfile createdProfile = new OperatorProfile(
+                OperatorProfilePaths.toProfileId(displayName, takenProfileIds),
+                displayName == null || displayName.isBlank() ? "New profile" : displayName.trim(),
+                false,
+                sharedWorkedDatabase);
+
+        knownProfiles.add(createdProfile);
+
+        if (!profileStore.saveProfiles(knownProfiles, createdProfile.getProfileId())) {
+            return null;
+        }
+
+        createPreferencesFile(createdProfile, null);
+
+        return createdProfile;
+    }
+
+    /**
+     * Creates a copy of an existing profile.
+     *
+     * <p>The preferences are taken over completely except for the login credentials:
+     * callsign and password are cleared on purpose, because a duplicate is meant for
+     * another operator. Antenna, locator, layout and integration settings are exactly
+     * what the operator does not want to enter twice.</p>
+     *
+     * <p>The worked-station database is never copied.</p>
+     *
+     * @param sourceProfile profile to copy
+     * @param displayName   name of the new profile
+     * @return the created profile, or null when it could not be stored
+     */
+    public OperatorProfile duplicateProfile(final OperatorProfile sourceProfile, final String displayName) {
+
+        if (sourceProfile == null) {
+            return null;
+        }
+
+        List<OperatorProfile> knownProfiles = listProfiles();
+        Set<String> takenProfileIds = new LinkedHashSet<>();
+
+        for (OperatorProfile existingProfile : knownProfiles) {
+            takenProfileIds.add(existingProfile.getProfileId());
+        }
+
+        OperatorProfile createdProfile = new OperatorProfile(
+                OperatorProfilePaths.toProfileId(displayName, takenProfileIds),
+                displayName == null || displayName.isBlank() ? "Copy" : displayName.trim(),
+                false,
+                sourceProfile.isSharedWorkedDatabase());
+
+        knownProfiles.add(createdProfile);
+
+        if (!profileStore.saveProfiles(knownProfiles, createdProfile.getProfileId())) {
+            return null;
+        }
+
+        createPreferencesFile(createdProfile, sourceProfile);
+
+        return createdProfile;
+    }
+
+    /**
+     * Changes the visible name of a profile. The identifier and all paths stay as they are.
+     *
+     * @param profile        profile to rename
+     * @param newDisplayName new name
+     * @return true if the registry was updated
+     */
+    public boolean renameProfile(final OperatorProfile profile, final String newDisplayName) {
+
+        if (profile == null || newDisplayName == null || newDisplayName.isBlank()) {
+            return false;
+        }
+
+        List<OperatorProfile> knownProfiles = listProfiles();
+
+        for (OperatorProfile currentProfile : knownProfiles) {
+            if (currentProfile.getProfileId().equals(profile.getProfileId())) {
+                currentProfile.setDisplayName(newDisplayName.trim());
+            }
+        }
+
+        return profileStore.saveProfiles(knownProfiles, profileStore.loadLastUsedProfileId().orElse(null));
+    }
+
+    /**
+     * Switches a profile between the common station database and its own one.
+     *
+     * @param profile              profile to change
+     * @param sharedWorkedDatabase true to use the common station worked database
+     * @return true if the registry was updated
+     */
+    public boolean setSharedWorkedDatabase(final OperatorProfile profile, final boolean sharedWorkedDatabase) {
+
+        if (profile == null || profile.isRootProfile()) {
+            return false;
+        }
+
+        List<OperatorProfile> knownProfiles = listProfiles();
+
+        for (OperatorProfile currentProfile : knownProfiles) {
+            if (currentProfile.getProfileId().equals(profile.getProfileId())) {
+                currentProfile.setSharedWorkedDatabase(sharedWorkedDatabase);
+            }
+        }
+
+        return profileStore.saveProfiles(knownProfiles, profileStore.loadLastUsedProfileId().orElse(null));
+    }
+
+    /**
+     * Removes a profile and its directory.
+     *
+     * <p>The root profile can never be removed, because its files are the installation
+     * itself. A profile using the common station database keeps that database untouched;
+     * only its own directory is deleted.</p>
+     *
+     * @param profile profile to remove
+     * @return true if the profile was removed
+     */
+    public boolean deleteProfile(final OperatorProfile profile) {
+
+        if (profile == null || profile.isRootProfile()) {
+            return false;
+        }
+
+        List<OperatorProfile> remainingProfiles = new ArrayList<>();
+
+        for (OperatorProfile currentProfile : listProfiles()) {
+            if (!currentProfile.getProfileId().equals(profile.getProfileId())) {
+                remainingProfiles.add(currentProfile);
+            }
+        }
+
+        if (!profileStore.saveProfiles(remainingProfiles,
+                profileStore.loadLastUsedProfileId().orElse(null))) {
+            return false;
+        }
+
+        deleteProfileDirectory(profile);
+
+        return true;
+    }
+
+    /**
+     * Returns the absolute directory of a profile.
+     *
+     * @param profile profile to resolve
+     * @return absolute profile directory
+     */
+    public String getProfileDirectory(final OperatorProfile profile) {
+        return ApplicationFileUtils.getFilePath(
+                ApplicationConstants.APPLICATION_NAME,
+                OperatorProfilePaths.profileRelativeDirectory(profile));
+    }
+
+    /**
+     * Creates the preferences file of a new profile.
+     *
+     * <p>The file is either seeded from the bundled template or copied from the source
+     * profile. In both cases the login credentials are cleared, so a new profile never
+     * carries another operator's callsign or password.</p>
+     *
+     * @param createdProfile profile that needs a preferences file
+     * @param sourceProfile  profile to copy the preferences from, or null for the template
+     */
+    private void createPreferencesFile(final OperatorProfile createdProfile,
+            final OperatorProfile sourceProfile) {
+
+        String createdRelativeFileName = OperatorProfilePaths.preferencesRelativeFileName(createdProfile);
+
+        if (sourceProfile != null) {
+            copyPreferencesFile(
+                    OperatorProfilePaths.preferencesRelativeFileName(sourceProfile),
+                    createdRelativeFileName);
+        }
+
+        // Seeds from the bundled template when nothing was copied, and always resolves
+        // the preferences of the new profile.
+        ChatPreferences createdPreferences = new ChatPreferences(createdRelativeFileName);
+        createdPreferences.readPreferencesFromXmlFile();
+
+        createdPreferences.setStn_loginCallSign("");
+        createdPreferences.setStn_loginPassword("");
+
+        createdPreferences.writePreferencesToXmlFile();
+    }
+
+    private void copyPreferencesFile(final String sourceRelativeFileName,
+            final String targetRelativeFileName) {
+
+        Path sourcePath = Path.of(ApplicationFileUtils.getFilePath(
+                ApplicationConstants.APPLICATION_NAME, sourceRelativeFileName));
+        Path targetPath = Path.of(ApplicationFileUtils.getFilePath(
+                ApplicationConstants.APPLICATION_NAME, targetRelativeFileName));
+
+        if (!Files.isRegularFile(sourcePath)) {
+            return;
+        }
+
+        try {
+            Path targetDirectory = targetPath.getParent();
+
+            if (targetDirectory != null) {
+                Files.createDirectories(targetDirectory);
+            }
+
+            Files.copy(sourcePath, targetPath);
+        } catch (IOException e) {
+            LOGGER.log(Level.WARNING,
+                    "Could not copy the preferences of the source profile, using the defaults instead", e);
+        }
+    }
+
+    private void deleteProfileDirectory(final OperatorProfile profile) {
+
+        Path profileDirectory = Path.of(getProfileDirectory(profile));
+
+        if (!Files.isDirectory(profileDirectory)) {
+            return;
+        }
+
+        try (Stream<Path> containedPaths = Files.walk(profileDirectory)) {
+            List<Path> deepestFirst = containedPaths
+                    .sorted(Comparator.reverseOrder())
+                    .toList();
+
+            for (Path currentPath : deepestFirst) {
+                Files.deleteIfExists(currentPath);
+            }
+        } catch (IOException e) {
+            LOGGER.log(Level.WARNING,
+                    "Could not remove the directory of the deleted operator profile", e);
+        }
+    }
+}

src/main/java/kst4contest/controller/OperatorProfilePaths.java

@@ -0,0 +1,199 @@
+package kst4contest.controller;
+
+import kst4contest.model.ChatPreferences;
+import kst4contest.model.OperatorProfile;
+import kst4contest.model.OperatorProfileSelection;
+
+import java.util.Collection;
+import java.util.Locale;
+
+/**
+ * Derives the file names of an operator profile.
+ *
+ * <p>This is the single place that knows how a profile maps onto files. The registry
+ * stores only the shared/own flag, never a path, so the two can never drift apart.</p>
+ */
+public final class OperatorProfilePaths {
+
+    /**
+     * Directory below the application directory that holds the additional profiles.
+     */
+    public static final String PROFILES_DIRECTORY = "profiles";
+
+    /**
+     * Identifier of the profile that uses the historic flat installation layout.
+     */
+    public static final String ROOT_PROFILE_ID = "default";
+
+    /**
+     * Maximum length of a generated profile identifier.
+     */
+    private static final int MAX_PROFILE_ID_LENGTH = 32;
+
+    private OperatorProfilePaths() {
+        // Utility class.
+    }
+
+    /**
+     * Builds the profile descriptor of the historic flat installation.
+     *
+     * @param displayName name to show for the root profile
+     * @return the root profile descriptor
+     */
+    public static OperatorProfile buildRootProfile(final String displayName) {
+        return new OperatorProfile(ROOT_PROFILE_ID, displayName, true, true);
+    }
+
+    /**
+     * Returns the profile directory relative to the application directory.
+     *
+     * @param profile profile to resolve
+     * @return relative directory name
+     */
+    public static String profileRelativeDirectory(final OperatorProfile profile) {
+        return PROFILES_DIRECTORY + "/" + profile.getProfileId();
+    }
+
+    /**
+     * Returns the preferences file name relative to the application directory.
+     *
+     * @param profile profile to resolve
+     * @return relative preferences file name
+     */
+    public static String preferencesRelativeFileName(final OperatorProfile profile) {
+
+        if (profile.isRootProfile()) {
+            return ChatPreferences.PREFERENCES_FILE;
+        }
+
+        return profileRelativeDirectory(profile) + "/" + ChatPreferences.PREFERENCES_FILE;
+    }
+
+    /**
+     * Returns the worked-station database file name relative to the application directory.
+     *
+     * <p>A profile using the common station database always resolves to the historic flat
+     * file, which is what a multi operator station wants: the existing contest state stays
+     * the shared one.</p>
+     *
+     * @param profile profile to resolve
+     * @return relative database file name
+     */
+    public static String workedDatabaseRelativeFileName(final OperatorProfile profile) {
+
+        if (profile.isRootProfile() || profile.isSharedWorkedDatabase()) {
+            return DBController.DATABASE_FILE;
+        }
+
+        return profileRelativeDirectory(profile) + "/" + DBController.DATABASE_FILE;
+    }
+
+    /**
+     * Resolves a profile descriptor into the runtime selection used during startup.
+     *
+     * @param profile profile to resolve
+     * @return resolved selection
+     */
+    public static OperatorProfileSelection resolve(final OperatorProfile profile) {
+
+        boolean usesSharedStationDatabase = profile.isRootProfile() || profile.isSharedWorkedDatabase();
+
+        return new OperatorProfileSelection(
+                profile,
+                preferencesRelativeFileName(profile),
+                workedDatabaseRelativeFileName(profile),
+                usesSharedStationDatabase
+        );
+    }
+
+    /**
+     * Derives a stable, file system safe identifier from a display name.
+     *
+     * <p>The identifier becomes a directory name and is never changed afterwards, so a
+     * later rename of the profile does not move any file.</p>
+     *
+     * @param displayName name entered by the operator
+     * @param takenProfileIds identifiers that are already in use
+     * @return an identifier that is not yet taken
+     */
+    public static String toProfileId(final String displayName, final Collection<String> takenProfileIds) {
+
+        StringBuilder sanitized = new StringBuilder();
+
+        if (displayName != null) {
+            String foldedDisplayName = foldGermanUmlauts(displayName.toUpperCase(Locale.ROOT));
+
+            for (char currentCharacter : foldedDisplayName.toCharArray()) {
+                boolean isAcceptable = (currentCharacter >= 'A' && currentCharacter <= 'Z')
+                        || (currentCharacter >= '0' && currentCharacter <= '9')
+                        || currentCharacter == '-';
+
+                if (isAcceptable) {
+                    sanitized.append(currentCharacter);
+                } else if (sanitized.length() > 0 && sanitized.charAt(sanitized.length() - 1) != '_') {
+                    sanitized.append('_');
+                }
+            }
+        }
+
+        while (sanitized.length() > 0 && sanitized.charAt(sanitized.length() - 1) == '_') {
+            sanitized.setLength(sanitized.length() - 1);
+        }
+
+        if (sanitized.length() > MAX_PROFILE_ID_LENGTH) {
+            sanitized.setLength(MAX_PROFILE_ID_LENGTH);
+        }
+
+        String candidate = sanitized.toString();
+
+        if (candidate.isEmpty() || ROOT_PROFILE_ID.equalsIgnoreCase(candidate)) {
+            candidate = "OP";
+        }
+
+        if (!isProfileIdTaken(candidate, takenProfileIds)) {
+            return candidate;
+        }
+
+        int suffix = 2;
+
+        while (isProfileIdTaken(candidate + "_" + suffix, takenProfileIds)) {
+            suffix++;
+        }
+
+        return candidate + "_" + suffix;
+    }
+
+    /**
+     * Folds German umlauts so a name like "Muller" written with an umlaut still produces a
+     * readable identifier instead of a placeholder character.
+     *
+     * @param upperCaseText already upper-cased text
+     * @return text with umlauts replaced by their base letters
+     */
+    private static String foldGermanUmlauts(final String upperCaseText) {
+        return upperCaseText
+                .replace("\u00C4", "A")
+                .replace("\u00D6", "O")
+                .replace("\u00DC", "U")
+                .replace("\u00DF", "SS");
+    }
+
+    private static boolean isProfileIdTaken(final String candidate, final Collection<String> takenProfileIds) {
+
+        if (ROOT_PROFILE_ID.equalsIgnoreCase(candidate)) {
+            return true;
+        }
+
+        if (takenProfileIds == null) {
+            return false;
+        }
+
+        for (String takenProfileId : takenProfileIds) {
+            if (candidate.equalsIgnoreCase(takenProfileId)) {
+                return true;
+            }
+        }
+
+        return false;
+    }
+}

src/main/java/kst4contest/controller/OperatorProfileStore.java

@@ -0,0 +1,386 @@
+package kst4contest.controller;
+
+import kst4contest.ApplicationConstants;
+import kst4contest.model.OperatorProfile;
+import kst4contest.utils.ApplicationFileUtils;
+
+import org.w3c.dom.Document;
+import org.w3c.dom.Element;
+import org.w3c.dom.Node;
+import org.w3c.dom.NodeList;
+
+import javax.xml.XMLConstants;
+import javax.xml.parsers.DocumentBuilder;
+import javax.xml.parsers.DocumentBuilderFactory;
+import javax.xml.transform.OutputKeys;
+import javax.xml.transform.Transformer;
+import javax.xml.transform.TransformerFactory;
+import javax.xml.transform.dom.DOMSource;
+import javax.xml.transform.stream.StreamResult;
+
+import java.io.File;
+import java.io.OutputStream;
+import java.nio.file.AtomicMoveNotSupportedException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.nio.file.StandardCopyOption;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Optional;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
+/**
+ * Reads and writes the operator profile registry.
+ *
+ * <p>The registry file is created lazily. As long as an installation has only the
+ * historic flat layout, no registry exists and none is written, so a single operator
+ * installation behaves exactly as before. The file appears when the second profile is
+ * created; at that moment the root profile is materialised as well.</p>
+ *
+ * <p>A missing, unreadable or malformed registry is never fatal. It is logged and
+ * treated like an installation without additional profiles.</p>
+ */
+public class OperatorProfileStore {
+
+    private static final Logger LOGGER = Logger.getLogger(OperatorProfileStore.class.getName());
+
+    /**
+     * Name of the registry file inside the application directory.
+     */
+    public static final String PROFILES_REGISTRY_FILE = "profiles.xml";
+
+    private static final String TAG_ROOT = "praktiKSTProfiles";
+    private static final String TAG_REGISTRY_VERSION = "registryVersion";
+    private static final String TAG_LAST_USED_PROFILE_ID = "lastUsedProfileId";
+    private static final String TAG_PROFILE = "profile";
+    private static final String TAG_PROFILE_ID = "profileId";
+    private static final String TAG_DISPLAY_NAME = "displayName";
+    private static final String TAG_ROOT_PROFILE = "rootProfile";
+    private static final String TAG_SHARED_WORKED_DATABASE = "sharedWorkedDatabase";
+    private static final String TAG_LAST_USED_EPOCH_MS = "lastUsedEpochMs";
+
+    private static final int REGISTRY_VERSION = 1;
+
+    private final String registryFilePath;
+
+    /**
+     * Creates a store working on the registry of the current installation.
+     */
+    public OperatorProfileStore() {
+        this(ApplicationFileUtils.getFilePath(
+                ApplicationConstants.APPLICATION_NAME, PROFILES_REGISTRY_FILE));
+    }
+
+    /**
+     * Creates a store working on an explicit registry file.
+     *
+     * @param registryFilePath absolute path of the registry file
+     */
+    public OperatorProfileStore(final String registryFilePath) {
+        this.registryFilePath = registryFilePath;
+    }
+
+    /**
+     * Returns whether a registry file exists at all.
+     *
+     * @return true if the installation already has more than the historic flat layout
+     */
+    public boolean isRegistryPresent() {
+        return new File(registryFilePath).isFile();
+    }
+
+    /**
+     * Builds the in-memory descriptor of the historic flat installation.
+     *
+     * <p>Nothing is written. This keeps a single operator installation untouched.</p>
+     *
+     * @return the implicit root profile
+     */
+    public OperatorProfile buildImplicitRootProfile() {
+        return OperatorProfilePaths.buildRootProfile("Default");
+    }
+
+    /**
+     * Reads all stored profiles.
+     *
+     * @return the stored profiles, or an empty list when no usable registry exists
+     */
+    public List<OperatorProfile> loadProfiles() {
+
+        List<OperatorProfile> loadedProfiles = new ArrayList<>();
+        Document document = readRegistryDocument();
+
+        if (document == null) {
+            return loadedProfiles;
+        }
+
+        NodeList profileNodes = document.getElementsByTagName(TAG_PROFILE);
+
+        for (int profileIndex = 0; profileIndex < profileNodes.getLength(); profileIndex++) {
+            Node currentNode = profileNodes.item(profileIndex);
+
+            if (currentNode.getNodeType() != Node.ELEMENT_NODE) {
+                continue;
+            }
+
+            Element profileElement = (Element) currentNode;
+            String profileId = readText(profileElement, TAG_PROFILE_ID);
+
+            if (profileId == null || profileId.isBlank()) {
+                LOGGER.log(Level.WARNING, "Skipping operator profile entry without an identifier");
+                continue;
+            }
+
+            OperatorProfile loadedProfile = new OperatorProfile();
+            loadedProfile.setProfileId(profileId.trim());
+            loadedProfile.setDisplayName(readText(profileElement, TAG_DISPLAY_NAME));
+            loadedProfile.setRootProfile(readBoolean(profileElement, TAG_ROOT_PROFILE, false));
+            loadedProfile.setSharedWorkedDatabase(
+                    readBoolean(profileElement, TAG_SHARED_WORKED_DATABASE, true));
+            loadedProfile.setLastUsedEpochMs(readLong(profileElement, TAG_LAST_USED_EPOCH_MS));
+
+            if (loadedProfile.getDisplayName() == null || loadedProfile.getDisplayName().isBlank()) {
+                loadedProfile.setDisplayName(loadedProfile.getProfileId());
+            }
+
+            // The root profile always uses the common station database, because its
+            // database is the historic flat file itself.
+            if (loadedProfile.isRootProfile()) {
+                loadedProfile.setSharedWorkedDatabase(true);
+            }
+
+            loadedProfiles.add(loadedProfile);
+        }
+
+        return loadedProfiles;
+    }
+
+    /**
+     * Reads the identifier of the profile that was activated last.
+     *
+     * @return the identifier, or empty when unknown
+     */
+    public Optional<String> loadLastUsedProfileId() {
+
+        Document document = readRegistryDocument();
+
+        if (document == null) {
+            return Optional.empty();
+        }
+
+        Element rootElement = document.getDocumentElement();
+
+        if (rootElement == null) {
+            return Optional.empty();
+        }
+
+        String lastUsedProfileId = readText(rootElement, TAG_LAST_USED_PROFILE_ID);
+
+        if (lastUsedProfileId == null || lastUsedProfileId.isBlank()) {
+            return Optional.empty();
+        }
+
+        return Optional.of(lastUsedProfileId.trim());
+    }
+
+    /**
+     * Writes the complete registry.
+     *
+     * @param profiles          profiles to store
+     * @param lastUsedProfileId identifier of the profile that was activated last, may be null
+     * @return true if the registry was written
+     */
+    public boolean saveProfiles(final List<OperatorProfile> profiles, final String lastUsedProfileId) {
+
+        try {
+            DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
+            DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder();
+            Document document = documentBuilder.newDocument();
+
+            Element rootElement = document.createElement(TAG_ROOT);
+            document.appendChild(rootElement);
+
+            appendTextElement(document, rootElement, TAG_REGISTRY_VERSION, String.valueOf(REGISTRY_VERSION));
+
+            if (lastUsedProfileId != null && !lastUsedProfileId.isBlank()) {
+                appendTextElement(document, rootElement, TAG_LAST_USED_PROFILE_ID, lastUsedProfileId);
+            }
+
+            for (OperatorProfile currentProfile : profiles) {
+                Element profileElement = document.createElement(TAG_PROFILE);
+                rootElement.appendChild(profileElement);
+
+                appendTextElement(document, profileElement, TAG_PROFILE_ID, currentProfile.getProfileId());
+                appendTextElement(document, profileElement, TAG_DISPLAY_NAME, currentProfile.getDisplayName());
+                appendTextElement(document, profileElement, TAG_ROOT_PROFILE,
+                        String.valueOf(currentProfile.isRootProfile()));
+                appendTextElement(document, profileElement, TAG_SHARED_WORKED_DATABASE,
+                        String.valueOf(currentProfile.isRootProfile() || currentProfile.isSharedWorkedDatabase()));
+                appendTextElement(document, profileElement, TAG_LAST_USED_EPOCH_MS,
+                        String.valueOf(currentProfile.getLastUsedEpochMs()));
+            }
+
+            return writeDocumentAtomically(document);
+        } catch (Exception e) {
+            LOGGER.log(Level.SEVERE, "Could not write the operator profile registry", e);
+            return false;
+        }
+    }
+
+    /**
+     * Records that a profile has been activated.
+     *
+     * <p>Does nothing when no registry exists, so a single operator installation is not
+     * turned into a multi profile installation by merely starting the application.</p>
+     *
+     * @param profileId identifier of the activated profile
+     * @return true if the registry was updated
+     */
+    public boolean recordLastUsed(final String profileId) {
+
+        if (!isRegistryPresent()) {
+            return false;
+        }
+
+        List<OperatorProfile> storedProfiles = loadProfiles();
+
+        if (storedProfiles.isEmpty()) {
+            return false;
+        }
+
+        for (OperatorProfile currentProfile : storedProfiles) {
+            if (currentProfile.getProfileId().equalsIgnoreCase(profileId)) {
+                currentProfile.setLastUsedEpochMs(System.currentTimeMillis());
+            }
+        }
+
+        return saveProfiles(storedProfiles, profileId);
+    }
+
+    /**
+     * Returns the absolute path of the registry file.
+     *
+     * @return absolute registry path
+     */
+    public String getRegistryFilePath() {
+        return registryFilePath;
+    }
+
+    private Document readRegistryDocument() {
+
+        File registryFile = new File(registryFilePath);
+
+        if (!registryFile.isFile()) {
+            return null;
+        }
+
+        try {
+            DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
+            documentBuilderFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
+
+            return documentBuilderFactory.newDocumentBuilder().parse(registryFile);
+        } catch (Exception e) {
+            LOGGER.log(Level.WARNING,
+                    "Could not read the operator profile registry, continuing without additional profiles", e);
+            return null;
+        }
+    }
+
+    private static String readText(final Element parentElement, final String tagName) {
+
+        NodeList matchingNodes = parentElement.getElementsByTagName(tagName);
+
+        if (matchingNodes.getLength() == 0) {
+            return null;
+        }
+
+        return matchingNodes.item(0).getTextContent();
+    }
+
+    private static boolean readBoolean(final Element parentElement,
+            final String tagName,
+            final boolean defaultValue) {
+
+        String rawValue = readText(parentElement, tagName);
+
+        if (rawValue == null || rawValue.isBlank()) {
+            return defaultValue;
+        }
+
+        return Boolean.parseBoolean(rawValue.trim());
+    }
+
+    private static long readLong(final Element parentElement, final String tagName) {
+
+        String rawValue = readText(parentElement, tagName);
+
+        if (rawValue == null || rawValue.isBlank()) {
+            return 0L;
+        }
+
+        try {
+            return Long.parseLong(rawValue.trim());
+        } catch (NumberFormatException e) {
+            return 0L;
+        }
+    }
+
+    private static void appendTextElement(final Document document,
+            final Element parentElement,
+            final String tagName,
+            final String textContent) {
+
+        Element createdElement = document.createElement(tagName);
+        createdElement.setTextContent(textContent == null ? "" : textContent);
+        parentElement.appendChild(createdElement);
+    }
+
+    /**
+     * Writes the registry through a temporary file so a crash can never leave a
+     * half-written registry behind. This mirrors the established preferences writer.
+     *
+     * @param document document to write
+     * @return true if the registry file was replaced
+     */
+    private boolean writeDocumentAtomically(final Document document) {
+
+        Path targetPath = Path.of(registryFilePath).toAbsolutePath();
+        Path parentDirectory = targetPath.getParent();
+
+        if (parentDirectory == null) {
+            LOGGER.log(Level.SEVERE,
+                    "The operator profile registry path has no directory: {0}", registryFilePath);
+            return false;
+        }
+
+        try {
+            Files.createDirectories(parentDirectory);
+
+            // The temporary file has to live next to the target so the final move can be
+            // atomic; both must be on the same file system.
+            Path temporaryPath = Files.createTempFile(
+                    parentDirectory, PROFILES_REGISTRY_FILE, ".tmp");
+
+            Transformer transformer = TransformerFactory.newInstance().newTransformer();
+            transformer.setOutputProperty(OutputKeys.INDENT, "yes");
+            transformer.setOutputProperty("{http://xml.apache.org/xslt}indent-amount", "4");
+
+            try (OutputStream outputStream = Files.newOutputStream(temporaryPath)) {
+                transformer.transform(new DOMSource(document), new StreamResult(outputStream));
+            }
+
+            try {
+                Files.move(temporaryPath, targetPath,
+                        StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);
+            } catch (AtomicMoveNotSupportedException atomicMoveUnsupported) {
+                Files.move(temporaryPath, targetPath, StandardCopyOption.REPLACE_EXISTING);
+            }
+
+            return true;
+        } catch (Exception e) {
+            LOGGER.log(Level.SEVERE, "Could not store the operator profile registry", e);
+            return false;
+        }
+    }
+}

src/main/java/kst4contest/controller/ReadUDPByWintestThread.java

@@ -2,10 +2,8 @@ package kst4contest.controller;
 
 import javafx.application.Platform;
 import kst4contest.ApplicationConstants;
-import kst4contest.model.Band;
 import kst4contest.model.ChatMember;
 import kst4contest.model.ThreadStateMessage;
-import kst4contest.view.GuiUtils;
 
 import java.io.BufferedWriter;
 import java.io.File;
@@ -15,8 +13,9 @@ import java.net.*;
 import java.nio.charset.StandardCharsets;
 import java.util.ArrayList;
 import java.util.Arrays;
+import java.util.HashMap;
+import java.util.List;
 import java.util.Map;
-import java.util.concurrent.ConcurrentHashMap;
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 
@@ -33,18 +32,40 @@ public class ReadUDPByWintestThread extends Thread {
 
     private static final int BUFFER_SIZE = 4096;
 
-    private final Map<Integer, String> receivedQsos = new ConcurrentHashMap<>();
     private long lastPacketTime = 0;
 
     private String myStation = "DO5AMF";
 
     private String targetStation = "";
     private String stationID = "";
-    private int lastKnownQso = 0;
 
     private ThreadStatusCallback callBackToController;
     private String ThreadNickName = "Wintest-msg";
 
+    /**
+     * Number of fields of a complete ADDQSO packet, including message type,
+     * source and destination.
+     */
+    private static final int ADDQSO_FIELD_COUNT = 24;
+
+    /** Field position of the Win-Test QSO number inside an ADDQSO packet. */
+    private static final int ADDQSO_QSO_NUMBER_INDEX = 11;
+
+    /** Field position of the logging station name inside an ADDQSO packet. */
+    private static final int ADDQSO_STATION_NAME_INDEX = 3;
+
+    private final WinTestLogSyncService logSyncService;
+
+    private WinTestLogSyncService.SyncState lastReportedSyncState;
+
+    /**
+     * Last IHAVE payload seen per station. Win-Test repeats the inventory
+     * periodically, so tracing only the changes keeps the output readable.
+     */
+    private final Map<String, String> lastTracedIhaveByStation = new HashMap<>();
+
+    private final WinTestNetworkAddressResolver addressResolver;
+
 
     public ReadUDPByWintestThread(ChatController client, ThreadStatusCallback callback) {
 
@@ -53,6 +74,21 @@ public class ReadUDPByWintestThread extends Thread {
         this.myStation = client.getChatPreferences().getStn_loginCallSignRaw(); //callsign of the logging stn
         this.PORT =  client.getChatPreferences().getLogsynch_wintestNetworkPort();
 
+        WinTestNetworkAddressResolver sharedAddressResolver =
+                client.getWinTestAddressResolver();
+        this.addressResolver = sharedAddressResolver != null
+                ? sharedAddressResolver
+                : new WinTestNetworkAddressResolver();
+
+        /*
+         * Preferences are read late on purpose: station name, port and broadcast
+         * address can be changed while the listener is running.
+         */
+        this.logSyncService = new WinTestLogSyncService(
+                this::sendNeedQso,
+                this::resolveOwnWinTestStationName
+        );
+
     }
 
     @Override
@@ -87,35 +123,113 @@ public class ReadUDPByWintestThread extends Thread {
 
         while (running) {
             try {
+                /*
+                 * DatagramPacket keeps the length of the previous datagram, so
+                 * without resetting it a long packet would be truncated after a
+                 * short one. A truncated packet loses its trailing fields and
+                 * its checksum.
+                 */
+                packet.setLength(buffer.length);
                 socket.receive(packet);
-                String msg = new String(packet.getData(), 0, packet.getLength(), StandardCharsets.US_ASCII).trim();
-                processWinTestMessage(msg);
+                processWinTestDatagram(
+                        packet.getData(), packet.getLength(), packet.getAddress());
             } catch (SocketTimeoutException e) {
-//                checkForMissingQsos();
+                logSyncService.tick();
+                reportSyncStateIfChanged();
             } catch (IOException e) {
                 //TODO: here is something to catch
             }
         }
     }
 
-    private void processWinTestMessage(String msg) {
+    /**
+     * Resolves the Win-Test framing of a received datagram and processes it.
+     *
+     * <p>The checksum byte and the NUL terminator are removed on the raw bytes
+     * before any text parsing, so the trailing fields of the packet stay
+     * readable. Afterwards the log synchronization gets its chance to request
+     * QSOs that were logged before this listener was started.</p>
+     *
+     * @param datagram raw datagram buffer
+     * @param length number of valid bytes in the buffer
+     */
+    void processWinTestDatagram(byte[] datagram, int length, InetAddress source) {
+        if (datagram == null || length <= 0) {
+            return;
+        }
+
+        WinTestPacket packet = WinTestPacket.fromDatagram(datagram, length);
+
+        if (packet != null && isWinTestStationMessage(packet.getMessageType())) {
+            /*
+             * Win-Test only answers broadcasts. Remembering where its packets
+             * come from keeps outgoing requests on the network the station
+             * actually lives in, even when the configured broadcast address
+             * belongs to a different or no longer existing network.
+             */
+            addressResolver.rememberStationAddress(source);
+        }
+
+        if (packet == null) {
+            /*
+             * The datagram does not follow the Win-Test framing. It still
+             * reaches the established text handling, which also recognizes the
+             * poison pill that stops this listener.
+             */
+            processWinTestPacket(
+                    null,
+                    new String(datagram, 0, length, StandardCharsets.US_ASCII).trim()
+            );
+            return;
+        }
+
+        processWinTestPacket(packet, packet.getMessageText());
+
+        logSyncService.tick();
+        reportSyncStateIfChanged();
+    }
+
+    void processWinTestMessage(String msg) {
+        processWinTestPacket(WinTestPacket.fromMessageText(msg), msg);
+    }
+
+    /**
+     * Processes one Win-Test message.
+     *
+     * @param packet parsed packet, or {@code null} when the message does not
+     *               follow the Win-Test framing
+     * @param msg complete message text
+     */
+    private void processWinTestPacket(WinTestPacket packet, String msg) {
 //        System.out.println("Wintest-Message received: " + msg);
 
+        if (msg == null) {
+            return;
+        }
+
         lastPacketTime = System.currentTimeMillis();
 
         if (msg.startsWith("HELLO:")) { //Client Signon of wintest
             parseHello(msg);
-            try {
-//                send_needqso();
-            }catch (Exception e) {
-                System.out.println("Error: ");
-                e.printStackTrace();
-            }
 
+            if (packet != null) {
+                System.out.println("[WinTest RX] HELLO from " + packet.getSource());
+                logSyncService.onStationSeen(packet.getSource());
+            }
 
         } else if (msg.startsWith("ADDQSO:")) { //adding qso to wintest log
             try {
 
+                if (packet != null && !packet.getDestination().isEmpty()) {
+                    /*
+                     * A directed ADDQSO is the answer to one of our NEEDQSO
+                     * requests. Tracing it separates a missing answer from a
+                     * failing evaluation of the answer.
+                     */
+                    System.out.println("[WinTest RX] ADDQSO answer from "
+                            + packet.getSource() + " to " + packet.getDestination());
+                }
+
                 parseAddQso(msg);
             } catch (Exception e) {
                 ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "Parsing ERROR: " + Arrays.toString(e.getStackTrace()), true);
@@ -125,8 +239,19 @@ public class ReadUDPByWintestThread extends Thread {
         } else if (msg.startsWith("STATUS")) {
             parseStatus(msg);
 
+            /*
+             * HELLO is only sent when a log is opened, so a listener that was
+             * started later learns about a station from its periodic STATUS.
+             * The configured station-name filter stays a QRG-sync setting: in a
+             * multi-station setup every band station keeps its own log, and all
+             * of them contribute Worked state.
+             */
+            if (packet != null) {
+                logSyncService.onStationSeen(packet.getSource());
+            }
+
         } else if (msg.startsWith("IHAVE:")) { //periodical message of wintest, which qsos are in the log
-//            parseIHave(msg); //TODO
+            parseIHave(packet);
         }
 
         else if (msg.contains(ApplicationConstants.DISCONNECT_RDR_POISONPILL)) {
@@ -140,6 +265,130 @@ public class ReadUDPByWintestThread extends Thread {
         callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
     }
 
+    /**
+     * Hands the periodic Win-Test log inventory to the log synchronization.
+     *
+     * <p>A packet with a broken checksum is discarded here. The run-length
+     * inventory is the last field of an IHAVE packet, so a corrupted packet
+     * would announce QSO ranges that do not exist. The established handling of
+     * the other message types is deliberately left unchanged, because it never
+     * verified the checksum.</p>
+     *
+     * @param packet received IHAVE packet
+     */
+    private void parseIHave(WinTestPacket packet) {
+        if (packet == null) {
+            return;
+        }
+
+        if (packet.isChecksumPresent() && !packet.isChecksumValid()) {
+            System.out.println("[WinTest] IHAVE with invalid checksum ignored");
+            return;
+        }
+
+        String tracedPayload = String.join(" ", packet.getDataTokens());
+        if (!tracedPayload.equals(lastTracedIhaveByStation.put(packet.getSource(), tracedPayload))) {
+            System.out.println("[WinTest RX] IHAVE from " + packet.getSource()
+                    + " to '" + packet.getDestination() + "': " + tracedPayload
+                    + (WinTestIhaveInventory.fromPacket(packet).isEmpty()
+                            ? "  <-- not usable as inventory" : ""));
+        }
+
+        logSyncService.onIhaveReceived(packet);
+    }
+
+    /**
+     * Reports a change of the log-synchronization progress to the controller.
+     */
+    private void reportSyncStateIfChanged() {
+        WinTestLogSyncService.SyncState currentSyncState = logSyncService.getState();
+
+        if (currentSyncState == lastReportedSyncState) {
+            return;
+        }
+
+        lastReportedSyncState = currentSyncState;
+
+        ThreadStateMessage threadStateMessage = new ThreadStateMessage(
+                this.ThreadNickName, true, "log sync: " + currentSyncState, false);
+        callBackToController.onThreadStatus(ThreadNickName, threadStateMessage);
+    }
+
+    /**
+     * Sends a NEEDQSO request as a UDP broadcast.
+     *
+     * <p>The framing follows the wtKST implementation exactly, including the
+     * leading blank of the data part:</p>
+     *
+     * <pre>
+     *   NEEDQSO: "KST4Contest" "STN1"  "STN1@44510" 1 50{checksum}\0
+     * </pre>
+     *
+     * @param targetStation Win-Test station the request is addressed to
+     * @param logId log identity in the form {@code StationName@LogUniqueID}
+     * @param countFrom first requested QSO number
+     * @param countTo last requested QSO number
+     */
+    private void sendNeedQso(String targetStation, String logId, long countFrom, long countTo) {
+        String data = " \"" + logId + "\" " + countFrom + " " + countTo;
+
+        WinTestMessage needQsoMessage = new WinTestMessage(
+                WinTestMessage.MessageType.NEEDQSO,
+                resolveOwnWinTestStationName(),
+                targetStation,
+                data
+        );
+
+        try (DatagramSocket sendSocket = new DatagramSocket()) {
+            sendSocket.setBroadcast(true);
+            sendSocket.setReuseAddress(true);
+
+            byte[] messageBytes = needQsoMessage.toBytes();
+            InetAddress broadcastAddress = addressResolver.resolveBroadcastAddress(
+                    client.getChatPreferences().getLogsynch_wintestNetworkBroadcastAddress());
+            int targetPort = client.getChatPreferences().getLogsynch_wintestNetworkPort();
+
+            sendSocket.send(new DatagramPacket(
+                    messageBytes, messageBytes.length, broadcastAddress, targetPort));
+
+            System.out.println("[WinTest LogSync] NEEDQSO to " + targetStation
+                    + " for " + logId + " " + countFrom + "-" + countTo);
+        } catch (IOException | RuntimeException exception) {
+            System.out.println("[WinTest LogSync] NEEDQSO could not be sent: "
+                    + exception.getMessage());
+        }
+    }
+
+    /**
+     * @return own station name in the Win-Test network, never blank
+     */
+    private String resolveOwnWinTestStationName() {
+        String configuredStationName =
+                client.getChatPreferences().getLogsynch_wintestNetworkStationNameOfKST();
+
+        if (configuredStationName == null || configuredStationName.isBlank()) {
+            return "KST4Contest";
+        }
+
+        return configuredStationName.trim();
+    }
+
+    /**
+     * Checks whether a message type identifies a genuine Win-Test station.
+     *
+     * <p>Internal control messages such as the poison pill must not influence
+     * the address of outgoing Win-Test packets.</p>
+     *
+     * @param messageType message type of a received packet
+     * @return {@code true} for a Win-Test station message
+     */
+    private static boolean isWinTestStationMessage(String messageType) {
+        return "HELLO".equals(messageType)
+                || "STATUS".equals(messageType)
+                || "IHAVE".equals(messageType)
+                || "ADDQSO".equals(messageType);
+    }
+
     /**
      * parsing of the hello message of wintest:
      * "HELLO: "STN1" "" 6667 130 "SLAVE" 1 0 1762201985"
@@ -348,15 +597,6 @@ public class ReadUDPByWintestThread extends Thread {
         }
     }
 
-//    private void send_needqso() throws IOException {
-//        String payload = String.format("NEEDQSO:\"%s\" \"%s\" \"%s\" %d %d?\0",
-//                "DO5AMF", "STN1", stationID, 1, 9999);
-//        InetAddress broadcast = InetAddress.getByName("255.255.255.255");
-//        byte[] bytes = payload.getBytes(StandardCharsets.US_ASCII);
-//        bytes[bytes.length - 2] = util_calculateChecksum((bytes));
-//        socket.send(new DatagramPacket(bytes, bytes.length, broadcast, 9871));
-//    }
-
 //    private void send_hello() throws IOException {
 //        String payload = String.format("HELLO:\"%s\" \"%s\" \"%s\" %d %d?\0",
 //                "DO5AMF", "", stationID, "SLAVE", 1, 14);
@@ -368,33 +608,83 @@ public class ReadUDPByWintestThread extends Thread {
 
 
     /**
-     * Resolves the project Band enum from Win-Test band IDs.
+     * Extracts the unchanged Win-Test band ID from the unquoted ADDQSO fields.
      *
-     * <p>Only bands that exist in the current Band enum are returned. 50/70 MHz are
-     * still represented as worked flags in ChatMember, but they are not part of the
-     * current Reachability/New-Locator band enum.</p>
-     *
-     * @param bandId Win-Test band id from ADDQSO
-     * @return matching Band or null
+     * @param message complete ADDQSO packet
+     * @return raw band ID or an empty value when the field is missing
      */
-    private Band helper_resolveBandFromWinTestBandId(String bandId) {
-        if (bandId == null) {
+    static String extractBandIdFromWinTestAddQso(String message) {
+        if (message == null) {
+            return "";
+        }
+
+        String[] quotedParts = message.split("\"");
+        if (quotedParts.length <= 6) {
+            return "";
+        }
+
+        String unquotedFields = quotedParts[6].trim();
+        if (unquotedFields.isEmpty()) {
+            return "";
+        }
+
+        String[] packetFields = unquotedFields.split("\\s+");
+        return packetFields.length > 3 ? packetFields[3] : "";
+    }
+
+    /**
+     * Builds the log identity of an ADDQSO packet.
+     *
+     * <p>Win-Test numbers the QSOs of every log continuously, so a QSO is only
+     * identified by the combination of the logging station, the unique log ID
+     * and the QSO number. The log ID is the last field of the packet.</p>
+     *
+     * @param packetFields fields of the ADDQSO packet
+     * @return identity in the form {@code StationName@LogUniqueID}, or
+     *         {@code null} when the packet does not carry both values
+     */
+    static String extractLogIdFromWinTestAddQso(List<String> packetFields) {
+        if (packetFields == null || packetFields.size() < ADDQSO_FIELD_COUNT) {
             return null;
         }
 
-        return switch (bandId.trim()) {
-            case "10" -> Band.B_50;
-            case "11" -> Band.B_70;
-            case "12" -> Band.B_144;
-            case "14" -> Band.B_432;
-            case "16" -> Band.B_1296;
-            case "17" -> Band.B_2320;
-            case "18" -> Band.B_3400;
-            case "19" -> Band.B_5760;
-            case "20" -> Band.B_10G;
-            case "21" -> Band.B_24G;
-            default -> null;
-        };
+        String stationName = packetFields.get(ADDQSO_STATION_NAME_INDEX);
+        String logUniqueId = packetFields.get(packetFields.size() - 1);
+
+        if (stationName == null || stationName.isBlank()
+                || logUniqueId == null || logUniqueId.isBlank()) {
+            return null;
+        }
+
+        return stationName.trim() + "@" + logUniqueId.trim();
+    }
+
+    /**
+     * Extracts the Win-Test QSO number of an ADDQSO packet.
+     *
+     * <p>Win-Test sends {@code 0} instead of {@code 1} for the first QSO of a
+     * log in some situations. wtKST corrects that the same way.</p>
+     *
+     * @param packetFields fields of the ADDQSO packet
+     * @return QSO number, or {@code 0} when the packet carries no usable value
+     */
+    static long extractQsoNumberFromWinTestAddQso(List<String> packetFields) {
+        if (packetFields == null || packetFields.size() < ADDQSO_FIELD_COUNT) {
+            return 0L;
+        }
+
+        String rawQsoNumber = packetFields.get(ADDQSO_QSO_NUMBER_INDEX);
+
+        if (rawQsoNumber == null) {
+            return 0L;
+        }
+
+        try {
+            long qsoNumber = Long.parseLong(rawQsoNumber.trim());
+            return qsoNumber <= 0L ? 1L : qsoNumber;
+        } catch (NumberFormatException exception) {
+            return 0L;
+        }
     }
 
     /**
@@ -449,112 +739,53 @@ public class ReadUDPByWintestThread extends Thread {
      * @param msg
      */
     private void parseAddQso(String msg) {
-
-
-        ChatMember modifyThat = null;
-
         try {
-//            int qsoNumber = extractQsoNumber(msg);
-//            receivedQsos.put(qsoNumber, msg);
-//            lastKnownQso = Math.max(lastKnownQso, qsoNumber);
-            String callSignCatched = msg.split("\"") [7];
+            List<String> packetFields = WinTestPacket.tokenize(msg);
+            String logId = extractLogIdFromWinTestAddQso(packetFields);
+            long qsoNumber = extractQsoNumberFromWinTestAddQso(packetFields);
+
+            /*
+             * The QSO number is registered before any validation. Otherwise the
+             * log synchronization would request a QSO with unusable content
+             * over and over again.
+             */
+            boolean isUnknownQso = logSyncService.registerReceivedQso(logId, qsoNumber);
+
+            String[] quotedParts = msg == null ? new String[0] : msg.split("\"");
+            String callSign = quotedParts.length > 7 ? quotedParts[7] : "";
+            String rawBandId = extractBandIdFromWinTestAddQso(msg);
             String locatorFromLogger = helper_resolveLocatorFromWinTestAddQso(msg);
-
-            ChatMember workedCall = new ChatMember();
-            workedCall.setCallSign(callSignCatched);
-            workedCall.setWorked(true); //its worked at this place, for sure!
-
-            if (locatorFromLogger != null) {
-                workedCall.setQra(locatorFromLogger);
+            LoggedQsoBand loggedBand = LoggedQsoBand.fromWinTestBandId(rawBandId);
+            ExternalLoggedQso loggedQso = ExternalLoggedQso.create(
+                    callSign, loggedBand, locatorFromLogger, "WINTEST").orElse(null);
+            if (loggedQso == null) {
+                System.out.println("[WinTestUDPRcvr: warning] ADDQSO without usable callsign ignored");
+                return;
             }
 
-            ArrayList<Integer> markTheseChattersAsWorked = client.checkListForChatMemberIndexesByCallSign(workedCall);
-
-            String bandId;
-            bandId = msg.split("\"")[6].split(" ")[4].trim();
-
-            Band workedBand = helper_resolveBandFromWinTestBandId(bandId);
-            switch (bandId) {
-                case "10" -> workedCall.setWorked50(true);
-                case "11" -> workedCall.setWorked70(true);
-                case "12" -> workedCall.setWorked144(true);
-                case "14" -> workedCall.setWorked432(true);
-                case "16" -> workedCall.setWorked1240(true);
-                case "17" -> workedCall.setWorked2300(true);
-                case "18" -> workedCall.setWorked3400(true);
-                case "19" -> workedCall.setWorked5600(true);
-                case "20" -> workedCall.setWorked10G(true);
-                case "21" -> workedCall.setWorked24G(true);
-                case "22" -> workedCall.setWorked47G(true);
-                case "23" -> workedCall.setWorked76G(true);
-                default -> System.out.println("[WinTestUDPRcvr: warning] Unbekannte Band-ID: " + bandId);
+            if (!isUnknownQso) {
+                /*
+                 * Win-Test resends known QSOs when a NEEDQSO request overlaps
+                 * with QSOs that already arrived as a broadcast. Worked state
+                 * and database entry exist in that case, so repeating the write
+                 * would only cost time during the initial log recovery.
+                 */
+                return;
             }
 
-            if (workedBand != null && locatorFromLogger != null) {
-                this.client.registerWorkedGrossField(workedBand, locatorFromLogger, workedCall, "WINTEST");
+            if (loggedBand == null && !rawBandId.isEmpty()) {
+                System.out.println("[WinTestUDPRcvr: warning] Unknown band ID: " + rawBandId);
             }
 
-            if (!markTheseChattersAsWorked.isEmpty()) {
-                //Worked call is part of the current chatmember list
-
-                for (int index : markTheseChattersAsWorked) {
-                    //iterate through the logged in chatmembers callsigns and set the worked markers
-                    modifyThat = client.getLst_chatMemberList().get(index);
-
-                    modifyThat.setWorked(true); //worked its for sure
-
-                    if (locatorFromLogger != null
-                            && (modifyThat.getQra() == null
-                            || modifyThat.getQra().isBlank()
-                            || "unknown".equalsIgnoreCase(modifyThat.getQra()))) {
-                        modifyThat.setQra(locatorFromLogger);
-                    }
-
-                    if (workedCall.isWorked50()) {
-                        modifyThat.setWorked50(true);
-                    } else if (workedCall.isWorked70()) {
-                        modifyThat.setWorked70(true);
-                    } else if (workedCall.isWorked144()) {
-                        modifyThat.setWorked144(true);
-                    } else if (workedCall.isWorked432()) {
-                        modifyThat.setWorked432(true);
-                    } else if (workedCall.isWorked1240()) {
-                        modifyThat.setWorked1240(true);
-                    } else if (workedCall.isWorked2300()) {
-                        modifyThat.setWorked2300(true);
-                    } else if (workedCall.isWorked3400()) {
-                        modifyThat.setWorked3400(true);
-                    } else if (workedCall.isWorked5600()) {
-                        modifyThat.setWorked5600(true);
-                    } else if (workedCall.isWorked10G()) {
-                        modifyThat.setWorked10G(true);
-                    } else if (workedCall.isWorked24G()) {
-                        modifyThat.setWorked24G(true);
-                    } else if (workedCall.isWorked47G()) {
-                        modifyThat.setWorked47G(true);
-                    } else if (workedCall.isWorked76G()) {
-                        modifyThat.setWorked76G(true);
-                    }   else {
-                        System.out.println("[WinTestUDPRcvr: warning] found no new worked-flag for this band: " + workedCall.getCallSignRaw() + bandId);
-                    }
-                }
-
-                try {
-
-                    GuiUtils.triggerGUIFilteredChatMemberListChange(client); //not clean at all
-
-                    // trigger band-upgrade hint after log entry (Win-Test)
-                    try {
-                        client.onExternalLogEntryReceived(workedCall.getCallSignRaw());
-                    } catch (Exception e) {
-                        System.out.println("[WinTestUDPRcvr, warning]: band-upgrade hint failed: " + e.getMessage());
-                    }
-
-                } catch (Exception IllegalStateException) {
-                    //do nothing, as it works...
-                }
+            ChatMember workedCall = loggedQso.toWorkedChatMember();
+            if (loggedBand != null
+                    && loggedBand.getProjectBand() != null
+                    && locatorFromLogger != null) {
+                this.client.registerWorkedGrossField(
+                        loggedBand.getProjectBand(), locatorFromLogger, workedCall, loggedQso.getSource());
             }
 
+            client.applyExternalLoggedQso(loggedQso);
 
             boolean isInChat = this.client.getDbHandler().updateWkdInfoOnChatMember(workedCall);
             // This will update the worked info on a worked chatmember. DBHandler will
@@ -587,17 +818,9 @@ public class ReadUDPByWintestThread extends Thread {
 
             bufwrtrRawMSGOut = new BufferedWriter(fileWriterPersistUDPToFile);
 
-            if (modifyThat != null) {
-                bufwrtrRawMSGOut.write("\n" + modifyThat.toString());
-                bufwrtrRawMSGOut.flush();
-                bufwrtrRawMSGOut.close();
-
-            } else {
-                bufwrtrRawMSGOut.write("\n" + workedCall.toString());
-                bufwrtrRawMSGOut.flush();
-                bufwrtrRawMSGOut.close();
-
-            }
+            bufwrtrRawMSGOut.write("\n" + workedCall.toString());
+            bufwrtrRawMSGOut.flush();
+            bufwrtrRawMSGOut.close();
 
 
             System.out.println("[WinTest, Info: Marking Chatmember as worked: " + workedCall.toString());

src/main/java/kst4contest/controller/ReadUDPbyUCXMessageThread.java

@@ -3,7 +3,6 @@ package kst4contest.controller;
 import java.io.*;
 import java.net.*;
 import java.sql.SQLException;
-import java.util.ArrayList;
 import java.util.Arrays;
 
 import javax.xml.XMLConstants;
@@ -13,7 +12,6 @@ import javax.xml.parsers.ParserConfigurationException;
 
 import kst4contest.ApplicationConstants;
 import kst4contest.model.ThreadStateMessage;
-import kst4contest.view.GuiUtils;
 import org.w3c.dom.Document;
 import org.w3c.dom.Element;
 import org.w3c.dom.Node;
@@ -132,54 +130,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
 		return WorkedGrossFieldCache.extractLocator6(helper_getOptionalElementText(element, "rcvnr"));
 	}
 
-	/**
-	 * Resolves the project Band enum from logger band values.
-	 *
-	 * @param band logger band text
-	 * @return matching Band or null
-	 */
-	private Band helper_resolveBandFromLoggerBand(String band) {
-		if (band == null) {
-			return null;
-		}
-
-		switch (band.trim()) {
-			case "50":
-			case "6m":
-				return Band.B_50;
-			case "70":
-			case "4m":
-				return Band.B_70;
-			case "144":
-			case "2m":
-				return Band.B_144;
-			case "432":
-			case "70cm":
-				return Band.B_432;
-			case "1240":
-			case "1296":
-			case "23cm":
-				return Band.B_1296;
-			case "2300":
-			case "2320":
-			case "13cm":
-				return Band.B_2320;
-			case "3400":
-			case "9cm":
-				return Band.B_3400;
-			case "5600":
-			case "5760":
-			case "6cm":
-				return Band.B_5760;
-			case "10G":
-			case "10368":
-			case "3cm":
-				return Band.B_10G;
-			default:
-				return null;
-		}
-	}
-
 	public void run() {
 
         System.out.println("ReadUDPByUCXLogThread: started Thread for UCXLog getUDP");
@@ -295,8 +245,6 @@ public class ReadUDPbyUCXMessageThread extends Thread {
 
 		String udpMsg = helper_extractXmlPayload(udpPacketToProcess);
 
-		ChatMember modifyThat = null;
-
         ThreadStateMessage threadStateMessage = new ThreadStateMessage(this.ThreadNickName, true, "received Message\n" + udpMsg, false);
 
         callBackToController.onThreadStatus(ThreadNickName,threadStateMessage);
@@ -342,95 +290,27 @@ public class ReadUDPbyUCXMessageThread extends Thread {
 
 						Element element = (Element) node;
 
-						String call = element.getElementsByTagName("call").item(0).getTextContent();
-						String band = helper_getOptionalElementText(element, "band");
+						String call = helper_getOptionalElementText(element, "call");
+						String rawBand = helper_getOptionalElementText(element, "band");
 						String gridSquare = helper_resolveLocatorFromContactInfo(element);
 						String points = helper_getOptionalElementText(element, "points");
+						LoggedQsoBand loggedBand = LoggedQsoBand.fromLoggerValue(rawBand);
+						ExternalLoggedQso loggedQso = ExternalLoggedQso.create(
+								call, loggedBand, gridSquare, "UCXLOG").orElse(null);
+						if (loggedQso == null) {
+							System.out.println("[ReadUDPFromUCX, warning]: QSO packet without usable callsign ignored");
+							continue;
+						}
 
 						System.out.println("[Readudp, info ]: received Current Element :" + node.getNodeName()
-								+ "call: " + call + " / " + band + " ----> " + points + " POINTS");
+								+ "call: " + call + " / " + rawBand + " ----> " + points + " POINTS");
 
 //						client.getChatPreferences().setBcn_contestScoreSum(Long.parseLong(points));
 
-						ChatMember workedCall = new ChatMember();
-						workedCall.setCallSign(call);
-						workedCall.setWorked(true);
-
-						if (gridSquare != null) {
-							workedCall.setQra(gridSquare);
-						}
-
-						Band workedBand = helper_resolveBandFromLoggerBand(band);
-
-						switch (band) {
-						case "50":
-						case "6m":
-						{
-							workedCall.setWorked50(true);
-							break;
-						}
-
-						case "70":
-						case "4m":
-						{
-							workedCall.setWorked70(true);
-							break;
-						}
-
-						case "144":
-						case "2m": //minos contest logger
-						{
-							workedCall.setWorked144(true);
-							break;
-						}
-
-						case "432":
-						case "70cm":
-							{
-								workedCall.setWorked432(true);
-								break;
-							}
-
-						case "1240": //ucxlog style
-						case "1296": //used for n1mm / Dxlog
-						case "23cm": //minos contest logger
-						{
-							workedCall.setWorked1240(true);
-							break;
-						}
-
-						case "2300":
-						case "13cm":
-							{
-							workedCall.setWorked2300(true);
-							break;
-						}
-
-						case "3400":
-						case "9cm":
-						{
-							workedCall.setWorked3400(true);
-							break;
-						}
-
-						case "5600":
-						case "6cm":
-						{
-							workedCall.setWorked5600(true);
-							break;
-						}
-
-						case "10G":
-						case "3cm":
-						{
-							workedCall.setWorked10G(true);
-                            break;
-						}
-
-
-							default:
-								System.out.println("[ReadUDPFromUCX, Error:] unexpected band value: \"" + band + "\"");
-								break;
+						ChatMember workedCall = loggedQso.toWorkedChatMember();
+						Band workedBand = loggedBand == null ? null : loggedBand.getProjectBand();
+						if (loggedBand == null && !rawBand.isEmpty()) {
+							System.out.println("[ReadUDPFromUCX, warning]: unexpected band value: \"" + rawBand + "\"");
 						}
 
 						{
@@ -444,60 +324,7 @@ public class ReadUDPbyUCXMessageThread extends Thread {
 
 //							asd //TODO: Check if callsign and callsignraw is similar, then mark first and further via new checklistforchatmembermultiplemethod with array of indize
 
-							ArrayList<Integer> markTheseChattersAsWorked = client.checkListForChatMemberIndexesByCallSign(workedCall);
-
-							if (markTheseChattersAsWorked.isEmpty()) {
-								//Worked call is not part of the chatmember list
-							} else {
-								for (int index : markTheseChattersAsWorked) {
-									modifyThat = client.getLst_chatMemberList().get(index);
-
-									modifyThat.setWorked(true);
-
-									if (workedCall.isWorked50()) {
-										modifyThat.setWorked50(true);
-
-									} else if (workedCall.isWorked70()) {
-										modifyThat.setWorked70(true);
-
-									} else if (workedCall.isWorked144()) {
-										modifyThat.setWorked144(true);
-
-									} else if (workedCall.isWorked432()) {
-										modifyThat.setWorked432(true);
-
-									} else if (workedCall.isWorked1240()) {
-										modifyThat.setWorked1240(true);
-
-									} else if (workedCall.isWorked2300()) {
-										modifyThat.setWorked2300(true);
-
-									} else if (workedCall.isWorked3400()) {
-										modifyThat.setWorked3400(true);
-
-									} else if (workedCall.isWorked5600()) {
-										modifyThat.setWorked5600(true);
-
-									} else if (workedCall.isWorked10G()) {
-										modifyThat.setWorked10G(true);
-									}
-								}
-
-								try {
-
-									GuiUtils.triggerGUIFilteredChatMemberListChange(this.client);
-									// BEGIN PATCH: trigger band-upgrade hint after log entry (UCXLog)
-									try {
-										client.onExternalLogEntryReceived(workedCall.getCallSignRaw());
-									} catch (Exception e) {
-										System.out.println("[UCXUDPRcvr, warning]: band-upgrade hint failed: " + e.getMessage());
-									}
-
-
-								} catch (Exception IllegalStateException) {
-									//do nothing, as it works...
-								}
-							}
+							client.applyExternalLoggedQso(loggedQso);
 
 							/**
 							 * old mechanic to markup worked stations in the chatmember table
@@ -574,7 +401,8 @@ public class ReadUDPbyUCXMessageThread extends Thread {
 						}
 
 						if (workedBand != null && gridSquare != null) {
-							this.client.registerWorkedGrossField(workedBand, gridSquare, workedCall, "UCXLOG");
+							this.client.registerWorkedGrossField(
+									workedBand, gridSquare, workedCall, loggedQso.getSource());
 						}
 
 						boolean isInChat = this.client.getDbHandler().updateWkdInfoOnChatMember(workedCall);
@@ -609,17 +437,9 @@ public class ReadUDPbyUCXMessageThread extends Thread {
 
 						bufwrtrRawMSGOut = new BufferedWriter(fileWriterPersistUDPToFile);
 
-						if (modifyThat != null) {
-							bufwrtrRawMSGOut.write("\n" + modifyThat.toString());
-							bufwrtrRawMSGOut.flush();
-							bufwrtrRawMSGOut.close();
-
-						} else {
-							bufwrtrRawMSGOut.write("\n" + workedCall.toString());
-							bufwrtrRawMSGOut.flush();
-							bufwrtrRawMSGOut.close();
-
-						}
+						bufwrtrRawMSGOut.write("\n" + workedCall.toString());
+						bufwrtrRawMSGOut.flush();
+						bufwrtrRawMSGOut.close();
 
 					}
 				}

src/main/java/kst4contest/controller/SkedReminderService.java

@@ -33,6 +33,24 @@ public final class SkedReminderService {
         this.controller = controller;
     }
 
+    /**
+     * Cancels every armed reminder and stops the scheduler thread.
+     *
+     * <p>Called when the runtime that owns this service is torn down, so a discarded
+     * runtime does not keep a thread and pending reminders alive.</p>
+     */
+    public void shutdown() {
+
+        for (List<ScheduledFuture<?>> remindersOfOneCall : scheduledByCallRaw.values()) {
+            for (ScheduledFuture<?> armedReminder : remindersOfOneCall) {
+                armedReminder.cancel(false);
+            }
+        }
+
+        scheduledByCallRaw.clear();
+        scheduler.shutdownNow();
+    }
+
     /**
      * Arms reminders for one sked. Existing reminders for this call are cancelled.
      *

src/main/java/kst4contest/controller/StatusUpdateListener.java

@@ -1,5 +1,7 @@
 package kst4contest.controller;
 
+import java.nio.file.Path;
+
 import kst4contest.model.ThreadStateMessage;
 
 public interface StatusUpdateListener {
@@ -33,4 +35,13 @@ public interface StatusUpdateListener {
         // Optional for non-UI listeners.
     }
 
+    /**
+     * Called after KST4Contest successfully creates a missing Simplelogfile.
+     *
+     * @param filePath absolute path of the newly created file
+     */
+    default void onSimpleLogFileCreated(Path filePath) {
+        // Optional for non-UI listeners.
+    }
+
 }

src/main/java/kst4contest/controller/UCXLogFileToHashsetParser.java

@@ -1,12 +1,13 @@
 package kst4contest.controller;
 
 import java.io.BufferedReader;
-import java.io.File;
-import java.io.FileInputStream;
-import java.io.FileNotFoundException;
 import java.io.IOException;
-import java.io.InputStreamReader;
-import java.util.HashMap;
+import java.nio.charset.Charset;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.util.HashSet;
+import java.util.Locale;
+import java.util.Set;
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 
@@ -14,73 +15,50 @@ import kst4contest.model.ChatMember;
 
 public class UCXLogFileToHashsetParser {
 
-	public BufferedReader fileReader;
-//	private final String PTRN_CallSign = "(([a-zA-Z]{1,2}[\\d{1}]?\\/)?(\\d{1}[a-zA-Z][\\d{1}][a-zA-Z]{1,3})((\\/p)|(\\/\\d))?)|(([a-zA-Z0-9]{1,2}[\\d{1}]?\\/)?(([a-zA-Z]{1,2}(\\d{1}[a-zA-Z]{1,4})))((\\/p)|(\\/\\d))?)"; //OLD, S51AR for example will not work
-	private final String PTRN_CallSign = "(([a-zA-Z]{1,2}[\\d]{1}?\\/)?(\\d{1}[a-zA-Z][\\d]{1}[a-zA-Z]{1,3})((\\/p)|(\\/\\d))?)|(([a-zA-Z0-9]{1,2}[\\d]{1}?\\/)?(([a-zA-Z]{1,2}(\\d{1}[a-zA-Z]{1,4})))((\\/p)|(\\/\\d))?)|([A-Z]\\d{2}[A-Z]{1,3})";
-
+	private static final Pattern CALL_SIGN_PATTERN = Pattern.compile(
+			"(([a-zA-Z]{1,2}[\\d]{1}?\\/)?(\\d{1}[a-zA-Z][\\d]{1}[a-zA-Z]{1,3})((\\/p)|(\\/\\d))?)"
+					+ "|(([a-zA-Z0-9]{1,2}[\\d]{1}?\\/)?(([a-zA-Z]{1,2}(\\d{1}[a-zA-Z]{1,4})))((\\/p)|(\\/\\d))?)"
+					+ "|([A-Z]\\d{2}[A-Z]{1,3})");
 
+	private final Path logFile;
 
 	public UCXLogFileToHashsetParser(String filePathAndName) {
-
-		try {
-			fileReader = new BufferedReader(new InputStreamReader(new FileInputStream(new File(filePathAndName))));
-
-		} catch (FileNotFoundException e) {
-			// TODO Auto-generated catch block
-			e.printStackTrace();
-		}
-
+		this.logFile = Path.of(filePathAndName);
 	}
 
-	/**
-	 * check if a line of the ucxlog-Logfile inhibits a Callsign<br/>
-	 * <b>returns ChatMember = null, if no frequency found</b>
-	 * 
-	 * @param chatMessage
-	 */
-	private ChatMember checkIfLineInhibitsCallSign(String line) {
-
-		Pattern pattern = Pattern.compile(PTRN_CallSign);
-		Matcher matcher = pattern.matcher(line);
-
-		String matchedString = "";
+	private String findLastCallSign(String line) {
+		Matcher matcher = CALL_SIGN_PATTERN.matcher(line);
+		String matchedCallSign = "";
 
 		while (matcher.find()) {
-
-			matchedString = matcher.group();
-//			System.out.println("[UCXLogFile:] Processed worked Callsign from file: " + matchedString);
-
+			matchedCallSign = matcher.group();
 		}
 
-		ChatMember newChatMember = new ChatMember();
-
-		newChatMember.setCallSign(matchedString.toUpperCase());
-
-		return newChatMember;
-
+		return matchedCallSign.toUpperCase(Locale.ROOT);
 	}
 
 	/**
-	 * Parses an ucxlog-live-file (full qualified path given by constructor
-	 * argument), looks by regex for callsigns and builds a hashmap with only one
-	 * entry by callsign
+	 * Parses the selected log file and returns every detected station as a
+	 * normalized base callsign. The reader is closed after each pass so the logging
+	 * application can continue replacing or rotating the file.
+	 *
+	 * @return unique normalized base callsigns found in the file
+	 * @throws IOException if the file cannot be read
 	 */
-	public HashMap<String, String> parse() throws IOException {
+	public Set<String> parse() throws IOException {
+		Set<String> workedBaseCalls = new HashSet<>();
 
-		HashMap<String, String> chatMemberMap = new HashMap();
-
-		String line;
-		while ((line = fileReader.readLine()) != null) {
-//			System.out.println("raw: " + line);
-			ChatMember temp = checkIfLineInhibitsCallSign(line);
-
-			if (temp.getCallSign() != "") {
-				chatMemberMap.put(temp.getCallSign(), temp.getCallSign());
+		try (BufferedReader fileReader = Files.newBufferedReader(logFile, Charset.defaultCharset())) {
+			String line;
+			while ((line = fileReader.readLine()) != null) {
+				String matchedCallSign = findLastCallSign(line);
+				String baseCallSign = ChatMember.normalizeCallSignToBaseCallSign(matchedCallSign);
+				if (baseCallSign != null && !baseCallSign.isBlank()) {
+					workedBaseCalls.add(baseCallSign.toUpperCase(Locale.ROOT));
+				}
 			}
 		}
-//		System.out.println(chatMemberMap.size());
-		return chatMemberMap;
 
+		return workedBaseCalls;
 	}
-
 }

src/main/java/kst4contest/controller/UserActualizationTask.java

@@ -1,325 +1,100 @@
 package kst4contest.controller;
 
-import java.io.File;
 import java.io.IOException;
-import java.util.HashMap;
-import java.util.Iterator;
+import java.nio.file.FileAlreadyExistsException;
+import java.nio.file.Files;
+import java.nio.file.InvalidPathException;
+import java.nio.file.Path;
+import java.util.Set;
 import java.util.TimerTask;
-
-import javafx.collections.ObservableList;
-import kst4contest.model.ChatMember;
-import kst4contest.model.ClusterMessage;
-import kst4contest.view.GuiUtils;
+import java.util.logging.Level;
+import java.util.logging.Logger;
 
 public class UserActualizationTask extends TimerTask {
 
-	private ChatController client;
+	private static final Logger LOGGER = Logger.getLogger(UserActualizationTask.class.getName());
+
+	private final ChatController client;
 
 	public UserActualizationTask(ChatController client) {
-
 		this.client = client;
-
 	}
 
 	@Override
 	public void run() {
-
 		Thread.currentThread().setName("UserActualizationTask");
 
-		/*
-		 * File-based log synchronization is optional. Do not create, open or parse the
-		 * configured file while the feature is disabled.
-		 */
+		try {
+			updateWorkedCallSignsFromFile();
+		} catch (RuntimeException exception) {
+			LOGGER.log(Level.WARNING,
+					"Unexpected failure while updating Worked callsigns from the Simplelogfile; "
+							+ "the periodic task will continue.",
+					exception);
+		}
+	}
+
+	private void updateWorkedCallSignsFromFile() {
 		if (!client.getChatPreferences().isLogsynch_fileBasedWkdCallInterpreterEnabled()) {
 			return;
 		}
 
-//		System.out.println("[Useract: ] Thread runned now");
-
-//		System.out.println("***********************Useract started");
-
-		/**
-		 * ******************************************since here: old mechanic for
-		 * marking worked stations by .ucx-file
-		 */
-
-		HashMap<String, String> fetchedWorkedSet = new HashMap<>();
-//		HashMap<String, String> fetchedWorkedSetUdpBckup = new HashMap<>();
-
-		File f = new File(this.client.getChatPreferences().getLogsynch_fileBasedWkdCallInterpreterFileNameReadOnly());
-		if (!f.exists() && !f.isDirectory()) {
-			try {
-				f.createNewFile();
-			} catch (IOException e) {
-				// TODO Auto-generated catch block
-				e.printStackTrace();
-			}
+		String configuredFileName = client.getChatPreferences()
+				.getLogsynch_fileBasedWkdCallInterpreterFileNameReadOnly();
+		if (configuredFileName == null || configuredFileName.isBlank()) {
+			LOGGER.warning("Cannot read the Simplelogfile because no file is selected.");
+			return;
 		}
 
-		UCXLogFileToHashsetParser getWorkedCallsignsOfUCXLogFile = new UCXLogFileToHashsetParser(
-				this.client.getChatPreferences().getLogsynch_fileBasedWkdCallInterpreterFileNameReadOnly());
+		final Path logFile;
+		try {
+			logFile = Path.of(configuredFileName).toAbsolutePath().normalize();
+		} catch (InvalidPathException exception) {
+			LOGGER.log(Level.WARNING,
+					"Cannot use the configured Simplelogfile path: " + configuredFileName,
+					exception);
+			return;
+		}
+
+		boolean created = createMissingLogFile(logFile);
+		if (!Files.isRegularFile(logFile)) {
+			return;
+		}
 
 		try {
-			fetchedWorkedSet = getWorkedCallsignsOfUCXLogFile.parse();
-
-			System.out.println("USERACT: fetchedWorkedSet size: " + fetchedWorkedSet.size());
-
-		} catch (IOException e) {
-			// TODO Auto-generated catch block
-			e.printStackTrace();
+			Set<String> workedBaseCalls = new UCXLogFileToHashsetParser(logFile.toString()).parse();
+			client.applySimpleLogWorkedBaseCalls(workedBaseCalls);
+			LOGGER.log(Level.FINE,
+					"Read {0} unique base callsigns from Simplelogfile {1}.",
+					new Object[] { workedBaseCalls.size(), logFile });
+		} catch (IOException exception) {
+			LOGGER.log(Level.WARNING, "Cannot read Simplelogfile " + logFile, exception);
 		}
 
-		ObservableList<ChatMember> praktiKSTActiveUserList = this.client.getLst_chatMemberList();
-
-		for (Iterator iterator = praktiKSTActiveUserList.iterator(); iterator.hasNext();) {
-			ChatMember chatMember = (ChatMember) iterator.next();
-
-//			System.out.println(chatMember.getCallSign());
-//			System.out.println("USERACT active user list entries " + praktiKSTActiveUserList.size());
-
-			if (fetchedWorkedSet.containsKey(chatMember.getCallSign())) {
-				chatMember.setWorked(true);
-				System.out.println("[USERACT, info:] marking Chatuser " + chatMember.getCallSign()
-						+ " as worked, based on READONLY-Logfile.");
-			}
-
-//			if (fetchedWorkedSetUdpBckup.containsKey(chatMember.getCallSign())) {
-//				chatMember.setWorked(true);
-//				System.out.println("[USERACT, info:] marking Chatuser " + chatMember.getCallSign() + " as worked, based on UDPLsnBackup-Logfile.");
-//			}
-//			GuiUtils.triggerGUIFilteredChatMemberListChange(this.client); //todo: quick and dirty gui fix
+		if (created) {
+			client.notifySimpleLogFileCreated(logFile);
 		}
-
-		ObservableList<ClusterMessage> praktiKSTClusterList = this.client.getLst_clusterMemberList();
-
-		for (Iterator iterator = praktiKSTClusterList.iterator(); iterator.hasNext();) {
-			ClusterMessage clusterMessage = (ClusterMessage) iterator.next();
-
-			if (fetchedWorkedSet.containsKey(clusterMessage.getReceiver().getCallSign())) {
-				clusterMessage.setReceiverWkd(true);
-				System.out.println("[USERACT, info:] marking Clusterspotted "
-						+ clusterMessage.getReceiver().getCallSign() + " as worked.");
-			}
-
-//			if (fetchedWorkedSetUdpBckup.containsKey(clusterMessage.getReceiver().getCallSign())) {
-//				clusterMessage.setReceiverWkd(true);
-//				System.out.println("[USERACT, info:] marking Clusterspotted "
-//						+ clusterMessage.getReceiver().getCallSign() + " as worked.");
-//			}
-
-		}
-
-		/**
-		 * ******************************************end here: old mechanic for marking
-		 * worked stations by .ucx-file
-		 * 
-		 */
-
-		/**
-		 * ******************************************since here: new mechanic for
-		 * marking worked stations by udp/adif based information
-		 */
-//		HashMap<String, String> fetchedWorkedMap = new HashMap<>();
-//
-//		fetchedWorkedMap = this.client.getMap_ucxLogInfoWorkedCalls();
-
-//		ObservableList<ChatMember> praktiKSTActiveUserList1 = this.client.getLst_chatMemberList();
-//
-//		for (Iterator iterator = praktiKSTActiveUserList.iterator(); iterator.hasNext();) {
-//			ChatMember chatMember = (ChatMember) iterator.next();
-//
-//			if (fetchedWorkedMap.containsKey(chatMember.getCallSign())) {
-//				chatMember.setWorked(true);
-//				System.out.println("[USERACT, info:] marking Chatuser " + chatMember.getCallSign() + " as worked based on UDP Log Info Collector.");
-//			}
-//		}
-
-//		ObservableList<ClusterMessage> praktiKSTClusterList1 = this.client.getLst_clusterMemberList();
-//
-//		for (Iterator iterator = praktiKSTClusterList.iterator(); iterator.hasNext();) {
-//			ClusterMessage clusterMessage = (ClusterMessage) iterator.next();
-//
-//			if (fetchedWorkedMap.containsKey(clusterMessage.getReceiver().getCallSign())) {
-//				clusterMessage.setReceiverWkd(true);
-//				System.out.println("[USERACT, info:] marking Clusterspotted "
-//						+ clusterMessage.getReceiver().getCallSign() + " as worked based on UDP Log Info Collector.");
-//			}
-//
-//		}
-
-//
-//		UCXLogFileToHashsetParser getWorkedCallsignsOfUCXLogFile = new UCXLogFileToHashsetParser(
-//				"C:\\UcxLog\\Logs\\DO5AMF\\DVU322_I.UCX");
-//		try {
-//			fetchedWorkedSet = getWorkedCallsignsOfUCXLogFile.parse();
-//		} catch (IOException e) {
-//			// TODO Auto-generated catch block
-//			e.printStackTrace();
-//		}
-//
-//		ObservableList<ChatMember> praktiKSTActiveUserList = this.client.getLst_chatMemberList();
-//
-//		for (Iterator iterator = praktiKSTActiveUserList.iterator(); iterator.hasNext();) {
-//			ChatMember chatMember = (ChatMember) iterator.next();
-//
-//			if (fetchedWorkedSet.containsKey(chatMember.getCallSign())) {
-//				chatMember.setWorked(true);
-//				System.out.println("[USERACT, info:] marking Chatuser " + chatMember.getCallSign() + " as worked.");
-//			}
-//		}
-//
-//		
-//		ObservableList<ClusterMessage> praktiKSTClusterList = this.client.getLst_clusterMemberList();
-//
-//		for (Iterator iterator = praktiKSTClusterList.iterator(); iterator.hasNext();) {
-//			ClusterMessage clusterMessage = (ClusterMessage) iterator.next();
-//
-//			if (fetchedWorkedSet.containsKey(clusterMessage.getReceiver().getCallSign())) {
-//				clusterMessage.setReceiverWkd(true);
-//				System.out.println("[USERACT, info:] marking Clusterspotted "
-//						+ clusterMessage.getReceiver().getCallSign() + " as worked.");
-//			}
-//
-//		}
-
-		/**
-		 * ******************************************end here: new mechanic for marking
-		 * worked stations by udp/adif based information
-		 * 
-		 */
-
-//		System.out.println("[UserActualizationtask:] Userlist actualization will be performed now. " 
-//		          + LocalDateTime.ofInstant(Instant.ofEpochMilli(scheduledExecutionTime()), 
-//		          ZoneId.systemDefault()));
-
-//		ChatMessage actualizeUserMsg = new ChatMessage();
-//		actualizeUserMsg.setDirectedToServer(true);
-//		actualizeUserMsg.setMessage("/show users");
-
-//		client.getMessageTXBus().add(actualizeUserMsg);
-
-//		Enumeration<String> e = this.client.getChatMemberTable().keys();
-//
-//		while (e.hasMoreElements()) {
-//			String key = e.nextElement();
-//
-//			System.out.println(this.client.getChatMemberTable().get(key).getCallSign() + ", "
-//					+ this.client.getChatMemberTable().get(key).getQra() + ": "
-//					+ this.client.getChatMemberTable().get(key).getFrequency());
-//
-//		}
-
-//		System.out.println("[UserAct]: Show the Cluster with known frequencies now: ");
-//
-//		Enumeration<String> e2 = this.client.getdXClusterMemberTable().keys();
-//
-//		while (e2.hasMoreElements()) {
-//			String key = e2.nextElement();
-//
-//			System.out.println(this.client.getdXClusterMemberTable().get(key).getCallSign() + ", "
-//					+ this.client.getdXClusterMemberTable().get(key).getQra() + ": "
-//					+ this.client.getdXClusterMemberTable().get(key).getFrequency());
-//
-//		}
-
-//		for (int i = 0; i < 100; i++) {
-//			
-//			System.out.print("\n");  
-//		}
-
-		/**
-		 * keeepalive start
-		 */
-//		ChatMessage keepAliveMSG = new ChatMessage();
-//		keepAliveMSG.setMessageText("\r");
-//		keepAliveMSG.setMessageDirectedToServer(true);
-//
-//		System.out.println(new Utils4KST().time_generateCurrentMMDDhhmmTimeString() + " [UserAct]: Sending keepalive: "
-//				+ keepAliveMSG.getMessageText());
-//		/**
-//		 * Sending keepalive
-//		 */
-//		this.client.getMessageTXBus().add(keepAliveMSG);
-
-		/**
-		 * keeepalive end
-		 */
-
-//		System.out.println("[UserAct]: Show the Userlist with known frequencies sorted now: ");
-
-//		ObservableList<ChatMember> userlist = this.client.getLst_chatMemberList();
-
-//		for (Iterator iterator = userlist.iterator(); iterator.hasNext();) {
-//			ChatMember chatMember = (ChatMember) iterator.next();
-//			System.out.println("[Useract] Entry " + this.client.getLst_chatMemberList().indexOf(chatMember) + ": " + chatMember.getCallSign()); 
-//		}
-
-//
-//		String chatMembers ="";
-
-//		SortedSet<String> keys = new TreeSet<>(this.client.getChatMemberTable().keySet());
-//		for (String key : keys) {
-//			
-//			chatMembers += this.client.getChatMemberTable().get(key).getCallSign() + ", "
-//					+ this.client.getChatMemberTable().get(key).getName() + " in "
-//					+ this.client.getChatMemberTable().get(key).getQra() + " @ QRG: "
-//					+ this.client.getChatMemberTable().get(key).getFrequency() + "\n";
-//					
-//			System.out.println(this.client.getChatMemberTable().get(key).getCallSign() + ", "
-//					+ this.client.getChatMemberTable().get(key).getName() + " in "
-//					+ this.client.getChatMemberTable().get(key).getQra() + " @ QRG: "
-//					+ this.client.getChatMemberTable().get(key).getFrequency());
-//		}
-
-//		System.out.println("\n[UserAct]: Show the Clusterlist with known frequencies sorted now: ");
-
-//		String dxcMembers ="";
-
-//		SortedSet<String> keys2 = new TreeSet<>(this.client.getdXClusterMemberTable().keySet());
-//		for (String key : keys2) {
-//			System.out.println(this.client.getdXClusterMemberTable().get(key).getCallSign() + " in "
-//					+ this.client.getdXClusterMemberTable().get(key).getQra() + " @ QRG: "
-//					+ this.client.getdXClusterMemberTable().get(key).getFrequency());
-//			
-//			dxcMembers += this.client.getdXClusterMemberTable().get(key).getCallSign() + " in "
-//					+ this.client.getdXClusterMemberTable().get(key).getQra() + " @ QRG: "
-//					+ this.client.getdXClusterMemberTable().get(key).getFrequency();
-//			
-//		}
-
-//		File userListLogger = new File(new Utils4KST().time_generateCurrentMMddString() + "_praktiKST_userlist.txt");
-//
-//		FileWriter fileWriterRAWChatMSGOut = null;
-//		
-//		try {
-//			fileWriterRAWChatMSGOut = new FileWriter(userListLogger, true);
-//		} catch (IOException e1) {
-//			// TODO Auto-generated catch block
-//			e1.printStackTrace();
-//		}
-//
-//		BufferedWriter bufwrtrRawMSGOut;
-//		
-//		bufwrtrRawMSGOut = new BufferedWriter(fileWriterRAWChatMSGOut);
-
-//		System.out.println("#######################################" + chatMembers);
-//		try {
-//			bufwrtrRawMSGOut.write(new Utils4KST().time_generateCurrentMMDDhhmmTimeString() + " " +this.client.getChatMemberTable().size() + " Chatmembers:\n" + chatMembers+ "\n");
-//			bufwrtrRawMSGOut.write(new Utils4KST().time_generateCurrentMMDDhhmmTimeString() + " " + this.client.getdXClusterMemberTable().size() + " Clusterentries:\n" + dxcMembers + "\n");
-
-//			bufwrtrRawMSGOut.flush();
-
-//		} catch (IOException e) {
-//			// TODO Auto-generated catch block
-//			e.printStackTrace();
-//		}
-
-//		try {
-//			bufwrtrRawMSGOut.close();
-//		} catch (IOException e) {
-		// TODO Auto-generated catch block
-//			e.printStackTrace();
-//		}
 	}
 
+	private boolean createMissingLogFile(Path logFile) {
+		if (Files.exists(logFile)) {
+			if (!Files.isRegularFile(logFile)) {
+				LOGGER.log(Level.WARNING,
+						"The selected Simplelogfile path is not a regular file: {0}",
+						logFile);
+			}
+			return false;
+		}
+
+		try {
+			Files.createFile(logFile);
+			LOGGER.log(Level.INFO, "Created missing Simplelogfile {0}.", logFile);
+			return true;
+		} catch (FileAlreadyExistsException exception) {
+			return false;
+		} catch (IOException | SecurityException exception) {
+			LOGGER.log(Level.WARNING, "Cannot create Simplelogfile " + logFile, exception);
+			return false;
+		}
+	}
 }

src/main/java/kst4contest/controller/WinTestIhaveInventory.java

@@ -0,0 +1,217 @@
+package kst4contest.controller;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+import java.util.Optional;
+
+/**
+ * Inventory of one Win-Test log, transported in an {@code IHAVE} packet.
+ *
+ * <p>Win-Test announces which QSO numbers of a log a station currently holds.
+ * To keep the packet short the inventory is run-length encoded:</p>
+ *
+ * <pre>
+ *   IHAVE: "Shack" "" "Shack@9" E 1 1 911-1-117
+ *                     ^logId    ^  ^ ^ ^run lengths
+ *                            origin | initial state
+ *                                   first row
+ * </pre>
+ *
+ * <p>The run lengths alternate between present and missing QSOs, starting with
+ * the state given by {@code InitialState} at QSO number {@code FirstRow}. The
+ * example above therefore means: QSOs 1 to 911 are present, QSO 912 is missing
+ * and QSOs 913 to 1029 are present again.</p>
+ *
+ * <p>Unlike the wtKST implementation this parser honours {@code FirstRow}
+ * instead of assuming that every inventory starts at QSO number one. Win-Test
+ * splits long inventories into several packets, and a split inventory starts at
+ * a higher first row.</p>
+ */
+public final class WinTestIhaveInventory {
+
+	/** Where the sending station got the log from. */
+	public enum Origin {
+		/** The station owns the log or the operator is logged on there. */
+		OWNER,
+		/** The station only mirrors a log owned by somebody else. */
+		LOGGED_ELSE
+	}
+
+	/** Protects against endless loops caused by a corrupted run-length chain. */
+	private static final int MAX_SEGMENTS = 512;
+
+	private static final int EXPECTED_FIELD_COUNT = 5;
+
+	private final String logId;
+	private final Origin origin;
+	private final List<WinTestLogSegment> segments;
+
+	private WinTestIhaveInventory(String logId, Origin origin, List<WinTestLogSegment> segments) {
+		this.logId = logId;
+		this.origin = origin;
+		this.segments = segments;
+	}
+
+	/**
+	 * Parses an {@code IHAVE} packet.
+	 *
+	 * @param packet received packet
+	 * @return inventory, or an empty value when the packet is not a usable
+	 *         {@code IHAVE} announcement
+	 */
+	public static Optional<WinTestIhaveInventory> fromPacket(WinTestPacket packet) {
+		if (packet == null || !"IHAVE".equals(packet.getMessageType())) {
+			return Optional.empty();
+		}
+
+		List<String> fields = packet.getDataTokens();
+		if (fields.size() != EXPECTED_FIELD_COUNT) {
+			/*
+			 * Win-Test versions before 1.29 use a shorter IHAVE format without
+			 * run-length encoding. It carries no usable range information, so
+			 * the blind fallback of the sync service has to take over.
+			 */
+			return Optional.empty();
+		}
+
+		String parsedLogId = fields.get(0) == null ? "" : fields.get(0).trim();
+		if (parsedLogId.isEmpty()) {
+			return Optional.empty();
+		}
+
+		Origin parsedOrigin = parseOrigin(fields.get(1));
+
+		long firstRow = parseUnsignedValue(fields.get(2));
+		long initialState = parseUnsignedValue(fields.get(3));
+
+		if (firstRow < 1L || initialState < 0L || initialState > 1L) {
+			return Optional.empty();
+		}
+
+		List<WinTestLogSegment> parsedSegments =
+				parseRunLengths(fields.get(4), firstRow, initialState == 1L);
+
+		if (parsedSegments == null) {
+			return Optional.empty();
+		}
+
+		return Optional.of(new WinTestIhaveInventory(parsedLogId, parsedOrigin, parsedSegments));
+	}
+
+	private static Origin parseOrigin(String rawOrigin) {
+		if (rawOrigin == null) {
+			return Origin.OWNER;
+		}
+
+		String normalizedOrigin = rawOrigin.trim().toUpperCase(java.util.Locale.ROOT);
+		if ("E".equals(normalizedOrigin) || "LOGGEDELSE".equals(normalizedOrigin)) {
+			return Origin.LOGGED_ELSE;
+		}
+		return Origin.OWNER;
+	}
+
+	/**
+	 * Expands the hyphen-separated run lengths into ranges.
+	 *
+	 * @param rawRunLengths run-length chain such as {@code 911-1-117}
+	 * @param firstRow QSO number the first run starts at
+	 * @param startsPresent {@code true} when the first run describes present QSOs
+	 * @return ranges of present QSOs, or {@code null} for an unusable chain
+	 */
+	private static List<WinTestLogSegment> parseRunLengths(
+			String rawRunLengths,
+			long firstRow,
+			boolean startsPresent
+	) {
+		if (rawRunLengths == null || rawRunLengths.isBlank()) {
+			return null;
+		}
+
+		String[] runLengths = rawRunLengths.trim().split("-");
+
+		/*
+		 * A chain that starts with present QSOs has to end with a present run,
+		 * so its length is odd. A chain that starts with missing QSOs needs an
+		 * even length for the same reason.
+		 */
+		if (startsPresent) {
+			if (runLengths.length % 2 == 0) {
+				return null;
+			}
+		} else if (runLengths.length % 2 == 1 || runLengths.length < 2) {
+			return null;
+		}
+
+		List<WinTestLogSegment> parsedSegments = new ArrayList<>();
+		long cursor = firstRow;
+		boolean present = startsPresent;
+
+		for (String runLength : runLengths) {
+			long count = parseUnsignedValue(runLength);
+			if (count < 0L) {
+				return null;
+			}
+
+			if (present && count > 0L) {
+				if (parsedSegments.size() >= MAX_SEGMENTS) {
+					return null;
+				}
+				parsedSegments.add(new WinTestLogSegment(cursor, cursor + count - 1L));
+			}
+
+			cursor += count;
+			present = !present;
+		}
+
+		return parsedSegments;
+	}
+
+	private static long parseUnsignedValue(String rawValue) {
+		if (rawValue == null) {
+			return -1L;
+		}
+
+		try {
+			return Long.parseLong(rawValue.trim());
+		} catch (NumberFormatException exception) {
+			return -1L;
+		}
+	}
+
+	/**
+	 * @return log identity in the form {@code StationName@LogUniqueID}
+	 */
+	public String getLogId() {
+		return logId;
+	}
+
+	public Origin getOrigin() {
+		return origin;
+	}
+
+	/**
+	 * @return ranges of QSO numbers the announcing station holds
+	 */
+	public List<WinTestLogSegment> getSegments() {
+		return Collections.unmodifiableList(segments);
+	}
+
+	/**
+	 * @return highest announced QSO number, or {@code 0} for an empty inventory
+	 */
+	public long getHighestQsoNumber() {
+		long highestQsoNumber = 0L;
+		for (WinTestLogSegment segment : segments) {
+			if (segment.getCountTo() > highestQsoNumber) {
+				highestQsoNumber = segment.getCountTo();
+			}
+		}
+		return highestQsoNumber;
+	}
+
+	@Override
+	public String toString() {
+		return logId + " " + origin + " " + segments;
+	}
+}

src/main/java/kst4contest/controller/WinTestLogSegment.java

@@ -0,0 +1,60 @@
+package kst4contest.controller;
+
+/**
+ * Consecutive range of Win-Test QSO numbers inside one log.
+ *
+ * <p>Win-Test numbers the QSOs of every log continuously. The {@code IHAVE}
+ * inventory of a log is therefore expressed as a list of ranges that are
+ * present in that log. A range is inclusive on both ends.</p>
+ */
+public final class WinTestLogSegment {
+
+	private final long countFrom;
+	private final long countTo;
+
+	/**
+	 * @param countFrom first QSO number of the range
+	 * @param countTo last QSO number of the range
+	 */
+	public WinTestLogSegment(long countFrom, long countTo) {
+		this.countFrom = countFrom;
+		this.countTo = countTo;
+	}
+
+	public long getCountFrom() {
+		return countFrom;
+	}
+
+	public long getCountTo() {
+		return countTo;
+	}
+
+	/**
+	 * @return number of QSOs covered by this range, never negative
+	 */
+	public long getCount() {
+		return countTo < countFrom ? 0L : countTo - countFrom + 1L;
+	}
+
+	@Override
+	public boolean equals(Object other) {
+		if (this == other) {
+			return true;
+		}
+		if (!(other instanceof WinTestLogSegment)) {
+			return false;
+		}
+		WinTestLogSegment otherSegment = (WinTestLogSegment) other;
+		return countFrom == otherSegment.countFrom && countTo == otherSegment.countTo;
+	}
+
+	@Override
+	public int hashCode() {
+		return Long.hashCode(countFrom) * 31 + Long.hashCode(countTo);
+	}
+
+	@Override
+	public String toString() {
+		return countFrom + "-" + countTo;
+	}
+}

src/main/java/kst4contest/controller/WinTestLogSyncService.java

@@ -0,0 +1,611 @@
+package kst4contest.controller;
+
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.LinkedHashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.NavigableSet;
+import java.util.Optional;
+import java.util.TreeSet;
+import java.util.function.LongSupplier;
+import java.util.function.Supplier;
+
+/**
+ * Recovers the part of a Win-Test log that was written before KST4Contest was
+ * started.
+ *
+ * <p>Win-Test broadcasts every new QSO as an {@code ADDQSO} packet. A client
+ * that joins the network later never sees the QSOs logged before it started, so
+ * stations already worked would still be shown as not worked. Win-Test also
+ * offers a pull mechanism for exactly this situation, and this service is the
+ * port of the wtKST {@code WtLogSync} implementation of it:</p>
+ *
+ * <ol>
+ *     <li>a Win-Test station announces itself with {@code HELLO} or, if its log
+ *         was opened before we started listening, with its periodic
+ *         {@code STATUS};</li>
+ *     <li>its periodic {@code IHAVE} packets announce which QSO numbers of
+ *         which log it holds;</li>
+ *     <li>missing ranges are requested with {@code NEEDQSO}, at most
+ *         {@value #MAX_QSOS_PER_REQUEST} QSOs per request;</li>
+ *     <li>Win-Test answers with ordinary {@code ADDQSO} packets that are
+ *         addressed to us instead of being broadcast.</li>
+ * </ol>
+ *
+ * <p>Because the answers are ordinary {@code ADDQSO} packets, the recovered
+ * QSOs run through the same Worked handling as live QSOs. This service only
+ * decides what still has to be requested; it neither touches the database nor
+ * the user interface.</p>
+ *
+ * <p>If a station is known but no usable {@code IHAVE} inventory arrives within
+ * {@value #INVENTORY_GRACE_PERIOD_MS} ms, a blind fallback requests fixed
+ * blocks starting at QSO number one until a block stays unanswered. That covers
+ * Win-Test versions whose {@code IHAVE} format carries no run lengths.</p>
+ *
+ * <p>Deviation from wtKST: wtKST discards its whole QSO table whenever a
+ * {@code HELLO} arrives, because it displays that table. KST4Contest only
+ * accumulates Worked state, where a stale entry is harmless while a discarded
+ * one would cause the complete log to be requested and written again. The log
+ * identity {@code StationName@LogUniqueID} already changes when Win-Test opens
+ * a different log, so nothing is cleared here.</p>
+ */
+public class WinTestLogSyncService {
+
+	/** Win-Test answers at most this many QSOs for one NEEDQSO request. */
+	static final int MAX_QSOS_PER_REQUEST = 50;
+
+	/** Time after which an unanswered request is retried elsewhere. */
+	static final long REQUEST_TIMEOUT_MS = 5000L;
+
+	/** Shortest distance between two evaluations without a pending trigger. */
+	static final long TICK_INTERVAL_MS = 2000L;
+
+	/** Waiting time for a usable IHAVE before the blind fallback starts. */
+	static final long INVENTORY_GRACE_PERIOD_MS = 15000L;
+
+	/** Upper bound for the blind fallback, equals 10000 QSOs. */
+	static final int MAX_BLIND_BLOCKS = 200;
+
+	/** Guards the gap search against a corrupted inventory. */
+	private static final long MAX_SCANNED_QSO_NUMBERS = 200000L;
+
+	/**
+	 * Sends a NEEDQSO request to a Win-Test station.
+	 */
+	@FunctionalInterface
+	public interface NeedQsoSender {
+
+		/**
+		 * @param targetStation Win-Test station name the request is sent to
+		 * @param logId log identity in the form {@code StationName@LogUniqueID}
+		 * @param countFrom first requested QSO number
+		 * @param countTo last requested QSO number
+		 */
+		void sendNeedQso(String targetStation, String logId, long countFrom, long countTo);
+	}
+
+	/** Progress of the log recovery, used for status reporting. */
+	public enum SyncState {
+		/** No Win-Test station seen yet. */
+		IDLE,
+		/** A station is known, but nothing has been requested yet. */
+		STATION_DETECTED,
+		/** QSOs are being requested. */
+		SYNCING,
+		/** Everything announced by the known stations has been received. */
+		IN_SYNC
+	}
+
+	private final NeedQsoSender needQsoSender;
+	private final Supplier<String> ownStationNameSupplier;
+	private final LongSupplier clock;
+
+	/** Inventories per Win-Test station, keyed by log identity. */
+	private final Map<String, Map<String, WinTestIhaveInventory>> inventoriesByStation =
+			new LinkedHashMap<>();
+
+	/** QSO numbers already received, keyed by log identity. */
+	private final Map<String, NavigableSet<Long>> receivedQsoNumbersByLogId = new HashMap<>();
+
+	/** State of the blind fallback, keyed by log identity. */
+	private final Map<String, BlindScan> blindScansByLogId = new LinkedHashMap<>();
+
+	private PendingRequest pendingRequest;
+	private long firstStationSeenAtMs;
+	private boolean usableInventorySeen;
+	private long lastTickMs;
+	private boolean tickDueImmediately;
+	private SyncState state = SyncState.IDLE;
+
+	/**
+	 * @param needQsoSender transport used for NEEDQSO requests
+	 * @param ownStationNameSupplier own Win-Test station name, read late because
+	 *                               it can be changed in the settings at runtime
+	 */
+	public WinTestLogSyncService(
+			NeedQsoSender needQsoSender,
+			Supplier<String> ownStationNameSupplier
+	) {
+		this(needQsoSender, ownStationNameSupplier, System::currentTimeMillis);
+	}
+
+	/**
+	 * @param needQsoSender transport used for NEEDQSO requests
+	 * @param ownStationNameSupplier own Win-Test station name
+	 * @param clock time source in milliseconds
+	 */
+	WinTestLogSyncService(
+			NeedQsoSender needQsoSender,
+			Supplier<String> ownStationNameSupplier,
+			LongSupplier clock
+	) {
+		this.needQsoSender = needQsoSender;
+		this.ownStationNameSupplier = ownStationNameSupplier;
+		this.clock = clock;
+	}
+
+	/**
+	 * Registers a Win-Test station seen in a HELLO or STATUS packet.
+	 *
+	 * @param stationName Win-Test station name
+	 */
+	public synchronized void onStationSeen(String stationName) {
+		if (stationName == null || stationName.isBlank()) {
+			return;
+		}
+
+		String normalizedStationName = stationName.trim();
+		if (normalizedStationName.equalsIgnoreCase(resolveOwnStationName())) {
+			// our own packets, nothing to synchronize from
+			return;
+		}
+
+		if (inventoriesByStation.putIfAbsent(normalizedStationName, new LinkedHashMap<>()) == null) {
+			tickDueImmediately = true;
+		}
+
+		if (firstStationSeenAtMs == 0L) {
+			firstStationSeenAtMs = clock.getAsLong();
+		}
+
+		if (state == SyncState.IDLE) {
+			state = SyncState.STATION_DETECTED;
+		}
+	}
+
+	/**
+	 * Takes over the inventory of an IHAVE packet.
+	 *
+	 * @param packet received IHAVE packet
+	 */
+	public synchronized void onIhaveReceived(WinTestPacket packet) {
+		if (packet == null || !packet.isAddressedTo(resolveOwnStationName())) {
+			return;
+		}
+
+		Optional<WinTestIhaveInventory> parsedInventory = WinTestIhaveInventory.fromPacket(packet);
+		if (parsedInventory.isEmpty()) {
+			return;
+		}
+
+		WinTestIhaveInventory inventory = parsedInventory.get();
+		onStationSeen(packet.getSource());
+
+		Map<String, WinTestIhaveInventory> stationInventories =
+				inventoriesByStation.get(packet.getSource() == null ? "" : packet.getSource().trim());
+
+		if (stationInventories == null) {
+			return;
+		}
+
+		WinTestIhaveInventory previousInventory =
+				stationInventories.put(inventory.getLogId(), inventory);
+
+		if (previousInventory == null
+				|| !previousInventory.getSegments().equals(inventory.getSegments())) {
+			System.out.println("[WinTest LogSync] inventory of " + inventory.getLogId()
+					+ " from " + packet.getSource()
+					+ " (" + inventory.getOrigin() + "): " + inventory.getSegments());
+		}
+
+		usableInventorySeen = true;
+		blindScansByLogId.remove(inventory.getLogId());
+		tickDueImmediately = true;
+	}
+
+	/**
+	 * Registers a QSO received in an ADDQSO packet.
+	 *
+	 * @param logId log identity in the form {@code StationName@LogUniqueID}
+	 * @param qsoNumber Win-Test QSO number inside that log
+	 * @return {@code true} when this QSO was not known before, and therefore
+	 *         still has to be applied to Worked state and database
+	 */
+	public synchronized boolean registerReceivedQso(String logId, long qsoNumber) {
+		if (logId == null || logId.isBlank() || qsoNumber <= 0L) {
+			// without a usable identity the QSO cannot be deduplicated
+			return true;
+		}
+
+		NavigableSet<Long> receivedQsoNumbers =
+				receivedQsoNumbersByLogId.computeIfAbsent(logId.trim(), key -> new TreeSet<>());
+		boolean isNewQso = receivedQsoNumbers.add(qsoNumber);
+
+		if (pendingRequest != null
+				&& pendingRequest.logId.equals(logId.trim())
+				&& qsoNumber >= pendingRequest.countFrom
+				&& qsoNumber <= pendingRequest.countTo) {
+
+			pendingRequest.answeredQsoCount++;
+
+			if (qsoNumber == pendingRequest.countTo
+					|| pendingRequest.answeredQsoCount >= pendingRequest.getRequestedQsoCount()) {
+				PendingRequest completedRequest = pendingRequest;
+				pendingRequest = null;
+				if (completedRequest.blind) {
+					finishBlindBlock(completedRequest);
+				}
+				tickDueImmediately = true;
+			}
+		}
+
+		return isNewQso;
+	}
+
+	/**
+	 * Advances the recovery. Called after every received packet and on every
+	 * receive timeout of the listener; an internal interval keeps the actual
+	 * work rare while a satisfied request triggers the next one immediately.
+	 */
+	public synchronized void tick() {
+		long now = clock.getAsLong();
+
+		if (!tickDueImmediately && now - lastTickMs < TICK_INTERVAL_MS) {
+			return;
+		}
+
+		lastTickMs = now;
+		tickDueImmediately = false;
+
+		if (pendingRequest != null) {
+			if (now - pendingRequest.sentAtMs < REQUEST_TIMEOUT_MS) {
+				return;
+			}
+			handlePendingTimeout();
+			return;
+		}
+
+		if (requestNextMissingRange(now)) {
+			return;
+		}
+
+		if (requestNextBlindBlock(now)) {
+			return;
+		}
+
+		if (state == SyncState.SYNCING) {
+			state = SyncState.IN_SYNC;
+		}
+	}
+
+	/**
+	 * @return current progress of the recovery
+	 */
+	public synchronized SyncState getState() {
+		return state;
+	}
+
+	/**
+	 * @return number of QSO numbers known for the given log
+	 */
+	synchronized int getKnownQsoCount(String logId) {
+		NavigableSet<Long> receivedQsoNumbers = receivedQsoNumbersByLogId.get(logId);
+		return receivedQsoNumbers == null ? 0 : receivedQsoNumbers.size();
+	}
+
+	private void handlePendingTimeout() {
+		PendingRequest timedOutRequest = pendingRequest;
+		pendingRequest = null;
+
+		if (timedOutRequest.blind) {
+			finishBlindBlock(timedOutRequest);
+			return;
+		}
+
+		String alternativeStation =
+				findAlternativeStation(timedOutRequest.logId, timedOutRequest.targetStation);
+
+		System.out.println("[WinTest LogSync] no answer from " + timedOutRequest.targetStation
+				+ " for " + timedOutRequest.logId + " "
+				+ timedOutRequest.countFrom + "-" + timedOutRequest.countTo);
+
+		if (alternativeStation != null) {
+			sendRequest(
+					alternativeStation,
+					timedOutRequest.logId,
+					timedOutRequest.countFrom,
+					timedOutRequest.countTo,
+					false,
+					clock.getAsLong()
+			);
+			return;
+		}
+
+		/*
+		 * Nobody else holds this log. The silent station is dropped and returns
+		 * with its next STATUS or IHAVE packet.
+		 */
+		System.out.println("[WinTest LogSync] dropping silent station "
+				+ timedOutRequest.targetStation + ", waiting for its next STATUS or IHAVE");
+		inventoriesByStation.remove(timedOutRequest.targetStation);
+		tickDueImmediately = true;
+	}
+
+	private String findAlternativeStation(String logId, String excludedStation) {
+		for (Map.Entry<String, Map<String, WinTestIhaveInventory>> station
+				: inventoriesByStation.entrySet()) {
+
+			if (station.getKey().equals(excludedStation)) {
+				continue;
+			}
+			if (station.getValue().containsKey(logId)) {
+				return station.getKey();
+			}
+		}
+		return null;
+	}
+
+	/**
+	 * Looks for the first announced QSO range that is still missing and
+	 * requests it. Stations that own a log are preferred over stations that
+	 * only mirror it.
+	 *
+	 * @param now current time in milliseconds
+	 * @return {@code true} when a request was sent
+	 */
+	private boolean requestNextMissingRange(long now) {
+		for (int pass = 0; pass < 2; pass++) {
+			boolean preferOwner = pass == 0;
+
+			for (Map.Entry<String, Map<String, WinTestIhaveInventory>> station
+					: new ArrayList<>(inventoriesByStation.entrySet())) {
+
+				for (WinTestIhaveInventory inventory : new ArrayList<>(station.getValue().values())) {
+					boolean isOwner = inventory.getOrigin() == WinTestIhaveInventory.Origin.OWNER;
+					if (preferOwner != isOwner) {
+						continue;
+					}
+
+					long[] missingRange = findMissingRange(
+							inventory.getSegments(),
+							receivedQsoNumbersByLogId.get(inventory.getLogId())
+					);
+
+					if (missingRange == null) {
+						continue;
+					}
+
+					sendRequest(
+							station.getKey(),
+							inventory.getLogId(),
+							missingRange[0],
+							missingRange[1],
+							false,
+							now
+					);
+					return true;
+				}
+			}
+		}
+		return false;
+	}
+
+	/**
+	 * Determines the next missing QSO range of one log.
+	 *
+	 * <p>wtKST compares its own segment list against the announced one and
+	 * derives the request bounds from the segment indices. Searching the gap
+	 * directly produces the same ranges for the ordinary cases, cannot run past
+	 * the end of either list, and never asks for QSO numbers that are already
+	 * known.</p>
+	 *
+	 * @param segments ranges announced by the station
+	 * @param receivedQsoNumbers QSO numbers already received for this log
+	 * @return first missing range as {@code {countFrom, countTo}}, or
+	 *         {@code null} when nothing is missing
+	 */
+	static long[] findMissingRange(
+			List<WinTestLogSegment> segments,
+			NavigableSet<Long> receivedQsoNumbers
+	) {
+		if (segments == null) {
+			return null;
+		}
+
+		long remainingScanBudget = MAX_SCANNED_QSO_NUMBERS;
+
+		for (WinTestLogSegment segment : segments) {
+			for (long qsoNumber = segment.getCountFrom();
+					qsoNumber <= segment.getCountTo();
+					qsoNumber++) {
+
+				remainingScanBudget--;
+				if (remainingScanBudget < 0L) {
+					return null;
+				}
+
+				if (receivedQsoNumbers != null && receivedQsoNumbers.contains(qsoNumber)) {
+					continue;
+				}
+
+				long countFrom = qsoNumber;
+				long countTo = countFrom;
+
+				while (countTo < segment.getCountTo()
+						&& countTo - countFrom + 1L < MAX_QSOS_PER_REQUEST
+						&& (receivedQsoNumbers == null || !receivedQsoNumbers.contains(countTo + 1L))) {
+					countTo++;
+				}
+
+				return new long[] { countFrom, countTo };
+			}
+		}
+
+		return null;
+	}
+
+	/**
+	 * Requests the next fixed block of a log whose station never sent a usable
+	 * inventory.
+	 *
+	 * @param now current time in milliseconds
+	 * @return {@code true} when a request was sent
+	 */
+	private boolean requestNextBlindBlock(long now) {
+		if (usableInventorySeen || firstStationSeenAtMs == 0L) {
+			return false;
+		}
+		if (now - firstStationSeenAtMs < INVENTORY_GRACE_PERIOD_MS) {
+			return false;
+		}
+
+		for (String logId : new ArrayList<>(receivedQsoNumbersByLogId.keySet())) {
+			BlindScan blindScan = blindScansByLogId.computeIfAbsent(logId, key -> new BlindScan());
+
+			if (blindScan.completed || blindScan.requestedBlockCount >= MAX_BLIND_BLOCKS) {
+				continue;
+			}
+
+			String targetStation = resolveStationForLogId(logId);
+			if (targetStation == null) {
+				continue;
+			}
+
+			blindScan.requestedBlockCount++;
+			sendRequest(
+					targetStation,
+					logId,
+					blindScan.nextCountFrom,
+					blindScan.nextCountFrom + MAX_QSOS_PER_REQUEST - 1L,
+					true,
+					now
+			);
+			return true;
+		}
+
+		return false;
+	}
+
+	private void finishBlindBlock(PendingRequest finishedRequest) {
+		BlindScan blindScan = blindScansByLogId.get(finishedRequest.logId);
+		if (blindScan == null) {
+			return;
+		}
+
+		System.out.println("[WinTest LogSync] blind block " + finishedRequest.countFrom
+				+ "-" + finishedRequest.countTo + " of " + finishedRequest.logId
+				+ " answered with " + finishedRequest.answeredQsoCount + " QSOs");
+
+		if (finishedRequest.answeredQsoCount == 0) {
+			// the log ends before this block, nothing left to fetch
+			blindScan.completed = true;
+		} else {
+			blindScan.nextCountFrom = finishedRequest.countTo + 1L;
+		}
+
+		tickDueImmediately = true;
+	}
+
+	/**
+	 * Resolves the Win-Test station a log belongs to. The log identity carries
+	 * the owning station name in front of the {@code @} separator.
+	 *
+	 * @param logId log identity
+	 * @return station name to ask, or {@code null} when none is known
+	 */
+	private String resolveStationForLogId(String logId) {
+		int separatorIndex = logId.indexOf('@');
+		String ownerStationName = separatorIndex > 0 ? logId.substring(0, separatorIndex) : logId;
+
+		for (String stationName : inventoriesByStation.keySet()) {
+			if (stationName.equalsIgnoreCase(ownerStationName)) {
+				return stationName;
+			}
+		}
+
+		return ownerStationName.isBlank() ? null : ownerStationName;
+	}
+
+	private void sendRequest(
+			String targetStation,
+			String logId,
+			long countFrom,
+			long countTo,
+			boolean blind,
+			long now
+	) {
+		pendingRequest = new PendingRequest(targetStation, logId, countFrom, countTo, blind, now);
+		state = SyncState.SYNCING;
+
+		try {
+			needQsoSender.sendNeedQso(targetStation, logId, countFrom, countTo);
+		} catch (RuntimeException exception) {
+			/*
+			 * A failed transmission must not stop the receive loop. The pending
+			 * request runs into its timeout and is retried from there.
+			 */
+			System.out.println(
+					"[WinTest LogSync] NEEDQSO could not be sent: " + exception.getMessage()
+			);
+		}
+	}
+
+	private String resolveOwnStationName() {
+		if (ownStationNameSupplier == null) {
+			return "";
+		}
+
+		String ownStationName = ownStationNameSupplier.get();
+		return ownStationName == null ? "" : ownStationName.trim();
+	}
+
+	/** Request that is waiting for its answer. */
+	private static final class PendingRequest {
+
+		private final String targetStation;
+		private final String logId;
+		private final long countFrom;
+		private final long countTo;
+		private final boolean blind;
+		private final long sentAtMs;
+		private int answeredQsoCount;
+
+		private PendingRequest(
+				String targetStation,
+				String logId,
+				long countFrom,
+				long countTo,
+				boolean blind,
+				long sentAtMs
+		) {
+			this.targetStation = targetStation;
+			this.logId = logId;
+			this.countFrom = countFrom;
+			this.countTo = countTo;
+			this.blind = blind;
+			this.sentAtMs = sentAtMs;
+		}
+
+		private long getRequestedQsoCount() {
+			return countTo - countFrom + 1L;
+		}
+	}
+
+	/** Progress of the blind fallback for one log. */
+	private static final class BlindScan {
+		private long nextCountFrom = 1L;
+		private int requestedBlockCount;
+		private boolean completed;
+	}
+}

src/main/java/kst4contest/controller/WinTestMessage.java

@@ -17,8 +17,10 @@ import java.nio.charset.StandardCharsets;
  */
 public class WinTestMessage {
 
-    /** Win-Test message types relevant for SKED management. */
+    /** Win-Test message types sent by KST4Contest. */
     public enum MessageType {
+        /** Requests a range of QSOs of one Win-Test log for log synchronization. */
+        NEEDQSO,
         LOCKSKED,
         UNLOCKSKED,
         ADDSKED,

src/main/java/kst4contest/controller/WinTestNetworkAddressResolver.java

@@ -0,0 +1,227 @@
+package kst4contest.controller;
+
+import java.net.Inet4Address;
+import java.net.InetAddress;
+import java.net.InterfaceAddress;
+import java.net.NetworkInterface;
+import java.net.SocketException;
+import java.net.UnknownHostException;
+import java.util.Enumeration;
+
+/**
+ * Determines the broadcast address used to talk to the Win-Test network.
+ *
+ * <p>Win-Test only reacts to broadcast packets; a unicast request to the same
+ * station stays unanswered. The configured broadcast address is therefore the
+ * one setting that silently disables every outgoing Win-Test feature when it is
+ * wrong: sending to an address outside the local networks succeeds without an
+ * error and the packet is routed away.</p>
+ *
+ * <p>Incoming Win-Test packets carry the information that is actually needed.
+ * The source address of a received packet identifies the network the station
+ * lives in, so the broadcast address of the matching local interface reaches it
+ * reliably. The configured address remains the fallback and keeps working for a
+ * station behind a router, where no local interface matches.</p>
+ */
+public class WinTestNetworkAddressResolver {
+
+	/** Last resort when neither a station nor a usable setting is available. */
+	private static final String LIMITED_BROADCAST_ADDRESS = "255.255.255.255";
+
+	/**
+	 * Resolves the local broadcast address for a remote address.
+	 */
+	@FunctionalInterface
+	public interface LocalBroadcastLookup {
+
+		/**
+		 * @param remoteAddress address a Win-Test packet was received from
+		 * @return broadcast address of the matching local interface, or
+		 *         {@code null} when no local interface serves that network
+		 */
+		InetAddress findBroadcastFor(InetAddress remoteAddress);
+	}
+
+	private final LocalBroadcastLookup localBroadcastLookup;
+
+	private volatile InetAddress lastStationAddress;
+
+	private volatile String lastReportedBroadcastAddress;
+
+	public WinTestNetworkAddressResolver() {
+		this(WinTestNetworkAddressResolver::findLocalBroadcastAddress);
+	}
+
+	/**
+	 * @param localBroadcastLookup interface lookup, replaceable for tests
+	 */
+	WinTestNetworkAddressResolver(LocalBroadcastLookup localBroadcastLookup) {
+		this.localBroadcastLookup = localBroadcastLookup;
+	}
+
+	/**
+	 * Remembers where Win-Test packets come from.
+	 *
+	 * <p>Only addresses of real Win-Test stations may be passed in. Loopback and
+	 * wildcard addresses are ignored, so an internal control packet cannot
+	 * redirect outgoing Win-Test traffic.</p>
+	 *
+	 * @param stationAddress source address of a received Win-Test packet
+	 */
+	public void rememberStationAddress(InetAddress stationAddress) {
+		if (stationAddress == null
+				|| stationAddress.isLoopbackAddress()
+				|| stationAddress.isAnyLocalAddress()
+				|| !(stationAddress instanceof Inet4Address)) {
+			return;
+		}
+
+		this.lastStationAddress = stationAddress;
+	}
+
+	/**
+	 * Determines the broadcast address for outgoing Win-Test packets.
+	 *
+	 * <p>Order of preference: the broadcast address of the local interface that
+	 * serves the last seen Win-Test station, then the configured address, then
+	 * the limited broadcast address.</p>
+	 *
+	 * @param configuredBroadcastAddress address from the settings, may be blank
+	 * @return address to send Win-Test packets to
+	 * @throws UnknownHostException if the configured address cannot be resolved
+	 *                              and the limited broadcast address fails too
+	 */
+	public InetAddress resolveBroadcastAddress(String configuredBroadcastAddress)
+			throws UnknownHostException {
+
+		InetAddress stationAddress = this.lastStationAddress;
+
+		if (stationAddress != null) {
+			InetAddress derivedBroadcastAddress =
+					localBroadcastLookup.findBroadcastFor(stationAddress);
+
+			if (derivedBroadcastAddress != null) {
+				reportDerivedAddress(derivedBroadcastAddress, configuredBroadcastAddress);
+				return derivedBroadcastAddress;
+			}
+		}
+
+		if (configuredBroadcastAddress != null && !configuredBroadcastAddress.isBlank()) {
+			return InetAddress.getByName(configuredBroadcastAddress.trim());
+		}
+
+		return InetAddress.getByName(LIMITED_BROADCAST_ADDRESS);
+	}
+
+	/**
+	 * Logs a derived address once as long as it stays the same, and points out
+	 * a configured address that does not match the Win-Test network.
+	 */
+	private void reportDerivedAddress(
+			InetAddress derivedBroadcastAddress,
+			String configuredBroadcastAddress
+	) {
+		String derivedHostAddress = derivedBroadcastAddress.getHostAddress();
+
+		if (derivedHostAddress.equals(lastReportedBroadcastAddress)) {
+			return;
+		}
+
+		lastReportedBroadcastAddress = derivedHostAddress;
+
+		String configuredHostAddress = configuredBroadcastAddress == null
+				? "" : configuredBroadcastAddress.trim();
+
+		if (derivedHostAddress.equals(configuredHostAddress)) {
+			return;
+		}
+
+		System.out.println("[WinTest] using broadcast address " + derivedHostAddress
+				+ " of the network Win-Test was heard on, configured is '"
+				+ configuredHostAddress + "'");
+	}
+
+	/**
+	 * Searches the local interfaces for the network a remote address belongs to.
+	 *
+	 * @param remoteAddress address of a Win-Test station
+	 * @return broadcast address of the matching interface, or {@code null}
+	 */
+	static InetAddress findLocalBroadcastAddress(InetAddress remoteAddress) {
+		if (!(remoteAddress instanceof Inet4Address)) {
+			return null;
+		}
+
+		try {
+			Enumeration<NetworkInterface> networkInterfaces =
+					NetworkInterface.getNetworkInterfaces();
+
+			while (networkInterfaces != null && networkInterfaces.hasMoreElements()) {
+				NetworkInterface networkInterface = networkInterfaces.nextElement();
+
+				for (InterfaceAddress interfaceAddress : networkInterface.getInterfaceAddresses()) {
+					InetAddress broadcastAddress = interfaceAddress.getBroadcast();
+
+					if (broadcastAddress == null
+							|| !(interfaceAddress.getAddress() instanceof Inet4Address)) {
+						continue;
+					}
+
+					if (isInSameSubnet(
+							interfaceAddress.getAddress(),
+							remoteAddress,
+							interfaceAddress.getNetworkPrefixLength())) {
+						return broadcastAddress;
+					}
+				}
+			}
+		} catch (SocketException exception) {
+			System.out.println("[WinTest] could not inspect local interfaces: "
+					+ exception.getMessage());
+		}
+
+		return null;
+	}
+
+	/**
+	 * Compares two IPv4 addresses up to the given network prefix length.
+	 *
+	 * @param localAddress address of a local interface
+	 * @param remoteAddress address of the Win-Test station
+	 * @param networkPrefixLength prefix length of the local interface
+	 * @return {@code true} when both addresses share the same network
+	 */
+	static boolean isInSameSubnet(
+			InetAddress localAddress,
+			InetAddress remoteAddress,
+			int networkPrefixLength
+	) {
+		if (localAddress == null || remoteAddress == null) {
+			return false;
+		}
+
+		byte[] localBytes = localAddress.getAddress();
+		byte[] remoteBytes = remoteAddress.getAddress();
+
+		if (localBytes.length != remoteBytes.length
+				|| networkPrefixLength < 0
+				|| networkPrefixLength > localBytes.length * 8) {
+			return false;
+		}
+
+		int remainingPrefixBits = networkPrefixLength;
+
+		for (int byteIndex = 0; byteIndex < localBytes.length && remainingPrefixBits > 0; byteIndex++) {
+			int comparedBits = Math.min(8, remainingPrefixBits);
+			int mask = (0xFF << (8 - comparedBits)) & 0xFF;
+
+			if ((localBytes[byteIndex] & mask) != (remoteBytes[byteIndex] & mask)) {
+				return false;
+			}
+
+			remainingPrefixBits -= comparedBits;
+		}
+
+		return true;
+	}
+}

src/main/java/kst4contest/controller/WinTestPacket.java

@@ -0,0 +1,238 @@
+package kst4contest.controller;
+
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
+/**
+ * Win-Test network packet received over UDP.
+ *
+ * <p>This is the receiving counterpart of {@link WinTestMessage} and follows the
+ * same framing:</p>
+ *
+ * <pre>
+ *   MESSAGETYPE: "src" "dst" data{checksum}\0
+ * </pre>
+ *
+ * <p>The checksum byte always has bit 7 set and is therefore not valid ASCII.
+ * Decoding the datagram as text before removing it turns the byte into a
+ * replacement character that sticks to the last data field. That is harmless
+ * for fields KST4Contest never reads, but the log synchronization needs exactly
+ * those trailing fields: the log ID of an {@code ADDQSO} packet and the
+ * run-length inventory of an {@code IHAVE} packet. The framing is therefore
+ * resolved on the raw bytes here, once, before any text parsing.</p>
+ */
+public final class WinTestPacket {
+
+	/** Quoted values stay one token, unquoted values are split at whitespace. */
+	private static final Pattern TOKEN_PATTERN = Pattern.compile("\"([^\"]*)\"|(\\S+)");
+
+	private final String messageType;
+	private final String source;
+	private final String destination;
+	private final String messageText;
+	private final List<String> dataTokens;
+	private final boolean checksumPresent;
+	private final boolean checksumValid;
+
+	private WinTestPacket(
+			String messageType,
+			String source,
+			String destination,
+			String messageText,
+			List<String> dataTokens,
+			boolean checksumPresent,
+			boolean checksumValid
+	) {
+		this.messageType = messageType;
+		this.source = source;
+		this.destination = destination;
+		this.messageText = messageText;
+		this.dataTokens = dataTokens;
+		this.checksumPresent = checksumPresent;
+		this.checksumValid = checksumValid;
+	}
+
+	/**
+	 * Builds a packet from a received datagram.
+	 *
+	 * <p>Trailing NUL bytes are removed first. If the resulting last byte has
+	 * bit 7 set it is the Win-Test checksum: it is verified against the sum of
+	 * all preceding bytes and removed before the message text is decoded.</p>
+	 *
+	 * @param datagram raw datagram buffer
+	 * @param length number of valid bytes in the buffer
+	 * @return parsed packet, or {@code null} when the datagram carries no message
+	 */
+	public static WinTestPacket fromDatagram(byte[] datagram, int length) {
+		if (datagram == null || length <= 0 || length > datagram.length) {
+			return null;
+		}
+
+		int endIndex = length;
+		while (endIndex > 0 && datagram[endIndex - 1] == 0) {
+			endIndex--;
+		}
+
+		if (endIndex == 0) {
+			return null;
+		}
+
+		boolean hasChecksum = (datagram[endIndex - 1] & 0x80) != 0;
+		boolean isChecksumValid = false;
+		int textEndIndex = endIndex;
+
+		if (hasChecksum) {
+			int sum = 0;
+			for (int index = 0; index < endIndex - 1; index++) {
+				sum += datagram[index] & 0xFF;
+			}
+			byte expectedChecksum = (byte) ((sum | 0x80) & 0xFF);
+			isChecksumValid = expectedChecksum == datagram[endIndex - 1];
+			textEndIndex = endIndex - 1;
+		}
+
+		String text = new String(datagram, 0, textEndIndex, StandardCharsets.US_ASCII);
+		return fromMessageText(text, hasChecksum, isChecksumValid);
+	}
+
+	/**
+	 * Builds a packet from an already decoded message text without checksum
+	 * information. Used for messages that reach the listener as text.
+	 *
+	 * @param messageText complete message text
+	 * @return parsed packet, or {@code null} for an unusable message
+	 */
+	public static WinTestPacket fromMessageText(String messageText) {
+		return fromMessageText(messageText, false, false);
+	}
+
+	private static WinTestPacket fromMessageText(
+			String rawMessageText,
+			boolean checksumPresent,
+			boolean checksumValid
+	) {
+		if (rawMessageText == null) {
+			return null;
+		}
+
+		String text = rawMessageText.trim();
+		int typeEndIndex = text.indexOf(": ");
+		if (typeEndIndex <= 0) {
+			return null;
+		}
+
+		String type = text.substring(0, typeEndIndex);
+		List<String> tokens = tokenize(text.substring(typeEndIndex + 2));
+
+		String packetSource = tokens.isEmpty() ? "" : tokens.get(0);
+		String packetDestination = tokens.size() > 1 ? tokens.get(1) : "";
+		List<String> data = tokens.size() > 2
+				? new ArrayList<>(tokens.subList(2, tokens.size()))
+				: new ArrayList<>();
+
+		return new WinTestPacket(
+				type,
+				packetSource,
+				packetDestination,
+				text,
+				data,
+				checksumPresent,
+				checksumValid
+		);
+	}
+
+	/**
+	 * Splits Win-Test payload text into fields. Quoted values are kept together
+	 * and empty quoted values are preserved, so field positions stay stable.
+	 *
+	 * @param text payload text
+	 * @return field values without their surrounding quotes
+	 */
+	static List<String> tokenize(String text) {
+		List<String> tokens = new ArrayList<>();
+		if (text == null) {
+			return tokens;
+		}
+
+		Matcher matcher = TOKEN_PATTERN.matcher(text);
+		while (matcher.find()) {
+			tokens.add(matcher.group(1) != null ? matcher.group(1) : matcher.group(2));
+		}
+		return tokens;
+	}
+
+	/**
+	 * @return message type such as {@code ADDQSO}, never {@code null}
+	 */
+	public String getMessageType() {
+		return messageType;
+	}
+
+	/**
+	 * @return Win-Test station that sent the packet
+	 */
+	public String getSource() {
+		return source;
+	}
+
+	/**
+	 * @return addressed Win-Test station, empty for a broadcast
+	 */
+	public String getDestination() {
+		return destination;
+	}
+
+	/**
+	 * @return complete message text without checksum byte and NUL terminator
+	 */
+	public String getMessageText() {
+		return messageText;
+	}
+
+	/**
+	 * @return payload fields following source and destination
+	 */
+	public List<String> getDataTokens() {
+		return Collections.unmodifiableList(dataTokens);
+	}
+
+	/**
+	 * @param index payload field position
+	 * @return field value, or {@code null} when the field is missing
+	 */
+	public String getDataToken(int index) {
+		return index >= 0 && index < dataTokens.size() ? dataTokens.get(index) : null;
+	}
+
+	public boolean isChecksumPresent() {
+		return checksumPresent;
+	}
+
+	public boolean isChecksumValid() {
+		return checksumValid;
+	}
+
+	/**
+	 * Checks whether this packet is meant for us.
+	 *
+	 * @param ownStationName own Win-Test station name
+	 * @return {@code true} for a broadcast or for a packet addressed to us
+	 */
+	public boolean isAddressedTo(String ownStationName) {
+		if (destination == null || destination.isEmpty()) {
+			return true;
+		}
+		return ownStationName != null && destination.equalsIgnoreCase(ownStationName.trim());
+	}
+
+	@Override
+	public String toString() {
+		return messageType + ": src=" + source + " dst=" + destination
+				+ " fields=" + dataTokens.size()
+				+ (checksumPresent ? (checksumValid ? " checksum=ok" : " checksum=bad") : " checksum=none");
+	}
+}

src/main/java/kst4contest/logic/FrequencyTextParser.java

@@ -13,9 +13,10 @@ import java.util.regex.Pattern;
  * Common parser for explicit amateur-radio frequencies embedded in text.
  *
  * <p>This parser deliberately handles only complete frequencies such as
- * 144.300, 432.357 or 10368.100. Relative forms such as ".210" or ambiguous
- * bare values such as "210" require additional message context and remain the
- * responsibility of the chat-message parser.</p>
+ * 144.300, 432.357, 10368.100 or their compact digit-only forms. Relative
+ * forms such as ".210" or ambiguous bare values such as "210" require
+ * additional message context and remain the responsibility of the
+ * chat-message parser.</p>
  */
 public final class FrequencyTextParser {
 
@@ -26,14 +27,18 @@ public final class FrequencyTextParser {
      * 432,357
      * 10368.100
      * 144.300.03
+     * 144300
+     * 10368100
      *
-     * At least two digits are required before the decimal separator. This
-     * intentionally prevents "1.2" from being interpreted as a frequency.
+     * At least two digits are required before a decimal separator. Compact
+     * values need at least five digits because their final three digits form
+     * the kHz part. This intentionally prevents "1.2" and bare values such as
+     * "210" from being interpreted as complete frequencies.
      */
     private static final Pattern EXPLICIT_FREQUENCY_PATTERN = Pattern.compile(
             "(?<![A-Z0-9])"
-                    + "(\\d{2,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?)"
-                    + "(?!\\d)",
+                    + "(\\d{2,5}[.,]\\d{1,3}(?:[.,]\\d{1,3})?|\\d{5,8})"
+                    + "(?![A-Z0-9])",
             Pattern.CASE_INSENSITIVE
     );
 
@@ -93,12 +98,12 @@ public final class FrequencyTextParser {
             return null;
         }
 
-        String normalized =
-                normalizeFrequencyString(
-                        rawFrequency
-                                .trim()
-                                .replace(',', '.')
-                );
+        final String trimmedFrequency = rawFrequency.trim();
+        final String normalized = trimmedFrequency.matches("\\d{5,8}")
+                ? trimmedFrequency.substring(0, trimmedFrequency.length() - 3)
+                        + "."
+                        + trimmedFrequency.substring(trimmedFrequency.length() - 3)
+                : normalizeFrequencyString(trimmedFrequency.replace(',', '.'));
 
         try {
             double frequencyMHz =

src/main/java/kst4contest/model/ChatPreferences.java

@@ -1,11 +1,16 @@
 package kst4contest.model;
 
 import java.io.File;
-import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.OutputStream;
-import java.util.ArrayList;
+import java.nio.file.AtomicMoveNotSupportedException;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.nio.file.StandardCopyOption;
 import java.util.Iterator;
+import java.util.LinkedHashMap;
+import java.util.Map;
+import java.util.OptionalDouble;
 
 import javax.xml.XMLConstants;
 import javax.xml.parsers.DocumentBuilder;
@@ -50,7 +55,7 @@ public class ChatPreferences {
 	 * Reading must stay backwards compatible: missing/unknown tags should fall back to defaults.
 	 */
 //	private static final int CONFIG_VERSION = 2;
-	public static final int CONFIG_VERSION = 5;
+	public static final int CONFIG_VERSION = 7;
 
 	// Prefer writing tag names that mirror variable names (human readable). Keep legacy tags for compatibility.
 	private static final String TAG_CONFIG_VERSION = "configVersion";
@@ -74,7 +79,26 @@ public class ChatPreferences {
 	 * TODO: delete this from the kst4contest.view/Main.java!
 	 */
 	public ChatPreferences() {
-		ApplicationFileUtils.copyResourceIfRequired(ApplicationConstants.APPLICATION_NAME, PREFERENCE_RESOURCE, PREFERENCES_FILE);
+		this(PREFERENCES_FILE);
+	}
+
+	/**
+	 * Creates preferences bound to one operator profile.
+	 *
+	 * <p>The file name is resolved below the application directory, so both
+	 * "preferences.xml" for the root installation and "profiles/OP2/preferences.xml"
+	 * for an additional operator profile are valid. A missing file is seeded from the
+	 * bundled template, which gives a new profile the same clean defaults a first-ever
+	 * installation gets.</p>
+	 *
+	 * @param applicationRelativeFileName preferences file name relative to the application directory
+	 */
+	public ChatPreferences(final String applicationRelativeFileName) {
+		ApplicationFileUtils.copyResourceIfRequired(ApplicationConstants.APPLICATION_NAME, PREFERENCE_RESOURCE, applicationRelativeFileName);
+		this.storeAndRestorePreferencesFileName = ApplicationFileUtils.getFilePath(
+				ApplicationConstants.APPLICATION_NAME,
+				applicationRelativeFileName
+		);
 
 //        lstNotify_QSOSniffer_sniffedCallSignList.add("DF0GEB");
 
@@ -143,7 +167,7 @@ public class ChatPreferences {
 	 *
 	 */
 
-	String programVersion = "Chat is powered by ON4KST \n\nUsage is free. You are welcome to support: \n\n- my project (donations, bugreports, good ideas are welcome), \n- ON4KST Servers, \n- AirScout developers and \n- OV3T (best AS-data provider of the world). \n\n73 de DO5AMF, Marc (DM5M / DARC X08)";
+	String programVersion = "Chat is powered by ON4KST \n\nUsage is free. You are welcome to support: \n\n- my project (donations, bugreports, good ideas are welcome), \n- ON4KST Servers, \n- AirScout developers and \n- OV3T (best AS-data provider of the world). \n\n73 de DO5AMF, Marc (DM5M / DARC X08)\nand DN9APW, Philipp Wagner";
 	String logsynch_storeWorkedCallSignsFileNameUDPMessageBackup = "udpReaderBackup.txt";
 	String storeAndRestorePreferencesFileName = ApplicationFileUtils.getFilePath(ApplicationConstants.APPLICATION_NAME, PREFERENCES_FILE);
 	String chatState; // working variable only for use by primarystage (title bar)
@@ -163,8 +187,14 @@ public class ChatPreferences {
 	int stn_pstRotatorPort = 12000;
 
 	boolean stn_loginAFKState = false; //always start as here
-	String stn_loginCallSign = "do5amf";
-	String stn_loginCallSignRaw = "do5amf"; //for example: do5amf instead of logincallsign do5amf-2
+	/*
+	 * The login credentials default to empty on purpose. A missing or empty value in
+	 * preferences.xml means "not configured yet", and falling back to a real callsign
+	 * would let an operator transmit under someone else's call. This matters for every
+	 * additional operator profile, whose preferences are created without credentials.
+	 */
+	String stn_loginCallSign = "";
+	String stn_loginCallSignRaw = ""; //for example: do5amf instead of logincallsign do5amf-2
 	String stn_loginPassword = "";
 	String stn_loginNameMainCat = "KST4Contest";
 	String stn_loginNameSecondCat = "KST4ContestSHF";
@@ -341,6 +371,12 @@ public class ChatPreferences {
 	private double[] GUIstationMapStageSceneSizeHW = new double[] { 1000, 800 };
 	private double[] GUIstationMapStagePositionXY = new double[] { Double.NaN, Double.NaN };
 	private boolean GUIstationMapPathAnalysisVisible = true;
+	private boolean GUIstationMapClusteringEnabled = true;
+	private final Map<String, Double> tableColumnWidths = new LinkedHashMap<>();
+
+	private static final String TAG_TABLE_COLUMN_WIDTH = "tableColumnWidth";
+	private static final double MIN_TABLE_COLUMN_WIDTH = 16.0;
+	private static final double MAX_TABLE_COLUMN_WIDTH = 10_000.0;
 
 
 	/*********************************************************************************
@@ -645,6 +681,39 @@ public class ChatPreferences {
 		this.GUIstationMapPathAnalysisVisible = GUIstationMapPathAnalysisVisible;
 	}
 
+	public boolean isGUIstationMapClusteringEnabled() {
+		return GUIstationMapClusteringEnabled;
+	}
+
+	public void setGUIstationMapClusteringEnabled(boolean GUIstationMapClusteringEnabled) {
+		this.GUIstationMapClusteringEnabled = GUIstationMapClusteringEnabled;
+	}
+
+	/**
+	 * Returns a stored width for one stable table/leaf-column identity.
+	 *
+	 * @param tableId stable table layout identifier
+	 * @param columnId stable leaf-column identifier
+	 * @return stored pixel width, or empty when no usable value exists
+	 */
+	public synchronized OptionalDouble getTableColumnWidth(String tableId, String columnId) {
+		if (!isValidTableColumnIdentity(tableId, columnId)) {
+			return OptionalDouble.empty();
+		}
+		Double width = tableColumnWidths.get(tableColumnWidthKey(tableId, columnId));
+		return isValidTableColumnWidth(width) ? OptionalDouble.of(width) : OptionalDouble.empty();
+	}
+
+	/**
+	 * Updates one table leaf-column width in memory. Persistence is coordinated by
+	 * the layout autosave layer.
+	 */
+	public synchronized void setTableColumnWidth(String tableId, String columnId, double width) {
+		if (isValidTableColumnIdentity(tableId, columnId) && isValidTableColumnWidth(width)) {
+			tableColumnWidths.put(tableColumnWidthKey(tableId, columnId), width);
+		}
+	}
+
 	public boolean isGuiOptions_defaultFilterNothing() {
 		return guiOptions_defaultFilterNothing;
 	}
@@ -1389,7 +1458,7 @@ public class ChatPreferences {
 	 *
 	 * @return true if the file writing was successful, else false
 	 */
-	public boolean writePreferencesToXmlFile() {
+	public synchronized boolean writePreferencesToXmlFile() {
 
 		DocumentBuilderFactory docFactory = DocumentBuilderFactory.newInstance();
 		try {
@@ -2085,27 +2154,25 @@ public class ChatPreferences {
 			);
 			guiOptions.appendChild(GUIstationMapPathAnalysisVisible);
 
+			Element GUIstationMapClusteringEnabled = doc.createElement("GUIstationMapClusteringEnabled");
+			GUIstationMapClusteringEnabled.setTextContent(
+					String.valueOf(this.isGUIstationMapClusteringEnabled())
+			);
+			guiOptions.appendChild(GUIstationMapClusteringEnabled);
+
+			appendTableColumnWidths(doc, guiOptions);
+
 			/****************************************************************************************
 			 ****************************** now write this XML! *************************************
 			 ****************************************************************************************/
 
-			writeXml(doc, System.out);
-
-			// write dom document to a file
-			try (FileOutputStream output =
-						 new FileOutputStream(storeAndRestorePreferencesFileName)) {
-				writeXml(doc, output);
-			} catch (IOException e) {
-				e.printStackTrace();
-			} catch (TransformerException e) {
-				// TODO Auto-generated catch block
-				e.printStackTrace();
-			}
+			writeDocumentAtomically(doc);
 
 
-		} catch (ParserConfigurationException | TransformerException e1) {
+		} catch (ParserConfigurationException | TransformerException | IOException e1) {
 			// TODO Auto-generated catch block
 			e1.printStackTrace();
+			return false;
 		}
 		return true;
 
@@ -2117,6 +2184,113 @@ public class ChatPreferences {
 
 	}
 
+	/**
+	 * Writes only layout values into the existing preferences document. Functional
+	 * settings are deliberately read from disk and left untouched.
+	 */
+	public synchronized boolean writeLayoutPreferencesToXmlFile() {
+		Path preferencesPath = Path.of(storeAndRestorePreferencesFileName).toAbsolutePath();
+		if (!Files.isRegularFile(preferencesPath)) {
+			System.out.println("[ChatPreferences, Warning]: Cannot autosave layout because preferences.xml does not exist.");
+			return false;
+		}
+
+		try {
+			DocumentBuilder documentBuilder = createSecureDocumentBuilderFactory().newDocumentBuilder();
+			Document document = documentBuilder.parse(preferencesPath.toFile());
+			Element root = document.getDocumentElement();
+			if (root == null) {
+				return false;
+			}
+
+			upsertDirectChildText(document, root, TAG_CONFIG_VERSION, String.valueOf(CONFIG_VERSION));
+			Element guiOptions = getDirectChildElement(root, "guiOptions");
+			if (guiOptions == null) {
+				guiOptions = document.createElement("guiOptions");
+				root.appendChild(guiOptions);
+			}
+
+			updateLayoutElements(document, guiOptions);
+			removeDirectChildren(guiOptions, TAG_TABLE_COLUMN_WIDTH);
+			appendTableColumnWidths(document, guiOptions);
+			writeDocumentAtomically(document);
+			return true;
+		} catch (ParserConfigurationException | SAXException | IOException | TransformerException exception) {
+			exception.printStackTrace();
+			return false;
+		}
+	}
+
+	private void updateLayoutElements(Document document, Element guiOptions) {
+		upsertDirectChildText(document, guiOptions, "GUIscn_ChatwindowMainSceneSizeHW",
+				getGUIscn_ChatwindowMainSceneSizeHW()[0] + ";" + getGUIscn_ChatwindowMainSceneSizeHW()[1]);
+		upsertDirectChildText(document, guiOptions, "GUIclusterAndQSOMonStage_SceneSizeHW",
+				getGUIclusterAndQSOMonStage_SceneSizeHW()[0] + ";" + getGUIclusterAndQSOMonStage_SceneSizeHW()[1]);
+		upsertDirectChildText(document, guiOptions, "GUIstage_updateStage_SceneSizeHW",
+				getGUIstage_updateStage_SceneSizeHW()[0] + ";" + getGUIstage_updateStage_SceneSizeHW()[1]);
+		upsertDirectChildText(document, guiOptions, "GUIsettingsStageSceneSizeHW",
+				getGUIsettingsStageSceneSizeHW()[0] + ";" + getGUIsettingsStageSceneSizeHW()[1]);
+		upsertDirectChildText(document, guiOptions, "GUIselectedCallSignSplitPane_dividerposition",
+				doubleArrayToCSVString(getGUIselectedCallSignSplitPane_dividerposition()));
+		upsertDirectChildText(document, guiOptions, "GUImainWindowLeftSplitPane_dividerposition",
+				doubleArrayToCSVString(getGUImainWindowLeftSplitPane_dividerposition()));
+		upsertDirectChildText(document, guiOptions, "GUImessageSectionSplitpane_dividerposition",
+				doubleArrayToCSVString(getGUImessageSectionSplitpane_dividerposition()));
+		upsertDirectChildText(document, guiOptions, "GUImainWindowRightSplitPane_dividerposition",
+				doubleArrayToCSVString(getGUImainWindowRightSplitPane_dividerposition()));
+		upsertDirectChildText(document, guiOptions, "GUIpnl_directedMSGWin_dividerpositionDefault",
+				doubleArrayToCSVString(getGUIpnl_directedMSGWin_dividerpositionDefault()));
+		upsertDirectChildText(document, guiOptions, "GUIstationMapStageSceneSizeHW",
+				getGUIstationMapStageSceneSizeHW()[0] + ";" + getGUIstationMapStageSceneSizeHW()[1]);
+		upsertDirectChildText(document, guiOptions, "GUIstationMapStagePositionXY",
+				getGUIstationMapStagePositionXY()[0] + ";" + getGUIstationMapStagePositionXY()[1]);
+		upsertDirectChildText(document, guiOptions, "GUIstationMapClusteringEnabled",
+				String.valueOf(isGUIstationMapClusteringEnabled()));
+	}
+
+	private void appendTableColumnWidths(Document document, Element guiOptions) {
+		for (Map.Entry<String, Double> entry : tableColumnWidths.entrySet()) {
+			if (!isValidTableColumnWidth(entry.getValue())) {
+				continue;
+			}
+
+			int separatorIndex = entry.getKey().indexOf('\u0000');
+			if (separatorIndex <= 0 || separatorIndex >= entry.getKey().length() - 1) {
+				continue;
+			}
+
+			Element widthElement = document.createElement(TAG_TABLE_COLUMN_WIDTH);
+			widthElement.setAttribute("tableId", entry.getKey().substring(0, separatorIndex));
+			widthElement.setAttribute("columnId", entry.getKey().substring(separatorIndex + 1));
+			widthElement.setAttribute("pixels", String.valueOf(entry.getValue()));
+			guiOptions.appendChild(widthElement);
+		}
+	}
+
+	private void writeDocumentAtomically(Document document) throws IOException, TransformerException {
+		Path target = Path.of(storeAndRestorePreferencesFileName).toAbsolutePath();
+		Path parent = target.getParent();
+		Path fileName = target.getFileName();
+		if (parent == null || fileName == null) {
+			throw new IOException("Preferences path has no parent directory: " + target);
+		}
+
+		Files.createDirectories(parent);
+		Path temporary = Files.createTempFile(parent, fileName.toString(), ".tmp");
+		try {
+			try (OutputStream output = Files.newOutputStream(temporary)) {
+				writeXml(document, output);
+			}
+			try {
+				Files.move(temporary, target, StandardCopyOption.ATOMIC_MOVE, StandardCopyOption.REPLACE_EXISTING);
+			} catch (AtomicMoveNotSupportedException exception) {
+				Files.move(temporary, target, StandardCopyOption.REPLACE_EXISTING);
+			}
+		} finally {
+			Files.deleteIfExists(temporary);
+		}
+	}
+
 	// write doc to output stream
 	private static void writeXml(Document doc, OutputStream output) throws TransformerException {
 
@@ -2824,6 +2998,7 @@ public class ChatPreferences {
 			 * case read GUI options
 			 *
 			 ***********************************************/
+			this.setGUIstationMapClusteringEnabled(true);
 			list = doc.getElementsByTagName("guiOptions");
 			if (list.getLength() != 0) {
 
@@ -2862,6 +3037,17 @@ public class ChatPreferences {
 								"GUIstationMapPathAnalysisVisible"
 						));
 
+						/*
+						 * Files written before config version 7 do not contain this value.
+						 * Missing or malformed values keep clustering enabled so existing
+						 * installations retain the established map behaviour.
+						 */
+						this.setGUIstationMapClusteringEnabled(getBooleanOrDefault(
+								element,
+								true,
+								"GUIstationMapClusteringEnabled"
+						));
+
 						// Splitpane divider positions
 						String s1 = getText(element, null, "GUIselectedCallSignSplitPane_dividerposition");
 						if (s1 != null) {
@@ -2920,6 +3106,22 @@ public class ChatPreferences {
 						if (s5 != null) {
 							this.setGUIpnl_directedMSGWin_dividerpositionDefault(csvStringToDoubleArray(s5));
 						}
+
+						tableColumnWidths.clear();
+						NodeList widthElements = element.getElementsByTagName(TAG_TABLE_COLUMN_WIDTH);
+						for (int widthIndex = 0; widthIndex < widthElements.getLength(); widthIndex++) {
+							Node widthNode = widthElements.item(widthIndex);
+							if (!(widthNode instanceof Element widthElement)) {
+								continue;
+							}
+
+							String tableId = widthElement.getAttribute("tableId");
+							String columnId = widthElement.getAttribute("columnId");
+							double width = parseDoubleOrDefault(widthElement.getAttribute("pixels"), Double.NaN);
+							if (isValidTableColumnIdentity(tableId, columnId) && isValidTableColumnWidth(width)) {
+								tableColumnWidths.put(tableColumnWidthKey(tableId, columnId), width);
+							}
+						}
 					}
 				}
 			}
@@ -3100,6 +3302,63 @@ public class ChatPreferences {
 		return (n instanceof Element) ? (Element) n : null;
 	}
 
+	private static DocumentBuilderFactory createSecureDocumentBuilderFactory()
+			throws ParserConfigurationException {
+		DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
+		factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
+		return factory;
+	}
+
+	private static Element getDirectChildElement(Element parent, String tagName) {
+		for (Node child = parent.getFirstChild(); child != null; child = child.getNextSibling()) {
+			if (child instanceof Element element && tagName.equals(element.getTagName())) {
+				return element;
+			}
+		}
+		return null;
+	}
+
+	private static void upsertDirectChildText(
+			Document document,
+			Element parent,
+			String tagName,
+			String value
+	) {
+		Element element = getDirectChildElement(parent, tagName);
+		if (element == null) {
+			element = document.createElement(tagName);
+			parent.appendChild(element);
+		}
+		element.setTextContent(value);
+	}
+
+	private static void removeDirectChildren(Element parent, String tagName) {
+		for (Node child = parent.getFirstChild(); child != null; ) {
+			Node next = child.getNextSibling();
+			if (child instanceof Element element && tagName.equals(element.getTagName())) {
+				parent.removeChild(child);
+			}
+			child = next;
+		}
+	}
+
+	private static String tableColumnWidthKey(String tableId, String columnId) {
+		if (!isValidTableColumnIdentity(tableId, columnId)) {
+			return "";
+		}
+		return tableId + '\u0000' + columnId;
+	}
+
+	private static boolean isValidTableColumnIdentity(String tableId, String columnId) {
+		return tableId != null && !tableId.isBlank() && tableId.indexOf('\u0000') < 0
+				&& columnId != null && !columnId.isBlank() && columnId.indexOf('\u0000') < 0;
+	}
+
+	private static boolean isValidTableColumnWidth(Double width) {
+		return width != null && Double.isFinite(width)
+				&& width >= MIN_TABLE_COLUMN_WIDTH && width <= MAX_TABLE_COLUMN_WIDTH;
+	}
+
 	/**
 	 * Returns the text content of the first matching child tag (directly under {@code parent})
 	 * or {@code defaultValue} if the tag does not exist or is empty.
@@ -3139,6 +3398,20 @@ public class ChatPreferences {
 		return "true".equalsIgnoreCase(v) || "1".equals(v) || "yes".equalsIgnoreCase(v);
 	}
 
+	private static boolean getBooleanOrDefault(Element parent, boolean defaultValue, String... tagNames) {
+		String value = getText(parent, null, tagNames);
+		if (value == null) {
+			return defaultValue;
+		}
+		if ("true".equalsIgnoreCase(value) || "1".equals(value) || "yes".equalsIgnoreCase(value)) {
+			return true;
+		}
+		if ("false".equalsIgnoreCase(value) || "0".equals(value) || "no".equalsIgnoreCase(value)) {
+			return false;
+		}
+		return defaultValue;
+	}
+
 	private static int getInt(Element parent, int defaultValue, String... tagNames) {
 		String v = getText(parent, null, tagNames);
 		if (v == null) {

src/main/java/kst4contest/model/OperatorProfile.java

@@ -0,0 +1,133 @@
+package kst4contest.model;
+
+import java.util.Objects;
+
+/**
+ * Descriptor of one operator profile.
+ *
+ * <p>A profile always owns its own preferences file. Whether it also owns its own
+ * worked-station database is decided by {@link #isSharedWorkedDatabase()}: a multi
+ * operator contest station keeps one common log and therefore shares the database,
+ * while two operators sharing a private computer usually want their worked data kept
+ * apart.</p>
+ *
+ * <p>The descriptor deliberately carries no file paths. They are derived in exactly one
+ * place, {@link kst4contest.controller.OperatorProfilePaths}, so a stored path can never
+ * drift apart from the flag that produced it.</p>
+ */
+public class OperatorProfile {
+
+    /**
+     * Stable identifier of the profile. It is assigned once and never changes, so
+     * renaming a profile never moves a directory.
+     */
+    private String profileId;
+
+    /**
+     * Name shown in the profile picker and in the settings window.
+     */
+    private String displayName;
+
+    /**
+     * True for the profile that uses the historic flat installation layout directly.
+     */
+    private boolean rootProfile;
+
+    /**
+     * True if this profile uses the common station worked-station database.
+     */
+    private boolean sharedWorkedDatabase;
+
+    /**
+     * Timestamp of the last activation, used to preselect an entry in the picker.
+     */
+    private long lastUsedEpochMs;
+
+    public OperatorProfile() {
+        // Default constructor for stepwise construction while reading the registry.
+    }
+
+    public OperatorProfile(final String profileId,
+            final String displayName,
+            final boolean rootProfile,
+            final boolean sharedWorkedDatabase) {
+        this.profileId = profileId;
+        this.displayName = displayName;
+        this.rootProfile = rootProfile;
+        this.sharedWorkedDatabase = sharedWorkedDatabase;
+    }
+
+    public String getProfileId() {
+        return profileId;
+    }
+
+    public void setProfileId(final String profileId) {
+        this.profileId = profileId;
+    }
+
+    public String getDisplayName() {
+        return displayName;
+    }
+
+    public void setDisplayName(final String displayName) {
+        this.displayName = displayName;
+    }
+
+    public boolean isRootProfile() {
+        return rootProfile;
+    }
+
+    public void setRootProfile(final boolean rootProfile) {
+        this.rootProfile = rootProfile;
+    }
+
+    public boolean isSharedWorkedDatabase() {
+        return sharedWorkedDatabase;
+    }
+
+    public void setSharedWorkedDatabase(final boolean sharedWorkedDatabase) {
+        this.sharedWorkedDatabase = sharedWorkedDatabase;
+    }
+
+    public long getLastUsedEpochMs() {
+        return lastUsedEpochMs;
+    }
+
+    public void setLastUsedEpochMs(final long lastUsedEpochMs) {
+        this.lastUsedEpochMs = lastUsedEpochMs;
+    }
+
+    @Override
+    public boolean equals(final Object other) {
+
+        if (this == other) {
+            return true;
+        }
+
+        if (!(other instanceof OperatorProfile)) {
+            return false;
+        }
+
+        return Objects.equals(profileId, ((OperatorProfile) other).profileId);
+    }
+
+    @Override
+    public int hashCode() {
+        return Objects.hashCode(profileId);
+    }
+
+    /**
+     * Returns the display name so the descriptor can be shown in a list control directly.
+     *
+     * @return the display name, or the profile id when no name was set
+     */
+    @Override
+    public String toString() {
+
+        if (displayName == null || displayName.isBlank()) {
+            return String.valueOf(profileId);
+        }
+
+        return displayName;
+    }
+}

src/main/java/kst4contest/model/OperatorProfileSelection.java

@@ -0,0 +1,70 @@
+package kst4contest.model;
+
+import kst4contest.ApplicationConstants;
+import kst4contest.utils.ApplicationFileUtils;
+
+import java.util.Objects;
+
+/**
+ * Resolved runtime view of the active operator profile.
+ *
+ * <p>This is the only profile information the rest of the application needs: two file
+ * names relative to the application directory plus the flag whether a missing
+ * worked-station database may be seeded from the bundled template. Everything else is
+ * derived from the descriptor.</p>
+ */
+public class OperatorProfileSelection {
+
+    private final OperatorProfile profile;
+    private final String preferencesRelativeFileName;
+    private final String workedDatabaseRelativeFileName;
+    private final boolean seedWorkedDatabaseFromResource;
+
+    public OperatorProfileSelection(final OperatorProfile profile,
+            final String preferencesRelativeFileName,
+            final String workedDatabaseRelativeFileName,
+            final boolean seedWorkedDatabaseFromResource) {
+        this.profile = Objects.requireNonNull(profile, "profile");
+        this.preferencesRelativeFileName =
+                Objects.requireNonNull(preferencesRelativeFileName, "preferencesRelativeFileName");
+        this.workedDatabaseRelativeFileName =
+                Objects.requireNonNull(workedDatabaseRelativeFileName, "workedDatabaseRelativeFileName");
+        this.seedWorkedDatabaseFromResource = seedWorkedDatabaseFromResource;
+    }
+
+    public OperatorProfile getProfile() {
+        return profile;
+    }
+
+    public String getPreferencesRelativeFileName() {
+        return preferencesRelativeFileName;
+    }
+
+    public String getWorkedDatabaseRelativeFileName() {
+        return workedDatabaseRelativeFileName;
+    }
+
+    public boolean isSeedWorkedDatabaseFromResource() {
+        return seedWorkedDatabaseFromResource;
+    }
+
+    /**
+     * Returns the absolute preferences path, for display in the settings window.
+     *
+     * @return absolute path of the preferences file
+     */
+    public String getPreferencesAbsolutePath() {
+        return ApplicationFileUtils.getFilePath(
+                ApplicationConstants.APPLICATION_NAME, preferencesRelativeFileName);
+    }
+
+    /**
+     * Returns the absolute worked-station database path, for display in the settings window.
+     *
+     * @return absolute path of the worked-station database
+     */
+    public String getWorkedDatabaseAbsolutePath() {
+        return ApplicationFileUtils.getFilePath(
+                ApplicationConstants.APPLICATION_NAME, workedDatabaseRelativeFileName);
+    }
+}

src/main/java/kst4contest/view/ApplicationRuntimeLauncher.java

@@ -0,0 +1,106 @@
+package kst4contest.view;
+
+import kst4contest.controller.ActiveOperatorProfile;
+import kst4contest.controller.OperatorProfilePaths;
+import kst4contest.controller.OperatorProfileStore;
+import kst4contest.model.OperatorProfile;
+
+import javafx.application.Platform;
+import javafx.stage.Stage;
+
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
+/**
+ * Owns the lifecycle of the running application.
+ *
+ * <p>Switching the operator profile tears the current runtime down completely and builds
+ * a fresh one in the same process. Rebinding the existing windows is not an option: the
+ * user interface is built from the chat controller outwards, with several hundred
+ * references to the active preferences, and many controls are instance fields created
+ * once. A new {@link Kst4ContestApplication} instance gets fresh controls, which is safe
+ * here because the class keeps no mutable static state.</p>
+ */
+public final class ApplicationRuntimeLauncher {
+
+    private static final Logger LOGGER = Logger.getLogger(ApplicationRuntimeLauncher.class.getName());
+
+    private static Kst4ContestApplication currentRuntime;
+
+    private ApplicationRuntimeLauncher() {
+        // Utility class.
+    }
+
+    /**
+     * Registers the runtime that is currently live.
+     *
+     * @param runtime the running application instance
+     */
+    public static void setCurrent(final Kst4ContestApplication runtime) {
+        currentRuntime = runtime;
+    }
+
+    /**
+     * Returns the runtime that is currently live.
+     *
+     * @return the running application instance, or null before the first startup
+     */
+    public static Kst4ContestApplication getCurrent() {
+        return currentRuntime;
+    }
+
+    /**
+     * Shuts the application down.
+     *
+     * <p>JavaFX only calls {@code stop()} on the instance it launched itself, so an exit
+     * after a profile switch has to release the resources explicitly.</p>
+     */
+    public static void exitApplication() {
+
+        if (currentRuntime != null) {
+            currentRuntime.shutdownRuntime();
+        }
+
+        Platform.exit();
+        System.exit(0);
+    }
+
+    /**
+     * Replaces the running runtime with one bound to another operator profile.
+     *
+     * @param targetProfile profile to activate
+     * @return true if the new runtime was built
+     */
+    public static boolean switchProfile(final OperatorProfile targetProfile) {
+
+        if (targetProfile == null) {
+            return false;
+        }
+
+        new OperatorProfileStore().recordLastUsed(targetProfile.getProfileId());
+
+        if (currentRuntime != null) {
+            currentRuntime.shutdownRuntime();
+        }
+
+        ActiveOperatorProfile.set(OperatorProfilePaths.resolve(targetProfile));
+
+        Kst4ContestApplication nextRuntime = new Kst4ContestApplication();
+
+        try {
+            nextRuntime.start(new Stage());
+        } catch (Exception e) {
+            // The previous runtime is already gone, so there is nothing left to return to.
+            LOGGER.log(Level.SEVERE, "Could not start the selected operator profile", e);
+            Kst4ContestApplication.alertWindowEvent(
+                    "The operator profile could not be started: " + e.getMessage()
+                            + "\n\nKST4Contest has to be closed.");
+            Platform.exit();
+            System.exit(1);
+            return false;
+        }
+
+        setCurrent(nextRuntime);
+        return true;
+    }
+}

src/main/java/kst4contest/view/CommandLineOptions.java

@@ -0,0 +1,102 @@
+package kst4contest.view;
+
+import java.util.List;
+
+/**
+ * Command line options of the application.
+ *
+ * <p>The parsed value is additionally kept in a process wide holder. JavaFX only knows
+ * the parameters of the {@code Application} instance it launched itself, so an instance
+ * created during a profile switch would see no parameters at all. Parsing once at
+ * startup and remembering the result avoids that entirely.</p>
+ */
+public class CommandLineOptions {
+
+    /**
+     * Command line switch selecting the operator profile to start with.
+     */
+    public static final String PROFILE_ARGUMENT = "--profile";
+
+    /**
+     * System property used as an alternative to the command line switch.
+     */
+    public static final String PROFILE_SYSTEM_PROPERTY = "kst4contest.profile";
+
+    private static volatile CommandLineOptions rememberedOptions = new CommandLineOptions(null);
+
+    private final String requestedProfileName;
+
+    public CommandLineOptions(final String requestedProfileName) {
+        this.requestedProfileName = requestedProfileName;
+    }
+
+    /**
+     * Parses the raw application arguments.
+     *
+     * <p>Unknown arguments are ignored on purpose. A typo in a command line must never
+     * keep an operator out of the application shortly before a contest.</p>
+     *
+     * @param rawArguments raw arguments, may be null
+     * @return the parsed options
+     */
+    public static CommandLineOptions parse(final List<String> rawArguments) {
+
+        String requestedProfileName = null;
+
+        if (rawArguments != null) {
+            for (int argumentIndex = 0; argumentIndex < rawArguments.size(); argumentIndex++) {
+                String currentArgument = rawArguments.get(argumentIndex);
+
+                if (currentArgument == null) {
+                    continue;
+                }
+
+                if (currentArgument.startsWith(PROFILE_ARGUMENT + "=")) {
+                    requestedProfileName = currentArgument.substring(PROFILE_ARGUMENT.length() + 1);
+                } else if (PROFILE_ARGUMENT.equals(currentArgument)
+                        && argumentIndex + 1 < rawArguments.size()) {
+                    requestedProfileName = rawArguments.get(argumentIndex + 1);
+                    argumentIndex++;
+                }
+            }
+        }
+
+        if (requestedProfileName == null || requestedProfileName.isBlank()) {
+            requestedProfileName = System.getProperty(PROFILE_SYSTEM_PROPERTY);
+        }
+
+        if (requestedProfileName != null && requestedProfileName.isBlank()) {
+            requestedProfileName = null;
+        }
+
+        return new CommandLineOptions(
+                requestedProfileName == null ? null : requestedProfileName.trim());
+    }
+
+    /**
+     * Stores the parsed options for the lifetime of the process.
+     *
+     * @param options options to remember
+     */
+    public static void remember(final CommandLineOptions options) {
+        rememberedOptions = options == null ? new CommandLineOptions(null) : options;
+    }
+
+    /**
+     * Returns the options parsed at application startup.
+     *
+     * @return the remembered options, never null
+     */
+    public static CommandLineOptions remembered() {
+        return rememberedOptions;
+    }
+
+    /**
+     * Returns the operator profile requested on the command line.
+     *
+     * @return the requested profile name, or null when none was given
+     */
+    public String getRequestedProfileName() {
+        return requestedProfileName;
+    }
+}

src/main/java/kst4contest/view/LayoutAutosave.java

@@ -0,0 +1,50 @@
+package kst4contest.view;
+
+import javafx.animation.PauseTransition;
+import javafx.application.Platform;
+import javafx.util.Duration;
+import kst4contest.model.ChatPreferences;
+
+import java.util.Objects;
+
+/**
+ * Coalesces JavaFX layout changes into selective preferences writes.
+ */
+public final class LayoutAutosave {
+
+    private static final Duration SAVE_DELAY = Duration.millis(750);
+
+    private final ChatPreferences preferences;
+    private final PauseTransition saveDelay = new PauseTransition(SAVE_DELAY);
+    private boolean pending;
+
+    public LayoutAutosave(ChatPreferences preferences) {
+        this.preferences = Objects.requireNonNull(preferences, "preferences");
+        saveDelay.setOnFinished(event -> flushPending());
+    }
+
+    public void requestSave() {
+        if (!Platform.isFxApplicationThread()) {
+            Platform.runLater(this::requestSave);
+            return;
+        }
+
+        pending = true;
+        saveDelay.playFromStart();
+    }
+
+    public void flushPending() {
+        if (!pending) {
+            return;
+        }
+
+        saveDelay.stop();
+        pending = false;
+        preferences.writeLayoutPreferencesToXmlFile();
+    }
+
+    public void cancelPending() {
+        saveDelay.stop();
+        pending = false;
+    }
+}

src/main/java/kst4contest/view/OperatorProfileBootstrap.java

@@ -0,0 +1,107 @@
+package kst4contest.view;
+
+import kst4contest.controller.OperatorProfilePaths;
+import kst4contest.controller.OperatorProfileStore;
+import kst4contest.model.OperatorProfile;
+import kst4contest.model.OperatorProfileSelection;
+
+import java.util.List;
+import java.util.Optional;
+
+/**
+ * Decides which operator profile the application starts with.
+ *
+ * <p>The class contains no user interface code so the decision can be tested headless.
+ * Asking the operator is delegated to an {@link OperatorProfileChoiceRequester}, and a
+ * problem worth telling the operator about is reported through
+ * {@link #getStartupWarning()} instead of being shown here.</p>
+ *
+ * <p>The most important property of this logic is what it does <em>not</em> do: an
+ * installation with no or exactly one profile is resolved without asking anything and
+ * without touching a single file, so a single operator start stays exactly as fast and
+ * as quiet as it was before profiles existed.</p>
+ */
+public class OperatorProfileBootstrap {
+
+    private String startupWarning;
+
+    /**
+     * Resolves the operator profile to start with.
+     *
+     * @param store           registry to read the profiles from
+     * @param commandLineOptions parsed command line options
+     * @param choiceRequester requester used when the operator has to choose
+     * @return the resolved selection, or null when the operator chose to quit
+     */
+    public OperatorProfileSelection resolveAtStartup(final OperatorProfileStore store,
+            final CommandLineOptions commandLineOptions,
+            final OperatorProfileChoiceRequester choiceRequester) {
+
+        startupWarning = null;
+
+        List<OperatorProfile> availableProfiles = store.loadProfiles();
+        String requestedProfileName = commandLineOptions == null
+                ? null
+                : commandLineOptions.getRequestedProfileName();
+
+        if (requestedProfileName != null) {
+            OperatorProfile requestedProfile = findProfile(availableProfiles, requestedProfileName);
+
+            if (requestedProfile != null) {
+                return OperatorProfilePaths.resolve(requestedProfile);
+            }
+
+            startupWarning = "The operator profile \"" + requestedProfileName
+                    + "\" is unknown. KST4Contest continues with the normal profile selection.";
+        }
+
+        if (availableProfiles.isEmpty()) {
+            // No registry at all: the historic flat installation is the only profile.
+            return OperatorProfilePaths.resolve(store.buildImplicitRootProfile());
+        }
+
+        if (availableProfiles.size() == 1) {
+            return OperatorProfilePaths.resolve(availableProfiles.get(0));
+        }
+
+        String preselectedProfileId = store.loadLastUsedProfileId().orElse(null);
+        Optional<OperatorProfile> chosenProfile =
+                choiceRequester.requestProfileChoice(availableProfiles, preselectedProfileId);
+
+        return chosenProfile.map(OperatorProfilePaths::resolve).orElse(null);
+    }
+
+    /**
+     * Returns a message that should be shown to the operator after startup.
+     *
+     * @return the warning text, or null when startup was unremarkable
+     */
+    public String getStartupWarning() {
+        return startupWarning;
+    }
+
+    /**
+     * Finds a profile by identifier or display name, ignoring case.
+     *
+     * @param availableProfiles profiles to search
+     * @param requestedName     identifier or display name entered by the operator
+     * @return the matching profile, or null
+     */
+    private static OperatorProfile findProfile(final List<OperatorProfile> availableProfiles,
+            final String requestedName) {
+
+        for (OperatorProfile currentProfile : availableProfiles) {
+            if (requestedName.equalsIgnoreCase(currentProfile.getProfileId())) {
+                return currentProfile;
+            }
+        }
+
+        for (OperatorProfile currentProfile : availableProfiles) {
+            if (requestedName.equalsIgnoreCase(currentProfile.getDisplayName())) {
+                return currentProfile;
+            }
+        }
+
+        return null;
+    }
+}

src/main/java/kst4contest/view/OperatorProfileChoiceRequester.java

@@ -0,0 +1,26 @@
+package kst4contest.view;
+
+import kst4contest.model.OperatorProfile;
+
+import java.util.List;
+import java.util.Optional;
+
+/**
+ * Asks the operator which profile to start with.
+ *
+ * <p>The startup logic depends on this interface rather than on a dialog, so the
+ * decision which profile to use can be tested without a JavaFX runtime.</p>
+ */
+@FunctionalInterface
+public interface OperatorProfileChoiceRequester {
+
+    /**
+     * Requests a profile choice.
+     *
+     * @param selectableProfiles  profiles to choose from, never empty
+     * @param preselectedProfileId identifier to preselect, may be null
+     * @return the chosen profile, or empty when the operator wants to quit
+     */
+    Optional<OperatorProfile> requestProfileChoice(List<OperatorProfile> selectableProfiles,
+            String preselectedProfileId);
+}

src/main/java/kst4contest/view/OperatorProfilePickerDialog.java

@@ -0,0 +1,143 @@
+package kst4contest.view;
+
+import kst4contest.model.OperatorProfile;
+
+import javafx.geometry.Insets;
+import javafx.scene.Scene;
+import javafx.scene.control.Button;
+import javafx.scene.control.Label;
+import javafx.scene.control.ListCell;
+import javafx.scene.control.ListView;
+import javafx.scene.input.KeyCode;
+import javafx.scene.input.MouseButton;
+import javafx.scene.layout.HBox;
+import javafx.scene.layout.Priority;
+import javafx.scene.layout.VBox;
+import javafx.stage.Modality;
+import javafx.stage.Stage;
+
+import java.util.List;
+import java.util.Optional;
+
+/**
+ * Asks the operator which profile to start with.
+ *
+ * <p>The dialog is shown only when more than one profile exists. It is intentionally
+ * minimal, because it stands between the operator and a contest: the last used profile
+ * is preselected, the list has the focus, and Enter or a double click start immediately.</p>
+ */
+public final class OperatorProfilePickerDialog {
+
+    private OperatorProfilePickerDialog() {
+        // Utility class.
+    }
+
+    /**
+     * Shows the picker and waits for the operator's choice.
+     *
+     * @param selectableProfiles   profiles to choose from
+     * @param preselectedProfileId identifier of the profile to preselect, may be null
+     * @return the chosen profile, or empty when the operator wants to quit
+     */
+    public static Optional<OperatorProfile> showAndSelect(final List<OperatorProfile> selectableProfiles,
+            final String preselectedProfileId) {
+
+        Stage dialogStage = new Stage();
+        GuiUtils.applyApplicationIcon(dialogStage);
+        dialogStage.initModality(Modality.APPLICATION_MODAL);
+        dialogStage.setTitle("Select operator profile");
+
+        ListView<OperatorProfile> profileListView = new ListView<>();
+        profileListView.getItems().addAll(selectableProfiles);
+        profileListView.setCellFactory(listView -> new OperatorProfileListCell());
+        VBox.setVgrow(profileListView, Priority.ALWAYS);
+
+        selectPreselectedProfile(profileListView, selectableProfiles, preselectedProfileId);
+
+        OperatorProfile[] chosenProfile = new OperatorProfile[1];
+
+        Button startButton = new Button("Start");
+        startButton.setDefaultButton(true);
+        startButton.setOnAction(event -> {
+            chosenProfile[0] = profileListView.getSelectionModel().getSelectedItem();
+            dialogStage.close();
+        });
+
+        Button quitButton = new Button("Quit");
+        quitButton.setCancelButton(true);
+        quitButton.setOnAction(event -> {
+            chosenProfile[0] = null;
+            dialogStage.close();
+        });
+
+        profileListView.setOnMouseClicked(event -> {
+            if (event.getButton() == MouseButton.PRIMARY && event.getClickCount() == 2) {
+                startButton.fire();
+            }
+        });
+
+        profileListView.setOnKeyPressed(event -> {
+            if (event.getCode() == KeyCode.ENTER) {
+                startButton.fire();
+            }
+        });
+
+        HBox buttonRow = new HBox(10, startButton, quitButton);
+        buttonRow.setPadding(new Insets(10, 0, 0, 0));
+
+        VBox dialogContent = new VBox(8,
+                new Label("More than one operator profile is configured."),
+                profileListView,
+                buttonRow);
+        dialogContent.setPadding(new Insets(15));
+
+        dialogStage.setScene(new Scene(dialogContent, 380, 280));
+        profileListView.requestFocus();
+        dialogStage.showAndWait();
+
+        return Optional.ofNullable(chosenProfile[0]);
+    }
+
+    private static void selectPreselectedProfile(final ListView<OperatorProfile> profileListView,
+            final List<OperatorProfile> selectableProfiles,
+            final String preselectedProfileId) {
+
+        int profileIndexToSelect = 0;
+
+        if (preselectedProfileId != null) {
+            for (int profileIndex = 0; profileIndex < selectableProfiles.size(); profileIndex++) {
+                if (preselectedProfileId.equalsIgnoreCase(
+                        selectableProfiles.get(profileIndex).getProfileId())) {
+                    profileIndexToSelect = profileIndex;
+                    break;
+                }
+            }
+        }
+
+        profileListView.getSelectionModel().select(profileIndexToSelect);
+        profileListView.scrollTo(profileIndexToSelect);
+    }
+
+    /**
+     * Renders a profile with its name and the kind of worked data it uses.
+     */
+    private static final class OperatorProfileListCell extends ListCell<OperatorProfile> {
+
+        @Override
+        protected void updateItem(final OperatorProfile profile, final boolean empty) {
+
+            super.updateItem(profile, empty);
+
+            if (empty || profile == null) {
+                setText(null);
+                return;
+            }
+
+            String workedDataDescription = profile.isRootProfile() || profile.isSharedWorkedDatabase()
+                    ? "shared station worked database"
+                    : "own worked database";
+
+            setText(profile.getDisplayName() + "\n" + workedDataDescription);
+        }
+    }
+}

src/main/java/kst4contest/view/OperatorProfileSettingsPane.java

@@ -0,0 +1,488 @@
+package kst4contest.view;
+
+import kst4contest.controller.ActiveOperatorProfile;
+import kst4contest.controller.OperatorProfileManagementService;
+import kst4contest.controller.OperatorProfilePaths;
+import kst4contest.model.OperatorProfile;
+import kst4contest.model.OperatorProfileSelection;
+
+import javafx.beans.property.SimpleStringProperty;
+import javafx.geometry.Insets;
+import javafx.scene.control.Alert;
+import javafx.scene.control.Alert.AlertType;
+import javafx.scene.control.Button;
+import javafx.scene.control.ButtonBar;
+import javafx.scene.control.ButtonType;
+import javafx.scene.control.Dialog;
+import javafx.scene.control.Label;
+import javafx.scene.control.RadioButton;
+import javafx.scene.control.TableColumn;
+import javafx.scene.control.TableView;
+import javafx.scene.control.TextField;
+import javafx.scene.control.TextInputDialog;
+import javafx.scene.control.ToggleGroup;
+import javafx.scene.layout.GridPane;
+import javafx.scene.layout.HBox;
+import javafx.scene.layout.Priority;
+import javafx.scene.layout.VBox;
+import javafx.util.Pair;
+
+import java.time.Instant;
+import java.time.ZoneId;
+import java.time.format.DateTimeFormatter;
+import java.util.List;
+import java.util.Optional;
+import java.util.function.Consumer;
+
+/**
+ * Settings tab that manages the operator profiles.
+ *
+ * <p>Every profile keeps its own settings and window layout. Whether it also keeps its
+ * own worked stations is chosen per profile, because a multi operator contest station
+ * shares one log while two operators on a private computer usually do not.</p>
+ */
+public class OperatorProfileSettingsPane extends VBox {
+
+    private static final DateTimeFormatter LAST_USED_FORMATTER =
+            DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm").withZone(ZoneId.systemDefault());
+
+    private final OperatorProfileManagementService managementService;
+    private final Consumer<OperatorProfile> profileActivationRequest;
+
+    private final TableView<OperatorProfile> profileTable = new TableView<>();
+    private final Label activeProfileLabel = new Label();
+    private final Label preferencesPathLabel = new Label();
+    private final Label workedDatabasePathLabel = new Label();
+
+    public OperatorProfileSettingsPane(final OperatorProfileManagementService managementService,
+            final Consumer<OperatorProfile> profileActivationRequest) {
+
+        this.managementService = managementService;
+        this.profileActivationRequest = profileActivationRequest;
+
+        setSpacing(10);
+        setPadding(new Insets(15));
+
+        getChildren().addAll(
+                buildActiveProfileHeader(),
+                buildProfileTable(),
+                buildButtonRows(),
+                buildExplanationLabel());
+
+        refreshActiveProfileHeader();
+        refreshProfileTable();
+    }
+
+    private GridPane buildActiveProfileHeader() {
+
+        GridPane headerGrid = new GridPane();
+        headerGrid.setHgap(10);
+        headerGrid.setVgap(4);
+
+        headerGrid.add(new Label("Active profile:"), 0, 0);
+        headerGrid.add(activeProfileLabel, 1, 0);
+        headerGrid.add(new Label("Settings file:"), 0, 1);
+        headerGrid.add(preferencesPathLabel, 1, 1);
+        headerGrid.add(new Label("Worked stations:"), 0, 2);
+        headerGrid.add(workedDatabasePathLabel, 1, 2);
+
+        return headerGrid;
+    }
+
+    private TableView<OperatorProfile> buildProfileTable() {
+
+        TableColumn<OperatorProfile, String> nameColumn = new TableColumn<>("Profile");
+        nameColumn.setCellValueFactory(cellData ->
+                new SimpleStringProperty(cellData.getValue().getDisplayName()));
+        nameColumn.setPrefWidth(200);
+
+        TableColumn<OperatorProfile, String> workedDataColumn = new TableColumn<>("Worked stations");
+        workedDataColumn.setCellValueFactory(cellData ->
+                new SimpleStringProperty(describeWorkedDataMode(cellData.getValue())));
+        workedDataColumn.setPrefWidth(200);
+
+        TableColumn<OperatorProfile, String> lastUsedColumn = new TableColumn<>("Last used");
+        lastUsedColumn.setCellValueFactory(cellData ->
+                new SimpleStringProperty(describeLastUsed(cellData.getValue())));
+        lastUsedColumn.setPrefWidth(140);
+
+        profileTable.getColumns().add(nameColumn);
+        profileTable.getColumns().add(workedDataColumn);
+        profileTable.getColumns().add(lastUsedColumn);
+        profileTable.setPlaceholder(new Label("No operator profile configured."));
+
+        VBox.setVgrow(profileTable, Priority.ALWAYS);
+
+        return profileTable;
+    }
+
+    private VBox buildButtonRows() {
+
+        Button newProfileButton = new Button("New profile...");
+        newProfileButton.setOnAction(event -> createProfile());
+
+        Button duplicateProfileButton = new Button("Duplicate...");
+        duplicateProfileButton.setOnAction(event -> duplicateSelectedProfile());
+
+        Button renameProfileButton = new Button("Rename...");
+        renameProfileButton.setOnAction(event -> renameSelectedProfile());
+
+        Button deleteProfileButton = new Button("Delete...");
+        deleteProfileButton.setOnAction(event -> deleteSelectedProfile());
+
+        Button changeWorkedDataButton = new Button("Change worked stations...");
+        changeWorkedDataButton.setOnAction(event -> changeWorkedDataModeOfSelectedProfile());
+
+        Button switchProfileButton = new Button("Switch to selected profile...");
+        switchProfileButton.setOnAction(event -> activateSelectedProfile());
+
+        HBox managementRow = new HBox(8,
+                newProfileButton, duplicateProfileButton, renameProfileButton, deleteProfileButton);
+        HBox activationRow = new HBox(8, changeWorkedDataButton, switchProfileButton);
+
+        return new VBox(8, managementRow, activationRow);
+    }
+
+    private Label buildExplanationLabel() {
+
+        Label explanation = new Label(
+                "Each profile has its own settings and window layout. A profile can either share the "
+                        + "common station worked stations, which is what a multi operator station wants, "
+                        + "or keep its own. Duplicating a profile copies everything except callsign and "
+                        + "password, and never copies worked stations.");
+        explanation.setWrapText(true);
+
+        return explanation;
+    }
+
+    private void refreshActiveProfileHeader() {
+
+        OperatorProfileSelection activeProfile = ActiveOperatorProfile.get();
+
+        if (activeProfile == null) {
+            activeProfileLabel.setText("unknown");
+            return;
+        }
+
+        activeProfileLabel.setText(activeProfile.getProfile().getDisplayName());
+        preferencesPathLabel.setText(activeProfile.getPreferencesAbsolutePath());
+        workedDatabasePathLabel.setText(activeProfile.getWorkedDatabaseAbsolutePath());
+    }
+
+    private void refreshProfileTable() {
+
+        List<OperatorProfile> knownProfiles = managementService.listProfiles();
+        OperatorProfile previouslySelected = profileTable.getSelectionModel().getSelectedItem();
+
+        profileTable.getItems().setAll(knownProfiles);
+
+        if (previouslySelected != null && knownProfiles.contains(previouslySelected)) {
+            profileTable.getSelectionModel().select(previouslySelected);
+        } else if (!knownProfiles.isEmpty()) {
+            profileTable.getSelectionModel().select(0);
+        }
+    }
+
+    private void createProfile() {
+
+        Optional<Pair<String, Boolean>> enteredProfile =
+                showProfileCreationDialog("New operator profile", "");
+
+        if (enteredProfile.isEmpty()) {
+            return;
+        }
+
+        OperatorProfile createdProfile = managementService.createProfile(
+                enteredProfile.get().getKey(), enteredProfile.get().getValue());
+
+        if (createdProfile == null) {
+            showError("The profile could not be created. The profile registry could not be written.");
+            return;
+        }
+
+        refreshProfileTable();
+        profileTable.getSelectionModel().select(createdProfile);
+
+        showInformation("The profile \"" + createdProfile.getDisplayName() + "\" was created without "
+                + "callsign and password. Enter them on the Station tab after switching to it.");
+    }
+
+    private void duplicateSelectedProfile() {
+
+        OperatorProfile selectedProfile = requireSelectedProfile();
+
+        if (selectedProfile == null) {
+            return;
+        }
+
+        TextInputDialog nameDialog =
+                new TextInputDialog("Copy of " + selectedProfile.getDisplayName());
+        nameDialog.setTitle("Duplicate operator profile");
+        nameDialog.setHeaderText("Name of the new profile");
+        nameDialog.setContentText(
+                "Everything is copied except callsign and password. Worked stations are never copied.");
+
+        Optional<String> enteredName = nameDialog.showAndWait();
+
+        if (enteredName.isEmpty() || enteredName.get().isBlank()) {
+            return;
+        }
+
+        OperatorProfile duplicatedProfile =
+                managementService.duplicateProfile(selectedProfile, enteredName.get());
+
+        if (duplicatedProfile == null) {
+            showError("The profile could not be duplicated.");
+            return;
+        }
+
+        refreshProfileTable();
+        profileTable.getSelectionModel().select(duplicatedProfile);
+    }
+
+    private void renameSelectedProfile() {
+
+        OperatorProfile selectedProfile = requireSelectedProfile();
+
+        if (selectedProfile == null) {
+            return;
+        }
+
+        TextInputDialog nameDialog = new TextInputDialog(selectedProfile.getDisplayName());
+        nameDialog.setTitle("Rename operator profile");
+        nameDialog.setHeaderText("New name of the profile");
+        nameDialog.setContentText("Files and folders of the profile are not touched.");
+
+        Optional<String> enteredName = nameDialog.showAndWait();
+
+        if (enteredName.isEmpty() || enteredName.get().isBlank()) {
+            return;
+        }
+
+        managementService.renameProfile(selectedProfile, enteredName.get());
+        refreshProfileTable();
+        refreshActiveProfileHeader();
+    }
+
+    private void deleteSelectedProfile() {
+
+        OperatorProfile selectedProfile = requireSelectedProfile();
+
+        if (selectedProfile == null) {
+            return;
+        }
+
+        if (selectedProfile.isRootProfile()) {
+            showError("The default profile uses the files of the installation itself "
+                    + "and cannot be deleted.");
+            return;
+        }
+
+        if (isActiveProfile(selectedProfile)) {
+            showError("The profile currently in use cannot be deleted. Switch to another "
+                    + "profile first.");
+            return;
+        }
+
+        Alert confirmation = new Alert(AlertType.CONFIRMATION);
+        confirmation.setTitle("Delete operator profile");
+        confirmation.setHeaderText("Delete the profile \"" + selectedProfile.getDisplayName() + "\"?");
+        confirmation.setContentText(
+                "The following folder is removed permanently:\n"
+                        + managementService.getProfileDirectory(selectedProfile)
+                        + "\n\n"
+                        + (selectedProfile.isSharedWorkedDatabase()
+                                ? "The common station worked stations are not touched."
+                                : "The worked stations of this profile are deleted as well."));
+
+        ButtonType deleteButton = new ButtonType("Delete profile", ButtonBar.ButtonData.OK_DONE);
+        ButtonType cancelButton = new ButtonType("Cancel", ButtonBar.ButtonData.CANCEL_CLOSE);
+        confirmation.getButtonTypes().setAll(deleteButton, cancelButton);
+
+        if (confirmation.showAndWait().orElse(cancelButton) != deleteButton) {
+            return;
+        }
+
+        if (!managementService.deleteProfile(selectedProfile)) {
+            showError("The profile could not be deleted.");
+        }
+
+        refreshProfileTable();
+    }
+
+    private void changeWorkedDataModeOfSelectedProfile() {
+
+        OperatorProfile selectedProfile = requireSelectedProfile();
+
+        if (selectedProfile == null) {
+            return;
+        }
+
+        if (selectedProfile.isRootProfile()) {
+            showError("The default profile always uses the common station worked stations, "
+                    + "because that database is the one of the installation itself.");
+            return;
+        }
+
+        Optional<Boolean> chosenMode = showWorkedDataModeDialog(selectedProfile);
+
+        if (chosenMode.isEmpty() || chosenMode.get() == selectedProfile.isSharedWorkedDatabase()) {
+            return;
+        }
+
+        managementService.setSharedWorkedDatabase(selectedProfile, chosenMode.get());
+        refreshProfileTable();
+
+        if (isActiveProfile(selectedProfile)) {
+            showInformation("The change takes effect after switching to this profile again.");
+        }
+    }
+
+    private void activateSelectedProfile() {
+
+        OperatorProfile selectedProfile = requireSelectedProfile();
+
+        if (selectedProfile == null) {
+            return;
+        }
+
+        if (isActiveProfile(selectedProfile)) {
+            showInformation("This profile is already active.");
+            return;
+        }
+
+        profileActivationRequest.accept(selectedProfile);
+    }
+
+    private Optional<Pair<String, Boolean>> showProfileCreationDialog(final String title,
+            final String initialName) {
+
+        Dialog<Pair<String, Boolean>> creationDialog = new Dialog<>();
+        creationDialog.setTitle(title);
+        creationDialog.setHeaderText("Name and worked stations of the new profile");
+
+        ButtonType createButton = new ButtonType("Create profile", ButtonBar.ButtonData.OK_DONE);
+        ButtonType cancelButton = new ButtonType("Cancel", ButtonBar.ButtonData.CANCEL_CLOSE);
+        creationDialog.getDialogPane().getButtonTypes().setAll(createButton, cancelButton);
+
+        TextField nameField = new TextField(initialName);
+        nameField.setPromptText("for example DN9APW");
+
+        ToggleGroup workedDataGroup = new ToggleGroup();
+
+        RadioButton ownDatabaseOption = new RadioButton("Own worked stations for this profile");
+        ownDatabaseOption.setToggleGroup(workedDataGroup);
+        ownDatabaseOption.setSelected(true);
+
+        RadioButton sharedDatabaseOption =
+                new RadioButton("Share the common station worked stations (multi operator station)");
+        sharedDatabaseOption.setToggleGroup(workedDataGroup);
+
+        VBox dialogContent = new VBox(8,
+                new Label("Profile name"),
+                nameField,
+                new Label("Worked stations"),
+                ownDatabaseOption,
+                sharedDatabaseOption);
+        dialogContent.setPadding(new Insets(10));
+
+        creationDialog.getDialogPane().setContent(dialogContent);
+
+        creationDialog.setResultConverter(pressedButton -> {
+            if (pressedButton != createButton || nameField.getText().isBlank()) {
+                return null;
+            }
+
+            return new Pair<>(nameField.getText().trim(), sharedDatabaseOption.isSelected());
+        });
+
+        return creationDialog.showAndWait();
+    }
+
+    private Optional<Boolean> showWorkedDataModeDialog(final OperatorProfile profile) {
+
+        Dialog<Boolean> modeDialog = new Dialog<>();
+        modeDialog.setTitle("Worked stations");
+        modeDialog.setHeaderText("Worked stations of \"" + profile.getDisplayName() + "\"");
+
+        ButtonType applyButton = new ButtonType("Apply", ButtonBar.ButtonData.OK_DONE);
+        ButtonType cancelButton = new ButtonType("Cancel", ButtonBar.ButtonData.CANCEL_CLOSE);
+        modeDialog.getDialogPane().getButtonTypes().setAll(applyButton, cancelButton);
+
+        ToggleGroup workedDataGroup = new ToggleGroup();
+
+        RadioButton ownDatabaseOption = new RadioButton("Own worked stations for this profile");
+        ownDatabaseOption.setToggleGroup(workedDataGroup);
+
+        RadioButton sharedDatabaseOption =
+                new RadioButton("Share the common station worked stations (multi operator station)");
+        sharedDatabaseOption.setToggleGroup(workedDataGroup);
+
+        sharedDatabaseOption.setSelected(profile.isSharedWorkedDatabase());
+        ownDatabaseOption.setSelected(!profile.isSharedWorkedDatabase());
+
+        Label pathHint = new Label("Switching does not move any data. Worked stations already "
+                + "collected under the other setting stay where they are.");
+        pathHint.setWrapText(true);
+
+        VBox dialogContent = new VBox(8, ownDatabaseOption, sharedDatabaseOption, pathHint);
+        dialogContent.setPadding(new Insets(10));
+
+        modeDialog.getDialogPane().setContent(dialogContent);
+        modeDialog.setResultConverter(pressedButton ->
+                pressedButton == applyButton ? sharedDatabaseOption.isSelected() : null);
+
+        return modeDialog.showAndWait();
+    }
+
+    private OperatorProfile requireSelectedProfile() {
+
+        OperatorProfile selectedProfile = profileTable.getSelectionModel().getSelectedItem();
+
+        if (selectedProfile == null) {
+            showInformation("Select a profile in the table first.");
+        }
+
+        return selectedProfile;
+    }
+
+    private static boolean isActiveProfile(final OperatorProfile profile) {
+
+        OperatorProfileSelection activeProfile = ActiveOperatorProfile.get();
+
+        return activeProfile != null
+                && activeProfile.getProfile().getProfileId().equals(profile.getProfileId());
+    }
+
+    private static String describeWorkedDataMode(final OperatorProfile profile) {
+
+        if (profile.isRootProfile() || profile.isSharedWorkedDatabase()) {
+            return "common station database";
+        }
+
+        return "own database";
+    }
+
+    private static String describeLastUsed(final OperatorProfile profile) {
+
+        if (profile.getLastUsedEpochMs() <= 0L) {
+            return "";
+        }
+
+        return LAST_USED_FORMATTER.format(Instant.ofEpochMilli(profile.getLastUsedEpochMs()));
+    }
+
+    private static void showInformation(final String message) {
+        Alert information = new Alert(AlertType.INFORMATION);
+        information.setTitle("Operator profiles");
+        information.setContentText(message);
+        information.showAndWait();
+    }
+
+    private static void showError(final String message) {
+        Alert error = new Alert(AlertType.ERROR);
+        error.setTitle("Operator profiles");
+        error.setContentText(message);
+        error.showAndWait();
+    }
+}

src/main/java/kst4contest/view/PrivateMessageRowStyleResolver.java

@@ -0,0 +1,83 @@
+package kst4contest.view;
+
+import java.util.List;
+
+/**
+ * Selects the CSS style class used for a private-message table row.
+ */
+public final class PrivateMessageRowStyleResolver {
+
+    /** Style used for messages sent by the local station. */
+    public static final String OWN_STYLE_CLASS =
+            "messageHighlightOwn-column";
+
+    /** Upper inclusive age bounds for the private-message color levels. */
+    private static final List<Long> AGE_LIMITS = List.of(
+            30L,
+            60L,
+            90L,
+            120L,
+            180L,
+            300L
+    );
+
+    /** Style classes corresponding to the configured age bounds. */
+    private static final List<String> AGE_STYLES = List.of(
+            "messageHighlight30-column",
+            "messageHighlight60-column",
+            "messageHighlight90-column",
+            "messageHighlight120-column",
+            "messageHighlight180-column",
+            "messageHighlight300-column"
+    );
+
+    /** All private-message row classes managed by the row factory. */
+    private static final List<String> MANAGED_STYLES = List.of(
+            OWN_STYLE_CLASS,
+            AGE_STYLES.get(0),
+            AGE_STYLES.get(1),
+            AGE_STYLES.get(2),
+            AGE_STYLES.get(3),
+            AGE_STYLES.get(4),
+            AGE_STYLES.get(5)
+    );
+
+    private PrivateMessageRowStyleResolver() {
+    }
+
+    /**
+     * Returns the complete set of private-message row classes managed by the
+     * row factory.
+     *
+     * @return immutable list of managed style classes
+     */
+    public static List<String> knownStyleClasses() {
+        return MANAGED_STYLES;
+    }
+
+    /**
+     * Selects the private-message row class for the supplied message age.
+     *
+     * @param ownMessage whether the message was sent by the local station
+     * @param ageSeconds message age in seconds
+     * @return managed CSS class, or {@code null} after the five-minute window
+     */
+    public static String resolveStyleClass(
+            final boolean ownMessage,
+            final long ageSeconds
+    ) {
+        String styleClass = null;
+        if (ownMessage) {
+            styleClass = OWN_STYLE_CLASS;
+        } else {
+            for (int index = 0; index < AGE_LIMITS.size(); index++) {
+                if (ageSeconds <= AGE_LIMITS.get(index)) {
+                    styleClass = AGE_STYLES.get(index);
+                    break;
+                }
+            }
+        }
+
+        return styleClass;
+    }
+}

src/main/java/kst4contest/view/TableLayoutManager.java

@@ -0,0 +1,280 @@
+package kst4contest.view;
+
+import javafx.application.Platform;
+import javafx.beans.value.ObservableValue;
+import javafx.collections.ListChangeListener;
+import javafx.scene.Node;
+import javafx.scene.control.TableColumn;
+import javafx.scene.control.TableView;
+import javafx.scene.input.MouseEvent;
+import javafx.scene.text.Font;
+import javafx.scene.text.Text;
+import kst4contest.model.ChatPreferences;
+
+import java.util.IdentityHashMap;
+import java.util.Map;
+import java.util.Objects;
+import java.util.OptionalDouble;
+
+/**
+ * Applies persisted leaf-column widths and performs one content-based initial
+ * sizing pass when no width has been stored yet.
+ */
+public final class TableLayoutManager {
+
+    private static final double CELL_HORIZONTAL_PADDING = 16.0;
+    private static final double DEFAULT_MINIMUM_WIDTH = 24.0;
+
+    private TableLayoutManager() {
+    }
+
+    public static ColumnSpec column(String id, TableColumn<?, String> column) {
+        return new ColumnSpec(id, column);
+    }
+
+    public static <S> void install(
+            TableView<S> table,
+            String tableId,
+            ChatPreferences preferences,
+            LayoutAutosave autosave,
+            ColumnSpec... columnSpecs
+    ) {
+        Objects.requireNonNull(table, "table");
+        Objects.requireNonNull(tableId, "tableId");
+        Objects.requireNonNull(preferences, "preferences");
+        Objects.requireNonNull(autosave, "autosave");
+
+        Map<TableColumn<?, String>, ColumnState> states = new IdentityHashMap<>();
+        for (ColumnSpec spec : columnSpecs) {
+            if (spec == null || !spec.column.getColumns().isEmpty()) {
+                continue;
+            }
+
+            if (spec.column.prefWidthProperty().isBound()) {
+                spec.column.prefWidthProperty().unbind();
+            }
+            spec.column.setId(tableId + "." + spec.id);
+
+            OptionalDouble storedWidth = preferences.getTableColumnWidth(tableId, spec.id);
+            ColumnState state = new ColumnState(spec, storedWidth.isEmpty());
+            states.put(spec.column, state);
+
+            if (storedWidth.isPresent()) {
+                setWidth(state, storedWidth.getAsDouble());
+                state.initialized = true;
+            }
+
+            spec.column.widthProperty().addListener((observable, oldWidth, newWidth) -> {
+                if (state.adjusting || !state.initialized || newWidth == null) {
+                    return;
+                }
+                storeWidth(preferences, autosave, tableId, state.spec.id, newWidth.doubleValue());
+            });
+        }
+
+        installEarlyManualResizeDetection(table, tableId, preferences, autosave, states);
+        scheduleInitialSizingWhenUsable(table, tableId, preferences, autosave, states);
+    }
+
+    private static <S> void scheduleInitialSizingWhenUsable(
+            TableView<S> table,
+            String tableId,
+            ChatPreferences preferences,
+            LayoutAutosave autosave,
+            Map<TableColumn<?, String>, ColumnState> states
+    ) {
+        if (states.values().stream().noneMatch(state -> !state.initialized)) {
+            return;
+        }
+
+        if (table.getItems() != null && !table.getItems().isEmpty()) {
+            Platform.runLater(() -> sizePendingColumns(table, tableId, preferences, autosave, states));
+            return;
+        }
+
+        @SuppressWarnings("unchecked")
+        final ListChangeListener<S>[] holder = new ListChangeListener[1];
+        holder[0] = change -> {
+            if (table.getItems() == null || table.getItems().isEmpty()) {
+                return;
+            }
+            table.getItems().removeListener(holder[0]);
+            Platform.runLater(() -> sizePendingColumns(table, tableId, preferences, autosave, states));
+        };
+        table.getItems().addListener(holder[0]);
+    }
+
+    private static <S> void sizePendingColumns(
+            TableView<S> table,
+            String tableId,
+            ChatPreferences preferences,
+            LayoutAutosave autosave,
+            Map<TableColumn<?, String>, ColumnState> states
+    ) {
+        for (ColumnState state : states.values()) {
+            if (state.initialized) {
+                continue;
+            }
+
+            double width = state.spec.flexible
+                    ? flexibleInitialWidth(table, state.spec)
+                    : contentInitialWidth(table, state.spec);
+            setWidth(state, width);
+            state.initialized = true;
+            storeWidth(preferences, autosave, tableId, state.spec.id, width);
+        }
+    }
+
+    private static <S> double contentInitialWidth(TableView<S> table, ColumnSpec spec) {
+        Text measurement = new Text();
+        measurement.setFont(Font.getDefault());
+        double requiredWidth = measure(spec.column.getText(), measurement);
+        for (int rowIndex = 0; rowIndex < table.getItems().size(); rowIndex++) {
+            ObservableValue<?> value = spec.column.getCellObservableValue(rowIndex);
+            if (value == null || value.getValue() == null) {
+                continue;
+            }
+            requiredWidth = Math.max(
+                    requiredWidth,
+                    measure(String.valueOf(value.getValue()), measurement)
+            );
+        }
+        return calculateInitialContentWidth(
+                requiredWidth,
+                spec.minimumWidth,
+                spec.maximumInitialWidth
+        );
+    }
+
+    private static <S> double flexibleInitialWidth(TableView<S> table, ColumnSpec spec) {
+        double tableShare = table.getWidth() > 1.0 ? table.getWidth() * 0.42 : spec.flexibleFallbackWidth;
+        Text measurement = new Text();
+        measurement.setFont(Font.getDefault());
+        double headerWidth = measure(spec.column.getText(), measurement) + CELL_HORIZONTAL_PADDING;
+        return clamp(Math.max(headerWidth, tableShare), spec.minimumWidth, spec.maximumInitialWidth);
+    }
+
+    private static <S> void installEarlyManualResizeDetection(
+            TableView<S> table,
+            String tableId,
+            ChatPreferences preferences,
+            LayoutAutosave autosave,
+            Map<TableColumn<?, String>, ColumnState> states
+    ) {
+        Map<TableColumn<?, String>, Double> widthsAtHeaderPress = new IdentityHashMap<>();
+        table.addEventFilter(MouseEvent.MOUSE_PRESSED, event -> {
+            if (!isColumnHeaderEvent(event)) {
+                return;
+            }
+            widthsAtHeaderPress.clear();
+            states.forEach((column, state) -> widthsAtHeaderPress.put(column, column.getWidth()));
+        });
+        table.addEventFilter(MouseEvent.MOUSE_RELEASED, event -> {
+            if (widthsAtHeaderPress.isEmpty()) {
+                return;
+            }
+            states.forEach((column, state) -> {
+                Double oldWidth = widthsAtHeaderPress.get(column);
+                if (oldWidth == null || Math.abs(oldWidth - column.getWidth()) <= 0.5) {
+                    return;
+                }
+                state.initialized = true;
+                storeWidth(preferences, autosave, tableId, state.spec.id, column.getWidth());
+            });
+            widthsAtHeaderPress.clear();
+        });
+    }
+
+    private static boolean isColumnHeaderEvent(MouseEvent event) {
+        Object target = event.getTarget();
+        Node node = target instanceof Node ? (Node) target : null;
+        while (node != null && node.getParent() != null) {
+            if (node.getStyleClass().contains("column-header")
+                    || node.getStyleClass().contains("nested-column-header")) {
+                return true;
+            }
+            node = node.getParent();
+        }
+        return false;
+    }
+
+    private static void setWidth(ColumnState state, double width) {
+        state.adjusting = true;
+        try {
+            state.spec.column.setPrefWidth(width);
+        } finally {
+            state.adjusting = false;
+        }
+    }
+
+    private static void storeWidth(
+            ChatPreferences preferences,
+            LayoutAutosave autosave,
+            String tableId,
+            String columnId,
+            double width
+    ) {
+        preferences.setTableColumnWidth(tableId, columnId, width);
+        autosave.requestSave();
+    }
+
+    private static double measure(String value, Text measurement) {
+        measurement.setText(value == null ? "" : value);
+        return measurement.getLayoutBounds().getWidth();
+    }
+
+    private static double clamp(double value, double minimum, double maximum) {
+        return Math.max(minimum, Math.min(value, maximum));
+    }
+
+    /**
+     * Calculates a compact content width. Package-private for focused sizing tests.
+     */
+    @SuppressWarnings("PMD.CommentDefaultAccessModifier")
+    static double calculateInitialContentWidth(
+            final double measuredWidth,
+            final double minimum,
+            final double maximum
+    ) {
+        return clamp(measuredWidth + CELL_HORIZONTAL_PADDING, minimum, maximum);
+    }
+
+    public static final class ColumnSpec {
+        private final String id;
+        private final TableColumn<?, String> column;
+        private double minimumWidth = DEFAULT_MINIMUM_WIDTH;
+        private double maximumInitialWidth = Double.MAX_VALUE;
+        private double flexibleFallbackWidth = 320.0;
+        private boolean flexible;
+
+        private ColumnSpec(String id, TableColumn<?, String> column) {
+            if (id == null || id.isBlank()) {
+                throw new IllegalArgumentException("Column id must not be blank");
+            }
+            this.id = id;
+            this.column = Objects.requireNonNull(column, "column");
+        }
+
+        public ColumnSpec maximumInitialWidth(double maximumInitialWidth) {
+            this.maximumInitialWidth = maximumInitialWidth;
+            return this;
+        }
+
+        public ColumnSpec flexible(double fallbackWidth) {
+            flexible = true;
+            flexibleFallbackWidth = fallbackWidth;
+            return this;
+        }
+    }
+
+    private static final class ColumnState {
+        private final ColumnSpec spec;
+        private boolean adjusting;
+        private boolean initialized;
+
+        private ColumnState(ColumnSpec spec, boolean awaitingInitialSizing) {
+            this.spec = spec;
+            initialized = !awaitingInitialSizing;
+        }
+    }
+}

src/main/java/kst4contest/view/TruncatedTextTableCell.java

@@ -0,0 +1,109 @@
+package kst4contest.view;
+
+import javafx.scene.control.TableCell;
+import javafx.scene.control.Tooltip;
+import javafx.scene.text.Text;
+import javafx.util.Duration;
+
+import java.util.function.Function;
+import java.util.function.BiFunction;
+
+/**
+ * Displays text normally and exposes the full value only when it is clipped.
+ * An optional functional explanation remains available and is combined with
+ * the full value when both are needed.
+ */
+public class TruncatedTextTableCell<S> extends TableCell<S, String> {
+
+    private final Function<String, String> formatter;
+    private final BiFunction<S, String, String> functionalTooltipProvider;
+    private final Tooltip tooltip = new Tooltip();
+    private final Text textMeasurement = new Text();
+    private String fullText = "";
+
+    public TruncatedTextTableCell() {
+        this(Function.identity(), null);
+    }
+
+    public TruncatedTextTableCell(Function<String, String> formatter) {
+        this(formatter, null);
+    }
+
+    public TruncatedTextTableCell(
+            Function<String, String> formatter,
+            BiFunction<S, String, String> functionalTooltipProvider
+    ) {
+        this.formatter = formatter == null ? Function.identity() : formatter;
+        this.functionalTooltipProvider = functionalTooltipProvider;
+        tooltip.setWrapText(true);
+        tooltip.setMaxWidth(800);
+        tooltip.setShowDelay(Duration.millis(250));
+        tooltip.setShowDuration(Duration.seconds(30));
+    }
+
+    @Override
+    protected void updateItem(String item, boolean empty) {
+        super.updateItem(item, empty);
+        if (empty || item == null) {
+            fullText = "";
+            setText(null);
+            setGraphic(null);
+            setTooltip(null);
+            return;
+        }
+
+        String formatted = formatter.apply(item);
+        fullText = formatted == null ? "" : formatted;
+        setText(fullText);
+        setGraphic(null);
+        updateTooltip();
+    }
+
+    @Override
+    protected void layoutChildren() {
+        super.layoutChildren();
+        updateTooltip();
+    }
+
+    private void updateTooltip() {
+        if (isEmpty()) {
+            setTooltip(null);
+            return;
+        }
+
+        String functionalText = resolveFunctionalTooltip();
+        boolean clipped = isTextClipped();
+        String tooltipText = TruncatedTextTooltipSupport.buildTooltipText(
+                fullText,
+                clipped,
+                functionalText
+        );
+        if (tooltipText == null) {
+            setTooltip(null);
+            return;
+        }
+
+        tooltip.setText(tooltipText);
+        setTooltip(tooltip);
+    }
+
+    private String resolveFunctionalTooltip() {
+        if (functionalTooltipProvider == null || getTableRow() == null) {
+            return null;
+        }
+        return functionalTooltipProvider.apply(getTableRow().getItem(), fullText);
+    }
+
+    private boolean isTextClipped() {
+        if (fullText.isEmpty()) {
+            return false;
+        }
+
+        textMeasurement.setText(fullText);
+        textMeasurement.setFont(getFont());
+        double requiredWidth = textMeasurement.getLayoutBounds().getWidth();
+        double availableWidth = Math.max(0.0,
+                getWidth() - snappedLeftInset() - snappedRightInset() - 2.0);
+        return TruncatedTextTooltipSupport.isTextClipped(requiredWidth, availableWidth);
+    }
+}

src/main/java/kst4contest/view/TruncatedTextTooltipSupport.java

@@ -0,0 +1,28 @@
+package kst4contest.view;
+
+/**
+ * Pure tooltip decisions kept separate from JavaFX controls for unit testing.
+ */
+final class TruncatedTextTooltipSupport {
+
+    private TruncatedTextTooltipSupport() {
+    }
+
+    static boolean isTextClipped(double requiredWidth, double availableWidth) {
+        return requiredWidth > availableWidth + 1.0;
+    }
+
+    static String buildTooltipText(String fullText, boolean clipped, String functionalText) {
+        boolean hasFunctionalText = functionalText != null && !functionalText.isBlank();
+        if (!clipped && !hasFunctionalText) {
+            return null;
+        }
+        if (!clipped) {
+            return functionalText;
+        }
+        if (!hasFunctionalText) {
+            return fullText;
+        }
+        return fullText + "\n\n" + functionalText;
+    }
+}