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.
3.5 KiB
3.5 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Depend in the Direction of Stability | HIGH | prevents unstable components from destabilizing dependents | comp, stability, dependencies, direction |
Depend in the Direction of Stability
Components should depend on components that are more stable than themselves. A stable component (many dependents, few dependencies) should not depend on an unstable component (few dependents, many dependencies).
Incorrect (stable component depends on unstable):
┌─────────────────────────────────────────────────────┐
│ core-domain │
│ (Used by 50 services, should be very stable) │
│ │
│ import { formatDate } from 'ui-helpers' // WRONG! │
│ import { sendMetrics } from 'analytics' // WRONG! │
└──────────────────────┬──────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
ui-helpers analytics reporting
(Changes (Changes (Changes
weekly) monthly) often)
# When ui-helpers changes, core-domain might break
# When core-domain breaks, all 50 services break
Correct (depend toward stability):
┌─────────────────────────────────────────────────────┐
│ core-domain │
│ (Used by 50 services, zero external dependencies) │
│ │
│ - Only depends on language primitives │
│ - Defines interfaces, not implementations │
└─────────────────────────────────────────────────────┘
▲
│
┌───────────────┼───────────────┐
│ │ │
ui-helpers analytics reporting
│ │ │
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────┐
│ external-dependencies │
│ (date-fns, axios, lodash - maintained externally) │
└─────────────────────────────────────────────────────┘
# Unstable components depend on stable core
# Core never breaks due to UI changes
Stability Metric:
Instability = Outgoing Dependencies / (Incoming + Outgoing)
- I = 0: Maximally stable (many dependents, no dependencies)
- I = 1: Maximally unstable (no dependents, many dependencies)
Dependencies should flow from high I to low I.
Reference: Clean Architecture - Stable Dependencies Principle