Make one scarce test window teach you more.
Introduction site · 한국어 · Method · Safety · AI specification
Some tests are easy to repeat. Others depend on a market session, a hardware rig, a field visit, a partner system, or a twelve-hour soak. One ordinary mistake can waste the whole opportunity, while the next real attempt may be a day or a week away.
TWDD is a research-stage method for this second kind of work. It prepares a scarce test window so a non-critical fault can be contained, the safe remainder can keep running, and every useful event becomes evidence for offline replay and repair.
TWDD does not mean ignoring errors. It means deciding before the run which errors must stop everything and which can be isolated without crossing a safety boundary.
Frame the Window → Preflight → Arm Guardrails → Run
→ Contain / Degrade → Harvest Evidence
→ Replay → Batch Repair → Revalidate
The live window is only one part of the method. Most leverage comes from preparing the run, preserving evidence, and converting live incidents into repeatable local tests.
| Response | Use it when | What happens |
|---|---|---|
Abort |
Safety, money, authorization, data integrity, or legal limits may be crossed | Stop in a known-safe state and block further side effects. |
Isolate |
One component or scenario could contaminate the rest | Quarantine that unit and continue only independent scenarios. |
Degrade |
The core observation remains safe without an optional capability | Enter a declared reduced mode and record it. |
Continue |
An expected non-critical fault does not affect the objective | Record structured evidence and move to the next scenario. |
An unclassified error is Abort. A recovered error is still a failed or degraded observation; it is never silently counted as a pass.
| Question | Primary method |
|---|---|
| What should the product mean or do? | IDD can use isolated implementations to discover product meaning. |
| How should known behavior be fixed and checked? | TDD and contract-first development encode agreed behavior and invariants. |
| How do we learn safely when real validation is scarce? | TWDD prepares, runs, observes, and replays the scarce window. |
These methods can be composed. A team may discover behavior with IDD, contract it with tests, validate it through TWDD, and add every live finding to an offline regression suite.
- the real test depends on a schedule, scarce equipment, a partner, or an expensive long run;
- several scenarios must be observed during one window;
- non-critical failures can be isolated without weakening hard safety limits; and
- inputs, decisions, outputs, exceptions, and external responses can be captured for replay.
Do not use TWDD to justify continued operation across an unsafe or irreversible boundary. Payments, authorization, destructive data changes, regulated actions, and other high-impact effects still need explicit contracts, domain controls, limits, and kill switches before a live run.
- What TWDD is
- The working method
- Safety and error policy
- Agent skill and plugin support
- Test Window Manifest
- Relationship to IDD and TDD
- Research basis
- Project status
- Hosting policy
The canonical skills/twdd/SKILL.md is packaged for Codex, Claude Code, and Gemini CLI. Claude Code can install it directly from this repository:
/plugin marketplace add SoliEstre/twdd
/plugin install twdd@twdd
Then invoke /twdd:twdd or describe a scarce market, hardware, field, partner, or long-running validation window. See agent skill and plugin support for all platforms and current distribution limits.
This repository contains a public research draft and an initial agent skill, not a validated standard, stable toolchain, or guarantee of first-run success. The name and composition are proposals. The project has not yet published controlled pilot evidence showing that TWDD reduces retest count or improves quality.
Project-owned material is available under the MIT License. Linked third-party publications retain their own terms.