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.
1.5 KiB
1.5 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Separate Commands from Queries | MEDIUM | eliminates ambiguous function behavior | func, cqs, command, query, separation |
Separate Commands from Queries
Functions should either do something or answer something, but not both. Either your function changes the state of an object, or it returns information about that object.
Incorrect (command and query mixed):
// Does this set the attribute and return success?
// Or check if attribute exists?
public boolean set(String attribute, String value) {
// ... sets attribute and returns true if it was set
}
// Confusing usage
if (set("username", "bob")) {
// Was username set, or did it already exist?
}
Correct (separated command and query):
// Query - returns information
public boolean attributeExists(String attribute) {
return attributes.containsKey(attribute);
}
// Command - changes state
public void setAttribute(String attribute, String value) {
attributes.put(attribute, value);
}
// Clear usage
if (!attributeExists("username")) {
setAttribute("username", "bob");
}
Alternative (return new state for immutable design):
// For immutable patterns, returning new state is acceptable
public Settings withAttribute(String attribute, String value) {
return new Settings(this.attributes.plus(attribute, value));
}
The separation makes code easier to read and reason about.
Reference: Clean Code, Chapter 3: Functions