clean-architecture-backend-template/docs/superpowers/plans/evidence/2026-08-15-wave0-baseline.md

# Wave 0 — Red Baseline Evidence

- Repository HEAD at capture: `2f5d2fc21954286213c1474d19935f571ef896ea`
- Captured: 2026-08-15
- Toolchain: JDK 21.0.11, Gradle 9.0.0, Docker Engine 29.7.2, Docker Compose 5.4.0
- Plan: [`2026-08-15-wave0-red-baseline.md`](../2026-08-15-wave0-red-baseline.md)

## Exit state

```
$ cd src && ./gradlew wave0RedReport --console=plain --no-daemon
BUILD SUCCESSFUL in 1m 7s
```

**12 red, 1 unexpectedly green.** The red set matches the plan's expected table except for
`StartupWarningZeroTest`, recorded as a deviation below.

| Red test | Closed by | Confirmed cause |
| --- | --- | --- |
| `SecretLeakScannerCharacterizationTest.methodCallWithSafeSuffixIsNotALeak` | Wave 2 C1 | safe-suffix `$` anchor cannot match past a captured `()` |
| `SecretLeakScannerCharacterizationTest.numericFencingIsNotALeak` | Wave 2 C1 | every `+` read as string concatenation |
| `FiveAdapterOffInventoryTest.jpaOffHoldsNothing` | Wave 1 T4/T9 | see JPA inventory below |
| `FiveAdapterOffInventoryTest.messagingOffHoldsNothing` | Wave 1 T7 | see messaging inventory below |
| `FiveAdapterOffInventoryTest.notificationOffHoldsNothing` | Wave 1 T3/T8 | see notification inventory below |
| `ShippedRuntimeFacadePresenceTest.mongoFacadeIsShipped` | Wave 1 T5 | `ClassNotFoundException` — not on the runtime classpath |
| `ShippedRuntimeFacadePresenceTest.graphQlFacadeIsShipped` | Wave 1 T6 | `ClassNotFoundException` |
| `ShippedRuntimeFacadePresenceTest.messagingPlatformFacadeIsShipped` | Wave 2 C3 | `ClassNotFoundException` |
| `DefaultProfileBootCharacterizationTest.localProfileStartsWithShippedDefaults` | Wave 1 T9 | relay-enabled with blank broker |
| `DefaultProfileBootCharacterizationTest.devProfileStartsWithShippedDefaults` | Wave 1 T9 / Wave 3 T2 | same validator reached first |
| `ComposeMergeCharacterizationTest.devStackRenders` | Wave 3 T3 | duplicate `/var/tmp/heap` mount target |
| `ReleaseManifestTaskExistenceTest.mongoReleaseContractNamesOnlyRegisteredTasks` | Wave 2 B5 | three unregistered tasks |

Green as planned: `StartupWarningRecorderTest`, `RuntimeMembershipClasspathAgreementTest`,
`ComposeMergeCharacterizationTest` base/local, `ShippedRuntimeFacadePresenceTest` JPA/notification,
`FiveAdapterOffInventoryTest` Mongo/GraphQL (vacuously — see Task 4), the three non-red scanner cases,
`DefaultProfileBootCharacterizationTest.prodProfileRefusesPlaintextJdbc`.

## Task 1 — secret scanner

```
$ ./gradlew :messaging:messaging-observability:test --tests '*SecretLeakScannerCharacterizationTest*'
SecretLeakScannerCharacterizationTest > RED: incrementing a fencing token is arithmetic, not concatenation FAILED
SecretLeakScannerCharacterizationTest > RED: a method call whose name ends in a safe suffix is not a leak FAILED
5 tests completed, 2 failed
```

The pre-existing repository failure this characterizes:

```
$ ./gradlew :messaging:messaging-observability:test --tests '*SecretLeakStaticScanTest*'
SecretLeakStaticScanTest > noSensitiveIdentifierIsConcatenatedIntoAString() FAILED
java.lang.AssertionError: [a concatenated secret never reaches the redactor, so it must not be written at all]
Expecting empty but was: ["KafkaSecurityConfigurer.java:104 + oauth.credentialId());",
    "InMemoryAdminOperationJournal.java:110 existing.leaseToken() + 1,"]
```

## Task 3 — off-state inventories

Captured from the failure messages, with all five switches off on `local`. These are the exact type
lists Wave 1 works down.

**JPA off** — a connection pool, the entity/repository scan, and the H2 vendor configuration all
exist:

```
com.zaxxer.hikari.HikariDataSource
dev.caskeleton.adapter.outbound.persistence.audit.DomainContextAuditContextPort
dev.caskeleton.adapter.outbound.persistence.config.PersistenceJpaConfig
dev.caskeleton.adapter.outbound.persistence.config.PersistenceVendorSettings
dev.caskeleton.adapter.outbound.persistence.failure.PersistenceExceptionTranslator
dev.caskeleton.adapter.outbound.persistence.failure.StandardSqlStateErrorMapping
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.FileTransitionRepository
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.FileserverCleanupRepository
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.FileserverQuotaRepository
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.FileserverRecoveryRepository
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.JpaFileRepository
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.JpaUploadSessionRepository
dev.caskeleton.adapter.outbound.persistence.fileserver.repository.UploadLeaseRepository
dev.caskeleton.adapter.outbound.persistence.h2.H2IdempotencyClaimRepository
dev.caskeleton.adapter.outbound.persistence.h2.H2LocalTimeoutConfigurer
dev.caskeleton.adapter.outbound.persistence.h2.H2OutboxClaimRepository
dev.caskeleton.adapter.outbound.persistence.h2.H2PersistenceConfig
dev.caskeleton.adapter.outbound.persistence.h2.H2SqlStateErrorMapping
(list truncated in the assertion message)
```

Confirms JPA-INT-001 and the JPA half of §4.3's consumer table: the Fileserver repositories are on
this list, which is why Wave 1 Task 4's `DataSourceRequirement` must name Fileserver as a relational
consumer rather than treating the pool as JPA's alone.

**Messaging off**:

```
dev.caskeleton.adapter.outbound.messaging.MessagingConfig
dev.caskeleton.adapter.outbound.messaging.MessagingSettings
dev.caskeleton.adapter.outbound.messaging.core.DisabledMessagePublisher
dev.caskeleton.adapter.outbound.messaging.kafka.KafkaAdapterConfig
dev.caskeleton.adapter.outbound.messaging.kafka.KafkaAdapterSettings
dev.caskeleton.adapter.outbound.messaging.outbox.DisabledOutboxMessagePublisher
dev.caskeleton.adapter.outbound.messaging.outbox.Slf4jOutboxRelayFailureReportAdapter
```

Note `DisabledMessagePublisher` and `DisabledOutboxMessagePublisher`: the sentinel behaviour is
correct, but off-invariant item 9 requires the **composition root** to supply it rather than the
adapter. Wave 1 Task 7 moves it.

**Notification off** — settings bind with the master off, which is NTF-INT-005 exactly:

```
dev.caskeleton.adapter.outbound.notification.NotificationConfig
dev.caskeleton.adapter.outbound.notification.NotificationRoutesSettings
dev.caskeleton.adapter.outbound.notification.core.RoutingNotifier
dev.caskeleton.adapter.outbound.notification.email.google.GoogleEmailNotificationAdapterConfig
dev.caskeleton.adapter.outbound.notification.platform.autoconfigure.NotificationPlatformSettings
dev.caskeleton.adapter.outbound.notification.slack.webhook.SlackNotificationAdapterConfig
dev.caskeleton.bootstrap.notification.NotificationPlatformSecretsConfig$NotificationSecretsSettings
```

## Task 5 — default-profile boot

Both `local` and `dev` fail on the same validator, with the message it was written to give:

```
org.springframework.beans.factory.BeanCreationException: Error creating bean with name
'outboxRelayBrokerRequirementValidator' defined in class path resource
[dev/caskeleton/bootstrap/outbox/OutboxConfig.class]: ca-skeleton.outbox.relay-enabled is enabled
but app.messaging.broker is blank, so every claimed outbox row would fail to publish and be
exhausted to DEAD. Either configure a broker, or set ca-skeleton.outbox.relay-enabled=false so
PENDING rows are preserved until one exists.
```

`dev` reaches this validator before the `ddl-auto=update` conflict the spec recorded from `bootRun`,
so the `ddl-auto` failure is currently **masked**. It will surface once Wave 1 Task 9 sets
`relay-enabled: false`, and Wave 3 Task 2 closes it.

## Task 7 — Compose merge

```
$ docker compose -f docker-compose.yml -f docker-compose.dev.yml config
services.app.volumes[1]: target /var/tmp/heap already mounted as services.app.tmpfs[1]
```

Base and local render cleanly (`app`, and `app,db` respectively).

## Task 8 — runtime project closure

```
$ ./gradlew :app-bootstrap:runtimeClasspathManifest
$ cat app-bootstrap/build/architecture/runtime-project-closure.txt
```

The manifest resolves and `RuntimeMembershipClasspathAgreementTest` is **green** — direct
dependencies and the resolved closure agree today, because no build-only leaf is reachable. This is
the gate that must stay green while Waves 1 and 2 add the Mongo, GraphQL, and messaging edges.

## Task 9 — release manifest

```
ReleaseManifestTaskExistenceTest FAILED
the Mongo release contract names task(s) that no build file registers, so a release manifest can
report them green without ever running them
missing: [mongoAtlasTest, mongoKmsTest, mongoShardedTest]
registered: [mongoReplicaSetTest, mongoFailoverTest, mongoMigrationTest, mongoCompatibilityTest,
             mongoSecurityIntegrationTest, mongoPerformanceTest, mongoStableContractTest]
```

`scripts/verify-mongodb-advanced.sh:95` also invokes `mongoShardedTest`, so that script cannot
currently succeed either.

---

## Deviations from the plan

### 1. `StartupWarningZeroTest` is green, not red

The plan expected this red. It passes: an **all-off, non-web** `local` startup emits zero WARN and
zero ERROR.

That is not a contradiction of spec §9.1 — the warnings recorded there
(`BeanPostProcessorChecker` on the authorization beans, two Micrometer late-`MeterFilter` warnings,
a Flyway converter warning on `dev`) were observed during `bootRun`, which is a **web** application
with JPA active. This test is narrower than the configuration that produces them.

Consequence for Wave 4: `StartupWarningZeroTest` as written does not yet measure the warnings Wave 4
must remove. Wave 4 Task 6 already calls for extending it to all three environments and every one-on
combination; that extension must also use `WebApplicationType.SERVLET`, or the gate will keep
passing while the warnings remain. Recorded here so the omission is not discovered as a surprise.

### 2. A test-harness defect surfaced first, and is not a production defect

Booting `CaSkeletonApplication` in-JVM from `app-bootstrap`'s own test source set fails before any
adapter is examined:

```
BeanDefinitionOverrideException: Invalid bean definition with name 'outboxEventJpaRepository'
defined in ... @EnableJpaRepositories declared on PersistenceJpaConfig: ... there is already
[...] defined in ... @EnableJpaRepositories declared on OutboxContainerTestSupport.OutboxRepositoryConfig
```

Cause: `CaSkeletonApplication` component-scans `dev.caskeleton.bootstrap`; this module's test sources
live in that package; so an in-JVM boot discovers a **test-only** configuration
(`OutboxContainerTestSupport.OutboxRepositoryConfig`) that the shipped jar has never contained.

This is a property of the measurement, not of the product — `bootRun` is unaffected. Left alone it
would have reported the same cause for every activation characterization and hidden the defects they
exist to name. `ShippedCompositionHarness` registers a `TypeExcludeFilter` that drops candidates
whose class file came from a test output directory, which is a rule about provenance rather than a
class-name list somebody has to maintain.

**This is a workaround for measuring, not a fix.** The faithful instrument is running the produced
jar as a child process, which is what Wave 2 Task E3 builds for GraphQL. If Wave 1's off-invariant
work needs stronger evidence than the harness can give, promote the activation tests to that shape
rather than trusting the exclusion.

### 3. A property-precedence trap worth remembering

`SpringApplicationBuilder#properties(String...)` contributes to `defaultProperties`, the
lowest-precedence source, so the all-off set lost to `application.yml`'s `relay-enabled: true` and
the "all-off" context died on the relay validator. The harness passes `--key=value` command-line
arguments instead. Any later test that sets an all-off baseline must do the same.

## Files added by Wave 0

Production sources changed: **none**. Verified by inspection — every path below is a test source or
a Gradle lane registration.

| File | Kind |
| --- | --- |
| `src/messaging/messaging-observability/src/test/java/.../SecretLeakScannerCharacterizationTest.java` | test |
| `src/app-bootstrap/src/test/java/.../activation/AdapterActivationInventory.java` | test fixture |
| `src/app-bootstrap/src/test/java/.../activation/ShippedCompositionHarness.java` | test fixture |
| `src/app-bootstrap/src/test/java/.../activation/FiveAdapterOffInventoryTest.java` | test |
| `src/app-bootstrap/src/test/java/.../activation/ShippedRuntimeFacadePresenceTest.java` | test |
| `src/app-bootstrap/src/test/java/.../activation/DefaultProfileBootCharacterizationTest.java` | test |
| `src/app-bootstrap/src/test/java/.../activation/StartupWarningRecorder.java` | test fixture |
| `src/app-bootstrap/src/test/java/.../activation/StartupWarningRecorderTest.java` | test |
| `src/app-bootstrap/src/test/java/.../activation/StartupWarningZeroTest.java` | test |
| `src/app-bootstrap/src/test/java/.../compose/ComposeMergeCharacterizationTest.java` | test |
| `src/app-bootstrap/src/test/java/.../registry/RuntimeMembershipClasspathAgreementTest.java` | test |
| `src/app-bootstrap/src/test/java/.../registry/ReleaseManifestTaskExistenceTest.java` | test |
| `src/app-bootstrap/build.gradle` | lane registration (`runtimeClasspathManifest`, `wave0Red`) |
| `src/messaging/messaging-observability/build.gradle` | lane registration (`wave0Red`) |
| `src/build.gradle` | lane registration (`wave0RedReport`) |

---

# Wave 1 progress note (same session)

## The repository-wide `test` is green

```
$ cd src && ./gradlew test --console=plain --no-daemon --continue
BUILD SUCCESSFUL in 3m 20s
```

It was **red at HEAD** before this work, on `SecretLeakStaticScanTest` (spec §3.1). Two changes made
it green, and neither is a suppression:

1. **The scanner defect is fixed** (Wave 2 C1, pulled forward because it was the only thing keeping
   the build red). A captured method call keeps its trailing `()`, so the safe-suffix exemption's `$`
   anchor never matched — stripping the call fixes it, where unanchoring the pattern would also have
   exempted `credentialIdentity`, which does carry the value. And a `+` with a numeric literal on
   either side is arithmetic, which cannot put a secret into a string. The three true-positive cases
   in the characterization are what prove the fix was not a weakening.
2. **Wave 0's deliberately-red characterizations are excluded from the ordinary `test` task** and
   reported by `wave0RedReport` instead. A permanently red `test` is a build nobody can use, and a
   gate nobody can use stops catching the regressions it exists for. Wave 6 requires the tag set to
   be empty, so the exclusion cannot quietly become forgetting.

## Remaining red set: 4

| Red | Closed by |
| --- | --- |
| `ShippedRuntimeFacadePresenceTest.graphQlFacadeIsShipped` | Wave 1 T6 |
| `ShippedRuntimeFacadePresenceTest.messagingPlatformFacadeIsShipped` | Wave 2 C3 |
| `ComposeMergeCharacterizationTest.devStackRenders` | Wave 3 T3 |
| `ReleaseManifestTaskExistenceTest.mongoReleaseContractNamesOnlyRegisteredTasks` | Wave 2 B5 |

Down from 12 at the Wave 0 baseline.

## Known defect left as found: the shared-contract scope rule

`CleanArchitectureTest.SHARED_CONTRACT_CONTAINS_ONLY_OPERATIONAL_CONTRACT_PACKAGES` has two faults
that mask each other:

- its subject pattern is `..shared..`, which matches any package named `shared` anywhere rather than
  the shared-contract module;
- its allowlist contains the bare module root `dev.caskeleton.shared` and the check matches by
  prefix, so **every** package inside the module is blessed automatically.

Net effect: the rule catches nothing inside the module it is named after, and does catch unrelated
leaves that happen to have a `shared` package — which is how it surfaced, when the Mongo leaf joined
the composition root's analysis scope.

Fixing it properly requires the violation fixture that proves the rule works to move inside
`dev.caskeleton.shared`, which then puts the fixture in the rule's own analysis scope, which requires
reworking how fixtures are scanned. That is a separate change from adapter activation, so the rule is
left as found with the defect documented at the rule itself, and the Mongo tenancy package added to
the allowlist to keep the build honest in the meantime. **This is technical debt, not a fix.**

## Corrections to the spec and to these plans, found by executing them

| Claim | Reality |
| --- | --- |
| `ca-skeleton.idempotency.provider` | The property does not exist. It is `ca-skeleton.capabilities.idempotency.provider`. |
| `app.fileserver.enabled` | It is `app.fileserver-platform.enabled`. |
| Notification/GraphQL selectors are legacy master aliases | They are subordinate settings that stay valid while the adapter is on. Treating them as aliases made every shipped configuration ambiguous. |
| `AutoConfigurationImportFilter` registers in `.imports` | It registers in `META-INF/spring.factories`. Getting this wrong fails open silently — the filter simply never runs. |
| The JPA root can import one exported entry | Inverting the vendor→config import to create one produced a package cycle. The composition root names both vendor configs instead, and the export surface admits them with that reason recorded. |

## Shipping Mongo pulled in reactive Mongo

Adding the Mongo leaf to `app-bootstrap` put `spring-boot-starter-data-mongodb-reactive` and
`mongodb-driver-reactivestreams` on the runtime classpath. The index's scope boundaries exclude
reactive Mongo from the shipped Stable runtime, and leaving the starter there would have let Boot
build a second client and pool from the same URI as soon as the master switch went on. Both are
excluded at the composition root rather than in the leaf, which still compiles the reactive paths for
a future promotion.

---

# Session close — Wave 1 complete, Wave 2/3 partially landed

## Verified state

```
$ cd src && ./gradlew test --console=plain --no-daemon --continue
BUILD SUCCESSFUL in 2m 58s

$ ./gradlew verifyEnvKeys verifyCleanArchitectureDependencies \
    verifyRuntimeModuleMembership verifyPublicPathSnapshot
verifyRuntimeModuleMembership: 2 runtime composition(s) match the registry
BUILD SUCCESSFUL

$ ./gradlew wave0RedReport
1 red remaining
```

**12 red at the Wave 0 baseline → 1.** The survivor is
`ShippedRuntimeFacadePresenceTest.messagingPlatformFacadeIsShipped`, which Wave 2 C3 closes: the
messaging platform has no production sender, only a test fake, so giving it runtime membership now
would ship a path that cannot work.

## Wave 1 — complete (13/13)

| Task | Delivered |
| --- | --- |
| T1 | `MasterSwitch` / `MasterSwitchParser` in `shared-contract` — five names in one place, strict parse |
| T2 | `MasterSwitchEnvironmentPostProcessor` — rejects before any detail namespace binds |
| T3 | Both composition-root scans narrowed; the properties scan names its packages because it has no `excludeFilters` |
| T4 | `PersistenceJpaRootAutoConfiguration` + `DataSourceRequirement` + `JpaOffAutoConfigurationImportFilter` |
| T5 | Mongo shipped, one authority, reactive starter excluded from the runtime |
| T6 | GraphQL shipped, one authority, Boot GraphQL auto-configurations filtered |
| T7 | Messaging bridge gated; disabled sentinels moved to the composition root |
| T8 | `NotificationRootAutoConfiguration` — secrets and registries named rather than scanned |
| T9 | Migration, outbox and idempotency under capability roots |
| T10 | `CapabilityDependencyValidator` — 8 rules, each naming the exact missing switch |
| T11 | `DatabaseReadinessGroupPostProcessor` — `db` membership derived from the capability closure |
| T12 | 8 env registry rows + YAML binding + a contract test derived from the enum |
| T13 | Membership gate reads the resolved runtime closure instead of declared dependencies |

Measured effect, JPA off: **~30 beans → 0** (pool, entity scan, repositories, Hibernate, Flyway, DB
health all gone).

## Pulled forward from later waves

- **Wave 2 C1** — the secret scanner's two false positives fixed at the cause. This is what made a
  repository-wide green `test` possible; it had been red at HEAD.
- **Wave 2 B5** — the three ghost Mongo lanes demoted to `experimental_contracts` rather than
  implemented, with the script and doc updated to match.
- **Wave 3 T1** — profileless deploys refused, scoped to the deployable artifact so slice tests are
  unaffected.
- **Wave 3 T3** — the dev Compose `tmpfs: !override []` fix; merge verified and mount targets checked
  for uniqueness in the merged model.

## The defaulting cascade, and what it cost

Removing the relay's blanket refusal exposed the failure underneath it, exactly as this document
predicted — and then that one exposed a third. The sequence was:

1. relay-enabled with a blank broker (fixed in T9);
2. `ddl-auto=update` against a Flyway-owned schema (fixed by changing the tracked `.env`);
3. `logging.level.root` failing to bind, because **62 placeholders in `application.yml` had no inline
   default at all** and only `application-local.yml` pinned enough of them for one profile to start.

55 of those 62 now carry a default. The remaining seven are deliberate: the datasource URL, username
and password, the application name, and the JWT issuer and audience — a default for any of them is a
deployment running against something nobody chose. CORS allowed-origins was moved out of that set
after the fact: CORS is off by default and an empty origin list is the safest value rather than an
arbitrary one, so it defaults to empty.

One of the added defaults was itself wrong — `max-age-seconds` got `600s` while the field is a
`long` — which is worth recording because it only surfaced through a real boot. A bulk defaulting
pass needs a boot per profile to be believed.

## Still open

- `ShippedRuntimeFacadePresenceTest.messagingPlatformFacadeIsShipped` (Wave 2 C3).
- The `..shared..` ArchUnit rule remains defective and documented at the rule itself; see the earlier
  note. Unchanged this session.
- Waves 2 (remaining), 3 (Compose lane matrix, Keycloak, MinIO), 4, 5 and 6 are untouched.

---

# Continuation — Wave 3 T2 and Wave 4 T1 landed; a Wave 4 fix disproved

## Verified state

```
$ cd src && ./gradlew test                        BUILD SUCCESSFUL
$ ./gradlew verifyEnvKeys verifyCleanArchitectureDependencies \
    verifyRuntimeModuleMembership verifyPublicPathSnapshot
                                                  BUILD SUCCESSFUL
$ ./gradlew wave0RedReport                        2 red
```

## Wave 3 T2 — env source separation, complete

`src/.env` is untracked. `src/.env.example` (309 keys, generated from the registry, 12
secret-classified keys left empty) and `src/.env.local.example` are tracked in its place, and
`.gitignore` carries `src/.env*` with the two examples negated.

`verifyEnvKeys` now reads the example. Reading the real file made it false in **both** directions: it
passed only where an operator's own environment file happened to exist, and it would have passed with
no example at all — so the file an adopter actually copies was never verified, while a file full of
real credentials was a build input. Proven by deleting `src/.env` and re-running: green.

Its rule B was inverted while retargeting. It required every key in the file to be an
`application.yml` placeholder, which is true of a hand-maintained `.env` and false of a catalogue —
most registry keys are bound by typed settings inside a leaf. Inverted to "every registered `APP_` key
appears in the example", it now catches the drift that actually matters: a key added to the registry
that never reached the file an adopter copies.

`SPRING_PROFILES_ACTIVE` was also corrected in the registry — `type: enum`, `required: true`, no
default — to match Wave 3 T1.

## Wave 4 T1 — MeterFilter ordering, complete

`MetricsContractConfig` and `SampleMetricsContractConfig` both install their filters through a
`MeterRegistryCustomizer` instead of a `@PostConstruct` that fetched the registry. The warning was the
visible half of the real defect: a filter applies only to meters registered after it, so the
cardinality and distribution policies were being applied to some meters and not others. Both
composition roots changed together, because fixing one leaves the warning reproducible from the other.

The Boot 4 package is `org.springframework.boot.micrometer.metrics.autoconfigure`, found by inspecting
the resolved jars rather than assumed.

## Wave 4 T4 — attempted, disproved, and left as found

The spec calls the structured log's `profile` field a drift: it reads `SPRING_PROFILES_ACTIVE`, so
overriding the profile on the command line while a stale value sits in the environment stamps lines
with the stale one. The drift is real.

The obvious fix — bind the field to `spring.profiles.active` — **does not work**, and an existing
contract test said so. `LogProfileDriftCharacterizationTest` was written to settle the question by
observation rather than argument, and it observed an empty string: Logback initialises before that
property resolves. A field that says nothing is not an improvement on a field that is sometimes wrong.

The binding was reverted to what it was, with the reason recorded at the declaration, and the
characterization kept as a tagged red. The fix needs a different mechanism — setting the logger
context property from the resolved environment once it is ready, rather than declaring the source in
XML — which is Wave 4's to build.

## Remaining red: 2

| Red | Closed by |
| --- | --- |
| `ShippedRuntimeFacadePresenceTest.messagingPlatformFacadeIsShipped` | Wave 2 C3 — no production sender exists, only a test fake |
| `LogProfileDriftCharacterizationTest` | Wave 4 — needs the mechanism above |

---

# Continuation — Wave 3 Compose lane matrix (static half) and Keycloak realm

## Verified state

```
$ cd src && ./gradlew test                                          BUILD SUCCESSFUL
$ ./gradlew verifyEnvKeys verifyCleanArchitectureDependencies \
    verifyRuntimeModuleMembership verifyPublicPathSnapshot          BUILD SUCCESSFUL
$ ./scripts/verify-compose-profile-contracts.sh
  all 15 lanes match src/config/runtime/compose-profile-contracts.json
$ ./gradlew wave0RedReport                                          2 red
```

## What landed

**`src/config/runtime/compose-profile-contracts.json`** — the lane SSOT. 15 lanes, each fixing a
Compose profile, a file stack, an explicit Spring runtime, and the exact service set that stack must
render. Exact rather than superset: a lane that quietly gains a service is a lane whose evidence
describes a different stack than the one that ran.

**`docker-compose.infra.yml`** — every shared service, each carrying Compose profiles so nothing
starts unless a lane names it: PostgreSQL, a single-node Mongo replica set with an idempotent
initiator, Kafka, Mailpit, MinIO with bucket bootstrap, Keycloak, and the three one-shot smoke
clients. Infrastructure no longer lives inside environment overlays, which is what let `local` stop
meaning "the app plus a database".

**`docker-compose.prod-smoke.yml`** — a production-shaped runtime whose JDBC URL carries
`sslmode=verify-full`, so the prod validators are satisfied rather than bypassed.

**`scripts/verify-compose-profile-contracts.sh`** — the static entry point, wired into the ordinary
test suite so a lane cannot drift until somebody remembers to run a shell script. It checks the
Compose version floor, the exact service set per lane, the rendered `SPRING_PROFILES_ACTIVE`, and
mount-target uniqueness in the merged model.

**Keycloak realm** (`infra/keycloak/`) — `ca-skeleton-api` as a confidential client with a service
account, standard flow and direct access grant off, an audience mapper and realm/client role mappers.
The client secret is a `${...}` reference; the entrypoint reads it from a mounted secret file and
execs `kc.sh`, so no value reaches Git, the rendered config, or `docker inspect`.

**Smoke clients** — `auth-smoke` (the seven realm checks, against the same issuer URL the app is
given), `object-storage-smoke` (upload → HEAD → download → delete → wrong-credential rejection, none
skippable), `notification-smoke` (three phases, so the handoff lane's accept and verify are the same
client talking about the same request id).

## What the verifier caught immediately

Writing it was worth it before running anything. On first execution it failed four lanes:

- `off-local` rendered `app,db`, because the `db` service was still in the local overlay as well as
  in the new infra file;
- three lanes could not render at all, because the local overlay's `depends_on: db` pointed at a
  service their profile does not enable — Compose refuses that outright.

Both are the same mistake: infrastructure declared where the environment is described. `db` now lives
only in the infra file, and the `depends_on` is gone — ordering belongs to the runtime-smoke wrapper,
which knows which services a lane actually starts.

## Two follow-on defects found and fixed

**Untracking `src/.env` broke local Compose on a fresh clone.** `docker compose config` failed
outright because the local overlay declared `env_file: ./src/.env`. Marked `required: false`, and
verified by moving the file aside: the stack renders. A convenience override had become a hard
prerequisite for rendering the stack at all.

**The developer host-port contract moved with the service.**
`DeveloperExperienceContractTest.localComposePublishesTheHostPortTheCommittedDatasourceUrlTargets`
asserted against the local overlay. It now asserts against the infra file and additionally that the
service carries the `local-jpa` profile — without which the port assertion would pass for a service
no lane ever brings up.

## Still open in Wave 3

`scripts/run-compose-runtime-smoke.sh` — the dynamic half — is not written. Nothing here has been
started; what is verified is that all 15 lanes render exactly what they claim, with the right Spring
runtime and no mount collisions. The lanes have not been run, and this document does not claim they
have.

---

# Continuation — the Compose lanes actually run

## Verified state

```
$ cd src && ./gradlew test verifyEnvKeys verifyCleanArchitectureDependencies \
    verifyRuntimeModuleMembership verifyPublicPathSnapshot      BUILD SUCCESSFUL
$ ./scripts/verify-compose-profile-contracts.sh                 all 15 lanes match
$ ./scripts/run-compose-runtime-smoke.sh --lane off-local       passed
$ ./scripts/run-compose-runtime-smoke.sh --lane off-dev         passed
$ ./scripts/run-compose-runtime-smoke.sh --lane off-prod        passed
```

Each lane's own report, fetched from the running application rather than asserted from the flags the
lane passed in:

| lane | activeProfile | switches on | dataSourceRequiredBy |
| --- | --- | --- | --- |
| `off-local` | `local` | none | not required |
| `off-dev` | `dev` | none | not required |
| `off-prod` | `prod` | none | not required |

`docker ps -a` and `docker volume ls` show no surviving `casmoke` project or volume.

**This is the Wave 1 exit criterion, demonstrated for the first time in a real container:** all five
adapters off, three environments, no infrastructure of any kind, and the application reporting so
itself.

## What was built

`scripts/run-compose-runtime-smoke.sh` — the dynamic entry point. Unique project per lane, evidence
directory that refuses to reuse a previous run's, static contract then `config` then `create`,
`up --wait` on long-running services only, a bounded readiness poll, every declared one-shot with a
non-zero exit failing the lane, sanitized evidence, and a `trap` teardown scoped to the lane's own
project — logs collected before the teardown, not after.

`AdapterActivationEndpoint` / `AdapterActivationReport` — the application's own answer about what
resolved on. A lane asserting on its own environment passes whenever it set the variables correctly,
which is not the claim being made.

## Six defects the lanes found, in the order they surfaced

Each was invisible to every check that existed before, and none would have been found by reading.

1. **A stale image.** The app service declares both `build:` and `image:`, so Compose reused a tag
   from an older state of the repository — the first run failed on a class that no longer exists in
   the tree. The wrapper now builds explicitly. A lane running a stale image produces evidence about
   code nobody changed.
2. **The actuator is on its own connector.** Fetching `8080/actuator` returned an empty file that
   read exactly like a failed assertion about the profile.
3. **The activation endpoint was authenticated.** Management auth is JWT, so only a lane with an
   identity provider could have read it — excluding the all-off lanes, whose claim is the hardest to
   check any other way. It is now permit-all alongside health/info/prometheus, and
   `AdapterActivationReportShapeTest` holds it to property names and booleans so that stays true.
   `ManagementActuatorSecurityContractTest` records the allowlist decision rather than absorbing it.
4. **`off-local` was passing by luck.** It read the developer's own `src/.env` for the seven
   deliberately-undefaulted values. The wrapper now generates them per run, so a lane reproduces
   anywhere rather than on the machine it was written on.
5. **The dev overlay has no healthcheck**, so `up --wait` returned as soon as the container was
   created and the first fetch landed before startup finished. The wrapper polls with a bound rather
   than trusting `--wait` alone.
6. **`environment:` beat `env_file:` in the prod overlay.** `APP_DATASOURCE_PASSWORD:
   "${APP_DATASOURCE_PASSWORD:-}"` read the host shell, not the lane's generated file, and injected
   an empty string — which the prod env validator then refused, correctly, about a value the lane had
   actually supplied.

## Not claimed

The twelve infrastructure-bearing lanes have not been run. `--matrix` exists and is untested against
them; what is demonstrated is the three all-off lanes end to end and that all fifteen render exactly
what they claim. Keycloak, MinIO, Mongo, Kafka and Mailpit have been written and rendered, not
started.

---

# Continuation — the infrastructure lanes, and what running them found

## Verified state

```
$ cd src && ./gradlew test verifyEnvKeys verifyCleanArchitectureDependencies \
    verifyRuntimeModuleMembership verifyPublicPathSnapshot      BUILD SUCCESSFUL
$ ./scripts/verify-compose-profile-contracts.sh                 all 15 lanes match
$ ./scripts/run-compose-runtime-smoke.sh --matrix src/config/runtime/compose-profile-contracts.json
  all 4 blocking lanes passed
```

No surviving `casmoke` container or volume.

| lane | activeProfile | switches on | vendor |
| --- | --- | --- | --- |
| `off-local` | local | none | none |
| `off-dev` | dev | none | none |
| `off-prod` | prod | none | none |
| `local-mongo` | local | `persistence-mongo` | none |

`local-mongo` is the first adapter proven on against real infrastructure: a single-node replica set,
the Mongo master switch on, no other switch on, and no relational connection required.

## The contract gained two assertions, because a green lane was not yet a meaningful one

**`expectedSwitchesOn`.** A lane named `local-jpa` that ran with JPA off would render the right
services, start cleanly, and prove nothing. The wrapper now compares the switches the application
reports against what the lane asked for.

**`expectedPersistenceVendor`.** `local-jpa` passed for a while against H2 while the PostgreSQL
container it started sat untouched beside it — `application-local.yml` pinned an in-memory URL as a
literal, which outranks any environment a caller supplies. Every other field in the report looked
correct. The report now carries the vendor resolved from the JDBC URL, and the lane asserts it.

That pin was not unique. `application-local.yml` also pinned `app.messaging.broker: ""` and the two
notification provider selectors, so `local-messaging` started Kafka, set `APP_MESSAGING_BROKER=kafka`
and was refused by the dependency validator for a value it had supplied. All four are placeholders
now; the defaults are unchanged, so a developer who sets nothing gets exactly what they got before.

## Four defects in the wrapper itself

1. **It reported success for lanes it never ran.** `docker compose exec` consumes stdin, and inside a
   plain `while read` loop it ate the remaining lanes — the first ran, the loop ended, and the script
   said all six passed. Reading on fd 3 fixes it; a ran-count guard makes a partial matrix a failure
   rather than a pass. A wrapper whose own success message is a false green is worse than no wrapper.
2. **Compose project names reject uppercase**, so the run id is lowercased for the project while the
   evidence directory keeps the readable timestamp.
3. **`env_file` lists merge and the later file wins.** The developer's optional `src/.env`, declared
   by the local overlay after the base, silently overrode the lane's own values. Lane settings now go
   into a generated `environment:` overlay, which beats every `env_file` regardless of order.
4. **`up --wait` is not a readiness gate where no healthcheck exists** — the dev overlay has none, so
   the first fetch landed before startup finished. The wrapper polls with a bound.

## Two spec findings confirmed in a real composition, not inferred

**MSG-INT-003.** With a healthy Kafka and the broker selected, startup fails on a missing
`KafkaSender` bean: the legacy Kafka configuration requires a project-supplied sender, and production
has none — only the tests provide a fake. This is precisely why the messaging platform leaves must
not get runtime membership before a real transport bridge exists.

**GQL-INT-002.** `APP_GRAPHQL_DEPLOYMENT_MODE` is registered and bound, but the platform still reads
the old `production` boolean and `environment` enum, which default to `false` and `PRODUCTION_PUBLIC`.
The startup validator therefore sees a production deployment with introspection enabled and refuses.

A third was found that the spec did not predict: **shipping GraphQL into the same context as the rest
of the application produced two `Clock` beans**, because the platform's clock was conditioned on its
own bean *name* rather than on the type. Every injection point wanting a `Clock` failed to start. It
now backs off on the type, which is what auto-configuration is for — and this could not have happened
while the leaf was build-only.

## Lanes marked not-blocking, with reasons recorded in the contract

`local-jpa`, `local-messaging-outbox`, the three notification lanes, `shared-infra-local`,
`shared-infra-dev`, `prod-smoke` and `all-adapters` are blocked on an open JPA finding: the entity
scan is unconditional while the Flyway migration streams are partitioned by capability, so
`ddl-auto=validate` against real PostgreSQL fails on `fs_cleanup_item`. Scoping the entity scan to
active capabilities is Wave 2 JPA work.

`local-messaging` is blocked on MSG-INT-003 and `local-graphql` on GQL-INT-002, both above.

Each carries its reason in `compose-profile-contracts.json` and each keeps its assertions, so the
lanes fail loudly rather than passing against the wrong thing.