Files
tegwick-control/OPERATING_MODEL.md

66 lines
1.9 KiB
Markdown

# Operating Model
## Purpose
This operating model defines how `tegwick-control` is used to reduce decision fatigue, keep important topics visible, and enable safe agent-assisted progress.
## Core Rules
### 1. Everything has a place
Unplaced topics create mental load. Every relevant topic should eventually have a home.
### 2. Not everything is active
A topic may be important without being active.
### 3. Commitments are different from options
Options can be collected freely. Commitments require ownership, next actions, and consequences.
### 4. Agentic work must be bounded
Agents should receive clearly scoped tasks with explicit allowed changes, expected outputs, and approval boundaries.
### 5. The system must protect energy
The purpose is continuous progress, not constant pressure.
## Work Classes
| Class | Meaning |
|---|---|
| Commitment | Something that must be done |
| Option | Something that may be valuable |
| Exploration | Something unclear that needs investigation |
| Decision | Something that requires choosing |
| Waiting | Something blocked by another person/system |
| Routine | Something recurring |
| Someday | Valuable but inactive |
## Review Surfaces
| Surface | Purpose |
|---|---|
| `TASKS.md` | Current actionable work |
| `DECISIONS.md` | Open and resolved decisions |
| `PROJECT_LANDSCAPE.md` | Major topic map |
| `areas/` | Per-topic notes and control cards |
| `WORKPLAN.md` | Sequenced setup plan |
| `inbox/` | Temporary capture area |
## Commitment Rule
No item becomes a commitment merely because it is interesting, important, or emotionally charged.
A commitment should have:
- an owner;
- a clear next action;
- a reason for acting now;
- a defined review surface.
## Agentic Coding Rule
No implementation work should be delegated to an agent until the target repo, intended outcome, boundaries, and approval requirements are clear.