docs: document application.properties.local usage for conformity testing

.github/workflows/docs-link-check.yml

@@ -21,7 +21,7 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
       - name: Check Markdown links
-        uses: lycheeverse/lychee-action@v2
+        uses: lycheeverse/lychee-action@e7477775783ea5526144ba13e8db5eec57747ce8
         with:
           # Offline (local links and #anchors only) on pull requests, full check otherwise
           args: >-

AGENTS.md

@@ -231,7 +231,8 @@ When updating the IETF protocol implementation for a new draft revision, follow
 ### 4. Conformity Test Suite Maintenance & Subagent Isolation
 Whenever a new draft revision of the RUFH specification is published, the repository's Python conformity test suite (`scripts/rufh_conformity_test.py`) MUST be reviewed and updated by a separate, dedicated subagent.
 - **Strict Isolation Rule**: The subagent tasked with updating `scripts/rufh_conformity_test.py` MUST ONLY consult the official IETF specification document (and RFC 9530) and MUST NOT inspect the Java server implementation code under `src/main/java/`. This ensures the conformity test suite remains an independent, unbiased specification benchmark.
-- **Default Multi-Backend Execution**: When executing the conformity test suite (`scripts/rufh_conformity_test.py`), tests MUST be run by default against all three supported storage backend types (Disk: `/test/api/upload`, S3: `/test-s3/api/upload`, and Azure Blob: `/test-azure/api/upload`) as documented in [`docs/CONFORMITY_TESTING.md`](docs/CONFORMITY_TESTING.md).
+- **Default Multi-Backend Execution**: When executing the conformity test suite (`scripts/rufh_conformity_test.py` and `scripts/tus_conformity_test.py`), tests MUST be run by default against all three supported storage backend types (Disk: `/test/api/upload`, S3: `/test-s3/api/upload`, and Azure Blob: `/test-azure/api/upload`) as documented in [`docs/CONFORMITY_TESTING.md`](docs/CONFORMITY_TESTING.md).
+- **Execution with application.properties.local**: When running the Spring Boot demo server for conformity testing, if `application.properties.local` is present (in `tus-java-server-spring-demo/spring-boot-rest/src/main/resources/application.properties.local`), the server MUST be executed using that file (passing `--spring.config.import=optional:file:spring-boot-rest/src/main/resources/application.properties.local[.properties]` or running from `tus-java-server-spring-demo` where `spring.config.import` loads it) so that the local configuration (such as real cloud S3 and Azure credentials) is used during conformity testing.
 
 ### 5. Conformity Test Suite Audit — Repeatable Procedure
 Use this procedure to audit `scripts/rufh_conformity_test.py` against the current (or a new) specification revision. The goal is to identify untested MUST/SHOULD/MAY requirements and produce an actionable improvement report.

docs/CONFORMITY_TESTING.md

@@ -34,6 +34,9 @@ mvn clean install -DskipTests
    ```bash
    cd ../tus-java-server-spring-demo
    mvn clean package -DskipTests
+   # If application.properties.local is present, spring.config.import in application.properties automatically loads it.
+   # You can also pass it explicitly if running from another directory:
+   # --spring.config.import=optional:file:spring-boot-rest/src/main/resources/application.properties.local[.properties]
    java -jar spring-boot-rest/target/spring-boot-rest-0.0.1-SNAPSHOT.jar --tus.server.max-upload-size=1024
    ```