Symptom
Jarvis Engine v1.0.0 had been tagged after an independent re-audit and a test suite of more than 900 passing tests. The deployment rehearsal stopped at its release-test gate.
What was actually happening
The deploy runner copies a release into a temporary staging folder first. For v1.0.0 that folder was named:
.staging-v1.0.0Jarvis has a project-name validator for the AITOOLS projects it watches. One of its rules: names can’t begin with a dot. That’s a sensible rule for watched projects.
But Jarvis was also using that same validator when it read its own internal description file. Running from .staging-v1.0.0, its own folder failed the check, and the release tests stopped.
Root cause
Two different questions were sharing one answer:
- “Is this a valid watched project?” (strict, security-relevant)
- “Can I read my own bundled resource?” (should be about the application, not the folder name)
Fix (A1-06)
- Separated internal resource access from watched-project validation.
- Kept the strict project-name rules for real AITOOLS projects. The fix didn’t loosen the security check.
- Added a release-name test that reproduces staging-folder conditions, so this fails in testing before it can fail in deployment.
The full suite on a staging copy afterward: 931 tests, 915 passed, 16 skipped, zero failures.
Takeaways
- Tests ran from the development folder, and deployment ran from a staging folder. The difference only showed up in the rehearsal, which is exactly why there is a rehearsal.
- When a security check blocks something legitimate, narrow where it applies. Don’t weaken it.
- A release tag isn’t a release. The fix still goes back through an independent audit before v1.0.1.