What is verified before anything ships

This page names the mistakes I found in my own work, and the points that are still open. Evidence beats promises, and a gap that has been named does less damage than one somebody else discovers later.

The Jira apps in numbers

Every number below comes from a measurement run across all ten apps on 31 August 2026 and describes the state on that day, not from an estimate.

• 158 automated test cases in 18 test files, spread across all ten apps. On the re-run, ten of ten test suites passed and none failed. Core logic is tested separately from the interface: each app's calculation logic is its own side-effect-free unit that runs without Jira. Five apps additionally test the application layer against stubbed Forge APIs.
• Nine of ten apps request no write permission at all on your Jira data. The one exception is Tree Clone, where creating issues is the entire point. No app requests more than two permissions, and none of the ten Forge manifests declares an external domain or any data egress.
• A central review module with thirteen stages accompanies every app from market research through to life after release. That module carries 83 tests of its own, so it checks itself.
• No language model signs off an app. The approval stage actively rejects agent identities, including disguised spellings using Cyrillic look-alike characters. And the independent second review may not come from the same model family that wrote the code.

What is explicitly open on the apps

Every app carries a matrix of failure classes, from missing permissions to a dropped network connection. Each cell has a status, and open cells stay visibly open instead of quietly disappearing. Right now, of 120 required cells, 22 are tested, 26 are not applicable and 72 are open. What is open is mostly the rarer failure paths: rate limits, API errors and network interruptions. The core logic is covered by the test suite above.

Two more open points: the late stages of the review model (marketplace release, documentation completeness, approval, post-release) have no recorded results yet for the current apps. And one app is blocked at the implementation-quality stage because its dependencies carry five high-severity vulnerabilities. Both are on record in the review logs and are being worked through.

A find from my own work shows why that skepticism is needed: in Tree Clone, a deliberately introduced fault stayed green at first, because the test data was already pre-sorted. The measurement was blind. After hardening, the same fault tripped three checks. A green test proves something only once you have seen it fail.

Limits

"Tested" is an engineering statement, not legal advice and not a certificate. The numbers on this page describe the state of the test run on 31 August 2026; after major changes, things get measured again.