Department & care
Delivering, checking and publishing the schedule
Local preview, two test suites, double check of half-days and names, then publication through a branch and a pull request, and a check that it actually works online.
Screenshot of a real tool · fictitious data, names blurred
The problem
A new version of the schedule can erase data, break a tab or display old names on the team’s workstations. And the publication procedure, done once a month, is forgotten from one time to the next.
Step-by-step method
- Start again from the online source, not from a local copy: archive it as is, with the current state of the data.
- Always deliver four things: a local preview to open right away, the changes on a dedicated branch (ready for a pull request), the archived source, and any emails, drafted in the conversation.
- Two test suites before any publication, both green: one suite on the data logic (merging by identity, odd/even-week attendance, migrations, the “also present” row), then the triple test in a driven browser:
- no script errors, all modules loaded, with and without real data;
- the key views: the month view shows all staff members, absences are displayed;
- the real gestures: importing an absence email, drag-and-drop in a tab, assigning a stand-in.
- Double check of half-days: compare the template schedule with each activity tab, and list the discrepancies (someone scheduled for echocardiography in the template but missing from the echocardiography tab). Nothing is corrected without approval.
- Double check of names against the directory: spelling, identifiers, duplicates, people not found flagged as such.
- Bundle and ask for approval: nothing is published without your explicit approval. The session’s fixes are bundled into a single version, rather than one publication per fix.
- Publish through a branch, then a pull request: Claude pushes the version to a branch and opens a pull request summarising the changes, the results of both test suites and the discrepancies. The person in charge reviews and merges it themselves; going live follows automatically. There is no longer any direct manual upload to the live version.
- Check online, because deployed does not mean tested: hard reload (Ctrl + F5), version number in the title, new buttons present, and the fixed gesture repeated for real. No link is passed on without having been opened; otherwise it is marked “not verified”. A “not connected” banner goes away with the team password.
- Announce: a short email to the secretariat and to the mailbox of the activity concerned, with the others in copy, drafted in the conversation and sent by you.
Deliverable
A tested version, listed discrepancies, a verified publication, and a ready announcement.
Lessons learned
- A frozen copy of the data inside the published file makes old names reappear on new workstations: remove it, and flag any workstation that is not connected.
- Dropping a person onto an occupied cell can create a duplicate: test this gesture with every version.
- A publication procedure must be written for someone who has never done it, including what they should see at the end.
- Beyond the capacity of a cell, names “disappeared”: an “also present” row now shows everyone who overflows.
- Two people editing the same cell at the same time: merge by identity (who is assigned), never by position in the list, otherwise one wipes out the other.
- The schedule never feeds anyone’s personal calendar: they are two separate sources.
Starter prompt
Here is the schedule’s repository. Apply the requested fix on a branch, run both test suites, then deliver the local preview, the list of half-day and name discrepancies, and a pull request ready for review. Publish nothing without my approval.