code-metrics
/octopus:code-metrics runs a local read of how your branch moves a catalog of
deterministic code-quality metrics — structure, debt, readability, decay, and
load risk — before you open the PR, and stays near-free unless something
actually regresses.
What it solves
The author who introduces a quality regression is usually the last to find out: review misses a creeping complexity number, a two-point coverage slip, or a new import cycle, and a dashboard only shows the trend long after the change merged. This command moves the read to the moment you can still fix it cheaply, and keeps it cheap by computing the numbers with your stack’s own tooling rather than a model.
How it works
A per-stack adapter — chosen from the detected stack — runs the real tooling and
normalizes the output to a shared contract. Beyond the v1 structure metrics
(coverage, complexity, module size, dependency cycles) it now reads debt and
readability counters (TODO/suppression counts, nesting depth, parameter count,
magic numbers, doc coverage), hotspots (churn × complexity), and a static
perf_risk proxy (info-only). The command fetches the per-merge baseline from
the octopus/code-metrics ref and prints a dual delta: your branch vs. that
baseline (the trend) and vs. your local main (this PR’s impact).
Thresholds are ratchet-by-default (no regression vs. baseline), with optional
absolute targets in .octopus.yml. The numeric run never calls a model; only a
threshold breach triggers a low-cost model to explain the regression and suggest
a fix. perf_risk is info-only and never gates.
Usage & parameters
octopus code-metrics [--stack <id>] [--metric <name>] [--verbose] [--emit-baseline]--stack <id>— force a stack adapter (csharp,typescript) instead of auto-detecting from the repo.--metric <name>— report a single metric instead of the full catalog.--verbose— show raw tooling output alongside the summary.--emit-baseline— print the flatbaseline.jsonfrom this run (used by the writer-Action).