CLI onboarding: interactive init wizard + resolved config inspect command

[darko-mijic]

Summary

Add first-class onboarding CLI support for adopters:

1. An interactive init wizard for new/existing repos.
2. A config inspection command that resolves and prints effective configuration.

This should reduce setup friction and eliminate trial-and-error when teams adopt @libar-dev/delivery-process.

Problem

Current onboarding is manual and easy to misconfigure:

• Users must handcraft delivery-process.config.ts and guess correct source globs.
• Script setup often hardcodes local internals (tsx ./node_modules/...) instead of stable package binaries.
• It is difficult to verify what config is actually effective after defaults, presets, and source overrides are applied.

Proposal

A) Interactive init command

Add a dedicated CLI entrypoint (example: delivery-process-init) runnable as:

• npx delivery-process-init

Behavior:

• Detect package manager (npm, pnpm, yarn) and module mode (type: module).
• Detect existing config (delivery-process.config.ts / .js) and offer safe update flow.
• Prompt for preset (libar-generic, generic, ddd-es-cqrs).
• Prompt/auto-detect source globs for:
  • TypeScript
  • Feature files
  • Stubs
• Prompt for output directory and overwrite mode.
• Optionally add scripts to package.json (query, docs, lint/validate).
• Optionally scaffold starter folders/spec/stub templates.
• Run a validation smoke check at end (e.g., process-api overview, generate-docs --list-generators).

Safety requirements:

• --dry-run support.
• Explicit confirmation before overwriting config/scripts.
• Never silently modify existing files.

Automation support:

• --yes / non-interactive mode with flags for CI/bootstrap automation.

B) Config inspection command

Add command to inspect effective resolved config (example names: process-api config subcommand or a separate delivery-process-config CLI).

Behavior:

• Load project config with existing discovery behavior.
• Print source of config (default vs file path).
• Print resolved effective config (preset/tag prefix, sources, output, generators, generator overrides).
• Optional --json output.
• Optional --validate mode with clear actionable errors.

Useful outputs:

• Effective source globs per generator.
• Whether stubs are merged into TypeScript sources.
• Workflow path in effect.

Suggested implementation areas

• CLI wiring: src/cli/
• Config load/resolve reuse:
  • src/config/config-loader.ts
  • src/config/project-config.ts
  • src/config/resolve-config.ts
  • src/config/merge-sources.ts
• Docs updates:
  • README.md
  • docs/CONFIGURATION.md
  • docs/PROCESS-API.md (if config lands under process-api)

Acceptance criteria

• Running npx delivery-process-init in a blank repo can produce a working setup without manual edits.
• Running init in an existing repo does not overwrite files without confirmation.
• There is a non-interactive mode suitable for automation.
• A config inspection command can print effective resolved config in human-readable and JSON forms.
• Misconfigurations produce actionable errors (not generic stack traces).
• Documentation includes a quick-start path for both blank and existing repos.

Out of scope (initial iteration)

• Full project migration/refactor assistant for arbitrary legacy doc pipelines.
• IDE UI integration.
• Multi-repo orchestration.

Why now

Recent onboarding/tutorial work shows strong demand for a lower-friction setup path and clearer config introspection. This issue formalizes those requirements into an implementable roadmap.