Files
AgentCompany/builtin-skills/software-engineer/clean-architecture/references/comp-stable-dependencies.md
T
ZacharyZhang-NY e74dafcd36 Silence render-disposed spam, unbreak bundled skills, drop board wake
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.
2026-04-20 08:13:48 -04:00

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