/**
 * Cloud Portal Onboarding Session Types.
 *
 * These types model the lightweight session-lifecycle data used by the Cloud
 * Portal sub-5-minute onboarding flow (KR3). They are deliberately distinct
 * from the marketing-focused {@link BrandOnboardingService} session model:
 * Cloud Portal sessions track *intent gathering* (website URL → AI prefill →
 * user-approved discovery answers), while Brand Onboarding tracks a fixed
 * questionnaire used to generate a Brand Voice Guide.
 *
 * Both flows ultimately funnel into
 * {@link provisionFromOnboarding} for team materialisation, but the session
 * stores are independent so each flow can evolve without coupling.
 *
 * @module services/onboarding/onboarding.types
 */
/**
 * Lifecycle of a Cloud Portal onboarding session.
 *
 * Transitions:
 *   created   → prefilled  (after POST /sessions/:id/prefill)
 *   prefilled → reviewed   (free-form PUT updates while user reviews)
 *   reviewed  → approved   (after POST /sessions/:id/approve)
 *   approved  → provisioned (after POST /provision succeeds)
 *   provisioned → completed (after POST /sessions/:id/complete — terminal,
 *                            stamps the magic-moment KR3 telemetry timestamp)
 *
 * Backwards transitions are allowed via PUT updates so the user can revise
 * answers before approving. The `completed` state is the terminal flag set
 * by the frontend wizard once the user reaches the post-provision success
 * screen — it lets us measure end-to-end onboarding wall-clock time.
 */
export type OnboardingSessionStatus = 'created' | 'prefilled' | 'reviewed' | 'approved' | 'provisioned' | 'completed';
/**
 * Confidence band for an AI-extracted prefill field.
 *
 * Mirrors {@link PrefillConfidence} from the brand-onboarding flow so callers
 * downstream of either service can reuse the same threshold logic.
 */
export type OnboardingPrefillConfidence = 'low' | 'medium' | 'high';
/**
 * AI-extracted prefill data for a Cloud Portal onboarding session.
 *
 * Generated by the Website Analysis pipeline (LLM extraction over the user's
 * marketing site) and stored as a single payload — fields are optional because
 * extraction confidence varies per site, and missing fields are surfaced as
 * `missingFields` for the user to fill in manually.
 */
export interface OnboardingPrefillData {
    /** Business / company name. */
    businessName?: string;
    /** Industry or vertical (free-form, normalised downstream). */
    industry?: string;
    /** One-sentence summary of what the business does. */
    description?: string;
    /** Target customer description. */
    targetCustomer?: string;
    /** Identified competitor names. */
    competitors?: string[];
    /** Brand personality keywords. */
    personality?: string[];
    /** Voice/tone descriptor. */
    tone?: string;
    /** Stated business goals. */
    goals?: string[];
    /** Active marketing platforms (e.g. ['Instagram','LinkedIn']). */
    platforms?: string[];
    /**
     * Field IDs that the extractor could not populate with sufficient confidence.
     * The Cloud Portal UI uses this to highlight what the user still needs to
     * confirm before approving.
     */
    missingFields?: string[];
    /** Aggregate confidence across all populated fields. */
    confidence?: OnboardingPrefillConfidence;
    /** ISO 8601 timestamp of the extraction run. */
    extractedAt?: string;
}
/**
 * User-approved answers from the Cloud Portal discovery review step.
 *
 * Shape is intentionally permissive (an open record) because the Cloud Portal
 * questionnaire is template-driven and may evolve. The
 * {@link OnboardingProvisionRequest} validator at the provision boundary
 * pulls out the typed fields it requires; everything else is forwarded as
 * `metadata` for downstream agents.
 */
export interface DiscoveryAnswers {
    /** Business identity block (name, vertical, size). */
    identity?: {
        name?: string;
        vertical?: string;
        size?: string;
    };
    /** Strategy block (goal, budget, urgency). */
    strategy?: {
        goal?: string;
        budget?: string;
        urgency?: string;
    };
    /** Vertical-specific probe answers (per OnboardingProvisionRequest §3.2). */
    probe?: Record<string, unknown>;
    /** Stack mapping answers (per OnboardingProvisionRequest §4). */
    stackMapping?: Record<string, unknown>;
    /** Free-form additional fields surfaced by the questionnaire. */
    [extra: string]: unknown;
}
/**
 * A Cloud Portal onboarding session.
 *
 * Persists in memory for the duration of the backend process — the Cloud
 * Portal flow is a single-user wizard whose lifetime is bounded by the
 * 5-minute onboarding budget, so disk persistence is intentionally deferred
 * until we observe a real reload need.
 */
export interface OnboardingSession {
    /** Unique session identifier (UUID v4). */
    id: string;
    /**
     * Owner user/tenant id (the authenticated principal that created the
     * session). Populated at `createSession()` time from the auth context
     * (`req.user.userId`). When undefined, the session is treated as
     * unscoped — this preserves OSS single-user behaviour for callers that
     * do not run behind the auth middleware. In Cloud Portal multi-tenant
     * mode the auth middleware ensures this is always populated, so all
     * read/write paths apply ownership checks and cross-tenant access
     * returns HTTP 404 with no enumeration leak.
     *
     * @see N1 — Phase E pre-beta tenant scoping
     */
    ownerUserId?: string;
    /** Optional website URL provided at session creation. */
    websiteUrl?: string;
    /** Current lifecycle status. */
    status: OnboardingSessionStatus;
    /** AI-extracted prefill data, present after POST /sessions/:id/prefill. */
    prefillData?: OnboardingPrefillData;
    /** User-approved discovery answers, present after POST /sessions/:id/approve. */
    discoveryAnswers?: DiscoveryAnswers;
    /** ISO 8601 timestamp of session creation. */
    createdAt: string;
    /** ISO 8601 timestamp of the last mutation. */
    updatedAt: string;
    /**
     * ISO 8601 timestamp of when the onboarding flow was marked terminal via
     * POST /sessions/:id/complete. Populated only after the user reaches the
     * post-provision success screen — used as the KR3 magic-moment wall-clock
     * marker (createdAt → completedAt = end-to-end onboarding duration).
     */
    completedAt?: string;
    /**
     * Optional knowledge-directory hint forwarded by the frontend's complete
     * call (`{ teamKnowledgeDir: '.crewly/knowledge' }`). Stored opaquely so
     * downstream tooling that wants to write team-knowledge artefacts post
     * onboarding can recover the location the wizard used; not interpreted by
     * the service itself.
     */
    teamKnowledgeDir?: string;
}
//# sourceMappingURL=onboarding.types.d.ts.map