​

Dependencies & build environment

Software can look correct in source form and still fail because its dependencies or environment assumptions are wrong. FORGE treats dependency and environment context as part of the build.

​

Dependency manifests

FORGE should preserve and update the project’s normal dependency manifest rather than inventing a parallel package system. Examples include the package or dependency files already used by the repository.

​

Add dependencies intentionally

A new dependency should have a reason. Before adding one, FORGE should consider whether the project already contains an equivalent library or pattern. Unnecessary dependencies increase build time, security surface, and maintenance burden.

​

Version compatibility

When the project pins runtime or framework versions, generated code should respect those versions unless the task explicitly includes an upgrade.

​

Environment variables

Source code can reference environment variables, but secret values should never be hardcoded into generated files or artifact examples. Document required variable names and purposes while keeping actual secret values outside FORGE prompts and artifacts.

​

Installation and validation

Where the build environment supports dependency installation, FORGE can use the resolved project state for validation. If installation is unavailable or fails because of network/private registry constraints, validation should report that limitation clearly.

​

Native/platform-specific dependencies

Some dependencies require operating-system packages, native compilers, GPUs, proprietary SDKs, or external services that the FORGE environment may not contain. Treat those projects as partially validated unless the required environment is actually available.

​

Reproducibility

Prefer lockfiles and existing package-manager conventions when the project uses them. A build that depends on floating dependency versions can behave differently when rerun later.