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.8 KiB
2.8 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Encapsulate Business Invariants Within Entities | CRITICAL | prevents invalid state, centralizes validation | entity, invariants, validation, encapsulation |
Encapsulate Business Invariants Within Entities
Business rules that must always be true (invariants) should be enforced by the entity itself. External code should not be able to put an entity into an invalid state.
Incorrect (invariants scattered outside entity):
# application/usecases/transfer_money.py
class TransferMoneyUseCase:
def execute(self, from_id, to_id, amount):
from_account = self.repo.find(from_id)
to_account = self.repo.find(to_id)
# Validation scattered in use case
if from_account.balance < amount:
raise InsufficientFundsError()
if amount <= 0:
raise InvalidAmountError()
if from_account.status != 'active':
raise AccountInactiveError()
from_account.balance -= amount # Direct field mutation
to_account.balance += amount
# Another use case might forget these checks!
Correct (invariants enforced by entity):
# domain/entities/account.py
class Account:
def __init__(self, id: AccountId, balance: Money, status: AccountStatus):
self._id = id
self._balance = balance
self._status = status
def withdraw(self, amount: Money) -> None:
self._ensure_active()
self._ensure_positive_amount(amount)
self._ensure_sufficient_funds(amount)
self._balance = self._balance.subtract(amount)
def deposit(self, amount: Money) -> None:
self._ensure_active()
self._ensure_positive_amount(amount)
self._balance = self._balance.add(amount)
def _ensure_active(self) -> None:
if self._status != AccountStatus.ACTIVE:
raise AccountInactiveError(self._id)
def _ensure_positive_amount(self, amount: Money) -> None:
if amount.is_zero_or_negative():
raise InvalidAmountError(amount)
def _ensure_sufficient_funds(self, amount: Money) -> None:
if self._balance.less_than(amount):
raise InsufficientFundsError(self._id, self._balance, amount)
# application/usecases/transfer_money.py
class TransferMoneyUseCase:
def execute(self, from_id, to_id, amount):
from_account = self.repo.find(from_id)
to_account = self.repo.find(to_id)
from_account.withdraw(amount) # Invariants guaranteed
to_account.deposit(amount)
Benefits:
- Impossible to create invalid account state
- Validation rules documented in one place
- Every use case gets consistent validation automatically
Reference: Domain-Driven Design - Aggregates