CARBON — Engineering ConfidenceUser Guide
CHAPTER 32 / 60 Pro

/failure

Run copy-only CARBON failure-injection and error-condition testing against an app, API, service, build, configuration, dataset, or artifact.

Fatima · Error UXSecurity & resilience

When to use it

You need to force errors without damaging the original project.

Before you start

Make a disposable copy and define a single fault. Inject it only there, inspect recovery and retain the original unchanged. Cleanup and restoration are part of the scenario, not optional afterthoughts.

Try this in your coding agent.

/failure In a disposable copy, inject a failed checkout response and check recovery.

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

Disposable-copy failure injection

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 disposable-copy failure injection. 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: Copy project → stub HTTP 503 → submit → verify retry message and cart preservation.

Report

A failed checkout response clears the cart before recovery. Faults are confined to the disposable copy; production is untouched.

CARBON

Example report

Illustration
Failure → evidence → recovery
Failure → evidence → recovery — TestBucks teaching screen

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

  1. Failed request
  2. Preserved state
  3. Safe retry

Illustrated outcome

A failed checkout response clears the cart before recovery.

Evidence to inspect

Copy project → stub HTTP 503 → submit → verify retry message and cart preservation.

Still untested / not established

Faults are confined to the disposable copy; production is untouched.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For disposable-copy failure injection, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Copy project → stub HTTP 503 → submit → verify retry message and cart preservation. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

Faults are confined to the disposable copy; production is untouched.

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 disposable-copy failure injection 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 /failure result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-reliability →/carbon-generate →

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