@intentic/need-resolver

The need resolver: turns an authored IntentSet into the abstract capabilities it requires. It owns the authored intent shapes and the intent → needs derivation, the first stage of the pipeline. Depends only on @intentic/graph; consumed by @intentic/state-resolver and @intentic/sdk.

Responsibilities

• Define the authored intent shapes (IntentSet, HostIntent, CloudflareIntent, AppIntent, …) and their input types.
• Derive the abstract Needs an intent implies (source-control, docker-registry, infra-control, deployment-target, domain) each a Capability on a Plane (control vs application).
• It stops at abstract capabilities: it does not choose concrete options (Forgejo/Komodo/etc.) or emit graph nodes, that is state-resolver's job.

Key files

• src/intent.ts: the authored intent types (IntentSet and friends).
• src/inputs.ts: input shapes (HostInput, CloudflareInput, EnvironmentInput, NotifyInput, …).
• src/needs.ts: resolveNeeds, Capability/Need/Plane, needKey.
• src/index.ts: public surface.

How it fits

Stage 1 of intent → needs → desired-state. The sdk builds an IntentSet from a deploy.config.ts; resolveNeeds turns it into Needs; state-resolver assigns each need a catalog option and emits nodes.

Conventions & gotchas

• Needs are intentionally provider-agnostic: keep concrete tech names out of this layer.
• Each need carries its Plane; downstream resolution and ordering rely on it. Co-located tests in src/needs.test.ts. See ARCHITECTURE.md.