Debugging guides
A Jam.dev alternative when you need to reproduce the bug locally
The bug report is clear. QA picked a workspace, changed an invitation from editor to viewer, entered three addresses and clicked Send. One address was rejected. The form cleared all three.
The recording shows the reset. The developer still needs the pending invitations, the relevant permissions and the response that rejected one address.
For a Jam user, the relevant question is what happens after the report has been understood. Can the developer reach the same failure on local code, and do it again after the first patch? The invitation case below is an example, not a customer incident.
Jam is more than a screen recorder
Jam captures technical context alongside screenshots or video, including console and network information and browser details. It supports links for collecting recordings and integrations with task trackers. Jam MCP can give a coding agent access to recording details, logs, requests and frames. 1, 2
If your problem is incomplete bug reports, those capabilities may be precisely what you need. A report that identifies the failed request and shows the symptom can be enough to find the mistake in the code.
The remaining problem may be setup: which workspace, which pending invitations and which rejection need to be present for the next check?
Who prepares the next attempt?
Continue the invitation example. The developer recreates the failure locally and changes the form reset logic. They now need to check it again. Meanwhile, one of the test users has accepted an invitation and the API no longer returns the same partial rejection.
The developer can seed fresh invitations, use a fixture or mock the rejection. A StatePort Card is another option when the failing setup was captured and can be reopened on the local app.
The Jam report remains useful evidence throughout that work. The additional requirement is an executable setup for the new code, whether you express it as fixtures, mocks or a captured StatePort case.
In StatePort’s Local app path, the frontend being tested is the running local application. Retained matching responses can supply its dependencies. That lets the developer change the form code without depending on the test server continuing to produce that particular rejection. 3
Which problem are you replacing Jam for?
| Work you need to do | Start here |
|---|---|
| Show the symptom with console and network context | A Jam report may already be enough |
| Ask an external person to record what they are seeing | Evaluate Jam’s recording-link workflow |
| Investigate a known local failure with working test fixtures | Keep the fixtures and tests |
| Return to a complicated supported setup after each edit | Try a StatePort capture and local reopen |
| Prove that server-side permissions or writes are fixed | Use an authorised backend test as well |
The first two rows describe documented Jam capabilities. The remaining rows are workflow choices, not a measured ranking. 1
What a useful StatePort Card would contain
For this example, the Card needs to preserve enough of the invitation flow to reach the rejection: the supported actions and form state, the relevant page context and the necessary recorded dependencies. Capture the failing path in StatePort, review what was retained and save it. Then test a reopen before relying on the Card for the investigation. 3, 4
Do not save a generic members-page snapshot and call the problem reproduced. Agree on the disputed behaviour first. In this example, the rejected email must remain editable and unrelated input must survive; what happens to accepted addresses is a separate requirement to confirm with QA.
The Card is not the customer’s account. A recipient may need their own compatible sign-in. It also cannot recover a response that was never captured or reconstruct arbitrary server state from a video. 3
There is no automatic Jam-link-to-State-Card import in the workflow described here. The capture is a separate StatePort operation while the relevant setup is available. A Jam recording can guide that work; it is not silently converted into an executable environment.
Leave the decision in the issue
A developer should not have to hunt through two comment systems to find the expected behaviour. Keep the bug, ownership, discussion and decision in the team’s existing issue or PR. Attach or link the useful material there.
For this example, the issue can keep the instructions short:
Symptom: partial invitation rejection clears every address.
Expected: retain rejected entries for correction.
Observed before fix: all fields clear after the error.
Reproduction: reviewed State Card, invitation-rejection case.
Check: same role, same rejection, editable rejected address.
Not established: whether the live API accepts a changed payload.Replace the example observations with your actual results before posting. Attach a short recording only if the form reset is hard to explain with the report and field values.
When Jam is the better fit
Jam may already solve the problem when a clear report and technical context are enough to diagnose the issue, and the team has a reliable test for the fix. Reporters do not need to adopt a new capture workflow in that case.
StatePort is worth trying when the repeated setup itself is slowing the investigation. Test it with one case whose conditions are genuinely awkward to rebuild. Check a second reopen after changing the frontend. That is a more useful evaluation than counting saved Cards.
Start with the first-Card guide and current beta limits. Reproduction on changed code uses Developer access; see plans and trial.
For an existing test-based setup, the Playwright and HAR comparison is a closer match than a bug-reporting comparison.
Sources
Written by StatePort. Documentation checked on 13 October 2026; no customer migration, head-to-head benchmark or Jam import is claimed.