Versions, evidence & contributing
Read support claims with their exact boundaries, inspect source and help keep the documentation honest.
What this documentation describes
Documentation source version: 1.4.0. Recorded capability evidence baseline: commit 75535bd739d7eefd43523dcc63799436c472fe12, scope reviewed . The build revision identifies the documentation sources; the evidence baseline identifies recorded capability scope. Uncommitted work in other checkouts is excluded.
Source presence is not release-channel availability. An artifact carrying the same version number may predate a source feature. Match agent/client integrations and inspect the source/release associated with the downloaded artifact.
How to read a support claim
| Label | Meaning | How to use it |
|---|---|---|
| Reloads | The documented path supports the change within its stated shape. | Read the conditions, then check your application result. |
| Conditional | An opt-in, special JVM, restricted adapter or follow-up action is needed. | Meet the prerequisites before treating it as supported. |
| Restart | The described change cannot be completed by this reload path. | Perform the named restart/schema/platform action. |
| Unverified | The current source registry lacks the required acceptance lane. | Run a relevant acceptance test; do not assume success or failure. |
| No reload | The source intentionally applies no Reclazz change for this case. | An unchanged definition can be a valid no-op; unknown file kinds belong to another pipeline. |
The project evidence registries make a finer distinction: watcher observations, component-only contracts, expected refusals, failed capabilities and unverified environments. A green characterization test for a refusal is not evidence that the feature reloads. Consult the original record for the exact verdict.
Named framework lanes are not a universal matrix
Stock SapMachine 17/21 on macOS arm64 are the main recorded lanes. The source targets Java 17+, but other JVM vendors, operating systems, future JDKs and enhanced VMs need their own acceptance evidence. Framework support is feature-specific:
- Core and ordinary Spring records name their own loader/shape limits.
- Modern MVC callbacks and native request boundaries have explicit Spring 6.1.14 records.
- Messaging uses exact Kafka/JMS/Rabbit and broker combinations, listed in its guide.
- Current native Boot properties/YAML P5 evidence uses Boot 2.7.18, not a fresh complete Boot 3 matrix.
- File-template observers do not establish packaged-resource or full view integration.
- SDK-derived Spring graphs are not deployed SAP tenant or cluster acceptance.
Trace the claims to the project
Contribute a verified improvement
Open source under Apache 2.0, with separate trademark terms for the name and mark. Start with a minimal synthetic reproduction and an observable before/after result. For a new support claim, record version, operating system, JVM, classloader, attachment route and the exact supported/unsupported shapes.
Keep tutorials, task guides, explanation and reference distinct. Put prerequisites before actions, keep example paths synthetic, and attach limitations to the claim they qualify. Update the support record and the relevant guide together.
Development trust boundary
Writing watched class output can execute code in the application JVM. Opt-in ImpEx/schema features can change the development database. Treat watch directories as trusted application inputs. The local socket binds to 127.0.0.1 and may expose class names and paths to other users who can reach it on the host.
This documentation adds no analytics or remote search. Search runs in your browser against the site’s static index. External project links and the site’s existing font host are separate network requests.
Sources & version scope
Documentation source 1.4.0 · evidence baseline 75535bd · reviewed 19 October 2026. Check your installed artifact; source features may postdate a release.