feat: add cadre init interactive scaffolding command (#15) (#15)

[jafreck]

Summary

Implements the cadre init CLI subcommand that interactively scaffolds a complete CADRE project configuration. Users can now run npx cadre init to launch a guided wizard that generates a valid cadre.config.json, updates .gitignore, and creates the .github/agents/ directory — eliminating the need to manually author the config from scratch.

Closes #15

Changes

• package.json / package-lock.json: Added @inquirer/prompts as a runtime dependency for interactive CLI prompts.
• src/cli/prompts.ts (new): Prompt definitions and isolated validator functions (validateProjectName, validateRepoPath, validateGitHubRepository, validateAzureDevOpsRepository, validateNonEmpty). Exports collectAnswers(yes, repoPathOverride?) which returns a typed answers object.
• src/cli/init.ts (new): Core runInit(opts) orchestrator that checks for a .git directory, optionally prompts for overwrite confirmation on existing configs, assembles and validates a CadreConfig via CadreConfigSchema.parse(), writes cadre.config.json atomically, manages .gitignore, and creates .github/agents/.
• src/index.ts: Registered the init subcommand with Commander, including -y/--yes (non-interactive mode) and --repo-path <path> options, following the same pattern as existing commands.
• tests/init.test.ts (new): 25 unit tests covering git-check failure, overwrite confirmation, --yes mode, config schema validation, .gitignore deduplication, and .github/agents/ directory creation.
• tests/prompts.test.ts (new): 30 unit tests for all validator functions (valid and invalid inputs for projectName, repoPath, GitHub/Azure DevOps repository formats, and non-empty strings).

Implementation Details

The implementation follows a clean separation of concerns: prompts.ts owns all field-level validation logic and prompt definitions; init.ts owns orchestration and file I/O. The --yes flag short-circuits all interactive prompts and applies documented defaults (repoPath → cwd, baseBranch → main, issues → { query: { state: 'open', limit: 10 } }, github.auth → { token: '${GITHUB_TOKEN}' }). Config assembly always runs through CadreConfigSchema.parse() before any file is written, ensuring structural correctness. File writes use the existing atomicWriteJSON utility from src/util/fs.ts.

Testing

• 25 new tests in tests/init.test.ts covering all runInit code paths
• 30 new tests in tests/prompts.test.ts covering all validators
• All new tests pass with npx vitest run
• Existing tests (225 total) continue to pass; one pre-existing failure in tests/github-issues.test.ts is unrelated to this feature (stale MCP tool name assertion)

Integration Verification

• Build: pass (npm run build exits 0)
• Tests: pass (new tests: 55/55; pre-existing failure is unrelated to this PR)
• Lint: N/A (no lint command configured in the project)

Notes

• Agent backend is hardcoded to copilot for now; adding the claude option is deferred to issue Multi-backend agent launcher: native support for Copilot CLI, Claude CLI, and direct API #3.
• .github/agents/ directory is created but no stub prompt files are scaffolded; agent file scaffolding is delegated to a separate sub-issue per the original spec.
• The "auto-detect" GitHub auth option was left unimplemented (no spec provided); the prompt currently offers token and app only.
• --repo-path flag is accepted as a CLI option and passed through to runInit; it overrides both the .git check path and the default repoPath in generated config.

Cadre Process Challenges

This section is required for all CADRE-generated PRs (dogfooding data).
Document honestly what was difficult, confusing, or error-prone when CADRE processed this issue.

• Issue clarity: The issue was well-detailed overall, but several edge cases were ambiguous: "auto-detect" GitHub auth method had no specified behavior; the --repo-path flag appeared only in the acceptance criteria without being listed in the detailed prompt/flag spec; and the non-interactive defaults for issue selection mode and auth method were not fully enumerated.
• Agent contracts: The code-writer agent initially missed forwarding opts.repoPath from runInit to collectAnswers, requiring a fix-surgeon pass. The signature mismatch was subtle and not caught until tests were written.
• Context limitations: The issue did not provide a file tree, so the codebase-scout agent had to explore the worktree before analysis. Existing utility helpers (atomicWriteJSON, ensureDir) were discovered during exploration rather than documented in the issue.
• Git/worktree: No significant problems encountered; branch and worktree setup worked cleanly.
• Parsing/output: The integration-checker surfaced a pre-existing test failure in tests/github-issues.test.ts (stale get_issue vs issue_read MCP tool name). A fix-surgeon agent was dispatched to fix this test, but the fix introduced only a test assertion update — the production code was already correct.
• Retry behavior: The fix-surgeon ran once for the code-review issues in task-003 (repoPath forwarding, --yes defaults) and once for the pre-existing test failure; both retries converged on correct fixes without additional iteration.
• Overall: The biggest friction point was under-specified edge cases (auth method defaults, --repo-path scoping) that required judgment calls during code-writing, followed by a fix-surgeon pass to resolve the resulting issues found in code review.

Closes #15