---
name: loom-doubt-driven-development
description: "Use when a non-trivial in-flight claim needs a challenge posture before more work depends on it, especially claims about behavior, safety, migration, compatibility, ordering, permissions, evidence, or review conclusions."
---

# loom-doubt-driven-development

Doubt-driven development is an in-flight challenge playbook.

It names the claim, extracts the smallest reviewable artifact and contract, runs a
fresh-context challenge when useful, reconciles findings, and routes durable output
through audit, evidence, tickets, specs, research, or constitution.

## Core Dependency

Use `loom-core` first. This playbook composes `loom-ralph`, `loom-audit`,
`loom-evidence`, `loom-tickets`, `loom-specs`, `loom-research`, and
`loom-constitution`.

Use this playbook for review posture. Use `loom-audit` when the challenge result
should be recorded as an audit.

## Use This Playbook When

Use this playbook when a claim is non-trivial, including:

- branching logic or invariants changed
- a module, service, storage, API, or worker boundary changed
- safety depends on ordering, idempotency, concurrency, caching, auth, permissions,
  migration, compatibility, or external behavior
- an implementation asserts it matches a spec or acceptance criterion
- a high-risk diff appears correct but would be expensive to debug later
- the current context has become invested in one interpretation

Skip it for mechanical renames, formatting, obvious one-line changes, simple file
moves, and local summaries.

## Route

Use this route:

```text
claim -> extract -> challenge -> reconcile -> record -> stop
```

## Claim

Name the claim in one or two sentences.

Examples:

- this cache update is idempotent under retry
- this migration preserves existing records
- this UI change satisfies `spec:checkout-flow#SCN-003`
- this ticket has enough evidence to close
- this API change is backward compatible

If the claim cannot be stated compactly, shape it before review.

## Extract

Extract the smallest reviewable artifact and contract.

Artifact examples:

- focused diff or changed function
- ticket closure story and evidence set
- spec requirement and scenario
- migration plan or SQL
- API contract and implementation
- command output or evidence dossier

Contract examples:

- `REQ-*`, `SCN-*`, or `ACC-*` IDs
- expected input/output behavior
- security or compatibility constraint
- migration invariant
- performance budget
- ticket scope and non-goals

Do not pass a broad transcript. Use records, diffs, evidence, and source excerpts.

## Challenge

Choose the challenge shape:

- failing test or reproduction when behavior can be disproved directly
- Ralph packet with `Mode: review` for a fresh-context worker
- `loom-audit` when the result should be durable review judgment
- local self-check only for low-risk work where no fresh context is available

The reviewer should look for:

- unstated assumptions
- contract gaps
- edge cases
- stale context
- evidence gaps
- boundary violations
- compatibility breaks
- security or data risks
- ways the artifact could satisfy tests while violating intent

## Reconcile

Classify each finding:

- actionable: change the artifact or record
- contract gap: update or route the contract before implementation continues
- evidence gap: gather or record evidence
- valid residual risk: record in the consuming surface with authority
- superseded: newer source state, scope, or evidence replaces it
- invalid: reject with evidence or source reality

Reviewer output is input to judgment. It does not automatically change the ticket,
spec, plan, or constitution.

## Record

Route durable results:

- audit findings and verdict -> `loom-audit`
- observed proof or challenge -> `loom-evidence`
- implementation follow-up -> `loom-tickets`
- behavior contract change -> `loom-specs`
- tradeoff, rejected path, or source conclusion -> `loom-research`
- durable precedent or policy -> `loom-constitution`
- reusable prevention lesson -> `loom-retrospective` then `loom-knowledge` when it
  becomes accepted knowledge

## Stop

Stop when:

- findings are resolved, routed, or intentionally accepted
- the artifact is too broad and needs decomposition
- the contract is not clear enough to review
- additional challenge would inspect unchanged material
- the operator accepts the residual risk

## Done Means

The doubt pass is done when:

- the claim, artifact, and contract are explicit
- challenge output was gathered or the lack of fresh context is visible
- findings were classified rather than copied forward blindly
- durable findings, evidence, or follow-up were routed to core records
- the next move is clear