CLI.

Under upgrade the per-file action is one of twelve kinds. The internal kind is the enum surfaced in the JSON shape; the label is the user-facing string rendered in CLI output:

$ npx @friedbotstudio/create-baseline doctor ./my-project

Baseline doctor — target: /Users/you/code/my-project
Manifest: version 1, installed 2026-05-11T14:00:00Z

  matched:    160
  customized: 0
  missing:    0
  added:      0

Four categories, surfaced in this order whenever non-zero:

Doctor never modifies the target. To repair drift, run the upgrade subcommand (preserves customizations; interactive in a TTY) or --force (overwrites everything except .claude/project.json).

For CI parsers, add --json to emit the structured report on stdout instead of the human renderer. The schema preserves matched, customized, missing, added, plus strict, target, manifestVersion, generatedAt, tampered, and the exitCode. Exit codes are unchanged; --strict still escalates customizations to exit 1.

• Servers named in the template are baseline-canonical. Currently context7, plantuml, playwright. The merge refreshes them from the template, so an upgrade delivers baseline arg and env updates (for example, a new flag on the playwright server). A user who customized a baseline-named server loses that customization on the next upgrade. Intentional customizations belong under a non-baseline name (for example playwright-custom).
• Servers absent from the template are user-added. Preserved byte-for-byte across merges.
• Top-level JSON keys outside mcpServers are additive: template keys are added when missing; the target's existing keys win on collision.
• If the target has no .mcp.json, the template is written verbatim.

The implementation lives in src/cli/mcp.js. The decision was recorded in README.md under ".mcp.json merge semantics".

{
  "manifest_version": 1,
  "generated_at": "2026-05-11T14:00:00.000Z",
  "files": {
    "CLAUDE.md": "9a3f...",
    ".claude/hooks/track_guard.mjs": "1c4b...",
    ".claude/skills/intake/SKILL.md": "f0d2...",
    ...
  }
}

This file is the input to every subsequent upgrade and to doctor. Two design notes:

• Each upgrade run replaces the manifest with a fresh one stamped at the new install time. The old manifest is the "old" side of the three-way reconcile; the new template is the "new" side; the target on disk is the lived side.
• The manifest is recommended for commit to the project's git history. It is the audit trail for "what baseline version was this project on as of which commit". The baseline's .gitignore does not exclude it.

The fetch is skipped when:

• plantuml is already on the system $PATH.
• --no-plantuml is set.
• --dry-run is set.
• The destination jar is already present with a matching sha256.

On network failure or sha mismatch, the install prints a warning and continues. Pass --require-plantuml to make the failure fatal (exit 4) so CI catches a wedged mirror.