Install and verify LMP locally

The repository includes install.sh as an idempotent local bootstrap. It provisions missing directories, builds the real Rust workspace, builds the required Docker sandbox image, and runs the 38-check qualification matrix.

This is the contributor/operator verification path, not the normal user onboarding path. A project user should start with Getting started and run npx create-lmp; use this page when you are validating the LMP checkout itself or preparing local benchmark evidence.

It does not replace Cargo.toml, .gitignore, Mind Packages, policies, or documentation. That is intentional: an installer must not destroy an existing checkout or silently replace the rules it is supposed to verify.

Standard installation

From the repository root:

./install.sh

The command requires Cargo, Python 3, Git, and a running Docker daemon. It creates ignored qualification output under lmp-test-results/ and exits non-zero if the Rust build, Docker setup, or qualification gate fails.

Check layout only

To validate the checkout without compiling or creating a Docker image:

./install.sh --check-only

This checks the Rust workspace members, bundled Mind Package, qualification runner, Docker definition, and expected directory layout.

Docker-unavailable development mode

./install.sh --skip-docker

This is useful for inspecting the layout on a machine without Docker, but it is not a successful end-to-end installation. The qualification artifact must report status: "blocked" until lmp-sandbox:local is available. Do not use this mode as release evidence.

Full real-OSS benchmark

The standard installer does not clone external repositories. Run the larger benchmark explicitly after the local qualification gate:

./install.sh --full-benchmark

The benchmark requires Docker and produces a complete result only when all 64 scenarios, 128 paired Docker gates, and all provenance checks pass. A partial, failed, or blocked artifact is not a release result.

What the installer proves

The installer verifies the checked-out implementation; it does not publish packages, deploy binaries to another host, or claim that a policy pass replaces human review and production testing.

Test unpublished packages from another project

The npm packages are not published yet. Developers testing LMP in a separate application should use a local package boundary rather than a registry version. Build the package first from this repository:

pnpm --filter @lending-mind/sdk build
pnpm --filter @lending-mind/lmp build

Tarball install (recommended)

This most closely resembles a real package install while keeping the package on the local machine:

mkdir -p /tmp/lmp-local-packages
pnpm --dir packages/core pack --pack-destination /tmp/lmp-local-packages
pnpm --dir packages/cli pack --pack-destination /tmp/lmp-local-packages

# Run this from the external test project.
pnpm add file:/tmp/lmp-local-packages/lending-mind-sdk-0.1.0.tgz
pnpm add file:/tmp/lmp-local-packages/lending-mind-lmp-0.1.0.tgz

Use the exact filenames printed by pnpm pack if the package version changes. The external project should then run its normal lmp init and evaluation commands. A tarball test verifies the files included by the package and avoids accidentally importing the repository's source tree.

Direct local path

For a fast test, a package can be referenced directly:

pnpm add /absolute/path/to/lend-mind-protocol/packages/cli

Or in package.json:

{
  "devDependencies": {
    "@lending-mind/lmp": "file:../lend-mind-protocol/packages/cli"
  }
}

The current packages use pnpm workspace dependencies during repository development. For an unrelated npm-only project, prefer the tarball path until the packages are published with registry-resolvable dependency metadata.

Linking for rapid iteration

Linking reflects rebuilt package changes immediately, but it is less faithful to a production install and can expose duplicate dependency trees:

# From the LMP repository.
pnpm --filter @lending-mind/lmp link --global

# From the external test project.
pnpm link --global @lending-mind/lmp

These methods are temporary developer-test paths. They do not create a public release, immutable package identity, or production support commitment.