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.8 KiB
Sections
This file defines all sections, their ordering, impact levels, and descriptions. The section ID (in parentheses) is the filename prefix used to group rules.
1. Dependency Direction (dep)
Impact: CRITICAL Description: The Dependency Rule is the architectural foundation. Source code dependencies must point inward only; violations cascade failures across all layers.
2. Entity Design (entity)
Impact: CRITICAL Description: Enterprise business rules must be framework-agnostic, stable, and completely independent of databases, UI, and external systems.
3. Use Case Isolation (usecase)
Impact: HIGH Description: Application-specific business rules orchestrate entities without leaking infrastructure details or depending on presentation concerns.
4. Component Cohesion (comp)
Impact: HIGH Description: Components grouped by business capability enable independent deployment, parallel team development, and controlled change propagation.
5. Boundary Definition (bound)
Impact: MEDIUM-HIGH Description: Architectural boundaries isolate volatile from stable elements; Humble Objects maximize testability by separating hard-to-test from easy-to-test code.
6. Interface Adapters (adapt)
Impact: MEDIUM Description: Controllers, presenters, and gateways translate between use cases and external systems without leaking implementation details.
7. Framework Isolation (frame)
Impact: MEDIUM Description: Frameworks are details, not architecture. Business logic must never import, reference, or depend on framework-specific types.
8. Testing Architecture (test)
Impact: LOW-MEDIUM Description: Tests are architectural components. Layer isolation enables fast unit tests, while boundaries enable targeted integration tests.