Maintenance Workflow defines the product’s first real-world intake loop: external reports should become structured operational work.
Intake channels and evidence boundary
The intended maintenance intake channels are:- Every record binds to the pilot property. “Everything is Villa Valentin right now. There is NO OTHER PROPERTY.” (founder, 2026-08-04, LUCI-92). No maintenance-inbox record is written without a property binding the Engine actually resolved; during the pilot that binding is
villa_valentin, read from property settings, never hardcoded and never inferred from a provider payload. An item the Engine cannot bind is refused visibly, never stored as a silent unscoped row. The Engine work carrying this invariant is recorded on LUCI-92 (Finalizing on 2026-09-10). - The generic maintenance webhook is gated. On 2026-08-30 a read-only probe showed the legacy webhook route accepting unauthenticated durable writes; the store was cleaned and the route now requires a shared secret header, matching how the Fieldwork intake path authenticates (LUCI-169, completed 2026-08-30). No secret value appears in any record.
- Postmark is the employee-facing thread only. Since September the guest-facing mail family (the booking magic link and the payment request) leaves the Engine through Resend; Postmark carries the Maintenance Inbox’s employee thread and nothing guest-facing (LUCI-232, LUCI-231; HLLC-41 audit read of the Engine’s outbound code, 2026-09-10). On Development every guest-facing mail is redirected to one testing inbox; employee-facing mail is untouched (LUCI-231).
Previously documented implementation flow
The imported operations record described:External messageauthenticated intakenormalized maintenance signalduplicate handlingstored-media or fallback outcomeMaintenance Inbox statelinked maintenance task
Current Engine source implements the route, normalization, verification, dedupe, media, inbox, and task seams. This source evidence does not prove a fresh provider delivery or every end-to-end side effect in a deployed environment.
Fieldwork submitted-item thread
Once Fieldwork receives the canonical submission acknowledgment, the item can carry one durable thread between the reporting employee and the authorized Maintenance Inbox operator:Submitted Fieldwork itemOperator reply in Maintenance InboxFieldwork API durable item threadEmployee sees and replies on the submitted itemMaintenance Inbox renders the combined chronology
The thread is not the employee’s draft conversation with Lucia. Lucia is out of the V1 loop.
Employee and operator seen cursors derive Sent, Seen, unread, and Needs your reply
presentation. The Maintenance Inbox records operator seen when the thread opens and refreshes on
its existing cadence. Its initial load stays calm while the thread is being resolved.
V1 is online-only. A failed employee send remains not sent; the system must not invent success.
Dismissed items preserve history and lock the employee composer. Operator messages use a real
Clerk-derived operator name. None of these messages is itself an approval, assignment,
schedule, spend, completion, or verification action.
What does not exist yet. Every conversation in the Maintenance Inbox begins with the employee: a Fieldwork submission or a provider message opens the thread, and the owner’s messages are replies inside it. An owner-initiated staff conversation with no issue behind it is a design phase, not a feature (Owner starts a staff conversation from Maintenance inbox, FILD-167, Planned as of 2026-09-10; founder, 2026-09-09: “Sometimes it’s preemptive from me to them.”).
Push lands on the record. The operator push for a new intake or an employee reply deep-links to the Maintenance page with the record’s id. On 2026-08-30 that landing rendered the generic page; the fix that opens the referenced record, with an owner-words notice for an unknown id, is recorded as completed on LUCI-167 on 2026-09-10. This pass did not read the served Admin commit for it.
See Messages and replies,
Owner review, and
Clerk.