Rename the board for my_app, and the worker in myXapp could lose its place. The two names differ by one character. In a filesystem that is ordinary. Inside SQL's LIKE pattern, the underscore means any single character.
OpenWorker pull request #556, merged September 18, fixes that collision in the migration from a filesystem-based board identity to a Git-based one. Its public description is explicitly marked “Written by Devin.” That establishes an attributed coding-agent contribution; it does not tell us how much prompting, editing or human review the work required. The linked private session is not needed as evidence.
A parameter can still contain a pattern
OpenWorker's team store keeps a board event log and per-agent reading positions. A cursor says how far a worker has consumed its feed. Moving a space to a new key must carry that position along without changing another space's state.
The old query already used a bound SQL parameter. The bug was what the parameter meant: a wildcard prefix followed by the unescaped old path. Looking for a cursor ending in /w/my_app also selected one ending in /w/myXapp. The subsequent rewrite sliced off the old suffix and appended the destination. With UPDATE OR REPLACE, colliding keys could remove a cursor row. A lookup for the neighboring space then fell back to zero.
This is why the small patch carries more than a string-cleanup lesson. The identity migration also moves board records and rebuilds the event hash chain because the space identity participates in it. A mistaken selection in the cursor step reaches the agent's delivery state: a worker may receive events it had already consumed. The inspected evidence demonstrates cursor loss, not a measured incident of repeated external actions.
The fix escapes backslashes, percent signs and underscores in the literal suffix and gives SQL an explicit escape character. The leading wildcard remains intentional: the cursor prefix contains the reader's identity. The path portion stops behaving as a pattern.
Builder lesson: test the neighbor
The transferable skill is to test the boundary of a migration's write set. Create two plausible identities that the old selector confuses. Give them different reading positions. Migrate only one. Then assert both that the destination inherited the intended position and that the neighbor kept its own.
The added regression test does exactly that with an underscore and an X. A test containing only the target workspace could have reported a successful migration while missing the collateral damage.
We also exercised the prepared repository's actual TeamStore against temporary SQLite databases. The underscore case preserved both positions, as did additional percent-sign and backslash cases. This was a focused store-level check, not the full application suite or a running agent-team test.
The first impression—a parameterized query should already be safe—confuses SQL syntax separation with pattern semantics. A bound value still has wildcard meaning when the operator is LIKE. For builders using coding agents on migrations, the review question is concrete: which almost-matching row would prove that this patch touches only the state it owns?