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.
70 lines
3.5 KiB
Markdown
70 lines
3.5 KiB
Markdown
---
|
|
title: Depend in the Direction of Stability
|
|
impact: HIGH
|
|
impactDescription: prevents unstable components from destabilizing dependents
|
|
tags: 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):**
|
|
|
|
```text
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ 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):**
|
|
|
|
```text
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ 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:**
|
|
```text
|
|
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](https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/ch14.xhtml)
|