22 fixes in three stages: how not to break a working system
While we were taking screenshots for this journal, a list of 22 flaws built up. Handing it to the agent as one task would have been the surest way to break something. How we split the work.
Every screenshot for this journal is a careful look at one screen. Almost every one revealed something small: a wrong active tab, a stretched label, “3 request” instead of “3 requests”. But there were serious things too: repeat imports crashed, and a third of the collection couldn’t be lent (see “Code 02”). We didn’t send each finding straight away but collected them in a separate file. By the end of the shoot it had 22 items.
Three stages instead of one task
- The essentials — 6 itemsRepeat imports, Aleph status codes, collections, the new-record form, a safe default import mode, the login lockout message.
- Catalogue correctness — 7 itemsThe collection filter, languages, rare books, volumes of multi-volume works, statistics.
- Interface — 10 itemsHeader, accounts, call-number label, appearance, login page, language selection.
Each stage went to the agent only after the previous one had been checked.
Rules for every stage
- A database backup before any change — and a check that it really restores.
- Only the items of the stage. Nothing “along the way”; if more is needed — stop and ask.
- Database structure changes are additive only: nothing deleted or renamed.
- Legal texts, cookies and security settings are off limits.
- Risky tests run only on a copy of the database.
- Nothing is published without the author’s decision.
Fast or safe
In the first stage the agent ran all eight core scenarios after every single item — search, record page, the whole request path, deletion and trash, login, ISBN, legal pages. Safe, but slow. From the second stage on we changed the rule: after each item, check only what it touches; run the full check once at the end. Safety didn’t suffer, and the time dropped noticeably.
What the agent caught itself
During a trial repeat import on a database copy, 958 extra items appeared. The agent found the cause and fixed it before the bug could reach the working database. That is exactly what copies are for. And it didn’t bend the result to our expectations: we had written “about 20 languages”, it honestly counted 15.
Code and data are different things
The last lesson came while preparing the release. Publishing moves the program and the database structure to the site — but not the data corrected in development. The removed false “holds”, the new collection codes, the normalised languages stay where they were fixed. For a production catalogue this would need a separate careful step. Our site holds test data, so we decided not to build a separate tool for it and to start later from a clean catalogue load.