Three new article modules: configuration binding, profiles and config data, Spring AOP

configuration-properties/  @ConfigurationProperties vs @Value on Spring Boot 4.1.1.
  The relaxed-binding matrix is generated by binding each spelling rather than
  transcribed, and re-checked against real processes -- the in-process probe was
  wrong twice before it was right. Records the three findings that came out of it:
  @Value does get relaxed resolution inside Spring Boot (Boot attaches
  ConfigurationPropertySources), the configuration processor silently stops
  generating metadata on JDK 23+ when declared as a plain dependency, and @Valid is
  not what makes nested constraints run.

profiles-and-config/       Precedence, profiles, spring.config.import and config trees.
  /precedence reports every source holding a property in rank order with file and
  line, which turns "my profile file had no effect" into a two-line answer. Also
  pins the counterintuitive one: an imported file outranks the file that imported it.

spring-aop/                Designators, proxy types, and aspects that do not fire.
  One advice per supported designator so the reference table is generated from real
  matches; all fourteen unsupported designators fed to the parser. Two corrections to
  the reference documentation: unsupported designators throw
  UnsupportedPointcutPrimitiveException (extends RuntimeException, not
  IllegalArgumentException), and spring-boot-starter-aop was renamed to
  spring-boot-starter-aspectj in Boot 4.

19 contract tests across the three modules, 15 captured transcripts, all regenerated
by scripts/run-all.sh. Verified on Spring Boot 4.1.1, Spring Framework 7.0.9,
JDK 25.0.4.1.

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

configuration-properties/docs/03-registration.md

@@ -0,0 +1,45 @@
+[← Relaxed binding](02-relaxed-binding.md) · [Index](../README.md) · [Records and defaults →](04-records-and-defaults.md)
+
+# 3. Getting the bean registered
+
+`@ConfigurationProperties` on a class does nothing on its own. The class has to become a bean,
+and there are three ways to arrange that:
+
+| How | Where it goes | When to use it |
+|---|---|---|
+| `@ConfigurationPropertiesScan` | on the application class | most applications; scans a package |
+| `@EnableConfigurationProperties(Foo.class)` | on any `@Configuration` class | libraries, or when you want the list explicit |
+| `@Component` | on the properties class itself | works, but mixes a stereotype into a value type |
+
+This project uses `@ConfigurationPropertiesScan`, on
+[`ConfigBindingApplication`](../src/main/java/com/ankurm/configprops/ConfigBindingApplication.java).
+
+## The failure
+
+If none of the three is present, the class compiles, the application starts, and the bean does
+not exist. Injecting it fails with `NoSuchBeanDefinitionException` — which is at least loud.
+
+The quiet version is worse: with constructor binding, a properties *record* that is never
+registered simply never appears, and if the only thing that used it was optional, nothing
+complains at all.
+
+## Constructor binding and `@Autowired` do not mix
+
+A type bound through its constructor is built by the binder, not by the container. It cannot
+have collaborators injected into that constructor, because every parameter is treated as a
+property to bind. If a properties type needs a collaborator, it is not a properties type.
+
+## `@ConfigurationProperties` on an `@Bean` method
+
+Legal, and useful when the type comes from a library you cannot annotate:
+
+```java
+@Bean
+@ConfigurationProperties(prefix = "demo.thirdparty")
+ThirdPartyConfig thirdPartyConfig() {
+    return new ThirdPartyConfig();
+}
+```
+
+This uses setter binding, not constructor binding — the object already exists by the time the
+binder sees it.