The Veil has been exercised through long conversations, browser sessions, voice, bridges, games, and multiple companion routes. That field history is stronger than a toy demo, yet it is difficult for a reviewer to replay consistently.
Changes to prompt assembly, service workers, global script order, or context filtering can regress a path that manual testing does not happen to touch. The answer is not to dismiss field evidence, but to turn its recurring failures into named test vectors.
What was actually going wrong
Manual success and lived use were sometimes asked to serve as permanent proof for every future build.
What I tried
- Retesting only the feature changed most recently
- Keeping bug examples solely in conversation notes
- Using one happy-path chat as a release check
Real incidents become repeatable vectors for blank output, context slicing, family-safe routing, bridge isolation, and version drift.
Why it worked
Tests preserve the knowledge gained in the field and make it visible before deployment.
Field testing discovers the right tests; regression proof keeps their lessons.
Where EACI uses this today
Main architecture is evaluated as a connected companion system, with new regressions tied back to concrete runtime evidence.
This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.