> ## Documentation Index
> Fetch the complete documentation index at: https://helloluciallc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# START HERE - Guest-Facing Lucia

<Note>
  Guest-facing Lucia is HelloLucia, LLC's public concierge product surface. She helps guests warmly before verification, preserves privacy while identity is uncertain, and turns guest conversation into structured operational clarity for the property team.
</Note>

***

## Product Line

HelloLucia, LLC now owns three major product lines:

```text theme={"dark"}
Lucia AI - Operator / Owner-Facing OS
Lucia AI - Public / Guest-Facing Concierge
Eval Labs - Evaluation + Regression System
```

Guest-facing Lucia is not simply a chatbot. She is a front-of-house teammate connected to operational truth.

The operator-facing Lucia OS remains the calm operating partner for owners and property teams. Guest-facing Lucia is the warm public concierge surface that can help, collect claims, and escalate structured signals without violating booking privacy.

Eval Labs is the proof and regression system for both surfaces.

***

## Current Implemented State

Current guest-facing Lucia implementation recorded by this Canon milestone:

```text theme={"dark"}
Product milestone: Guest Agent v0.1.0 - Guest Identity + Magic-Link Lab
Current live proof: Controlled Reservations + Magic-Link Verification Loop
GitHub repo: hello-lucia/lucia-guest-agent
Local path: /Users/avivhadar/Desktop/lucia-guest-agent
Branch: main
Current source commit: 826a6a14e2fa95bfd60c8008fb0cdc9d846b4231
Production URL: https://guest.hellolucia.ai/
Live guest reservations route: https://guest.hellolucia.ai/reservations
Guest Agent lab route: https://lucia-guest-agent.netlify.app/lucia-lab/
Default model: gpt-5.6-sol (GPT-5.6 Sol)
Production override: VV_AI_MODEL=gpt-5.6-sol
Source fallback: gpt-5.6-sol
Model gateway: OpenAI Responses API
Embeddings model: text-embedding-3-small
Model boundary: configured and verified independently from Lucia Engine
Live provider-returned model proof: gpt-5.6-sol
Visible page identity: Guest Agent build tag is visible in the lab
```

Both Lucia Engine and Lucia Guest Agent currently use `gpt-5.6-sol`, but the shared value does not imply inheritance. Engine configuration and `/admin/operator-focus` provenance establish Engine runtime truth. Guest Agent configuration and its separately deployed provider proof establish Guest Agent runtime truth.

The Guest Agent does not expose or persist the Engine's `meta.model_runtime` provenance contract. Its 2026-07-12 verification proved both the effective configured model and the provider-returned model as `gpt-5.6-sol`; it did not change prompts, verification flow, routing, schemas, or the core SSE events `start`, `token`, `cta`, `meta`, and `done`.

This is deployed runtime and live-development product truth. It is not a broader production-readiness claim.

***

## Guest Product Versioning

Current guest-facing product milestone:

```text theme={"dark"}
Guest Agent v0.1.0 - Guest Identity + Magic-Link Lab
```

Definition:

```text theme={"dark"}
first working guest-facing Lucia lab
guest-facing concierge independently configured for gpt-5.6-sol through VV_AI_MODEL
identity orientation handshake
booked-guest claim collection
claim fragment memory
Engine candidate lookup
Resend magic-link verification
verified session state
verified-session recognition after magic-link click
resend/status intent split for guest verification
safe verification_expires_at metadata in pending guest-agent state
controlled/test guest reservation creation with owned/test email
Engine seed booking persistence
Guest Agent /reservations availability calendar using Engine truth
server-side Guest Agent signing boundary for seed booking requests
Admin calendar visibility for generated seed bookings
guest operational signal bridge
Admin Signal Stream visibility foundation
```

Versioning boundary:

```text theme={"dark"}
commit tag = engineering truth
product version = milestone/product truth
```

The guest-facing UI should eventually show both:

```text theme={"dark"}
Guest v0.1.0 · <commit>
```

***

## What Changed

Guest-facing Lucia is now a distinct major product surface inside the Canon.

Current implemented surface:

```text theme={"dark"}
Villa/Lucia-style lab page created and polished
editorial visual system: Canela, nucleus divider, black top bar, refined chat card
guest identity orientation lives inside Lucia's first message
identity orientation must be selected before normal chat begins
generated orientation prompt appears in the composer
guest sends the orientation prompt
identity buttons disappear after orientation
normal conversation begins
```

The interaction should feel like Lucia orienting herself, not like a form.

***

## Completed Reservations + Verification Loop

The completed live-development proof now connects:

```text theme={"dark"}
Guest Agent /reservations
Engine seed booking truth
Admin calendar booking visibility
guest-facing magic-link verification
verified guest session
booking-specific guest planning
```

This remains a controlled seed/test reservation loop. It is not a public booking engine, payment system, Lodgify replacement, auth system, or production OTA integration.

***

## Identity Orientation Options

Guest-facing Lucia begins by asking the guest to orient the relationship:

```text theme={"dark"}
I'm already booked
I'm joining someone's stay
I'm planning a trip
Just exploring
```

These are not decorative buttons. They are the first step in privacy-safe context collection.

***

## Product Doctrine

Guest-facing Lucia may help before verification.

Guest-facing Lucia may collect claims.

Guest-facing Lucia may not expose booking-private details or mutate booking records until identity/linkage is verified or operator-linked.

Core public-facing doctrine:

```text theme={"dark"}
helpful first
privacy-safe always
claims are claims until verified
service overlap is never identity evidence
operator linkage is required before unsafe attachment
```

Guest-facing Lucia should remain:

```text theme={"dark"}
warm
friendly
welcoming
capable
hospitality-native
privacy-safe
helpful first, careful with verification
```

Guest-facing Lucia must not become:

```text theme={"dark"}
robotic
procedural
generic SaaS
cold privacy language
a form disguised as chat
```

***

## Guest-Facing Lucia Eval Track

Eval Labs now needs a first-class Guest-Facing Lucia Eval Track separate from operator-facing Lucia evals.

Purpose:

```text theme={"dark"}
Manual testing cannot cover every possible guest phrasing.
Eval Labs must stress-test guest identity, verification, privacy, tone, and guest-to-operator routing at scale.
```

The track must cover identity orientation, booked-guest claim parsing, claim fragments across turns, weak vs strong claims, ambiguous/no-match cases, magic-link eligibility, verification-email privacy, token consume/replay/expiry, verified session state, guest operational signals, Admin Signal Stream visibility, Focus Ops no Luca/Nora drift, and warm hospitality tone.

***

## Knowledge Center Map

Start here, then read:

* [01 - Guest Identity and Linkage Contract](/lucia/guest-facing-lucia/guest-identity-and-linkage-contract)
* [02 - Guest Operational Signals](/lucia/guest-facing-lucia/guest-operational-signals)
* [03 - Magic Link Booking Verification](/lucia/guest-facing-lucia/magic-link-booking-verification)
* [04 - Guest Verification Email](/lucia/guest-facing-lucia/guest-verification-email)
* [05 - Guest-to-Operator Bridge](/lucia/guest-facing-lucia/guest-to-operator-bridge)
* [06 - Guest-Facing Tone and Hospitality Doctrine](/lucia/guest-facing-lucia/guest-facing-tone-and-hospitality-doctrine)
* [07 - Guest-Facing Eval Requirements](/lucia/guest-facing-lucia/guest-facing-eval-requirements)
* [08 - Guest-Facing Roadmap](/lucia/guest-facing-lucia/guest-facing-roadmap)

***

## Current Boundary

Implemented does not mean production-hardened.

Current non-production gaps include:

```text theme={"dark"}
automated testing of guest verification combinations
Eval Labs guest identity battery
Admin guest signal review/link surface
production booking engine/payment/OTA integration
owner/operator-configured reservation rules
durable persistence for guest signals and verification state
rate limiting / replay / spam hardening
operator-linked booking verification
inquiry record support
guest-of-guest verification paths
production privacy/consent copy
Villa Valentin launch hardening
```

Canon should record implemented state, doctrine, and roadmap separately.