@forge-kit-dev/core
v0.2.0
Published
Harness orchestrator, module loader, and conflict resolver for forge.
Downloads
43
Readme
@forge-kit-dev/core
The orchestration layer. Defines the Harness, the Module contract, the module loader, the rule conflict resolver, and file-path helpers for .forge/runs/<runId>/.
Design tenets
- Thin by construction.
@forge-kit-dev/corehas no host-specific code. The CLI brings in a runtime adapter (@forge-kit-dev/cliimports@forge-kit-dev/coreplus theclaude-coderuntime in v0.1) and wires it intonew Harness(...). That means:- core typechecks without Claude Code types in scope
- tests instantiate Harnesses with a stub runtime
- a v0.2 standalone adapter (Anthropic SDK) can be added without touching core
- Fail at construction, not at first run. The Harness validates active module presence and detects rule conflicts in its constructor. A misconfigured project should be unable to start a run.
- Determinism.
loadModules()sorts by precedence,composePrompt()walks modules in load order and skills in declaration order. This is what makesforge test:meta-eval(Step 10) meaningful.
What's here vs what's in Step 9
Everything except Harness.run() is fully implemented in v0.1. run() is intentionally a throwing stub — the pipeline it will drive depends on @forge-kit-dev/agents + a concrete runtime, both of which ship in Step 9. The signature is already frozen so the CLI and modules can type-check against the full API.
