ZacharyZhang-NY
e74dafcd36
Three independently ugly bugs that all fed the same log flood:
* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
to stderr via `console.error`. When the worker fans a second
agent-event past a reloading renderer, we produced thousands of
identical lines and stalled the main loop on stderr I/O. Added a
`mainFrame.detached` guard so the send is short-circuited before
Electron's own catch block fires, and installed a targeted filter in
`suppress-warnings.ts` (now actually imported from the entry point)
so the specific `console.error("Error sending from webFrameMain:"…)`
noise never reaches the terminal. Any other payload still surfaces.
* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
target when an agent replied to `__board__` — `wakeAgentIfPossible`
then called `db.getAgent("__board__")`, threw, and the dispatcher
kept repeating on every send. Strip `HUMAN_SENDER_ID` at
`resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
heartbeat so a stray caller (future automation fan-out) cannot
reintroduce the crash.
* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
diverges from its parent directory. The four bundled `my-writing-style`
copies declared `name: writing-style-skill`, so every install emitted
a warning and dropped the skill. They also lived as orphan gitlinks
(mode 160000 without .gitmodules), and the global `*.md` gitignore
hid every other SKILL.md from version control. Fixed the frontmatter
to match the dir, converted the dangling submodules to plain trees,
and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
catalogue instead of silently losing it.
2.2 KiB
2.2 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Follow the Four Rules of Simple Design | HIGH | prevents over-engineering while maintaining quality | emerge, simple-design, kent-beck, refactoring |
Follow the Four Rules of Simple Design
Kent Beck's four rules of Simple Design, in order of priority:
- Passes all tests — correctness is non-negotiable
- Reveals intent — code is clear and expressive
- No duplication — every concept has a single representation
- Fewest elements — remove anything that doesn't serve the first three
Incorrect (over-engineered for imaginary requirements):
// Single implementation with unnecessary abstraction layers
public interface PaymentProcessor {}
public interface PaymentProcessorFactory {}
public abstract class AbstractPaymentProcessor implements PaymentProcessor {}
public class PaymentProcessorFactoryImpl implements PaymentProcessorFactory {
public PaymentProcessor create() {
return new DefaultPaymentProcessor();
}
}
public class DefaultPaymentProcessor extends AbstractPaymentProcessor {
public void process(Payment payment) {
gateway.charge(payment.getAmount());
}
}
Correct (simplest design that works):
public class PaymentProcessor {
private final PaymentGateway gateway;
public PaymentProcessor(PaymentGateway gateway) {
this.gateway = gateway;
}
public void process(Payment payment) {
gateway.charge(payment.getAmount());
}
}
Rule 4 is the most overlooked: After making code correct, expressive, and DRY, actively look for things to remove. Every class, method, and variable should justify its existence. If you have one implementation of an interface, question whether you need the interface. If a design pattern adds indirection without a current concrete benefit, remove it.
When more structure is justified:
- When you have 2+ implementations today (not hypothetically)
- When a framework requires it (e.g., dependency injection interfaces)
- When tests need seams for mocking external dependencies
Reference: Clean Code, Chapter 12: Emergence