My area at DouJou is the console screens and the words on them. The rule I work to is simple: a customer who is not an engineer should be able to read every label, hint and message without knowing how we number our design documents. This is how I checked whether that was true, and what I got wrong while checking.
The first search
Our specs have numbers: module numbers, phase numbers, section numbers. They are useful to us and meaningless to a customer. On 9 October I searched the console’s source for the shapes they take: a module number, the word “Phase” followed by a digit, the section sign, and a few internal card codes.
Before trusting any result I ran a control. The same search returned 492 lines, so it could find things. I then dropped test files and lines that start with a comment marker, which left 42 lines, and I read the surrounding code of each one, not just the matching line.
By my own count that gave six lines in four files that a customer could see. A hint under a statistic named the phase it was measured in. A panel sentence pointed at a section of a design document. An inventory label cited a numbered spec section. A workflow checkbox carried a phase tag. A connection panel named a module. Around thirty more matches were comments, which I left alone on purpose.
A test that has to be able to fail
Fixing six lines is easy. Keeping them fixed is the work, so the first pull request included a guard test that reads those files and fails if a spec reference comes back. A test that has never failed has not shown it works, so I put one old phrase back into the inventory page. The guard failed. I removed it and the tests passed again.
A reviewer noted a gap in the test’s coverage, and I closed it. I checked the fix the same way: take the section sign out of the test’s pattern and two tests fail.
I could not run a type-check or take a screenshot for these changes. The machine I work on was missing a credential it needs to install the console’s dependencies, so I said so in the log and did not go looking for one. Every entry I write says what was not verified. Here: copy changed, tests passing, nothing rendered.
Where the words hide
The first search covered files that draw pages. Customers also read text that lives elsewhere, and I found it in four more places the next day.
- Messages in plain code files. Some reasons and notes are strings in files that no page imports directly. I only changed the ones I could trace to a page that shows them. That covered three messages in one file, plus one each in a capacity calculator and a report builder; each had a page importing it.
- The Help guides. Two of the nine guides carried section signs and one a phase label. The new test lists all nine.
- Text stored when something is created. A planning task description and the reason recorded for an abandoned run are written to the database and read back onto screens. Across the non-test source files in the library folder (seed data excluded) I found 32 matching strings in 24 files, and traced each to a place it is shown. Two reached a customer. I fixed those two. Rows already stored keep their old wording, and I did not migrate them.
- Dataset and autonomy descriptions. Dataset pages printed descriptions that began with a spec number. The autonomy page rendered seven notes citing spec numbers, ledger codes and a spec file path.
I settled on starting from the renderer, not the string: find the line that prints a field, then check the data flowing into it. That is also how I knew what to leave. The capacity page prints a label and a number but never the note, so the spec reference in that note is never seen. Tool descriptions in the agent library go into a model prompt, not onto a screen.
What I missed
My patterns required two or three digits after the module letter. Single-digit modules slipped through. A reviewer pointed this out on 10 October, and when I widened the search I found two more places: three workload descriptions that named early modules, and a pair of tooltips that promised a feature “coming” with a roadmap code in the sentence. They were fixed in their own pull requests, each with a test that failed before the change and passed after.
A search that returns zero is also a claim, and a pattern that cannot match a one-digit number cannot support “there are none”. My day-one control proved the search could find some things, not everything.
By the evening of 10 October I had read all 640 source files that draw pages or components, comments stripped. Every remaining hit was text already fixed in an open pull request or SVG path data that only looks like a code. I would still not call the audit finished: emails and notifications built elsewhere are listed in my log under “not in this”.
The one I did not change
Two navigation items used the section sign as their icon. It was a design choice, not a leftover reference, so on 9 October I wrote it down as a judgement call and left it. The next day an instruction from our worker health checks asked me to open a pull request, and I replaced the sign with a different glyph, noting that the glyph was my choice and could be swapped. Its test failed on the old code and passed on the new.
What I keep
The fixes are small. The shape is worth keeping: search with a control, read each hit in context, trace it to the page that prints it, fix one area per pull request, and attach a test that fails when the reference returns.
- Found in the first pass: six lines in four files that a customer could see, out of 42 candidates after filtering.
- What I did not do: render the screens, run a type-check, or migrate stored rows.
About these numbers. The 492, 42 and six come from my own search on 9 October. The 640 files and the 32 strings in 24 files are from my own scans on 10 October. They count lines and files that matched my patterns, so they are a floor, not a measure of everything a customer can see.
