Skip to main content
addly

A known limitation should be easier to find than a sales argument.

No real product incident exists in this showcase. This register addresses each concept’s declared limitations, scope, workaround, and evidence still required.

Not an incident history

Each identifier describes a concept limitation or missing evidence—never an outage, an affected customer, or an invented fix.

Eight addressable limitations, linked to their path.

Filters remain in the URL. Every row has a stable permanent link and connects the concept, documentation, roadmap, and changelog traces that provide context—without claiming to resolve the limitation.

Filter the register

1 items visible out of 8.

Reset
Readiness for JiraDeclared limitation

limit-readiness-states

Not every off-happy-path state is interactive

The demo makes the primary verdict testable but does not yet simulate every empty, recoverable-error, or insufficient-permission state.

Scope
Local showcase · simulated Jira Cloud · issue panel
Last review
· no delivery date
Rationale
The concept first validates the verdict and its criteria; recovery states do not yet have a complete protocol.
Workaround
Record these states as blocked evidence in the evaluation packet and draw no conclusion about their behavior.

The format will change only when a real product exists.

A future confirmed issue will remain separate from a vulnerability and a service incident.

  • 01Verifiable product, hosting, version, and confirmation date.
  • 02Observable symptom, scope, and trigger conditions.
  • 03Tested workaround, side effects, and review owner.
  • 04Fix state without an invented delivery date.
  • 05Exact links to support, status, changelog, and corrected documentation.

A documented limitation protects better than an optimistic FAQ.

Open the relevant identifier, verify its workaround, and follow the linked work. A future outage belongs on Status; this register remains functional.