تشغيل أي مهارة في Manus بنقرة واحدة

forze-deps-consumption

النجوم٢

التفرعات٢

آخر تحديث٢٢ يونيو ٢٠٢٦ في ٠٠:٥٣

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.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

morzecrew

morzecrew/forze

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·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.

المزيد من هذا المستودع

نفس المستودع

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

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.