CARBON — Engineering ConfidenceUser Guide
CHAPTER 24 / 60 Pro

/carbon-state

Hunt lost, inconsistent, stale or invalid application state through read-only code inspection and scoped browser/API scenarios. Test multi-tab and independent-user interleavings, save/reload, export/reimport, persistence, invalid stored data and recovery. Preserve originals and use isolated synthetic state for corruption or destructive checks.

Arjun · Data integritySecurity & resilience

When to use it

The problem appears after refresh, navigation, sign-in or concurrent activity.

Before you start

Write the state sequence and expected invariants. Test guest/account handoff, separate users, tabs, save/reload and round trips. Use isolated records for malformed-state or destructive cases.

Try this in your coding agent.

/carbon-state Check whether cart contents survive refresh, back navigation and sign-in.

Replace sample paths with your project. Slash names are shorthand; your host may use a plugin prefix or a skill picker. Invocation help →

ILLUSTRATIVE WALKTHROUGH

Cart state transitions

An expanded teaching example, not a recorded or live execution. The report stays visible while the replay explains how to read it.

  1. 01Read context
  2. 02Investigate
  3. 03Show evidence
  4. 04Report

Coding-agent conversation

Read context

I’m reviewing cart state transitions. I’ll keep the scope and permissions explicit.

Investigate

Follow the weakest evidence link and record what remains blocked.

Show evidence

Here is the evidence trail to inspect: Guest cart → sign-in → account cart → compare item IDs and quantities.

Report

Signing in replaces the guest cart without a visible merge rule. Concurrent sessions and offline sync remain untested.

CARBON

Example report

Illustration
Follow the cart state
Follow the cart state — TestBucks teaching screen

TestBucks course screen with illustrative analysis. The screenshot supplies context; the demo does not establish a newly observed bug.

  1. Cart input
  2. Totals & state
  3. Checkout evidence

Illustrated outcome

Signing in replaces the guest cart without a visible merge rule.

Evidence to inspect

Guest cart → sign-in → account cart → compare item IDs and quantities.

Still untested / not established

Concurrent sessions and offline sync remain untested.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For cart state transitions, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Guest cart → sign-in → account cart → compare item IDs and quantities. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

Concurrent sessions and offline sync remain untested.

The next decision

Decide whether the evidence calls for a focused check, a reviewed fix or more context. Do not convert a plausible example into a verified finding.

Adapt the example to your project

  1. Replace cart state transitions with a real feature, path or decision in your project.
  2. State the expected rule and its source. Include safe fixtures, constraints and a budget where appropriate.
  3. Ask for exact evidence and remaining gaps. Approve consequential actions separately.
/jay Review the /carbon-state result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-reliability →/carbon-data →

Content checked against the local command definition: skills/carbon-state/SKILL.md. Examples adapted from the homepage’s TestBucks walkthroughs. Availability is edition- and host-dependent.