0019 Repository-Centered Default Workflow
Date: 2026-07-21
Status
Accepted and active.
Context
Earlier Harness versions made workflow bookkeeping compete with the repository for authority. That added ceremony to bounded changes, encouraged self-reported completion, and made current work harder to retrieve from ordinary code review.
Complex work still needs durable memory, and consequential product choices still need explicit human authority. Those needs do not require a parallel task control plane.
Decision
- Product documents, architecture, decisions, plans, code, tests, CI, runtime signals, and Git history are the system of record.
AGENTS.mdremains a small stable entrypoint and points todocs/WORKFLOW.md.- Read-only work inspects only what the answer needs and makes no mutation.
- Bounded changes use an ephemeral plan, local authority, and relevant proof.
- Work that spans sessions, coordinates contributors, has meaningful dependencies, or requires recovery uses one file under
docs/plans/active/. - Materially different externally observable choices stop before editing. Configurable defaults are not authority.
- Completion requires executable or observable evidence appropriate to the behavior.
- Lasting decisions are indexed Git-native documents. Task-local choices stay in the execution plan.
Alternatives Considered
- Require one lifecycle for every task. Rejected because work shape, not a global process ladder, determines the memory and proof required.
- Remove durable planning. Rejected because coordinated and recoverable work must survive session boundaries.
- Treat all sensitive terminology as an approval gate. Rejected because authority depends on an actual unresolved choice, not keywords.
Consequences
- Small work stays cheap and directly reviewable.
- Complex work remains resumable without duplicate task truth.
- Weak product tests and runtime guidance become visible instead of being masked by workflow metadata.
- Maintainers must resist adding replacement ceremony without representative evidence.