Guest OS: Conference Guest Coordination

01 · Project overview

Conference reception involves frequent schedule and resource changes, with concurrent edits creating conflicts. I developed and maintained the application within the coordination group, bringing profiles, schedules and vehicle dispatch into one platform to reduce fragmented information and repeated confirmations.

02 · My responsibilities

• Developed and maintained frontend and backend modules for profiles, schedules, dispatch and administration.
• Designed shared state subscriptions, incremental writes, permissions and sensitive-field presentation.
• Simplified modules from field feedback and addressed concurrent overwrites, lost fields and startup flicker.
• Converted incident causes into regression tests and data-safety constraints.

03 · Features and coordination flow

• A command center aggregates guest state, with profiles, timelines, reminders and activity logs.
• Schedule and vehicle boards expose timings, transport needs and conflicts.
• Hotel, lounge and directory modules share runtime registries and field configuration.
• Role and ownership rules govern viewing/editing, with sensitive fields masked by default.
• Change notifications and a state-driven assistant support traceable coordination.

Guest OS: Conference Guest Coordination — screenshot 1 (personal details masked)

04 · Architecture and data safety

A FastAPI persistence layer and a single frontend Store share the same state. Field-level PATCH, revision-based optimistic locking and three-way merge replace client-side full-state overwrites. Reads distinguish valid data, a verified empty database and errors; the revision advances only after data writes succeed.

05 · Incidents and outcomes

The report records concentrated development from September 11–21, followed by October refinements. Concurrent overwrites, stale clients clearing fields and mock startup flicker exposed weaknesses in the early write model. Incremental updates, field preservation, loading gates and suspicious-deletion safeguards resulted in 83 regression tests.

06 · Limitations and reflection

The report identifies divergence between the deployed hotfix branch and the main branch, with important fixes still requiring integration. Historical passing tests do not imply every branch is safe. My takeaway: successful saves must mean persisted data, incident reviews need executable constraints, and unused field features should be removed.

07 · Scope and source

This was a self-initiated or personally led practice during my Alibaba Cloud trainee period, supporting internal learning, collaboration or training rather than external client delivery. The account follows my project report dated October 10, 2026. Development and test figures describe that historical snapshot, not current production status. Screenshots come exclusively from my supplied folder; sensitive people and contact details are masked.