Add dft init for dbt-native repo bootstrap

Problem

Implement a first-class dft project bootstrap command for existing repos, especially dbt repos that will store dashboards under /faces. The command should detect dbt_project.yml, create or validate faces/ and optional dataface.yml, scaffold starter dashboards or partials, and avoid manual setup steps currently described only in docs. It should support the analytics repo as an internal example-customer path for future M2 dashboard authoring.

Context

• Dataface already assumes a dbt-native repo layout with faces/ as the canonical dashboard directory.
• The docs describe a manual workflow rather than a first-class bootstrap command:
• docs/docs/guides/installation.md
• docs/docs/guides/cli-reference.md
• The CLI currently has validate, compile, serve, render, inspect, agent, and mcp commands, but no repo/project bootstrap command:
• dataface/cli/main.py
• Existing runtime behavior already auto-detects dbt project markers and repo structure in several places:
• apps/playground/routes.py
• apps/playground/file_watcher.py
• IDE detection paths under apps/ide/vscode-extension/
• The expected near-term analyst workflow is to add Dataface to an existing dbt repo, especially the internal analytics repo at /Users/dave.fowler/Fivetran/analytics, and start authoring dashboards in /faces.
• Today that requires users to know multiple undocumented or weakly-enforced conventions:
• create faces/
• optionally add dataface.yml
• understand where starter dashboards/partials should go
• understand how Dataface discovers the dbt project root
• For M1 analyst work, this needs to become a predictable, low-friction command rather than a docs-only setup ritual.

Possible Solutions

Option 1: Improve docs only

• Expand installation and getting-started docs with an "existing dbt repo" recipe.
• Pros:
• Lowest engineering effort
• No CLI surface expansion
• Cons:
• Does not reduce analyst setup friction
• Easy to get slightly wrong in real repos
• Hard to enforce conventions consistently

Option 2: Add a minimal dft init that only creates missing files

• Add a CLI command that detects a dbt repo and creates faces/, faces/partials/, and optional dataface.yml.
• Pros:
• Solves the main bootstrap problem
• Small surface area
• Cons:
• May still leave users without a useful starter workflow
• Risks becoming a thin wrapper around mkdir

Option 3: Add a repo-aware dft init with templates and idempotent validation Recommended

• Add a first-class bootstrap command that:
• detects dbt repo/project root
• confirms whether Dataface is already initialized
• creates faces/, faces/partials/, and optional dataface.yml
• scaffolds starter files
• supports safe re-runs without clobbering existing work
• prints next-step guidance tailored to the detected repo
• Pros:
• Matches the actual intended product workflow
• Gives analysts a single obvious command
• Establishes one canonical repo shape for future docs, IDE, and CI support
• Cons:
• More implementation work
• Requires decisions on template defaults and overwrite behavior

Plan

1. Define the desired bootstrap contract for existing dbt repos. - Inputs: current working directory or explicit --project-dir - Detection: dbt_project.yml, existing faces/, existing dataface.yml - Outputs: initialized repo layout plus clear terminal guidance
2. Add a new CLI command surface, likely dft init, in the main CLI.
3. Implement project-root discovery and idempotent filesystem setup.
4. Add starter templates. - Minimum viable set:
   • faces/hello.yml or equivalent starter face
   • faces/partials/_header.yml if helpful
   • optional dataface.yml
5. Decide and implement safe overwrite policy. - Create missing files by default - Refuse to overwrite existing files unless an explicit force flag exists
6. Add tests for: - dbt repo detection - non-dbt directory behavior - re-running dft init - project-dir override - Fixture repos: use tmp_path copies of minimal dbt layouts; do not require the internal analytics repo in CI.
7. Update docs to make dft init the primary path, not a manual sequence.
8. Manual validation: run the command against any checkout that contains dbt_project.yml (e.g. ~/Fivetran/analytics when that tree exists, or another internal dbt repo). This does not depend on the analytics branch/bootstrap task — only on having a normal dbt project directory to point --project-dir at.

Implementation Progress

• Initial planning notes:
• Confirmed there is currently no dft init repo bootstrap command in dataface/cli/main.py.
• Confirmed docs already describe the target conventions (faces/, optional dataface.yml, dbt repo auto-detection), so this task is mainly about productizing that convention.
• Confirmed this should land before analyst-facing onboarding, not as a later polish item.
• Ordering vs analytics branch task: implement and test dft init using temp dirs + optional manual run in ~/Fivetran/analytics (or any dbt repo). The create analytics repo Dataface branch task is for git workflow and internal rollout, not a prerequisite to build or test the CLI.

• faces/ placement: must be at the same level as models/ inside the dbt project dir. dft init detects dbt_project.yml and puts faces/ alongside models/, macros/, tests/, etc.

• [x] Tests written first (TDD) — tests/core/test_init_command.py with 11 tests covering:

• dbt project detection and non-dbt directory behavior
• faces/, faces/partials/, starter face, and .gitkeep creation
• Idempotency: re-run skips existing files, --force overwrites
• --project-dir override and cwd default
• [x] Core implementation — dataface/cli/commands/init.py:
• init_command() returns an InitResult dataclass with project_dir, dbt_detected, created_files, skipped_files
• Detects dbt_project.yml at project root
• Creates faces/, faces/partials/, faces/hello.yml starter, and faces/partials/.gitkeep
• Never overwrites existing files unless --force is passed
• [x] CLI wiring — dft init registered in dataface/cli/main.py with --project-dir and --force options
• Prints created/skipped files and next-step guidance
• [x] CI green — 3070 tests pass, lint and format clean

QA Exploration

• [x] QA exploration completed (or N/A for non-UI tasks)

N/A for browser QA. Verification should focus on CLI behavior in temporary repos and in the internal analytics repo.

Review Feedback

• [ ] Review cleared