scalp ci

CI pipelines don't have time for a multi-step dance. scalp ci is the equivalent of install --guarded + audit + a structured report, packaged as a single command that exits 0 or 1.

Usage

scalp ci [flags]

Flags

How it works

Basic usage

cd my-project
scalp ci

First run (no policy file):

! policy not found; allowing with audit

Report written to .scalp/ci-report.json:

{
  "version": "0.2",
  "passed": true,
  "audit": {
    "verified": 142,
    "mismatched": 0,
    "missing": 0
  }
}

CI with violations

If a package violates policy or trust scoring:

ci failed: [{"PackageID":"evil@1.0.0","Reason":"denylist","Rule":"pattern:*-free"}]

Report:

{
  "version": "0.2",
  "passed": false,
  "violations": [
    {
      "package": "evil@1.0.0",
      "reason": "denylist_match: pattern:*-free",
      "rule": "denylist"
    }
  ],
  "audit": {
    "verified": 0,
    "mismatched": 0,
    "missing": 0
  }
}

PR context

# For PRs from forks
scalp ci --pr-context fork

# For internal PRs
scalp ci --pr-context internal

Fork context forces require_hash: true and blocks install scripts. Internal context respects your policy.

SARIF report

scalp ci --sarif .scalp/report.sarif

Generates a SARIF 2.1.0 report alongside the JSON report. Each violation becomes a SARIF result.

Write report to stdout

scalp ci --output -

Useful for debugging or piping to other tools.

Allow scripts (internal only)

scalp ci --pr-context internal --allow-scripts

Why separate from install --guarded?

scalp install --guarded is a dev workflow — warnings, custom PM args, policy-dependent enforcement.

scalp ci is a pipeline command — always blocks, no passthrough args, machine-readable output.

They share the same evaluation engine. Same trust scores, same cache. The difference is the guardrails and the output format.