[Hanabi9248]

AsyncTask.createMonitor extracts classpath resources and uses SshUtil.getCurrentDirPath() for the local archive path. Two existing helper behaviors break that flow: encoded file URLs leave a literal %20 in paths containing spaces, and AlertAutoScalingServiceImpl.parseRuleXml passes the actual monitor/ivory/alert-rule.xml file to copyDirFilesFromJar, whose IDE branch unconditionally traverses it as a directory and dereferences a null listFiles() result.

This change decodes the two existing file-URL boundaries once, preserving literal +. In the IDE resource branch, a regular file is now copied through the existing copy(dirPath) pipeline and returns; directory recursion and the JAR branch remain unchanged. getAllFile keeps its directory contract. The existing CodeSource selection, JAR-path truncation, output-directory/CWD policy, SSH behavior and build configuration are unchanged.

Validation used the complete real SshUtil plus five unchanged official support classes, real cached dependencies, real URLClassLoader/TCCL, Spring resource resolution, filesystem streams/copies and private byte-for-byte Spring JAR copies. No replacement Spring/JSch/copy implementation or service was used. Two distinct rounds were run:

• Earlier URL-path revision: baseline 2 failures plus 4 passing controls → 6 passes. The failures were the space-containing CodeSource and classpath directories. Unicode already passed on this runtime and remains a control. These six cases were not rerun for the later single-file increment.
• New single-resource increment, compared against the already published URL-path version: the actual official XML and a nonempty binary each failed in regular-file directory traversal; the nonempty recursive directory control passed. The final candidate passed all 3 new cases, checking complete copied bytes, all four XML rule names/thresholds, nested directory copying and unchanged source files. Both complete-class compilations succeeded.

The standalone runners are in tests/regression. After compiling the complete production/support classes and the runners with the real dependencies, use ResourcePathRegression <private-ASCII-directory> <classes> <spring-core.jar> <other-runtime-jars...> for the first suite, and ResourceFileRegression ide <private-directory> <classes> <spring-core.jar> cloudnative/src/main/resources/monitor/ivory/alert-rule.xml <other-runtime-jars...> for the new suite. The shared marker is ResourcePathMarker. Published runners differ from the executed files only by license comments.

Environment: Windows, JDK 25.0.4.101 with --release 8; existing Spring core/jcl 5.2.10.RELEASE, Hutool 5.8.20, JSch 0.1.55, commons-io 2.6, slf4j-api 1.7.30 and Lombok 1.18.42. The project declares Lombok 1.18.20, which was not tested. SLF4J used its standard NOP fallback; log contents were not tested.

Not run: Maven/full backend, original Lombok 1.18.20/JDK 8 runtime, Linux, Unix JAR resource control or Windows JAR branch, Spring Boot packaging, actual monitor readiness/controller/database flow, deployment/SSH/SCP, or arbitrary-working-directory behavior. The XML test invokes the real copy helper and parses its copied XML; it does not instantiate the whole alert service. No full deployment success is claimed.