Verify a project after installing its tools

An installation finishing does not establish that a project builds or launches its intended entry point. Editor completion and AI-generated edits are process feedback. Verification connects the environment, dependency graph, launch command, and observable behavior.

The teaching application reads a synthetic document catalog, displays three records, and handles a search for a missing title. Define that run contract before selecting tools. A tool comparison needs the same task and acceptance conditions, rather than an unsupported speed ranking.

Manifests and lockfiles answer different questions

A manifest declares dependency requirements. A lockfile records a resolved dependency graph. Top-level declarations can contain version ranges, while the lockfile usually includes transitive dependencies and integrity information. A few package names do not describe the entire graph.

A lockfile also leaves other environment conditions unresolved. Runtime versions, operating systems, native dependencies, package-manager settings, environment variables, and external services can affect the result. Record the runtime and installation policy, with platform conditions where necessary. A lockfile alone cannot guarantee identical behavior on every computer.

Read the project's package-manager convention and scripts before installing. Mixing tools can create competing lockfiles. Review the manifest and lockfile together when dependencies change, especially unexpected broad updates. Installation can execute lifecycle scripts or native builds, so package provenance and execution permissions matter.

Understand npm ci before running it

The npm documentation states that npm ci requires an existing lockfile. It fails when the manifest and lockfile disagree instead of updating the lockfile. It also removes an existing node_modules directory before installation. Verify it in a disposable checkout or a dependency directory known to be rebuildable, rather than one containing manual edits.

Settings affecting dependency resolution may need to match those used to generate the lockfile. Read project configuration before choosing the command. Network access, registries, platform builds, and lifecycle scripts produce different failures. Preserve their errors and exit statuses instead of repeatedly deleting the lockfile.

After installation, run the project's declared checks, build, and startup steps. Script names do not guarantee their function: a script named test may contain only a placeholder. Inspect what it actually checks. Confirm build artifacts after a successful build and application behavior after startup.

Editors supply several kinds of evidence

A language server analyzes types and symbols. A formatter changes presentation. A debugger pauses execution and exposes state. A terminal runs project commands. These tools complement one another, but formatted code does not establish correct business behavior, and completion does not prove the launch process has the required dependencies.

VS Code launch configuration can specify an entry point, arguments, and environment. A debugger starting the catalog application below the project root may load different configuration from a terminal run. Document the expected directory and entry point, then compare the actual debugger settings. Machine-specific absolute paths rarely make suitable shared configuration.

Verify browser results against the intended data. An old process, cached page, or wrong port can still show a plausible application. Use synthetic record IDs or a clear version marker to identify the new build. Check empty results, loading errors, and retry behavior as well as the successful page.

Give an AI CLI a checkable task

AI coding tools may read repositories, edit files, and run commands. Their capabilities, authentication, and permissions differ by vendor and version. Verify those capabilities rather than infer them from a product name. Compare tools on the same small requirement and acceptance conditions.

For a missing-search fix, specify allowed files, response semantics, and check commands. Inspect the resulting diff, command record, exit statuses, and failure cases. A message saying the task is complete is insufficient. Even an executed command needs to cover the original defect.

Plugins and CLIs may execute with the current user's privileges. Inspect provenance, access scope, network requirements, and how task records are stored. Supply synthetic data and necessary context. Do not place credentials in project files or screenshots to simplify setup. A reversible local trial can establish whether the workflow fits.

Expose inconsistency with an offline contract

The example reduces the manifest and lock to mappings of names to exact versions. It verifies agreement, then changes only the declared version. This is a teaching contract, not an implementation of npm ranges, transitive resolution, integrity verification, or installation.

manifest = {"library": "1.2.0"}
lock = {"library": "1.2.0"}
def agrees(declared, resolved):
    return all(resolved.get(name) == version for name, version in declared.items())
assert agrees(manifest, lock)
manifest["library"] = "1.3.0"
assert not agrees(manifest, lock)
print(agrees(manifest, lock))

The output is False: the locked value remains 1.2.0 while the declaration becomes 1.3.0. The result establishes a disagreement in this simplified mapping. It cannot validate a real package-lock file or replace npm installation.

The check deliberately does not repair the lock automatically. Automatic agreement could hide who authorized the dependency update. Make intentional updates through the package manager and review their resolved graph.

For an application requiring backend services, distinguish local startup from dependency reachability. Project-provided stubs or synthetic data can support basic verification, but state which requests did not reach the real backend. Misclassifying an unavailable service as a frontend build failure leads to reinstalling unrelated dependencies.

Exercise: deliver run evidence

In a disposable copy, record runtime and package-manager versions, manifest and lockfile state, installation command, and exit status. Run the project's checks, build, and startup procedure. Verify the three synthetic records, an explicit empty state for an unknown search, and consistent behavior after refresh.

Introduce a manifest-lock mismatch, incorrect entry point, and missing required configuration. Each failure must be located at installation, startup, or application behavior, then retested through the original procedure after repair. Compare an editor-debugging workflow with an AI CLI using visible evidence, access scope, and recovery cost. An impression that one is smarter does not explain the choice.