transport-security-setup

Form 1: project-bootstrap and arch-adopt chain it by name, and a skill with disable-model-invocation: true cannot be called through the Skill tool — the reason sonarqube-setup stays model-invocable. Axis 2 of the interview — two callers, one of which runs inside a project where project-bootstrap does not exist — made it a skill of its own; the closest rejected form was a transport block inside security-architect, a design skill that writes docs only and runs per use case, so a project with no protected endpoint would never decide transport. Record: @.claude/decisions/0122-transport-security-setup-and-secrets.md.

Runs on sonnet with effort: low: one interview with fixed options, then edits per answer (@.claude/decisions/0080-procedural-skills-on-sonnet.md).

Project directory. When the caller's one-line context names project: <absolute path>, that directory is the project root, not the session's: read and write every path of this procedure under it, and run every shell command as (cd "<path>" && …). When this skill chains docker-architect, pass project: <path> on in its context.

grep -n "^\*\*Transport:" CLAUDE.md 2>/dev/null
grep -rnE "server\.ssl|ssl:|bundle:|forward-headers-strategy" --include='application*.yml' --include='application*.properties' . 2>/dev/null | grep -v /target/
grep -nE "spring-boot-starter-(security|jetty)" pom.xml build.gradle */pom.xml */build.gradle 2>/dev/null

• **Transport: found → entry rule: report and stop.
• pom.xml at the root → maven; build.gradle → gradle. The main module is the one with
• spring-boot-starter-security present → the security filter chain owns HSTS, and step 4 is
• spring-boot-starter-jetty present → topology B and C are not offered: Jetty does not reload

When a caller already passed an answer in its one-line context, don't ask it again.

First call — the topology, with one line of what each costs:

Second call, depending on the first:

• A or C′ — local edge: "Run a local Caddy edge in docker-compose, so HTTPS, HTTP/2 and HSTS
• B or C — two questions in the same call:

Merge into the main module's application.yml — into its existing roots, never a second server: or spring: key in the same document:

server.http2.enabled: true goes in for every topology.

Write templates/HstsHeaderFilter.java.example into the blueprint's configuration package plus .web (config.web, infrastructure.config.web); in a blueprint with no configuration package (hexagonal, onion, custom), into a web subpackage of the inbound REST adapter. Base package and package names come from the blueprint's packages.map, never from the exemplar.

With Spring Security present, nothing is written: its default header writer already sends the same value, and the filter would only override it.

For B and C, every @SpringBootTest must run with the test profile, or its context now starts with TLS on and fails reading /etc/tls (@.claude/rules/testing.md § Slices and context requires it anyway):

grep -rL '@ActiveProfiles("test")' $(grep -rl "@SpringBootTest" --include='*.java' src/test/ 2>/dev/null) 2>/dev/null

Add @ActiveProfiles("test") to each file listed. The generator's own *ApplicationTests is usually the only one.

A datasource in the context. When the project has a Testcontainers configuration —

grep -rl "class TestcontainersConfiguration" --include='*.java' src/test/ */src/test/ 2>/dev/null

Invoke docker-architect through the Skill tool with a one-line context, and only in these two cases. It owns every service block and the Dockerfile; don't write either here, not even when it looks like a copy.

• A or C′ with a local edge → "service edge (Caddy) and docker/caddy/Caddyfile, chained from
• B or C → "Dockerfile: the image also listens on 8443 (EXPOSE 8080 8443), chained from

No docker-compose.yml or Dockerfile at the root → docker-architect stops on its own entry rule; say so in the report.

Write the matching paragraph of templates/CLAUDE-transport.md.example into the root CLAUDE.md, placeholders filled, right below the **Bounded context: paragraph (or below the first heading when there is none). That template owns the wording.

When chained by project-bootstrap, skip: its own Verify runs next and covers the test this skill wrote. Otherwise run the project's full build — ./mvnw -B verify or ./gradlew build. A red test is reported with its first failing assertion, never "fixed" by loosening the configuration.

✅ Transport decided — topology <A edge | B direct | C mutual TLS | C′ mesh>

Configuration . <application.yml path> — <forwarded headers + trusted proxies | SSL bundle `webserver`, reload, 8443, TLS on except <profiles>> · HTTP/2 on
HSTS .......... <Spring Security's default writer | HstsHeaderFilter in <package>>
Test .......... <ForwardedHeadersIT | TransportSecurityIT> — <green in the build | runs in project-bootstrap's Verify> · @ActiveProfiles("test") added to <n files | none needed>
Container ..... <edge (Caddy) added by docker-architect | Dockerfile EXPOSE 8443 by docker-architect | not touched — <reason>>
CLAUDE.md ..... Transport paragraph written

Then the lines the person needs on day one, by topology:

• A / C′ — in each environment, set TRUSTED_PROXIES to the edge's addresses (CIDR list);
• B / C — mount the certificate and key (PEM, PKCS#8) as files and set TLS_CERTIFICATE and
• C — the bundle's truststore holds only the private CA that issues client certificates, from