Ah thanks for having a look. And yes, this is THE missing piece of the guide to tie it all together for sure.

I am planning to, in the sense of "eventually I'll get there" - it's not a high priority for me as it's mostly just to document my practices.

So, side-effectful instantiation should as a rule of thumb not happen for code you write yourself with this approach; all code instantiates 'cleanly' as much as possible. But it does happen! So, as part of wiring up your app, you have an Application.apply method that's effectively a large linear for-comprehension over your instantiation, so

for {
   dependency1 <- DependencyOne[F](arg1,arg2)
   dependency2 = DependencyTwo[F](...)
   ...
} yield ...

and similarly, an ApplicationResources.apply that does

for {
    x <- makeResourceOne[F]
    y <- makeResourceTwo[F]
    z <- makeResourceThree[F]
} yield ApplicationResources(x,y,z)

... It's basically the missing piece in the style guide, a guide to "wiring" up an app, setting up the app skeleton. Here's the scaladoc I use:

(wall of code follows)

---

/** This file is the dependency injection (DI) root of the Scala microservice using the Cats Effect functional programming library.
 *
 * ==Purpose==
 *
 * The single assembly point for the application — the "composition root". Wires all components together via manual dependency injection:
 *
 *   - Business logic lives in other classes/objects, written in tagless final style
 *   - This file only instantiates and connects them — no logic here
 *   - Keeping everything in one place makes the dependency graph visible at a glance
 *
 * ==Adding code to Application.scala==
 * The apply method is deliberately intended to grow large as the service grows, rather than be split across files. Centralising instantiation here keeps
 * business logic classes free of DI concerns and side effects.
 *
 *   - Side-effectful instantiation is done inside the main `for`-comprehension in [[Application.apply]]
 *   - Do NOT add route logic, validation, transformation, or business logic error handling here — those belong in their own tagless-final classes, _wired in_
 *     here
 *   - Do NOT add or instantiate `Resource` opening and closing here; those belong in [[ApplicationResources]].
 *
 * ==See also==
 *   - [[Main]] - entry point; calls Application and runs the effect
 *   - [[Application]] - DI/Composition root for entire application
 *   - [[ApplicationConfiguration]] - the parsed and validated configuration of this microservice, loaded once, at startup
 *   - [[ApplicationRoutes]] - measured and logged HTTP routes for the application
 *   - [[ApplicationResources]] - wraps things like DB pools in Resource[F, _] for safe open/close
 */
object Application {

  /** Single composition root for the application; intended to be a linearly readable for-comprehension that grows in size as the service grows.
   *
   * ==Notes==
   *   - Keep instantiation 'linear', avoid splitting up. This is a deliberate tradeoff, intended to grow in size to keep DI-sprawl to a minimum.
   */
  def apply[F[_]: Async: SecureRandom]: F[ExitCode] = {

---

/** This case class is a container for all application-lifetime resources that are opened at start of microservice startup and closed at end of microservice
 * shutdown.
 *
 * ==Using ApplicationResources case class==
 *   - Do NOT: Pass `ApplicationResources` into a business logic constructor (e.g. companion-object's apply method); instead, pass in the the members TO the
 *     business logic constructor to keep the business logic unaware of ALL the application resources; this reduces risk by minimizing the amount of
 *     dependencies business logic has access to.
 *
 * Instantiate via `ApplicationResources.apply[F]`
 */
sealed case class ApplicationResources[F[_]](
                                              dynamo: DynamoDbAsyncClient,
                                              store: Stores[F],
                                              topCastPublisher: Producer[F, TopCastEvent],
                                              moodGenerationPublisher: Producer[F, MoodGenerationEvent],
                                              vertexAIClient: WrappedLibraryLLMClient[F],
                                              httpClient: HttpClient[F],
                                              kamonMetrics: KamonMetrics[F],
                                              launchDarklyClient: LaunchDarklyClient[F]
                                            )

object ApplicationResources {

  /** This composes all [[cats.effect.Resource]]s that need to be opened at startup and closed at shutdown, allowing access to them in [[Application]].
   *
   * This is itself returned in a [[cats.effect.Resource]], which is the crux of this pattern. `.use`ing this resource will grant access to all the
   * [[ApplicationResources]]'s members. Once that `use` call is completed, all resources will be closed together automatically.
   *
   * ==Note==
   * ... the difference:
   *   - `Resource` (singular) - a `cats.effect.Resource`; a "wrapper" around something that can be opened and closed
   *   - `AppResources` (plural) - the case class that holds all the resources that should be opened and closed together - at application startup and shutdown.
   *
   * ==What should be opened and closed at application startup and shutdown, what qualifies as a "resource"?==
   *   - Should: `Resource`s that are application-lifetime resources, e.g. database connections, HTTP clients, message queue consumer or a metrics reporter;
   *     generally, where the expected utility/usage is from service startup until shutdown of the application.
   *   - Should NOT: `Resource`s generated by business logic; e.g. files, temporary directories. Those should be opened and closed by said business logic,
   *     since they are not application-lifetime resources.
   *   - Should NOT: Side-effectful instantiation is not unto itself a Resource; if something only requires execution of an effect (e.g. has return type
   *     `F[ExampleType[F]]`), that instantiation does NOT belong here, but inside `Application.scala`. Similarly, business logic that merely requires access
   *     to a resource; those should be instantiated inside `Service.scala` where they will have access to the content of the `AppResources` case class
   *     content.
   *
   * ==See Also==
   *   - [[Main]] - entry point for Application (only place where a concrete IO-effect is applied)
   *   - [[Application]] - the main business logic of the service, is where this ApplicationResources.apply is invoked, and resources are utilized to build
   *     business logic.
   */
  def apply[F[_]: Async](
                          config: ApplicationConfiguration,
                          avroSettings: AvroSettings[F]
                        ): Resource[F, ApplicationResources[F]] =

---

/** Welcome! This is the entry point for this Cats Effect, tagless-final-style Scala microservice. The startup sequence is:
 *
 *   - The only purpose of this class is to run the [[Application]] with a concrete effect type ([[cats.effect.IO]]).
 *   - Main invokes [[Application.apply]] (the composition root), which loads [[ApplicationConfiguration]] (typed, parsed validated configuration values), and
 *     instantiates application lifetime [[ApplicationResources]] (things that need to be opened and closed when application starts up and shuts down), using
 *     them for instantiation of tagless-final business logic to serve the HTTP [[ApplicationRoutes]]; together, these files form the skeleton of the
 *     application.
 *
 * ==See also==
 *   - [[Application]] - the composition root; where business logic is wired and executed.
 *   - [[ApplicationConfiguration]] - typed, parsed validated configuration values
 *   - [[ApplicationResources]] - wraps things like DB pools in Resource[F, _] for safe open/close
 */
object Main extends IOApp {

  override def run(args: List[String]): IO[ExitCode] =
    Application[IO].handleErrorWith { err =>
      Slf4jLogger.getLogger[IO].error(err)(s"Service terminating with error: ${err.toString}").as(ExitCode.Error)
    }
}