The architecture satisfaction loop

# The architecture satisfaction loop

## Purpose

A bounded refactoring workflow that live-tests the system, runs an independent review, commits checkpoints, and records progress.

## Prompt

```text
Refactor until you are happy with the architecture. After each significant step, live-test the system, run autoreview, and commit. Track progress in /tmp/refactor-{projectname}.md.
```

## When To Use

Use this for a deliberate architectural refactor where the destination can be stated in concrete terms and the current system can be tested after each meaningful change.

## Workflow

- Write down the architectural target, constraints, and current risks before editing code.
- Make one significant, reviewable change at a time.
- Live-test the affected behavior and run an independent review after each significant step.
- Commit each verified checkpoint and update the temporary progress file with decisions, blockers, and the next action.

## Verifier

The architecture is satisfactory and checks pass.

Live-test, autoreview, and commit each significant step.

## Notes

Small verified checkpoints reduce refactor risk and preserve rollback points. The progress file keeps the goal and decisions available across long sessions or handoffs.

Define what satisfactory means before starting, such as module boundaries, dependency direction, passing tests, and acceptable performance. A subjective stop condition can otherwise run indefinitely.

## Source

- Source: Forward Future Loop Library
- Author: Peter Steinberger
- Published: 2026-06-12
- Modified: 2026-06-17
- URL: https://signals.forwardfuture.ai/loop-library/loops/architecture-satisfaction-loop/