Choosing
Deciding whether to bring someone else's work in. What counts as grounds for rejection, and when a rejection gets reopened.
Far more gets turned down than taken in. Across the forty pieces in Teardowns, exactly one tool made it to an install.
So this section is not about what I picked. It is about how a rejection gets written down. A rejection that records only the conclusion tells future me nothing, and when there is nothing to read, the same investigation opens again.
Posts
| Post | The problem |
|---|---|
| Forty rejections, and the reason was rarely the tool | What to record when the subject of the verdict is my environment, not the tool |
| You don’t have it if it has never run | Which layer are you judging “we already have this” at |
Not written yet
- What happens when a reopen condition actually fires. Twenty-one are written down and none has fired
- What else to record when I reject something others have already adopted, so the rejection isn’t misread
- What changes if I build something that counts run history automatically — right now there is only a proxy
The rule for this section
A rejection carries both its reason and its reopen condition, and that condition is written against a change in my environment, not a change in the tool. “When it gets more stars” or “when the version goes up” is not a condition — it is a deferral with no deadline. That sentence fires nothing six months later.