Document that a sandboxed logging program needs its own network permission

A logging program started as a Flatpak, or through a Wine environment
such as Bottles, uses the network permissions of that sandbox. Without
shared=network its 127.0.0.1 is not the loopback KST4Contest listens on,
so the connection is refused although KST4Contest reports the port
correctly.

Adds the check and the override command to the DX Cluster troubleshooting
section in both language versions, and notes that the published
KST4Contest Flatpak manifest already carries --share=network.

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/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,60 @@
+---
+name: Bug Report
+about: Report a problem with KST4Contest / Ein Problem mit KST4Contest melden
+title: "[BUG] "
+labels: bug
+---
+
+**DE:** Bitte fülle alle Felder so vollständig wie möglich aus. Das hilft, den Fehler schneller zu finden.
+**EN:** Please fill in all fields as completely as possible. This helps to find the bug faster.
+
+## Description / Beschreibung
+
+<!-- EN: A clear and concise description of the bug. -->
+<!-- DE: Eine klare und präzise Beschreibung des Problems. -->
+
+## Steps to reproduce / Schritte zum Reproduzieren
+
+<!-- EN: Step-by-step instructions to reproduce the bug. -->
+<!-- DE: Schritt-für-Schritt-Anleitung, um den Fehler zu reproduzieren. -->
+
+1.
+2.
+3.
+
+## Expected behaviour / Erwartetes Verhalten
+
+<!-- EN: What did you expect to happen? / DE: Was hätte passieren sollen? -->
+
+## Actual behaviour / Tatsächliches Verhalten
+
+<!-- EN: What actually happened? / DE: Was ist stattdessen passiert? -->
+
+## Log file content / Inhalt der Logdatei
+
+**EN:** Please paste the content of the error log file here. It is written automatically and contains error messages only — no personal data.
+**DE:** Bitte füge hier den Inhalt der Fehler-Logdatei ein. Sie wird automatisch geschrieben und enthält nur Fehlermeldungen — keine persönlichen Daten.
+
+| OS | Path / Pfad |
+|----|-------------|
+| Linux / macOS | `~/.praktiKST/kst4contest-errors.log` |
+| Windows | `C:\Users\<YourName>\.praktiKST\kst4contest-errors.log` |
+
+```
+Paste log content here / Loginhalt hier einfügen
+```
+
+## Version
+
+**KST4Contest version / Version** (e.g. 1.41.0):
+
+**Java version / Java-Version** (`java -version`, e.g. 17.0.9):
+
+**Operating system / Betriebssystem:** <!-- Linux / Windows / macOS -->
+
+**Logging software / Logprogramm** (if applicable / falls relevant, e.g. UCXLog, N1MM+, WinTest):
+
+## Checklist / Checkliste
+
+- [ ] I have attached the log file / Ich habe die Logdatei angehängt
+- [ ] I have checked that this issue has not been reported before / Ich habe geprüft, dass dieses Problem noch nicht gemeldet wurde

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: false

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,33 @@
+---
+name: Feature Request
+about: Suggest a new feature or improvement / Neue Funktion oder Verbesserung vorschlagen
+title: "[FEATURE] "
+labels: enhancement
+---
+
+**DE:** Bitte beschreibe deine Idee so genau wie möglich.
+**EN:** Please describe your idea as precisely as possible.
+
+## Summary / Zusammenfassung
+
+<!-- EN: A short summary of the feature you'd like. -->
+<!-- DE: Eine kurze Zusammenfassung der gewünschten Funktion. -->
+
+## Motivation / Begründung
+
+<!-- EN: Why would this feature be useful? What problem does it solve? -->
+<!-- DE: Warum wäre diese Funktion nützlich? Welches Problem löst sie? -->
+
+## Detailed description / Detaillierte Beschreibung
+
+<!-- EN: Describe the feature in detail. How should it work? -->
+<!-- DE: Beschreibe die Funktion im Detail. Wie soll sie funktionieren? -->
+
+## Alternatives considered / Geprüfte Alternativen
+
+<!-- EN: Have you considered any alternative solutions or workarounds? -->
+<!-- DE: Hast du alternative Lösungen oder Workarounds in Betracht gezogen? -->
+
+## Checklist / Checkliste
+
+- [ ] I have checked that this feature has not been requested before / Ich habe geprüft, dass diese Funktion noch nicht angefragt wurde

.github/latex-manual/manual-template.tex

@@ -0,0 +1,259 @@
+%% ============================================================
+%%  KST4Contest – pandoc LaTeX manual template
+%%  PDF engine: XeLaTeX
+%%  Usage: pandoc --template=manual-template.tex --pdf-engine=xelatex
+%% ============================================================
+\documentclass[11pt,a4paper]{article}
+
+%% ─── Font / encoding ──────────────────────────────────────────────────────
+\usepackage{fontspec}
+% Latin Modern handles all Western European characters (umlauts etc.)
+\defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
+
+%% ─── Language ─────────────────────────────────────────────────────────────
+\usepackage{polyglossia}
+$if(polyglossia-lang)$
+\setmainlanguage{$polyglossia-lang$}
+$else$
+\setmainlanguage{english}
+$endif$
+
+%% ─── Page layout ──────────────────────────────────────────────────────────
+\usepackage[a4paper, top=2.5cm, bottom=2.5cm, left=2.5cm, right=2.5cm]{geometry}
+
+%% ─── Text decorations (strikethrough via ~~...~~ in Markdown → \st{}) ────
+\usepackage{soul}
+
+%% ─── Colors ───────────────────────────────────────────────────────────────
+\usepackage[dvipsnames,svgnames,x11names]{xcolor}
+\definecolor{brand-green}{RGB}{7,166,54}
+\definecolor{link-blue}{RGB}{0,86,163}
+\definecolor{code-bg}{RGB}{245,247,250}
+\definecolor{code-border}{RGB}{180,200,225}
+\definecolor{blockquote-line}{RGB}{7,166,54}
+
+%% ─── Hyperlinks ───────────────────────────────────────────────────────────
+\usepackage{hyperref}
+\hypersetup{
+  colorlinks  = true,
+  linkcolor   = link-blue,
+  urlcolor    = link-blue,
+  filecolor   = link-blue,
+  citecolor   = link-blue,
+  pdftitle    = {$title$},
+  pdfauthor   = {DO5AMF (Marc Fröhlich), DN9APW (Philipp Wagner)},
+  pdfsubject  = {KST4Contest User Manual},
+  pdfkeywords = {KST4Contest, pratiKST, VHF, Contest, Ham Radio},
+  bookmarks            = true,
+  bookmarksnumbered    = true,
+  bookmarksopen        = true,
+  bookmarksopenlevel   = 2,
+  pdfpagemode          = UseOutlines,
+}
+
+%% ─── Graphics ─────────────────────────────────────────────────────────────
+\usepackage{graphicx}
+\graphicspath{{./}{./github_docs/}}
+\makeatletter
+\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
+\def\maxheight{\ifdim\Gin@nat@height>0.65\textheight 0.65\textheight\else\Gin@nat@height\fi}
+\makeatother
+\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
+
+%% ─── Tables ───────────────────────────────────────────────────────────────
+\usepackage{longtable}
+\usepackage{booktabs}
+\usepackage{array}
+\usepackage{calc}
+\usepackage{multirow}
+\setlength{\tabcolsep}{8pt}
+\renewcommand{\arraystretch}{1.35}
+% Pandoc pipe-table helpers
+\newcolumntype{L}[1]{>{\raggedright\arraybackslash}p{#1}}
+\newcolumntype{C}[1]{>{\centering\arraybackslash}p{#1}}
+\newcolumntype{R}[1]{>{\raggedleft\arraybackslash}p{#1}}
+
+%% ─── Lists ────────────────────────────────────────────────────────────────
+\providecommand{\tightlist}{%
+  \setlength{\itemsep}{2pt}\setlength{\parskip}{0pt}}
+
+%% ─── Code blocks (--listings flag) ───────────────────────────────────
+\usepackage{listings}
+\lstset{
+  basicstyle       = \ttfamily\small,
+  backgroundcolor  = \color{code-bg},
+  frame            = single,
+  framesep         = 4pt,
+  rulecolor        = \color{code-border},
+  breaklines       = true,
+  breakatwhitespace= false,
+  showstringspaces = false,
+  extendedchars    = true,
+  xleftmargin      = 6pt,
+  xrightmargin     = 6pt,
+  aboveskip        = 8pt,
+  belowskip        = 8pt,
+  literate         = {→}{{\ensuremath{\rightarrow}}}1
+                     {←}{{\ensuremath{\leftarrow}}}1
+                     {↔}{{\ensuremath{\leftrightarrow}}}1
+                     {…}{{\ldots}}1,
+}
+
+%% ─── Blockquotes ──────────────────────────────────────────────────────────
+\usepackage{mdframed}
+\newmdenv[
+  topline      = false,
+  rightline    = false,
+  bottomline   = false,
+  leftline     = true,
+  linewidth    = 3pt,
+  linecolor    = blockquote-line,
+  backgroundcolor = code-bg,
+  leftmargin   = 0pt,
+  rightmargin  = 0pt,
+  innerleftmargin  = 12pt,
+  innerrightmargin = 8pt,
+  innertopmargin   = 6pt,
+  innerbottommargin= 6pt,
+  skipabove    = 8pt,
+  skipbelow    = 8pt,
+]{blockquotebox}
+
+\renewenvironment{quote}
+  {\begin{blockquotebox}\small\itshape}
+  {\end{blockquotebox}}
+
+%% ─── Section styling ──────────────────────────────────────────────────────
+\usepackage{titlesec}
+
+\titleformat{\section}
+  {\Large\bfseries\color{brand-green}}
+  {}
+  {0em}
+  {}
+  [\color{brand-green}\titlerule]
+\titlespacing{\section}{0pt}{20pt}{10pt}
+
+\titleformat{\subsection}
+  {\large\bfseries\color{brand-green}}
+  {}
+  {0em}
+  {}
+\titlespacing{\subsection}{0pt}{14pt}{6pt}
+
+\titleformat{\subsubsection}
+  {\normalsize\bfseries}
+  {}
+  {0em}
+  {}
+\titlespacing{\subsubsection}{0pt}{10pt}{4pt}
+
+% Level 4 (####): displayed as a named block heading in dark-grey
+\titleformat{\paragraph}
+  {\normalsize\bfseries\color{brand-green}}
+  {}
+  {0em}
+  {}
+\titlespacing{\paragraph}{0pt}{8pt}{2pt}
+
+% Level 5 (#####): slightly smaller, italic, lighter grey
+\titleformat{\subparagraph}
+  {\small\bfseries\itshape\color{brand-green!85!black}}
+  {}
+  {0em}
+  {}
+\titlespacing{\subparagraph}{0pt}{6pt}{1pt}
+
+% Reserve two additional section levels for future use (###### and deeper).
+% Pandoc currently maps up to \subparagraph for standard Markdown headings.
+\titleclass{\subsubsubsection}{straight}[\subparagraph]
+\newcounter{subsubsubsection}[subparagraph]
+\renewcommand\thesubsubsubsection{\thesubparagraph.\arabic{subsubsubsection}}
+\titleformat{\subsubsubsection}
+  {\small\bfseries\color{brand-green!75!black}}
+  {}
+  {0em}
+  {}
+\titlespacing{\subsubsubsection}{0pt}{5pt}{1pt}
+
+\titleclass{\subsubsubsubsection}{straight}[\subsubsubsection]
+\newcounter{subsubsubsubsection}[subsubsubsection]
+\renewcommand\thesubsubsubsubsection{\thesubsubsubsection.\arabic{subsubsubsubsection}}
+\titleformat{\subsubsubsubsection}
+  {\small\itshape\color{brand-green!65!black}}
+  {}
+  {0em}
+  {}
+\titlespacing{\subsubsubsubsection}{0pt}{4pt}{1pt}
+
+\setcounter{secnumdepth}{6}
+\setcounter{tocdepth}{6}
+
+%% ─── Header / Footer ──────────────────────────────────────────────────────
+\usepackage{fancyhdr}
+\pagestyle{fancy}
+\fancyhf{}
+\fancyhead[L]{\small\color{brand-green}\textbf{KST4Contest}}
+\fancyhead[R]{\small\color{brand-green}$if(version)$$version$$endif$}
+\fancyfoot[L]{\small\color{gray}DO5AMF \textbar\ DN9APW}
+\fancyfoot[C]{\small\color{gray}\thepage}
+\fancyfoot[R]{\small\color{gray}$title$}
+\renewcommand{\headrulewidth}{0.4pt}
+\renewcommand{\footrulewidth}{0.3pt}
+\renewcommand{\headrule}{\color{brand-green}\hrule width\headwidth height\headrulewidth}
+
+%% ─── Paragraph spacing ────────────────────────────────────────────────────
+\usepackage{parskip}
+\setlength{\parskip}{6pt}
+\setlength{\parindent}{0pt}
+
+%% ─── TOC styling ──────────────────────────────────────────────────────────
+\usepackage{tocloft}
+\renewcommand{\cfttoctitlefont}{\Large\bfseries\color{brand-green}}
+\renewcommand{\cftsecfont}{\bfseries\color{brand-green}}
+\renewcommand{\cftsecpagefont}{\bfseries\color{brand-green}}
+\renewcommand{\cftsubsecfont}{\color{brand-green}}
+\renewcommand{\cftsubsecpagefont}{\color{brand-green}}
+\renewcommand{\cftsubsubsecfont}{\color{brand-green!85!black}}
+\renewcommand{\cftsubsubsecpagefont}{\color{brand-green!85!black}}
+\renewcommand{\cftparafont}{\color{brand-green!75!black}}
+\renewcommand{\cftparapagefont}{\color{brand-green!75!black}}
+\renewcommand{\cftsubparafont}{\color{brand-green!65!black}}
+\renewcommand{\cftsubparapagefont}{\color{brand-green!65!black}}
+\setlength{\cftbeforesecskip}{4pt}
+
+%% ─── Misc ─────────────────────────────────────────────────────────────────
+\usepackage{amsmath}
+\usepackage{microtype}
+% Pandoc helper macros
+\newcommand{\passthrough}[1]{#1}
+
+%% ══════════════════════════════════════════════════════════════════════════
+\begin{document}
+
+%% ─── Title page ───────────────────────────────────────────────────────────
+\begin{titlepage}
+  \pagecolor{brand-green}
+  \centering
+  \vspace*{3.5cm}
+  {\fontsize{52}{62}\selectfont\bfseries\color{white}KST4Contest}\\[0.4cm]
+  {\fontsize{22}{28}\selectfont\color{white!75!brand-green}pratiKST (ON4KST Chat Client)}\\[2.8cm]
+  \color{white!40!brand-green}\rule{10cm}{0.6pt}\\[1.8cm]
+  {\LARGE\bfseries\color{white}$title$}\\[1cm]
+  $if(version)${\large\color{white!80!brand-green}Version:\space{}$version$}\\[0.6cm]$endif$
+  \vfill
+  {\large\color{white}DO5AMF · Marc Fröhlich · DM5M · DN9APW · Philipp Wagner}\\[0.4cm]
+  {\color{white!70!brand-green}\today}\\[2cm]
+\end{titlepage}
+
+\pagecolor{white}
+\newpage
+
+%% ─── Table of Contents ────────────────────────────────────────────────────
+\tableofcontents
+\newpage
+
+%% ─── Main content ─────────────────────────────────────────────────────────
+$body$
+
+\end{document}

.github/latex-manual/strip-wiki-links.lua

@@ -0,0 +1,156 @@
+--[[
+  strip-wiki-links.lua – pandoc Lua filter for KST4Contest documentation
+  -----------------------------------------------------------------------
+  1. Removes language-switch blockquotes (GitHub Wiki navigation) that
+     are not relevant in the printed PDF manual.
+  2. Converts internal GitHub-wiki-style links to in-document anchors
+     so links jump within the generated PDF.
+  3. Replaces flag emoji and other symbols that XeLaTeX cannot render with
+     plain-text equivalents.
+--]]
+
+local PAGE_ANCHOR_MAP = {
+  ["de-Home"] = "kst4contest-wiki",
+  ["de-Installation"] = "installation",
+  ["de-Konfiguration"] = "konfiguration",
+  ["de-Funktionen"] = "funktionen",
+  ["de-Benutzeroberflaeche"] = "benutzeroberflache",
+  ["de-Makros-und-Variablen"] = "makros-und-variablen",
+  ["de-Log-Synchronisation"] = "log-synchronisation",
+  ["de-AirScout-Integration"] = "airscout-integration",
+  ["de-DX-Cluster-Server"] = "integrierter-dx-cluster-server",
+  ["de-Changelog"] = "changelog",
+
+  ["en-Home"] = "kst4contest-wiki",
+  ["en-Installation"] = "installation",
+  ["en-Configuration"] = "configuration",
+  ["en-Features"] = "features",
+  ["en-User-Interface"] = "user-interface",
+  ["en-Macros-and-Variables"] = "macros-and-variables",
+  ["en-Log-Sync"] = "log-synchronisation",
+  ["en-AirScout-Integration"] = "airscout-integration",
+  ["en-DX-Cluster-Server"] = "built-in-dx-cluster-server",
+  ["en-Changelog"] = "changelog",
+
+  ["Installation"] = "installation",
+  ["Konfiguration"] = "konfiguration",
+  ["Funktionen"] = "funktionen",
+  ["Benutzeroberflaeche"] = "benutzeroberflache",
+  ["Makros-und-Variablen"] = "makros-und-variablen",
+  ["Log-Synchronisation"] = "log-synchronisation",
+  ["AirScout-Integration"] = "airscout-integration",
+  ["DX-Cluster-Server"] = "integrierter-dx-cluster-server",
+  ["Changelog"] = "changelog",
+
+  ["Configuration"] = "configuration",
+  ["Features"] = "features",
+  ["User-Interface"] = "user-interface",
+  ["Macros-and-Variables"] = "macros-and-variables",
+  ["Log-Sync"] = "log-synchronisation",
+}
+
+local function normalize_anchor(text)
+  local s = text:lower()
+  s = s:gsub("%%20", "-")
+  s = s:gsub("ä", "a"):gsub("ö", "o"):gsub("ü", "u"):gsub("ß", "ss")
+  s = s:gsub("[^%w%s%-_]", "")
+  s = s:gsub("[_%s]+", "-")
+  s = s:gsub("%-+", "-")
+  s = s:gsub("^%-", ""):gsub("%-$", "")
+  return s
+end
+
+local function normalize_page_key(page)
+  local key = page:gsub("^%./", ""):gsub("^/", "")
+  key = key:gsub("^github_docs/", "")
+  key = key:gsub("%.md$", "")
+  return key
+end
+
+local function resolve_page_anchor(page)
+  local key = normalize_page_key(page)
+  return PAGE_ANCHOR_MAP[key] or normalize_anchor(key)
+end
+
+local function convert_url_token(token)
+  local url, trailing = token:match("^(https?://%S-)([%.%,%;%:%!%?]?)$")
+  if not url then
+    return nil
+  end
+
+  local link = pandoc.Link({pandoc.Str(url)}, url)
+  if trailing ~= "" then
+    return {link, pandoc.Str(trailing)}
+  end
+  return link
+end
+
+-- Map of emoji / special Unicode sequences → plain-text replacements.
+-- Add more entries here as needed.
+local EMOJI_MAP = {
+  -- Flag sequences
+  ["\xF0\x9F\x87\xAC\xF0\x9F\x87\xA7"] = "[EN]",  -- 🇬🇧
+  ["\xF0\x9F\x87\xA9\xF0\x9F\x87\xAA"] = "[DE]",  -- 🇩🇪
+  -- Status symbols
+  ["\xE2\x9C\x85"] = "[OK]",   -- ✅
+  ["\xE2\x9D\x8C"] = "[--]",   -- ❌
+  -- Misc symbols used in tables / text
+  ["\xF0\x9F\x94\xB4"] = "[red]",    -- 🔴
+  ["\xF0\x9F\x9F\xA1"] = "[yellow]", -- 🟡
+  ["\xF0\x9F\x9F\xA2"] = "[green]",  -- 🟢
+}
+
+--- Replace emoji in a plain string.
+local function replace_emoji(text)
+  for pattern, replacement in pairs(EMOJI_MAP) do
+    text = text:gsub(pattern, replacement)
+  end
+  return text
+end
+
+--- Filter: remove language-switch blockquotes from PDF output.
+-- These blockquotes appear in every wiki page for GitHub navigation
+-- but are not needed in the printed manual.
+function BlockQuote(el)
+  local text = pandoc.utils.stringify(el)
+  if text:find("Du liest gerade die deutsche Version") or
+     text:find("You are reading the English version") then
+    return {}
+  end
+  return el
+end
+
+--- Filter: convert internal wiki links to in-PDF anchor links.
+function Link(el)
+  local target = el.target
+  -- Keep external URLs unchanged.
+  if target:match("^https?://") or target:match("^mailto:") then
+    return el
+  end
+
+  if target:match("^#") then
+    local fragment = target:gsub("^#", "")
+    return pandoc.Link(el.content, "#" .. normalize_anchor(fragment), el.title, el.attr)
+  end
+
+  local page, fragment = target:match("^([^#]+)#(.+)$")
+  if page and fragment then
+    return pandoc.Link(el.content, "#" .. normalize_anchor(fragment), el.title, el.attr)
+  end
+
+  return pandoc.Link(el.content, "#" .. resolve_page_anchor(target), el.title, el.attr)
+end
+
+--- Filter: replace emoji sequences in plain Str elements.
+function Str(el)
+  local linkified = convert_url_token(el.text)
+  if linkified then
+    return linkified
+  end
+
+  local replaced = replace_emoji(el.text)
+  if replaced ~= el.text then
+    return pandoc.Str(replaced)
+  end
+  return el
+end

.github/workflows/aur-nightly-git.yml

@@ -0,0 +1,155 @@
+name: AUR Nightly (kst4contest-git)
+
+on:
+  workflow_run:
+    workflows: ["Nightly Runtime Artifacts"]
+    types: [completed]
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+env:
+  AUR_SSH_DIR: /tmp/aur-ssh
+
+jobs:
+  update-aur-git:
+    if: >-
+      github.event_name == 'workflow_dispatch' ||
+      github.event.workflow_run.conclusion == 'success'
+
+    runs-on: ubuntu-latest
+
+    container:
+      image: archlinux:latest
+
+    steps:
+      - name: Install dependencies
+        run: |
+          pacman -Sy --noconfirm git openssh base-devel
+          useradd -m builder
+
+      - name: Checkout repository
+        uses: actions/checkout@v7
+        with:
+          fetch-depth: 0
+
+      - name: Mark workspace as safe Git directory
+        run: |
+          git config --global --add safe.directory "$GITHUB_WORKSPACE"
+
+      - name: Compute pkgver
+        id: ver
+        run: |
+          BASE=$(grep -m1 '<version>' pom.xml \
+            | sed 's/.*<version>\(.*\)<\/version>.*/\1/' \
+            | sed 's/[-.]nightly//')
+
+          GIT_PKGVER="${BASE}.r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"
+
+          echo "Computed pkgver: ${GIT_PKGVER}"
+          echo "pkgver=${GIT_PKGVER}" >> "$GITHUB_OUTPUT"
+
+      - name: Update PKGBUILD
+        env:
+          PKGVER: ${{ steps.ver.outputs.pkgver }}
+        run: |
+          sed -i "s/^pkgver=.*/pkgver=${PKGVER}/" \
+            packaging/aur/kst4contest-git/PKGBUILD
+
+      - name: Generate .SRCINFO
+        run: |
+          cp -r packaging/aur/kst4contest-git /tmp/kst4contest-git
+          chown -R builder:builder /tmp/kst4contest-git
+
+          su builder -c \
+            "cd /tmp/kst4contest-git && makepkg --printsrcinfo > .SRCINFO"
+
+          cp /tmp/kst4contest-git/.SRCINFO \
+            packaging/aur/kst4contest-git/.SRCINFO
+
+          echo "Generated .SRCINFO:"
+          cat packaging/aur/kst4contest-git/.SRCINFO
+
+      - name: Set up and verify AUR SSH
+        env:
+          AUR_SSH_PRIVATE_KEY: ${{ secrets.AUR_SSH_PRIVATE_KEY }}
+        run: |
+          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 package metadata to AUR
+        env:
+          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"
+
+          AUR_DIR="/tmp/aur/kst4contest-git"
+
+          mkdir -p "$(dirname "${AUR_DIR}")"
+
+          git -c init.defaultBranch=master clone \
+            "ssh://aur@aur.archlinux.org/kst4contest-git.git" \
+            "${AUR_DIR}"
+
+          cp packaging/aur/kst4contest-git/PKGBUILD \
+            "${AUR_DIR}/PKGBUILD"
+
+          cp packaging/aur/kst4contest-git/.SRCINFO \
+            "${AUR_DIR}/.SRCINFO"
+
+          git -C "${AUR_DIR}" add PKGBUILD .SRCINFO
+
+          if git -C "${AUR_DIR}" diff --cached --quiet; then
+            echo "kst4contest-git: package metadata is already current."
+          else
+            git -C "${AUR_DIR}" commit \
+              -m "Update pkgver to ${{ steps.ver.outputs.pkgver }}"
+
+            git -C "${AUR_DIR}" push origin HEAD:master
+
+            echo "kst4contest-git: successfully pushed to AUR."
+          fi

.github/workflows/aur-publish.yml

@@ -0,0 +1,228 @@
+name: Publish AUR Packages
+
+on:
+  workflow_run:
+    workflows: ["Tagged Release Build"]
+    types: [completed]
+  workflow_dispatch:
+    inputs:
+      version:
+        description: "Release tag (e.g. v1.41.1) — defaults to latest stable release"
+        required: false
+        default: ""
+      dry_run:
+        description: "Dry run — skip AUR push and repo commit (for testing)"
+        type: choice
+        options: ["false", "true"]
+        default: "false"
+
+permissions:
+  contents: read
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+  AUR_SSH_DIR: /tmp/aur-ssh
+
+jobs:
+  publish-aur:
+    if: >-
+      github.event_name == 'workflow_dispatch' ||
+      github.event.workflow_run.conclusion == 'success'
+    runs-on: ubuntu-latest
+    container:
+      image: archlinux:latest
+
+    steps:
+      - name: Install dependencies
+        run: |
+          pacman -Sy --noconfirm git openssh curl base-devel nodejs
+          useradd -m builder
+
+      - name: Checkout
+        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
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          INPUT_VERSION: ${{ inputs.version }}
+        run: |
+          if [[ -n "${INPUT_VERSION}" ]]; then
+            TAG="${INPUT_VERSION}"
+          else
+            TAG=$(curl -sf \
+              -H "Authorization: Bearer ${GH_TOKEN}" \
+              -H "Accept: application/vnd.github+json" \
+              "https://api.github.com/repos/${{ github.repository }}/releases/latest" \
+              | grep '"tag_name"' | sed 's/.*"tag_name": *"\([^"]*\)".*/\1/')
+          fi
+          PKGVER="${TAG#v}"
+          echo "tag=${TAG} → pkgver=${PKGVER}"
+          echo "tag=${TAG}" >> "$GITHUB_OUTPUT"
+          echo "pkgver=${PKGVER}" >> "$GITHUB_OUTPUT"
+
+      - name: Compute SHA256 checksums
+        id: sha
+        run: |
+          TAG="${{ steps.ver.outputs.tag }}"
+          REPO="${{ github.repository }}"
+
+          echo "Hashing pre-built Arch package..."
+          SHA_BIN=$(curl -sfL \
+            "https://github.com/${REPO}/releases/download/${TAG}/KST4Contest-${TAG}-archlinux-x86_64.pkg.tar.zst" \
+            | sha256sum | awk '{print $1}')
+          echo "bin: ${SHA_BIN}"
+
+          echo "Hashing source tarball..."
+          SHA_SRC=$(curl -sfL \
+            "https://github.com/${REPO}/archive/refs/tags/${TAG}.tar.gz" \
+            | sha256sum | awk '{print $1}')
+          echo "src: ${SHA_SRC}"
+
+          echo "bin=${SHA_BIN}" >> "$GITHUB_OUTPUT"
+          echo "src=${SHA_SRC}" >> "$GITHUB_OUTPUT"
+
+      - name: Update PKGBUILDs
+        env:
+          PKGVER: ${{ steps.ver.outputs.pkgver }}
+          SHA_BIN: ${{ steps.sha.outputs.bin }}
+          SHA_SRC: ${{ steps.sha.outputs.src }}
+        run: |
+          # kst4contest-bin
+          sed -i "s/^pkgver=.*/pkgver=${PKGVER}/" packaging/aur/kst4contest-bin/PKGBUILD
+          sed -i "s/^sha256sums=.*/sha256sums=('${SHA_BIN}')/" packaging/aur/kst4contest-bin/PKGBUILD
+
+          # kst4contest (source build)
+          sed -i "s/^pkgver=.*/pkgver=${PKGVER}/" packaging/aur/kst4contest/PKGBUILD
+          sed -i "s/^sha256sums=.*/sha256sums=('${SHA_SRC}')/" packaging/aur/kst4contest/PKGBUILD
+
+          # A new pkgver supersedes any rebuild-only pkgrel bumps made in between.
+          sed -i "s/^pkgrel=.*/pkgrel=1/" packaging/aur/kst4contest-bin/PKGBUILD
+          sed -i "s/^pkgrel=.*/pkgrel=1/" packaging/aur/kst4contest/PKGBUILD
+
+          # kst4contest-git: Basis aus pom.xml, Suffix aus git
+          BASE_VER=$(grep -m1 '<version>' pom.xml \
+            | sed 's/.*<version>\(.*\)<\/version>.*/\1/' | sed 's/[-.]nightly//')
+          GIT_PKGVER="${BASE_VER}.r$(git rev-list --count HEAD).g$(git rev-parse --short HEAD)"
+          sed -i "s/^pkgver=.*/pkgver=${GIT_PKGVER}/" packaging/aur/kst4contest-git/PKGBUILD
+
+          echo "=== Updated PKGBUILD versions ==="
+          grep -H '^pkgver=\|^sha256sums=' packaging/aur/*/PKGBUILD
+
+      - name: Generate .SRCINFO files
+        run: |
+          for pkg in kst4contest-bin kst4contest kst4contest-git; do
+            cp -r "packaging/aur/${pkg}" "/tmp/${pkg}"
+            chown -R builder:builder "/tmp/${pkg}"
+            su builder -c "cd /tmp/${pkg} && makepkg --printsrcinfo > .SRCINFO"
+            cp "/tmp/${pkg}/.SRCINFO" "packaging/aur/${pkg}/.SRCINFO"
+            echo "=== ${pkg}/.SRCINFO ==="
+            cat "packaging/aur/${pkg}/.SRCINFO"
+          done
+
+      - name: Set up AUR SSH
+        if: inputs.dry_run != 'true'
+        env:
+          AUR_SSH_PRIVATE_KEY: ${{ secrets.AUR_SSH_PRIVATE_KEY }}
+        run: |
+          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 -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}/"
+            git -C "${aur_dir}" add PKGBUILD .SRCINFO
+            git -C "${aur_dir}" diff --cached --quiet \
+              && echo "${pkg}: no changes, skipping push" && return 0
+            git -C "${aur_dir}" commit -m "${msg}"
+            git -C "${aur_dir}" push origin HEAD:master
+            echo "${pkg}: pushed to AUR"
+          }
+
+          push_to_aur kst4contest-bin "Update to ${TAG}"
+          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

@@ -0,0 +1,109 @@
+name: Build Documentation PDF
+
+# Runs when documentation changes are pushed to main, or on manual trigger.
+# Also triggered as a dependency from the tagged-release workflow.
+on:
+  push:
+    branches:
+      - main
+    paths:
+      - github_docs/**
+      - .github/latex-manual/**
+      - .github/workflows/docs-pdf.yml
+  workflow_dispatch:
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+
+permissions:
+  contents: read
+
+jobs:
+  build-docs-pdf:
+    name: Build Documentation PDF
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve version string
+        run: |
+          if [[ "${{ github.ref }}" == refs/tags/* ]]; then
+            VERSION="${{ github.ref_name }}"
+          else
+            VERSION="$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')-${GITHUB_SHA::7}"
+          fi
+          echo "DOC_VERSION=$VERSION" >> "$GITHUB_ENV"
+
+      - name: Install pandoc and LaTeX toolchain
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends \
+            pandoc \
+            texlive-xetex \
+            texlive-fonts-recommended \
+            texlive-latex-extra \
+            texlive-plain-generic
+
+      - name: Build English PDF manual
+        run: |
+          mkdir -p dist
+          pandoc \
+            --from=markdown-yaml_metadata_block \
+            --template=.github/latex-manual/manual-template.tex \
+            --pdf-engine=xelatex \
+            --lua-filter=.github/latex-manual/strip-wiki-links.lua \
+            --resource-path=.:github_docs \
+            --listings \
+            --toc \
+            --toc-depth=6 \
+            -V title="User Manual" \
+            -V polyglossia-lang=english \
+            -V version="${DOC_VERSION}" \
+            -o dist/KST4Contest-${DOC_VERSION}-manual-en.pdf \
+            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 \
+            github_docs/en-Log-Sync.md \
+            github_docs/en-AirScout-Integration.md \
+            github_docs/en-DX-Cluster-Server.md \
+            github_docs/en-Changelog.md
+
+      - name: Build German PDF manual
+        run: |
+          pandoc \
+            --from=markdown-yaml_metadata_block \
+            --template=.github/latex-manual/manual-template.tex \
+            --pdf-engine=xelatex \
+            --lua-filter=.github/latex-manual/strip-wiki-links.lua \
+            --resource-path=.:github_docs \
+            --listings \
+            --toc \
+            --toc-depth=6 \
+            -V title="Benutzerhandbuch" \
+            -V polyglossia-lang=german \
+            -V version="${DOC_VERSION}" \
+            -o dist/KST4Contest-${DOC_VERSION}-manual-de.pdf \
+            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_docs/de-Log-Synchronisation.md \
+            github_docs/de-AirScout-Integration.md \
+            github_docs/de-DX-Cluster-Server.md \
+            github_docs/de-Changelog.md
+
+      - name: Upload PDF artifacts
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: docs-pdf
+          path: dist/KST4Contest-*-manual-*.pdf
+          retention-days: 30

.github/workflows/github-wiki.yml

@@ -0,0 +1,21 @@
+name: Publish wiki
+on:
+  push:
+    branches: [main]
+    paths:
+      - github_docs/**
+      - .github/workflows/github-wiki.yml
+concurrency:
+  group: publish-wiki
+  cancel-in-progress: true
+permissions:
+  contents: write
+jobs:
+  publish-wiki:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: Andrew-Chen-Wang/github-wiki-action@v4
+        with:
+          path: github_docs
+          disable-empty-commits: true

.github/workflows/nightly-artifacts.yml

@@ -0,0 +1,682 @@
+name: Nightly Runtime Artifacts
+
+on:
+  push:
+    branches:
+      - main
+    paths:
+      - "src/**"
+      - "packaging/icons/**"
+      - "packaging/macos/**"
+      - "pom.xml"
+      - "mvnw"
+      - "mvnw.cmd"
+      - ".github/workflows/nightly-artifacts.yml"
+  workflow_dispatch:
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+
+permissions:
+  contents: write
+  packages: write
+
+jobs:
+  build-windows-zip:
+    name: Build Windows ZIP
+    runs-on: windows-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        shell: pwsh
+        run: |
+          $xml = [xml](Get-Content pom.xml)
+          $version = $xml.project.version
+          $shortSha = "${{ github.sha }}".Substring(0, 7)
+          Add-Content -Path $env:GITHUB_ENV -Value "VERSION=$version"
+          Add-Content -Path $env:GITHUB_ENV -Value "SHORT_SHA=$shortSha"
+          Add-Content -Path $env:GITHUB_ENV -Value "ASSET_BASENAME=praktiKST-$version-$shortSha"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install WiX Toolset
+        shell: pwsh
+        run: choco install wixtoolset --no-progress -y
+
+      - name: Build JAR and copy runtime dependencies
+        shell: pwsh
+        run: |
+          .\mvnw.cmd -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          $jar = Get-ChildItem -Path target -Filter 'praktiKST-*.jar' | Sort-Object LastWriteTime -Descending | Select-Object -First 1
+          if (-not $jar) {
+            throw "No project JAR produced"
+          }
+          Copy-Item $jar.FullName target/dist-libs/app.jar
+
+      - name: Build app-image with jpackage
+        shell: pwsh
+        run: |
+          New-Item -ItemType Directory -Force -Path dist | Out-Null
+          $addModules = & java packaging/AddModules.java
+          if ($LASTEXITCODE -ne 0) { throw "Failed to resolve --add-modules from module-info.java" }
+          jpackage `
+            --type app-image `
+            --name praktiKST `
+            --icon packaging/icons/kst4contest.ico `
+            --input target/dist-libs `
+            --main-jar app.jar `
+            --main-class kst4contest.view.Kst4ContestApplication `
+            --module-path target/dist-libs `
+            --add-modules $addModules `
+            --dest dist
+
+      - name: Create Windows ZIP
+        shell: pwsh
+        run: |
+          if (-not (Test-Path dist/praktiKST)) {
+            throw "No Windows app-image produced by jpackage"
+          }
+          Compress-Archive -Path dist/praktiKST -DestinationPath "dist/$env:ASSET_BASENAME-windows-x64.zip" -Force
+
+      - name: Upload Windows artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: windows-zip
+          path: dist/praktiKST-*-windows-x64.zip
+          retention-days: 14
+
+  build-linux-appimage:
+    name: Build Linux AppImage
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        run: |
+          VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
+          SHORT_SHA="${GITHUB_SHA::7}"
+          echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build app-image with jpackage
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type app-image \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --dest dist
+
+      - name: Create AppDir metadata
+        run: |
+          rm -rf target/KST4Contest.AppDir
+          cp -a dist/KST4Contest target/KST4Contest.AppDir
+
+          cat > target/KST4Contest.AppDir/AppRun << 'EOF'
+          #!/bin/sh
+          HERE="$(dirname "$(readlink -f "$0")")"
+          exec "$HERE/bin/KST4Contest" "$@"
+          EOF
+          chmod +x target/KST4Contest.AppDir/AppRun
+
+          cat > target/KST4Contest.AppDir/KST4Contest.desktop << 'EOF'
+          [Desktop Entry]
+          Type=Application
+          Name=KST4Contest
+          Exec=KST4Contest
+          Icon=KST4Contest
+          Categories=Network;HamRadio;
+          Terminal=false
+          EOF
+
+          if [ -f target/KST4Contest.AppDir/lib/KST4Contest.png ]; then
+            cp target/KST4Contest.AppDir/lib/KST4Contest.png target/KST4Contest.AppDir/KST4Contest.png
+          fi
+
+      - name: Build AppImage
+        run: |
+          wget -q -O target/appimagetool.AppImage https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage
+          chmod +x target/appimagetool.AppImage
+          APPIMAGE_EXTRACT_AND_RUN=1 ARCH=x86_64 target/appimagetool.AppImage target/KST4Contest.AppDir "dist/${ASSET_BASENAME}-linux-x86_64.AppImage"
+
+      - name: Upload Linux artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-appimage
+          path: dist/KST4Contest-*-linux-x86_64.AppImage
+          retention-days: 14
+
+  build-linux-deb:
+    name: Build Debian package
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        run: |
+          VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
+          SHORT_SHA="${GITHUB_SHA::7}"
+          echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install packaging dependencies
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends fakeroot
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build Debian package
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type deb \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --linux-package-deps "libgstreamer1.0-0,libgstreamer-plugins-base1.0-0,gstreamer1.0-plugins-good" \
+            --dest dist
+          DEB="$(ls dist/*.deb | head -n 1)"
+          if [ -z "$DEB" ]; then
+            echo "No DEB produced by jpackage" && exit 1
+          fi
+          mv "$DEB" "dist/${ASSET_BASENAME}-debian-amd64.deb"
+
+      - name: Upload Debian artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-debian
+          path: dist/KST4Contest-*-debian-amd64.deb
+          retention-days: 14
+
+  build-linux-rpm:
+    name: Build Fedora package
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        run: |
+          VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
+          SHORT_SHA="${GITHUB_SHA::7}"
+          echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install packaging dependencies
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends rpm
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build Fedora package
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type rpm \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --linux-package-deps "gstreamer1,gstreamer1-plugins-base,gstreamer1-plugins-good" \
+            --dest dist
+          RPM="$(ls dist/*.rpm | head -n 1)"
+          if [ -z "$RPM" ]; then
+            echo "No RPM produced by jpackage" && exit 1
+          fi
+          mv "$RPM" "dist/${ASSET_BASENAME}-fedora-x86_64.rpm"
+
+      - name: Upload Fedora artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-fedora
+          path: dist/KST4Contest-*-fedora-x86_64.rpm
+          retention-days: 14
+
+  build-linux-arch:
+    name: Build Arch Linux package
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        run: |
+          VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
+          SHORT_SHA="${GITHUB_SHA::7}"
+          echo "VERSION=$VERSION" >> "$GITHUB_ENV"
+          echo "SHORT_SHA=$SHORT_SHA" >> "$GITHUB_ENV"
+          echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install packaging dependencies
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends zstd
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build app-image with jpackage
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type app-image \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --dest dist
+
+      - name: Build Arch Linux package artifact
+        run: |
+          ARCH=$(uname -m)
+          PKGVER=$(printf '%s' "${VERSION}-${SHORT_SHA}" | sed 's/[^[:alnum:].+_]/_/g')
+          PKGROOT="target/archpkg"
+          rm -rf "$PKGROOT"
+          mkdir -p "$PKGROOT/usr/lib/KST4Contest" "$PKGROOT/usr/bin"
+          cp -a dist/KST4Contest/. "$PKGROOT/usr/lib/KST4Contest/"
+          cat > "$PKGROOT/usr/bin/KST4Contest" << 'EOF'
+          #!/bin/sh
+          exec /usr/lib/KST4Contest/bin/KST4Contest "$@"
+          EOF
+          chmod 755 "$PKGROOT/usr/bin/KST4Contest"
+          mkdir -p "$PKGROOT/usr/share/applications" "$PKGROOT/usr/share/icons/hicolor/256x256/apps"
+          cat > "$PKGROOT/usr/share/applications/KST4Contest.desktop" << 'EOF'
+          [Desktop Entry]
+          Type=Application
+          Name=KST4Contest
+          Comment=ON4KST Chat Client for VHF/UHF contest operation
+          Exec=KST4Contest
+          Icon=KST4Contest
+          Categories=Network;HamRadio;
+          Terminal=false
+          EOF
+          if [ -f "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" ]; then
+            cp "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" "$PKGROOT/usr/share/icons/hicolor/256x256/apps/KST4Contest.png"
+          fi
+          INSTALLED_SIZE=$(du -sb "$PKGROOT" | cut -f1)
+          BUILDDATE=$(date +%s)
+          WORKFLOW_SHA256=$(sha256sum "$GITHUB_WORKSPACE/.github/workflows/nightly-artifacts.yml" | awk '{print $1}')
+          {
+            echo "pkgname = kst4contest"
+            echo "pkgbase = kst4contest"
+            echo "xdata = pkgtype=pkg"
+            echo "pkgver = ${PKGVER}-1"
+            echo "pkgdesc = KST4Contest amateur radio contest logger"
+            echo "url = https://github.com/${{ github.repository }}"
+            echo "builddate = ${BUILDDATE}"
+            echo "packager = GitHub Actions"
+            echo "size = ${INSTALLED_SIZE}"
+            echo "arch = ${ARCH}"
+            echo "license = custom"
+            echo "depend = java-runtime"
+            echo "depend = gst-plugins-base"
+            echo "depend = gst-plugins-good"
+          } > "$PKGROOT/.PKGINFO"
+          {
+            echo "format = 2"
+            echo "pkgname = kst4contest"
+            echo "pkgbase = kst4contest"
+            echo "pkgver = ${PKGVER}-1"
+            echo "pkgarch = ${ARCH}"
+            echo "pkgbuild_sha256sum = ${WORKFLOW_SHA256}"
+            echo "packager = GitHub Actions"
+            echo "builddate = ${BUILDDATE}"
+            echo "builddir = /build"
+            echo "startdir = /build"
+            echo "buildtool = makepkg"
+            echo "buildtoolver = 7.0.0-1-x86_64"
+            echo "buildenv = !distcc !color !ccache check !sign"
+            echo "options = !strip docs libtool staticlibs emptydirs zipman purge !debug !lto"
+          } > "$PKGROOT/.BUILDINFO"
+          tar --zstd --transform 's|^\./||' -cf "dist/${ASSET_BASENAME}-archlinux-${ARCH}.pkg.tar.zst" -C "$PKGROOT" .
+
+      - name: Upload Arch Linux artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-arch
+          path: dist/KST4Contest-*-archlinux-*.pkg.tar.zst
+          retention-days: 14
+
+  build-flatpak:
+    name: Build Flatpak
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        run: |
+          VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
+          SHORT_SHA="${GITHUB_SHA::7}"
+          echo "VERSION=$VERSION" >> "$GITHUB_ENV"
+          echo "SHORT_SHA=$SHORT_SHA" >> "$GITHUB_ENV"
+          echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Install Flatpak tooling
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends flatpak flatpak-builder elfutils
+          flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
+          flatpak --user install -y flathub org.freedesktop.Platform//24.08 org.freedesktop.Sdk//24.08
+
+      - name: Build app-image with jpackage
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+          mkdir -p target/flatpak-src
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type app-image \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --dest target/flatpak-src
+
+      - name: Create Flatpak manifest
+        run: |
+          mkdir -p dist
+          cat > target/de.x08.KST4Contest.yml << 'EOF'
+          app-id: de.x08.KST4Contest
+          runtime: org.freedesktop.Platform
+          runtime-version: "24.08"
+          sdk: org.freedesktop.Sdk
+          command: KST4Contest
+          finish-args:
+            - --socket=wayland
+            - --socket=x11
+            - --socket=pulseaudio
+            - --share=network
+            - --share=ipc
+            - --device=dri
+            - --filesystem=~/.praktiKST
+            - --env=ALSA_CONFIG_PATH=/app/share/alsa/asound.conf
+          modules:
+            - name: kst4contest
+              buildsystem: simple
+              build-commands:
+                - install -d /app/lib/KST4Contest /app/bin /app/share/applications /app/share/alsa
+                - printf '@include /usr/share/alsa/alsa.conf\npcm.!default { type pulse }\nctl.!default { type pulse }\n' > /app/share/alsa/asound.conf
+                - cp -a . /app/lib/KST4Contest/
+                - printf '#!/bin/sh\nexec /app/lib/KST4Contest/bin/KST4Contest "$@"\n' > /app/bin/KST4Contest
+                - chmod 755 /app/bin/KST4Contest
+                - echo '[Desktop Entry]' > /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Type=Application' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Name=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Comment=ON4KST Chat Client for VHF/UHF contest operation' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Exec=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Icon=de.x08.KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - printf 'Categories=Network;HamRadio;\n' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Terminal=false' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - test -f /app/lib/KST4Contest/lib/KST4Contest.png && install -Dm644 /app/lib/KST4Contest/lib/KST4Contest.png /app/share/icons/hicolor/256x256/apps/de.x08.KST4Contest.png || true
+              sources:
+                - type: dir
+                  path: flatpak-src/KST4Contest
+          EOF
+
+      - name: Import Flatpak signing key
+        run: |
+          echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
+          FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')
+          echo "FLATPAK_GPG_KEY_ID=$FLATPAK_GPG_KEY_ID" >> "$GITHUB_ENV"
+
+      - name: Build Flatpak repo (nightly)
+        run: |
+          flatpak-builder --force-clean target/flatpak-build target/de.x08.KST4Contest.yml
+          flatpak build-export --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo target/flatpak-build nightly
+          flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo
+
+      - name: Create flatpakref (nightly)
+        run: |
+          REPO_NAME="${GITHUB_REPOSITORY#*/}"
+          PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
+          GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
+          cat > "dist/de.x08.KST4Contest.nightly.flatpakref" << EOF
+          [Flatpak Ref]
+          Name=de.x08.KST4Contest
+          Branch=nightly
+          Title=KST4Contest (Nightly) – ON4KST Chat Client
+          Url=${PAGES_URL}
+          RuntimeRepo=https://flathub.org/repo/flathub.flatpakrepo
+          GPGKey=${GPG_KEY_B64}
+          IsRuntime=false
+          EOF
+
+      - name: Upload flatpakref
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: flatpakref
+          path: dist/de.x08.KST4Contest.nightly.flatpakref
+
+      - name: Upload Flatpak OSTree repo
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: flatpak-ostree-repo
+          path: target/flatpak-repo/
+
+  publish-flatpak-repo:
+    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
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends flatpak
+
+      - name: Import Flatpak signing key
+        run: |
+          echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
+          echo "FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')" >> "$GITHUB_ENV"
+
+      - name: Download OSTree repo artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: flatpak-ostree-repo
+          path: flatpak-ostree-repo/
+
+      - name: Checkout existing flatpak-repo branch
+        uses: actions/checkout@v4.1.7
+        with:
+          ref: flatpak-repo
+          path: existing-flatpak-repo
+
+      - name: Merge nightly build into flatpak-repo
+        run: |
+          cd existing-flatpak-repo
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git config user.name "github-actions[bot]"
+          # Copy the new OSTree build into the repo
+          rsync -a ../flatpak-ostree-repo/ ./
+          # Regenerate summary with all branches
+          flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" .
+          # Generate .flatpakrepo with embedded GPG key so users can do remote-add without errors
+          REPO_NAME="${GITHUB_REPOSITORY#*/}"
+          PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
+          GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
+          cat > kst4contest.flatpakrepo << EOF
+          [Flatpak Repo]
+          Title=KST4Contest
+          Url=${PAGES_URL}
+          Homepage=https://github.com/${GITHUB_REPOSITORY}
+          Comment=KST4Contest – ON4KST Chat Client for VHF/UHF contests
+          GPGKey=${GPG_KEY_B64}
+          EOF
+          # Stage all changes (new/updated refs, summary, objects in OSTree)
+          git add -A
+          if git diff --cached --quiet; then
+            echo "No changes to commit"
+          else
+            git commit -m "Nightly flatpak: $(echo ${{ github.sha }} | cut -c1-7)"
+            git push https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git HEAD:flatpak-repo
+          fi
+
+  build-macos-dmg:
+    name: Build macOS DMG (${{ matrix.os }})
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [macos-latest, macos-15-intel]
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Resolve nightly version info
+        run: |
+          VERSION=$(grep -m1 '<version>' pom.xml | sed 's/.*<version>\(.*\)<\/version>.*/\1/')
+          SHORT_SHA="${GITHUB_SHA::7}"
+          ARCH=$(uname -m)
+          echo "VERSION=$VERSION" >> "$GITHUB_ENV"
+          echo "SHORT_SHA=$SHORT_SHA" >> "$GITHUB_ENV"
+          echo "ASSET_BASENAME=KST4Contest-${VERSION}-${SHORT_SHA}" >> "$GITHUB_ENV"
+          echo "ARCH=$ARCH" >> "$GITHUB_ENV"
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Import signing certificate
+        env:
+          MACOS_CERT_P12: ${{ secrets.MACOS_CERT_P12 }}
+          MACOS_CERT_PASSWORD: ${{ secrets.MACOS_CERT_PASSWORD }}
+        run: ./packaging/macos/ci-import-cert.sh
+
+      # Builds the jar, signs the app bundle and every native library inside it,
+      # wraps it into a DMG and has Apple notarize the result. Same script the
+      # local Mac uses, so the two cannot drift apart.
+      - name: Build signed and notarized DMG
+        env:
+          MACOS_NOTARY_KEY: ${{ secrets.MACOS_NOTARY_KEY }}
+          NOTARY_KEY_ID: ${{ secrets.MACOS_NOTARY_KEY_ID }}
+          NOTARY_ISSUER: ${{ secrets.MACOS_NOTARY_ISSUER }}
+        run: |
+          printf '%s' "$MACOS_NOTARY_KEY" | base64 --decode > "$RUNNER_TEMP/notary.p8"
+          export NOTARY_KEY="$RUNNER_TEMP/notary.p8"
+          ./packaging/macos/build-signed-dmg.sh
+
+      - name: Remove signing credentials
+        if: always()
+        run: |
+          rm -f "$RUNNER_TEMP/notary.p8"
+          if [ -n "${SIGNING_KEYCHAIN:-}" ]; then
+            security delete-keychain "$SIGNING_KEYCHAIN" || true
+          fi
+
+      - name: Rename DMG artifact
+        run: |
+          DMG=$(ls dist/*.dmg | head -n 1)
+          if [ -z "$DMG" ]; then
+            echo "No DMG produced by the build" && exit 1
+          fi
+          mv "$DMG" "dist/${ASSET_BASENAME}-macos-${ARCH}.dmg"
+
+      - name: Upload macOS artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: macos-dmg-${{ matrix.os }}
+          path: dist/KST4Contest-*-macos-*.dmg
+          retention-days: 14

.github/workflows/pr-compile-check.yml

@@ -0,0 +1,34 @@
+name: PR Compile Check
+
+on:
+  pull_request:
+    branches:
+      - main
+  workflow_dispatch:
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+
+jobs:
+  compile:
+    name: Compile (Java 21)
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Verify packaging module list matches module-info.java
+        run: java packaging/AddModules.java --verify-pom
+
+      - name: Compile
+        run: ./mvnw -B -DskipTests compile

.github/workflows/tagged-release.yml

@@ -0,0 +1,833 @@
+name: Tagged Release Build
+
+on:
+  push:
+    tags:
+      - "*"
+  workflow_dispatch:
+
+permissions:
+  actions: read
+  contents: write
+  issues: read
+  packages: write
+
+env:
+  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
+
+jobs:
+  build-windows-zip:
+    name: Build Windows ZIP
+    runs-on: windows-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install WiX Toolset
+        shell: pwsh
+        run: choco install wixtoolset --no-progress -y
+
+      - name: Build JAR and copy runtime dependencies
+        shell: pwsh
+        run: |
+          .\mvnw.cmd -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          $jar = Get-ChildItem -Path target -Filter 'praktiKST-*.jar' | Sort-Object LastWriteTime -Descending | Select-Object -First 1
+          if (-not $jar) {
+            throw "No project JAR produced"
+          }
+          Copy-Item $jar.FullName target/dist-libs/app.jar
+
+      - name: Build app-image with jpackage
+        shell: pwsh
+        run: |
+          New-Item -ItemType Directory -Force -Path dist | Out-Null
+          $addModules = & java packaging/AddModules.java
+          if ($LASTEXITCODE -ne 0) { throw "Failed to resolve --add-modules from module-info.java" }
+          jpackage `
+            --type app-image `
+            --name praktiKST `
+            --icon packaging/icons/kst4contest.ico `
+            --input target/dist-libs `
+            --main-jar app.jar `
+            --main-class kst4contest.view.Kst4ContestApplication `
+            --module-path target/dist-libs `
+            --add-modules $addModules `
+            --dest dist
+
+      - name: Create Windows ZIP
+        shell: pwsh
+        run: |
+          if (-not (Test-Path dist/praktiKST)) {
+            throw "No Windows app-image produced by jpackage"
+          }
+          Compress-Archive -Path dist/praktiKST -DestinationPath dist/praktiKST-${{ github.ref_name }}-windows-x64.zip -Force
+
+      - name: Upload Windows artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: windows-zip
+          path: dist/praktiKST-${{ github.ref_name }}-windows-x64.zip
+
+  build-linux-appimage:
+    name: Build Linux AppImage
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build app-image with jpackage
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type app-image \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --dest dist
+
+      - name: Create AppDir metadata
+        run: |
+          rm -rf target/KST4Contest.AppDir
+          cp -a dist/KST4Contest target/KST4Contest.AppDir
+
+          cat > target/KST4Contest.AppDir/AppRun << 'EOF'
+          #!/bin/sh
+          HERE="$(dirname "$(readlink -f "$0")")"
+          exec "$HERE/bin/KST4Contest" "$@"
+          EOF
+          chmod +x target/KST4Contest.AppDir/AppRun
+
+          cat > target/KST4Contest.AppDir/KST4Contest.desktop << 'EOF'
+          [Desktop Entry]
+          Type=Application
+          Name=KST4Contest
+          Exec=KST4Contest
+          Icon=KST4Contest
+          Categories=Network;HamRadio;
+          Terminal=false
+          EOF
+
+          if [ -f target/KST4Contest.AppDir/lib/KST4Contest.png ]; then
+            cp target/KST4Contest.AppDir/lib/KST4Contest.png target/KST4Contest.AppDir/KST4Contest.png
+          fi
+
+      - name: Build AppImage
+        run: |
+          wget -q -O target/appimagetool.AppImage https://github.com/AppImage/appimagetool/releases/download/continuous/appimagetool-x86_64.AppImage
+          chmod +x target/appimagetool.AppImage
+          APPIMAGE_EXTRACT_AND_RUN=1 ARCH=x86_64 target/appimagetool.AppImage target/KST4Contest.AppDir dist/KST4Contest-${{ github.ref_name }}-linux-x86_64.AppImage
+
+      - name: Upload Linux artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-appimage
+          path: dist/KST4Contest-${{ github.ref_name }}-linux-x86_64.AppImage
+
+  build-linux-deb:
+    name: Build Debian package
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install packaging dependencies
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends fakeroot
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build Debian package
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type deb \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --linux-package-deps "libgstreamer1.0-0,libgstreamer-plugins-base1.0-0,gstreamer1.0-plugins-good" \
+            --dest dist
+          DEB="$(ls dist/*.deb | head -n 1)"
+          if [ -z "$DEB" ]; then
+            echo "No DEB produced by jpackage" && exit 1
+          fi
+          mv "$DEB" "dist/KST4Contest-${{ github.ref_name }}-debian-amd64.deb"
+
+      - name: Upload Debian artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-debian
+          path: dist/KST4Contest-${{ github.ref_name }}-debian-amd64.deb
+
+  build-linux-rpm:
+    name: Build Fedora package
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install packaging dependencies
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends rpm
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build Fedora package
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type rpm \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --linux-package-deps "gstreamer1,gstreamer1-plugins-base,gstreamer1-plugins-good" \
+            --dest dist
+          RPM="$(ls dist/*.rpm | head -n 1)"
+          if [ -z "$RPM" ]; then
+            echo "No RPM produced by jpackage" && exit 1
+          fi
+          mv "$RPM" "dist/KST4Contest-${{ github.ref_name }}-fedora-x86_64.rpm"
+
+      - name: Upload Fedora artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-fedora
+          path: dist/KST4Contest-${{ github.ref_name }}-fedora-x86_64.rpm
+
+  build-linux-arch:
+    name: Build Arch Linux package
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Install packaging dependencies
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends zstd
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Build JAR and copy runtime dependencies
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+
+      - name: Build app-image with jpackage
+        run: |
+          mkdir -p dist
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type app-image \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --dest dist
+
+      - name: Build Arch Linux package artifact
+        run: |
+          ARCH=$(uname -m)
+          PKGVER=$(printf '%s' "${{ github.ref_name }}" | sed 's/[^[:alnum:].+_]/_/g')
+          PKGROOT="target/archpkg"
+          rm -rf "$PKGROOT"
+          mkdir -p "$PKGROOT/usr/lib/KST4Contest" "$PKGROOT/usr/bin"
+          cp -a dist/KST4Contest/. "$PKGROOT/usr/lib/KST4Contest/"
+          cat > "$PKGROOT/usr/bin/KST4Contest" << 'EOF'
+          #!/bin/sh
+          exec /usr/lib/KST4Contest/bin/KST4Contest "$@"
+          EOF
+          chmod 755 "$PKGROOT/usr/bin/KST4Contest"
+          mkdir -p "$PKGROOT/usr/share/applications" "$PKGROOT/usr/share/icons/hicolor/256x256/apps"
+          cat > "$PKGROOT/usr/share/applications/KST4Contest.desktop" << 'EOF'
+          [Desktop Entry]
+          Type=Application
+          Name=KST4Contest
+          Comment=ON4KST Chat Client for VHF/UHF contest operation
+          Exec=KST4Contest
+          Icon=KST4Contest
+          Categories=Network;HamRadio;
+          Terminal=false
+          EOF
+          if [ -f "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" ]; then
+            cp "$PKGROOT/usr/lib/KST4Contest/lib/KST4Contest.png" "$PKGROOT/usr/share/icons/hicolor/256x256/apps/KST4Contest.png"
+          fi
+          INSTALLED_SIZE=$(du -sb "$PKGROOT" | cut -f1)
+          BUILDDATE=$(date +%s)
+          WORKFLOW_SHA256=$(sha256sum "$GITHUB_WORKSPACE/.github/workflows/tagged-release.yml" | awk '{print $1}')
+          {
+            echo "pkgname = kst4contest"
+            echo "pkgbase = kst4contest"
+            echo "xdata = pkgtype=pkg"
+            echo "pkgver = ${PKGVER}-1"
+            echo "pkgdesc = KST4Contest amateur radio contest logger"
+            echo "url = https://github.com/${{ github.repository }}"
+            echo "builddate = ${BUILDDATE}"
+            echo "packager = GitHub Actions"
+            echo "size = ${INSTALLED_SIZE}"
+            echo "arch = ${ARCH}"
+            echo "license = custom"
+            echo "depend = java-runtime"
+            echo "depend = gst-plugins-base"
+            echo "depend = gst-plugins-good"
+          } > "$PKGROOT/.PKGINFO"
+          {
+            echo "format = 2"
+            echo "pkgname = kst4contest"
+            echo "pkgbase = kst4contest"
+            echo "pkgver = ${PKGVER}-1"
+            echo "pkgarch = ${ARCH}"
+            echo "pkgbuild_sha256sum = ${WORKFLOW_SHA256}"
+            echo "packager = GitHub Actions"
+            echo "builddate = ${BUILDDATE}"
+            echo "builddir = /build"
+            echo "startdir = /build"
+            echo "buildtool = makepkg"
+            echo "buildtoolver = 7.0.0-1-x86_64"
+            echo "buildenv = !distcc !color !ccache check !sign"
+            echo "options = !strip docs libtool staticlibs emptydirs zipman purge !debug !lto"
+          } > "$PKGROOT/.BUILDINFO"
+          tar --zstd --transform 's|^\./||' -cf "dist/KST4Contest-${{ github.ref_name }}-archlinux-${ARCH}.pkg.tar.zst" -C "$PKGROOT" .
+
+      - name: Upload Arch Linux artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: linux-arch
+          path: dist/KST4Contest-${{ github.ref_name }}-archlinux-*.pkg.tar.zst
+
+  build-flatpak:
+    name: Build Flatpak
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Install Flatpak tooling
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends flatpak flatpak-builder elfutils
+          flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
+          flatpak --user install -y flathub org.freedesktop.Platform//24.08 org.freedesktop.Sdk//24.08
+
+      - name: Build app-image with jpackage
+        run: |
+          ./mvnw -B -DskipTests package dependency:copy-dependencies -DincludeScope=runtime -DoutputDirectory=target/dist-libs
+          cp "$(ls -t target/praktiKST-*.jar | head -n 1)" target/dist-libs/app.jar
+          mkdir -p target/flatpak-src
+          ADD_MODULES="$(java packaging/AddModules.java)"
+          jpackage \
+            --type app-image \
+            --name KST4Contest \
+            --icon packaging/icons/kst4contest.png \
+            --input target/dist-libs \
+            --main-jar app.jar \
+            --main-class kst4contest.view.Kst4ContestApplication \
+            --module-path target/dist-libs \
+            --add-modules "$ADD_MODULES" \
+            --dest target/flatpak-src
+
+      - name: Create Flatpak manifest
+        run: |
+          mkdir -p dist
+          cat > target/de.x08.KST4Contest.yml << 'EOF'
+          app-id: de.x08.KST4Contest
+          runtime: org.freedesktop.Platform
+          runtime-version: "24.08"
+          sdk: org.freedesktop.Sdk
+          command: KST4Contest
+          finish-args:
+            - --socket=wayland
+            - --socket=x11
+            - --socket=pulseaudio
+            - --share=network
+            - --share=ipc
+            - --device=dri
+            - --filesystem=~/.praktiKST
+            - --env=ALSA_CONFIG_PATH=/app/share/alsa/asound.conf
+          modules:
+            - name: kst4contest
+              buildsystem: simple
+              build-commands:
+                - install -d /app/lib/KST4Contest /app/bin /app/share/applications /app/share/alsa
+                - printf '@include /usr/share/alsa/alsa.conf\npcm.!default { type pulse }\nctl.!default { type pulse }\n' > /app/share/alsa/asound.conf
+                - cp -a . /app/lib/KST4Contest/
+                - printf '#!/bin/sh\nexec /app/lib/KST4Contest/bin/KST4Contest "$@"\n' > /app/bin/KST4Contest
+                - chmod 755 /app/bin/KST4Contest
+                - echo '[Desktop Entry]' > /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Type=Application' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Name=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Comment=ON4KST Chat Client for VHF/UHF contest operation' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Exec=KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Icon=de.x08.KST4Contest' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - printf 'Categories=Network;HamRadio;\n' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - echo 'Terminal=false' >> /app/share/applications/de.x08.KST4Contest.desktop
+                - test -f /app/lib/KST4Contest/lib/KST4Contest.png && install -Dm644 /app/lib/KST4Contest/lib/KST4Contest.png /app/share/icons/hicolor/256x256/apps/de.x08.KST4Contest.png || true
+              sources:
+                - type: dir
+                  path: flatpak-src/KST4Contest
+          EOF
+
+      - name: Import Flatpak signing key
+        run: |
+          echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
+          FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')
+          echo "FLATPAK_GPG_KEY_ID=$FLATPAK_GPG_KEY_ID" >> "$GITHUB_ENV"
+
+      - name: Determine OSTree branch and flatpakref filename
+        run: |
+          if [[ "${{ github.ref_name }}" == beta-* ]]; then
+            echo "OSTREE_BRANCH=beta" >> "$GITHUB_ENV"
+            echo "FLATPAKREF_NAME=de.x08.KST4Contest.beta.flatpakref" >> "$GITHUB_ENV"
+          else
+            echo "OSTREE_BRANCH=stable" >> "$GITHUB_ENV"
+            echo "FLATPAKREF_NAME=de.x08.KST4Contest.flatpakref" >> "$GITHUB_ENV"
+          fi
+
+      - name: Build Flatpak repo
+        run: |
+          flatpak-builder --force-clean target/flatpak-build target/de.x08.KST4Contest.yml
+          flatpak build-export --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo target/flatpak-build "$OSTREE_BRANCH"
+          flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" target/flatpak-repo
+
+      - name: Create flatpakref
+        run: |
+          REPO_NAME="${GITHUB_REPOSITORY#*/}"
+          PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
+          GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
+          cat > "dist/${FLATPAKREF_NAME}" << EOF
+          [Flatpak Ref]
+          Name=de.x08.KST4Contest
+          Branch=${OSTREE_BRANCH}
+          Title=KST4Contest (${{ startsWith(github.ref_name, 'beta-') && 'Beta' || 'Release' }}) – ON4KST Chat Client
+          Url=${PAGES_URL}
+          RuntimeRepo=https://flathub.org/repo/flathub.flatpakrepo
+          GPGKey=${GPG_KEY_B64}
+          IsRuntime=false
+          EOF
+
+      - name: Upload flatpakref
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: flatpakref
+          path: dist/*.flatpakref
+
+      - name: Upload Flatpak OSTree repo
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: flatpak-ostree-repo
+          path: target/flatpak-repo/
+
+  build-macos-dmg:
+    name: Build macOS DMG (${{ matrix.os }})
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [macos-latest, macos-15-intel]
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Set up Java 21
+        uses: actions/setup-java@v4.1.0
+        with:
+          distribution: temurin
+          java-version: "21"
+
+      - name: Ensure mvnw is executable
+        run: chmod +x mvnw
+
+      - name: Import signing certificate
+        env:
+          MACOS_CERT_P12: ${{ secrets.MACOS_CERT_P12 }}
+          MACOS_CERT_PASSWORD: ${{ secrets.MACOS_CERT_PASSWORD }}
+        run: ./packaging/macos/ci-import-cert.sh
+
+      # Builds the jar, signs the app bundle and every native library inside it,
+      # wraps it into a DMG and has Apple notarize the result. Same script the
+      # local Mac uses, so the two cannot drift apart.
+      - name: Build signed and notarized DMG
+        env:
+          MACOS_NOTARY_KEY: ${{ secrets.MACOS_NOTARY_KEY }}
+          NOTARY_KEY_ID: ${{ secrets.MACOS_NOTARY_KEY_ID }}
+          NOTARY_ISSUER: ${{ secrets.MACOS_NOTARY_ISSUER }}
+        run: |
+          printf '%s' "$MACOS_NOTARY_KEY" | base64 --decode > "$RUNNER_TEMP/notary.p8"
+          export NOTARY_KEY="$RUNNER_TEMP/notary.p8"
+          ./packaging/macos/build-signed-dmg.sh
+
+      - name: Remove signing credentials
+        if: always()
+        run: |
+          rm -f "$RUNNER_TEMP/notary.p8"
+          if [ -n "${SIGNING_KEYCHAIN:-}" ]; then
+            security delete-keychain "$SIGNING_KEYCHAIN" || true
+          fi
+
+      - name: Rename DMG artifact
+        run: |
+          ARCH=$(uname -m)
+          DMG=$(ls dist/*.dmg | head -n 1)
+          if [ -z "$DMG" ]; then
+            echo "No DMG produced by the build" && exit 1
+          fi
+          mv "$DMG" "dist/KST4Contest-${{ github.ref_name }}-macos-${ARCH}.dmg"
+
+      - name: Upload macOS artifact
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: macos-dmg-${{ matrix.os }}
+          path: dist/KST4Contest-${{ github.ref_name }}-macos-*.dmg
+
+  build-docs-pdf:
+    name: Build Documentation PDF
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4.1.7
+
+      - name: Install pandoc and LaTeX toolchain
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends \
+            pandoc \
+            texlive-xetex \
+            texlive-fonts-recommended \
+            texlive-latex-extra \
+            texlive-plain-generic
+
+      - name: Build English PDF manual
+        run: |
+          mkdir -p dist
+          pandoc \
+            --from=markdown-yaml_metadata_block \
+            --template=.github/latex-manual/manual-template.tex \
+            --pdf-engine=xelatex \
+            --lua-filter=.github/latex-manual/strip-wiki-links.lua \
+            --resource-path=.:github_docs \
+            --listings \
+            --toc \
+            --toc-depth=3 \
+            -V title="User Manual" \
+            -V polyglossia-lang=english \
+            -V version="${{ github.ref_name }}" \
+            -o dist/KST4Contest-${{ github.ref_name }}-manual-en.pdf \
+            github_docs/en-Home.md \
+            github_docs/en-Installation.md \
+            github_docs/en-Configuration.md \
+            github_docs/en-Features.md \
+            github_docs/en-User-Interface.md \
+            github_docs/en-Macros-and-Variables.md \
+            github_docs/en-Log-Sync.md \
+            github_docs/en-AirScout-Integration.md \
+            github_docs/en-DX-Cluster-Server.md \
+            github_docs/en-Changelog.md
+
+      - name: Build German PDF manual
+        run: |
+          pandoc \
+            --from=markdown-yaml_metadata_block \
+            --template=.github/latex-manual/manual-template.tex \
+            --pdf-engine=xelatex \
+            --lua-filter=.github/latex-manual/strip-wiki-links.lua \
+            --resource-path=.:github_docs \
+            --listings \
+            --toc \
+            --toc-depth=3 \
+            -V title="Benutzerhandbuch" \
+            -V polyglossia-lang=german \
+            -V version="${{ github.ref_name }}" \
+            -o dist/KST4Contest-${{ github.ref_name }}-manual-de.pdf \
+            github_docs/de-Home.md \
+            github_docs/de-Installation.md \
+            github_docs/de-Konfiguration.md \
+            github_docs/de-Funktionen.md \
+            github_docs/de-Benutzeroberflaeche.md \
+            github_docs/de-Makros-und-Variablen.md \
+            github_docs/de-Log-Synchronisation.md \
+            github_docs/de-AirScout-Integration.md \
+            github_docs/de-DX-Cluster-Server.md \
+            github_docs/de-Changelog.md
+
+      - name: Upload PDF artifacts
+        uses: actions/upload-artifact@v4.3.4
+        with:
+          name: docs-pdf
+          path: dist/KST4Contest-${{ github.ref_name }}-manual-*.pdf
+
+  publish-flatpak-repo:
+    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
+        run: |
+          sudo apt-get update -qq
+          sudo apt-get install -y --no-install-recommends flatpak
+
+      - name: Import Flatpak signing key
+        run: |
+          echo "${{ secrets.FLATPAK_GPG_PRIVATE_KEY }}" | gpg --batch --import
+          echo "FLATPAK_GPG_KEY_ID=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr/{print $10; exit}')" >> "$GITHUB_ENV"
+
+      - name: Download OSTree repo artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: flatpak-ostree-repo
+          path: flatpak-ostree-repo/
+
+      - name: Checkout existing flatpak-repo branch
+        uses: actions/checkout@v4.1.7
+        with:
+          ref: flatpak-repo
+          path: existing-flatpak-repo
+
+      - name: Merge build into flatpak-repo
+        run: |
+          cd existing-flatpak-repo
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git config user.name "github-actions[bot]"
+          rsync -a ../flatpak-ostree-repo/ ./
+          # Regenerate summary with all branches (not just the one just built)
+          flatpak build-update-repo --gpg-sign="$FLATPAK_GPG_KEY_ID" .
+          # Generate .flatpakrepo with embedded GPG key so users can do remote-add without errors
+          REPO_NAME="${GITHUB_REPOSITORY#*/}"
+          PAGES_URL="https://${GITHUB_REPOSITORY_OWNER}.github.io/${REPO_NAME}/"
+          GPG_KEY_B64=$(gpg --export "$FLATPAK_GPG_KEY_ID" | base64 -w 0)
+          cat > kst4contest.flatpakrepo << EOF
+          [Flatpak Repo]
+          Title=KST4Contest
+          Url=${PAGES_URL}
+          Homepage=https://github.com/${GITHUB_REPOSITORY}
+          Comment=KST4Contest – ON4KST Chat Client for VHF/UHF contests
+          GPGKey=${GPG_KEY_B64}
+          EOF
+          git add -A
+          if git diff --cached --quiet; then
+            echo "No changes to commit"
+          else
+            git commit -m "Flatpak repo: ${{ github.ref_name }}"
+            git push https://x-access-token:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}.git HEAD:flatpak-repo
+          fi
+
+  release-tag:
+    name: Publish Tagged Release
+    runs-on: ubuntu-latest
+    needs:
+      - build-windows-zip
+      - build-linux-appimage
+      - build-linux-deb
+      - build-linux-rpm
+      - build-linux-arch
+      - build-macos-dmg
+      - build-flatpak
+      - build-docs-pdf
+      - publish-flatpak-repo
+
+    steps:
+      - name: Checkout release source
+        uses: actions/checkout@v4.1.7
+
+      - name: Download Windows artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: windows-zip
+          path: release-assets/windows
+
+      - name: Download Linux artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: linux-appimage
+          path: release-assets/linux
+
+      - name: Download macOS artifacts
+        uses: actions/download-artifact@v4.1.3
+        with:
+          pattern: macos-dmg-*
+          merge-multiple: true
+          path: release-assets/macos
+
+      - name: Download Debian artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: linux-debian
+          path: release-assets/debian
+
+      - name: Download Fedora artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: linux-fedora
+          path: release-assets/fedora
+
+      - name: Download Arch Linux artifact
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: linux-arch
+          path: release-assets/archlinux
+
+      - name: Download flatpakref
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: flatpakref
+          path: release-assets/flatpakref
+
+      - name: Download PDF manuals
+        uses: actions/download-artifact@v4.1.3
+        with:
+          name: docs-pdf
+          path: release-assets/docs
+
+      - name: Create tagged release
+        uses: ncipollo/release-action@v1
+        with:
+          token: ${{ secrets.GITHUB_TOKEN }}
+          tag: ${{ github.ref_name }}
+          name: ${{ startsWith(github.ref_name, 'beta-') && format('Beta {0}', github.ref_name) || format('Release {0}', github.ref_name) }}
+          prerelease: ${{ startsWith(github.ref_name, 'beta-') }}
+          allowUpdates: false
+          replacesArtifacts: false
+          makeLatest: ${{ !startsWith(github.ref_name, 'beta-') }}
+          generateReleaseNotes: true
+          artifacts: >-
+            release-assets/windows/praktiKST-${{ github.ref_name }}-windows-x64.zip,
+            release-assets/linux/KST4Contest-${{ github.ref_name }}-linux-x86_64.AppImage,
+            release-assets/debian/KST4Contest-${{ github.ref_name }}-debian-amd64.deb,
+            release-assets/fedora/KST4Contest-${{ github.ref_name }}-fedora-x86_64.rpm,
+            release-assets/archlinux/KST4Contest-${{ github.ref_name }}-archlinux-*.pkg.tar.zst,
+            release-assets/flatpakref/*.flatpakref,
+            release-assets/macos/KST4Contest-${{ github.ref_name }}-macos-*.dmg,
+            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
+
+      - 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: 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

.gitignore

@@ -0,0 +1,49 @@
+# Fleet IDE
+.fleet
+
+# Intellij
+.idea
+*.iml
+
+# Eclipse
+.project
+.classpath
+
+# Maven
+target
+
+
+debug.out
+.DS_Store
+
+#Logfiles
+SimpleLogFile.txt
+udpReaderBackup.txt
+
+#tempfiles
+.idea/
+out/
+
+#targetfiles - mvn wrapper
+target/
+
+#builds
+build/
+
+#pdf output directory
+dist/
+
+#zip files for local backups
+*.zip
+
+# node Modules in website
+website/node_modules/
+
+# built website output (rebuilt on the server)
+website/_site/
+
+# Local secrets for act testing
+.secrets
+
+# Apple notarization private keys - never commit these
+*.p8

.mvn/wrapper/maven-wrapper.properties

@@ -0,0 +1,18 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.2/apache-maven-3.9.2-bin.zip
+wrapperUrl=https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.2.0/maven-wrapper-3.2.0.jar

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.

LICENSE

@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<https://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<https://www.gnu.org/licenses/why-not-lgpl.html>.

README.md

@@ -0,0 +1,98 @@
+# KST4Contest
+
+KST4Contest is a Java-based client for the [ON4KST chat](https://www.on4kst.org/chat/login.php), developed for coordinated VHF, UHF and microwave contest operation.
+
+The application is developed by Marc Fröhlich (DO5AMF) and since 2026 Philipp Wagner (DN9APW).
+
+## Start here
+
+- [Project website](https://kst4contest.hamradioonline.de/)
+- [Download Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
+- [Online manual](https://kst4contest.hamradioonline.de/manual/)
+- [GitHub wiki](https://github.com/praktimarc/kst4contest/wiki)
+- [Issues and bug reports](https://github.com/praktimarc/kst4contest/issues)
+- [Development roadmap](https://kst4contest.hamradioonline.de/roadmap/)
+
+## What KST4Contest does
+
+KST4Contest combines the ON4KST chat with information that is useful when coordinating contacts during a contest.
+
+Among other things, it can:
+
+- display and filter stations from the supported ON4KST chat categories;
+- derive band and frequency information from chat messages and station names;
+- maintain Worked and NOT QRV information for the available bands;
+- calculate station priorities from distance, activity and other available information;
+- manage internal skeds and received Win-Test skeds;
+- use AirScout information when evaluating possible aircraft-scatter contacts;
+- display stations, paths and additional propagation information on maps;
+- exchange information with supported logging programs, Win-Test, PSTRotator and a local DX Cluster interface;
+- provide configurable automatic replies for recurring chat requests.
+
+Calculated scores, aircraft-scatter information and path assessments are operating aids. They depend on the available data and should not be treated as guarantees that a contact is possible.
+
+## Installation
+
+Ready-to-use packages are available for Windows, Linux and macOS. These packages include the required Java runtime, so a separate Java installation is normally not necessary.
+
+Use the central download page to select the appropriate build:
+
+- **Stable** is intended for normal contest operation.
+- **Beta** contains changes that are being prepared for a stable release.
+- **Nightly** contains the latest automated development build and is mainly intended for testing.
+
+[Open the download page](https://kst4contest.hamradioonline.de/download/)
+
+## Documentation
+
+The documentation is available in German and English:
+
+- [German manual](https://github.com/praktimarc/kst4contest/wiki/de-Home)
+- [English manual](https://github.com/praktimarc/kst4contest/wiki/en-Home)
+- [Online manual](https://kst4contest.hamradioonline.de/manual/)
+
+The Markdown sources used for the wiki and the generated PDF manuals are stored in [`github_docs`](github_docs/).
+
+Changes to operating behaviour should be documented together with their purpose and limitations. This is especially important for functions whose result depends on external data, heuristics or information derived from chat messages.
+
+## Building from source
+
+Building KST4Contest requires JDK 21. The Maven Wrapper included in the repository should be used, so a separate Maven installation is not required.
+
+Linux and macOS:
+
+```bash
+./mvnw clean test
+./mvnw -B -DskipTests compile
+```
+
+Windows:
+
+```powershell
+mvnw.cmd clean test
+mvnw.cmd -B -DskipTests compile
+```
+
+## Repository structure
+
+- `src/main/java/` – application source code
+- `src/test/` – automated tests
+- `github_docs/` – German and English manual sources
+- `website/` – project website sources
+- `packaging/` – platform-specific packaging files
+
+## CI status
+
+### Documentation
+
+[![Publish wiki](https://github.com/praktimarc/kst4contest/actions/workflows/github-wiki.yml/badge.svg)](https://github.com/praktimarc/kst4contest/actions/workflows/github-wiki.yml)
+
+[![Docs PDF](https://github.com/praktimarc/kst4contest/actions/workflows/docs-pdf.yml/badge.svg)](https://github.com/praktimarc/kst4contest/actions/workflows/docs-pdf.yml)
+
+### Builds
+
+[![Nightly Runtime Artifacts](https://github.com/praktimarc/kst4contest/actions/workflows/nightly-artifacts.yml/badge.svg)](https://github.com/praktimarc/kst4contest/actions/workflows/nightly-artifacts.yml)
+
+## License
+
+KST4Contest is distributed under the [GNU General Public License v3.0](LICENSE).

config

@@ -1,4 +0,0 @@
-[core]
-repo_version=1
-mode=archive-z2
-indexed-deltas=true

de.x08.KST4Contest.flatpakref

@@ -1,8 +0,0 @@
-[Flatpak Ref]
-Name=de.x08.KST4Contest
-Branch=stable
-Title=KST4Contest – ON4KST Chat Client
-Url=https://praktimarc.github.io/kst4contest/
-RuntimeRepo=https://flathub.org/repo/flathub.flatpakrepo
-GPGKey=mQINBGowB94BEACrD2AV/0kpwPjfu/hk8TJdlx8a7kvMOHzqJJLVOh1Nsp4BWXb3Wd2CUdFoFoRroclMiHEMNljGjD4Zov4B3Q1mDWwmgxAWrW6Gs5LeNXwBhrMss6m6sW1oPX/7Dbivb2YHlkQ/cLKMjFsAXF5YRwyox3kgJSWQkuke5feNI7zlE9L5cf/eyrpmy/YGUJjgZ36nDLGJeqa20BWMLjBd9KQoe0R1GO9I3LUeyQAr5a+FFvGtJ/c3kQcvWszWq0V2a4PnjMYcyu2MGkx+X0Eeou51Z08FdUB1+2ZOF3vPD/lNVfTCP2pLZ95KSRofkpfX93segEm3rHraxpFUnZyPSlPfP7mLNy5uZPU1XRvbQc9nQ2Nmot8R6indRM08yl/ZVym4FJQaYL0DdHXP7H95Rcm/S0QdIN4RbUBuXwtJI3Ru5rJ40SkO3kezFLb6elKlddwNkWlotvtL320/2S6OvSXB/Z2QPQvr2u1JkKOaypwxKFW73yqCpxtZjYTJfWmUtg6qSL3RoEXfIZIJQQqNUqyBUjxbzJA+INQfMPCmLAff3AeBkrQ6PoEszenDn89gz5lAKV8U0nls6nmI6ejTHRRB3a9eqIAvRYVTk7tVkaO2HDYmrbGLFvicLlHg3EZMKUVed4sPooRKZsTm+HSYIOp3WYrGm4KDejcVvbX6RaecMQARAQABtClLU1Q0Q29udGVzdCBGbGF0cGFrIDxmbGF0cGFrQGtzdDRjb250ZXN0PokCTwQTAQoAORYhBOR4Druu7f7iLrxAqJ+GlquNiTZgBQJqMAfeAxsvBAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRCfhparjYk2YL/JD/9SJglBeCtNPf8H1+lo5OlS4Gha+cBngESMWfrGQww6TonULuSSMtyMabFotEQUmZ9rGmEerwAWENH96KXJlv+fVPUIz4dREiJf4nPAluDb2yapWVQjVxorHR1OI185OXPWq0OXZ6OdZH+e5zHIDDHRlwwWU0LdyeSZrGoCe8vkWHe4x7BbG2+Ocafno14MzbTFSkHbuYgQi0DAfLhp4xuZpop4qktHs8mcEFzn97IDk2z/vXETw4Lm5jwmEFUk2wM3N65HS3DkhujR4fvZf/OKJvQ+oRCWJ2LYseAsopoPBjUT2EkhlMQKDSR6L2P2cN4gUnbwmGO6wzKRsvRIZFBAzkASHSr6gwizhOVoRILh3uTPrshbea8qif/jXfLbhMJiYpfp4zLtjPCevyaBY6ZfMKVeIR+yjUzBfqOGRQwdXW8zsfmSPMT0acurr3nvg3RNA+4gJAbbcIQRcbjeEmIeeUSiPjK3xvNz7WdyA3e6U4ocjZivTDv+xQ4Nmowz1Q3Iy9N5/k18nu2hIl9YfVt9Vn4XfJuqtYruIX9dA/F7x6uQ9M4jM8jwU+NV9HqOdlHV+eIiZuMKUy7pLPwW1QaLxmMN2nc2wutjHdh5Ywn1whVszvXgE+W1L4W4PmzW/Iw5KbjyTehEFfLNUM6bnME05fQpEcuQgmDfHPWkMf6fIA==
-IsRuntime=false

docs/PROJECT_CONTEXT.md

@@ -0,0 +1,233 @@
+# 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
+
+- 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.
+
+## 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.
+- `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/Home.md

@@ -0,0 +1,45 @@
+# KST4Contest Manual / Handbuch
+
+KST4Contest is a desktop client for the [ON4KST Chat](https://www.on4kst.org/chat/login.php), developed for VHF, UHF and SHF contest operation. It combines chat, candidate selection, sked planning, aircraft-scatter information, station mapping and connections to logging and station software.
+
+KST4Contest ist ein Desktop-Client für den [ON4KST-Chat](https://www.on4kst.org/chat/login.php), der für den Contest-Betrieb auf den VHF-, UHF- und SHF-Bändern entwickelt wurde. Er verbindet Chat, Stationsauswahl, Sked-Planung, Aircraft-Scatter-Daten, Stationskarte sowie die Anbindung an Log- und Stationssoftware.
+
+Developed by / Entwickelt von:
+
+- **DO5AMF (Marc Fröhlich)**, operator at / Operator bei **DM5M**
+- **DN9APW (Philipp Wagner)**, developer since / Entwickler seit Mai 2025
+
+---
+
+## Language / Sprache
+
+| Deutsch | English |
+|---|---|
+| [Deutsches Handbuch](de-Home) | [English manual](en-Home) |
+
+Both versions follow the same structure and describe the same application state.  
+Beide Sprachfassungen verwenden dieselbe Struktur und beschreiben denselben Programmstand.
+
+---
+
+## Start here / Hier beginnen
+
+- [Download Stable, Beta or Nightly / Stable, Beta oder Nightly herunterladen](https://kst4contest.hamradioonline.de/download/)
+- [Online manual / Online-Handbuch](https://kst4contest.hamradioonline.de/manual/)
+- [Installation](de-Installation) / [Installation](en-Installation)
+- [Configuration](en-Configuration) / [Konfiguration](de-Konfiguration)
+
+The Stable version is the normal choice for contest operation. Beta and Nightly builds are intended for testing particular changes and may contain functions which have not yet been released as Stable.
+
+Für den normalen Contestbetrieb ist die Stable-Version vorgesehen. Beta- und Nightly-Builds dienen dem gezielten Test neuer Änderungen und können Funktionen enthalten, die noch nicht als Stable veröffentlicht wurden.
+
+---
+
+## Project links / Projektlinks
+
+- [Project website / Projektwebseite](https://kst4contest.hamradioonline.de/)
+- [Downloads](https://kst4contest.hamradioonline.de/download/)
+- [Source code / Quellcode](https://github.com/praktimarc/kst4contest)
+- [GitHub Releases](https://github.com/praktimarc/kst4contest/releases)
+- [Bug reports and feature requests / Fehler und Funktionswünsche](https://github.com/praktimarc/kst4contest/issues)
+- [Development roadmap / Entwicklungsstand](https://kst4contest.hamradioonline.de/roadmap/)

github_docs/de-AirScout-Integration.md

@@ -0,0 +1,124 @@
+# AirScout-Integration
+
+> 🇬🇧 [English version](en-AirScout-Integration) | 🇩🇪 Du liest gerade die deutsche Version
+
+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.
+
+---
+
+## AirScout herunterladen
+
+Download von AirScout:
+- http://airscout.eu/index.php/download
+
+---
+
+## Flugzeugdaten-Feeds (ADS-B)
+
+Ö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
+
+Für diesen Dienst ist ein Account erforderlich. Bitte eine Spende für Thomas in Betracht ziehen – der Server-Betrieb ist nicht kostenlos!
+
+---
+
+## AirScout einrichten
+
+### Schritt 1: ADS-B-Feed in AirScout konfigurieren
+
+1. AirScout starten.
+2. In den AirScout-Einstellungen den OV3T-Feed-Account eintragen (Benutzername, Passwort, URL).
+
+![AirscoutSchritt1](as_plane_feed_1.png)
+![AirscoutSchritt2](as_plane_feed_2.png)
+
+3. Verbindung testen.
+
+### Schritt 2: UDP-Kommunikation für KST4Contest aktivieren
+
+In AirScout die UDP-Schnittstelle aktivieren:
+
+- In den AirScout-Einstellungen die entsprechende Checkbox aktivieren (nur eine Checkbox notwendig).
+- Standard-Ports nicht ändern, wenn kein besonderer Grund vorliegt.
+
+### Schritt 3: KST4Contest-Einstellungen
+
+In den KST4Contest-Preferences → **AirScout Settings**:
+- AirScout-Kommunikation aktivieren
+- IP und Port auf Standardwerte lassen (sofern nicht geändert)
+
+![AirscoutSchritt3](as_plane_feed_3.png){ width=85% }
+
+
+
+---
+
+## Kommunikation zwischen KST4Contest und AirScout (ab v1.263)
+
+**Verbesserung in v1.263**: KST4Contest sendet nur noch Stationen an AirScout, deren QRB (Entfernung) kleiner als das eingestellte **Maximum-QRB** ist. Das Abfrageintervall wurde von 12 Sekunden auf **60 Sekunden** verlängert.
+
+**Vorteile:**
+- Deutlich weniger Berechnungsaufwand für AirScout
+- Deutlich weniger Nachrichtenverkehr
+- Das Tracking-Problem mit dem „Show Path in AirScout"-Button wurde dadurch deutlich verbessert
+- Weniger Rechenleistung insgesamt
+
+Außerdem: Der Name des KST4Contest-Clients und des AirScout-Servers war früher hartcodiert (`KST` und `AS`). Ab v1.263 werden die in den Preferences eingetragenen Namen verwendet.
+
+---
+
+## Mehrere KST4Contest-Instanzen und AirScout
+
+> **Achtung**: Wenn mehrere KST4Contest-Instanzen gleichzeitig betrieben werden und bei beiden die AirScout-Kommunikation aktiviert ist, antwortet AirScout **an beide Instanzen**.
+
+Das ist unproblematisch, wenn:
+- Beide Instanzen denselben Locator verwenden, **oder**
+- Beide Instanzen unterschiedliche Login-Rufzeichen haben.
+
+Andernfalls kann es zu fehlerhaften AP-Daten kommen.
+
+---
+
+## AP-Spalte in der Benutzerliste
+
+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 | 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.
+
+## 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 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 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

@@ -0,0 +1,508 @@
+# Benutzeroberfläche
+
+> 🇬🇧 [English version](en-User-Interface) | 🇩🇪 Du liest gerade die deutsche Version
+
+## Verbinden mit dem Chat
+
+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:
+
+- Mit **Connect to …** im Einstellungsfenster werden die dort eingetragenen Werte übernommen und die Verbindung gestartet.
+- **File → Connect to …** verwendet die bereits in KST4Contest übernommenen Einstellungen.
+
+Geänderte Einstellungen müssen mit **Save Settings** gespeichert werden, wenn sie auch beim nächsten Programmstart verwendet werden sollen.
+
+Eine bestehende Verbindung kann über **File → Disconnect** oder über **Disconnect** im Einstellungsfenster beendet werden. **Exit + disconnect** beendet zusätzlich das Programm.
+
+Bei einem unerwarteten Verbindungsverlust versucht KST4Contest nach einer begrenzten Wartezeit, die ON4KST-Verbindung kontrolliert neu aufzubauen. Ein fehlgeschlagener Erstaufbau blockiert die Benutzeroberfläche nicht mehr.
+
+Ob die Verbindung lediglich als TCP-Verbindung besteht oder bereits vollständig angemeldet und synchronisiert ist, zeigt der [`LINK`-Status](#statusleiste-und-hinweise) im Hauptfenster.
+
+---
+
+## Hauptfenster-Überblick
+
+Das Hauptfenster besteht aus mehreren Bereichen:
+
+
+### Statusleiste und Hinweise
+
+Die Statusleiste befindet sich am oberen Rand des Hauptfensters neben dem Menü.
+
+![Statusleiste mit ON4KST-Verbindungsanzeige](connection_status_indicator.png)
+
+Der dauerhaft sichtbare `LINK`-Indikator zeigt den tatsächlichen Zustand der ON4KST-Verbindung:
+
+| Anzeige | Bedeutung |
+|---|---|
+| grünes `LINK` | Login und Synchronisation der konfigurierten Chat-Kategorien sind vollständig abgeschlossen |
+| gelbes `LINK…` | Verbindung, Anmeldung, Benutzerlistensynchronisation oder kontrolliertes Beenden läuft |
+| rotes `LINK!` | keine Verbindung oder Wartezeit vor einem automatischen Neuaufbau |
+
+Der Tooltip enthält den internen Verbindungsstatus und eine genauere Beschreibung des aktuellen Schritts. Der Indikator ist keine Schaltfläche.
+
+`ONLINE` wird erst gemeldet, nachdem die Anmeldung bestätigt und die Benutzerlisten der konfigurierten Kategorien vollständig empfangen wurden. Während die Verbindung noch aufgebaut oder neu synchronisiert wird, bleiben Sendfeld und **TX** deaktiviert.
+
+Bei bestimmten Ereignissen erscheinen vorübergehend weitere Hinweise:
+
+- `SKED` weist auf eine fällige Sked-Erinnerung hin. Der Text enthält das vollständige Zielrufzeichen und die verbleibende Zeit.
+- `BAND+` erscheint nach einem Logeintrag, wenn für die gearbeitete Station noch mindestens ein gemeinsames, aktiviertes und nicht gearbeitetes Band erkannt wurde.
+
+Beide Hinweise blinken ungefähr zwölf Sekunden und verschwinden anschließend wieder. Der vollständige Inhalt beziehungsweise die Herleitung steht im jeweiligen Tooltip. Die Anzeigen sind nicht anklickbar.
+
+
+### PM-Fenster (oben links)
+
+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, 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):
+
+| Spalte | Inhalt |
+|---|---|
+| Callsign | Rufzeichen der Station |
+| Name | Name beziehungsweise Zusatzinformationen aus dem Chat-Namensfeld |
+| QRA | Maidenhead-Locator |
+| QRB | Entfernung in km |
+| QTF | Richtung in Grad |
+| QRG | Zuletzt aus einer Chat-Nachricht erkannte Frequenz |
+| Tropo | Ergebnis der bandbezogenen Tropo- beziehungsweise Streckenbewertung |
+| Score | Aktueller, numerisch sortierbarer Prioritätswert des normalisierten Basisrufzeichens |
+| Act | Minuten seit der letzten Aktivität |
+| AP | AirScout-Flugzeugdaten, sofern aktiviert |
+| worked | Bandbezogener Worked-, Bandmöglichkeits- und Großfeldstatus sowie `wkdany` |
+| NOT QRV @ | Bänder, auf denen die Station manuell als nicht QRV markiert wurde |
+| Category | Chat-Kategorie des Eintrags |
+
+Die QRG-Spalte zeigt die zuletzt für eine Station erkannte Frequenz. Fehlende Nullen werden für die Anzeige ergänzt, sodass beispielsweise `144.21` als `144.210` erscheint. Erkennt KST4Contest nacheinander Frequenzen auf mehreren Bändern, zeigt die Spalte den letzten Treffer; die internen Bandinformationen können trotzdem mehrere aktuelle Bänder der Station enthalten.
+
+Relative Angaben werden zunächst mit einem höchstens 30 Minuten alten Bandkontext desselben Absenders kombiniert. Nur wenn dieser fehlt, verwendet KST4Contest das globale Fallback-Band. Erkennungsregeln, Beispiele und Grenzen: [QRG-Erkennung](de-Funktionen#qrg-erkennung).
+
+### Worked-, Band- und Großfeldstatus
+
+Die Unterspalten unter **worked** sind kompakt, weil bei mehreren aktivierten Bändern kaum Platz für ausgeschriebene Zustände bleibt. `X` kennzeichnet ein auf diesem Band gearbeitetes Rufzeichen. `a` und `B+` weisen auf ein angebotenes, noch nicht gearbeitetes Band hin. Ein angehängtes `o` bedeutet, dass das vierstellige Großfeld auf diesem Band bereits gearbeitet wurde.
+
+Die Unterspalte **wkdany** ist bandunabhängig: `x` steht für ein bereits gearbeitetes Rufzeichen, `o` für ein auf irgendeinem Band gearbeitetes Großfeld und `xo` für beides.
+
+Jede Statuszelle besitzt einen Tooltip mit der Legende und dem für die betreffende Station ermittelten Zustand. Die vollständige Herleitung einschließlich NOT-QRV-Vorrang: [Gearbeitete Rufzeichen, neue Bänder und neue Großfelder](de-Funktionen#gearbeitete-rufzeichen-neue-bänder-und-neue-großfelder).
+
+![Bandbezogener Worked-Status und Worked-Großfelder](worked_band_status.png)
+
+**Sortierung**: Klick auf Spaltenköpfe. QRB-Sortierung arbeitet numerisch (ab v1.22 korrigiert).
+
+
+Ein grün und fett dargestelltes Rufzeichen kennzeichnet eine aus einer gerichteten Nachricht hergeleitete Richtungsgelegenheit. Die Markierung bezieht sich auf den Absender der Nachricht und bleibt höchstens fünf Minuten sichtbar. Herleitung und Grenzen: [Richtungsgelegenheiten aus gerichteten Nachrichten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
+### Sendfeld
+
+Das Sendfeld enthält den vorbereiteten Text für die nächste ausgehende Nachricht.
+
+Wird eine Station bewusst per Maus oder Tastatur in der Benutzerliste ausgewählt, bereitet KST4Contest eine gerichtete Nachricht vor:
+
+```text
+/cq RUFZEICHEN
+```
+
+Dabei werden das vollständige sichtbare Rufzeichen einschließlich eines vorhandenen Suffixes und die Chat-Kategorie der ausgewählten Station beibehalten. Ein Ziel wie `9A0BB-70` wird nicht auf `9A0BB` verkürzt.
+
+Eine Hintergrundaktualisierung, Neusortierung oder Filteränderung darf einen bereits bearbeiteten Nachrichtentext nicht überschreiben. Nur eine tatsächliche Auswahl durch den Operator bereitet den `/cq`-Empfänger erneut vor.
+
+- **TX** oder `Enter` sendet den vorbereiteten Text.
+- `Esc` leert das Sendfeld.
+- Während KST4Contest nicht vollständig mit ON4KST verbunden ist, bleiben Sendfeld und **TX** deaktiviert.
+
+Shortcuts, Snippets und Variablen sind unter [Makros und Variablen](de-Makros-und-Variablen) beschrieben.
+
+### MYQRG- und SECONDQRG-Feld
+
+Die beiden QRG-Felder enthalten die eigenen Frequenzen der primären und sekundären Chat-Kategorie.
+
+`MYQRG` kann von einer aktivierten TRX-Synchronisation aktualisiert oder – bei deaktivierten automatischen QRG-Quellen – von Hand eingetragen werden. `SECONDQRG` bleibt davon unabhängig und enthält die QRG der zweiten Kategorie.
+
+Die Auswahl einer Station aus dem zweiten Chat verändert die Bedeutung der beiden Werte nicht: `MYQRG` gehört weiterhin zur primären, `SECONDQRG` zur sekundären Kategorie.
+
+Weitere Einzelheiten: [TRX-Sync-Einstellungen](de-Konfiguration#trx-sync-einstellungen).
+
+### MYQTF-Feld
+
+Das MYQTF-Feld zeigt die aktuelle Antennenrichtung als numerischen Winkel in Grad.
+
+Ist PSTRotator aktiviert, wird der Wert automatisch übernommen und das Feld ist nicht manuell bearbeitbar. Ohne aktive Rotatorsynchronisation kann die Antennenrichtung direkt eingetragen werden. Die Änderung wird beim Verlassen des Feldes übernommen.
+
+Der Wert beeinflusst unter anderem:
+
+- die QTF-Filterung,
+- die Darstellung des Antennensektors auf der Stationskarte,
+- die Prioritätsberechnung,
+- die AP-Timeline und
+- die Variable `MYQTF`.
+
+---
+
+## 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.
+
+Ist ein Nachrichtentext breiter als die sichtbare Zelle, zeigt KST4Contest den vollständigen Inhalt als Tooltip an. Dazu die Maus kurz über die betreffende **Message**-Zelle halten. Passt der Text vollständig in die Spalte, wird kein zusätzlicher Volltext-Tooltip eingeblendet.
+
+Webadressen mit `http://`, `https://` oder dem Präfix `www.` werden innerhalb des Nachrichtentextes als Links dargestellt. Ein Klick öffnet die Adresse im Standardbrowser des Betriebssystems. Andere Protokolle werden nicht als Link behandelt.
+
+![Abgeschnittener Nachrichtentext mit Volltext-Tooltip und Link](message_tooltip_and_link.png)
+
+Damit muss der Divider nicht allein deshalb verschoben werden, um eine einzelne längere Nachricht zu lesen. Für einen dauerhaft breiteren Nachrichtenbereich kann er selbstverständlich weiterhin angepasst werden.
+
+---
+
+## Filter und Reachability-Steuerung
+
+Die Filterleiste befindet sich oberhalb der Chatmember-Tabelle. Filter können miteinander kombiniert werden; eine Station bleibt nur sichtbar, wenn sie alle aktiven Bedingungen erfüllt.
+
+![Umgebrochene Filterleiste bei schmaler Chatmember-Ansicht](filter_bar_wrapped.png)
+
+### Stationsfilter
+
+| Bedienelement | Wirkung |
+|---|---|
+| **Show only QTF** | Zeigt nur Stationen innerhalb der gewählten Antennenrichtung und des konfigurierten Öffnungswinkels |
+| **Show only QRB [km] <=** | Begrenzt die Liste auf die eingetragene maximale Entfernung |
+| **Find** | Filtert nach einem vollständigen oder teilweisen Rufzeichen |
+| **wkd** | Blendet Basisrufzeichen aus, die bereits auf mindestens einem unterstützten Band gearbeitet wurden |
+| einzelne Band-Schaltflächen | Blenden Stationen aus, die auf dem betreffenden Band bereits gearbeitet oder dort als NOT QRV markiert wurden |
+| **Inactive stations** | Blendet Stationen aus, deren letzte Chataktivität mehr als 20 Minuten zurückliegt |
+| **Only new grids** | Zeigt nur Stationen aus vierstelligen Großfeldern, die bisher auf keinem Band gearbeitet wurden |
+| **New bands** | Zeigt Stationen mit mindestens einer erkannten, lokal aktivierten und noch nicht gearbeiteten Bandmöglichkeit |
+| **Tropo >=0dB** | Zeigt Stationen mit einer berechneten, nicht negativen SSB-Marge |
+| **AS next 5m** | Zeigt Stationen mit einem aktuellen oder innerhalb der nächsten fünf Minuten erwarteten AirScout-Fenster |
+
+Bei **New bands** werden aktuelle QRGs, Bandangaben im Namensfeld und aktive Rufzeichenvarianten gemeinsam ausgewertet. Manuelle NOT-QRV-Markierungen haben Vorrang.
+
+Der Filter **Tropo >=0dB** entfernt nur Stationen, für die eine abgeschlossene Berechnung eine negative Marge ergeben hat. Noch nicht berechnete oder fehlgeschlagene Auswertungen bleiben sichtbar. Andernfalls würde ein fehlender API-Wert wie ein nachgewiesen ungeeigneter Funkweg behandelt.
+
+### Grid color
+
+**Grid color** ist kein Filter. Die Funktion verändert ausschließlich die Darstellung des QRA-Feldes und kennzeichnet bereits gearbeitete vierstellige Großfelder.
+
+Die Station bleibt unabhängig von der Farbmarkierung in der Tabelle sichtbar. **Reset filters** deaktiviert diese Anzeige deshalb nicht.
+
+### Reachability und Calc selected
+
+Das Dropdown **Reachability** bestimmt das Band, auf das sich die Tropo-Spalte, der Tropo-Filter und eine ausdrücklich gestartete Streckenberechnung beziehen.
+
+- **Auto** leitet das Band aus der aktuellen Stations-QRG, Bandangaben im Namensfeld und der unterstützten Chat-Kategorie her.
+- Ein ausdrücklich gewähltes Band übersteuert diese automatische Auswahl für die Reachability-Auswertung.
+
+Eine Änderung des Dropdowns startet keine Berechnung für die gesamte Benutzerliste. Das wäre bei einer Online-Höhendatenquelle unnötig langsam und würde externe API-Abfragen vervielfachen.
+
+**Calc selected** berechnet ausschließlich die aktuell ausgewählte Station auf dem gewählten beziehungsweise automatisch hergeleiteten Band. Das Ergebnis wird anschließend in der Tropo-Spalte und den zugehörigen Ansichten verwendet.
+
+### Filter zurücksetzen
+
+**Reset filters** entfernt:
+
+- den QTF-Filter,
+- den QRB-Filter,
+- den Inhalt des Rufzeichen-Suchfeldes,
+- alle Worked- und Bandfilter,
+- **Inactive stations**,
+- **Only new grids**,
+- **New bands**,
+- **Tropo >=0dB** und
+- **AS next 5m**.
+
+Die internen Filterprädikate werden dabei ausdrücklich geleert. Es genügt nicht, lediglich die sichtbaren Toggle-Buttons zurückzusetzen.
+
+Nicht verändert werden:
+
+- **Grid color**, weil es sich um eine Darstellungsoption handelt, und
+- die Auswahl im **Reachability**-Dropdown, weil sie das Berechnungsband festlegt und nicht unmittelbar die Tabelle filtert.
+
+### Verhalten bei schmaler Ansicht
+
+Die Filterleiste besitzt keine feste Breite. QTF-, Worked- und Reachability-Controls nutzen zunächst den verfügbaren Platz ihrer jeweiligen Zeile.
+
+Wird der mittlere Divider nach rechts verschoben und die Chatmember-Ansicht dadurch schmaler, wechseln Bedienelemente erst dann in die nächste Zeile, wenn ihre tatsächlich benötigte Breite nicht mehr ausreicht. Wird der Bereich wieder breiter, ordnen sie sich unmittelbar neu an.
+
+Im Klartext: Die Filter bestimmen den Tabelleninhalt, aber nicht mehr die Mindestbreite der gesamten rechten Programmseite.
+
+---
+
+## Stationsinfo-Panel (Further Info)
+
+Rechts unten werden die Nachrichten der ausgewählten Station zusammengeführt. Dazu gehören öffentliche Nachrichten, Privatnachrichten an die eigene Station und – soweit im Chat sichtbar – Privatnachrichten an andere Stationen.
+
+Der im Panel gewählte Filter bestimmt, welche dieser Nachrichten angezeigt werden. Unter **Settings → GUI** lässt sich festlegen, welcher Filter beim Öffnen einer Stationsinformation vorausgewählt ist:
+
+- alle Nachrichten,
+- Privatnachrichten an die eigene Station,
+- Privatnachrichten an andere Stationen oder
+- öffentliche Nachrichten.
+
+Die Einstellung verändert nur die Darstellung im Stationsinfo-Panel. Nachrichten werden dadurch weder verworfen noch aus den übrigen Nachrichtentabellen entfernt. Der Filter kann im Panel jederzeit für die aktuell betrachtete Station gewechselt werden.
+
+Im unteren Bereich können für die ausgewählte Station bandbezogene **Not QRV**-Markierungen gesetzt werden. Sichtbar sind die Bänder, die in den Stationseinstellungen für die eigene Station aktiviert wurden. **tag not qrv all** setzt beziehungsweise entfernt die Markierung für alle unterstützten Bänder gemeinsam, einschließlich momentan nicht eingeblendeter Bänder.
+
+Die Änderung wirkt sofort auf die Spalte **NOT QRV @**, die Bandmöglichkeiten und die zugehörigen Filter. Sie wird in der internen Datenbank gespeichert und nach einem Neustart wiederhergestellt.
+
+![Bandbezogene NOT-QRV-Markierungen im Further-Info-Bereich](not_qrv_controls.png)
+
+Im selben Bereich wird der aktuelle **Priority score** der ausgewählten Station angezeigt.
+
+Mit **Sked fail** lässt sich ein fehlgeschlagener Versuch markieren. Der Score des normalisierten Basisrufzeichens wird dadurch stark reduziert. **Reset fail** entfernt diese Markierung wieder. Die Markierung gilt für alle aktiven Suffix- und Kategorievarianten der Station und bleibt innerhalb der laufenden Programmsitzung erhalten.
+
+Darunter befinden sich die Bedienelemente zum Anlegen eines Skeds:
+
+| Bedienelement | Bedeutung |
+|---|---|
+| **Sked in** | Zeit bis zum Sked |
+| **Band** | vereinbartes Band aus den eigenen aktivierten Bändern |
+| **Mode** | `SSB` oder `CW` für eine mögliche Win-Test-Übergabe |
+| **Create sked** | internen Sked anlegen |
+| **Remind-PM in** | automatische Reminder-PMs aktivieren |
+| **2+1**, **5+2+1**, **10+5+2+1** | Zeitpunkte der Reminder-PMs vor dem Termin |
+
+![Sked-Steuerung im Further-Info-Bereich](sked_controls.png)
+
+Das vorgeschlagene Band wird aus aktuellen QRG- und Namensinformationen der Station hergeleitet. Vor dem Anlegen kann es ausdrücklich geändert werden. Die Mode-Auswahl betrifft nur die Übergabe an Win-Test; der interne Sked und die Reminder-PMs funktionieren unabhängig davon.
+
+**Create sked** legt den Termin immer zuerst in KST4Contest an. Ist der Win-Test-Netzwerk-Listener aktiv, wird anschließend zusätzlich eine Übergabe an Win-Test versucht. Kann keine zum ausgewählten Band passende QRG ermittelt werden oder ist Win-Test nicht erreichbar, bleiben der interne Sked, seine Priorisierung und gegebenenfalls angelegte Reminder erhalten.
+
+Die vollständige Herleitung und die Grenzen der Funktion sind unter [Skeds und Sked-Erinnerungen](de-Funktionen#skeds-und-sked-erinnerungen) beschrieben.
+
+---
+
+## Prioritätsliste
+
+Die kompakte Prioritätsleiste befindet sich rechts zwischen Benutzerliste und Further-Info-Bereich. Sie zeigt die beiden derzeit höchstbewerteten Kandidaten unmittelbar im Hauptfenster:
+
+```text
+Priority:  1 RUFZEICHEN SCORE  2 RUFZEICHEN SCORE  more
+```
+
+Ein Klick auf einen der beiden Kandidaten wählt den dazugehörigen aktiven Chatmember aus. Dabei werden das vollständige Rufzeichen einschließlich Suffix und die zugehörige Chat-Kategorie verwendet.
+
+Die Schaltfläche **more** öffnet ein separates Fenster mit bis zu 15 Kandidaten. Die Liste ist nach absteigendem Score sortiert. Ein Doppelklick wählt den betreffenden Kandidaten aus und schließt das Fenster.
+
+![Priority Score, kompakte Kandidatenliste und Further-Info-Steuerung](priority_score_overview.png)
+
+Stationen mit einem Score von `0` werden nicht in die Prioritätsliste aufgenommen. In der Benutzerliste bleiben sie sichtbar, sodass der Ausschluss nachvollzogen und beispielsweise durch eine geänderte NOT-QRV-Markierung korrigiert werden kann.
+
+Der Score wird für das normalisierte Basisrufzeichen berechnet. Mehrere aktive Varianten wie `9A0BB-2` und `9A0BB-70` können daher in der Benutzerliste denselben Wert anzeigen. Die Chatmember bleiben trotzdem getrennte Nachrichtenziele.
+
+Neue Nachrichten, AirScout-Daten, Skeds und Statusänderungen lösen eine Neuberechnung aus. Zusätzlich erfolgt eine regelmäßige Aktualisierung im Hintergrund. Eine kurzzeitig noch nicht angepasste Reihenfolge ist deshalb kein Fehler.
+
+Herleitung und Grenzen: [Prioritätsscore und Prioritätsliste](de-Funktionen#prioritätsscore-und-prioritätsliste-ab-v140).
+
+---
+
+## Stationskarte
+
+Die Stationskarte kann auf zwei Wegen geöffnet werden:
+
+- **Windows → Show / hide station map** öffnet oder schließt das Kartenfenster.
+- **Show on map** im **Further Info**-Bereich öffnet die Karte und fokussiert die ausgewählte Station.
+
+Die Karte verwendet die Stationen, die nach Anwendung der aktuellen Benutzerlistenfilter noch sichtbar sind. Die Kopfzeile zeigt die Anzahl der dargestellten Stationen und weist mit `filtered view active` auf eine gefilterte Ansicht hin.
+
+![Stationskarte mit ausgewählter Station und eingeblendeter Streckenanalyse](station_map_path_analysis.png)
+
+### Station auswählen
+
+Ein einzelner Stationsmarker kann direkt angeklickt werden. KST4Contest:
+
+1. übernimmt den konkreten Chatmember als aktuelle Auswahl,
+2. scrollt die Benutzerliste zum entsprechenden Eintrag,
+3. aktualisiert den **Further Info**-Bereich und
+4. bereitet das vollständige sichtbare Rufzeichen als `/cq`-Empfänger vor.
+
+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:
+
+- vollständiges Rufzeichen,
+- Locator,
+- QRB und QTF,
+- erkannte aktive Bänder,
+- eine gegebenenfalls vorhandene `B+`-Bandmöglichkeit und
+- die zuletzt bekannten QRGs.
+
+Lange Inhalte werden in der Kopfzeile gekürzt. Der vollständige Text steht im Tooltip.
+
+### Auswahl mit Reset view löschen
+
+**Reset view** löscht die Stationsauswahl, ohne die Kartenposition oder den Zoomlevel zu verändern.
+
+Dabei werden:
+
+- die ausgewählte Station zurückgesetzt,
+- die Auswahl in der Benutzerliste aufgehoben,
+- die Verbindungslinie zur Gegenstation entfernt,
+- eine noch laufende Auswertung der vorherigen Station verworfen und
+- der rechte Analysebereich entfernt.
+
+Die Karte selbst bleibt im zuvor gewählten Ausschnitt. Die Funktion ist deshalb kein geografischer Reset auf den eigenen Standort.
+
+![Stationskarte nach Reset view ohne ausgewählte Station](station_map_reset.png)
+
+Wird anschließend wieder ein einzelner Marker gewählt, erscheinen Stationsauswahl und Analysebereich erneut.
+
+### DX-Cluster-Spot auslösen
+
+**Trigger cluster spot** erscheint nur bei ausgewählter Station. Die Schaltfläche sendet einen einzelnen Spot an die mit dem integrierten DX-Cluster-Server verbundenen Logprogramme.
+
+Vorausgesetzt werden:
+
+- ein aktivierter lokaler DX-Cluster-Server,
+- mindestens ein verbundener Cluster-Client und
+- eine für die ausgewählte Station verwendbare QRG.
+
+Der Spot wird nicht an einen öffentlichen Internet-Cluster gesendet.
+
+### Streckenanalyse
+
+Unterhalb der Karte befindet sich das Höhenprofil. Der rechte Analysebereich zeigt unter anderem:
+
+- verwendete Datenquelle und Anzahl der Höhenpunkte,
+- Analysefrequenz,
+- Erdkrümmungs- beziehungsweise Refraktionsmodell,
+- Radio- und Geländehorizont,
+- Fresnel-Freiheit,
+- erkannte Hindernisse,
+- Link-Budget,
+- geschätzten Empfangspegel und
+- eine zusammenfassende Pfadbewertung.
+
+Die Auswertung verwendet dasselbe zentral hergeleitete Band wie die Reachability-Funktionen. Ein im **Reachability**-Dropdown ausdrücklich gewähltes Band wird berücksichtigt.
+
+Die Werte bleiben technische Abschätzungen. Gebäude, Bewuchs, lokale Abschattungen, aktuelle Ausbreitungsbedingungen und nicht bekannte Stationsparameter können das reale Ergebnis deutlich verändern.
+
+### Streckenanalyse ausblenden
+
+Mit **Hide path analysis** werden Höhenprofil und rechter Analysebereich gemeinsam ausgeblendet. Der Kartenbereich erhält dadurch mehr Platz.
+
+![Stationskarte mit ausgeblendeter Pfadanalyse](station_map_compact.png)
+
+Der Hinweis **Path analysis is hidden** und die Schaltfläche **Show path analysis** bleiben sichtbar. Die Funktion kann daher ohne Umweg wieder eingeschaltet werden.
+
+Ist beim Wiedereinblenden keine Station ausgewählt, erscheint kein leerer rechter Bereich. Er wird erst wieder aufgebaut, nachdem eine konkrete Station gewählt wurde.
+
+Die Auswahl wird gespeichert und beim nächsten Programmstart wiederhergestellt.
+
+Der Divider zwischen Karte und Detailbereich lässt sich horizontal verschieben. Bei einem schmalen Detailbereich werden längere Angaben umgebrochen; reicht die verfügbare Höhe nicht aus, erscheint eine vertikale Scrollleiste.
+
+Ausführliche Herleitung und Grenzen: [Stationskarte und Streckenanalyse](de-Funktionen#stationskarte-und-streckenanalyse-ab-v141).
+
+---
+
+## Globale Nachrichtentabs und Monitorfenster
+
+Der untere Bereich des Hauptfensters enthält drei globale Nachrichtentabs. Ihr Inhalt ist nicht von der aktuell in der Benutzerliste ausgewählten Station abhängig.
+
+| Tab | Inhalt |
+|---|---|
+| **Public messages** | Öffentliche Chatnachrichten, CQ-Rufe und Beacons |
+| **DXCluster messages** | Über ON4KST empfangene DX-Cluster-Meldungen |
+| **QSO of the other** | Gerichtete Nachrichten zwischen zwei anderen Stationen |
+
+![Globale Nachrichtentabs im Hauptfenster](global_message_tabs.png)
+
+Im Tab **QSO of the other** werden Absender und Empfänger getrennt dargestellt. Die Spalten **Last QRG TX** und **Last QRG RX** enthalten die zuletzt für beide Stationen bekannten Frequenzen. Sie geben nicht zwingend die QRG der angezeigten Unterhaltung wieder.
+
+**wkd TX?** und **wkd RX?** zeigen den globalen Worked-Status der beiden Basisrufzeichen. Die Angaben sind nicht bandbezogen.
+
+Der Tab **DXCluster messages** zeigt den meldenden und den gemeldeten Teilnehmer, deren Locator, die QRG, den Meldungstext und den globalen Worked-Status der gemeldeten Station. Welche Felder tatsächlich gefüllt sind, hängt von der vom ON4KST-Server übertragenen Meldung ab.
+
+Nachrichtentexte bleiben einzeilig. Ist eine Zelle zu schmal, erscheint der vollständige Inhalt als Tooltip. Webadressen im Meldungstext lassen sich anklicken.
+
+### Separates Monitorfenster
+
+Zusätzlich öffnet KST4Contest das Fenster **Cluster & QSO of the other**. Es zeigt oben die DX-Cluster-Meldungen und darunter die gerichteten Nachrichten zwischen anderen Stationen.
+
+![Separates Cluster- und QSO-Monitorfenster](cluster_qso_monitor.png)
+
+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:
+
+```text
+Windows → Hide cluster / stranger QSOs
+Windows → Show cluster / stranger QSOs
+```
+
+Die Tabellen im Hauptfenster und im Monitorfenster greifen auf dieselben Daten zu. Das Ausblenden des Monitorfensters beendet daher weder den Empfang noch die Darstellung in den unteren Tabs.
+
+Herleitung und Grenzen: [Globale Nachrichtenansichten](de-Funktionen#globale-nachrichtenansichten).
+
+---
+
+## Menü
+
+### File
+
+- **Connect to …** startet die Verbindung mit den bereits übernommenen Einstellungen.
+- **Disconnect** beendet die aktuelle ON4KST-Verbindung, ohne KST4Contest zu schließen.
+- **Exit + disconnect** beendet die Verbindung und anschließend das Programm.
+
+Die Connect- und Disconnect-Einträge werden entsprechend dem aktuellen Verbindungszustand aktiviert oder deaktiviert.
+
+### Options
+
+- **Set QRG as name in Chat (main category)** sendet `/SETNAME` mit der aktuellen `MYQRG` an die primäre Chat-Kategorie.
+- **Show me as away in chat** sendet `/AWAY`.
+- **Show me as active in chat** sendet `/BACK`.
+- **Show options** blendet das Einstellungsfenster ein beziehungsweise aus.
+
+Die serverbezogenen Funktionen sind nur bei vollständig aufgebauter ON4KST-Verbindung verfügbar.
+
+### Windows
+
+- **Hide cluster / stranger QSOs** beziehungsweise **Show cluster / stranger QSOs** blendet das zusätzliche Cluster- und QSO-Monitorfenster aus oder wieder ein.
+- **hide options** beziehungsweise **show options** blendet das Einstellungsfenster aus oder wieder ein.
+- **Use dark mode design** aktiviert das dunkle Farbschema.
+- **Use default mode design** aktiviert das normale helle Farbschema.
+- **Show / hide station map** öffnet beziehungsweise schließt das separate Fenster mit Stationskarte und Streckenanalyse.
+
+---
+
+## Fenstergrößen und Divider
+
+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, genügt eine manuelle Korrektur; die neue Größe wird automatisch gespeichert.
+
+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.
+
+---
+
+## Tipps zur Bedienung
+
+- **Einstellungsfenster geöffnet lassen**: Schneller Zugriff auf Beacon-Aktivierung/Deaktivierung.
+- **Rechtsklick in der Benutzerliste**: Öffnet das Snippet-Menü und weitere Aktionen (QRZ.com-Profil, NOT-QRV-Tags setzen).
+- **Enter aus dem Chat heraus**: Wenn im Sendfeld Text steht, sendet Enter direkt – auch wenn der Fokus woanders liegt.
+- **Beacon stoppen**: Beim Scannen von Frequenzen den Beacon ausschalten, damit der Chat nicht mit Meldungen überflutet wird.

github_docs/de-Changelog.md

@@ -0,0 +1,486 @@
+# Changelog
+
+> 🇬🇧 [English version](en-Changelog) | 🇩🇪 Du liest gerade die deutsche Version
+
+Versionsverlauf von KST4Contest / PraktiKST.
+
+Die veröffentlichten Stable-Versionen und ihre Programmpakete stehen unter [GitHub Releases](https://github.com/praktimarc/kst4contest/releases). Zusätzlich enthält diese Seite die Änderungen des aktuellen Entwicklungsstands, soweit sie bereits implementiert und geprüft wurden.
+
+---
+
+## 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.
+
+### Neu
+
+- **Sichtbarer ON4KST-Verbindungsstatus:** Ein kompakter `LINK`-Indicator im Hauptfenster zeigt den tatsächlichen Zustand der ON4KST-Verbindung an. Grün bedeutet vollständig angemeldet und synchronisiert, Gelb kennzeichnet Verbindungsaufbau und Synchronisation, Rot eine unterbrochene Verbindung, einen Fehler oder die Wartezeit vor dem nächsten Verbindungsversuch.
+
+- **Gemeinsame Herleitung verfügbarer Bänder:** Ein zentraler `BandOpportunityResolver` wertet aktuelle QRGs, Bandangaben im Namensfeld, aktive Rufzeichenvarianten, Worked-Informationen und NOT-QRV-Markierungen gemeinsam aus. Benutzerliste, **New bands**, Band-Upgrade-Hinweis, Priority Score, Stationskarte und automatische Bandauswahl verwenden damit dieselbe Grundlage.
+
+- **Erweiterte Bandanzeige:** Die Bandspalten unterscheiden jetzt:
+  - `X` für auf diesem Band gearbeitet,
+  - `a` für ein angebotenes, noch nicht gearbeitetes Band einer insgesamt neuen Station,
+  - `B+` für ein angebotenes, noch nicht gearbeitetes Band einer bereits auf einem anderen Band gearbeiteten Station und
+  - `o` für ein auf diesem Band bereits gearbeitetes Locator-Großfeld.
+
+  Die Anzeigen können kombiniert werden, beispielsweise als `ao` oder `B+o`. Die zusätzlichen Kennzeichnungen `a` und `o` lassen sich in den GUI-Einstellungen separat ausblenden.
+
+- **Unterstützung für 50 und 70 MHz:** Beide Bänder stehen in der Stationskonfiguration, den Worked- und NOT-QRV-Funktionen, der Benutzerliste, den Filtern, der internen Datenbank, der UCXLog-Auswertung und dem Win-Test-Listener zur Verfügung. Bereits gespeicherte Datenbanken werden um die benötigten Spalten ergänzt.
+
+- **Globale Nachrichtentabs:** Öffentliche Nachrichten, ON4KST-DX-Cluster-Meldungen und gerichtete Nachrichten zwischen anderen Stationen können direkt im Hauptfenster angezeigt werden. Das bisherige separate Monitorfenster bleibt zusätzlich verfügbar und verwendet dieselben Nachrichtenspeicher.
+
+- **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.
+
+- **Ausblendbare Streckenanalyse:** Geländeprofil und Analysebereich der Stationskarte können vollständig ausgeblendet werden. Die Auswahl wird gespeichert und beim nächsten Programmstart wiederhergestellt.
+
+### Geändert
+
+- **Sessionbezogene ON4KST-Verbindungssteuerung:** Socket, Reader, Writer, Messagebus und Warteschlangen gehören jetzt zu einer eindeutig identifizierten Verbindungssession. Veraltete Threads einer abgelösten Verbindung können dadurch keine Daten mehr verarbeiten oder die neue Verbindung schließen. `ONLINE` wird erst nach bestätigtem Login und vollständig empfangenen Benutzerlisten gemeldet. Verbindungsaufbau, Login und Synchronisation besitzen feste Zeitlimits; Heartbeats, ausbleibende Eingangsdaten, EOF sowie Lese- und Schreibfehler werden überwacht und lösen bei Bedarf einen kontrollierten Neuaufbau mit Backoff aus.
+
+- **ON4KST-Protokollbefehle abgesichert:** Ausgehende Befehle werden zentral aufgebaut und auf gültige Kategorien, Locatoren und unerlaubte Frame-Trennzeichen geprüft. Da ON4KST pro TCP-Session nur einen Locator verwaltet, wird für beide Chat-Kategorien der Hauptlocator verwendet und eine abweichende zweite Konfiguration protokolliert, statt widersprüchliche Befehle an den Server zu senden.
+
+- **QRG-Erkennung präzisiert:** Vollständige und relative Frequenzangaben werden weiterhin erkannt. Nackte dreistellige Zahlen gelten nur noch bei erkennbarem Frequenzkontext als QRG. Signalrapporte, Bandangaben und andere Zahlen erzeugen dadurch seltener falsche Frequenzen.
+
+- **Stationsbezogener Frequenzkontext:** Bei relativen QRGs verwendet KST4Contest zuerst einen höchstens 30 Minuten alten Bandkontext derselben Station. Erst wenn dieser fehlt, wird das global konfigurierte Fallback-Band verwendet.
+
+- **Fallback-Band als Dropdown:** Das globale Fallback kann nur noch aus unterstützten Bandwerten ausgewählt werden. Es betrifft die gesamte QRG-Erkennung und nicht nur DX-Cluster-Spots.
+
+- **Einheitliche QRG-Darstellung:** Frequenzen werden in Benutzer- und Nachrichtentabellen mit mindestens drei Nachkommastellen dargestellt.
+
+- **Bandabhängige AirScout- und Streckenberechnung:** KST4Contest leitet für jede Station eine möglichst realistische Frequenz aus der aktuellen QRG und den bekannten Bandinformationen ab. AirScout erhält kanonische Bandwerte. Die frühere Zwischenlösung mit 430 MHz wurde durch 432 MHz ersetzt.
+
+- **Gemeinsame Frequenzherleitung:** AirScout, **Calc selected** und die Pfadanalyse der Stationskarte verwenden denselben `PropagationFrequencyResolver`. Ein im Reachability-Dropdown ausdrücklich gewähltes Band wird bei manuellen Berechnungen berücksichtigt.
+
+- **Rufzeichenvarianten getrennt verarbeitet:** Aktive Chatmember werden durch das vollständige Rufzeichen einschließlich Suffix und die Chat-Kategorie unterschieden. `DN9APW`, `DN9APW-2` oder vergleichbare Logins bleiben dadurch getrennte Nachrichtenziele.
+
+- **Gemeinsame Basisinformationen:** Worked-Flags, NOT-QRV-Informationen und der Priority Score werden weiterhin für Varianten desselben Basisrufzeichens gemeinsam ausgewertet. Getrennte Nachrichtenziele führen damit nicht zu widersprüchlichen Worked-Daten.
+
+- **Priority Score korrigiert:** Stationen ohne gemeinsames verfügbares Band oder mit übersteuernder NOT-QRV-Markierung werden nicht mehr als Prioritätskandidaten angeboten. Bandgelegenheiten bereits gearbeiteter Stationen können einen eigenen Priority Boost erhalten.
+
+- **Sked-Erstellung erweitert:** Das Band wird aus den lokal aktivierten Bändern gewählt. Für die Win-Test-Übergabe wird `SSB` oder `CW` ausdrücklich ausgewählt, statt den Mode unzuverlässig aus dem Band abzuleiten.
+
+- **Win-Test-Sked-Übergabe präzisiert:** Die QRG muss zum gewählten Band passen. Sichtbare KST-Suffixe werden für das Logziel entfernt, portable Bestandteile bleiben erhalten und die Zeitangaben der `ADDSKED`-Pakete werden korrekt erzeugt. Ein Fehler bei der Übergabe entfernt den internen KST4Contest-Sked nicht.
+
+- **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 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.
+
+- **Nachrichtentabellen verbessert:** Abgeschnittene Nachrichtentexte erhalten einen Tooltip mit dem vollständigen Inhalt. Erkannte Webadressen können im Systembrowser geöffnet werden.
+
+- **Kompaktere Filterleiste:** Die Filter bleiben bei normaler Breite in einer kompakten Anordnung und werden erst dann umgebrochen, wenn der tatsächlich verfügbare Platz nicht mehr ausreicht. Der mittlere Divider kann dadurch weiter verschoben werden.
+
+- **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
+
+- **Zuverlässige Benutzerliste beim Login:** Ungültige oder unvollständige `UA0`-Teilnehmerdatensätze werden einzeln verworfen und protokolliert, ohne die Verarbeitung der alphabetisch folgenden Teilnehmer abzubrechen. Die gültigen Einträge werden zunächst pro Kategorie gesammelt und erst mit dem ersten zugehörigen `UE`-Abschlussframe vollständig veröffentlicht.
+
+- **Benutzerliste verschwindet nach dem Login:** ON4KST kann nach Namens-, Status- oder anderen Live-Änderungen weitere `UE`-Frames für dieselbe Kategorie senden. Wiederholte Abschlussframes werden jetzt erkannt und ignoriert, damit eine bereits gefüllte Benutzerliste nicht durch eine leere Momentaufnahme ersetzt wird.
+
+- **Fehlgeschlagener Erstaufbau und Verbindungsverlust:** Wenn beim Programmstart keine Verbindung zum Server hergestellt werden kann, läuft KST4Contest nicht mehr in eine Endlos- oder Busy-Wait-Schleife. Die Oberfläche bleibt bedienbar und weitere Versuche erfolgen mit begrenztem Backoff. Auch ein vom Server geschlossener oder über längere Zeit stummer Socket wird zuverlässig erkannt.
+
+- **Messagebus-Protokollierung:** Bereits korrekt verarbeitete ON4KST-Frames werden nicht mehr zusätzlich als `Critical, detected unhandled Chatmessage` gemeldet. Nur tatsächlich unbekannte Telegramme erreichen noch diesen Logzweig.
+
+- **Passwort im Fehlerlog:** Das ON4KST-Passwort wird beim Verbindungsaufbau nicht mehr im Klartext in die Konsole oder Logdatei geschrieben.
+
+- **Langzeitfehler der Stationsauswahl:** Die vom Message-Thread verwalteten Chatmember wurden von der JavaFX-Ansicht entkoppelt. Gleichzeitige Änderungen der Daten und Tabellenansicht führen dadurch nicht mehr nach längerer Laufzeit zu fehlerhaften Auswahlmodellen oder Concurrent-Modification-Problemen.
+
+- **Keine Phantom-Chatmember durch UM3:** Historische oder zusätzliche Servermeldungen erzeugen keine Benutzerlisteneinträge für Stationen, die nicht tatsächlich im Chat angemeldet sind.
+
+- **Nachrichten an Rufzeichen mit Suffix:** Mehrere gleichzeitig angemeldete Varianten desselben Basisrufzeichens überschreiben sich nicht mehr gegenseitig. Damit wurde [Issue #73](https://github.com/praktimarc/kst4contest/issues/73) behoben.
+
+- **DX-Cluster-Locatoren:** Sender und gemeldete Station erhalten nicht mehr versehentlich denselben Locator. Damit wurde [Issue #48](https://github.com/praktimarc/kst4contest/issues/48) behoben.
+
+- **Worked-Anzeige in „QSO of the other“:** Die Worked-Spalten verwenden wieder die jeweils richtige sendende beziehungsweise empfangende Station.
+
+- **Fehlende SECONDAP-Daten:** Eine nicht vorhandene zweite Aircraft-Scatter-Gelegenheit führt beim Bearbeiten der Anzeige nicht mehr zu einer ungültigen Textauswahl und JavaFX-Exception.
+
+- **Historische Rufzeichen:** Das Hervorheben oder Anklicken eines Rufzeichens, das nicht mehr in der aktuellen Benutzerliste vorhanden ist, läuft nicht mehr in eine Exception.
+
+- **Win-Test-Sked-Zeit und Rufzeichen:** Zeitstempel, Band-QRG-Zuordnung sowie die Behandlung von KST-Suffixen und portablen Rufzeichen wurden korrigiert.
+
+- **Filter-Reset:** Alle Filterprädikate werden tatsächlich entfernt; der sichtbare Zustand des Buttons entspricht wieder dem wirksamen Filterzustand.
+
+### Dokumentation und Auslieferung
+
+- Das deutsche und englische Handbuch wurde systematisch mit dem Quellcode abgeglichen, erweitert und mit aktuellen Screenshots versehen. Die Dokumentation erklärt nicht nur die Bedienelemente, sondern auch Herleitung, Datenquellen und Grenzen der Funktionen.
+
+- Für Arch Linux stehen `kst4contest-bin`, `kst4contest` und `kst4contest-git` im AUR zur Verfügung.
+
+- Die Downloadseite unterscheidet Stable, Beta und Nightly und bietet die jeweils tatsächlich vorhandenen Pakete für Windows, Linux und macOS an.
+
+- Nightly-Pakete werden automatisiert aus dem aktuellen `main`-Branch gebaut. Stable- und Beta-Releases verwenden reproduzierbare Paketnamen für die unterstützten Plattformen.
+
+- **Signierte und notarisierte macOS-Pakete:** Die DMG-Dateien für Apple Silicon und Intel sind mit einer Apple Developer ID signiert und von Apple notarisiert; das Notarisierungsticket ist in der DMG hinterlegt. Der erste Start funktioniert damit per Doppelklick, ohne den bisherigen Umweg über **Öffnen** im Kontextmenü, und die Prüfung gelingt auch ohne Internetverbindung. Betroffen sind Nightly-, Beta- und Stable-Pakete gleichermaßen. Die Windows-Pakete sind weiterhin nicht signiert.
+
+- **Korrekte Bundle-Kennung und Version unter macOS:** Die Anwendung meldet sich jetzt als `de.x08.KST4Contest` statt als `kst4contest.view` und trägt die tatsächliche Versionsnummer im Bundle. Bisher wies jedes Release im Finder unter **Informationen** die Version `1.0` aus. Bestehende Einstellungen sind davon nicht betroffen, da KST4Contest seine Daten in `~/.praktiKST/` ablegt und nicht an der Bundle-Kennung festmacht.
+
+### Bekannte Grenzen
+
+- Die aktive Geländedatenquelle verwendet Open-Meteo mit Copernicus-GLO-90-Daten und höchstens 100 Höhenpunkten pro Strecke.
+
+- Der atmosphärische K-Faktor ist derzeit fest auf `4/3` eingestellt.
+
+- Für die Gegenstation wird eine Antennenhöhe von 10 Metern über Grund angenommen.
+
+- Aircraft-Scatter-Daten aus AirScout und die Geländeanalyse der Stationskarte sind weiterhin getrennte Bewertungen.
+
+- 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)
+
+**Hotfix für Texteingabe und Fokusverhalten**
+
+### Behoben
+
+- Das Nachrichteneingabefeld wurde nach einiger Zeit beziehungsweise bei bestimmten UI-Aktualisierungen unerwartet geleert.
+- Beim Filtern oder Auswählen einer Station wurde der Eingabefokus unbeabsichtigt wieder in das Sendefeld verschoben.
+
+Die korrigierte Version ist als [Release v1.41.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1) verfügbar.
+
+---
+
+
+## v1.41.0 (2026-07-01)
+
+**Stationskarte, begrenzte Nachrichtenspeicher und bildschirmgerechtes Hauptfenster**
+
+### Neu
+
+- **Stationskarte:** Eine interaktive OpenStreetMap-Karte stellt aktive Chatmember mit brauchbarem Locator geografisch dar.
+
+- **Antennensektor und Verbindungslinie:** Die Karte zeigt den aktuellen eigenen QTF, den konfigurierten Antennen-Öffnungswinkel, das maximale QRB und die Verbindung zur ausgewählten Station.
+
+- **Maidenhead-Raster:** Ein an die Zoomstufe angepasstes Locator-Raster erleichtert die geografische Einordnung.
+
+- **Geländeprofil:** Für ausgewählte Stationen kann ein Höhenprofil über die Open-Meteo Elevation API berechnet werden. Die aktive Datenquelle verwendet Copernicus GLO-90 und höchstens 100 gleichmäßig verteilte Abfragepunkte.
+
+- **Geometrische Streckenanalyse:** Die Auswertung berücksichtigt Sichtlinie, Erdkrümmung mit `k = 4/3`, Radio- und Geländehorizont, erste Fresnel-Zone und eine grobe Hindernisabschätzung.
+
+- **Lokaler Karten-Proxy:** Leaflet wird mit der Anwendung ausgeliefert. Kartenkacheln werden über einen lokalen Proxy geladen, damit keine externe JavaScript-Bibliothek zur Laufzeit nachgeladen werden muss. Für die OpenStreetMap-Kacheln und die Online-Höhendaten ist weiterhin eine Internetverbindung erforderlich.
+
+### Geändert
+
+- **Begrenzte Nachrichtenspeicher:** Die globale Chatnachrichtenliste wird oberhalb von 30.000 Einträgen auf 25.000 verkleinert. Der getrennte DX-Cluster-Speicher wird oberhalb von 10.000 Einträgen auf 8.000 verkleinert.
+
+- **Bildschirmgerechte Startgröße:** Das Hauptfenster wird beim Start gegen den sichtbaren Bereich des primären Bildschirms geprüft und bei Bedarf verkleinert oder verschoben.
+
+- **Kompaktere Benutzeroberfläche:** Mehrere Bereiche wurden für kleinere Bildschirme und verstellbare Divider angepasst.
+
+### Einordnung der Kartenfunktion
+
+Die Stationskarte und AirScout können dieselbe Gegenstation betreffen, führen aber getrennte Berechnungen durch. Aircraft-Scatter-Flugzeuge werden nicht in das Geländeprofil eingerechnet.
+
+Im Quellcode vorhandene Klassen für Copernicus GLO-30, Offline-DEM-Import und weitere Terrain-Provider waren in v1.41 nicht Bestandteil der aktiv verwendeten Berechnungskette. Die tatsächlich verwendete Online-Höhenquelle ist Open-Meteo auf Basis von Copernicus GLO-90.
+
+---
+
+## v1.40 (2026-02-16)
+**Großes Feature-Release: Score-System, AP-Timeline, Win-Test, PSTRotator**
+
+**Neu:**
+- **Chatmember Score-System**: Jeder Chatmember erhält automatisch eine Prioritätsbewertung anhand von Antennenrichtung, Aktivitätszeit, Nachrichtenanzahl, aktiven Bändern, Frequenzen, Sked-Richtung und anderen Faktoren. Die Top-Kandidaten werden in einer eigenen Liste hervorgehoben.
+- **AP-Timeline**: Für jeden möglichen AP-Ankunftsminuten-Slot werden bis zu 4 hochbewertete Stationen angezeigt, die erreichbar wären. Bevorzugt werden APs mit dem höchsten Potenzial, nicht die schnellste Ankunft. Stationen, auf die die eigene Antenne nicht zeigt, werden transparent dargestellt.
+- **Win-Test-Unterstützung** (ab v1.31 als Beta, jetzt vollständig konfigurierbar): Log-Synchronisation, Frequenzauswertung und **Sked-Übergabe via UDP** vollständig integriert. In den Preferences aktivier-/deaktivierbar.
+- **PSTRotator-Interface** (ab v1.31 als Beta, jetzt vollständig konfigurierbar): Aktualisierung der Rotatorposition direkt aus KST4Contest. In den Preferences aktivier-/deaktivierbar.
+- **QSO-Sniffer**: Nachrichten von konfigurierbaren Rufzeichen-Listen werden automatisch in das PM-Fenster weitergeleitet.
+- **Band-Alert bei gearbeiteten Stationen**: Wenn eine Station geloggt wird, erscheint ein Hinweis, wenn diese Station ein weiteres Band aktiv hat, auf dem man selbst ebenfalls QRV ist.
+- **Sked-Erinnerungs-ALERT**: Pro Chatmember kann ein Sked-Alarm mit automatischen Nachrichten in konfigurierbaren Intervallen (2+1 / 5+2+1 / 10+5+2+1 Minuten vor dem Sked) eingerichtet werden, plus akustische und optische Benachrichtigung.
+- **Chat-Historie beim Start laden**: Beim Verbindungsaufbau wird die Serverhistorie geladen, um aktive Chatmember und letzte Nachrichten sofort sichtbar zu machen.
+- **Skedfail-Button**: Im FurtherInfo-Panel kann ein Sked-Misserfolg für einen Chatmember markiert werden, was dessen Score senkt.
+
+**Geändert:**
+- AP-Notizen in DX-Cluster-Spots integriert.
+- Scrolling der Chatmember-Tabelle folgt automatisch der aktuellen Nachrichtenauswahl.
+- Generic Auto-Antwort und QRG-Auto-Antwort senden max. einmal pro 45 Sekunden pro Rufzeichen (verhindert Spam-Schleifen).
+- Speicherbare Einstellungen erweitert: ServerDNS/Port, PSTRotator-Interface, Win-Test-Interface, Callsign-Sniffer, Dark-Mode-Standard.
+- Datum in der Chat-Tabelle entfernt (nur Uhrzeit verbleibt – spart Platz).
+
+**Behoben:**
+- Benutzerliste wird jetzt bei jedem Neu-Login automatisch sortiert.
+- Posonpill-Nachrichten beenden jetzt nur genau eine Client-Instanz (nicht alle und nicht wtKST).
+- wtKST: Absturz bei KST4Contest-Trennung behoben.
+- Mehrere Probleme mit Rufzeichen-Suffixen wie `/p`, `-2` etc. behoben.
+- `QTFDefault` wurde nicht korrekt gespeichert → behoben.
+- AirScout-Watchlist (ASWATCHLIST) wurde nicht korrekt aktualisiert → behoben.
+- Dark Mode: QRG-Felder wurden nicht vollständig angezeigt → behoben.
+- Versionsnummer-Anzeige korrigiert.
+
+---
+
+## v1.31 (2025-12-13)
+**Win-Test + PSTRotator Beta, QSO-Sniffer, DNS-Hotfix**
+
+**Neu:**
+- **Win-Test-Unterstützung** (Beta, noch nicht deaktivierbar): Log-Synchronisation und Frequenzauswertung.
+- **PSTRotator-Unterstützung** (Beta, noch nicht deaktivierbar).
+- **QSO-Sniffer**: Nachrichten von konfigurierbaren Rufzeichen werden ins PM-Fenster weitergeleitet.
+
+**Geändert:**
+- **DNS-Server geändert**: Von `www.on4kst.info` auf `www.on4kst.org` (Hotfix). Der DNS-Server ist ab sofort in den Preferences änderbar.
+
+**Behoben:**
+- Endlosschleife im Fehlerfall friert den Client ein → behoben.
+
+---
+
+## v1.266 (2025-10-03)
+**AirScout-Fix für Rufzeichen mit Suffix**
+
+**Behoben:**
+- AirScout-Interface funktionierte nicht, wenn das Login-Rufzeichen einen Suffix enthielt (z. B. `9A1W-2`). AirScout kann mit diesem Format nicht umgehen – es wird jetzt nur noch das Basis-Rufzeichen ohne Suffix an AirScout übergeben.
+
+*(Fehler gemeldet und getestet von 9A2HM / Kreso – herzlichen Dank!)*
+
+---
+
+## v1.265 (2025-09-28)
+**Richtungs-Buttons bleiben aktiviert eingefärbt**
+
+**Behoben:**
+- Richtungs-Buttons (N / NE / E usw.) behalten jetzt ihre Farbe, wenn sie aktiviert sind, sodass der Aktivierungsstatus auf einen Blick erkennbar ist.
+
+---
+
+## v1.264 (2025-08-02)
+**Simplelogfile: Rufzeichen-Erkennung verbessert**
+
+**Behoben:**
+- Rufzeichen wie `S53CC`, `S51A` usw. wurden in der SimpleLogFile-Auswertung nicht als gearbeitet markiert → Erkennungsmuster verbessert.
+
+*(Fehler gemeldet von Boris, S53CC – danke!)*
+
+---
+
+## v1.263 (2025-06-08)
+**AirScout-Kommunikation und Login-Name**
+
+**Geändert:**
+- AirScout-Kommunikation grundlegend überarbeitet: Nur noch Stationen mit QRB < max-QRB werden an AirScout gesendet.
+- Abfrage-Intervall von 12 Sekunden auf **60 Sekunden** erhöht.
+- Deutlich weniger Berechnungsaufwand und Nachrichtenverkehr → Stabileres AirScout-Tracking.
+- Name des AS-Clients und AS-Servers ist jetzt aus den Preferences konfigurierbar (war vorher hartcodiert auf „KST" / „AS").
+
+**Behoben:**
+- „Track in AirScout"-Button war sehr träge → durch neue Kommunikationslogik deutlich verbessert.
+- Name im Chat ist jetzt speicherbar (Fehler behoben).
+- Visuelle Korrekturen vor und nach dem Login.
+- Fehler behoben, der von 9A2HM (Kreso) gemeldet wurde.
+
+---
+
+## v1.262 (2025-05-21)
+**Freeze-Fix bei vorzeitiger Nachrichtenlieferung**
+
+**Behoben:**
+- ON4KST liefert manchmal Nachrichten, bevor der Login abgeschlossen ist. Das verursachte Fehler in der Nachrichtenverarbeitung → jetzt behoben.
+
+---
+
+## v1.26 (2025-05)
+**Multi-Channel-Login und Dark Mode**
+
+**Neu:**
+- **Dark Mode**: Umschaltbar über `Window → Use Dark Mode`.
+- **Multi-Channel-Login**: Gleichzeitiger Login in zwei Chat-Kategorien.
+- **Opposite Station Multi-Callsign Login-Tagging**: Unterstützung für Stationen mit mehreren Rufzeichen.
+
+**Geändert:**
+- Farbgebungs-Mechanismus überarbeitet: Farben können jetzt über CSS angepasst werden.
+
+**Behoben:**
+- Stationsmarkierung komplett überarbeitet und korrekt gestellt.
+
+---
+
+## v1.251 (2025-02)
+**Bugfix für UDP-Broadcast-Spot-Info**
+
+**Behoben:**
+- Problem beim Lesen von UDP-Broadcast-Spot-Informationen behoben (gemeldet von Steve Clements – danke!).
+- Stationsmarkierung (erneut verbessert).
+
+---
+
+## v1.25 (2025-02)
+**Wunschliste umgesetzt**
+
+**Neu:**
+- **Neuer Einstellungs-Tab: Messagehandling**
+  - Auto-Antwort auf eingehende Nachrichten konfigurierbar.
+  - Automatische Antwort mit eigener CQ-QRG, wenn jemand danach fragt.
+  - Konfigurierbarer Standard-Filter für das Userinfo-Fenster *(für Gianluca :-) )*.
+- **Farbige PM-Zeilen**: Neue Privatnachrichten erscheinen rot und faden alle 30 Sekunden über Gelb bis Weiß ab *(Idee von IU3OAR, Gianluca)*.
+
+**Behoben:**
+- Stationen mit Suffixen wie „-2" und „-70" wurden nicht als gearbeitet markiert → werden jetzt ignoriert, Station wird korrekt markiert.
+
+---
+
+## v1.24 (2024-11)
+**Wunschliste + DX-Cluster-Spots**
+
+**Neu:**
+- Button zum Öffnen des **QRZ.com-Profils** der ausgewählten Station.
+- Button zum Öffnen des **QRZ-CQ-Profils** der ausgewählten Station.
+- **DX-Cluster-Server-Integration**: Richtungs-Warnungen werden als Spots an das Logprogramm gesendet (wenn QRG bekannt).
+
+*(Zusätzlich wurden Farbgebungen der PM-Zeilen hinzugefügt – tnx Gianluca)*
+
+---
+
+## v1.23 (2024-10)
+**Integrierter DX-Cluster-Server**
+
+**Neu:**
+- KST4Contest enthält jetzt einen **integrierten DX-Cluster-Server**.
+- Generiert DX-Cluster-Spots und sendet sie an das Logprogramm, wenn eine Richtungs-Warnung ausgelöst und eine QRG bekannt ist.
+- Spotter-Rufzeichen muss sich vom Contest-Rufzeichen unterscheiden (für korrekte Filterung im Logprogramm).
+
+*(Idee von OM0AAO, Viliam Petrik – danke!)*
+
+---
+
+## v1.22 (2024-05)
+**Usability-Verbesserungen und AirScout-Button-Fix**
+
+**Neu:**
+- Neue Variablen (tnx OM0AAO, Viliam Petrik):
+  - `MYLOCATORSHORT`
+  - `MYQRGSHORT`
+  - `QRZNAME`
+
+**Geändert:**
+- Sendfeld-Fokus: Nach Klick auf Rufzeichen in der Benutzerliste erhält das Sendfeld sofort den Fokus – kein Doppelklick notwendig *(tnx Gianluca)*.
+
+**Behoben:**
+- Worked-Station-Filter ist jetzt live-aktiv: Gearbeitete Stationen verschwinden sofort nach Aktivierung des Filters *(tnx Gianluca)*.
+- QRB-Sortierung war lexikografisch → jetzt numerisch *(tnx Alessandro Murador)*.
+- AirScout-„Show Path"-Button: Klick maximiert AirScout und zeigt den Pfad korrekt an.
+
+---
+
+## v1.21 (2024-04)
+**Usability-Verbesserungen**
+
+**Geändert:**
+- Fenstergrößen und Divider-Positionen werden beim Klick auf „Save Settings" in der Konfigurationsdatei gespeichert und beim Start wiederhergestellt.
+- Filter-Bereich als Flowpane → bessere Darstellung auf kleineren Bildschirmen.
+
+---
+
+## v1.2 (2024-04)
+**Bandselektion und NOT-QRV-Tags**
+
+**Neu:**
+- **Bandselektion**: In den Preferences auswählbar, welche Bänder aktiv sind. Nur für gewählte Bänder erscheinen Buttons und Felder in der UI. Speichern und Neustart erforderlich.
+- **NOT-QRV-Tags pro Station und Band**: Stationen können für jedes Band als „nicht QRV" markiert werden. Kombinierbar mit dem Userlist-Filter.
+- **QTF-Pfeil**: Der „Show path in AS"-Button zeigt jetzt einen Pfeil mit dem QTF der ausgewählten Station an.
+
+---
+
+## Frühere Versionen
+
+### v1.1
+Erste öffentlich veröffentlichte Version. Grundfunktionen:
+- Worked-Markierung via Simplelogfile und UDP
+- Sked-Richtungs-Hervorhebung
+- QRG-Erkennung
+- Text-Snippets und Shortcuts
+- AirScout-Interface (erste Version)
+- Intervall-Beacon
+- PM-Abfang für öffentliche Nachrichten mit eigenem Rufzeichen
+- Update-Hinweis-Dienst
+
+---
+
+## Geplante Features
+
+- ~~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

@@ -0,0 +1,275 @@
+# Integrierter DX-Cluster-Server
+
+> 🇬🇧 [English version](en-DX-Cluster-Server) | 🇩🇪 Du liest gerade die deutsche Version
+
+Seit Version 1.23 enthält KST4Contest einen lokalen DX-Cluster-Server. Er übergibt erkannte Richtungsgelegenheiten und die dazugehörige Frequenz an den DX-Cluster-Client eines Logprogramms.
+
+Die Idee dazu stammt von OM0AAO, Viliam Petrik. Vielen Dank!
+
+---
+
+## Warum überhaupt ein eigener DX-Cluster-Server?
+
+Eine interessante Frequenz im Chat zu erkennen ist nur der erste Schritt. Im Contest muss diese Information dort ankommen, wo sie unmittelbar verwendet werden kann: im Logprogramm und dessen Bandmap.
+
+KST4Contest verbindet deshalb zwei bereits vorhandene Informationen:
+
+1. Aus einer gerichteten Chat-Nachricht lässt sich abschätzen, in welche Richtung die sendende Station ihre Antenne wahrscheinlich ausgerichtet hat.
+2. Aus derselben oder einer vorherigen Nachricht kann eine Frequenz der Station bekannt sein.
+
+Treffen beide Informationen zusammen, erzeugt KST4Contest einen lokalen DX-Cluster-Spot. Der Logger kann diesen Spot in seiner Bandmap anzeigen und – abhängig von seiner eigenen Konfiguration – den Transceiver nach einem Klick auf die entsprechende Frequenz einstellen.
+
+Im Klartext: Die Information muss nicht erst im Chat gefunden, gelesen, gemerkt und anschließend erneut in den Logger eingetragen werden. Genau diese kleinen Unterbrechungen kosten im Contest überraschend viel Aufmerksamkeit.
+
+---
+
+## 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.
+
+Dafür werden zwei Richtungen verglichen:
+
+- die Richtung von Station A zu Station B,
+- die Richtung von Station A zur eigenen Station.
+
+Der in den Station Settings konfigurierte Antennen-Öffnungswinkel ist der vollständige Winkel. Für die Prüfung wird jeweils die Hälfte links und rechts der Richtung A → B angesetzt. Bei `70°` sind das somit `±35°`.
+
+Da ON4KST keine Antennendaten der fremden Station überträgt, verwendet KST4Contest den Öffnungswinkel der eigenen Antenne zugleich als Näherung für Station A. Das ist keine Messung der tatsächlichen Antennenrichtung, sondern eine bewusst einfache geometrische Annahme.
+
+Ein DX-Cluster-Spot wird nur erzeugt, wenn alle folgenden Bedingungen erfüllt sind:
+
+1. Eine gerichtete Nachricht wurde zwischen zwei anderen Stationen erkannt.
+2. Für Absender und Empfänger sind gültige Locator bekannt.
+3. Der Absender liegt innerhalb des konfigurierten maximalen QRB zur eigenen Station.
+4. Die eigene Station liegt aus Sicht des Absenders innerhalb des angenommenen Antennenkorridors.
+5. Für den Absender ist eine verwertbare Frequenz bekannt oder in der aktuellen Nachricht erkannt worden.
+6. Der lokale DX-Cluster-Server ist aktiviert.
+
+Treffen die Bedingungen zu, wird der Spot unmittelbar beim Verarbeiten der Nachricht erzeugt. Die parallel angezeigte grüne Richtungsmarkierung bleibt dagegen fünf Minuten sichtbar und kann durch spätere Nachrichten verlängert oder vorzeitig entfernt werden.
+
+Das Verfahren berücksichtigt weder Gelände noch aktuelle Ausbreitungsbedingungen und beweist keine tatsächliche Antennenstellung. Es erkennt eine plausible Gelegenheit. Die ausführliche Herleitung und ein Zahlenbeispiel stehen unter [Richtungsgelegenheiten aus gerichteten Nachrichten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
+
+---
+
+## 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.
+
+Vollständige Frequenzen bestimmen ihr Band direkt:
+
+```text
+144.205
+432,088
+1296.338
+10368.100
+```
+
+Relative Angaben enthalten dagegen nur den Frequenzanteil innerhalb eines Bandes:
+
+```text
+.205
+,205
+qrg 205
+freq is 205
+on 205
+205 MHz
+```
+
+Eine nackte dreistellige Zahl wie `205` wird ohne Frequenzkontext nicht ausgewertet. Dasselbe gilt für `599`, `144` oder Formulierungen wie `worked 210 stations`. So verhindert KST4Contest, dass Signalrapporte, Bandnamen oder Zählwerte als scheinbar plausible QRG gespeichert und später an den Logger weitergegeben werden.
+
+Bei einer relativen QRG wird das Band in dieser Reihenfolge bestimmt:
+
+1. KST4Contest prüft, ob für denselben Absender innerhalb der letzten 30 Minuten bereits ein passender Bandkontext bekannt wurde.
+2. Sind mehrere aktuelle Bänder bekannt, wird der zuletzt aktualisierte plausible Kontext verwendet.
+3. Erst wenn kein geeigneter Stationskontext vorhanden ist, verwendet KST4Contest das unter **Fallback band for relative QRG detection** ausgewählte Band.
+
+Beispiel:
+
+```text
+Globales Fallback: 144 MHz
+Letzte vollständige QRG der Station: 432.088 MHz
+Neue Chat-Angabe derselben Station: .100
+Erkannte QRG: 432.100 MHz
+DX-Cluster-Frequenz: 432100.0 kHz
+```
+
+Ohne den aktuellen 432-MHz-Kontext würde dieselbe Angabe mit dem globalen Fallback zu `144.100 MHz` ergänzt.
+
+Die QRG-Erkennung läuft vor der Richtungs- und Spotprüfung. Nennt eine Station ihre Frequenz erstmals in der gerichteten Nachricht, die zugleich eine Richtungsgelegenheit auslöst, kann bereits der daraus erzeugte Spot diese Frequenz enthalten. War zuvor eine andere QRG der Station bekannt, wird sie durch die neu erkannte Angabe aktualisiert.
+
+Das Fallback-Band ist eine globale Einstellung der QRG-Erkennung. Seine Wirkung ist nicht auf den DX-Cluster beschränkt. Konfiguration, unterstützte Bänder und weitere Folgen sind unter [Fallback-Band für relative QRG-Erkennung](de-Konfiguration#fallback-band-für-relative-qrg-erkennung) beschrieben.
+
+---
+
+## Einrichtung in KST4Contest
+
+Öffne den Reiter **Notification** in den Preferences.
+
+![Benachrichtigungen und lokaler DX-Cluster-Server](client_settings_window_notification.png)
+
+Konfiguriere anschließend:
+
+1. **Enable the local DX Cluster server …** aktivieren.
+2. Einen freien **TCP port** eintragen. Standard ist `8000`.
+3. Unter **Fallback band for relative QRG detection** das passende Band auswählen.
+4. Ein **Spotter callsign** festlegen.
+
+Für das Spotter-Rufzeichen sollte nach Möglichkeit ein anderes Rufzeichen als das Contest-Rufzeichen verwendet werden. Einige Logger filtern Spots, die scheinbar von der eigenen Station stammen. Das Ergebnis wäre technisch korrekt erzeugt, aber in der Bandmap trotzdem unsichtbar – eine besonders unproduktive Art von Erfolg.
+
+Änderungen am Aktivierungsstatus und am TCP-Port werden während einer laufenden Chat-Verbindung sofort angewendet. Bei einem Portwechsel werden vorhandene DX-Cluster-Verbindungen getrennt und müssen vom Logger neu aufgebaut werden.
+
+Die Einstellungen werden erst mit **Save Settings** dauerhaft in der `preferences.xml` gespeichert.
+
+---
+
+## Einrichtung im Logprogramm
+
+Das Logprogramm wird als DX-Cluster-Client mit KST4Contest verbunden.
+
+| Einstellung | KST4Contest und Logger auf demselben Computer | Logger auf einem anderen Computer |
+|---|---|---|
+| Host | `127.0.0.1` | IP-Adresse des KST4Contest-Computers |
+| Port | In KST4Contest konfigurierter TCP-Port | In KST4Contest konfigurierter TCP-Port |
+| Login | Beliebiges Rufzeichen, falls der Logger eines verlangt | Beliebiges Rufzeichen, falls der Logger eines verlangt |
+| Passwort | Nicht erforderlich | Nicht erforderlich |
+
+KST4Contest wertet den vom Logger gesendeten Login nicht zur Authentifizierung aus. Die Verbindung ist für ein lokales oder vertrauenswürdiges Stationsnetz vorgesehen.
+
+Wenn der Logger auf einem anderen Computer läuft, muss dessen Verbindung durch die lokale Firewall des KST4Contest-Computers zugelassen werden. Der Port sollte nicht ohne weiteren Schutz aus dem Internet erreichbar sein.
+
+Mehrere DX-Cluster-Clients können gleichzeitig verbunden werden. Ein erzeugter Spot wird an alle aktuell verbundenen Clients gesendet.
+
+---
+
+## Verbindung testen
+
+Die Schaltfläche **Send test spot** erzeugt folgenden Testeintrag:
+
+```text
+Spotted callsign: DO5AMF
+Comment: DXC test: You donated $100!
+Frequency: .300 des konfigurierten Fallback-Bandes
+```
+
+Bei einem Fallback-Band von `144 MHz` erscheint der Spot daher auf ungefähr `144.300 MHz`.
+
+Der Kommentar ist ein bewusst beibehaltenes Easteregg. Er dient ausschließlich dazu, den Testspot im Logprogramm eindeutig wiederzuerkennen. Eine tatsächliche Spende oder sonstige externe Aktion wird dadurch selbstverständlich nicht ausgelöst.
+
+Vor dem Test müssen drei Bedingungen erfüllt sein:
+
+1. KST4Contest ist mit dem ON4KST-Chat verbunden.
+2. Der lokale DX-Cluster-Server ist aktiviert.
+3. Der DX-Cluster-Client des Logprogramms ist mit KST4Contest verbunden.
+
+Fehlt die Client-Verbindung, zeigt KST4Contest eine entsprechende Meldung an. Ein erfolgreich ausgeführter Test bedeutet damit tatsächlich, dass mindestens ein Client den Spot erhalten hat.
+
+---
+
+## Inhalt eines erzeugten Spots
+
+Ein Spot enthält:
+
+- das konfigurierte Spotter-Rufzeichen,
+- die normalisierte Frequenz,
+- das vollständige sichtbare Rufzeichen der erkannten oder ausgewählten Station,
+- den Locator,
+- die aktuelle UTC-Zeit.
+
+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%
+```
+
+---
+
+## Wenn kein Spot erscheint
+
+### Der Testspot kommt nicht im Logger an
+
+Prüfe:
+
+- Ist KST4Contest mit dem Chat verbunden?
+- Ist der lokale DX-Cluster-Server aktiviert?
+- Verwendet der Logger denselben TCP-Port?
+- Verwendet der Logger bei lokalem Betrieb `127.0.0.1`?
+- Blockiert eine Firewall die Verbindung?
+- Ist im Logger das DX-Cluster-Fenster beziehungsweise die Bandmap aktiviert?
+
+### 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:
+
+- kein gerichteter Nachrichtenaustausch,
+- fehlender Locator,
+- Station außerhalb des maximalen QRB,
+- Richtung außerhalb des konfigurierten Öffnungswinkels,
+- keine erkannte Frequenz.
+
+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.
+
+---
+
+## Getestete Logprogramme
+
+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-Home.md

@@ -0,0 +1,129 @@
+# KST4Contest – Handbuch
+
+> [English version](en-Home) | Du liest gerade die deutsche Version
+
+KST4Contest ist ein Desktop-Client für den [ON4KST-Chat](https://www.on4kst.org/chat/login.php), der für den Contest-Betrieb auf den VHF-, UHF- und SHF-Bändern entwickelt wurde. Er verbindet Chat, Stationsauswahl, Sked-Planung, Aircraft-Scatter-Daten und die Anbindung an weitere Programme in einer gemeinsamen Arbeitsoberfläche.
+
+Entwickelt wird KST4Contest von **DO5AMF (Marc Fröhlich)**, Operator bei DM5M und (seit Mai 2025) **DN9APW (Philipp Wagner)**. Der Quellcode ist öffentlich auf [GitHub](https://github.com/praktimarc/kst4contest) verfügbar.
+
+---
+
+## Wozu braucht man einen eigenen ON4KST-Client?
+
+Der ON4KST-Chat liefert während eines Contests eine große Menge an Informationen: aktive Stationen, Locator, Frequenzen, Sked-Anfragen und Hinweise auf aktuelle Aktivität. Das eigentliche Problem besteht nicht darin, diese Daten zu sehen. Man muss daraus rechtzeitig die nächste sinnvolle Verbindung ableiten.
+
+KST4Contest wertet die verfügbaren Informationen aus, ordnet sie und stellt sie in einem contestgerechten Arbeitsablauf dar. Dabei werden unter anderem Antennenrichtung, Entfernung, bekannte Bänder und Frequenzen, bereits gearbeitete Stationen, Chat-Aktivität und Aircraft-Scatter-Zeiten berücksichtigt.
+
+Das Programm entscheidet jedoch nicht, welches QSO tatsächlich möglich ist. Der Prioritätsscore, die AP-Timeline und die verschiedenen Hervorhebungen sind Entscheidungshilfen. Die endgültige Beurteilung bleibt beim Operator – schon deshalb, weil auch ein recht überzeugender Computerbildschirm noch keine Funkverbindung herstellt.
+
+---
+
+## Was KST4Contest im Contest unterstützt
+
+- **Chat beobachten und einordnen:** KST4Contest kann zwei ON4KST-Chat-Kategorien gleichzeitig darstellen. Nachrichten, Frequenzangaben und bekannte Bandaktivitäten werden den jeweiligen Stationen zugeordnet.
+
+- **Relevante Stationen herausfiltern:** Richtungs-, Entfernungs-, Worked- und NOT-QRV-Filter reduzieren die Benutzerliste auf die Stationen, die für den aktuellen Betriebszustand tatsächlich interessant sind.
+
+- **Kandidaten priorisieren:** Das Score-System bewertet aktive Chatmember anhand mehrerer bekannter Kriterien. Die derzeit relevantesten Kandidaten erscheinen zusätzlich in einer eigenen Prioritätsliste.
+
+- **Skeds vorbereiten und im Blick behalten:** Sked-Erinnerungen, automatische Vorwarnungen und die AP-Timeline helfen dabei, vereinbarte Verbindungen nicht zwischen Chat, Log und laufendem CQ-Betrieb zu verlieren.
+
+- **Aircraft Scatter einbeziehen:** Über die AirScout-Schnittstelle werden geeignete Flugzeuge und erwartete Reflexionszeiten in die Stationsbewertung und Zeitplanung übernommen.
+
+- **Log und Funkstation anbinden:** KST4Contest synchronisiert gearbeitete Stationen und Frequenzinformationen mit unterstützten Logprogrammen. Zusätzlich stehen Schnittstellen zu Win-Test, PSTRotator und ein integrierter DX-Cluster-Server zur Verfügung.
+
+- **Stationen und Funkwege darstellen:** Die Stationskarte zeigt aktive Chatmember, Locator-Felder, Antennenrichtungen und den Weg zur ausgewählten Station. Für ausgewählte Verbindungen kann außerdem ein Geländeprofil berechnet werden.
+
+Die Funktionen greifen ineinander. Eine erkannte Frequenz kann beispielsweise einem aktiven Band zugeordnet werden, der Worked-Status stammt aus dem Log, Aircraft-Scatter-Daten ergänzen die zeitliche Bewertung und der daraus berechnete Score beeinflusst die Prioritätsliste. Fehlende oder veraltete Eingangsdaten können deshalb auch das Ergebnis beeinflussen.
+
+---
+
+## Voraussetzungen
+
+Für die Anmeldung ist ein registrierter ON4KST-Account erforderlich. Registrierung und Login sind über die [offizielle ON4KST-Anmeldeseite](https://www.on4kst.org/chat/login.php) erreichbar.
+
+Die offizielle Sprache im ON4KST-Chat ist Englisch. Das gilt auch für Nachrichten an Stationen aus dem eigenen Land. Übliche Amateurfunk-Abkürzungen wie `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` oder `73` sind dabei normal und meistens erheblich schneller als ausformulierte Prosa.
+
+Download, unterstützte Betriebssysteme und Installationswege sind im Kapitel [Installation](de-Installation) beschrieben.
+
+---
+
+## Versionsstand dieses Handbuchs
+
+Dieses Handbuch unterscheidet zwischen der veröffentlichten Stable-Version und dem aktuellen Entwicklungsstand.
+
+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)
+- [Versionsgeschichte und aktueller Nightly-Stand](de-Changelog)
+
+Für einen Contest ist grundsätzlich die Stable-Version zu empfehlen. Nightly-Builds enthalten neuere Korrekturen und Funktionen, können sich aber zwischen zwei Builds verändern. Sie sind sinnvoll, wenn eine konkrete Änderung getestet werden soll. Der erste Versuch zehn Minuten vor Contestbeginn ist dagegen meistens eine recht effiziente Methode, gleichzeitig Software und Operator zu testen.
+
+---
+
+## Schnellnavigation
+
+| Seite | Inhalt |
+|---|---|
+| [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 |
+| [Funktionen](de-Funktionen) | Arbeitsweise, Herleitung und Grenzen der einzelnen Funktionen |
+| [Makros und Variablen](de-Makros-und-Variablen) | Wiederverwendbare Texte, Shortcuts und automatisch ersetzte Werte |
+| [Benutzeroberfläche](de-Benutzeroberflaeche) | Aufbau der Oberfläche und Bedienung im Contest |
+| [Changelog](de-Changelog) | Releases, Nightly-Änderungen und behobene Fehler |
+
+---
+
+## Kontakt und Support
+
+- **Download:** [Stable, Beta und Nightly](https://kst4contest.hamradioonline.de/download/)
+- **Quellcode:** [praktimarc/kst4contest](https://github.com/praktimarc/kst4contest)
+- **Fehler und Funktionswünsche:** [GitHub Issues](https://github.com/praktimarc/kst4contest/issues)
+- **E-Mail:** praktimarc+kst4contest@gmail.com  
+  Bitte nur für Themen verwenden, die KST4Contest betreffen.
+
+### Einen Fehler melden
+
+Ein Fehler lässt sich wesentlich schneller nachvollziehen, wenn die Meldung mindestens folgende Angaben enthält:
+
+1. verwendete KST4Contest-Version,
+2. Betriebssystem und Installationsart,
+3. genaue Schritte bis zum Fehler,
+4. erwartetes und tatsächlich beobachtetes Verhalten,
+5. gegebenenfalls einen Screenshot,
+6. die Fehler-Logdatei.
+
+Die Fehler-Logdatei wird hier gespeichert:
+
+| Betriebssystem | Pfad |
+|---|---|
+| Linux / macOS | `~/.praktiKST/kst4contest-errors.log` |
+| Windows | `C:\Users\<Benutzername>\.praktiKST\kst4contest-errors.log` |
+
+Vor dem Hochladen sollte die Datei kurz geprüft werden. Ein Fehlerprotokoll enthält überwiegend technische Informationen, kann abhängig vom Fehler aber beispielsweise lokale Dateipfade oder weitere Kontextdaten enthalten.
+
+In Datei- und Verzeichnisnamen wird teilweise noch der technische Name `praktiKST` verwendet. Gemeint ist dasselbe Programm.
+
+---
+
+## Danksagungen
+
+KST4Contest wurde durch Rückmeldungen aus dem praktischen Contest-Betrieb wesentlich verbessert. Viele Funktionen entstanden nicht aus einer theoretischen Anforderungsliste, sondern aus Situationen, in denen während eines Contests eine Information fehlte, zu spät sichtbar wurde oder schlicht an der falschen Stelle stand.
+
+Besonderer Dank gilt:
+
+- Gianluca Costantino (IU3OAR),
+- Alessandro Murador (IZ3VTH),
+- Reczetár István (HA1FV),
+- Viliam Petrik (OM0AAO) für die Idee zum integrierten DX-Cluster,
+- Konrad Neitzel (DC9DJ) für Unterstützung bei der Projektstruktur,
+- Andreas (DO5ALF), Webmaster von funkerportal.de,
+- Franz van Velzen (PE0WGA) für Tests sowie
+- DN9APW (Philipp Wagner), der seit Mai 2026 an der Entwicklung und den CI/CD-Pipelines mitarbeitet.
+
+Ebenso wichtig sind die Fehlermeldungen, Tests und konkreten Betriebserfahrungen aller weiteren Nutzer. Eine genaue Beschreibung eines reproduzierbaren Problems hilft dem Projekt meistens mehr als ein allgemeines „läuft gut“ – auch wenn Letzteres natürlich angenehmer zu lesen ist.

github_docs/de-Installation.md

@@ -0,0 +1,437 @@
+# Installation
+
+> 🇬🇧 [English version](en-Installation) | 🇩🇪 Du liest gerade die deutsche Version
+
+KST4Contest wird für Windows, Linux und macOS als fertiges Programmpaket bereitgestellt. Für die offiziellen Release-Pakete muss Java nicht separat installiert werden: Die benötigte Java-Laufzeitumgebung ist bereits enthalten.
+
+Benötigt werden damit im Wesentlichen ein unterstütztes Betriebssystem, eine Internetverbindung und ein ON4KST-Account. Das klingt zunächst überschaubar – und ist es normalerweise auch.
+
+## Voraussetzungen
+
+### ON4KST-Account
+
+KST4Contest ist ein eigenständiger Client für den ON4KST-Chat, ersetzt aber nicht den dazugehörigen Benutzeraccount.
+
+Falls noch kein Account vorhanden ist, kann er über die offizielle ON4KST-Seite angelegt werden:
+
+- [ON4KST-Anmeldung und Registrierung](https://www.on4kst.org/chat/login.php)
+
+ON4KST gibt Englisch als gemeinsame Sprache im Chat vor. Das gilt auch dann, wenn beide beteiligten Stationen dieselbe Muttersprache sprechen. Im Contestbetrieb werden häufig die üblichen Amateurfunk-Abkürzungen wie `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` oder `73` verwendet.
+
+Die eigentliche Bedienung des Chats und das Senden persönlicher Nachrichten werden im Kapitel zur Benutzeroberfläche beschrieben. Für die Installation ist zunächst nur wichtig, dass der Account funktioniert.
+
+### Bildschirmgröße
+
+Eine nutzbare Bildschirmfläche von ungefähr **1200 × 720 Pixeln** oder mehr wird empfohlen.
+
+KST4Contest passt das Hauptfenster automatisch an die verfügbare Fläche des primären Bildschirms an. Das Programm kann deshalb auch auf kleineren Bildschirmen gestartet werden. Weniger Platz bleibt allerdings weniger Platz: In diesem Fall können nicht alle Tabellen, Filter und Zusatzinformationen gleichzeitig in sinnvoller Größe dargestellt werden.
+
+### Java
+
+Für die fertigen Pakete aus den [GitHub Releases](https://github.com/praktimarc/kst4contest/releases/latest) ist keine separate Java-Installation erforderlich. Die benötigte Laufzeitumgebung wird zusammen mit KST4Contest ausgeliefert.
+
+Eine Java-Entwicklungsumgebung wird nur benötigt, wenn KST4Contest selbst aus dem Quellcode gebaut werden soll. Bei den AUR-Paketen `kst4contest` und `kst4contest-git` werden Java 21 und Maven als Build-Abhängigkeiten durch den Paketmanager berücksichtigt.
+
+---
+
+## Stable, Beta oder Nightly?
+
+KST4Contest wird in drei Entwicklungsständen bereitgestellt:
+
+| Kanal | Geeignet für | Einordnung |
+|---|---|---|
+| **Stable** | Normaler Contestbetrieb | Veröffentlichte und für den regulären Einsatz vorgesehene Version |
+| **Beta** | Gezielte Tests vor einem Stable-Release | Vorabversion mit weitgehend festgelegtem Funktionsumfang |
+| **Nightly** | Frühe Tests neuer Funktionen | Aktueller Entwicklungsstand aus dem `main`-Branch |
+
+Für den normalen Einsatz wird die **Stable-Version** empfohlen.
+
+Beta- und Nightly-Versionen können Funktionen enthalten, die im Stable-Release noch nicht verfügbar sind. Sie können aber ebenso unfertige Bedienabläufe, geänderte Einstellungen oder neue Fehler enthalten. Das ist kein ungewöhnlicher Defekt im Veröffentlichungsverfahren, sondern der Zweck eines Entwicklungskanals.
+
+Wenn in diesem Manual eine Funktion ausdrücklich mit **Nightly** gekennzeichnet ist, gehört sie noch nicht zwingend zum aktuellen Stable-Release.
+
+---
+
+## Download
+
+Die aktuelle Stable-Version ist hier verfügbar:
+
+- [Aktuelles KST4Contest-Release](https://github.com/praktimarc/kst4contest/releases/latest)
+- [Alle veröffentlichten Versionen](https://github.com/praktimarc/kst4contest/releases)
+
+Die Release-Seite enthält die Programmpakete sowie die deutschen und englischen PDF-Handbücher.
+
+### Welches Paket wird benötigt?
+
+| Betriebssystem | Paket | Typischer Dateiname |
+|---|---|---|
+| Windows x64 | ZIP-Paket | `praktiKST-v<Version>-windows-x64.zip` |
+| Linux x86_64 | AppImage | `KST4Contest-v<Version>-linux-x86_64.AppImage` |
+| Debian/Ubuntu amd64 | DEB-Paket | `KST4Contest-v<Version>-debian-amd64.deb` |
+| Fedora/RPM x86_64 | RPM-Paket | `KST4Contest-v<Version>-fedora-x86_64.rpm` |
+| Arch Linux x86_64 | Arch-Paket | `KST4Contest-v<Version>-archlinux-x86_64.pkg.tar.zst` |
+| Linux mit Flatpak | Flatpak-Referenz | `de.x08.KST4Contest.flatpakref` |
+| macOS Apple Silicon | DMG für ARM64 | `KST4Contest-v<Version>-macos-arm64.dmg` |
+| macOS Intel | DMG für x86_64 | `KST4Contest-v<Version>-macos-x86_64.dmg` |
+
+Lade Programmpakete nur aus den offiziellen GitHub Releases, dem KST4Contest-Flatpak-Repository oder den verlinkten AUR-Paketen herunter. Dateien aus anderen Quellen können anders gebaut, veraltet oder verändert worden sein.
+
+---
+
+## Installation unter Windows
+
+KST4Contest wird unter Windows als ZIP-Paket bereitgestellt. Ein klassischer Installer ist nicht erforderlich.
+
+1. Lade `praktiKST-v<Version>-windows-x64.zip` aus dem aktuellen Release herunter.
+2. Entpacke die ZIP-Datei vollständig in einen eigenen Ordner.
+3. Öffne den entpackten Ordner.
+4. Starte `praktiKST.exe`.
+
+Starte das Programm nicht direkt aus der noch komprimierten ZIP-Datei. KST4Contest besteht aus mehreren Dateien und einer mitgelieferten Laufzeitumgebung. Windows kann diese Struktur nur zuverlässig verwenden, wenn das Archiv vorher vollständig entpackt wurde.
+
+Die Programmeinstellungen befinden sich nicht im entpackten Programmordner, sondern im Benutzerverzeichnis:
+
+```text
+%USERPROFILE%\.praktiKST\preferences.xml
+```
+
+Dadurch können neue Programmversionen in einen anderen Ordner entpackt werden, ohne dass die vorhandenen Einstellungen verloren gehen.
+
+---
+
+## Installation unter Linux
+
+Unter Linux stehen mehrere Paketformate zur Verfügung. Welches davon sinnvoll ist, hängt weniger von KST4Contest als von der verwendeten Distribution und der gewünschten Update-Methode ab.
+
+| Installationsart | Sinnvoll, wenn … |
+|---|---|
+| **Flatpak** | Updates zentral verwaltet werden sollen und Flatpak bereits verwendet wird |
+| **AppImage** | KST4Contest ohne Installation als einzelne portable Datei gestartet werden soll |
+| **DEB/RPM** | die Paketverwaltung der Distribution verwendet werden soll |
+| **Arch-Paket/AUR** | Arch Linux, Manjaro oder EndeavourOS eingesetzt wird |
+
+### Flatpak
+
+Flatpak ist für die meisten Linux-Anwender der einfachste Weg, KST4Contest installiert und aktualisierbar zu halten. Das KST4Contest-Repository ist GPG-signiert und enthält die Kanäle Stable, Beta und Nightly.
+
+#### Stable über die Release-Datei installieren
+
+Lade `de.x08.KST4Contest.flatpakref` aus dem aktuellen Release herunter und öffne die Datei mit der Softwareverwaltung der verwendeten Desktop-Umgebung.
+
+Alternativ kann sie im Terminal installiert werden:
+
+```bash
+flatpak install ./de.x08.KST4Contest.flatpakref
+```
+
+#### KST4Contest-Repository hinzufügen
+
+Das Repository muss nur einmal hinzugefügt werden:
+
+```bash
+flatpak remote-add --if-not-exists kst4contest \
+https://praktimarc.github.io/kst4contest/kst4contest.flatpakrepo
+```
+
+Anschließend kann die Stable-Version installiert werden:
+
+```bash
+flatpak install kst4contest de.x08.KST4Contest//stable
+```
+
+#### Beta installieren
+
+```bash
+flatpak install kst4contest de.x08.KST4Contest//beta
+```
+
+#### Nightly installieren
+
+```bash
+flatpak install kst4contest de.x08.KST4Contest//nightly
+```
+
+KST4Contest verwendet für alle drei Kanäle dieselbe App-ID. Eine parallele Installation mehrerer KST4Contest-Kanäle ist deshalb nicht vorgesehen.
+
+Zum Wechsel von Stable auf Nightly beispielsweise:
+
+```bash
+flatpak uninstall de.x08.KST4Contest//stable
+flatpak install kst4contest de.x08.KST4Contest//nightly
+```
+
+Die persönlichen Einstellungen im Verzeichnis `~/.praktiKST` werden dabei nicht automatisch gelöscht.
+
+Installierte Flatpak-Anwendungen können mit folgendem Befehl aktualisiert werden:
+
+```bash
+flatpak update de.x08.KST4Contest
+```
+
+Je nach Desktop-Umgebung kann die grafische Softwareverwaltung verfügbare Flatpak-Updates ebenfalls anzeigen oder automatisch installieren. Der Befehl `flatpak update` selbst führt das Update aus; er verspricht nicht, irgendwann von allein vorbeizukommen.
+
+### AppImage
+
+Das AppImage benötigt keine klassische Installation.
+
+1. Lade `KST4Contest-v<Version>-linux-x86_64.AppImage` herunter.
+2. Öffne ein Terminal im Download-Verzeichnis.
+3. Mache die Datei ausführbar:
+
+```bash
+chmod +x KST4Contest-v<Version>-linux-x86_64.AppImage
+```
+
+4. Starte KST4Contest:
+
+```bash
+./KST4Contest-v<Version>-linux-x86_64.AppImage
+```
+
+Das AppImage kann anschließend an einen anderen Ort verschoben werden, beispielsweise nach `~/Applications`.
+
+### Debian und Ubuntu
+
+Installiere das DEB-Paket mit:
+
+```bash
+sudo apt install ./KST4Contest-v<Version>-debian-amd64.deb
+```
+
+Alternativ kann die Datei in einer grafischen Paketverwaltung geöffnet werden.
+
+### Fedora und kompatible RPM-Systeme
+
+Installiere das RPM-Paket mit:
+
+```bash
+sudo dnf install ./KST4Contest-v<Version>-fedora-x86_64.rpm
+```
+
+### Arch Linux: fertiges Release-Paket
+
+Das aus dem GitHub Release heruntergeladene Arch-Paket kann direkt installiert werden:
+
+```bash
+sudo pacman -U KST4Contest-v<Version>-archlinux-x86_64.pkg.tar.zst
+```
+
+### Arch Linux: Installation über den AUR
+
+Im AUR stehen drei Varianten bereit:
+
+| Paket | Inhalt |
+|---|---|
+| [`kst4contest-bin`](https://aur.archlinux.org/packages/kst4contest-bin) | Vorgefertigtes Paket des aktuellen Stable-Releases |
+| [`kst4contest`](https://aur.archlinux.org/packages/kst4contest) | Stable-Release, das lokal aus dem Quellcode gebaut wird |
+| [`kst4contest-git`](https://aur.archlinux.org/packages/kst4contest-git) | Aktueller Entwicklungsstand aus dem `main`-Branch |
+
+Für die meisten Anwender ist `kst4contest-bin` die naheliegende Variante:
+
+```bash
+yay -S kst4contest-bin
+```
+
+Stable aus dem Quellcode bauen:
+
+```bash
+yay -S kst4contest
+```
+
+Aktuellen Entwicklungsstand bauen:
+
+```bash
+yay -S kst4contest-git
+```
+
+Die drei Pakete stellen dieselbe Anwendung bereit und sind deshalb als gegenseitige Konflikte definiert. Installiere nur eine Variante gleichzeitig.
+
+AUR-Updates werden berücksichtigt, wenn der verwendete AUR-Helper nach Paketaktualisierungen sucht, beispielsweise mit:
+
+```bash
+yay -Syu
+```
+
+Sie erfolgen nicht allein deshalb automatisch, weil das Paket aus dem AUR stammt.
+
+---
+
+## Installation unter macOS
+
+> **Best-Effort-Support:** Die macOS-Pakete werden zusammen mit den übrigen Releases gebaut, aber nicht in demselben Umfang getestet wie die Windows- und Linux-Versionen. Rückmeldungen sind willkommen; eine vollständig geprüfte Unterstützung aller macOS-Versionen und Hardwarevarianten kann derzeit jedoch nicht zugesagt werden.
+
+Für Apple-Silicon-Macs wird das Paket mit `arm64` benötigt. Für Intel-Macs ist das Paket mit `x86_64` vorgesehen.
+
+1. Lade die passende DMG-Datei herunter.
+2. Öffne die DMG-Datei.
+3. Ziehe `KST4Contest.app` in den Ordner **Programme**.
+4. Starte KST4Contest aus dem Programme-Ordner oder über das Launchpad.
+
+Ab Version 1.42 sind die macOS-Pakete mit einer Apple Developer ID signiert und von Apple notarisiert. Der erste Start funktioniert damit per Doppelklick, ohne Umweg über das Kontextmenü und ohne Sicherheitsabfrage. Das Notarisierungsticket liegt in der DMG-Datei selbst, sodass die Prüfung auch ohne Internetverbindung gelingt.
+
+Wer nachsehen möchte, ob ein heruntergeladenes Paket wirklich signiert ist, kann das im Terminal prüfen:
+
+```bash
+spctl --assess --type open --context context:primary-signature -v KST4Contest-v<Version>-macos-arm64.dmg
+```
+
+Erwartet wird `accepted` zusammen mit `source=Notarized Developer ID`.
+
+### Versionen bis einschließlich 1.41.1
+
+Ältere Pakete sind nicht notarisiert. macOS blockiert den ersten Start deshalb.
+
+Falls die Anwendung aus dem offiziellen GitHub Release stammt:
+
+1. Öffne den Programme-Ordner im Finder.
+2. Klicke mit der rechten Maustaste oder mit gedrückter Ctrl-Taste auf `KST4Contest.app`.
+3. Wähle **Öffnen**.
+4. Bestätige den Start im angezeigten Dialog.
+
+Alternativ kann macOS unter **Systemeinstellungen → Datenschutz & Sicherheit** die Schaltfläche **Trotzdem öffnen** anbieten.
+
+---
+
+## Wo werden die Einstellungen gespeichert?
+
+KST4Contest speichert seine Einstellungen und weitere lokale Arbeitsdateien im Benutzerverzeichnis. Der Programmordner und das Datenverzeichnis sind voneinander getrennt.
+
+| Betriebssystem | Datenverzeichnis | Einstellungsdatei |
+|---|---|---|
+| Windows | `%USERPROFILE%\.praktiKST\` | `%USERPROFILE%\.praktiKST\preferences.xml` |
+| Linux | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
+| macOS | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
+
+Beachte die Schreibweise `.praktiKST` mit großem `KST`. Unter Linux und macOS wird zwischen Groß- und Kleinschreibung unterschieden. `.praktikst` wäre dort schlicht ein anderes Verzeichnis.
+
+Ein Programmupdate entfernt dieses Verzeichnis nicht. Trotzdem ist es sinnvoll, vor größeren Versionswechseln oder umfangreichen Änderungen an der Konfiguration eine Sicherung davon anzulegen.
+
+---
+
+## Updates
+
+KST4Contest prüft beim Start, ob ein neueres Stable-Release verfügbar ist. Wenn eine neuere Version gefunden wird, erscheint ein Informationsfenster mit:
+
+- der installierten Version,
+- der aktuellen Stable-Version,
+- einer kurzen Übersicht wesentlicher Änderungen,
+- dem Changelog,
+- bekannten Problemen,
+- einem Link zur passenden GitHub-Release-Seite.
+
+![Update-Hinweis von KST4Contest](update_window.png)
+
+Der Update-Checker installiert nichts selbst. Er informiert über die neue Version und öffnet die plattformneutrale Release-Seite. Dort muss das passende Paket für Windows, Linux oder macOS ausgewählt werden.
+
+### Windows aktualisieren
+
+1. Beende KST4Contest.
+2. Lade das neue Windows-ZIP herunter.
+3. Entpacke es in einen neuen oder leeren Ordner.
+4. Starte die neue Version.
+5. Prüfe, ob die bisherigen Einstellungen geladen wurden.
+6. Entferne den alten Programmordner erst danach.
+
+Die Einstellungen bleiben erhalten, weil sie unter `%USERPROFILE%\.praktiKST` und nicht im Programmordner gespeichert werden.
+
+### AppImage aktualisieren
+
+1. Lade das neue AppImage herunter.
+2. Mache es ausführbar.
+3. Starte die neue Datei.
+4. Entferne das bisherige AppImage erst, wenn die neue Version funktioniert.
+
+### Debian und Ubuntu aktualisieren
+
+```bash
+sudo apt install ./KST4Contest-v<Version>-debian-amd64.deb
+```
+
+### Fedora aktualisieren
+
+```bash
+sudo dnf upgrade ./KST4Contest-v<Version>-fedora-x86_64.rpm
+```
+
+### Arch-Paket aktualisieren
+
+```bash
+sudo pacman -U KST4Contest-v<Version>-archlinux-x86_64.pkg.tar.zst
+```
+
+### AUR-Paket aktualisieren
+
+Aktualisiere das installierte Paket über den verwendeten AUR-Helper, beispielsweise:
+
+```bash
+yay -Syu
+```
+
+### Flatpak aktualisieren
+
+```bash
+flatpak update de.x08.KST4Contest
+```
+
+### macOS aktualisieren
+
+1. Lade die neue DMG-Datei für die vorhandene Architektur herunter.
+2. Beende KST4Contest.
+3. Öffne die DMG-Datei.
+4. Ersetze `KST4Contest.app` im Programme-Ordner.
+5. Starte die neue Version und prüfe die vorhandenen Einstellungen.
+
+Die Konfiguration unter `~/.praktiKST` bleibt davon unberührt.
+
+---
+
+## Probleme beim ersten Start
+
+### Windows meldet eine unbekannte Anwendung
+
+KST4Contest ist derzeit nicht mit einem kommerziellen Windows-Code-Signing-Zertifikat signiert. Windows oder ein zusätzlich installiertes Sicherheitsprodukt kann deshalb vor einer unbekannten oder selten heruntergeladenen Anwendung warnen.
+
+Prüfe in diesem Fall zuerst:
+
+- Stammt die Datei aus dem [offiziellen KST4Contest-Release](https://github.com/praktimarc/kst4contest/releases/latest)?
+- Passt der Dateiname zum veröffentlichten Release?
+- Wurde die Datei vollständig heruntergeladen?
+- Nennt das Sicherheitsprogramm einen konkreten Erkennungsnamen oder nur eine allgemeine Reputationswarnung?
+
+Ein Warnhinweis ist allein weder ein sicherer Beweis für Schadsoftware noch automatisch ein Fehlalarm. Wenn die Herkunft der Datei unklar ist, sollte sie nicht gestartet oder aus der Quarantäne wiederhergestellt werden.
+
+Einige Anwender haben insbesondere Quarantäne-Meldungen von Norton 360 gemeldet. Wenn sich eine Meldung reproduzieren lässt, erstelle bitte einen [GitHub-Issue](https://github.com/praktimarc/kst4contest/issues) und nenne:
+
+- die KST4Contest-Version,
+- den vollständigen Dateinamen,
+- das verwendete Sicherheitsprodukt und dessen Version,
+- den angezeigten Erkennungsnamen,
+- möglichst einen Screenshot der Meldung.
+
+### Das AppImage startet nicht
+
+Prüfe zuerst das Ausführungsrecht:
+
+```bash
+chmod +x KST4Contest-v<Version>-linux-x86_64.AppImage
+```
+
+Starte die Datei anschließend aus einem Terminal. Fehlermeldungen sind dort meist aussagekräftiger als ein Doppelklick, der lediglich nichts Sichtbares tut.
+
+### macOS blockiert die Anwendung
+
+Ab Version 1.42 sollte das nicht mehr vorkommen, da die Pakete signiert und notarisiert sind. Tritt die Blockade trotzdem auf, ist die DMG-Datei meist unvollständig heruntergeladen oder nachträglich verändert worden. Lade sie in dem Fall erneut aus dem offiziellen GitHub Release.
+
+Bei älteren Versionen ist die Blockade zu erwarten. Verwende dort die unter [Installation unter macOS](#installation-unter-macos) beschriebene Funktion **Öffnen** im Kontextmenü.
+
+### Das Problem bleibt bestehen
+
+Prüfe zunächst, ob das Problem bereits unter [GitHub Issues](https://github.com/praktimarc/kst4contest/issues) beschrieben wurde. Falls nicht, erstelle einen neuen Issue mit:
+
+- Betriebssystem und Version,
+- verwendeter KST4Contest-Version,
+- Installationsart,
+- genauer Fehlermeldung,
+- den Schritten, mit denen sich das Problem reproduzieren lässt.
+
+„Geht nicht“ beschreibt den Zustand meistens korrekt, hilft bei der Fehlersuche aber nur begrenzt.

github_docs/de-Konfiguration.md

@@ -0,0 +1,896 @@
+# Konfiguration
+
+> 🇬🇧 [English version](en-Configuration) | 🇩🇪 Du liest gerade die deutsche Version
+
+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**: 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`).
+
+---
+
+## Station Settings (Stationseinstellungen)
+
+![Stationseinstellungen](client_settings_window_station.png)
+
+### Login und Chat-Kategorien
+
+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) 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. 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
+
+Über die Checkboxen **My station uses …** wird festgelegt, auf welchen Bändern die eigene Station im aktuellen Setup arbeiten kann. Unterstützt werden 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1296 MHz, 2320 MHz, 3400 MHz, 5760 MHz und 10 GHz.
+
+Die Auswahl steuert nicht nur die sichtbaren Bandspalten. Sie wird außerdem verwendet für:
+
+- die bandbezogenen Worked- und NOT-QRV-Filter,
+- die im **Further Info**-Bereich sichtbaren NOT-QRV-Schalter,
+- die Herleitung von `a`- und `B+`-Bandmöglichkeiten,
+- den Filter **New bands**,
+- den Band-Upgrade-Hinweis nach einem Logeintrag und
+- bandbezogene Prioritäts- und Reachability-Funktionen.
+
+Nach einer Änderung **Save Settings** verwenden und KST4Contest neu starten. Die Bandspalten und mehrere zugehörige Bedienelemente werden beim Aufbau der Benutzeroberfläche erzeugt und deshalb nicht vollständig in der laufenden Sitzung ergänzt oder entfernt.
+
+### Antennen-Öffnungswinkel (Antenna Beamwidth)
+
+Trage den vollständigen horizontalen Öffnungswinkel der eigenen Antenne in Grad ein. KST4Contest verwendet jeweils die Hälfte dieses Werts links und rechts der gewählten beziehungsweise hergeleiteten Antennenrichtung. Ein eingetragener Wert von `70°` entspricht daher einem Korridor von `±35°`.
+
+Der Wert wird an mehreren Stellen verwendet:
+
+- für den QTF-Filter der Benutzerliste,
+- für die Darstellung des eigenen Antennenkorridors,
+- als angenommener Öffnungswinkel einer fremden Station bei der [Herleitung von Richtungsgelegenheiten](de-Funktionen#richtungsgelegenheiten-aus-gerichteten-nachrichten).
+
+Der letzte Punkt ist bewusst eine Näherung. ON4KST überträgt weder die verwendete Antenne noch deren Öffnungswinkel. KST4Contest verwendet deshalb den eigenen Wert als praktikable Annahme für die Gegenstation.
+
+Wähle einen realistischen Wert. Ein zu großer Öffnungswinkel erzeugt viele geometrische Treffer, die praktisch kaum noch eine Aussage haben. Ein zu kleiner Wert kann dagegen brauchbare Richtungsgelegenheiten ausblenden.
+
+### Standard-Maximum-QRB
+
+Trage die maximale Entfernung in Kilometern ein, innerhalb der KST4Contest Richtungsgelegenheiten berücksichtigen soll. Maßgeblich ist die Entfernung zwischen der eigenen Station und dem Absender der gerichteten Nachricht – nicht die Entfernung zwischen Absender und Empfänger.
+
+Liegt der Absender weiter entfernt, wird die Situation auch dann nicht hervorgehoben und nicht als Richtungsgelegenheit an den lokalen DX-Cluster-Server weitergegeben, wenn der berechnete Winkel passen würde.
+
+Der Wert sollte zum eigenen Stationsaufbau und zum vorgesehenen Contestbetrieb passen. Ein unnötig großer Bereich erzeugt Hinweise für Stationen, die praktisch nicht mehr zum Arbeitsbereich gehören; ein zu kleiner Bereich blendet mögliche Kandidaten bereits vor der Richtungsbewertung aus.
+
+---
+
+### Streckenanalyse und Link-Budget
+
+Die Stationskarte verwendet mehrere Werte aus dem Reiter **Station**, um das Geländeprofil und das Link-Budget zur ausgewählten Gegenstation zu berechnen. Die Angaben zum eigenen Stationsaufbau sollten deshalb möglichst realistisch sein. Bei der Gegenstation handelt es sich dagegen um globale Annahmen, solange keine genaueren Daten vorliegen.
+
+| Einstellung | Verwendung |
+|---|---|
+| **Own antenna height AGL** | Höhe der eigenen Antenne über dem lokalen Gelände in Metern |
+| **Own TX power W** | Eigene Sendeleistung in Watt |
+| **Own ant. gain dBi** | Gewinn der eigenen Antenne in dBi |
+| **DX OM TX power W** | Angenommene Sendeleistung der Gegenstation in Watt |
+| **DX OM ant. gain dBi** | Angenommener Antennengewinn der Gegenstation in dBi |
+
+**AGL** bedeutet *Above Ground Level*. Trage hier nicht die Höhe über dem Meeresspiegel ein. Die Geländehöhe am eigenen Standort stammt bereits aus dem Höhenprofil; KST4Contest addiert die konfigurierte Antennenhöhe zu diesem Wert.
+
+Für die Gegenstation verwendet KST4Contest derzeit eine feste Antennenhöhe von 10 Metern über dem lokalen Gelände. Sendeleistung und Antennengewinn der Gegenstation stammen aus den beiden **DX OM**-Feldern. Diese Werte sind bewusst nur Annahmen: Der ON4KST-Chat überträgt weder die tatsächliche Antennenhöhe noch die vollständigen Stationsdaten der Gegenstation.
+
+Antennengewinne müssen in `dBi` eingetragen werden. Liegt ein Wert in `dBd` vor, muss vor der Eingabe `2.15 dB` addiert werden:
+
+```text
+dBi = dBd + 2.15 dB
+```
+
+Die aktuelle QTF, der konfigurierte Antennen-Öffnungswinkel und das Standard-Maximum-QRB beeinflussen die Darstellung der Stationskarte. Die für die eigene Station aktivierten Bänder und die für die Gegenstation hergeleitete Frequenz wirken sich zusätzlich auf die Auswahl der Analysefrequenz aus.
+
+Für das Geländeprofil berücksichtigt KST4Contest die Antennenhöhen, das Höhenmodell und die Erdkrümmung mit einem festen effektiven Erdradiusfaktor von `k = 4/3`. Das Link-Budget verwendet außerdem:
+
+- die Entfernung und die aktuelle Analysefrequenz,
+- die Sendeleistungen und Antennengewinne beider Stationen,
+- frequenzabhängig geschätzte Speiseleitungsverluste,
+- die Freiraumdämpfung und
+- eine grobe zusätzliche Dämpfung durch das maßgebliche Hindernis im Geländeprofil.
+
+Die Berechnung erfolgt für beide Übertragungsrichtungen. Für die gemeinsame SSB- beziehungsweise CW-Marge ist die ungünstigere Richtung maßgeblich. Zu optimistische Leistungs- oder Antennenwerte verbessern daher zwar das angezeigte Ergebnis, nicht aber den realen Funkweg.
+
+Die Werte bleiben technische Abschätzungen. Aktuelle Ausbreitungsbedingungen, lokale Abschattungen, Bewuchs, Gebäude, Störungen und nicht bekannte Stationsparameter können das tatsächliche Ergebnis deutlich verändern. Bedienung, Frequenzauswahl und Grenzen der Berechnung sind unter [Stationskarte und Streckenanalyse](de-Funktionen#stationskarte-und-streckenanalyse-ab-v141) beschrieben.
+
+---
+
+
+
+## Log-Sync-Einstellungen
+
+Drei Methoden stehen zur Verfügung, um gearbeitete Stationen automatisch zu markieren. Details: [Log-Synchronisation](de-Log-Synchronisation).
+
+### Universal File Based Callsign Interpreter (Simplelogfile)
+
+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
+
+**Empfohlene Methode.** KST4Contest hört auf UDP-Pakete, die das Logprogramm beim Speichern eines QSOs an die Broadcast-Adresse sendet. Die Stationen werden mit Bandinformation markiert. UDP-Port: Standard **12060**. (Wird z. B. von UCXLog, N1MM+, QARTest, DXLog.net genutzt).
+
+### Win-Test Network-Listener (Zusätzlicher UDP-Listener)
+
+Dedizierter Netzwerk-Erkenner für Win-Test. KST4Contest empfängt und verarbeitet Win-Test-spezifische UDP-Pakete (inkl. Sked-Übergabe) auf dem dafür konfigurierten Port.
+
+---
+
+## TRX-Sync-Einstellungen
+
+Die TRX-Synchronisation übernimmt die aktuelle Frequenz aus dem Logprogramm und stellt sie in KST4Contest als eigene QRG der ersten Chat-Kategorie bereit. QSO- und Frequenzsynchronisation verwenden teilweise denselben UDP-Empfänger, sind funktional aber voneinander getrennt: Ein empfangenes `RadioInfo`-Paket markiert keine Station als gearbeitet, und ein QSO-Paket ändert nicht automatisch die eigene QRG.
+
+![Einstellungen für die TRX-Synchronisation](client_settings_window_trxsync.png)
+
+### Verfügbare QRG-Quellen
+
+| Quelle | Aktivierung | Verhalten |
+|---|---|---|
+| **Allgemeiner RadioInfo-Listener** | `Update MYQRG from RadioInfo messages received on the shared log-sync port` | Verarbeitet kompatible `RadioInfo`-Pakete auf dem gemeinsam mit der QSO-Synchronisation verwendeten UDP-Port. Der Standardport ist `12060`. |
+| **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. 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.
+
+### Welche QRG wird aktualisiert?
+
+Beide automatischen Quellen aktualisieren ausschließlich `MYQRG`. Das ist die eigene QRG der ersten beziehungsweise primären Chat-Kategorie.
+
+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 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
+
+Standardmäßig verwendet KST4Contest die Hauptfrequenz des empfangenen Win-Test-`STATUS`-Pakets.
+
+Die Option `Use pass frequency from Win-Test STATUS` verwendet stattdessen die im Paket enthaltene Pass-Frequenz. Das ist beispielsweise sinnvoll, wenn Win-Test im Split-Betrieb eine abweichende Frequenz führt und genau diese im Chat als Arbeitsfrequenz veröffentlicht werden soll.
+
+Enthält das Paket keine gültige Pass-Frequenz, fällt KST4Contest automatisch auf die Hauptfrequenz zurück. Eine fehlende Pass-Frequenz löscht daher weder `MYQRG` noch ersetzt sie den Wert durch eine offensichtlich falsche Zahl.
+
+Die Frequenzen werden einheitlich im KST4Contest-Format dargestellt, beispielsweise:
+
+```text
+50.300.00
+144.300.00
+1296.100.00
+10368.100.00
+```
+
+Die Werte werden erst beim Auflösen des Nachrichtentextes eingesetzt. Ändert das Logprogramm zwischen zwei Beacon-Läufen die Frequenz, verwendet die nächste Nachricht bereits den aktualisierten Wert.
+
+Die eigene QRG kann außerdem als Fallback für die Übergabe eines Skeds an Win-Test verwendet werden. Das geschieht nur, wenn die QRG auswertbar ist und zum ausdrücklich ausgewählten Sked-Band gehört. Einzelheiten stehen unter [Log-Synchronisation](de-Log-Synchronisation#skeds-an-win-test-übergeben).
+
+Weitere Informationen zu den Textvariablen: [Makros und Variablen](de-Makros-und-Variablen#variablen).
+
+### Mehrere Logger oder Funkgeräte
+
+Alle aktivierten QRG-Quellen schreiben in denselben Wert `MYQRG`. KST4Contest ordnet eingehende `RadioInfo`- oder `STATUS`-Pakete derzeit weder einem bestimmten Funkgerät noch einer Chat-Kategorie zu.
+
+Sind der allgemeine RadioInfo-Listener und die Win-Test-Synchronisation gleichzeitig aktiviert, bestimmt deshalb das zuletzt verarbeitete Paket die angezeigte QRG. Dasselbe gilt, wenn mehrere Logger ihre Frequenzpakete an dieselbe KST4Contest-Instanz senden.
+
+Für ein Setup mit mehreren Funkgeräten gilt daher:
+
+- QSO-Pakete dürfen von mehreren Loggern empfangen werden.
+- Frequenzpakete sollten nur von der Quelle gesendet werden, die `MYQRG` tatsächlich steuern soll.
+- In einem Win-Test-Netzwerk sollte zusätzlich der Stationsfilter verwendet werden.
+- Werden zwei vollständig unabhängige QRG-Synchronisationen benötigt, sind zwei getrennte KST4Contest-Instanzen die eindeutigere Lösung.
+
+Anders ausgedrückt: Mehrere Worked-Quellen lassen sich sinnvoll zusammenführen. Mehrere gleichzeitig sendende Frequenzquellen erzeugen dagegen keine zusätzliche Information, sondern lediglich einen Wettbewerb darum, welches Paket zuletzt angekommen ist.
+
+Nach Abschluss der Konfiguration **Save Settings** verwenden.
+
+---
+
+
+## AirScout-Einstellungen
+
+Im Reiter **AirScout** wird die UDP-Verbindung zwischen KST4Contest und AirScout eingerichtet. KST4Contest fordert dort keine allgemeinen Flugzeugdaten an, sondern übermittelt die aktuell relevanten Stationspfade. AirScout berechnet die dazu passenden Flugzeuge und sendet das Ergebnis an die anfragende KST4Contest-Instanz zurück.
+
+Vorausgesetzt wird AirScout `0.9.9.5` oder neuer.
+
+![AirScout-Einstellungen in KST4Contest](as_plane_feed_3.png){ width=85% }
+
+### Einstellungen der UDP-Verbindung
+
+| Einstellung | Standardwert | Verwendung |
+|---|---:|---|
+| **Enable AirScout UDP integration** | deaktiviert | Aktiviert das Senden von AirScout-Anfragen und die Verarbeitung der Antworten |
+| **AirScout server identifier** | `AS` | Logischer Name der angesprochenen AirScout-Instanz |
+| **KST4Contest client identifier** | `KST` | Logischer Name dieser KST4Contest-Instanz |
+| **AirScout UDP port** | `9872` | Gemeinsamer UDP-Port für Anfragen und Antworten |
+| **Select AirScout frequency automatically per station** | aktiviert | Ermittelt Band und Frequenz für jede Gegenstation aus dem aktuellen Stationskontext |
+| **Forced AirScout band value** | `1440000` | Verwendet bei deaktivierter Automatik einen festen AirScout-Bandwert für alle Stationen |
+
+Ist **Enable AirScout UDP integration** deaktiviert, sendet KST4Contest keine AirScout-Anfragen und verwirft eingehende AirScout-Antworten. Der UDP-Empfänger kann trotzdem gebunden bleiben, damit sich die Funktion während einer laufenden Verbindung wieder einschalten lässt.
+
+KST4Contest verwendet für ausgehende AirScout-Pakete die Broadcast-Adresse `255.255.255.255`. Eine Ziel-IP wird deshalb nicht separat konfiguriert. AirScout und KST4Contest müssen den verwendeten UDP-Broadcast empfangen können; Router leiten einen solchen Broadcast normalerweise nicht in ein anderes Netz weiter. Bei Problemen sollten daher zuerst der UDP-Port, die lokale Firewall und die Netzzuordnung geprüft werden.
+
+### Automatische Bandauswahl pro Station
+
+**Auto per station** ist die empfohlene Einstellung. KST4Contest verwendet dann nicht einen festen Bandwert für alle Gegenstationen, sondern leitet eine geeignete Frequenz aus den verfügbaren Informationen ab.
+
+Die Quellen werden in folgender Reihenfolge ausgewertet:
+
+1. die zuletzt erkannte, höchstens 30 Minuten alte QRG der Gegenstation,
+2. eine eindeutige vollständige QRG im Namensfeld eines aktiven Chat-Eintrags,
+3. eindeutige Bandangaben im Namensfeld,
+4. 432 MHz, wenn dieselbe Station gleichzeitig in der VHF/UHF- und Microwave-Kategorie aktiv ist und 432 MHz für die eigene Station aktiviert wurde,
+5. das niedrigste für die eigene Station aktivierte Band, das zur unterstützten Chat-Kategorie passt.
+
+Aktive Chat-Varianten desselben Basisrufzeichens werden gemeinsam ausgewertet. Die Einträge `CALLSIGN`, `CALLSIGN-2` und `CALLSIGN-432` können dadurch gemeinsam zur Bandherleitung beitragen, bleiben für die Nachrichtenverarbeitung aber getrennte Chat-Teilnehmer.
+
+Nur Bänder, die unter **My station uses …** aktiviert wurden, kommen für die automatische Auswahl infrage. Ein manuell gesetztes NOT-QRV-Kennzeichen schließt das betreffende Band aus und hat Vorrang vor automatisch erkannten QRG- oder Namensinformationen.
+
+Unterstützt werden die Chat-Kategorien für 50/70 MHz, VHF/UHF, Microwave und EME/JT65. Andere ON4KST-Kategorien werden für die AirScout-Bandherleitung ignoriert. Kann keine ausreichend belastbare Frequenz bestimmt werden, sendet KST4Contest für diese Station keine Anfrage. Ein beliebiger Rückfall auf 144 MHz würde zwar ein syntaktisch vollständiges Paket erzeugen, aber nicht zwangsläufig eine sinnvolle Berechnung.
+
+Die automatische AirScout-Auswahl verwendet dieselbe Herleitung wie die interne Streckenanalyse. Damit bewerten beide Funktionen den Stationspfad auf derselben fachlichen Grundlage.
+
+### Festes AirScout-Band
+
+Wird **Auto per station** deaktiviert, verwendet KST4Contest den unter **Forced AirScout band value** eingetragenen Wert für alle Stationen.
+
+Der Wert wird in der von der AirScout-UDP-Schnittstelle verwendeten Einheit eingetragen:
+
+| Band | AirScout-Wert |
+|---|---:|
+| 50 MHz | `500000` |
+| 70 MHz | `700000` |
+| 144 MHz | `1440000` |
+| 432 MHz | `4320000` |
+| 1296 MHz | `12960000` |
+| 2320 MHz | `23200000` |
+| 3400 MHz | `34000000` |
+| 5760 MHz | `57600000` |
+| 10368 MHz | `103680000` |
+| 24048 MHz | `240480000` |
+
+Im festen Modus wird weder die zuletzt erkannte QRG noch das im Namen genannte Band der Gegenstation berücksichtigt. Diese Einstellung ist deshalb hauptsächlich für einen eindeutig auf ein Band begrenzten Stationsbetrieb oder zur Fehlersuche sinnvoll.
+
+### Server- und Client-Identifier
+
+Die Identifier gehören zum AirScout-Protokoll und sind keine DNS-Namen oder IP-Adressen.
+
+Ausgehende Anfragen enthalten zunächst den Client- und anschließend den Server-Identifier:
+
+```text
+"KST" "AS"
+```
+
+AirScout antwortet in umgekehrter Reihenfolge:
+
+```text
+"AS" "KST"
+```
+
+KST4Contest verarbeitet eine Antwort nur, wenn beide Identifier exakt mit der aktuellen Konfiguration übereinstimmen. Der Vergleich unterscheidet zwischen Groß- und Kleinschreibung.
+
+Die Identifier dürfen nicht leer sein und keine Anführungszeichen oder Zeilenumbrüche enthalten.
+
+Werden mehrere KST4Contest-Instanzen im selben Netz betrieben, sollte jede einen eigenen Client-Identifier erhalten, beispielsweise:
+
+```text
+KST-144
+KST-432
+```
+
+Bei mehreren AirScout-Instanzen müssen zusätzlich unterschiedliche Server-Identifier verwendet werden. Dadurch wird verhindert, dass die Antwort für einen Arbeitsplatz von einer anderen KST4Contest-Instanz verarbeitet wird.
+
+### Welche Stationen werden angefragt?
+
+KST4Contest startet die erste periodische AirScout-Abfrage ungefähr zehn Sekunden nach dem Aufbau der Chat-Verbindung. Weitere Abfragen folgen im Abstand von 60 Sekunden.
+
+Eine aktive Station wird nur berücksichtigt, wenn:
+
+- ein verwendbares Rufzeichen vorhanden ist,
+- ein Locator vorhanden ist,
+- die Entfernung berechnet werden konnte,
+- die Entfernung kleiner als das konfigurierte **Maximum-QRB** ist und
+- ein verwendbares Band bestimmt werden konnte.
+
+Mehrere aktive Chat-Einträge desselben Basisrufzeichens erzeugen nicht für jeden Suffix eine eigene identische Pfadberechnung. Die zurückgegebenen AirScout-Informationen werden anschließend wieder den passenden aktiven Chat-Varianten zugeordnet.
+
+Die Auswahl begrenzt nicht nur den Netzwerkverkehr. Sie verhindert außerdem, dass AirScout dauerhaft Pfade berechnet, die außerhalb des für die eigene Station vorgesehenen Arbeitsbereichs liegen.
+
+### Übernahme geänderter Einstellungen
+
+Folgende Änderungen werden nach Verlassen des Eingabefeldes beziehungsweise Betätigen der Checkbox sofort für neue Pakete verwendet:
+
+- Aktivierung oder Deaktivierung der AirScout-Integration,
+- Server-Identifier,
+- Client-Identifier,
+- automatische oder feste Bandauswahl und
+- fester Bandwert.
+
+Nach einer Änderung des UDP-Ports muss die Chat-Verbindung getrennt und neu aufgebaut oder KST4Contest neu gestartet werden. Der bereits laufende UDP-Empfänger bleibt sonst weiterhin an den vorherigen Port gebunden.
+
+Zum dauerhaften Speichern anschließend **Save Settings** verwenden.
+
+Die Einrichtung der AirScout-Seite, die Anzeige der Flugzeuge und die Bedeutung der AP-Daten sind unter [AirScout-Integration](de-AirScout-Integration) beschrieben.
+
+---
+
+## Notification Settings (Benachrichtigungen)
+
+![Benachrichtigungen, DX-Cluster-Ausgabe und QSO-Monitoring](client_settings_window_notification.png)
+
+Im Reiter **Notification** werden nicht nur akustische Hinweise konfiguriert. Hier befinden sich auch die Einstellungen für den lokalen DX-Cluster-Server, den Band-Upgrade-Hinweis und das QSO-Monitoring.
+
+### Akustische Hinweise
+
+Die drei Audiofunktionen arbeiten unabhängig voneinander:
+
+- **Play notification sounds …** aktiviert kurze Hinweistöne für neue Privatnachrichten, erkannte Richtungsgelegenheiten, Sked-Erinnerungen und Band-Upgrade-Hinweise.
+- **Spell the sender's callsign in CW …** gibt das Rufzeichen des Absenders einer neuen Privatnachricht als CW-Signal aus.
+- **Speak the sender's callsign phonetically …** spricht das Rufzeichen des Absenders phonetisch aus.
+
+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.
+
+Zur Auswahl stehen ausschließlich die vom Frequenzparser unterstützten Bandpräfixe:
+
+```text
+50 MHz
+70 MHz
+144 MHz
+432 MHz
+1296 MHz
+2320 MHz
+3400 MHz
+5760 MHz
+10368 MHz (10G)
+24048 MHz (24G)
+```
+
+Das Dropdown ist kein Filter und keine Vorgabe für vollständig angegebene Frequenzen. `432.088` wird unabhängig von der Auswahl als Frequenz im 432-MHz-Band erkannt. Benötigt wird das Fallback bei relativen Angaben wie `.205`, `,205` oder `qrg 205`.
+
+Bevor KST4Contest auf das Fallback zurückgreift, prüft es den Bandkontext des Absenders. Wurde für dieselbe Station innerhalb der letzten 30 Minuten bereits eine passende vollständige Frequenz erkannt, hat dieses Band Vorrang. Ein Fallback von `144 MHz` macht aus `.100` daher `432.100 MHz`, wenn die Station kurz zuvor beispielsweise `432.088` genannt hat.
+
+Die Einstellung befindet sich im Notification-Bereich, wirkt aber auf die gesamte QRG-Erkennung. Damit beeinflusst sie nicht nur mögliche DX-Cluster-Spots, sondern auch die QRG-Spalte, erkannte aktive Bänder, Priorisierung, Band-Upgrade-Hinweise und Funktionen, die eine bekannte Stationsfrequenz verwenden.
+
+Mehr zur Erkennungslogik und zu absichtlich ignorierten Zahlen: [QRG-Erkennung](de-Funktionen#qrg-erkennung).
+
+### Local DX Cluster output
+
+KST4Contest kann erkannte Richtungsgelegenheiten als DX-Cluster-Spots an ein Logprogramm weitergeben. Eine im Chat erkannte Frequenz erscheint dadurch direkt in der Bandmap des Logprogramms und muss nicht erst von Hand übertragen werden.
+
+Die Checkbox **Enable the local DX Cluster server …** startet beziehungsweise beendet den lokalen TCP-Server. Bei einer laufenden Chat-Verbindung wird die Änderung sofort wirksam.
+
+Folgende Einstellungen und Schaltflächen gehören zur lokalen DX-Cluster-Ausgabe:
+
+- **TCP port**: Port, auf dem KST4Contest Verbindungen von DX-Cluster-Clients annimmt. Der Standardwert ist `8000`. Wird der Port während einer laufenden Verbindung geändert, startet KST4Contest den Server auf dem neuen Port neu. Der Logger muss sich anschließend ebenfalls mit dem neuen Port verbinden.
+- **Fallback band for relative QRG detection**: Das oben beschriebene globale Fallback-Band. Der Testspot verwendet `.300` dieses Bandes. Reale Spots verwenden dagegen die für den jeweiligen Absender erkannte QRG.
+- **Spotter callsign**: Rufzeichen, das im erzeugten DX-Cluster-Spot als Spotter erscheint. Hier sollte ein anderes Rufzeichen als das im Contest verwendete Stationsrufzeichen eingetragen werden. Einige Logprogramme filtern Spots des eigenen Rufzeichens oder behandeln sie anders als fremde Spots.
+- **Send test spot**: Sendet den folgenden Testspot an alle aktuell verbundenen DX-Cluster-Clients:
+
+```text
+Spotted callsign: DO5AMF
+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
+
+1. KST4Contest mit dem ON4KST-Chat verbunden ist,
+2. der lokale DX-Cluster-Server aktiviert ist und
+3. mindestens ein DX-Cluster-Client mit KST4Contest verbunden ist.
+
+KST4Contest erzeugt nicht bei jeder im Chat gefundenen Frequenz automatisch einen Spot. Ein realer Spot entsteht nur dann, wenn eine gerichtete Nachricht zwischen zwei Stationen auf eine für die eigene Station interessante Antennenrichtung schließen lässt und für den Absender eine nutzbare Frequenz bekannt ist.
+
+Die vollständige Herleitung und die Einrichtung des Logprogramms sind im Kapitel [Integrierter DX-Cluster-Server](de-DX-Cluster-Server) beschrieben.
+
+### Band-Upgrade-Hinweis nach einem Logeintrag
+
+Nach einem über UCXLog oder Win-Test empfangenen Logeintrag kann KST4Contest prüfen, ob die gerade gearbeitete Station noch ein weiteres gemeinsames, aber bisher nicht gearbeitetes Band anbietet.
+
+Die Prüfung verwendet dieselbe Bandherleitung wie die `a`- und `B+`-Anzeige:
+
+1. die in den Stationseinstellungen aktivierten eigenen Bänder,
+2. höchstens 30 Minuten alte QRG-Erkennungen der Gegenstation,
+3. eindeutige Bandangaben im Namensfeld ihrer aktiven Chat-Einträge,
+4. die pro Band gespeicherten Worked-Markierungen und
+5. manuell gesetzte NOT-QRV-Tags.
+
+Aktive Chat-Varianten desselben normalisierten Rufzeichens werden gemeinsam ausgewertet. NOT-QRV hat Vorrang vor einer automatisch erkannten QRG oder Bandangabe.
+
+Bleibt mindestens ein gemeinsames, noch nicht gearbeitetes Band übrig, erscheint im Hauptfenster für ungefähr zwölf Sekunden ein blinkender **BAND+**-Hinweis mit Rufzeichen und den noch offenen Bändern. Der Tooltip zeigt die vollständige Herleitung. Ist die allgemeine Soundausgabe aktiviert, wird zusätzlich ein kurzer Hinweiston abgespielt.
+
+Die beiden Optionen haben unterschiedliche Aufgaben:
+
+- **Blink + sound …** aktiviert den Hinweis nach einem passenden Logeintrag.
+- **Priority boost …** erhöht zusätzlich den Score von Stationen, die bereits auf mindestens einem Band gearbeitet wurden, aber noch ein weiteres gemeinsames und nicht gearbeitetes Band anbieten.
+
+Der Priority Boost ist nur ein Faktor innerhalb der gesamten Berechnung. Entfernung, Antennenrichtung, aktuelle Aktivität, AirScout-Daten, Skeds und negative Hinweise können den endgültigen Listenplatz weiterhin verändern. Die aktivierte Option garantiert deshalb weder einen bestimmten Score noch einen bestimmten Platz in der Prioritätsliste.
+
+Die übrigen Score-Gewichte besitzen derzeit keine eigenen Bedienelemente. Mehrere vorhandene Einstellungen liefern jedoch Eingangsdaten für die Berechnung, insbesondere die [aktivierten Bänder](#aktivierte-bänder), der [Antennen-Öffnungswinkel](#antennen-öffnungswinkel-antenna-beamwidth), der [Standard-Maximum-QRB](#standard-maximum-qrb) und die [AirScout-Einstellungen](#airscout-einstellungen).
+
+Die vollständige Herleitung ist unter [Prioritätsscore und Prioritätsliste](de-Funktionen#prioritätsscore-und-prioritätsliste-ab-v140) beschrieben.
+
+Der Hinweis setzt eine Log-Synchronisation mit Bandinformation voraus. Der einfache dateibasierte Callsign-Interpreter erkennt lediglich Rufzeichen und liefert deshalb keine sichere Information über das Band des gerade geloggten QSOs.
+
+Weitere Hintergründe: [Band-Upgrade-Hinweis nach einem Logeintrag](de-Funktionen#band-upgrade-hinweis-nach-einem-logeintrag).
+
+### Sniffer-Einstellungen (ab v1.31)
+
+Das QSO-Monitoring ist für Stationen gedacht, deren Kommunikation man gezielt verfolgen möchte. Das kann beispielsweise eine seltene Station, eine DXpedition oder eine andere Station des eigenen Contest-Teams sein, deren Sked-Absprachen im allgemeinen Chatverkehr nicht untergehen sollen.
+
+Die Rufzeichen werden im Reiter **Notification** unter **QSO monitoring** verwaltet.
+
+Für jedes eingetragene Basisrufzeichen zeigt KST4Contest Nachrichten zusätzlich in der PM-Tabelle an, wenn eine Variante dieses Rufzeichens entweder Absender oder Empfänger der Nachricht ist. Berücksichtigt werden beide verbundenen Chat-Kategorien.
+
+Die Liste arbeitet bewusst mit dem normalisierten Basisrufzeichen. Folgende Eingaben erzeugen deshalb denselben Monitoring-Eintrag:
+
+```text
+DN9APW
+DN9APW-2
+DN9APW-70
+DN9APW-144
+```
+
+In allen Fällen speichert und zeigt KST4Contest den Eintrag als:
+
+```text
+DN9APW
+```
+
+Damit müssen die verschiedenen KST-Suffixe einer Station nicht einzeln eingetragen werden. Wird später eine Nachricht von `DN9APW-2` gesendet oder an `DN9APW-70` adressiert, wird sie durch denselben Eintrag erfasst.
+
+Diese Zusammenführung gilt ausschließlich für das QSO-Monitoring. Die aktiven ChatMember-Objekte, vollständigen Nachrichtenempfänger und Chat-Kategorien bleiben getrennt. Eine an `DN9APW-70` gerichtete Nachricht wird deshalb nicht an `DN9APW-2` umgeleitet.
+
+Überwachte Nachrichten werden in der PM-Tabelle mit den vollständigen sichtbaren Rufzeichen von Absender und Empfänger gekennzeichnet:
+
+```text
+Sniffed: (DN9APW-2 > DL0ABC-70) Nachrichtentext
+```
+
+Die ursprüngliche Nachricht bleibt gleichzeitig in ihrer normalen Tabelle erhalten. Das Monitoring verändert weder den Nachrichteninhalt noch dessen Routing.
+
+Erfasst werden Nachrichten, bei denen das überwachte Rufzeichen tatsächlich Absender oder Empfänger ist. Eine bloße Erwähnung des Rufzeichens im Nachrichtentext reicht nicht aus. Öffentliche Nachrichten einer überwachten Station werden ebenfalls angezeigt; als Empfänger erscheint dabei `ALL`.
+
+Ist eine Nachricht bereits direkt an das eigene Rufzeichen gerichtet, erscheint sie als normale Privatnachricht und erhält keine zusätzliche `Sniffed:`-Kennzeichnung.
+
+Rufzeichen werden folgendermaßen verwaltet:
+
+1. Mit **Add monitored callsign** ein neues Rufzeichen hinzufügen.
+2. Ein vorhandenes Rufzeichen per Doppelklick bearbeiten und die Änderung mit `Enter` übernehmen.
+3. Zum Entfernen den Inhalt einer Tabellenzelle löschen und mit `Enter` bestätigen.
+
+Die Eingabe darf ein sichtbares KST-Suffix oder portable Bestandteile enthalten. KST4Contest normalisiert sie vor dem Speichern auf das Basisrufzeichen. Mehrere Varianten desselben Basisrufzeichens gelten deshalb als Duplikat.
+
+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 ab v1.42 enthalten.
+
+Weitere Hintergründe und die Abgrenzung zum Nachrichtenrouting: [QSO-Monitoring](de-Funktionen#qso-monitoring-ab-v131).
+---
+
+## Shortcut Settings (Schnellzugriff-Schaltflächen)
+
+![Konfiguration der Shortcut-Schaltflächen und Text-Snippets](client_settings_window_shortcuts.png)
+
+Jeder Eintrag im oberen Bereich des Reiters **Shortcuts** erzeugt eine Schaltfläche oberhalb des Nachrichteneingabefeldes im Hauptfenster. Ein Klick hängt den konfigurierten Text an den bereits vorhandenen Inhalt des Sendfeldes an.
+
+Enthält der Shortcut eine [Variable](de-Makros-und-Variablen#variablen), wird sie beim Einfügen durch ihren aktuellen Wert ersetzt. Ein Shortcut wie
+
+```text
+pse call me at MYQRGSHORT
+```
+
+kann dadurch beispielsweise folgenden Text einfügen:
+
+```text
+pse call me at 144.388
+```
+
+Die exakten Einträge `MYQRG` und `SECONDQRG` werden zusätzlich als QRG-Schaltflächen hervorgehoben. Sie fügen die aktuelle QRG der ersten beziehungsweise zweiten Chat-Kategorie ein.
+
+Auch der Shortcut `/SETNAME MYQRG` wird hervorgehoben. Beim Anklicken löst KST4Contest `MYQRG` auf und übernimmt den vollständigen Serverbefehl in das Sendfeld. Der Befehl wird nicht automatisch versendet und kann vor dem Senden mit `Enter` oder **TX** noch geprüft werden.
+
+
+Die Reihenfolge der Tabelle entspricht der Reihenfolge der Schaltflächen im Hauptfenster. Die Einträge werden folgendermaßen verwaltet:
+
+1. Mit **Add shortcut** wird am Anfang der Liste ein neuer Eintrag angelegt und sofort zur Bearbeitung geöffnet.
+2. Ein vorhandener Eintrag kann per Doppelklick bearbeitet werden. `Enter` übernimmt die Änderung.
+3. Wird der Inhalt vollständig gelöscht und anschließend mit `Enter` bestätigt, entfernt KST4Contest den Eintrag.
+4. Mit **Move selected up** und **Move selected down** wird der markierte Eintrag innerhalb der Liste verschoben.
+
+Änderungen werden sofort im Hauptfenster sichtbar. Damit sie auch nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
+
+---
+
+## Snippet Settings (Text-Snippets)
+
+Snippets sind längere Textbausteine, die vor allem für Nachrichten an eine ausgewählte Station vorgesehen sind. Sie können über folgende Wege aufgerufen werden:
+
+- per Rechtsklick auf eine Station in der Benutzerliste,
+- per Rechtsklick auf eine Nachricht in der öffentlichen Chat-Tabelle,
+- per Rechtsklick auf eine Nachricht in der PM-Tabelle oder
+- mit `Ctrl+1` bis `Ctrl+0` für die ersten zehn Einträge der Snippet-Liste.
+
+Bei den Tastenkombinationen entspricht die Zuordnung der Tabellenreihenfolge:
+
+| Tastenkombination | Snippet |
+|---|---:|
+| `Ctrl+1` | erster Eintrag |
+| `Ctrl+2` | zweiter Eintrag |
+| … | … |
+| `Ctrl+9` | neunter Eintrag |
+| `Ctrl+0` | zehnter Eintrag |
+
+Ein über das Kontextmenü ausgewähltes Snippet wird an den bereits vorbereiteten Nachrichtentext angehängt. Die Auswahl einer Station oder Nachricht hat das Sendfeld zuvor normalerweise bereits mit dem passenden `/cq`-Empfänger vorbereitet.
+
+Eine Tastenkombination verhält sich etwas anders: Sie ersetzt den bisherigen Inhalt des Sendfeldes durch eine vollständig adressierte Privatnachricht:
+
+```text
+/cq RUFZEICHEN Snippet-Text
+```
+
+Dabei wird das vollständige sichtbare Rufzeichen einschließlich eines vorhandenen Suffixes verwendet. Für `9A0BB-70` entsteht daher beispielsweise:
+
+```text
+/cq 9A0BB-70 pse ur qrg?
+```
+
+Die Chat-Kategorie der ausgewählten Station bleibt für den späteren Versand erhalten. Ist keine Station ausgewählt oder ist für die gedrückte Tastenkombination kein Snippet vorhanden, wird nichts eingefügt.
+
+Variablen werden beim Einfügen des Snippets aufgelöst. Stationsbezogene Variablen wie `QRZNAME`, `FIRSTAP` oder `SECONDAP` verwenden die aktuell ausgewählte Station. Der vorbereitete Text wird nicht automatisch gesendet und kann deshalb noch geprüft oder geändert werden. `Enter` oder **TX** sendet die Nachricht; `Esc` leert das Sendfeld.
+
+Die Snippet-Liste wird genauso bearbeitet wie die Shortcut-Liste:
+
+1. **Add new snippet** legt am Anfang der Liste einen neuen Eintrag an.
+2. Ein Doppelklick öffnet einen vorhandenen Eintrag zur Bearbeitung.
+3. `Enter` übernimmt die Änderung.
+4. Ein leer bestätigter Eintrag wird entfernt.
+5. **Move selected up** und **Move selected down** ändern die Reihenfolge und damit auch die Zuordnung zu `Ctrl+1` bis `Ctrl+0`.
+
+Die Kontextmenüs und Tastenkombinationen werden nach einer Änderung sofort aktualisiert. Für die dauerhafte Speicherung anschließend **Save Settings** verwenden.
+
+Eine vollständige Übersicht der verfügbaren Platzhalter und ihrer Grenzen steht unter [Makros und Variablen](de-Makros-und-Variablen).
+
+---
+
+## Beacon Settings (Automatischer Beacon)
+
+![Beacon-Einstellungen](client_settings_window_beacon.png)
+
+Ein Beacon sendet in regelmäßigen Abständen eine öffentliche CQ-Nachricht. Er ist für Betriebssituationen gedacht, in denen die eigene Station über längere Zeit auf einer festen Frequenz ruft. Andere Stationen erhalten dadurch eine aktuelle QRG-Information, ohne dass der Operator denselben Text immer wieder von Hand in den Chat schreiben muss.
+
+KST4Contest verwendet einen gemeinsamen Timer für beide Chat-Kategorien. Aktivierung und Nachrichtentext werden trotzdem getrennt konfiguriert:
+
+- **Enable CQ beacon** aktiviert den Beacon der betreffenden Kategorie.
+- **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 die zweite Kategorie in derselben ON4KST-Sitzung aktiviert und vollständig synchronisiert ist.
+
+### Intervall und Timer-Verhalten
+
+Das Intervall wird in ganzen Minuten angegeben. Der kleinste zulässige Wert ist eine Minute.
+
+Nach dem Aufbau der Chat-Verbindung prüft KST4Contest die Beacons erstmals nach ungefähr zehn Sekunden. Anschließend gilt das eingestellte Intervall.
+
+Wird das Intervall während einer laufenden Verbindung geändert, beginnt der Countdown mit dem neuen Wert erneut. Die Änderung selbst löst keine sofortige Beacon-Nachricht aus.
+
+Beide Kategorien verwenden denselben Timer. Unterschiedliche Intervalle für den ersten und zweiten Chat können deshalb nicht eingestellt werden.
+
+### Nachrichtentext und Variablen
+
+Ein Beacon darf die [globalen Variablen](de-Makros-und-Variablen#variablen-im-beacon) verwenden, die sich ausschließlich auf die eigene Station beziehen:
+
+- `MYQRG`
+- `MYQRGSHORT`
+- `SECONDQRG`
+- `MYLOCATOR`
+- `MYLOCATORSHORT`
+- `MYCALL`
+- `MYQTF`
+
+Eine mögliche Nachricht für die erste Chat-Kategorie ist:
+
+```text
+calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
+```
+
+Für den zweiten Chat muss `SECONDQRG` verwendet werden, wenn dessen Frequenz von der ersten Kategorie abweicht:
+
+```text
+calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
+```
+
+Die Variablen werden bei jedem Timer-Lauf neu aufgelöst. Ändert die Logsoftware zwischenzeitlich die in `MYQRG` gespeicherte Frequenz, verwendet bereits der nächste Beacon den aktualisierten Wert. Das Template selbst muss dafür nicht geändert werden.
+
+`MYQRG` und `MYQRGSHORT` beziehen sich immer auf die erste Chat-Kategorie. Die Auswahl oder Aktivierung des zweiten Chats ändert diese Zuordnung nicht.
+
+Stationsbezogene Variablen wie `QRZNAME`, `FIRSTAP` oder `SECONDAP` benötigen eine ausgewählte Gegenstation. Da ein öffentlicher Beacon keine bestimmte Station adressiert, werden diese Variablen im Beacon nicht aufgelöst.
+
+### Prüfung des Nachrichtentextes
+
+KST4Contest prüft sowohl das eingetragene Template als auch den nach der Variablenauflösung tatsächlich zu sendenden Text.
+
+Für Beacon-Nachrichten gelten folgende Bedingungen:
+
+- Der endgültige Nachrichtentext darf nicht leer sein.
+- Er darf höchstens 120 Zeichen enthalten.
+- Das Protokoll-Trennzeichen `|` ist nicht zulässig.
+- Zeilenumbrüche sind nicht zulässig.
+
+Eine ungültige Eingabe wird nicht als neue Beacon-Konfiguration übernommen. Wird ein Template erst durch eine spätere Variablenauflösung ungültig, beispielsweise weil der aufgelöste Text länger als 120 Zeichen ist, wird dieser Beacon-Lauf ausgelassen.
+
+Ein Template, das ausschließlich aus einer momentan noch leeren globalen Variable besteht, kann gespeichert werden. Das ist beispielsweise beim Start möglich, bevor die erste QRG vom Logprogramm empfangen wurde. Solange die Variable keinen verwendbaren Inhalt liefert, sendet KST4Contest jedoch keine leere Nachricht.
+
+### Wann sollte der Beacon ausgeschaltet werden?
+
+Der Beacon ist nur dann hilfreich, wenn seine QRG-Angabe zum tatsächlichen Betrieb passt. Bleibt er beim Absuchen oder häufigen Wechseln von Frequenzen aktiviert, können andere Stationen auf einer inzwischen falschen Frequenz nach der eigenen Station suchen.
+
+Im Klartext: Solange auf einer festen QRG CQ gerufen wird, spart der Beacon Arbeit. Beim „Schleichen“ über das Band sollte er ausgeschaltet werden.
+
+Änderungen wirken während der laufenden Verbindung. Damit Aktivierung, Texte und Intervall auch nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
+
+---
+
+## Messagehandling Settings (ab v1.25)
+
+![Automatische Antworten](client_settings_window_messagehandling.png)
+
+Die wichtigste Anwendung der allgemeinen automatischen Antwort betrifft Stationen, die zwar im ON4KST-Chat eingeloggt sind, den laufenden Contest aber nicht mitfunken. Gerade während größerer Contests werden Sked-Anfragen teilweise unkoordiniert und in großer Zahl an eingeloggte Stationen verteilt, ohne vorher zu prüfen, ob sie überhaupt teilnehmen. Die Empfänger müssten sonst immer wieder dieselbe Absage schreiben.
+
+KST4Contest kann darauf mit einem vorher festgelegten Text reagieren. Davon getrennt steht eine gezielte QRG-Auskunft zur Verfügung. Beide Funktionen können unabhängig voneinander aktiviert werden.
+
+### Allgemeine automatische Antwort
+
+**Enable automatic reply to all private messages** beantwortet eingehende Privatnachrichten mit dem Text im Feld rechts daneben. Es gibt einen gemeinsamen Text für beide Chat-Kategorien. Die beim Eingeben verwendete Groß- und Kleinschreibung bleibt erhalten.
+
+Eine zweckmäßige Nachricht ist beispielsweise:
+
+```text
+Sri, I am not taking part in this contest. No skeds.
+```
+
+Das Präfix `[KST4C Automsg]` muss nicht in das Eingabefeld geschrieben werden. KST4Contest ergänzt es automatisch.
+
+Die beim Empfänger sichtbare Nachricht lautet daher beispielsweise:
+
+```text
+[KST4C Automsg] Sri, I am not taking part in this contest. No skeds.
+```
+
+Die eingegangene Privatnachricht bleibt sichtbar. Die Funktion blockiert oder verwirft keine Anfrage, sondern erspart lediglich die wiederholte manuelle Antwort.
+
+Die Antwort wird an das vollständige Rufzeichen des Absenders einschließlich eines vorhandenen Suffixes und in derselben Chat-Kategorie gesendet, in der die Privatnachricht eingegangen ist. Das ist bei einem parallelen Login in zwei Kategorien entscheidend: Eine Nachricht aus dem Microwave-Chat darf nicht versehentlich im VHF/UHF-Chat beantwortet werden.
+
+Ein leerer oder ausschließlich aus Leerzeichen bestehender Antworttext erzeugt keine automatische Nachricht. Enthält der Text ein Protokoll-Trennzeichen wie `|` oder einen Zeilenumbruch, wird die Antwort ebenfalls verworfen.
+
+### Automatische QRG-Antwort
+
+**Enable automatic QRG replies** reagiert auf typische QRG-Anfragen. Die Erkennung unterscheidet nicht zwischen Groß- und Kleinschreibung und sucht nach folgenden Textbestandteilen:
+
+```text
+ur qrg?
+your qrg?
+qrg?
+freq?
+pse qrg
+```
+
+Die Antwort enthält ausschließlich die QRG der Kategorie, in der die Anfrage eingegangen ist:
+
+| Eingegangene Privatnachricht | Verwendete QRG |
+|---|---|
+| Hauptkategorie | aktuelle QRG der Hauptkategorie |
+| zweite Chat-Kategorie | aktuelle QRG der zweiten Kategorie |
+
+Eine mögliche Antwort lautet:
+
+```text
+[KST4C Automsg] QRG is: 144.300.00
+```
+
+Die Werte stammen aus denselben QRG-Feldern, die auch von `MYQRG` und `SECONDQRG` verwendet werden. Die Haupt-QRG kann manuell eingetragen oder durch die [TRX-Synchronisation](#trx-sync-einstellungen) aktualisiert werden. Für die zweite Kategorie wird der dort konfigurierte beziehungsweise manuell eingetragene Wert verwendet.
+
+Ist für die betreffende Kategorie keine QRG vorhanden, sendet KST4Contest keine unvollständige Antwort. Eine Nachricht wie `QRG is:` ohne Frequenz würde zwar auf die Frage reagieren, dem Anfragenden aber keine Information liefern. Sie wird deshalb bereits vor der Übergabe an die Sendequeue verworfen.
+
+Sind die allgemeine und die QRG-bezogene Antwort gleichzeitig aktiviert, hat die QRG-Antwort Vorrang. Eine erkannte QRG-Anfrage erzeugt daher nicht zusätzlich den allgemeinen Antworttext. Fehlt die benötigte QRG, fällt KST4Contest auch nicht auf die allgemeine Antwort zurück.
+
+### Schutz vor wiederholten Antworten
+
+Jede automatisch erzeugte Nachricht trägt das feste Präfix:
+
+```text
+[KST4C Automsg]
+```
+
+Die allgemeine und die QRG-bezogene Antwort reagieren nicht auf Nachrichten, die dieses Präfix bereits enthalten. Dadurch beantworten sich zwei entsprechend arbeitende Clients nicht gegenseitig in einer Schleife.
+
+Zusätzlich gilt eine gemeinsame Sperrzeit von zwei Minuten für beide Antwortarten. Die Sperre wird getrennt nach vollständigem Rufzeichen und Chat-Kategorie geführt.
+
+Daraus folgt:
+
+- `CALLSIGN-2` und `CALLSIGN-70` besitzen getrennte Sperrzeiten.
+- Dasselbe vollständige Rufzeichen kann in einer anderen Chat-Kategorie unabhängig beantwortet werden.
+- Eine allgemeine Antwort sperrt für zwei Minuten auch eine QRG-Antwort an dasselbe Rufzeichen in derselben Kategorie.
+- Eine QRG-Antwort sperrt entsprechend auch die allgemeine Antwort.
+
+Die Sperrzeit beginnt nur, wenn KST4Contest eine vollständige und lokal gültige Antwort in die Sendequeue übernimmt. Eine fehlende QRG, ein leerer allgemeiner Antworttext oder ein wegen ungültiger Zeichen verworfener Text startet keine Sperrzeit. Sobald die fehlende Information korrigiert wurde, kann daher unmittelbar eine gültige Antwort erzeugt werden.
+
+> **Hinweis**: Der Antworttext sollte den tatsächlichen Status eindeutig benennen. Wer den Contest nur beobachtet und keine Skeds fahren möchte, sollte genau das mitteilen. Eine vage Nachricht erzeugt im Zweifel nur die nächste Rückfrage – und damit exakt die Arbeit, welche die Funktion vermeiden soll.
+
+Änderungen wirken während der laufenden Verbindung. Damit Aktivierung und Text nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
+
+Weitere Hintergründe: [Automatische Antworten auf Privatnachrichten](de-Funktionen#automatische-antworten-auf-privatnachrichten-ab-v125).
+
+---
+
+## Win-Test-Netzwerk-Listener (ab v1.31)
+
+Der Win-Test-Netzwerk-Listener verarbeitet das native Win-Test-UDP-Protokoll. Er ist vom allgemeinen QSO-UDP-Listener auf Port `12060` unabhängig und übernimmt drei Aufgaben:
+
+- QSOs einschließlich Band- und Locatorinformation auswerten,
+- STATUS-Pakete für die eigene QRG verarbeiten und
+- Skeds an das Win-Test-Netzwerk übergeben.
+
+### Einstellungen unter Log sync
+
+| Einstellung | Funktion |
+|---|---|
+| **Receive Win-Test network based UDP log messages** | Aktiviert den Win-Test-Netzwerk-Listener. Bei aktiviertem Listener wird nach **Create sked** auch die Sked-Übergabe versucht. |
+| **UDP-Port for Win-Test listener** | Port des Win-Test-Netzwerks. Standard ist `9871`. Der Port wird auch für die Sked-Übergabe verwendet. |
+| **KST station name in Win-Test network (src of SKED packets)** | Stationsname, unter dem KST4Contest die Sked-Pakete sendet. In einem Netzwerk mit mehreren Clients sollte ein eindeutiger Name verwendet werden. |
+| **Win-Test network broadcast address** | Zieladresse für ausgehende Win-Test-Netzwerkpakete. Bei lokalem Netzwerkbetrieb muss hier eine vom Win-Test-Rechner erreichbare Broadcast-Adresse eingetragen sein. |
+
+Die Broadcast-Adresse ist konfigurierbar, weil `255.255.255.255` nicht in jedem Stationsnetz und nicht über jede Netzwerkschnittstelle zuverlässig weitergeleitet wird. Bei mehreren Rechnern kann stattdessen die zum Stationsnetz gehörende gerichtete Broadcast-Adresse erforderlich sein.
+
+### Einstellungen unter TRX sync
+
+| Einstellung | Funktion |
+|---|---|
+| **Win-Test STATUS QRG Sync** | Übernimmt die aktuelle Frequenz aus Win-Test-STATUS-Paketen als eigene QRG. |
+| **Use pass frequency from Win-Test STATUS** | Verwendet die übertragene Pass-Frequenz anstelle der normalen TRX-QRG. |
+| **Win-Test station name filter** | Verarbeitet nur STATUS-Pakete der angegebenen Win-Test-Station. Ein leeres Feld akzeptiert alle Stationsnamen. |
+
+Der Stationsfilter ist insbesondere bei mehreren Win-Test-Clients sinnvoll. Ohne Filter kann die zuletzt eingegangene STATUS-Meldung eines anderen Arbeitsplatzes die eigene QRG in KST4Contest überschreiben.
+
+### Sked-Übergabe
+
+Für die Sked-Übergabe gibt es keinen davon getrennten internen Sked-Modus. Ist der Listener aktiviert, versucht **Create sked** zusätzlich zur internen Anlage die Übertragung an Win-Test.
+
+KST4Contest sendet nur dann ein `ADDSKED`-Paket, wenn eine QRG ermittelt wurde, die zum ausdrücklich ausgewählten Band gehört. Kann keine passende QRG gefunden werden, bleibt der interne Sked bestehen und die Win-Test-Übergabe wird ausgelassen.
+
+Die Auswahl `SSB` oder `CW` erfolgt direkt im Further-Info-Bereich beim Anlegen des Skeds. Eine automatische Mode-Ableitung wird nicht verwendet.
+
+Nach Änderungen **Save Settings** verwenden, damit Port, Stationsname, Broadcast-Adresse und TRX-Optionen beim nächsten Programmstart wiederhergestellt werden.
+
+Datenbehandlung und QRG-Auswahl: [Log-Synchronisation – Win-Test](de-Log-Synchronisation#win-test)
+
+
+## PSTRotator-Einstellungen (ab v1.31, vollständig konfigurierbar ab v1.40)
+
+KST4Contest kann eine ausgewählte Antennenrichtung über die UDP-Schnittstelle von [PSTRotator](https://www.pstrotator.com/) einstellen und die von PSTRotator gemeldete aktuelle Position als eigene QTF übernehmen.
+
+Die Einstellungen befinden sich im Reiter **Station**:
+
+| Einstellung | Standardwert | Verwendung |
+|---|---:|---|
+| **Enable PSTRotator** | deaktiviert | Startet die UDP-Kommunikation mit PSTRotator |
+| **PSTRotator host** | `127.0.0.1` | Hostname oder IP-Adresse des Rechners, auf dem PSTRotator läuft |
+| **PSTRotator UDP port** | `12000` | UDP-Port, auf dem PSTRotator die Steuerbefehle empfängt |
+
+Bei Betrieb auf demselben Rechner ist `127.0.0.1` normalerweise die eindeutigste Einstellung. Läuft PSTRotator auf einem anderen Rechner im Stationsnetz, muss dessen erreichbare IP-Adresse oder DNS-Name eingetragen werden.
+
+Der Port darf zwischen `1` und `65534` liegen. Port `65535` ist nicht möglich, weil PSTRotator seine Positionsmeldungen auf dem jeweils folgenden Port sendet.
+
+### PSTRotator vorbereiten
+
+In PSTRotator muss unter **Communication → UDP Control Port** derselbe UDP-Port eingetragen werden wie in KST4Contest. Anschließend muss **UDP Control** in PSTRotator aktiviert werden.
+
+Bei der Standardeinstellung ergibt sich folgendes Portpaar:
+
+| Richtung | UDP-Port |
+|---|---:|
+| KST4Contest → PSTRotator | `12000` |
+| PSTRotator → KST4Contest | `12001` |
+
+KST4Contest bindet den Empfangsport automatisch. Er wird nicht separat konfiguriert.
+
+Bei Betrieb auf zwei Rechnern müssen die lokale Firewall und das Stationsnetz UDP-Pakete in beiden Richtungen zulassen. Ist der Empfangsport bereits durch ein anderes Programm belegt, kann KST4Contest die Positionsmeldungen nicht empfangen.
+
+Das vollständige UDP-Protokoll ist im [PSTRotatorAz User Manual](https://www.qsl.net/yo3dmu/ANT/PstRotatorAz%20User%20Manual.pdf) beschrieben.
+
+### Übernahme der aktuellen QTF
+
+KST4Contest fragt PSTRotator alle zwei Sekunden nach der aktuellen Azimutposition und dem Betriebsmodus. Die zurückgemeldete Azimutposition wird als `actualQTF` übernommen.
+
+Bei aktivierter PSTRotator-Integration ist das QTF-Feld im Hauptfenster deshalb nicht manuell editierbar. Es zeigt die zuletzt von PSTRotator gemeldete Position.
+
+Diese QTF wird unter anderem verwendet für:
+
+- den Richtungsfilter,
+- die Bewertung von Richtungsgelegenheiten,
+- den Priority Score,
+- die Darstellung des Antennensektors auf der Stationskarte,
+- die AP- und Sked-Timeline und
+- die Variable `MYQTF`.
+
+Eine empfangene Rotatorposition ist damit nicht nur eine Anzeige. Sie verändert mehrere Funktionen, die auf der aktuellen Antennenrichtung beruhen.
+
+KST4Contest verwendet derzeit nur den Azimut. Eine Elevationssteuerung oder eine vollständige Azimut-/Elevationsnachführung ist nicht Bestandteil dieser Integration.
+
+### Änderungen übernehmen
+
+Aktivierung, Host und Port werden beim Start der Rotatorverbindung ausgewertet. Nach einer Änderung sollte die ON4KST-Verbindung getrennt und erneut aufgebaut oder KST4Contest neu gestartet werden.
+
+Anschließend **Save Settings** verwenden, damit die Werte auch beim nächsten Programmstart wiederhergestellt werden.
+
+---
+
+## GUI Settings: Hinweise in den Bandspalten
+
+Im Reiter **GUI** lassen sich zwei Zusatzinformationen der Bandspalten ein- oder ausblenden:
+
+- **Show "o" in band columns …** zeigt ein `o`, wenn das vierstellige Großfeld auf dem betreffenden Band bereits gearbeitet wurde. Das Abschalten entfernt keine Daten aus der Datenbank; nur die zusätzliche Anzeige in den Bandspalten wird ausgeblendet. `wkdany` bleibt davon unberührt.
+- **Show "a" in band columns …** unterscheidet ein vollständig neues Rufzeichen von einer Bandmöglichkeit mit einem bereits auf einem anderen Band gearbeiteten Rufzeichen. Ist die Option ausgeschaltet, werden beide Fälle als `B+` dargestellt. Die Bandherleitung selbst ändert sich dadurch nicht.
+
+Änderungen werden in der laufenden Benutzeroberfläche unmittelbar sichtbar. Damit sie nach dem nächsten Programmstart erhalten bleiben, anschließend **Save Settings** verwenden.
+
+![GUI-Einstellungen für die Hinweise in den Bandspalten](client_settings_window_gui.png)
+
+---
+
+## Worked Station Database Settings (Gearbeitete-Stationen-Datenbank)
+
+Die interne SQLite-Datenbank speichert die contestbezogenen Zustände unabhängig von der Datenbank des Logprogramms:
+
+- globaler Worked-Status eines Rufzeichens,
+- Worked-Status pro Band,
+- 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.
+
+Die Schaltfläche **Reset worked, NOT-QRV and grid data...** entfernt sämtliche Worked-Markierungen, NOT-QRV-Tags und gespeicherten Großfelder. Vor dem Reset erscheint eine Sicherheitsabfrage. Die bekannten Rufzeichenzeilen bleiben erhalten; zurückgesetzt werden nur die contestbezogenen Zustände.
+
+Ein Reset ist sinnvoll, wenn bewusst mit einem leeren Conteststand begonnen werden soll oder Testdaten eingelesen wurden. Als tägliche Wartungsmaßnahme ist er nicht vorgesehen.
+
+Anzeige und Herleitung: [Gearbeitete Rufzeichen, neue Bänder und neue Großfelder](de-Funktionen#gearbeitete-rufzeichen-neue-bänder-und-neue-großfelder).
+
+---
+
+## Dark Mode (ab v1.26)
+
+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
+
+**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 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

@@ -0,0 +1,230 @@
+# Log-Synchronisation
+
+> 🇬🇧 [English version](en-Log-Sync) | 🇩🇪 Du liest gerade die deutsche Version
+
+KST4Contest übernimmt gearbeitete Stationen aus dem Logprogramm und stellt daraus den globalen Worked-Status, bandbezogene Worked-Markierungen und – sofern ein Locator übertragen wurde – gearbeitete Großfelder bereit. Dafür gibt es drei Wege: den dateibasierten Simplelogfile-Interpreter, den allgemeinen QSO-UDP-Listener und den eigenen Win-Test-Netzwerk-Listener.
+
+---
+
+![Log-Synchronisation Einstellungsfenster](client_settings_window_logsync.png)
+
+## Methode 1: Universal File Based Callsign Interpreter (Simplelogfile)
+
+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 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.
+
+---
+
+## Methode 2: Netzwerk-Listener für QSO-UDP-Pakete – empfohlen
+
+UCXLog, QARTest, N1MM+ und DXLog.net können beim Speichern eines QSOs ein UDP-Paket senden. KST4Contest empfängt diese Pakete standardmäßig auf Port `12060` und übernimmt das Rufzeichen sowie die enthaltenen Band- und Locatorinformationen.
+
+Liegt eine Bandinformation vor, wird das Rufzeichen für dieses Band als gearbeitet markiert. Enthält das Paket zusätzlich einen gültigen Locator, speichert KST4Contest dessen vierstelliges Großfeld für das betreffende Band. Fehlende Informationen werden nicht aus anderen Feldern geraten.
+
+KST4Contest muss zum Zeitpunkt der Übertragung laufen. Einige Logprogramme können jedoch das vorhandene Log erneut senden: QARTest bietet dafür **Invia log completo**; DXLog.net sendet beim Broadcast des vollständigen Logs `contactreplace`-Pakete, die KST4Contest ebenfalls verarbeitet.
+
+**Standardport:** `12060`
+
+---
+
+## Unterstützte Logprogramme
+
+### UCXLog (DL7UCX)
+
+![UCXLog Konfiguration](ucxlog_logsync.png)
+
+UCXLog sendet QSO-UDP-Pakete und Transceiver-Frequenzpakete.
+
+**Einstellungen in UCXLog:**
+- UDP-Broadcast aktivieren
+- IP-Adresse des KST4Contest-Computers eintragen (bei lokalem Betrieb: `127.0.0.1`)
+- Port: 12060 (Standard)
+
+Grün markierte Felder in den UCXLog-Einstellungen beachten: IP und Port müssen eingetragen werden.
+
+Hinweis für Multi-Setup (2 Computer, 2 Radios, eine KST4Contest-Instanz): Beide Logprogramme müssen die QSO-Pakete an die IP des KST4Contest-Computers senden. Dann ist mindestens eine IP nicht `127.0.0.1`.
+
+### QARTest (IK3QAR)
+
+![QARTest Konfiguration](qartest_logsync.png)
+
+**Besonderheit**: QARTest kann das **vollständige Log** an KST4Contest senden (Schaltfläche „Invia log completo" in den QARTest-Einstellungen). Damit werden auch QSOs erfasst, die vor dem Start von KST4Contest geloggt wurden.
+
+**Einstellungen in QARTest:**
+- UDP-Broadcast und IP/Port wie UCXLog konfigurieren
+- „Invia log completo" für den vollständigen Log-Upload verwenden
+
+*(„Buona funzionalità caro IK3QAR!" – DO5AMF)*
+
+### N1MM+
+
+**Einstellungen in N1MM+:**
+
+In N1MM+ unter `Config → Configure Ports, Mode Control, Winkey, etc. → Broadcast Data`:
+- `Radio Info` aktivieren (für TRX-Sync/QRG)
+- `Contact Info` aktivieren (für QSO-Sync)
+- IP: `127.0.0.1` (oder IP des KST4Contest-Computers)
+- Port: 12060
+
+Für den integrierten DX-Cluster-Server: N1MM+ als DX-Cluster-Client konfigurieren (Server: `127.0.0.1`, Port wie in KST4Contest eingestellt).
+
+### DXLog.net
+
+![DXLog.net Konfiguration](dxlog_net_logsync.png)
+
+**Einstellungen in DXLog.net:**
+- UDP-Broadcast aktivieren
+- IP des KST4Contest-Computers eintragen (grün markierte Felder)
+- Port: 12060
+
+Beim Broadcast des vollständigen Logbuchs verwendet DXLog.net `contactreplace` anstelle von `contactinfo`. KST4Contest verarbeitet beide Pakettypen. Damit können auch ältere QSOs übernommen werden, wenn der vollständige Broadcast ausgelöst wird, während KST4Contest läuft.
+
+### Win-Test
+
+Win-Test wird über einen eigenen UDP-Listener für das native Win-Test-Netzwerkprotokoll angebunden. Dieser Listener ist vom allgemeinen QSO-UDP-Listener auf Port `12060` unabhängig.
+
+#### QSO- und Worked-Synchronisation
+
+Bei einem neuen QSO übernimmt KST4Contest:
+
+- das geloggte Rufzeichen,
+- die native Win-Test-Band-ID und
+- einen gültigen Locator, sofern er im Paket enthalten ist.
+
+Die Band-IDs für 50 und 70 MHz werden ebenso verarbeitet wie die VHF-, UHF- und SHF-Bänder. Das Rufzeichen wird global und auf dem erkannten Band als gearbeitet markiert. Liegt zusätzlich ein Locator vor, wird dessen vierstelliges Großfeld für dieses Band gespeichert.
+
+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.
+
+Die QRG wird in folgender Reihenfolge bestimmt:
+
+1. KST4Contest sucht die neueste, höchstens 30 Minuten alte QRG der Gegenstation auf dem ausdrücklich ausgewählten Band. Dabei werden aktive Varianten desselben Basisrufzeichens gemeinsam ausgewertet.
+2. Fehlt eine solche QRG, wird die eigene QRG der Chat-Kategorie geprüft, in der der Sked angelegt wurde. Sie wird nur verwendet, wenn sie sich auswerten lässt und tatsächlich zum ausgewählten Band gehört.
+3. Kann auf keinem dieser Wege eine passende QRG ermittelt werden, wird kein `ADDSKED` gesendet.
+
+Eine feste Ersatzfrequenz wie `144.300` wird bewusst nicht verwendet. Eine technisch erfolgreiche Übergabe mit falschem Band oder falscher QRG wäre im Contestbetrieb schlechter als eine sichtbar ausgelassene Übergabe.
+
+Der interne Sked bleibt in jedem Fall erhalten. Das gilt auch bei einer ungültigen Broadcast-Adresse, einem Netzwerkfehler oder einem nicht erreichbaren Win-Test-Client.
+
+#### Behandlung von KST-Rufzeichensuffixen
+
+KST-Suffixe kennzeichnen häufig den verwendeten Chat-Login oder ein Band. Sie gehören nicht in jedem Fall zum Logrufzeichen. Für Win-Test entfernt KST4Contest deshalb einen mit `-` abgetrennten KST-Suffix, erhält aber portable und internationale Rufzeichenbestandteile:
+
+| Rufzeichen im KST-Chat | Übergabe an Win-Test |
+|---|---|
+| `DN9APW-2` | `DN9APW` |
+| `9A0BB-70` | `9A0BB` |
+| `EA5/G8MBI/P-70` | `EA5/G8MBI/P` |
+| `DN9APW-2/P` | `DN9APW/P` |
+
+Innerhalb von KST4Contest bleibt das vollständige Rufzeichen erhalten. Timeline, Reminder-PMs und Chat-Kategorie beziehen sich weiterhin auf den konkret ausgewählten Login.
+
+#### Mode, Zeitpunkt und Notizen
+
+Der Mode wird beim Anlegen des Skeds ausdrücklich als `SSB` oder `CW` gewählt. Eine automatische Ableitung aus der QRG findet nicht statt, weil eine begrenzte Liste angenommener Bandsegmente nicht alle unterstützten VHF-, UHF- und SHF-Bänder zuverlässig abbilden kann.
+
+KST4Contest überträgt den tatsächlichen Sked-Zeitpunkt ohne einen zusätzlichen Minutenversatz. Die Notizen enthalten – soweit bekannt – Locator und QTF sowie den Hinweis, dass der Sked über KST4Contest angelegt wurde.
+
+Für die Übergabe sendet KST4Contest die Win-Test-Pakete `LOCKSKED`, `ADDSKED` und `UNLOCKSKED`.
+
+![Von KST4Contest an Win-Test übergebener Sked](wintest_sked_handover.png)
+
+#### Einstellungen
+
+Im Reiter **Log sync**:
+
+- `Receive Win-Test network based UDP log messages`
+- `UDP-Port for Win-Test listener`, standardmäßig `9871`
+- `KST station name in Win-Test network (src of SKED packets)`
+- `Win-Test network broadcast address`
+
+Im Reiter **TRX sync**:
+
+- `Win-Test STATUS QRG Sync`
+- `Use pass frequency from Win-Test STATUS`
+- `Win-Test station name filter`
+
+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)
+
+
+## TRX-Frequenz-Synchronisation
+
+Neben der QSO-Synchronisation übertragen UCXLog und andere Programme auch die **aktuelle Transceiverfrequenz** via UDP. KST4Contest verarbeitet diese Information und stellt sie als Variable `MYQRG` bereit.
+
+![FrequenzButtons](qrg_buttons.png)
+
+**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
+- Win-Test STATUS-Paket (optional, konfigurierbar im Reiter „TRX-Synchronisation" unter „Win-Test STATUS QRG Sync")
+- Manuelle Eingabe im QRG-Feld
+
+> **Hinweis für Multi-Setup**: Bei zwei Logprogrammen an zwei Computern sollte nur **eines** die Frequenzpakete senden. KST4Contest kann nicht zwischen den Quellen unterscheiden und verarbeitet alle eingehenden Pakete.
+
+---
+
+## Multi-Setup: 2 Radios, 2 Computer
+
+Für DM5M-typische Setups (2 Radios, 2 Computer, eine KST4Contest-Instanz oder zwei separate):
+
+**Variante A – Eine gemeinsame KST4Contest-Instanz:**
+- Beide Logprogramme senden QSO-Pakete an die IP des KST4Contest-Computers
+- Nur ein Logprogramm sendet Frequenzpakete (empfohlen: das VHF-Logprogramm)
+
+**Variante B – Zwei separate KST4Contest-Instanzen (empfohlen):**
+- Jedes Logprogramm kommuniziert mit seiner eigenen KST4Contest-Instanz via `127.0.0.1`
+- Zwei separate Chat-Logins
+- Bessere Trennung und weniger Konflikte
+
+---
+
+## Interne Datenbank
+
+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:
+
+| Quelle | Rufzeichen global | Bandbezogen | Großfeld |
+|---|---:|---:|---:|
+| Simplelogfile | ja | nein | nein |
+| 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 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

@@ -0,0 +1,370 @@
+# Makros und Variablen
+
+> 🇬🇧 [English version](en-Macros-and-Variables) | 🇩🇪 Du liest gerade die deutsche Version
+
+KST4Contest unterscheidet zwischen Shortcut-Schaltflächen, Text-Snippets und Variablen. Shortcuts und Snippets enthalten vorbereitete Texte. Variablen ergänzen Informationen, die sich während des Betriebs ändern können.
+
+Der eingefügte Text bleibt im Sendfeld sichtbar und kann vor dem Senden geprüft oder geändert werden.
+
+---
+
+## Überblick
+
+| Mechanismus | Aufruf | Verwendung |
+|---|---|---|
+| **Shortcut** | Schaltfläche oberhalb des Sendfeldes | Fügt einen konfigurierten Text in das Sendfeld ein |
+| **Snippet** | Kontextmenü oder `Ctrl+1` bis `Ctrl+0` | Bereitet einen Text für die ausgewählte Station vor |
+| **Variable** | Platzhalter innerhalb eines Nachrichtentextes | Fügt aktuelle QRG-, Locator-, Richtungs-, Stations- oder AirScout-Informationen ein |
+
+Shortcuts und Snippets speichern Texte. Variablen liefern die dazugehörigen aktuellen Werte.
+
+Ein Shortcut wie
+
+```text
+pse sked?
+```
+
+fügt immer denselben Text ein. Ein Shortcut mit
+
+```text
+pse call me at MYQRGSHORT
+```
+
+verwendet dagegen die QRG, die beim Anklicken des Shortcuts aktuell in KST4Contest hinterlegt ist.
+
+---
+
+## Shortcut-Schaltflächen
+
+Shortcuts werden unter **Preferences → Shortcut Settings** konfiguriert.
+
+![Konfiguration der Shortcut-Schaltflächen und Text-Snippets](client_settings_window_shortcuts.png)
+
+Jeder Eintrag erzeugt eine Schaltfläche im Hauptfenster. Ein Klick hängt den konfigurierten Text an den vorhandenen Inhalt des Sendfeldes an. Ein bereits vorbereiteter Nachrichtentext wird dabei nicht gelöscht.
+
+Enthält der Shortcut eine Variable, wird sie beim Einfügen aufgelöst. Aus
+
+```text
+pse call me at MYQRGSHORT
+```
+
+kann beispielsweise werden:
+
+```text
+pse call me at 144.388
+```
+
+Die exakten Einträge `MYQRG` und `SECONDQRG` werden als QRG-Schaltflächen hervorgehoben. Sie fügen die aktuelle QRG der ersten beziehungsweise zweiten Chat-Kategorie ein.
+
+Auch der Shortcut
+
+```text
+/SETNAME MYQRG
+```
+
+wird hervorgehoben. Beim Anklicken wird `MYQRG` aufgelöst und der daraus entstehende Serverbefehl in das Sendfeld übernommen. Der Befehl wird nicht automatisch gesendet.
+
+Die Reihenfolge der Einträge in den Einstellungen bestimmt die Reihenfolge der Schaltflächen im Hauptfenster. Bearbeitung, Sortierung und Speicherung sind unter [Konfiguration – Shortcut Settings](de-Konfiguration#shortcut-settings-schnellzugriff-schaltflächen) beschrieben.
+
+---
+
+## Text-Snippets
+
+Snippets werden unter **Preferences → Snippet Settings** konfiguriert. Sie sind vor allem für wiederkehrende Nachrichten an eine bestimmte Station vorgesehen.
+
+Snippets können aufgerufen werden:
+
+- per Rechtsklick auf eine Station in der Benutzerliste,
+- per Rechtsklick auf eine öffentliche Nachricht,
+- per Rechtsklick auf eine Privatnachricht oder
+- mit `Ctrl+1` bis `Ctrl+0` für die ersten zehn Einträge der Snippet-Liste.
+
+### Verwendung über das Kontextmenü
+
+Die Auswahl einer Station oder Nachricht bereitet normalerweise bereits den passenden `/cq`-Empfänger im Sendfeld vor. Das anschließend im Kontextmenü ausgewählte Snippet wird an diesen Text angehängt.
+
+Ein bereits vorhandener Nachrichtentext kann dadurch gezielt erweitert werden.
+
+### Verwendung über die Tastatur
+
+Ein mit `Ctrl+1` bis `Ctrl+0` aufgerufenes Snippet ersetzt den bisherigen Inhalt des Sendfeldes durch eine vollständig adressierte Nachricht:
+
+```text
+/cq RUFZEICHEN Snippet-Text
+```
+
+Das vollständige sichtbare Rufzeichen einschließlich eines vorhandenen Suffixes bleibt erhalten. Für die ausgewählte Station `9A0BB-70` kann beispielsweise entstehen:
+
+```text
+/cq 9A0BB-70 pse ur qrg?
+```
+
+KST4Contest behält intern auch die Chat-Kategorie der ausgewählten Station bei. Ein Snippet für `9A0BB-70` wird deshalb nicht versehentlich über die andere aktive Chat-Kategorie gesendet.
+
+Ist keine Station ausgewählt oder existiert für die gedrückte Tastenkombination kein Snippet, wird nichts eingefügt.
+
+Der vorbereitete Text wird nicht automatisch versendet:
+
+- `Enter` oder **TX** sendet die Nachricht.
+- `Esc` leert das Sendfeld.
+
+### Zuordnung der Tastenkombinationen
+
+Die Zuordnung folgt der Reihenfolge in der Snippet-Liste:
+
+| Tastenkombination | Verwendeter Eintrag |
+|---|---:|
+| `Ctrl+1` | erster Eintrag |
+| `Ctrl+2` | zweiter Eintrag |
+| … | … |
+| `Ctrl+9` | neunter Eintrag |
+| `Ctrl+0` | zehnter Eintrag |
+
+Die Tastenkombinationen können auch einer programmierbaren Makro-Tastatur zugewiesen werden. Die Idee zu dieser Bedienung stammt von IU3OAR, Gianluca Costantino.
+
+KST4Contest legt keine verbindliche Liste von Standard-Snippets fest. Welche Texte sinnvoll sind, hängt vom eigenen Contestbetrieb und der verwendeten Betriebsart ab.
+
+Bearbeitung, Sortierung und Speicherung sind unter [Konfiguration – Snippet Settings](de-Konfiguration#snippet-settings-text-snippets) beschrieben.
+
+---
+
+## Variablen
+
+Variablen sind reservierte Platzhalter innerhalb eines Nachrichtentextes. Sie müssen in Großbuchstaben geschrieben werden und unterscheiden zwischen Groß- und Kleinschreibung.
+
+Variablen können verwendet werden in:
+
+- Shortcuts,
+- Snippets,
+- Beacon-Texten und
+- direkt eingegebenen oder eingefügten Nachrichtentexten.
+
+Bei einem Shortcut oder Snippet werden die Variablen bereits beim Einfügen in das Sendfeld aufgelöst. Direkt in das Sendfeld geschriebene oder eingefügte Variablen werden unmittelbar vor der Übernahme in die Sendewarteschlange aufgelöst.
+
+Stationsbezogene Variablen verwenden immer die aktuell ausgewählte Station. KST4Contest leitet diese Station nicht aus einem von Hand in den Nachrichtentext geschriebenen `/cq`-Empfänger ab.
+
+---
+
+## Globale Variablen
+
+Globale Variablen benötigen keine ausgewählte Gegenstation.
+
+| Variable | Ersetzter Wert |
+|---|---|
+| `MYQRG` | aktuelle QRG der ersten beziehungsweise primären Chat-Kategorie |
+| `MYQRGSHORT` | erste sieben Zeichen von `MYQRG` |
+| `SECONDQRG` | aktuelle QRG der zweiten Chat-Kategorie |
+| `MYLOCATOR` | vollständiger Locator der eigenen Station |
+| `MYLOCATORSHORT` | erste vier Zeichen des eigenen Locators |
+| `MYCALL` | konfiguriertes eigenes Rufzeichen |
+| `MYQTF` | aktuelle Antennenrichtung als numerischer Wert in Grad |
+
+Beispiel:
+
+```text
+cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
+```
+
+kann aufgelöst werden zu:
+
+```text
+cq at 144.388, qtf 135, loc JO51IJ
+```
+
+### QRG-Variablen
+
+`MYQRG` enthält die QRG der ersten Chat-Kategorie. Der Wert kann aus der TRX-Synchronisation des Logprogramms oder aus dem manuell bearbeiteten QRG-Feld stammen.
+
+`MYQRGSHORT` verwendet denselben Wert, beschränkt ihn aber auf die ersten sieben Zeichen:
+
+```text
+144.388.03 → 144.388
+```
+
+`SECONDQRG` enthält die QRG der zweiten Chat-Kategorie. Die Auswahl einer Station aus dem zweiten Chat verändert die Bedeutung von `MYQRG` nicht. Soll ausdrücklich die QRG der zweiten Kategorie eingesetzt werden, muss `SECONDQRG` verwendet werden.
+
+### Locator-Variablen
+
+`MYLOCATOR` übernimmt den vollständigen konfigurierten Locator der eigenen Station:
+
+```text
+JO51IJ
+```
+
+`MYLOCATORSHORT` verwendet nur die ersten vier Zeichen:
+
+```text
+JO51
+```
+
+### MYQTF
+
+`MYQTF` übernimmt die aktuelle, in KST4Contest hinterlegte Antennenrichtung als numerischen Winkel in Grad.
+
+Beispiel:
+
+```text
+ant MYQTF deg
+```
+
+kann werden zu:
+
+```text
+ant 135 deg
+```
+
+Die Richtung wird nicht in Himmelsrichtungen wie `north`, `north-east` oder `south-west` umgewandelt.
+
+---
+
+## Variablen für die ausgewählte Station
+
+Diese Variablen benötigen eine ausgewählte Gegenstation:
+
+| Variable | Ersetzter Wert |
+|---|---|
+| `QRZNAME` | Name der ausgewählten Station oder deren vollständiges Rufzeichen, wenn kein Name verfügbar ist |
+| `FIRSTAP` | Beschreibung und Ankunftszeit des ersten von AirScout gemeldeten Flugzeugs |
+| `SECONDAP` | Beschreibung und Ankunftszeit des zweiten von AirScout gemeldeten Flugzeugs |
+
+Beispiel:
+
+```text
+Hi QRZNAME, FIRSTAP, pse lsn at MYQRGSHORT
+```
+
+kann werden zu:
+
+```text
+Hi David, a very big AP in 2 min, pse lsn at 144.388
+```
+
+### QRZNAME
+
+KST4Contest verwendet den Namen aus dem Namensfeld der ausgewählten Station. Ist dort kein verwendbarer Name vorhanden, wird stattdessen das vollständige sichtbare Rufzeichen eingesetzt.
+
+### FIRSTAP
+
+Ist ein AirScout-Kandidat verfügbar, enthält `FIRSTAP` dessen Beschreibung und die voraussichtliche Zeit bis zum Reflexionsfenster.
+
+Beispiel:
+
+```text
+a very big AP in 2 min
+```
+
+Ist für die ausgewählte Station kein Flugzeug verfügbar, wird eingesetzt:
+
+```text
+no ap available
+```
+
+### SECONDAP
+
+`SECONDAP` verwendet den zweiten verfügbaren AirScout-Kandidaten.
+
+Beispiel:
+
+```text
+Next big AP in 9 min
+```
+
+Ist kein zweiter Kandidat vorhanden, wird `SECONDAP` durch einen leeren Text ersetzt.
+
+### Verhalten ohne ausgewählte Station
+
+Ist keine Station ausgewählt, bleiben `QRZNAME`, `FIRSTAP` und `SECONDAP` im Text sichtbar. KST4Contest entfernt diese Platzhalter nicht automatisch.
+
+Ein sichtbarer, nicht aufgelöster Platzhalter ist eindeutiger als eine formal vollständige Nachricht, in der unbemerkt eine wichtige Information fehlt. Vor dem Senden sollte deshalb geprüft werden, ob die richtige Station ausgewählt ist und alle benötigten Variablen aufgelöst wurden.
+
+---
+
+## Variablen im Beacon
+
+Ein öffentlicher Beacon besitzt keine ausgewählte Gegenstation. Deshalb können dort ausschließlich globale Variablen verwendet werden:
+
+- `MYQRG`
+- `MYQRGSHORT`
+- `SECONDQRG`
+- `MYLOCATOR`
+- `MYLOCATORSHORT`
+- `MYCALL`
+- `MYQTF`
+
+`QRZNAME`, `FIRSTAP` und `SECONDAP` dürfen in einem Beacon nicht verwendet werden.
+
+Eine mögliche Vorlage für die erste Chat-Kategorie ist:
+
+```text
+calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
+```
+
+Verwendet die zweite Chat-Kategorie eine andere QRG, muss deren Vorlage `SECONDQRG` enthalten:
+
+```text
+calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
+```
+
+Die globalen Variablen werden bei jedem Timer-Lauf erneut ausgewertet. Eine inzwischen vom Logprogramm aktualisierte QRG kann dadurch bereits in der nächsten Beacon-Nachricht erscheinen.
+
+Der vollständig aufgelöste Beacon-Text:
+
+- muss mindestens ein gültiges Zeichen enthalten,
+- darf höchstens 120 Zeichen lang sein,
+- darf das Protokoll-Trennzeichen `|` nicht enthalten und
+- darf keine Zeilenumbrüche enthalten.
+
+Ist der Text beim vorgesehenen Versand leer oder ungültig, wird der betreffende Beacon-Lauf ausgelassen.
+
+Intervall, Aktivierung und Verhalten beider Kategorien sind unter [Konfiguration – Beacon Settings](de-Konfiguration#beacon-settings-automatischer-beacon) beschrieben.
+
+---
+
+## Beispiel für einen Snippet-Workflow
+
+Als erstes Snippet ist beispielsweise konfiguriert:
+
+```text
+Hi QRZNAME, pse sked? I call at MYQRGSHORT
+```
+
+Der Ablauf kann dann folgendermaßen aussehen:
+
+1. In der Benutzerliste wird `DL1ABC-432` ausgewählt.
+2. `Ctrl+1` wird gedrückt.
+3. KST4Contest bereitet die adressierte Nachricht vor und löst die Variablen auf.
+4. Der vollständige Text wird im Sendfeld geprüft.
+5. Falls die Gegenstation eine andere QRG vorgeschlagen hat, wird der Text entsprechend angepasst.
+6. `Enter` oder **TX** sendet die Nachricht.
+
+Das Ergebnis kann beispielsweise lauten:
+
+```text
+/cq DL1ABC-432 Hi Peter, pse sked? I call at 432.088
+```
+
+Das vollständige Rufzeichen bestimmt den Empfänger. Die ausgewählte Chat-Kategorie bestimmt den Versandweg. Die Variablen verringern die wiederholte Texteingabe, entscheiden aber nicht, ob die eingesetzten Informationen noch zur aktuellen Betriebssituation passen.
+
+---
+
+## Grenzen der Variablenauflösung
+
+Variablen geben den Informationsstand wieder, den KST4Contest im Moment der Auflösung besitzt.
+
+Dabei ist insbesondere zu beachten:
+
+- Eine vom Logprogramm gelieferte QRG kann sich inzwischen geändert haben.
+- Eine manuell eingetragene QRG bleibt aktiv, bis sie erneut geändert wird.
+- `MYQRG` bleibt die QRG der primären Kategorie, auch wenn eine Station aus der zweiten Kategorie ausgewählt wurde.
+- Die ausgewählte Station kann von einem manuell eingegebenen `/cq`-Empfänger abweichen.
+- AirScout kann für die betreffende Strecke keine aktuellen Flugzeugdaten liefern.
+- Stationsbezogene Variablen bleiben sichtbar, wenn keine Station ausgewählt ist.
+- 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

@@ -0,0 +1,124 @@
+# AirScout Integration
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-AirScout-Integration)
+
+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.
+
+---
+
+## Downloading AirScout
+
+Download AirScout from:
+- http://airscout.eu/index.php/download
+
+---
+
+## Aircraft Data Feeds (ADS-B)
+
+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
+
+An account is required for this service. Please consider donating to Thomas – the server costs are not free!
+
+---
+
+## Setting Up 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.
+
+![AirscoutStep1](as_plane_feed_1.png)
+![AirscoutStep2](as_plane_feed_2.png)
+
+3. Test the connection.
+
+### Step 2: Enable UDP Communication for KST4Contest
+
+In AirScout, enable the UDP interface:
+
+- Activate the corresponding checkbox in the AirScout settings (only one checkbox needed).
+- Do not change the default ports unless there is a specific reason.
+
+### Step 3: KST4Contest Settings
+
+In KST4Contest Preferences → **AirScout Settings**:
+- Enable AirScout communication
+- Leave IP and port at their default values (unless changed)
+
+![AirscoutStep3](as_plane_feed_3.png){ width=85% }
+
+
+
+---
+
+## Communication Between KST4Contest and AirScout (from v1.263)
+
+**Improvement in v1.263**: KST4Contest now only sends stations to AirScout whose QRB (distance) is less than the configured **maximum QRB**. The query interval has been extended from 12 seconds to **60 seconds**.
+
+**Benefits:**
+- Significantly less computation load for AirScout
+- Significantly less message traffic
+- The tracking issue with the "Show Path in AirScout" button is greatly improved
+- Less overall CPU usage
+
+Additionally: The name of the KST4Contest client and AirScout server was previously hardcoded (`KST` and `AS`). From v1.263, the names configured in the Preferences are used.
+
+---
+
+## Multiple KST4Contest Instances and AirScout
+
+> **Note**: If multiple KST4Contest instances are running simultaneously and AirScout communication is enabled on both, AirScout will respond **to both instances**.
+
+This is not a problem if:
+- Both instances use the same locator, **or**
+- Both instances have different login callsigns.
+
+Otherwise, it may result in incorrect AP data.
+
+---
+
+## AP Column in the User List
+
+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 | 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**.
+
+## 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 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 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

@@ -0,0 +1,485 @@
+# Changelog
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Changelog)
+
+Version history of KST4Contest / PraktiKST.
+
+Published Stable versions and their application packages are available under [GitHub Releases](https://github.com/praktimarc/kst4contest/releases). This page also lists changes from the current development version where they have already been implemented and tested.
+
+---
+
+## 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.
+
+### Added
+
+- **Visible ON4KST connection state:** A compact `LINK` indicator in the main window displays the actual state of the ON4KST connection. Green means fully authenticated and synchronised, yellow indicates connection setup or synchronisation, and red indicates a lost connection, an error or the delay before the next connection attempt.
+
+- **Shared band-opportunity calculation:** A central `BandOpportunityResolver` evaluates recent QRGs, band designators in station names, active callsign variants, Worked information and NOT-QRV marks. The user list, **New bands**, band-upgrade hint, Priority Score, station map and automatic band selection now use the same basis.
+
+- **Extended band status display:** The band columns now distinguish:
+  - `X` for worked on this band,
+  - `a` for an offered and unworked band of a completely new callsign,
+  - `B+` for an offered and unworked band of a callsign already worked elsewhere, and
+  - `o` for a locator square already worked on this band.
+
+  The codes can be combined, for example as `ao` or `B+o`. The additional `a` and `o` indicators can be hidden separately in the GUI settings.
+
+- **50 and 70 MHz support:** Both bands are available in station settings, Worked and NOT-QRV handling, the user list, filters, the internal database, UCXLog processing and the Win-Test listener. Existing databases are extended with the required columns.
+
+- **Global message tabs:** Public messages, ON4KST DX cluster messages and directed messages between other stations can be displayed directly in the main window. The existing separate monitor window remains available and uses the same underlying message stores.
+
+- **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.
+
+- **Hideable path analysis:** The terrain profile and analysis section of the station map can be hidden completely. The selected state is stored and restored at the next application start.
+
+### Changed
+
+- **Session-based ON4KST connection lifecycle:** Each socket, reader, writer, message bus and queue now belongs to an explicitly identified connection session. Delayed threads from an obsolete connection can therefore no longer process data or close its replacement. `ONLINE` is reported only after the login has been accepted and all requested user lists have been received. Connection setup, login and synchronisation use bounded timeouts, while heartbeats, missing inbound traffic, EOF and read or write failures trigger controlled reconnect attempts with backoff where appropriate.
+
+- **Validated ON4KST protocol commands:** Outgoing frames are built centrally and checked for valid categories, locators and prohibited frame delimiters. Because ON4KST maintains one locator per TCP session, the main locator is used for both chat categories and a conflicting secondary configuration is logged instead of sending contradictory commands to the server.
+
+- **More precise QRG recognition:** Complete and relative frequency references continue to be recognised. Bare three-digit numbers are treated as QRGs only when a frequency context is available. Signal reports, band designators and unrelated numbers therefore produce fewer false frequencies.
+
+- **Station-specific frequency context:** For relative QRGs, KST4Contest first uses a band context for the same station which is no more than 30 minutes old. The globally configured fallback band is used only when this context is unavailable.
+
+- **Fallback band dropdown:** The global fallback can only be selected from supported band values. It applies to the complete QRG parser, not merely to DX cluster spots.
+
+- **Consistent QRG formatting:** Frequencies are displayed with at least three decimal places in the user list and message tables.
+
+- **Band-aware AirScout and path calculations:** KST4Contest derives a realistic frequency for each station from its current QRG and known band information. AirScout receives canonical band values. The temporary 430 MHz fallback has been replaced with 432 MHz.
+
+- **Shared propagation-frequency selection:** AirScout, **Calc selected** and the station-map path analysis use the same `PropagationFrequencyResolver`. A band selected explicitly in the Reachability dropdown is respected for manual calculations.
+
+- **Separate callsign variants:** Active chat members are distinguished by their complete callsign, including suffix, and by chat category. `DN9APW`, `DN9APW-2` and similar logins therefore remain separate message targets.
+
+- **Shared base-callsign information:** Worked flags, NOT-QRV information and Priority Scores continue to be evaluated across variants of the same base callsign. Separate message targets no longer result in contradictory Worked information.
+
+- **Corrected Priority Score eligibility:** Stations without a common available band, or with an overriding NOT-QRV mark, are no longer offered as priority candidates. An open band at a station already worked elsewhere can receive a separate Priority Boost.
+
+- **Extended sked creation:** The band is selected from those enabled locally. `SSB` or `CW` is selected explicitly for the Win-Test handover instead of attempting to infer the mode unreliably from the band.
+
+- **More precise Win-Test sked handover:** The QRG must belong to the selected band. Visible KST suffixes are removed for the logging target while portable callsign components are preserved. `ADDSKED` timestamps are generated correctly. A failed handover does not remove the internal KST4Contest sked.
+
+- **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 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.
+
+- **Improved message tables:** Truncated messages show their complete text in a tooltip. Recognised web addresses can be opened in the system browser.
+
+- **More compact filter bar:** Filters retain their compact arrangement at normal widths and wrap only when the available space is genuinely insufficient. This allows the centre divider to be moved further to the right.
+
+- **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
+
+- **Reliable initial user list:** Invalid or incomplete `UA0` member records are rejected and logged individually without preventing alphabetically following members from being processed. Valid entries are staged per category and published as one complete snapshot when the first corresponding `UE` end marker is received.
+
+- **User list disappearing after login:** ON4KST may send additional `UE` frames for the same category after name, state or other live updates. Repeated end markers are now detected and ignored so that an already populated user list cannot be replaced by an empty snapshot.
+
+- **Failed initial connection and lost sockets:** An unavailable server during startup no longer sends KST4Contest into an endless or busy-wait loop. The user interface remains responsive and further attempts use bounded reconnect backoff. Sockets closed by the server, or connections without inbound traffic for an excessive period, are also detected reliably.
+
+- **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.
+
+- **Messages to callsigns with suffixes:** Several active variants of the same base callsign no longer overwrite each other. This resolves [Issue #73](https://github.com/praktimarc/kst4contest/issues/73).
+
+- **DX cluster locators:** The reporting and reported station no longer receive the same locator accidentally. This resolves [Issue #48](https://github.com/praktimarc/kst4contest/issues/48).
+
+- **Worked state in “QSO of the other”:** The Worked columns again use the correct transmitting and receiving station.
+
+- **Missing SECONDAP data:** A missing second aircraft-scatter opportunity no longer produces an invalid text selection and JavaFX exception when the field is edited.
+
+- **Historical callsigns:** Highlighting or selecting a callsign which is no longer present in the active user list no longer causes an exception.
+
+- **Win-Test sked time and callsign handling:** Timestamps, band-to-QRG assignment, KST suffixes and portable callsigns are handled correctly.
+
+- **Filter reset:** All filter predicates are actually removed, and the visible button state again matches the effective filter state.
+
+### Documentation and packaging
+
+- The German and English manuals have been systematically checked against the source code, extended and supplied with current screenshots. The documentation now describes not only the controls, but also how information is derived and where the limits of a result lie.
+
+- The AUR provides `kst4contest-bin`, `kst4contest` and `kst4contest-git` for Arch Linux.
+
+- The download page distinguishes between Stable, Beta and Nightly and offers only packages which actually belong to the corresponding channel.
+
+- Nightly packages are built automatically from the current `main` branch. Stable and Beta releases use predictable asset names for the supported platforms.
+
+- **Signed and notarized macOS packages:** The DMG files for Apple Silicon and Intel are signed with an Apple Developer ID and notarized by Apple, with the notarization ticket stapled into the DMG. The first launch now works by double-clicking, without the previous detour through **Open** in the context menu, and the check also succeeds without an internet connection. This applies to Nightly, Beta and Stable packages alike. The Windows packages remain unsigned.
+
+- **Correct bundle identifier and version on macOS:** The application now identifies itself as `de.x08.KST4Contest` rather than `kst4contest.view`, and carries its actual version number in the bundle. Previously every release reported version `1.0` in Finder's **Get Info** panel. Existing settings are unaffected, because KST4Contest stores its data in `~/.praktiKST/` rather than keying it to the bundle identifier.
+
+### Known limitations
+
+- The active terrain provider uses Open-Meteo with Copernicus GLO-90 data and no more than 100 elevation samples per path.
+
+- The atmospheric K factor is currently fixed at `4/3`.
+
+- An antenna height of 10 metres above ground is assumed for the remote station.
+
+- Aircraft-scatter information from AirScout and the terrain analysis in the station map remain separate assessments.
+
+- 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)
+
+**Hotfix for text input and focus handling**
+
+### Fixed
+
+- The message input field was unexpectedly cleared after some time or during particular UI updates.
+- Filtering or selecting a station could move the input focus back to the send field unintentionally.
+
+The corrected version is available as [Release v1.41.1](https://github.com/praktimarc/kst4contest/releases/tag/v1.41.1).
+
+---
+## v1.41.0 (2026-07-01)
+
+**Station map, bounded message stores and screen-aware main window**
+
+### Added
+
+- **Station map:** An interactive OpenStreetMap-based map displays active chat members for which a usable locator is available.
+
+- **Antenna sector and connection line:** The map shows the current local QTF, configured antenna beamwidth, maximum QRB and the path to the selected station.
+
+- **Maidenhead grid:** A locator grid adapted to the current zoom level provides geographical orientation.
+
+- **Terrain profile:** An elevation profile for a selected station can be requested from the Open-Meteo Elevation API. The active source uses Copernicus GLO-90 data and no more than 100 evenly distributed samples.
+
+- **Geometrical path analysis:** The calculation includes line of sight, Earth curvature using `k = 4/3`, radio and terrain horizons, the first Fresnel zone and a rough obstruction estimate.
+
+- **Local map proxy:** Leaflet is bundled with the application. Map tiles are loaded through a local proxy so that no external JavaScript library is required at runtime. An Internet connection is still required for OpenStreetMap tiles and online elevation data.
+
+### Changed
+
+- **Bounded message stores:** The global chat-message list is reduced from more than 30,000 entries to 25,000. The separate DX cluster store is reduced from more than 10,000 entries to 8,000.
+
+- **Screen-aware startup size:** The main window is checked against the visible area of the primary screen at startup and reduced or repositioned when necessary.
+
+- **More compact user interface:** Several UI sections were adapted for smaller displays and movable dividers.
+
+### Scope of the map function
+
+The station map and AirScout may refer to the same remote station, but their calculations remain separate. Aircraft used by AirScout are not included in the terrain profile.
+
+Classes for Copernicus GLO-30, offline DEM imports and additional terrain providers existed in the source tree but were not part of the active calculation chain in v1.41. The elevation source actually used was Open-Meteo based on Copernicus GLO-90.
+
+---
+
+
+## v1.40 (2026-02-16)
+**Major Feature Release: Score System, AP Timeline, Win-Test, PSTRotator**
+
+**New:**
+- **Chatmember Score System**: Every chat member is automatically scored based on antenna direction, activity time, message count, active bands, frequencies, sked direction (degrees), and other factors. Top candidates are highlighted in a dedicated list.
+- **AP Timeline**: For each minute of possible aircraft arrival, up to 4 highly-scored stations are shown that should be workable. Aircraft with the highest potential are preferred over the fastest arrival. Chat members whose antenna is not pointing towards you are shown transparently.
+- **Win-Test Support** (Beta since v1.31, now fully configurable): Log synchronisation, frequency parsing and **sked handover via UDP** fully integrated. Can be enabled/disabled in Preferences.
+- **PSTRotator Interface** (Beta since v1.31, now fully configurable): Rotator position updates directly from KST4Contest. Can be enabled/disabled in Preferences.
+- **QSO Sniffer**: Messages from configurable callsign lists are automatically forwarded to the PM window.
+- **Band Alert for logged stations**: When a station is logged, a hint appears if that station has another active band that you are also QRV on.
+- **Sked Reminder ALERT**: A sked alarm with automatic messages in configurable intervals (2+1 / 5+2+1 / 10+5+2+1 minutes before the sked) can be set up for each chat member, plus acoustic and visual notification.
+- **Load chat history on startup**: Chat server history is loaded on connect to immediately see active members and recent messages.
+- **Skedfail button**: In the FurtherInfo panel, a sked failure can be marked for a chat member, which lowers their priority score.
+
+**Changed:**
+- AP notes added to internal DX cluster spots.
+- Chat member table scrolling follows the current message selection automatically.
+- Generic auto-reply and QRG auto-reply now fire a maximum of once every 45 seconds per callsign (prevents spam and message ping-pong).
+- New saveable settings: ServerDNS/Port, PSTRotator interface, Win-Test interface, callsign sniffer, Dark Mode on by default.
+- Date column removed from chat table (time only – saves space).
+
+**Fixed:**
+- User list now automatically sorted on every new member sign-on.
+- Posonpill messages now terminate exactly one client instance (no longer affects all instances or wtKST).
+- wtKST: crash on KST4Contest disconnection fixed.
+- Multiple issues with callsign suffixes like `/p`, `-2`, etc. fixed throughout.
+- `QTFDefault` was not saved correctly → fixed.
+- AirScout watchlist (ASWATCHLIST) was not being updated → fixed.
+- Dark Mode: QRG fields not displayed at full size → fixed.
+- Version number display corrected.
+
+---
+
+## v1.31 (2025-12-13)
+**Win-Test + PSTRotator Beta, QSO Sniffer, DNS Hotfix**
+
+**New:**
+- **Win-Test support** (Beta, not yet deactivatable): Log synchronisation and frequency parsing.
+- **PSTRotator support** (Beta, not yet deactivatable).
+- **QSO Sniffer**: Messages from configurable callsigns are forwarded to the PM window.
+
+**Changed:**
+- **DNS server changed**: From `www.on4kst.info` to `www.on4kst.org` (hotfix). The DNS server is now configurable in Preferences.
+
+**Fixed:**
+- Endless loop in error case freezes the client → fixed.
+
+---
+
+## v1.266 (2025-10-03)
+**AirScout Fix for Callsigns with Suffix**
+
+**Fixed:**
+- AirScout interface did not work when the login callsign contained a suffix (e.g. `9A1W-2`). AirScout cannot handle this format – only the base callsign without suffix is now passed to AirScout.
+
+*(Bug reported and tested by 9A2HM / Kreso – many thanks!)*
+
+---
+
+## v1.265 (2025-09-28)
+**Direction Buttons Stay Coloured When Active**
+
+**Fixed:**
+- Direction buttons (N / NE / E etc.) now keep their highlight colour when activated, making the active state immediately visible.
+
+---
+
+## v1.264 (2025-08-02)
+**Simplelogfile: Improved Callsign Recognition**
+
+**Fixed:**
+- Callsigns like `S53CC`, `S51A`, etc. were not being marked as worked in the SimpleLogFile interpreter → recognition pattern improved.
+
+*(Bug reported by Boris, S53CC – thank you!)*
+
+---
+
+## v1.263 (2025-06-08)
+**AirScout Communication and Login Name**
+
+**Changed:**
+- AirScout communication fundamentally revised: Only stations with QRB < max-QRB are now sent to AirScout.
+- Query interval extended from 12 seconds to **60 seconds**.
+- Significantly less computation load and message traffic → more stable AirScout tracking.
+- Name of the AS client and AS server is now configurable from the Preferences (was previously hardcoded to "KST" / "AS").
+
+**Fixed:**
+- "Track in AirScout" button was very sluggish → greatly improved by new communication logic.
+- Name in chat is now saveable (bug fixed).
+- Visual corrections before and after login.
+- Bug fixed that was reported by 9A2HM (Kreso).
+
+---
+
+## v1.262 (2025-05-21)
+**Freeze Fix for Early Message Delivery**
+
+**Fixed:**
+- ON4KST sometimes delivers messages before login is complete. This caused errors in the message processing engine → now fixed.
+
+---
+
+## v1.26 (2025-05)
+**Multi-Channel Login and Dark Mode**
+
+**New:**
+- **Dark Mode**: Toggle via `Window → Use Dark Mode`.
+- **Multi-channel login**: Simultaneous login to two chat categories.
+- **Opposite station multi-callsign login tagging**: Support for stations with multiple callsigns.
+
+**Changed:**
+- Colouring mechanism revised: Colours can now be customised via CSS.
+
+**Fixed:**
+- Station tagging completely revised and corrected.
+
+---
+
+## v1.251 (2025-02)
+**Bugfix for UDP Broadcast Spot Info**
+
+**Fixed:**
+- Problem reading UDP broadcast spot information fixed (reported by Steve Clements – thank you!).
+- Station tagging (further improved).
+
+---
+
+## v1.25 (2025-02)
+**Wishlist Time**
+
+**New:**
+- **New settings tab: Messagehandling**
+  - Auto-reply to incoming messages configurable.
+  - Automatic reply with own CQ QRG when someone asks for it.
+  - Configurable default filter for the userinfo window *(for Gianluca :-) )*.
+- **Coloured PM rows**: New private messages appear red and fade every 30 seconds from yellow to white *(idea by IU3OAR, Gianluca)*.
+
+**Fixed:**
+- Stations with suffixes like "-2" and "-70" were not being marked as worked → now ignored, station is correctly marked.
+
+---
+
+## v1.24 (2024-11)
+**Wishlist + DX Cluster Spots**
+
+**New:**
+- Button to open the **QRZ.com profile** of the selected station.
+- Button to open the **QRZ-CQ profile** of the selected station.
+- **DX Cluster Server integration**: Direction warnings are sent as spots to the logging software (when QRG is known).
+
+*(Coloured PM row feature also added – tnx Gianluca)*
+
+---
+
+## v1.23 (2024-10)
+**Built-in DX Cluster Server**
+
+**New:**
+- KST4Contest now contains a **built-in DX cluster server**.
+- Generates DX cluster spots and sends them to the logging software when a direction warning is triggered and a QRG is known.
+- Spotter callsign must differ from the contest callsign (for correct filtering in the logging software).
+
+*(Idea by OM0AAO, Viliam Petrik – thank you!)*
+
+---
+
+## v1.22 (2024-05)
+**Usability Improvements and AirScout Button Fix**
+
+**New:**
+- New variables (tnx OM0AAO, Viliam Petrik):
+  - `MYLOCATORSHORT`
+  - `MYQRGSHORT`
+  - `QRZNAME`
+
+**Changed:**
+- Send field focus: After clicking a callsign in the user list, the send field immediately receives focus – no double-click needed *(tnx Gianluca)*.
+
+**Fixed:**
+- Worked-station filter is now live: Worked stations disappear immediately when the filter is activated *(tnx Gianluca)*.
+- QRB sorting was lexicographic → now numeric *(tnx Alessandro Murador)*.
+- AirScout "Show Path" button: Click now maximises AirScout and correctly shows the path.
+
+---
+
+## v1.21 (2024-04)
+**Usability Improvements**
+
+**Changed:**
+- Window sizes and divider positions are saved in the configuration file when clicking "Save Settings" and restored on startup.
+- Filter section as flowpane → better display on smaller screens.
+
+---
+
+## v1.2 (2024-04)
+**Band Selection and NOT-QRV Tags**
+
+**New:**
+- **Band selection**: Selectable in Preferences which bands are active. Only buttons and fields for selected bands appear in the UI. Save and restart required.
+- **NOT-QRV tags per station and band**: Stations can be marked as "not QRV" for each band. Combinable with the user list filter.
+- **QTF arrow**: The "Show path in AS" button now shows an arrow with the QTF of the selected station.
+
+---
+
+## Earlier Versions
+
+### v1.1
+First publicly released version. Core features:
+- Worked marking via Simplelogfile and UDP
+- Sked direction highlighting
+- QRG detection
+- Text snippets and shortcuts
+- AirScout interface (first version)
+- Interval beacon
+- PM catching for public messages containing your own callsign
+- Update notification service
+
+---
+
+## Planned Features
+
+- ~~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

@@ -0,0 +1,953 @@
+# Configuration
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Konfiguration)
+
+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**: 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.
+
+---
+
+## Station Settings
+
+![Station Settings](client_settings_window_station.png)
+
+### Login and Chat Categories
+
+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).
+
+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`). 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
+
+The **My station uses …** checkboxes define the bands available in the current local station setup. Supported choices are 50 MHz, 70 MHz, 144 MHz, 432 MHz, 1296 MHz, 2320 MHz, 3400 MHz, 5760 MHz and 10 GHz.
+
+This selection controls more than the visible band columns. It is also used for:
+
+- the per-band Worked and NOT-QRV filters,
+- the NOT-QRV controls visible in the **Further Info** panel,
+- the `a` and `B+` band-opportunity calculation,
+- the **New bands** filter,
+- the band-upgrade hint after a log entry, and
+- band-specific priority and Reachability functions.
+
+After a change, click **Save Settings** and restart KST4Contest. Band columns and several related controls are created while the user interface is being built and are therefore not added or removed completely during the current session.
+
+### Antenna Beamwidth
+
+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°`.
+
+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
+
+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
+
+The station map uses several values from the **Station** tab to calculate the terrain profile and link budget for the selected remote station. Enter the local station data as realistically as possible. The remote-station values remain global assumptions unless more accurate information is available.
+
+| Setting | Use |
+|---|---|
+| **Own antenna height AGL** | Height of the local antenna above the surrounding terrain in metres |
+| **Own TX power W** | Local transmit power in watts |
+| **Own ant. gain dBi** | Gain of the local antenna in dBi |
+| **DX OM TX power W** | Assumed transmit power of the remote station in watts |
+| **DX OM ant. gain dBi** | Assumed antenna gain of the remote station in dBi |
+
+**AGL** means *Above Ground Level*. Do not enter the height above sea level. The terrain elevation at the local station already comes from the elevation profile; KST4Contest adds the configured antenna height to this value.
+
+For the remote station, KST4Contest currently uses a fixed antenna height of 10 metres above the local terrain. Its transmit power and antenna gain come from the two **DX OM** fields. These values are deliberately assumptions: ON4KST provides neither the actual antenna height nor the complete station data of the remote operator.
+
+Antenna gains must be entered in `dBi`. Add `2.15 dB` before entering a value specified in `dBd`:
+
+```text
+dBi = dBd + 2.15 dB
+```
+
+The current QTF, configured antenna beamwidth and default maximum QRB affect the map display. The bands enabled for the local station and the frequency derived for the remote station also affect the selection of the analysis frequency.
+
+For the terrain profile, KST4Contest uses the antenna heights, elevation model and Earth curvature with a fixed effective Earth-radius factor of `k = 4/3`. The link budget additionally includes:
+
+- distance and the current analysis frequency,
+- transmit powers and antenna gains in both directions,
+- frequency-dependent estimated feeder losses,
+- free-space path loss, and
+- a rough additional loss caused by the relevant obstruction in the terrain profile.
+
+The calculation is performed in both directions. The weaker direction determines the common SSB or CW margin. Optimistic power or antenna values therefore improve the displayed result, but they do not improve the real radio path.
+
+The results remain engineering estimates. Current propagation conditions, local obstructions, vegetation, buildings, interference and unknown station parameters can change the actual result considerably. Operation, frequency selection and the limits of the calculation are described under [Station Map and Path Analysis](en-Features#station-map-and-path-analysis-from-v141).
+
+---
+
+## Server Settings (from v1.31)
+
+The connection details for the ON4KST chat server are shown at the top of the **Station** tab. They normally do not need to be changed.
+
+| Setting | Meaning |
+|---|---|
+| **ON4KST server** | DNS name or IP address of the chat server; the software default is `www.on4kst.org` |
+| **Port** | TCP port of the chat server; the default is `23001` |
+
+`www.on4kst.info` may also remain in an existing, working configuration. There is no reason to change it merely because the displayed name differs from the software default, provided that the chat connection remains reliable.
+
+These values apply only to the outgoing ON4KST chat connection. They do not change the local DX cluster server or any connection to AirScout, PSTRotator or logging software.
+
+The port must be between `1` and `65535`. An invalid entry is rejected and replaced with the last valid value. An incorrect server name or port, on the other hand, prevents KST4Contest from connecting to the chat.
+
+Changing either value does not alter an existing TCP connection. Disconnect and reconnect the chat, or restart KST4Contest. Then use **Save Settings** so that the values are retained for the next program start.
+
+---
+
+## Log Sync Settings
+
+The **Log sync** tab selects the sources from which KST4Contest imports worked stations. The three input paths provide different levels of detail:
+
+![Log synchronisation settings](client_settings_window_logsync.png)
+
+| Input path | Data used | Result in KST4Contest |
+|---|---|---|
+| **Simplelogfile** | Callsigns read from a selected file | global Worked status, but no band or locator information |
+| **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 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 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).
+
+---
+
+## TRX Sync Settings
+
+TRX synchronisation imports the current frequency from the logging application and makes it available in KST4Contest as the local QRG of the first chat category. QSO and frequency synchronisation may use the same UDP receiver, but they remain separate functions: receiving a `RadioInfo` packet does not mark a station as worked, and receiving a QSO packet does not automatically change the local QRG.
+
+![TRX synchronisation settings](client_settings_window_trxsync.png)
+
+### Available QRG Sources
+
+| Source | Setting | Behaviour |
+|---|---|---|
+| **General RadioInfo listener** | `Update MYQRG from RadioInfo messages received on the shared log-sync port` | Processes compatible `RadioInfo` packets on the UDP port shared with QSO synchronisation. The default port is `12060`. |
+| **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. 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.
+
+### Which QRG Is Updated?
+
+Both automatic sources update `MYQRG` only. This is the local QRG of the first or primary chat category.
+
+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.
+
+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
+
+By default, KST4Contest uses the main frequency contained in the Win-Test `STATUS` packet.
+
+Enable `Use pass frequency from Win-Test STATUS` to use the packet's pass frequency instead. This is useful, for example, when Win-Test maintains a different frequency during split operation and that is the frequency which should be announced in the chat.
+
+If the packet does not contain a valid pass frequency, KST4Contest automatically falls back to the main frequency. A missing pass frequency therefore neither clears `MYQRG` nor replaces it with an obviously incorrect number.
+
+Frequencies use a consistent KST4Contest display format, for example:
+
+```text
+50.300.00
+144.300.00
+1296.100.00
+10368.100.00
+```
+
+The number of digits before the first dot is derived from the frequency. Microwave frequencies with four or five MHz digits are therefore formatted correctly as well.
+
+### Selecting the Win-Test Station
+
+Several stations in a Win-Test network may transmit `STATUS` packets at the same time. `Win-Test station name filter` selects the station which is allowed to update the local QRG in KST4Contest.
+
+Example:
+
+```text
+STN1
+```
+
+The comparison is case-insensitive. If the field is empty, `STATUS` packets from every Win-Test station are accepted.
+
+In a multi-operator setup, set the filter to the station name of the operating position which actually belongs to this KST4Contest instance. Otherwise, a packet from another position may replace the QRG currently being displayed.
+
+### Using MYQRG and SECONDQRG
+
+The synchronised QRG can be used in every text processed by the common KST4Contest variable resolver. This includes:
+
+- the send field,
+- shortcuts,
+- snippets, and
+- automatic beacons.
+
+`MYQRG` contains the complete QRG of the first chat category. `MYQRGSHORT` uses only its first seven characters. `SECONDQRG` contains the separately entered QRG of the second chat category.
+
+Examples:
+
+```text
+I am calling cq at MYQRG
+cq on MYQRGSHORT
+second chat qrg SECONDQRG
+```
+
+The values are inserted when the message text is resolved. If the logging application changes frequency between two beacon runs, the next message already uses the updated value.
+
+The local QRG may also be used as a fallback when handing a sked over to Win-Test. This only happens if the QRG can be parsed and belongs to the band explicitly selected for the sked. See [Log Synchronisation](en-Log-Sync#handing-skeds-over-to-win-test) for details.
+
+Further information about text variables: [Macros and Variables](en-Macros-and-Variables#variables).
+
+### Multiple Loggers or Radios
+
+Every enabled QRG source writes to the same `MYQRG` value. KST4Contest does not currently assign incoming `RadioInfo` or `STATUS` packets to a particular radio or chat category.
+
+If the general RadioInfo listener and Win-Test synchronisation are enabled at the same time, the most recently processed packet therefore determines the displayed QRG. The same applies when several logging applications send frequency packets to one KST4Contest instance.
+
+For a setup containing several radios:
+
+- QSO packets may be received from several logging applications.
+- Frequency packets should only be transmitted by the source which is intended to control `MYQRG`.
+- A Win-Test network should additionally use the station-name filter.
+- If two completely independent QRG synchronisations are required, two separate KST4Contest instances provide the clearer arrangement.
+
+In other words, combining several Worked sources is useful. Combining several simultaneously transmitting frequency sources merely creates a contest over which packet arrived last.
+
+Click **Save Settings** after completing the configuration.
+
+---
+
+## AirScout Settings
+
+The **AirScout** tab configures the UDP connection between KST4Contest and AirScout. KST4Contest does not request a general aircraft feed. It submits the station paths which are currently relevant, while AirScout calculates the matching aircraft and returns the result to the requesting KST4Contest instance.
+
+AirScout `0.9.9.5` or newer is required.
+
+![AirScout settings in KST4Contest](as_plane_feed_3.png){ width=85% }
+
+### UDP Connection Settings
+
+| Setting | Default | Use |
+|---|---:|---|
+| **Enable AirScout UDP integration** | disabled | Enables AirScout requests and the processing of returned information |
+| **AirScout server identifier** | `AS` | Logical name of the AirScout instance being addressed |
+| **KST4Contest client identifier** | `KST` | Logical name of this KST4Contest instance |
+| **AirScout UDP port** | `9872` | Shared UDP port for requests and responses |
+| **Select AirScout frequency automatically per station** | enabled | Derives a suitable band and frequency from the current context of each remote station |
+| **Forced AirScout band value** | `1440000` | Uses one fixed AirScout band value for every station when automatic selection is disabled |
+
+When **Enable AirScout UDP integration** is disabled, KST4Contest neither sends AirScout requests nor processes incoming AirScout responses. The UDP receiver may remain bound so that the integration can be enabled again during the current connection.
+
+KST4Contest sends AirScout packets to the broadcast address `255.255.255.255`. No separate destination IP address is therefore configured. AirScout and KST4Contest must be able to receive the same UDP broadcast; routers do not normally forward this type of broadcast into another network. If communication fails, check the UDP port, local firewall and network assignment first.
+
+### Automatic Band Selection per Station
+
+**Auto per station** is the recommended setting. Instead of using one fixed band value for every remote station, KST4Contest derives a suitable frequency from the available operating context.
+
+The sources are evaluated in this order:
+
+1. the most recently detected QRG of the remote station, provided that it is no more than 30 minutes old,
+2. one unambiguous complete QRG in the name field of an active chat entry,
+3. unambiguous band designators in the name field,
+4. 432 MHz if the same station is active in both the VHF/UHF and Microwave categories and 432 MHz is enabled for the local station,
+5. the lowest locally enabled band belonging to the supported chat category.
+
+Active chat variants of the same base callsign are evaluated together. Entries such as `CALLSIGN`, `CALLSIGN-2` and `CALLSIGN-432` can therefore contribute to the same band decision while remaining separate chat members for message processing.
+
+Only bands enabled under **My station uses …** are eligible for automatic selection. A manually assigned NOT-QRV mark excludes the corresponding band and takes precedence over automatically detected QRG or name information.
+
+The 50/70 MHz, VHF/UHF, Microwave and EME/JT65 chat categories are supported. Other ON4KST categories do not participate in AirScout band resolution. If no sufficiently reliable frequency can be determined, KST4Contest omits the request for that station. An arbitrary fallback to 144 MHz would produce a syntactically complete packet, but not necessarily a useful calculation.
+
+Automatic AirScout selection uses the same propagation-frequency resolver as the internal path analysis. Both functions therefore evaluate the station path from the same technical basis.
+
+### Fixed AirScout Band
+
+When **Auto per station** is disabled, KST4Contest uses the value entered under **Forced AirScout band value** for every station.
+
+Enter the value in the unit used by the AirScout UDP interface:
+
+| Band | AirScout value |
+|---|---:|
+| 50 MHz | `500000` |
+| 70 MHz | `700000` |
+| 144 MHz | `1440000` |
+| 432 MHz | `4320000` |
+| 1296 MHz | `12960000` |
+| 2320 MHz | `23200000` |
+| 3400 MHz | `34000000` |
+| 5760 MHz | `57600000` |
+| 10368 MHz | `103680000` |
+| 24048 MHz | `240480000` |
+
+In fixed mode, neither the remote station's recently detected QRG nor a band stated in its name is considered. This option is therefore mainly useful for a station setup which is clearly limited to one band, or for troubleshooting.
+
+### Server and Client Identifiers
+
+The identifiers belong to the AirScout protocol. They are not DNS names or IP addresses.
+
+Outgoing requests contain the client identifier followed by the server identifier:
+
+```text
+"KST" "AS"
+```
+
+AirScout returns them in the opposite order:
+
+```text
+"AS" "KST"
+```
+
+KST4Contest processes a response only if both identifiers exactly match the current configuration. The comparison is case-sensitive.
+
+Identifiers must not be empty and must not contain quotation marks or line breaks.
+
+If several KST4Contest instances operate in the same network, assign a distinct client identifier to each one, for example:
+
+```text
+KST-144
+KST-432
+```
+
+If several AirScout instances are present, use distinct server identifiers as well. This prevents a response intended for one operating position from being processed by another KST4Contest instance.
+
+### Which Stations Are Requested?
+
+KST4Contest starts the first periodical AirScout request approximately ten seconds after the chat connection has been established. Further requests follow every 60 seconds.
+
+An active station is included only if:
+
+- a usable callsign is available,
+- a locator is available,
+- its distance has been calculated,
+- its distance is below the configured **Maximum QRB**, and
+- a usable band can be determined.
+
+Several active chat entries of the same base callsign do not create a separate identical path calculation for every suffix. The returned AirScout information is subsequently assigned to the corresponding active chat variants.
+
+This selection does more than reduce network traffic. It also prevents AirScout from continuously calculating paths outside the intended working range of the local station.
+
+### Applying Changed Settings
+
+The following changes are used for new packets immediately after leaving the input field or changing the checkbox:
+
+- enabling or disabling the AirScout integration,
+- server identifier,
+- client identifier,
+- automatic or fixed band selection, and
+- the forced band value.
+
+After changing the UDP port, disconnect and reconnect the chat or restart KST4Contest. The existing UDP receiver otherwise remains bound to the previous port.
+
+Click **Save Settings** afterwards to retain the configuration.
+
+AirScout setup, aircraft display and the meaning of the returned AP information are described under [AirScout Integration](en-AirScout-Integration).
+
+---
+
+## Notification Settings
+
+![Notifications, DX cluster output and QSO monitoring](client_settings_window_notification.png)
+
+The three audio functions work independently:
+
+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
+
+The **Fallback band for relative QRG detection** dropdown selects the band used when a relative QRG cannot be assigned to a recent station-specific band context.
+
+Only band prefixes supported by the frequency parser are available:
+
+```text
+50 MHz
+70 MHz
+144 MHz
+432 MHz
+1296 MHz
+2320 MHz
+3400 MHz
+5760 MHz
+10368 MHz (10G)
+24048 MHz (24G)
+```
+
+The dropdown is neither a filter nor an override for complete frequencies. `432.088` is recognised as a frequency in the 432 MHz band regardless of the selection. The fallback is needed for relative values such as `.205`, `,205` or `qrg 205`.
+
+Before using the fallback, KST4Contest checks the sender's recent band context. If a complete frequency has been detected for the same station during the previous 30 minutes, that band takes precedence. A fallback setting of `144 MHz` therefore still turns `.100` into `432.100 MHz` if the station mentioned `432.088` shortly before.
+
+Although this setting is located in the Notification tab, it affects the general QRG parser. It therefore influences the QRG column, detected active bands, priority calculations, band-upgrade hints and other functions which use a known station frequency – not only DX cluster spots.
+
+Further details, including numbers which are deliberately ignored, are described under [QRG Detection](en-Features#qrg-detection).
+
+### Local DX Cluster Output
+
+KST4Contest can forward detected directional opportunities to logging software as DX cluster spots. A frequency recognised in the chat can therefore appear directly in the logger's band map without being entered manually.
+
+The **Enable the local DX Cluster server …** checkbox starts or stops the local TCP server. When KST4Contest is connected to the chat, the change takes effect immediately.
+
+The following settings and controls belong to the local DX cluster output:
+
+- **TCP port**: Port on which KST4Contest accepts connections from DX cluster clients. The default is `8000`. Changing the port while the server is running restarts it on the new port. The logger must then reconnect to that port.
+- **Fallback band for relative QRG detection**: The global fallback band described above. The test spot uses `.300` on this band. Actual spots use the QRG detected for the respective sender.
+- **Spotter callsign**: Callsign shown as the spotter in generated DX cluster entries. A callsign different from the contest callsign should be used. Some logging programs filter spots apparently sent by the local station or treat them differently from external spots.
+- **Send test spot**: Sends the following entry to every currently connected DX cluster client:
+
+```text
+Spotted callsign: DO5AMF
+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
+
+1. KST4Contest is connected to the ON4KST chat,
+2. the local DX cluster server is enabled, and
+3. at least one DX cluster client is connected to KST4Contest.
+
+KST4Contest does not generate a spot for every frequency found in the chat. An actual spot is created only when a directed message between two stations indicates a relevant antenna direction for the local station and a usable frequency is known for the sender.
+
+The complete derivation and logger setup are described under [Built-in DX Cluster Server](en-DX-Cluster-Server).
+
+---
+
+### Band Upgrade Hint after a Log Entry
+
+After receiving a log entry from UCXLog or Win-Test, KST4Contest can check whether the station which has just been worked still offers another common and unworked band.
+
+The check uses the same derivation as the `a` and `B+` display:
+
+1. the bands enabled in the local station settings,
+2. QRGs detected for the remote station during the previous 30 minutes,
+3. explicit band designators in the name fields of its active chat entries,
+4. stored per-band Worked marks, and
+5. manually assigned NOT-QRV marks.
+
+Active chat variants of the same normalised callsign are evaluated together. NOT-QRV takes precedence over an automatically detected QRG or band designator.
+
+If at least one common and unworked band remains, the main window displays a blinking **BAND+** hint for approximately twelve seconds. The callsign and remaining bands are included in the button text; the tooltip contains the complete derivation. If general notification sounds are enabled, KST4Contest also plays a short sound.
+
+The two options serve different purposes:
+
+- **Blink + sound …** enables the hint after a matching log entry.
+- **Priority boost …** additionally raises the score of stations which have already been worked on at least one band but still offer another common and unworked band.
+
+The Priority Boost is only one factor in the complete calculation. Distance, antenna direction, recent activity, AirScout data, skeds and negative hints may still change the final order. Enabling the option therefore guarantees neither a particular score nor a particular position in the priority list.
+
+The other score weights currently have no separate user-interface controls. Several existing settings nevertheless provide input data for the calculation, particularly the [active bands](#active-bands), [antenna beamwidth](#antenna-beamwidth), [default maximum QRB](#default-maximum-qrb) and [AirScout settings](#airscout-settings).
+
+The complete calculation is described under [Priority Score and Priority List](en-Features#priority-score-and-priority-list-from-v140).
+
+
+The hint requires a log-synchronisation source which provides band information. The file-based callsign interpreter sees callsigns only and cannot reliably identify the band of the QSO which has just been logged.
+
+Further explanation: [Band Upgrade Hint after a Log Entry](en-Features#band-upgrade-hint-after-a-log-entry).
+
+---
+
+## Shortcut Settings
+
+![Configuration of shortcut buttons and text snippets](client_settings_window_shortcuts.png)
+
+Each entry in the upper part of the **Shortcuts** tab creates one button above the message field in the main window. Pressing the button appends its configured text to the current contents of the send field.
+
+If the shortcut contains a [variable](en-Macros-and-Variables#variables), it is replaced with its current value when the text is inserted. A shortcut such as
+
+```text
+pse call me at MYQRGSHORT
+```
+
+may therefore insert:
+
+```text
+pse call me at 144.388
+```
+
+The exact entries `MYQRG` and `SECONDQRG` are additionally highlighted as QRG buttons. They insert the current frequency of the primary or secondary chat category respectively.
+
+The shortcut `/SETNAME MYQRG` is highlighted as well. When it is pressed, KST4Contest resolves `MYQRG` and inserts the complete server command into the send field. The command is not transmitted automatically and can still be checked before it is sent with `Enter` or **TX**.
+
+
+The order of the table determines the order of the buttons in the main window. Manage the entries as follows:
+
+1. **Add shortcut** creates a new entry at the beginning of the list and immediately opens it for editing.
+2. Double-click an existing entry to edit it. Press `Enter` to accept the change.
+3. To remove an entry, delete its complete contents and confirm with `Enter`.
+4. Use **Move selected up** and **Move selected down** to change the position of the selected entry.
+
+Changes appear in the main window immediately. Use **Save Settings** afterwards if they should remain available after the next program start.
+
+---
+
+## Snippet Settings
+
+Snippets are longer text blocks intended primarily for messages to a selected station. They can be opened through:
+
+- a right-click on a station in the user list;
+- a right-click on a message in the public chat table;
+- a right-click on a message in the PM table; or
+- `Ctrl+1` through `Ctrl+0` for the first ten entries in the snippet list.
+
+The keyboard mapping follows the order of the table:
+
+| Key combination | Snippet |
+|---|---:|
+| `Ctrl+1` | first entry |
+| `Ctrl+2` | second entry |
+| … | … |
+| `Ctrl+9` | ninth entry |
+| `Ctrl+0` | tenth entry |
+
+A snippet selected from a context menu is appended to the message already prepared in the send field. Selecting a station or message will normally have inserted the appropriate `/cq` destination first.
+
+A keyboard shortcut behaves differently: it replaces the current contents of the send field with a complete directed message:
+
+```text
+/cq CALLSIGN snippet text
+```
+
+The complete visible callsign, including any suffix, is retained. Selecting `9A0BB-70` may therefore produce:
+
+```text
+/cq 9A0BB-70 pse ur qrg?
+```
+
+The selected station's chat category is retained for transmission. If no station is selected, or no snippet is assigned to the chosen key combination, nothing is inserted.
+
+Variables are resolved when the snippet is inserted. Station-specific variables such as `QRZNAME`, `FIRSTAP` and `SECONDAP` refer to the currently selected station. The prepared message is not sent automatically and can still be checked or edited. Press `Enter` or **TX** to send it; `Esc` clears the send field.
+
+The snippet list is edited in the same way as the shortcut list:
+
+1. **Add new snippet** creates a new entry at the beginning of the list.
+2. Double-click an existing entry to edit it.
+3. Press `Enter` to accept the change.
+4. Confirming an empty entry removes it.
+5. **Move selected up** and **Move selected down** change both the displayed order and the assignment to `Ctrl+1` through `Ctrl+0`.
+
+The context menus and keyboard mappings are updated immediately. Use **Save Settings** afterwards to store the modified list permanently.
+
+The complete list of available placeholders and their limitations is described under [Macros and Variables](en-Macros-and-Variables).
+
+---
+
+## Beacon Settings
+
+![Beacon settings](client_settings_window_beacon.png)
+
+A beacon sends a public CQ message at regular intervals. It is intended for operating situations in which the local station calls CQ on a fixed frequency for an extended period. Other stations receive current QRG information without requiring the operator to enter the same message repeatedly.
+
+KST4Contest uses one shared timer for both chat categories. Each category nevertheless has its own enable setting and message template:
+
+- **Enable CQ beacon** enables the beacon for the respective category.
+- **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 category is enabled and fully synchronised in the same ON4KST session.
+
+### Interval and timer behaviour
+
+The interval is entered in whole minutes. The minimum permitted value is one minute.
+
+After the chat connection has been established, KST4Contest performs the first beacon check after approximately ten seconds. The configured interval applies after that initial check.
+
+Changing the interval while connected restarts the countdown with the new value. The change itself does not cause an immediate beacon message.
+
+Both categories use the same timer. Separate intervals for the primary and secondary chat cannot be configured.
+
+### Message text and variables
+
+A beacon may use the [global variables](en-Macros-and-Variables#variables-in-the-beacon) which depend only on the local station:
+
+- `MYQRG`
+- `MYQRGSHORT`
+- `SECONDQRG`
+- `MYLOCATOR`
+- `MYLOCATORSHORT`
+- `MYCALL`
+- `MYQTF`
+
+A suitable message for the primary chat category is:
+
+```text
+calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
+```
+
+Use `SECONDQRG` for the second chat if it operates on a different frequency:
+
+```text
+calling cq at SECONDQRG, ant MYQTF deg, loc MYLOCATOR
+```
+
+Variables are resolved again on every timer run. If the logging software changes the QRG stored in `MYQRG`, the next beacon can already contain the updated value. The message template does not have to be edited.
+
+`MYQRG` and `MYQRGSHORT` always refer to the primary chat category. Enabling or selecting the second chat does not change this assignment.
+
+Station-specific variables such as `QRZNAME`, `FIRSTAP` and `SECONDAP` require a selected remote station. A public beacon has no such destination, so these variables are not resolved in beacon messages.
+
+### Message validation
+
+KST4Contest validates both the configured template and the message which remains after all variables have been resolved.
+
+The following restrictions apply:
+
+- The final message must not be empty.
+- It must not exceed 120 characters.
+- The protocol separator `|` is not permitted.
+- Line breaks are not permitted.
+
+An invalid entry is not accepted as the new beacon configuration. If a template becomes invalid only after resolving its variables, for example because the resulting text exceeds 120 characters, that beacon run is skipped.
+
+A template which consists only of a temporarily empty global variable may still be stored. This can happen during startup before the first QRG has been received from the logger. KST4Contest does not send an empty message while the variable has no usable value.
+
+### When should the beacon be disabled?
+
+The beacon is useful only while its QRG matches the actual operation. Leaving it enabled while searching the band or changing frequencies frequently may cause other stations to look for the local station on an obsolete frequency.
+
+In plain terms: the beacon saves work while calling CQ on a fixed QRG. It should be disabled while moving around the band.
+
+Changes take effect during the current connection. Use **Save Settings** afterwards to retain the enable settings, message templates and interval for the next program start.
+
+---
+
+## Messagehandling Settings (from v1.25)
+
+![Automatic reply settings](client_settings_window_messagehandling.png)
+
+The most important use of the general automatic reply concerns stations which are logged into the ON4KST chat but are not taking part in the current contest. During larger contests, sked requests are sometimes sent to many logged-in stations without first checking whether they are participating. Without an automatic reply, the recipients would have to enter the same refusal repeatedly.
+
+KST4Contest can answer these requests with a predefined message. A separate function provides the local QRG when a private message contains a recognised frequency request. Both functions can be enabled independently.
+
+### General automatic reply
+
+**Enable automatic reply to all private messages** answers incoming private messages with the text entered in the adjacent field. One common text is used for both chat categories. The configured capitalisation is preserved.
+
+A suitable message is:
+
+```text
+Sri, I am not taking part in this contest. No skeds.
+```
+
+Do not add the `[KST4C Automsg]` prefix to the configured text. KST4Contest inserts it automatically.
+
+The message received by the remote station may therefore be:
+
+```text
+[KST4C Automsg] Sri, I am not taking part in this contest. No skeds.
+```
+
+The incoming private message remains visible. The function neither blocks nor discards the request; it merely avoids entering the same answer repeatedly.
+
+The reply is addressed to the sender's complete callsign, including any visible suffix, and sent through the chat category in which the private message was received. This distinction matters when two categories are connected at the same time: a request received through the microwave chat must not be answered accidentally through the VHF/UHF chat.
+
+An empty or whitespace-only answer does not produce an automatic message. A configured text containing the protocol separator `|` or a line break is rejected as well.
+
+### Automatic QRG reply
+
+**Enable automatic QRG replies** reacts to common QRG requests. Matching is case-insensitive and looks for the following text fragments:
+
+```text
+ur qrg?
+your qrg?
+qrg?
+freq?
+pse qrg
+```
+
+The answer contains only the QRG belonging to the category in which the request was received:
+
+| Incoming private message | QRG used for the reply |
+|---|---|
+| Primary category | current QRG of the primary category |
+| Second chat category | current QRG of the second category |
+
+A possible reply is:
+
+```text
+[KST4C Automsg] QRG is: 144.300.00
+```
+
+The values come from the same QRG fields used by `MYQRG` and `SECONDQRG`. The primary QRG may be entered manually or updated through [TRX synchronisation](#trx-sync-settings). The second category uses the value configured or entered for that category.
+
+If no QRG is available for the incoming category, KST4Contest does not send an incomplete reply. A message containing `QRG is:` without a frequency would technically answer the request while providing no useful information. It is therefore rejected before reaching the transmit queue.
+
+When both automatic-reply functions are enabled, the QRG reply takes precedence. A recognised QRG request does not additionally produce the general reply. If the required QRG is missing, KST4Contest does not fall back to the general answer.
+
+### Protection against repeated replies
+
+Every automatically generated reply contains the fixed prefix:
+
+```text
+[KST4C Automsg]
+```
+
+The general and QRG-specific functions ignore messages which already contain this prefix. This prevents two clients with automatic replies enabled from answering each other indefinitely.
+
+A common two-minute cooldown additionally applies to both reply types. The cooldown is tracked separately for each complete callsign and chat category.
+
+This means:
+
+- `CALLSIGN-2` and `CALLSIGN-70` have separate cooldowns.
+- The same complete callsign can still receive an independent reply in another chat category.
+- A general reply also suppresses a QRG reply to the same callsign in the same category for two minutes.
+- A QRG reply likewise suppresses the general reply.
+
+The cooldown starts only after KST4Contest has produced a complete, locally valid message and placed it in the transmit queue. A missing QRG, an empty general reply or a message rejected because of invalid characters does not start the cooldown. Once the missing information has been corrected, a valid reply can therefore be generated immediately.
+
+> **Note**: The configured text should describe the actual operating status clearly. If the station is only observing the contest and does not accept skeds, say exactly that. A vague automatic message is likely to produce another question – which is precisely the work this function is intended to avoid.
+
+Changes take effect during the current connection. Use **Save Settings** afterwards to retain the enable settings and general reply text for the next program start.
+
+Further background: [Automatic Replies to Private Messages](en-Features#automatic-replies-to-private-messages-from-v125).
+
+---
+
+
+## Win-Test Network Listener (from v1.31)
+
+The Win-Test network listener processes the native Win-Test UDP protocol. It is independent of the general QSO UDP listener on port `12060` and has three separate tasks:
+
+- processing QSOs including band and locator information,
+- processing STATUS packets for the local QRG, and
+- handing skeds over to the Win-Test network.
+
+### Log sync settings
+
+| Setting | Function |
+|---|---|
+| **Receive Win-Test network based UDP log messages** | Enables the Win-Test network listener. When the listener is enabled, pressing **Create sked** also attempts the Win-Test handover. |
+| **UDP-Port for Win-Test listener** | Port used by the Win-Test network. The default is `9871`. The same port is used for the sked handover. |
+| **KST station name in Win-Test network (src of SKED packets)** | Station name used by KST4Contest when sending sked packets. A unique name should be used in a network containing several clients. |
+| **Win-Test network broadcast address** | Destination address for outgoing Win-Test network packets. In a local network, the address must be reachable by the Win-Test computer. |
+
+The broadcast address is configurable because `255.255.255.255` is not forwarded reliably through every station network or network interface. In a multi-computer setup, the directed broadcast address belonging to the station network may be required instead.
+
+### TRX sync settings
+
+| Setting | Function |
+|---|---|
+| **Win-Test STATUS QRG Sync** | Takes the current frequency from Win-Test STATUS packets and uses it as the local QRG. |
+| **Use pass frequency from Win-Test STATUS** | Uses the transmitted pass frequency instead of the normal TRX QRG. |
+| **Win-Test station name filter** | Only processes STATUS packets from the specified Win-Test station. An empty field accepts every station name. |
+
+The station filter is particularly useful when several Win-Test clients are active. Without a filter, the most recently received STATUS packet from another operating position can overwrite the local QRG in KST4Contest.
+
+### Sked handover
+
+There is no separate internal sked mode for the Win-Test handover. When the listener is enabled, **Create sked** attempts the Win-Test transfer in addition to creating the internal sked.
+
+KST4Contest only sends an `ADDSKED` packet when it can determine a QRG which belongs to the explicitly selected band. If no matching QRG is available, the internal sked remains intact and the Win-Test handover is omitted.
+
+`SSB` or `CW` is selected directly in the Further Info section when the sked is created. No automatic mode inference is used.
+
+Click **Save Settings** after making changes so that the port, station name, broadcast address and TRX options are restored at the next start.
+
+Data handling and QRG selection: [Log Synchronisation – Win-Test](en-Log-Sync#win-test)
+
+---
+
+## 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.
+
+The settings are located in the **Station** tab:
+
+| Setting | Default | Purpose |
+|---|---:|---|
+| **Enable PSTRotator** | disabled | Starts UDP communication with PSTRotator |
+| **PSTRotator host** | `127.0.0.1` | Hostname or IP address of the computer running PSTRotator |
+| **PSTRotator UDP port** | `12000` | UDP port on which PSTRotator receives control commands |
+
+When both applications run on the same computer, `127.0.0.1` is normally the clearest setting. If PSTRotator runs on another computer in the station network, enter its reachable IP address or DNS name.
+
+The port must be between `1` and `65534`. Port `65535` cannot be used because PSTRotator reports its position on the following port.
+
+### Preparing PSTRotator
+
+Configure the same UDP port under **Communication → UDP Control Port** in PSTRotator and enable **UDP Control**.
+
+The default configuration uses the following pair:
+
+| Direction | UDP port |
+|---|---:|
+| KST4Contest → PSTRotator | `12000` |
+| PSTRotator → KST4Contest | `12001` |
+
+KST4Contest binds the return port automatically. It is not configured separately.
+
+When the programs run on different computers, the local firewalls and station network must permit UDP traffic in both directions. KST4Contest cannot receive position reports if another program already occupies the return port.
+
+The complete UDP protocol is documented in the [PSTRotatorAz User Manual](https://www.qsl.net/yo3dmu/ANT/PstRotatorAz%20User%20Manual.pdf).
+
+### Updating the local QTF
+
+KST4Contest asks PSTRotator for the current azimuth and operating mode every two seconds. The reported azimuth becomes `actualQTF`.
+
+While PSTRotator integration is enabled, the QTF field in the main window is therefore read-only. It displays the most recent position reported by PSTRotator.
+
+This QTF is used by:
+
+- the direction filter;
+- the derivation of direction opportunities;
+- the Priority Score;
+- the antenna sector on the station map;
+- the AP and sked timeline; and
+- the `MYQTF` variable.
+
+A received rotator position is therefore more than a displayed value. It changes several functions which depend on the current antenna direction.
+
+The current integration uses azimuth only. Elevation control and complete azimuth/elevation tracking are outside its present scope.
+
+### Applying changed settings
+
+The enable setting, host and port are evaluated when the rotator connection is started. After changing them, disconnect and reconnect the ON4KST session or restart KST4Contest.
+
+Use **Save Settings** afterwards so that the values are restored at the next program start.
+
+---
+
+## Sniffer Settings (from v1.31)
+
+QSO monitoring is intended for stations whose communication should remain visible during busy chat activity. This may be a rare station, a DXpedition or another station in the same contest team whose sked arrangements should not disappear in the general message traffic.
+
+The callsign list is maintained under **QSO monitoring** in the **Notification** tab.
+
+For every monitored base callsign, KST4Contest additionally shows messages in the PM table when a variant of that callsign is either the sender or the receiver. Both connected chat categories are included.
+
+The list intentionally uses the normalised base callsign. The following entries therefore produce the same monitoring entry:
+
+```text
+DN9APW
+DN9APW-2
+DN9APW-70
+DN9APW-144
+```
+
+In every case, KST4Contest stores and displays:
+
+```text
+DN9APW
+```
+
+The different KST suffixes of one station do not have to be entered separately. A later message sent by `DN9APW-2` or addressed to `DN9APW-70` is covered by the same entry.
+
+This aggregation applies to QSO monitoring only. Active ChatMember objects, complete message destinations and chat categories remain separate. A message addressed to `DN9APW-70` is therefore not redirected to `DN9APW-2`.
+
+A monitored message is marked in the PM table using the complete visible callsigns of its sender and receiver:
+
+```text
+Sniffed: (DN9APW-2 > DL0ABC-70) Message text
+```
+
+The original message remains in its normal table. Monitoring changes neither its contents nor its routing.
+
+A message is included only when the monitored station is actually its sender or receiver. Merely mentioning the callsign in the message text is not sufficient. Public messages sent by a monitored station are included as well; their receiver is displayed as `ALL`.
+
+A message which is already addressed directly to the local callsign remains a normal private message and does not receive an additional `Sniffed:` marker.
+
+Manage the list as follows:
+
+1. Press **Add monitored callsign** to add an entry.
+2. Double-click an existing entry to edit it and press `Enter` to apply the change.
+3. To remove an entry, delete the complete cell contents and press `Enter`.
+
+The entered value may contain a visible KST suffix or portable components. KST4Contest normalises it to the base callsign before storing it. Different variants of the same base callsign are therefore treated as duplicates.
+
+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 from v1.42 onwards.
+
+Further background and the distinction from message routing: [QSO Sniffer](en-Features#qso-sniffer-from-v131).
+
+---
+
+## GUI Settings: Band-Column Hints
+
+Two optional additions to the band columns can be enabled or disabled in the **GUI** tab:
+
+- **Show "o" in band columns …** displays an `o` if the four-character grid square has already been worked on the relevant band. Disabling the option does not delete any database records; it only hides the additional indicator in the band columns. `wkdany` is unaffected.
+- **Show "a" in band columns …** distinguishes a completely new callsign from a band opportunity involving a callsign already worked elsewhere. When disabled, both cases are displayed as `B+`. The band-opportunity calculation itself remains unchanged.
+
+Changes are reflected in the current user interface immediately. Click **Save Settings** afterwards if they should persist after the next start.
+
+![GUI settings for band-column hints](client_settings_window_gui.png)
+
+---
+
+## Worked Station Database Settings
+
+The internal SQLite database stores contest-related state independently of the logging application's database:
+
+- the global Worked status of a callsign,
+- Worked status per band,
+- 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.
+
+The **Reset worked, NOT-QRV and grid data...** button removes every Worked mark, NOT-QRV mark and stored worked grid square. A confirmation dialog is displayed first. Known callsign rows remain in the database; only the contest-related state is reset.
+
+A reset is useful when you deliberately want to start with an empty contest state or have imported test data. It is not intended as a daily maintenance step.
+
+Display and derivation: [Worked Callsigns, New Bands and New Grid Squares](en-Features#worked-callsigns-new-bands-and-new-grid-squares).
+
+---
+
+## Dark Mode (from v1.26)
+
+Enable Dark Mode through **Windows → Use dark mode design**. Use **Windows → Use default mode design** to restore the normal light colour scheme.
+
+---
+
+## Saving Settings
+
+**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 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

@@ -0,0 +1,281 @@
+# Built-in DX Cluster Server
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-DX-Cluster-Server)
+
+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.
+
+The idea came from OM0AAO, Viliam Petrik. Thank you!
+
+---
+
+## Why Use a Local DX Cluster Server?
+
+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.
+
+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.
+
+---
+
+## Automatic Spots from Directional Opportunities
+
+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.
+
+Two directions are compared:
+
+- the direction from station A to station B;
+- the direction from station A to the local station.
+
+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°`.
+
+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.
+
+An automatic DX Cluster spot is created only when all of the following conditions are met:
+
+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
+
+The **Send test spot** button creates the following test entry:
+
+```text
+Spotted callsign: DO5AMF
+Comment: DXC test: You donated $100!
+Frequency: .300 on the configured fallback band
+```
+
+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 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 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.
+
+---
+
+## Content of a Generated Spot
+
+A spot contains:
+
+- 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 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.
+
+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%
+```
+
+---
+
+## If No Spot Appears
+
+### The Test Spot Does Not Reach the Logger
+
+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 Programmes
+
+The interface has been used with:
+
+- 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-Home.md

@@ -0,0 +1,132 @@
+# KST4Contest – User Manual
+
+> You are reading the English version | [Deutsche Version](de-Home)
+
+KST4Contest is a desktop client for the [ON4KST Chat](https://www.on4kst.org/chat/login.php), developed for VHF, UHF and SHF contest operation. It brings chat, candidate selection, sked planning, aircraft scatter data and external station software together in a single operating interface.
+
+KST4Contest is developed by **DO5AMF (Marc Fröhlich)**, operator at DM5M and (since May 2025) **DN9APW (Philipp Wagner)**. The source code is publicly available on [GitHub](https://github.com/praktimarc/kst4contest).
+
+---
+
+## Why use a dedicated ON4KST client?
+
+During a contest, the ON4KST Chat provides a considerable amount of information: active stations, locators, frequencies, sked requests and indications of current activity. The actual problem is not seeing this data. It is turning it into the next useful contact in time.
+
+KST4Contest evaluates the available information, puts it into context and presents it as part of a contest-oriented workflow. This includes antenna direction, distance, known bands and frequencies, worked status, chat activity and aircraft scatter timing.
+
+The program does not decide which QSO is actually possible. Priority scores, the AP timeline and visual highlights are decision aids. The final judgement remains with the operator – not least because even a very convincing computer screen cannot complete a radio contact.
+
+---
+
+## How KST4Contest supports contest operation
+
+- **Observe and organise chat activity:** KST4Contest can display two ON4KST chat categories at the same time. Messages, frequency information and known band activity are assigned to the corresponding stations.
+
+- **Reduce the station list:** Direction, distance, worked and NOT-QRV filters help limit the user list to stations that are relevant to the current operating situation.
+
+- **Prioritise candidates:** The score system evaluates active chat members using several known criteria. The currently most relevant candidates are also shown in a separate priority list.
+
+- **Prepare skeds and keep them visible:** Sked reminders, automatic advance messages and the AP timeline help prevent scheduled contacts from disappearing somewhere between chat, logging and ongoing CQ operation.
+
+- **Include aircraft scatter information:** The AirScout interface brings suitable aircraft and expected reflection times into candidate evaluation and sked planning.
+
+- **Connect the logger and station equipment:** KST4Contest synchronises worked stations and frequency information with supported logging software. It also provides interfaces for Win-Test, PSTRotator and a built-in DX Cluster server.
+
+- **Display stations and radio paths:** The station map shows active chat members, locator squares, antenna directions and the path to the selected station. A terrain profile can also be calculated for selected paths.
+
+These functions share information. A detected frequency can indicate an active band, worked status comes from the logger, aircraft scatter data adds timing information and the resulting score affects the priority list. Missing or outdated input data can therefore affect the result as well.
+
+---
+
+## Requirements
+
+A registered ON4KST account is required. Registration and login are available from the [official ON4KST login page](https://www.on4kst.org/chat/login.php).
+
+English is the official language of the ON4KST Chat. This also applies when communicating with stations from your own country. Common amateur radio abbreviations such as `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` and `73` are normal and usually considerably faster than carefully written prose.
+
+Downloads, supported operating systems and installation methods are described in [Installation](en-Installation).
+
+---
+
+## Manual version
+
+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/)
+- [GitHub releases](https://github.com/praktimarc/kst4contest/releases)
+- [Version history](en-Changelog)
+
+The stable release is normally the appropriate choice for contest operation. Beta and Nightly builds contain newer fixes and functions, but may still change between builds. They are intended for testing specific changes. Ten minutes before a contest is usually not the ideal time for a first test.
+
+---
+
+## Quick navigation
+
+| Page | Contents |
+|---|---|
+| [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 |
+| [Features](en-Features) | Operation, reasoning and limitations of individual functions |
+| [Macros and Variables](en-Macros-and-Variables) | Reusable messages, shortcuts and automatically substituted values |
+| [User Interface](en-User-Interface) | Interface layout and operation during a contest |
+| [Changelog](en-Changelog) | Releases, Nightly changes and resolved issues |
+
+---
+
+## Contact and support
+
+- **Download:** [Stable, Beta and Nightly builds](https://kst4contest.hamradioonline.de/download/)
+- **Source code:** [praktimarc/kst4contest](https://github.com/praktimarc/kst4contest)
+- **Bug reports and feature requests:** [GitHub Issues](https://github.com/praktimarc/kst4contest/issues)
+- **Email:** praktimarc+kst4contest@gmail.com  
+  Please use this address only for KST4Contest-related topics.
+
+### Reporting a bug
+
+A problem is considerably easier to reproduce when the report contains at least:
+
+1. the KST4Contest version,
+2. the operating system and installation method,
+3. the exact steps leading to the problem,
+4. the expected and observed behaviour,
+5. a screenshot where appropriate,
+6. the error log file.
+
+The error log is stored at:
+
+| Operating system | Path |
+|---|---|
+| Linux / macOS | `~/.praktiKST/kst4contest-errors.log` |
+| Windows | `C:\Users\<YourName>\.praktiKST\kst4contest-errors.log` |
+
+Please inspect the file briefly before uploading it. An error log mainly contains technical information, but depending on the problem it may also include local file paths or other contextual data.
+
+Some file and directory names still use the technical name `praktiKST`. They refer to the same program.
+
+---
+
+## Acknowledgements
+
+Many functions and corrections in KST4Contest originate from observations made during actual contest operation. Reports that describe not only what happened, but also under which conditions it happened, are particularly useful.
+
+Special thanks go to:
+
+- Gianluca Costantino (IU3OAR)
+- Alessandro Murador (IZ3VTH)
+- Reczetár István (HA1FV)
+- Viliam Petrik (OM0AAO) for the DX Cluster idea
+- Konrad Neitzel (DC9DJ) for his work on the project structure
+- Andreas (DO5ALF), webmaster of funkerportal.de
+- Franz van Velzen (PE0WGA) for testing
+- Philipp (DN9APW) for further development of KST4Contest and the CI/CD infrastructure
+- all other testers and contributors who supplied reproducible reports, ideas and corrections
+
+Not every suggestion can be implemented unchanged. Nevertheless, reports from real operation remain an important basis for deciding which problems should be solved first.

github_docs/en-Installation.md

@@ -0,0 +1,437 @@
+# Installation
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Installation)
+
+KST4Contest is distributed as a ready-to-run application package for Windows, Linux and macOS. The official release packages do not require a separate Java installation: the required Java runtime is already included.
+
+In practical terms, you need a supported operating system, an internet connection and an ON4KST account. That sounds manageable—and usually it is.
+
+## Requirements
+
+### ON4KST account
+
+KST4Contest is an independent client for the ON4KST chat, but it does not replace the corresponding user account.
+
+If you do not have an account yet, you can create one on the official ON4KST website:
+
+- [ON4KST login and registration](https://www.on4kst.org/chat/login.php)
+
+ON4KST specifies English as the common language for the chat. This also applies when both stations happen to share another language. During contests, the usual amateur radio abbreviations such as `pse`, `agn`, `qrg`, `dir`, `rrr`, `tnx` and `73` are widely used.
+
+Using the chat and sending personal messages are covered in the user interface chapter. For the installation, the only thing that matters at this point is that the account works.
+
+### Screen size
+
+A usable screen area of approximately **1200 × 720 pixels** or more is recommended.
+
+KST4Contest automatically adapts the main window to the available area of the primary screen. The application can therefore also be started on smaller displays. Less space is still less space, however: not all tables, filters and additional information can then be displayed at a useful size at the same time.
+
+### Java
+
+The ready-made packages from the [GitHub Releases](https://github.com/praktimarc/kst4contest/releases/latest) do not require a separate Java installation. The required runtime is distributed with KST4Contest.
+
+A Java development environment is only required if you want to build KST4Contest from source. For the AUR packages `kst4contest` and `kst4contest-git`, Java 21 and Maven are handled as build dependencies by the package manager.
+
+---
+
+## Stable, Beta or Nightly?
+
+KST4Contest is distributed through three development channels:
+
+| Channel | Intended use | Classification |
+|---|---|---|
+| **Stable** | Normal contest operation | Published version intended for regular use |
+| **Beta** | Focused testing before a Stable release | Pre-release version with a largely defined feature set |
+| **Nightly** | Early testing of new features | Current development state from the `main` branch |
+
+The **Stable version** is recommended for normal operation.
+
+Beta and Nightly builds may contain features that are not yet available in the Stable release. They may also contain unfinished workflows, changed settings or new defects. That is not an unusual failure of the release process; it is the purpose of a development channel.
+
+If a function in this manual is explicitly marked as **Nightly**, it is not necessarily part of the current Stable release yet.
+
+---
+
+## Download
+
+The current Stable version is available here:
+
+- [Latest KST4Contest release](https://github.com/praktimarc/kst4contest/releases/latest)
+- [All published releases](https://github.com/praktimarc/kst4contest/releases)
+
+The release page contains the application packages as well as the English and German PDF manuals.
+
+### Which package do I need?
+
+| Operating system | Package | Typical filename |
+|---|---|---|
+| Windows x64 | ZIP package | `praktiKST-v<version>-windows-x64.zip` |
+| Linux x86_64 | AppImage | `KST4Contest-v<version>-linux-x86_64.AppImage` |
+| Debian/Ubuntu amd64 | DEB package | `KST4Contest-v<version>-debian-amd64.deb` |
+| Fedora/RPM x86_64 | RPM package | `KST4Contest-v<version>-fedora-x86_64.rpm` |
+| Arch Linux x86_64 | Arch package | `KST4Contest-v<version>-archlinux-x86_64.pkg.tar.zst` |
+| Linux with Flatpak | Flatpak reference | `de.x08.KST4Contest.flatpakref` |
+| macOS Apple Silicon | DMG for ARM64 | `KST4Contest-v<version>-macos-arm64.dmg` |
+| macOS Intel | DMG for x86_64 | `KST4Contest-v<version>-macos-x86_64.dmg` |
+
+Only download application packages from the official GitHub Releases, the KST4Contest Flatpak repository or the linked AUR packages. Files from other sources may have been built differently, may be outdated or may have been modified.
+
+---
+
+## Installing on Windows
+
+KST4Contest is distributed as a ZIP package for Windows. A conventional installer is not required.
+
+1. Download `praktiKST-v<version>-windows-x64.zip` from the latest release.
+2. Extract the ZIP file completely into a dedicated folder.
+3. Open the extracted folder.
+4. Start `praktiKST.exe`.
+
+Do not start the application directly from the compressed ZIP file. KST4Contest consists of several files and a bundled runtime. Windows can only use this structure reliably after the archive has been extracted completely.
+
+The application settings are not stored in the extracted program directory. They are stored in your user profile:
+
+```text
+%USERPROFILE%\.praktiKST\preferences.xml
+```
+
+This allows a new application version to be extracted into a different directory without losing the existing settings.
+
+---
+
+## Installing on Linux
+
+Several Linux package formats are available. The appropriate choice depends less on KST4Contest itself than on your distribution and the way you prefer to manage updates.
+
+| Installation method | Useful when … |
+|---|---|
+| **Flatpak** | updates should be managed centrally and Flatpak is already in use |
+| **AppImage** | KST4Contest should run as a portable file without package installation |
+| **DEB/RPM** | the distribution’s native package manager should be used |
+| **Arch package/AUR** | Arch Linux, Manjaro or EndeavourOS is being used |
+
+### Flatpak
+
+For most Linux users, Flatpak is the simplest way to keep KST4Contest installed and manageable through the system’s update tools. The KST4Contest repository is GPG-signed and contains the Stable, Beta and Nightly channels.
+
+#### Installing Stable from the release file
+
+Download `de.x08.KST4Contest.flatpakref` from the latest release and open it with the software manager provided by your desktop environment.
+
+Alternatively, install it from a terminal:
+
+```bash
+flatpak install ./de.x08.KST4Contest.flatpakref
+```
+
+#### Adding the KST4Contest repository
+
+The repository only needs to be added once:
+
+```bash
+flatpak remote-add --if-not-exists kst4contest \
+https://praktimarc.github.io/kst4contest/kst4contest.flatpakrepo
+```
+
+You can then install the Stable version:
+
+```bash
+flatpak install kst4contest de.x08.KST4Contest//stable
+```
+
+#### Installing Beta
+
+```bash
+flatpak install kst4contest de.x08.KST4Contest//beta
+```
+
+#### Installing Nightly
+
+```bash
+flatpak install kst4contest de.x08.KST4Contest//nightly
+```
+
+All three KST4Contest channels use the same application ID. Installing multiple KST4Contest channels in parallel is therefore not supported.
+
+For example, to switch from Stable to Nightly:
+
+```bash
+flatpak uninstall de.x08.KST4Contest//stable
+flatpak install kst4contest de.x08.KST4Contest//nightly
+```
+
+This does not automatically remove the personal settings stored in `~/.praktiKST`.
+
+Installed Flatpak applications can be updated with:
+
+```bash
+flatpak update de.x08.KST4Contest
+```
+
+Depending on the desktop environment, the graphical software manager may also display or automatically install available Flatpak updates. The `flatpak update` command itself performs an update; it does not promise to turn up and run by itself one day.
+
+### AppImage
+
+The AppImage does not require a conventional installation.
+
+1. Download `KST4Contest-v<version>-linux-x86_64.AppImage`.
+2. Open a terminal in the download directory.
+3. Make the file executable:
+
+```bash
+chmod +x KST4Contest-v<version>-linux-x86_64.AppImage
+```
+
+4. Start KST4Contest:
+
+```bash
+./KST4Contest-v<version>-linux-x86_64.AppImage
+```
+
+The AppImage can then be moved to another location, such as `~/Applications`.
+
+### Debian and Ubuntu
+
+Install the DEB package with:
+
+```bash
+sudo apt install ./KST4Contest-v<version>-debian-amd64.deb
+```
+
+Alternatively, open the file with a graphical package manager.
+
+### Fedora and compatible RPM systems
+
+Install the RPM package with:
+
+```bash
+sudo dnf install ./KST4Contest-v<version>-fedora-x86_64.rpm
+```
+
+### Arch Linux: installing the release package
+
+The Arch package downloaded from the GitHub Release can be installed directly:
+
+```bash
+sudo pacman -U KST4Contest-v<version>-archlinux-x86_64.pkg.tar.zst
+```
+
+### Arch Linux: installing from the AUR
+
+Three variants are available in the AUR:
+
+| Package | Content |
+|---|---|
+| [`kst4contest-bin`](https://aur.archlinux.org/packages/kst4contest-bin) | Pre-built package from the current Stable release |
+| [`kst4contest`](https://aur.archlinux.org/packages/kst4contest) | Stable release built locally from source |
+| [`kst4contest-git`](https://aur.archlinux.org/packages/kst4contest-git) | Current development state from the `main` branch |
+
+For most users, `kst4contest-bin` is the straightforward option:
+
+```bash
+yay -S kst4contest-bin
+```
+
+To build the Stable release from source:
+
+```bash
+yay -S kst4contest
+```
+
+To build the current development state:
+
+```bash
+yay -S kst4contest-git
+```
+
+All three packages provide the same application and are therefore defined as conflicting with one another. Install only one variant at a time.
+
+AUR updates are included when the selected AUR helper checks for package updates, for example:
+
+```bash
+yay -Syu
+```
+
+They do not happen automatically merely because the package came from the AUR.
+
+---
+
+## Installing on macOS
+
+> **Best-effort support:** The macOS packages are built together with the other releases, but they are not tested to the same extent as the Windows and Linux versions. Feedback is welcome; fully tested support for every macOS version and hardware variant cannot currently be guaranteed.
+
+Apple Silicon Macs require the package marked `arm64`. Intel Macs require the package marked `x86_64`.
+
+1. Download the appropriate DMG file.
+2. Open the DMG file.
+3. Drag `KST4Contest.app` into the **Applications** folder.
+4. Start KST4Contest from the Applications folder or Launchpad.
+
+From version 1.42 onwards the macOS packages are signed with an Apple Developer ID and notarized by Apple. The first launch therefore works by double-clicking, without going through the context menu and without a security prompt. The notarization ticket is stapled into the DMG file itself, so the check also succeeds without an internet connection.
+
+To confirm that a downloaded package really is signed, check it in a terminal:
+
+```bash
+spctl --assess --type open --context context:primary-signature -v KST4Contest-v<version>-macos-arm64.dmg
+```
+
+The expected result is `accepted` together with `source=Notarized Developer ID`.
+
+### Versions up to and including 1.41.1
+
+Older packages are not notarized, so macOS blocks the first launch.
+
+If the application came from the official GitHub Release:
+
+1. Open the Applications folder in Finder.
+2. Right-click or Control-click `KST4Contest.app`.
+3. Select **Open**.
+4. Confirm the launch in the dialog that appears.
+
+Alternatively, macOS may provide an **Open Anyway** button under **System Settings → Privacy & Security**.
+
+---
+
+## Where are the settings stored?
+
+KST4Contest stores its settings and other local working files in the user’s home directory. The application directory and the data directory are separate.
+
+| Operating system | Data directory | Settings file |
+|---|---|---|
+| Windows | `%USERPROFILE%\.praktiKST\` | `%USERPROFILE%\.praktiKST\preferences.xml` |
+| Linux | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
+| macOS | `~/.praktiKST/` | `~/.praktiKST/preferences.xml` |
+
+Note the spelling `.praktiKST` with an uppercase `KST`. Linux and macOS distinguish between uppercase and lowercase letters. `.praktikst` would simply be a different directory.
+
+An application update does not remove this directory. Even so, creating a backup before a major version change or extensive configuration work is sensible.
+
+---
+
+## Updates
+
+When KST4Contest starts, it checks whether a newer Stable release is available. If it finds one, it displays an information window containing:
+
+- the installed version,
+- the latest Stable version,
+- a short overview of the main changes,
+- the changelog,
+- known issues,
+- a link to the corresponding GitHub Release page.
+
+![KST4Contest update notification](update_window.png)
+
+The update checker does not install anything. It reports the new version and opens the platform-neutral release page. From there, you must select the appropriate package for Windows, Linux or macOS.
+
+### Updating Windows
+
+1. Close KST4Contest.
+2. Download the new Windows ZIP package.
+3. Extract it into a new or empty directory.
+4. Start the new version.
+5. Check that the existing settings have been loaded.
+6. Remove the old application directory only after that.
+
+The settings are preserved because they are stored under `%USERPROFILE%\.praktiKST`, not in the application directory.
+
+### Updating an AppImage
+
+1. Download the new AppImage.
+2. Make it executable.
+3. Start the new file.
+4. Remove the previous AppImage only after the new version works.
+
+### Updating Debian and Ubuntu
+
+```bash
+sudo apt install ./KST4Contest-v<version>-debian-amd64.deb
+```
+
+### Updating Fedora
+
+```bash
+sudo dnf upgrade ./KST4Contest-v<version>-fedora-x86_64.rpm
+```
+
+### Updating the Arch package
+
+```bash
+sudo pacman -U KST4Contest-v<version>-archlinux-x86_64.pkg.tar.zst
+```
+
+### Updating an AUR package
+
+Update the installed package through the selected AUR helper, for example:
+
+```bash
+yay -Syu
+```
+
+### Updating Flatpak
+
+```bash
+flatpak update de.x08.KST4Contest
+```
+
+### Updating macOS
+
+1. Download the new DMG file for the appropriate architecture.
+2. Close KST4Contest.
+3. Open the DMG file.
+4. Replace `KST4Contest.app` in the Applications folder.
+5. Start the new version and check the existing settings.
+
+The configuration under `~/.praktiKST` is not affected.
+
+---
+
+## Problems during the first launch
+
+### Windows reports an unknown application
+
+KST4Contest is not currently signed with a commercial Windows code-signing certificate. Windows or an additional security product may therefore warn about an unknown or rarely downloaded application.
+
+Check the following first:
+
+- Did the file come from the [official KST4Contest release](https://github.com/praktimarc/kst4contest/releases/latest)?
+- Does the filename match the published release?
+- Was the file downloaded completely?
+- Does the security product report a specific detection name or only a general reputation warning?
+
+A warning alone is neither reliable proof of malware nor automatically a false positive. If the origin of the file is unclear, do not run it or restore it from quarantine.
+
+Some users have reported quarantine messages from Norton 360 in particular. If the warning can be reproduced, please create a [GitHub issue](https://github.com/praktimarc/kst4contest/issues) and include:
+
+- the KST4Contest version,
+- the complete filename,
+- the security product and its version,
+- the reported detection name,
+- a screenshot of the warning, if possible.
+
+### The AppImage does not start
+
+Check the executable permission first:
+
+```bash
+chmod +x KST4Contest-v<version>-linux-x86_64.AppImage
+```
+
+Then start the file from a terminal. Error messages shown there are usually more useful than a double-click that simply produces no visible result.
+
+### macOS blocks the application
+
+From version 1.42 onwards this should no longer happen, because the packages are signed and notarized. If it does occur, the DMG file was most likely downloaded incompletely or modified afterwards; download it again from the official GitHub Release.
+
+On older versions the block is expected. Use the **Open** function described under [Installing on macOS](#installing-on-macos).
+
+### The problem remains
+
+First check whether the problem has already been reported under [GitHub Issues](https://github.com/praktimarc/kst4contest/issues). If it has not, create a new issue containing:
+
+- the operating system and version,
+- the KST4Contest version,
+- the installation method,
+- the exact error message,
+- the steps required to reproduce the problem.
+
+“It does not work” usually describes the situation accurately, but it is of limited value during diagnosis.

github_docs/en-Log-Sync.md

@@ -0,0 +1,231 @@
+# Log Synchronisation
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Log-Synchronisation)
+
+KST4Contest imports worked stations from the logging application and derives the global Worked status, per-band Worked marks and – where a locator is available – worked grid squares. Three input paths are available: the file-based Simplelogfile interpreter, the general QSO UDP listener and the dedicated Win-Test network listener.
+
+---
+
+![Log Sync Settings Window](client_settings_window_logsync.png)
+
+## Method 1: Universal File Based Callsign Interpreter (Simplelogfile)
+
+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.
+
+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
+
+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.
+
+If a band is available, the callsign is marked as worked on that band. If the packet also contains a valid locator, KST4Contest stores its four-character grid square for that band. Missing information is not inferred from unrelated fields.
+
+KST4Contest must be running when the packet is transmitted. Some logging applications can, however, resend an existing log: QARTest provides **Invia log completo**, while DXLog.net sends `contactreplace` packets when broadcasting the complete log. KST4Contest processes both mechanisms.
+
+**Default port:** `12060`
+
+---
+
+## Supported Logging Software
+
+### UCXLog (DL7UCX)
+
+![UCXLog Configuration](ucxlog_logsync.png)
+
+UCXLog sends QSO UDP packets and transceiver frequency packets.
+
+**Settings in UCXLog:**
+- Enable UDP broadcast
+- Enter the IP address of the KST4Contest computer (for local operation: `127.0.0.1`)
+- Port: 12060 (default)
+
+Note the green-highlighted fields in the UCXLog settings: IP and port must be filled in.
+
+Note for multi-setup (2 computers, 2 radios, one KST4Contest instance): Both logging programs must send QSO packets to the IP of the KST4Contest computer. In this case, at least one IP is not `127.0.0.1`.
+
+### QARTest (IK3QAR)
+
+![QARTest Configuration](qartest_logsync.png)
+
+**Special feature**: QARTest can send the **complete log** to KST4Contest (button "Invia log completo" in the QARTest settings). This means QSOs logged before KST4Contest was started are also captured.
+
+**Settings in QARTest:**
+- Configure UDP broadcast and IP/port as with UCXLog
+- Use "Invia log completo" for a full log upload
+
+*(„Buona funzionalità caro IK3QAR!" – DO5AMF)*
+
+### N1MM+
+
+**Settings in N1MM+:**
+
+In N1MM+ under `Config → Configure Ports, Mode Control, Winkey, etc. → Broadcast Data`:
+- Enable `Radio Info` (for TRX sync / QRG)
+- Enable `Contact Info` (for QSO sync)
+- IP: `127.0.0.1` (or IP of the KST4Contest computer)
+- Port: 12060
+
+For the built-in DX cluster server: configure N1MM+ as a DX cluster client (server: `127.0.0.1`, port as set in KST4Contest).
+
+### DXLog.net
+
+![DXLog.net Configuration](dxlog_net_logsync.png)
+
+**Settings in DXLog.net:**
+- Enable UDP broadcast
+- Enter the IP of the KST4Contest computer (green-highlighted fields)
+- Port: 12060
+
+When broadcasting the complete logbook, DXLog.net uses `contactreplace` instead of `contactinfo`. KST4Contest processes both packet types. Older QSOs can therefore be imported by starting a complete-log broadcast while KST4Contest is running.
+
+### Win-Test
+
+Win-Test is connected through a dedicated UDP listener for the native Win-Test network protocol. This listener is independent of the general QSO UDP listener on port `12060`.
+
+#### QSO and Worked synchronisation
+
+For a new QSO, KST4Contest imports:
+
+- the logged callsign,
+- the native Win-Test band ID, and
+- a valid locator where one is included in the packet.
+
+Band IDs for 50 and 70 MHz are processed in the same way as the VHF, UHF and SHF bands. The callsign is marked as worked globally and on the detected band. If a locator is also available, its four-character grid square is stored for that band.
+
+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.
+
+The QRG is selected in the following order:
+
+1. KST4Contest looks for the most recent QRG of the remote station on the explicitly selected band. The QRG must be no more than 30 minutes old. Active variants of the same base callsign are evaluated together.
+2. If no such QRG is available, KST4Contest checks the local QRG of the chat category in which the sked was created. It is only used if it can be parsed and actually belongs to the selected band.
+3. If neither source provides a matching QRG, no `ADDSKED` packet is sent.
+
+A fixed replacement frequency such as `144.300` is deliberately not used. During a contest, a technically successful handover containing the wrong band or QRG is worse than a visibly omitted handover.
+
+The internal sked remains intact in every case. This also applies when the broadcast address is invalid, the network fails or no Win-Test client can be reached.
+
+#### Handling KST callsign suffixes
+
+KST suffixes often identify a particular chat login or band. They are not necessarily part of the log callsign. KST4Contest therefore removes a suffix separated by `-` before handing the callsign over to Win-Test, while preserving portable and international callsign components:
+
+| Callsign in the KST chat | Callsign passed to Win-Test |
+|---|---|
+| `DN9APW-2` | `DN9APW` |
+| `9A0BB-70` | `9A0BB` |
+| `EA5/G8MBI/P-70` | `EA5/G8MBI/P` |
+| `DN9APW-2/P` | `DN9APW/P` |
+
+The complete callsign remains available inside KST4Contest. The timeline, reminder PMs and chat category continue to refer to the login which was actually selected.
+
+#### Mode, time and notes
+
+The mode is selected explicitly as `SSB` or `CW` when the sked is created. It is not inferred automatically from the QRG because a limited list of assumed band segments cannot represent every supported VHF, UHF and SHF band reliably.
+
+KST4Contest sends the actual scheduled time without adding an extra minute. Where available, the notes include the locator and QTF together with an indication that the sked was created through KST4Contest.
+
+The handover consists of the Win-Test packets `LOCKSKED`, `ADDSKED` and `UNLOCKSKED`.
+
+![Sked handed over from KST4Contest to Win-Test](wintest_sked_handover.png)
+
+#### Settings
+
+In the **Log sync** tab:
+
+- `Receive Win-Test network based UDP log messages`
+- `UDP-Port for Win-Test listener`, default `9871`
+- `KST station name in Win-Test network (src of SKED packets)`
+- `Win-Test network broadcast address`
+
+In the **TRX sync** tab:
+
+- `Win-Test STATUS QRG Sync`
+- `Use pass frequency from Win-Test STATUS`
+- `Win-Test station name filter`
+
+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)
+
+
+
+## TRX Frequency Synchronisation
+
+In addition to QSO synchronisation, UCXLog and other programs also transmit the **current transceiver frequency** via UDP. KST4Contest processes this information and makes it available as the `MYQRG` variable.
+
+![Frequency Buttons](qrg_buttons.png)
+
+**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
+- Win-Test STATUS packet (optional, configurable in the "TRX Synchronisation" tab under "Win-Test STATUS QRG Sync")
+- Manual entry in the QRG field
+
+> **Note for multi-setup**: With two logging programs on two computers, only **one** should send frequency packets. KST4Contest cannot distinguish between sources and processes all incoming packets.
+
+---
+
+## Multi-Setup: 2 Radios, 2 Computers
+
+For DM5M-style setups (2 radios, 2 computers, one KST4Contest instance or two separate):
+
+**Option A – One shared KST4Contest instance:**
+- Both logging programs send QSO packets to the IP of the KST4Contest computer
+- Only one logging program sends frequency packets (recommended: the VHF logging program)
+
+**Option B – Two separate KST4Contest instances (recommended):**
+- Each logging program communicates with its own KST4Contest instance via `127.0.0.1`
+- Two separate chat logins
+- Better separation and fewer conflicts
+
+---
+
+## Internal 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:
+
+| Source | Global callsign status | Per-band status | Grid square |
+|---|---:|---:|---:|
+| Simplelogfile | yes | no | no |
+| 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 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

@@ -0,0 +1,372 @@
+# Macros and Variables
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Makros-und-Variablen)
+
+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
+
+| Mechanism | Access | Use |
+|---|---|---|
+| **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.
+
+---
+
+## Shortcut Buttons
+
+Shortcuts are configured under **Preferences → Shortcut Settings**.
+
+![Configuration of shortcut buttons and text snippets](client_settings_window_shortcuts.png)
+
+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).
+
+---
+
+## Text Snippets
+
+Snippets are configured under **Preferences → Snippet Settings**. They are intended primarily for recurring messages to a particular station.
+
+Snippets can be opened:
+
+- 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.
+
+### Using the Context Menu
+
+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.
+
+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
+```
+
+The complete visible callsign, including any suffix, is retained. Selecting `9A0BB-70` may therefore produce:
+
+```text
+/cq 9A0BB-70 pse ur qrg?
+```
+
+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.
+
+If no station is selected, or no snippet exists for the selected key combination, nothing is inserted.
+
+The prepared text is not sent automatically:
+
+- `Enter` or **TX** sends the message.
+- `Esc` clears the send field.
+
+### Keyboard Mapping
+
+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 are reserved placeholders within message text. They must be written in uppercase and are case-sensitive.
+
+Variables can be used in:
+
+- shortcuts,
+- snippets,
+- beacon texts, and
+- message text entered or pasted directly into the send field.
+
+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.
+
+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.
+
+---
+
+## Global Variables
+
+Global variables do not require a selected remote station.
+
+| 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 |
+
+For example,
+
+```text
+cq at MYQRGSHORT, qtf MYQTF, loc MYLOCATOR
+```
+
+may be resolved to:
+
+```text
+cq at 144.388, qtf 135, loc JO51IJ
+```
+
+### QRG Variables
+
+`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.
+
+`MYQRGSHORT` uses the same value, but limits it to the first seven characters:
+
+```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
+
+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
+
+If an AirScout candidate is available, `FIRSTAP` contains its description and the expected time until the reflection window.
+
+For example:
+
+```text
+a very big AP in 2 min
+```
+
+If no aircraft is available for the selected station, KST4Contest inserts:
+
+```text
+no ap available
+```
+
+### SECONDAP
+
+`SECONDAP` uses the second available AirScout candidate.
+
+For example:
+
+```text
+Next big AP in 9 min
+```
+
+If there is no second candidate, `SECONDAP` is replaced with an empty string.
+
+Further information about the aircraft data is available under [AirScout Integration](en-AirScout-Integration#ap-variables-in-messages).
+
+### 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 use only global variables:
+
+- `MYQRG`
+- `MYQRGSHORT`
+- `SECONDQRG`
+- `MYLOCATOR`
+- `MYLOCATORSHORT`
+- `MYCALL`
+- `MYQTF`
+
+`QRZNAME`, `FIRSTAP` and `SECONDAP` are not resolved in a beacon and should not be used there.
+
+A possible template for the first chat category is:
+
+```text
+calling cq at MYQRGSHORT, ant MYQTF deg, loc MYLOCATOR
+```
+
+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 already appear in the next beacon message.
+
+The fully resolved beacon text:
+
+- 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
+
+For example, the first configured snippet may contain:
+
+```text
+Hi QRZNAME, pse sked? I call at MYQRGSHORT
+```
+
+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

@@ -0,0 +1,513 @@
+# User Interface
+
+> 🇬🇧 You are reading the English version | 🇩🇪 [Deutsche Version](de-Benutzeroberflaeche)
+
+## Connecting to the Chat
+
+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.
+
+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)
+
+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)
+
+The central table of all currently active chat users. Columns (depending on configuration):
+
+| Column | Content |
+|---|---|
+| Callsign | Station callsign |
+| Name | Name and additional information from the chat name field |
+| QRA | Maidenhead locator |
+| QRB | Distance in km |
+| QTF | Direction in degrees |
+| QRG | Most recent frequency detected in a chat message |
+| Tropo | Result of the band-specific tropo or path assessment |
+| Score | Current, numerically sortable priority score of the normalised base callsign |
+| Act | Minutes since the most recent activity |
+| AP | AirScout aircraft data, when enabled |
+| worked | Per-band Worked, band-opportunity and grid-square status, plus `wkdany` |
+| 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.
+
+The **wkdany** subcolumn is band-independent: `x` means that the callsign has been worked, `o` means that the grid square has been worked on any band, and `xo` means both.
+
+Each status cell has a tooltip containing the legend and the state derived for that station. For the complete calculation, including NOT-QRV precedence, see [Worked Callsigns, New Bands and New Grid Squares](en-Features#worked-callsigns-new-bands-and-new-grid-squares).
+
+![Band-specific Worked status and worked grid squares](worked_band_status.png)
+
+**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
+
+The send field contains the prepared text for the next outgoing message.
+
+When an operator deliberately selects a station in the user list using the mouse or keyboard, KST4Contest prepares a directed message:
+
+```text
+/cq CALLSIGN
+```
+
+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`.
+
+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.
+
+---
+
+## Table Widths and Truncated Cell Values
+
+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.
+
+Manually changed column widths are saved automatically and restored at the next start. Later messages or station updates do not overwrite that choice.
+
+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)
+
+### 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.
+
+---
+
+## Station Info Panel (Further Info)
+
+The lower-right panel combines the messages associated with the selected station. This includes public messages, private messages to the local station and, where visible in the chat, private messages addressed to other stations.
+
+The selected filter controls which of these messages are displayed. Under **Settings → GUI**, the default filter can be set to:
+
+- all messages,
+- private messages to the local station,
+- private messages to other stations, or
+- public messages.
+
+This setting changes the Further Info display only. Messages are neither discarded nor removed from the other message tables, and the filter can be changed at any time for the currently selected station.
+
+The lower part of the panel contains per-band **Not QRV** marks for the selected station. Individual controls are shown for the bands enabled in the local station settings. **tag not qrv all** sets or removes the mark for every supported band, including bands which are not currently visible.
+
+The change immediately affects the **NOT QRV @** column, band opportunities and the corresponding filters. It is stored in the internal database and restored after a restart.
+
+![Per-band NOT-QRV marks in the Further Info panel](not_qrv_controls.png)
+
+The current **Priority score** of the selected station is displayed in the same section.
+
+**Sked fail** marks an unsuccessful attempt and strongly reduces the score of the normalised base callsign. **Reset fail** removes the mark. It applies to all active suffix and category variants of the station and remains active for the current program session.
+
+The controls underneath are used to create a sked:
+
+| Control | Meaning |
+|---|---|
+| **Sked in** | Time remaining until the sked |
+| **Band** | Agreed band selected from the locally enabled bands |
+| **Mode** | `SSB` or `CW` for a possible Win-Test handover |
+| **Create sked** | Create the internal sked |
+| **Remind-PM in** | Enable automatic reminder PMs |
+| **2+1**, **5+2+1**, **10+5+2+1** | Times at which reminder PMs are sent before the sked |
+
+![Sked controls in the Further Info section](sked_controls.png)
+
+The proposed band is derived from recent QRG and name information for the station. It can be changed explicitly before creating the sked. The mode selection only affects the Win-Test handover; the internal sked and reminder PMs work independently.
+
+**Create sked** always creates the appointment inside KST4Contest first. If the Win-Test network listener is active, KST4Contest then attempts an additional handover to Win-Test. If no QRG matching the selected band can be found or Win-Test cannot be reached, the internal sked, its priority contribution and any scheduled reminders remain intact.
+
+The complete derivation and limitations are described under [Skeds and Sked Reminders](en-Features#skeds-and-sked-reminders).
+
+---
+
+## Priority List
+
+The compact priority bar is located on the right-hand side between the user list and the Further Info section. It displays the two currently highest-ranked candidates directly in the main window:
+
+```text
+Priority:  1 CALLSIGN SCORE  2 CALLSIGN SCORE  more
+```
+
+Clicking either candidate selects the corresponding active chat member. The complete callsign, including its suffix and chat category, is used.
+
+The **more** button opens a separate window containing up to 15 candidates. The list is sorted by descending score. Double-clicking an entry selects the candidate and closes the window.
+
+![Priority Score, compact candidate list and Further Info controls](priority_score_overview.png)
+
+Stations with a score of `0` are not included in the priority list. They remain visible in the user list so that the reason for their exclusion can be examined and, for example, an incorrect NOT-QRV mark can be changed.
+
+The score is calculated for the normalised base callsign. Several active variants such as `9A0BB-2` and `9A0BB-70` may therefore display the same value in the user list. They nevertheless remain separate message targets.
+
+New messages, AirScout data, skeds and status changes request a new calculation. A periodic refresh also runs in the background. A briefly outdated order is therefore not an error.
+
+Calculation and limitations: [Priority Score and Priority List](en-Features#priority-score-and-priority-list-from-v140).
+
+---
+
+## Station Map
+
+The station map can be opened in two ways:
+
+- **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 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`.
+
+![Station map with a selected station and visible path analysis](station_map_path_analysis.png)
+
+### Selecting a Station
+
+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 `/cq` recipient.
+
+Chat logins with the same normalised base callsign and position may share one marker. They nevertheless remain separate message targets inside KST4Contest.
+
+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,
+- the Earth-curvature or refraction model,
+- radio and terrain horizons,
+- Fresnel-zone clearance,
+- detected obstructions,
+- the link budget,
+- estimated received power, and
+- a summarised path assessment.
+
+The analysis uses the same centrally derived band as the Reachability functions. A band explicitly selected in the **Reachability** dropdown is taken into account.
+
+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 **Path analysis is hidden** message and **Show path analysis** button remain visible, so the function can be restored directly.
+
+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
+
+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 | Content |
+|---|---|
+| **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 |
+
+![Global message tabs in the main window](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.
+
+**wkd TX?** and **wkd RX?** show the global Worked state of the two base callsigns. These values are not band-specific.
+
+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.
+
+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.
+
+### Separate Monitor 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 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.
+
+The window can be hidden and restored through:
+
+```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** 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 standard light colour scheme.
+- **Show / hide station map** opens or closes the separate station-map and path-analysis window.
+
+---
+
+## Window Sizes and Dividers
+
+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, correcting it manually is sufficient; the new size is saved automatically.
+
+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**: 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.