Decide final dft product and CLI naming for public launch

Problem

Choose the final external name for dft/dataface before M3 launch, reconciling product positioning, CLI/docs impact, and the existing naming/domain option set so launch surfaces do not drift. The outcome needs an explicit documentation and terminology migration plan so public docs, examples, and onboarding surfaces switch consistently instead of drifting by channel.

Context

The repo currently has a split identity:

• product/domain language centers on Dataface
• the CLI command is dft
• some roadmap/task/docs language still treats dft as the public shorthand
• tasks/strategy/naming-and-domains.md contains the current candidate set (dataface, data claw, dboards, and others)

That split is manageable internally, but it becomes a launch risk once docs, examples, package naming, integrations, and public messaging all need to be consistent. If the product name and CLI name are still fuzzy at M3, every new surface will make the cleanup harder.

Relevant anchors:

• tasks/strategy/naming-and-domains.md - candidate names and notes
• docs and examples that already use Dataface
• CLI surfaces that use dft
• future integrations and starter pages that will need stable public terminology

Constraints:

• dataface.com is already owned, so "do nothing" is a real option.
• Public launch prefers a stable, low-churn naming story unless a change unlocks meaningful product value.
• The decision must cover product name, CLI name, docs terminology, and rollout/migration guidance together.
• The outcome should not block technical work unnecessarily beyond places where the public name is actually user-facing.

Possible Solutions

Option A - Recommended: keep Dataface as the product name and dft as the CLI

Make the split explicit instead of treating it as unresolved drift:

• product/site/docs: Dataface
• CLI/examples/commands: dft

Then document that mapping clearly and remove accidental inconsistency elsewhere.

• Pros: lowest churn, already matches owned domain and current code/docs reality.
• Cons: still requires disciplined docs style so dft does not accidentally become the product name by shorthand.

Option B - Rename the public product to a new brand before launch

Choose a new product/domain identity from the candidate list and update launch surfaces accordingly.

• Pros: possible positioning reset if the new name is clearly stronger.
• Cons: large docs and messaging churn, higher launch risk, and domain/trademark work before product evidence demands it.

Option C - Collapse everything under dft

Treat dft as both the product and CLI identity.

• Pros: very short and consistent in commands.
• Cons: weak public meaning, harder domain/story positioning, and throws away the clarity of Dataface.

Plan

1. Inventory the current naming split across domain, docs, CLI help, examples, tasks, and onboarding surfaces.
2. Evaluate whether any candidate in tasks/strategy/naming-and-domains.md beats the current Dataface/dft split strongly enough to justify launch churn.
3. Make an explicit recommendation for product name, CLI name, and how they should be written together in docs and examples.
4. Define the docs/terminology rollout work required once the decision lands, including starter files, markdown/report docs, integration docs, and public launch materials.
5. Record any deferred cleanup if the repo still contains legacy/internal shorthand after the primary decision is made.

Implementation Progress

QA Exploration

N/A - naming/positioning decision task, not a browser flow.

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

Review Feedback

• [ ] Review cleared