Run any Skill in Manus with one click

forze-deps-consumption

Stars2

Forks2

UpdatedJune 22, 2026 at 00:53

Explains how Forze resolves dependencies in applications: plain vs routed Deps, route=spec.name, built-in DepsModule composition, and merge conflicts. Use when debugging handler resolution or wiring Postgres, Redis, S3, and other shipped integration modules.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

morzecrew

morzecrew/forze

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	forze-deps-consumption
description	Explains how Forze resolves dependencies in applications: plain vs routed Deps, route=spec.name, built-in DepsModule composition, and merge conflicts. Use when debugging handler resolution or wiring Postgres, Redis, S3, and other shipped integration modules.

Forze dependency consumption

Use when wiring or debugging how your application resolves ports from ExecutionContext. For bootstrap and DepsRegistry, see forze-wiring. For mapping logical spec names to integration configs, see forze-specs-infrastructure. For a private integration not covered by shipped forze_* packages, see forze-custom-deps.

Plain vs routed

Deps registers providers in two shapes:

Mode	Shape	Use when
`Deps.plain({DepKey: value})`	one provider per key	shared clients, secrets, idempotency defaults
`Deps.routed({DepKey: {route: value}})`	one provider per key + route	specs resolved by `spec.name`

Shipped modules such as PostgresDepsModule, S3DepsModule, and InngestDepsModule return merged Deps containers. Your app passes them to DepsRegistry.from_modules(...).

How handlers resolve ports

You define a logical spec (DocumentSpec, QueueSpec, …) with a stable name (prefer a shared StrEnum).
The integration module maps that name to physical config (table, bucket, queue URL, …).
At runtime, ExecutionContext resolves the factory with route=spec.name, then builds the port.

Convenience helpers (ctx.document.query, ctx.storage, …) do this internally. For other dep keys:

port = ctx.deps.resolve_configurable(
    ctx, QueueCommandDepKey, order_queue, route=order_queue.name
)

Merge conflicts

Deps.merge(...) raises CoreException on duplicate plain keys, plain-vs-routed conflicts, or duplicate routed keys. Treat that as a wiring bug: two modules registered the same key/route, or you merged overlapping maps twice.

Lifecycle vs deps

Built-in DepsModule.__call__ should only register providers. Connection pools and clients start via LifecycleModule or LifecycleStep factories on your LifecyclePlan (PostgresLifecycleModule, postgres_lifecycle_step, s3_lifecycle_step, …). Keep deps and lifecycle as separate plans, freeze both, then pass the frozen registries to ExecutionRuntime. See forze-wiring.

Anti-patterns

Instantiating integration adapters in handlers — resolve ports from ExecutionContext.
Mismatching spec name and deps-module route keys — use one shared StrEnum for both.
Calling resolve_configurable without route=spec.name for spec-backed keys.
Opening network connections inside handler code — use lifecycle steps and registered clients.

Reference

Docs are versioned. These links use latest (the newest release). If your app pins an older forze minor, replace latest in the URL with that version (e.g. .../forze/0.3/...) or use the version selector on the site.

More from this repository

same repository

forze-messaging-streaming

morzecrew/forze

Uses Forze queue, pub/sub, and stream contracts with QueueSpec, PubSubSpec, StreamSpec, SQSDepsModule, RabbitMQDepsModule, Redis adapters, and Mock adapters. Use when producing, consuming, or testing async messages/events.

2026-07-032

forze-documents-search

morzecrew/forze

Implements Forze document and search access the kit-first way: DocumentFacade and SearchFacade over build_document_registry / build_search_registry, kit DTOs (DocumentIdDTO, ListRequestDTO, DocumentUpdateDTO), the query DSL, pagination, cache-aware DocumentSpec / SearchSpec, and the Postgres / Mongo / Firestore / Meilisearch backends behind them. Use when building data access features.

2026-06-302

measure-before-optimizing

morzecrew/forze

Optimize code only after a real, measured performance problem - distinguish macro (design-level) from micro (fine-tuned) performance, reach for data-structure and algorithm wins before micro-tweaks, profile to find real hotspots, and don't trade readability or adaptability for unmeasured speed. Use when optimizing code, reviewing performance suggestions, choosing "faster" constructs, or when the user mentions performance, optimization, speed, or efficiency.

2026-06-252

naming-things

morzecrew/forze

Name variables, functions, classes, and modules well by avoiding known anti-patterns - single letters, abbreviations, types baked into names, missing units, "Base"/"Abstract" class names, and "Utils"/"Helper" grab-bags. Use when naming or renaming code, reviewing names in a diff, or when the user mentions naming, identifiers, variable names, readability, or that a name feels off.

2026-06-252

never-nesting

morzecrew/forze

Keep code flat and readable by limiting indentation depth, using guard clauses with early returns, and extracting nested blocks into well-named functions. Use when writing or refactoring code with deep nesting, pyramid-shaped if/else, arrow code, or when the user mentions nesting, indentation, guard clauses, early returns, extracting functions, cyclomatic complexity, or making code more readable.

2026-06-252

self-documenting-code

morzecrew/forze

Make code explain itself instead of relying on comments - name sub-expressions, extract complex conditions into well-named functions, lean on the type system, and reserve comments for the "why" the code cannot express. Use when writing or reviewing comments, refactoring hard-to-read logic, deciding whether a comment is needed, or when the user mentions comments, self-documenting code, or code readability.

2026-06-252

name	forze-deps-consumption
description	Explains how Forze resolves dependencies in applications: plain vs routed Deps, route=spec.name, built-in DepsModule composition, and merge conflicts. Use when debugging handler resolution or wiring Postgres, Redis, S3, and other shipped integration modules.

Forze dependency consumption

Plain vs routed

Deps registers providers in two shapes:

Mode	Shape	Use when
`Deps.plain({DepKey: value})`	one provider per key	shared clients, secrets, idempotency defaults
`Deps.routed({DepKey: {route: value}})`	one provider per key + route	specs resolved by `spec.name`

Shipped modules such as PostgresDepsModule, S3DepsModule, and InngestDepsModule return merged Deps containers. Your app passes them to DepsRegistry.from_modules(...).

How handlers resolve ports

You define a logical spec (DocumentSpec, QueueSpec, …) with a stable name (prefer a shared StrEnum).
The integration module maps that name to physical config (table, bucket, queue URL, …).
At runtime, ExecutionContext resolves the factory with route=spec.name, then builds the port.

Convenience helpers (ctx.document.query, ctx.storage, …) do this internally. For other dep keys:

port = ctx.deps.resolve_configurable(
    ctx, QueueCommandDepKey, order_queue, route=order_queue.name
)

Merge conflicts

Lifecycle vs deps

Anti-patterns

Instantiating integration adapters in handlers — resolve ports from ExecutionContext.
Mismatching spec name and deps-module route keys — use one shared StrEnum for both.
Calling resolve_configurable without route=spec.name for spec-backed keys.
Opening network connections inside handler code — use lifecycle steps and registered clients.

Reference

Docs are versioned. These links use latest (the newest release). If your app pins an older forze minor, replace latest in the URL with that version (e.g. .../forze/0.3/...) or use the version selector on the site.