The change
01What production-sensitive behaviour changed?
A pull request may touch identity, authorization, data, payments, webhooks, caching, or deployment behaviour.
Public beta · JavaScript and TypeScript
Review production-safety evidence before merging JS/TS pull requests.
Qedix reviews risky JavaScript and TypeScript changes and shows maintainers what safety evidence exists, what appears missing, and where review attention is needed.
- Advisory by default
- JavaScript and TypeScript pull requests
- Evidence linked to changed code
- Maintainers make the final decision
Illustrative Qedix report
Pull request #482
Make order creation atomic
src/api/orders/route.tsmodified
await db.order.create(orderInput);
await db.inventory.update(stockChange);Request schema validation
ObservedValidation evidence is visible before the changed write path.
Atomic transaction boundary
Not provenThe dependent writes are visible, but one transaction boundary is not proven.
Failure-path verification
ReviewVerify that a second-write failure cannot leave partial order state.
Evidence is advisoryMaintainer decides
The production gap
A green pipeline can still leave important assumptions unproven.
Tests, type checking, linting, and security tools remain essential. Qedix adds a pull-request evidence view focused on production-sensitive changes and the controls around them.
The control
02Which safety control should be visible?
The expected evidence depends on the changed path: validation, ownership, signature verification, transaction scope, or another control.
The decision
03What still needs maintainer judgment?
Qedix separates visible evidence from assumptions that require tests, runtime context, or application-specific review.
How it works
Connect once. Review every supported pull request with fresh evidence.
Qedix stays inside the GitHub review workflow. It gives maintainers an advisory evidence layer without taking ownership of merge or deployment decisions.
- 01
Connect selected repositories
Install the Qedix GitHub App only on the repositories your team wants reviewed.
- 02
Open or update a pull request
Qedix reviews the supported JavaScript and TypeScript changes associated with the pull request.
- 03
Review evidence before merge
See what production-safety evidence is visible, what appears missing, and where maintainer attention is needed.
Evidence, not a mystery score
Three states make the review decision easier to understand.
Qedix distinguishes visible evidence from missing proof and context-dependent review. The result remains explainable and advisory.
Observed
Relevant production-safety evidence is visible in the reviewed pull-request context.
Not proven
Qedix did not find enough visible evidence to support the expected safety control.
Review
The change needs application-specific context or maintainer judgment before merge.
What maintainers receive
A review path connected to changed code.
Reports organize affected files, visible controls, missing evidence, review context, and suggested verification. They are designed to support a decision, not hide it behind one unexplained score.
- Affected code
- Files and relevant changed locations
- Visible evidence
- Controls found in reviewed context
- Missing proof
- Expected evidence not established
- Next verification
- Focused maintainer review or tests
Production-sensitive coverage
Focused review for changes that can fail beyond CI.
Qedix organizes review attention around production-sensitive JavaScript and TypeScript paths. Coverage depends on the changed code and the evidence visible in pull-request context.
01
Authorization
Review changes that may weaken access checks, roles, permissions, ownership, or protected operations.
02
Authentication
Surface changes involving sessions, tokens, identity verification, and authentication boundaries.
03
Request validation
Check whether changed request paths show appropriate schema and input-validation evidence.
04
Webhook safety
Review signature verification, replay handling, deduplication, and side-effect ordering.
05
Payment paths
Highlight sensitive payment, entitlement, amount, and provider-event changes that require careful review.
06
Database integrity
Review destructive writes, transaction boundaries, mutation scope, and consistency-sensitive changes.
07
Tenant isolation
Surface changed reads and writes where organization, workspace, owner, or tenant scope needs evidence.
08
Secrets and errors
Review changed paths that may expose credentials, sensitive values, internal errors, or unsafe logging.
09
Caching and deployment
Highlight stale authorization, invalidation, dependency, build, migration, and deployment risks.
Coverage descriptions are product guidance, not a guarantee that every defect or vulnerability will be detected.
Clear product boundaries
Designed to strengthen review, not replace engineering judgment.
Trust starts with precise limits. Qedix works alongside your existing quality, security, and deployment process.
1
Qedix is advisory
It organizes evidence and review attention. It does not replace maintainers, security review, tests, or deployment approval.
2
A clean result is not a guarantee
Static pull-request analysis cannot prove that software is secure, correct, compliant, or free from defects.
3
Suggested tests are not executed tests
When Qedix recommends a test, the recommendation does not mean that Qedix executed the application or test suite.
4
Pull-request context has limits
Runtime configuration, infrastructure, external services, and application-specific behaviour may require separate verification.
Trust and control
Your team stays in control of access and decisions.
Qedix is built around selected GitHub repository access, advisory results, and evidence that maintainers can review in context.
01
Repository selection stays with administrators
Authorized GitHub administrators control which repositories are connected to Qedix.
02
No persistent full-repository copy
Repository source is processed temporarily for authorized analysis. Qedix retains selected repository and pull-request metadata, analysis results, affected file references, and limited redacted evidence excerpts.
03
Results remain evidence, not authority
Qedix does not automatically approve, merge, deploy, or make the final release decision.
04
Evidence remains inspectable
Reports connect recommendations to affected code and visible or missing evidence instead of asking teams to trust an unexplained conclusion.
Free during public beta
Add production-safety evidence to your next pull request.
Install Qedix on selected repositories. No beta access request or paid subscription is currently required.
Product support
Questions before you connect Qedix?
Ask about installation, repository permissions, public beta access, your first report, or removing Qedix.
Direct emailinfo@qohere.in