Transmission #059: PDD — server Docker JAR/runtime split

Opened Prompt-Driven Development for server Docker/CI time: planning tree at .agents/planning/2026-05-05-server-docker-jar-runtime/ (rough-idea.md, idea-honing.md through Q11, research/, design/, implementation/). Goal is to stop paying in-image Gradle + findutils on every PR compose build, standardize a pre-built Shadow JAR, use amazoncorretto:25-alpine consistently, split arm64 dev (compose mount) vs amd64 registry, keep tests-first PR CI and move full docker build toward release (GHA + manual script), main-only automation, latest per product choice (see research gap vs current release.yml semver tags).

PDD: research pass (CI, release, Gradle)

Recorded research/existing-ci-release-compose.md (PR server-ci.yml flow, release.yml server/blog push and semver tags, compose/Docker/publish today) and research/gradle-shadow-openapi.md (OpenAPI resolution for sparse checkout, Shadow mergeServiceFiles, confirmed output helerion-server-1.0.0-all.jar). Highlights a requirements vs repo tension: honing asked for latest only, but release.yml still pushes ${VERSION} and latest—resolve in design or update honing.

PDD: iteration checkpoint

User marked research sufficient. Added iteration-checkpoint.md in the planning folder: consolidated requirements table, research pointers, and open decisions (registry tags vs honing, compose shape, CI step order). Awaiting explicit choice: detailed design (Step 6), more honing, or more research.

PDD: detailed design (Step 6)

Authored design/detailed-design.md as a standalone spec: overview, consolidated requirements (including §2.1 registry tag decision vs current release.yml), architecture and data-flow mermaid diagrams, components (Gradle, Dockerfile, Compose, scripts, GHA), artifact “data models”, error handling, testing strategy, appendices (tech choices, research summary, alternatives, open notes). Next PDD step is implementation plan (implementation/plan.md) after explicit go-ahead.

PDD: implementation plan + summary (Steps 7–8)

Added implementation/plan.md with a checklist and seven steps (Gradle JAR → Compose → slim Dockerfile → publish-server.sh → server-ci.yml → release.yml / latest only → docs). Each step includes objective, guidance, tests, integration, and Demo. Wrote summary.md listing artifacts and follow-ups. Ready to implement in-repo following the checklist.

Server Docker: slim runtime + host JAR (implemented)

Gradle: shadowJar now writes build/libs/helerion-server.jar (stable name); Flyway mergeServiceFiles unchanged. server/docker-compose.yml runs amazoncorretto:25-alpine with a read-only mount of that JAR (no server image build on compose up). server/Dockerfile is single-stage COPY of the same path. server/.dockerignore uses build/** exceptions so the JAR is in the build context. publish-server.sh runs ./gradlew shadowJar then docker build (no repo_root). PR CI runs shadowJar before docker compose up -d (no --build). release.yml sets up JDK/Gradle, shadowJar, then pushes server:latest only; release notes updated. server/README.md and .cursor/skills/helerion-publish/SKILL.md updated.

Gradle: plugin versions in the catalog

Shadow, OpenAPI Generator, Flyway, and nu.studer.jooq are now declared under [plugins] in server/gradle/libs.versions.toml and applied via alias(libs.plugins.*) in server/build.gradle, so their versions are not duplicated next to libs.*. jersey-container-grizzly2-http reuses version.ref = "jersey" (one number for the Jersey stack). The Studer plugin’s catalog version key is studer-jooq so it does not sit under the same jooq-* prefix as jooq — Gradle’s type-safe accessors would otherwise nest libs.versions.jooq and break libs.versions.jooq.get() in the jooq { } block.

PDD: release CI + remote reload

Started a second same-day PDD track (separate folder): .agents/planning/2026-05-05-release-ci-remote-reload/ — rough-idea.md, empty idea-honing.md, and research/, design/, implementation/ placeholders. Scope: trigger helerion-remote-reload (or equivalent) from release CI, with fallbacks (SSH limits, Python webhook, Docker orchestration) if direct script use from GitHub Actions is not viable.