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

# Messages and replies

> Continue a submitted item's employee-to-operator thread and read Sent, Seen, unread, and locked-state truth correctly.

Use messages when an operator needs a detail after you have submitted an issue. Each submitted
item has its own thread between the reporting employee and the authorized operator. It is not
the draft conversation with Lucia, and Lucia stays out of the V1 exchange.

## Find a reply

<Steps>
  <Step title="Open Submitted Issues">
    Use the drawer's **Submitted Issues** row. An amber count shows how many submitted items
    need your reply, and the same count sits as a small badge on the hamburger menu button,
    visible even on the empty chat home. The Submitted page also places those items in a
    **Needs your reply** section at the top.
  </Step>

  <Step title="Open the submitted item">
    The item shows the employee and operator messages in one chronological thread. A cold-open
    notice may also point you to waiting replies; V1 notifications appear only in the app on
    open or refresh.
  </Step>

  <Step title="Read the delivery state">
    **Sent** means the message was accepted for delivery. **Seen** means the other party's seen
    cursor has reached it. Neither label proves that anyone approved, assigned, scheduled, or
    completed the maintenance work.
  </Step>

  <Step title="Reply while online">
    Type and send from the submitted item. V1 has no offline queue: if the app cannot send, it
    must say that the reply was not sent instead of displaying false success.
  </Step>
</Steps>

## Thread and access boundaries

| Boundary       | Current behavior                                                                                                   |
| -------------- | ------------------------------------------------------------------------------------------------------------------ |
| Thread         | One durable thread per submitted item, separate from the draft conversation                                        |
| Who starts it  | The employee's submission opens every thread today; the operator's messages are replies inside it                  |
| Visibility     | Property-scoped item access and the reporting employee's authorized Fieldwork access                               |
| Participants   | Reporting employee and authorized Maintenance Inbox operator; Lucia is not a participant                           |
| Unread state   | Derived from each party's seen cursor; surfaced as **Needs your reply**, the drawer count, and the hamburger badge |
| Dismissed item | History stays visible; the employee composer is locked                                                             |
| Connectivity   | Online send only in V1; offline queue and push notifications to the phone are not claimed                          |

The operator's visible name comes from a real Clerk identity. A missing trustworthy name must
not be replaced with a fabricated operator identity.

## What does not exist yet

* **An owner-started conversation.** There is no door for the owner to open a conversation
  with an employee that no issue started. That change is **Planned** as a spec phase (Owner
  starts a staff conversation from Maintenance inbox, FILD-167, 2026-09-09); nothing on this
  page should be read as that feature.
* **The Wave 4 reply record.** The Wave 4 session of 2026-08-10 proved the submission chain
  (the app → the Fieldwork API → the engine → the Maintenance Inbox) but found the inbox reply
  composer dead-ended. That record (Wave 4 landed — enable replies, FILD-58) remains
  **Planned** with an open founder verification checklist dated 2026-08-29. The per-item
  thread described on this page comes from the later, founder-verified proof of 2026-08-19
  (FILD-77); the Wave 4 record is not closed by this documentation.

## What a message does not do

A reply can clarify the report. It does not itself approve cost, assign a person, contact a
vendor, schedule work, close the item, or verify completion. Those remain explicit operator
actions and truth states in Lucia.

## See also

* [Log and track issues](/fieldwork/using-fieldwork/logging-and-tracking-issues)
* [Owner review](/fieldwork/using-fieldwork/owner-review)
* [Tips and guides](/fieldwork/using-fieldwork/tips-and-guides)
* [Maintenance Workflow](/lucia/operations/maintenance-workflow)
* [Clerk identity boundary](/lucia/infrastructure/clerk)

## Verification basis

<Note>
  Verified on **September 10, 2026** against the evidence named in this page's metadata. The
  per-item message loop is bounded to the founder-recorded round trip of 2026-08-19 and to the
  app source at `692a71c`, which carries the drawer count, the hamburger badge, and the Needs your
  reply section. The claim does not certify unrelated operator actions.
</Note>