Scaffold faces index md and hello yaml in dft init

Problem

Extend dft init to create a helpful /faces landing page plus hello.yml together, so a fresh repo serves a self-guided starter surface immediately after init instead of an empty folder or a single opaque example. The scaffold should double as in-repo documentation, teaching the /faces model and first editing steps through the generated starter pages themselves. The task should also include a manual adoption pass in ~/Fivetran/analytics to add the new starter files in that real repo once the scaffold shape is settled.

Context

dft init already creates a small scaffold in dataface/cli/commands/init.py:

• dataface.yml
• faces/hello.yml
• faces/partials/.gitkeep

That is enough to prove the command works, but not enough to make a freshly initialized repo self-explanatory. The generated content still feels like a starter file, not like an onboarding surface.

Once markdown report pages exist, dft init can do better by creating a landing page that teaches the /faces model directly inside the served experience. This task is intentionally small in scope: create the two most useful starter pages together:

• faces/index.md
• faces/hello.yml

That pair gives users both authoring modes immediately without creating a giant template tree.

Relevant anchors:

• dataface/cli/commands/init.py - current scaffold implementation
• bootstrap-dft-init-for-one-command-serve-in-dbt-repos.md - prior dft init design/implementation context
• markdown report task and schema naming task - upstream decisions that define the new index.md contract

Constraints:

• Keep the starter scaffold opinionated but small.
• The generated index.md should act as instructional content, not generic docs boilerplate.
• hello.yml and index.md should serve cleanly right after init.
• Follow through manually in ~/Fivetran/analytics once the scaffold is settled so the pattern is proven in a real repo.

Possible Solutions

Option A - Keep only hello.yml

Preserve the current minimal scaffold and rely on external docs to teach the rest.

• Pros: tiny implementation.
• Cons: misses the chance to make /faces self-teaching and does not showcase markdown report pages.

Option B - Recommended: scaffold faces/index.md plus faces/hello.yml

Generate a markdown landing page that explains the repo's /faces surface and links to a simple YAML example. Keep the scaffold to exactly those two user-facing files plus the existing support files.

• Pros: clear onboarding, both authoring modes represented, minimal sprawl.
• Cons: depends on the markdown report contract being stable first.

Option C - Generate a larger tutorial tree

Create multiple examples, docs pages, quickstarts, and partials up front.

• Pros: richer demo experience.
• Cons: too much template surface for an init command and harder to maintain across product changes.

Plan

1. Reuse the settled markdown report contract and naming decisions to define the exact shape of faces/index.md.
2. Update dataface/cli/commands/init.py scaffolds so init generates: - faces/index.md - faces/hello.yml - existing support files that still make sense
3. Make the generated landing page explicitly instructional: - explain /faces - explain .md versus .yml - point users at the first file to edit
4. Add tests for init behavior, idempotency, and generated file contents.
5. Update docs/help text so dft init and related guides mention the new landing-page scaffold.
6. Manually add the same starter files in ~/Fivetran/analytics and verify that the onboarding flow makes sense in the real repo, not just in fixtures.

Implementation Progress

QA Exploration

QA should include serving the generated scaffold locally and verifying that the landing page is understandable, links resolve, and the starter flow feels self-serve. The manual ~/Fivetran/analytics adoption pass is part of that proof.

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

Review Feedback

• [ ] Review cleared