Perspective · quality and recovery

Defects are work, not afterthoughts.

Defects move through the same operational model as other work: intake, bounded allocation, owner handoff, repair assignment, completion, and verification evidence. A defect is not merely a note that someone promises to remember.

Defects perspective showing defect, assignment, and completion lanes

Recovery stays traceable.

The Defects perspective is a sibling of Execution. Humans and agents can create defect records, but the repair path should still become bounded project work with allocation, reassignment discipline, completion state, and test or verification evidence.

Defect intake

Failures and regressions enter the same model with severity, description, refs, and verification expectations.

Bounded allocation

The next repair owner is explicit, reassignment is controlled, and the work does not drift through memory.

Verification evidence

The closeout path points back to tests, smoke checks, or review evidence rather than a vague “fixed” label.

The recovery view of the same work.

Defects belong inside the same model because recovery is not separate from delivery. A defect may start as a failure report, but it quickly becomes assignment, discussion, implementation, verification, and release evidence. If that chain is split across tools, the repair can look complete while the project still cannot prove what happened.

The Defects perspective follows the Execution substrate on purpose. Intake creates a durable object. Allocation makes ownership explicit. Repair becomes bounded work. Completion requires evidence. The result is not just a list of bugs; it is a recovery lane connected to the rest of the project truth.

A fixed label is not recovery. Recovery is the defect, the assignment, and the evidence closing together.

This also makes defects useful for agents. An agent should be able to see the defect, the owner, the references, the expected verification, and the surrounding messages without reconstructing the story from memory.