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

[jafreck]

Summary

Implements cadre init as an interactive CLI wizard that scaffolds a complete CADRE project configuration. Users are prompted for project name, platform, repository, repo path, base branch, issue selection mode, agent backend, build commands, and GitHub auth method. The generated cadre.config.json is validated via CadreConfigSchema.parse() before being written to disk.

Closes #15

Changes

• package.json / package-lock.json: Added @inquirer/prompts@^7 as a runtime dependency for interactive terminal prompts.
• src/cli/prompts.ts (new): Defines all interactive prompts with inline validation. Exports runPrompts({ yes: boolean }) which either runs the interactive wizard or returns defaults in non-interactive mode. Exports the PromptAnswers interface.
• src/cli/init.ts (new): Core init logic. Checks for a git repo, handles existing config overwrite confirmation, assembles and validates the config via CadreConfigSchema.parse(), writes cadre.config.json, appends .cadre/ to .gitignore, and creates .github/agents/.
• src/index.ts: Registers the init subcommand with Commander, including --yes / -y and --repo-path flags, following the existing command registration pattern.
• tests/prompts.test.ts (new): Unit tests for runPrompts covering the --yes mode and all validation functions (project name, repository, repo path).
• tests/init.test.ts (new): Integration tests for runInit using temporary directories. Verifies git-repo detection, config writing, .gitignore management, .github/agents/ creation, and overwrite handling.
• tests/cli-init.test.ts (new): Additional init tests focused on edge-case behaviors.
• tests/index-init.test.ts (new): Tests for the Commander command registration (help output, flag routing, error handling).
• tests/inquirer-prompts.test.ts (new): Tests for the @inquirer/prompts integration layer.
• tests/github-issues.test.ts: Fixed a pre-existing test assertion to match the updated MCP tool name (issue_read with method parameter, replacing the old get_issue call).

Implementation Details

Prompts are split into two layers: prompts.ts handles the UI/UX layer (inquirer calls + validation) while init.ts orchestrates the file system side effects. In --yes mode, project name and repository are derived from the git remote URL when available, falling back to empty strings with a warning. Config assembly maps prompt answers directly to the CadreConfigSchema shape; the parse() call acts as a final correctness gate before any file is written. File writes use atomicWriteJSON for the config and direct fs calls for the .gitignore append and directory creation.

Testing

• 209 of 210 tests pass across 24 test files
• New tests cover: --yes mode defaults, per-field validation, git-repo detection error, config write/parse round-trip, .gitignore append (existing and missing), .github/agents/ directory creation, overwrite-with---yes flow, Commander command registration
• The single pre-existing failing test (github-issues.test.ts) is an unrelated regression from a prior MCP API rename and was fixed as part of this PR

Integration Verification

• Install: pass
• Build: pass
• Tests: 209/210 pass (1 pre-existing failure in tests/github-issues.test.ts fixed in this PR; integration report captured it before the fix was applied)

Notes

• Agent backend is hardcoded to copilot; the Claude option is deferred to issue Multi-backend agent launcher: native support for Copilot CLI, Claude CLI, and direct API #3.
• .github/agents/ scaffolding (populating agent prompt files) is deferred to a sub-issue as noted in the original issue.
• In --yes mode, fields without obvious defaults (project name, repository) are derived from the git remote URL if detectable; otherwise they default to empty strings with a logged warning.
• The --repo-path flag allows overriding the working directory and bypasses the local git-repo existence check.

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 detailed and well-structured. The main ambiguity was around --yes mode defaults for fields like project name and repository — the issue didn't specify what to do when no obvious default exists. The analysis agent reasonably inferred "derive from git remote or emit a warning", but this required an assumption.
• Agent contracts: The fix-surgeon agent was invoked to fix an unrelated pre-existing test failure (github-issues.test.ts), but it left a result markdown file (fix-surgeon-integration-fix-test-result.md) in the worktree root. This artifact should be cleaned up or written to the .cadre/ scratch space, not the project root.
• Context limitations: No file tree was provided in the issue body, so the analysis agent had to infer file locations from the issue description and general TypeScript/Node conventions. This worked well here but could fail on less conventional projects.
• Git/worktree: No git or worktree problems were observed during this run.
• Parsing/output: Several task result and test result markdown files (task-00N-result.md, task-00N-tests.md) were committed to the worktree root rather than stored only in .cadre/. These clutter the diff and should be redirected to the .cadre/issues/<N>/ directory or excluded from commits entirely.
• Retry behavior: The fix-surgeon was invoked once after the initial integration check failed due to the pre-existing github-issues.test.ts failure. The retry resolved the issue, though the failure was unrelated to the actual feature being implemented — the pipeline could benefit from a "pre-check" phase to detect pre-existing failures before attributing them to new code.
• Overall: The biggest friction point was artifact leakage — task result files and the fix-surgeon result file ended up in the worktree root, polluting the diff with non-source content. Routing all agent scratch files to .cadre/issues/<N>/ would keep the diff clean and focused on the actual feature changes.

Closes #15