Mapping the Shift Note Stack
April 14 was not a feature-launch day. It was a map-making day. Brett was trying to work out what a proper shift-note feature would actually need, and the answer turned out to be more complicated than adding a text box and saving some rows. The sessions had to trace where shift notes already lived, how they were being reused, what AI plumbing was already available, and which admin patterns could be borrowed instead of reinvented.
The first question was basic: where do shift notes actually live?
The opening research pass did not assume the system already had a neat, single-source shift-note model. Instead, it followed the existing behavior through the code and through the surrounding workflows.
The key finding was that the practical shift-note trail was still anchored in roster comments and related operational note formats, not in some fully realized dedicated editor. That mattered because it separated several things that could easily be blurred together:
- roster comments and shift notes,
- cover-request annotations,
- vehicle and operational markers,
- and later shift-report style writeups.
Historically, this is the real accomplishment of the day. It reduced ambiguity. Before you can build a good editor, you have to know what problem you are actually editing.
The AI stack was more ready than the feature itself
The next worker pass reviewed the existing LLM infrastructure. That made the situation clearer in a different way.
The project already had substantial AI plumbing in place:
- OpenAI-backed structured-output patterns,
- tracking and cost-monitoring work through TokenWatch,
- existing response-processing conventions,
- and several surrounding AI features already in production or active development.
So the shift-note problem was not “we need AI from scratch.” It was more like: the AI layer was available, but the feature definition and data flow were still catching up.
That distinction matters. It meant later work could focus on shaping the note system properly instead of spending all its energy proving the model layer existed.
The UI and schema audits found more reusable structure than expected
The third pass checked the frontend patterns and the database side of the problem.
That review found that the project was not starting from zero there either. The admin frontend already had reusable building blocks for:
- participant lookup and selection patterns,
- date and form controls,
- modal-driven workflows,
- and the general page-level structure needed for a staff-facing editor.
On the data side, there was already enough groundwork to show the feature was plausible without a total redesign. The important historical point is not that the finished shift-note module already existed. It did not. The point is that the project had more reusable infrastructure than the vague state of the feature might have suggested.
What changed
| Area | What April 14 clarified |
|---|---|
| Shift note source of truth | The team mapped the real operational note pathways instead of assuming a clean dedicated subsystem already existed |
| AI readiness | The LLM/tooling layer was largely available already; the unresolved work was product definition and workflow design |
| UI readiness | Existing admin patterns could support the feature without inventing a new frontend language |
| Schema readiness | The data problem looked unfinished, but not blank |
What did not happen yet
This is where source-faithfulness matters most.
April 14 did not produce a polished shift-note editor. It did not prove the whole feature flow end-to-end. And it did not mean Brett had already settled every product choice.
What it did do was remove a lot of uncertainty:
- where the notes were coming from,
- how they differed from adjacent systems,
- which existing AI patterns could help,
- and which admin structures could be reused.
Why this mattered later
The later April sessions moved toward broader engine, POS, care-profile, and agent-review work, but this day belongs in the chronology because it shows a repeated RABS pattern: before Brett pushed a feature into implementation, he often forced the project to answer the messier architectural question first. April 14 was that question for shift notes. The feature was still unfinished, but it was no longer undefined.