DevBerth v0.1.4

What changed

#16 — docs: define exact universal stop boundaries

What changed

• Defines the exact-stop boundary for DevBerth-managed groups, strong same-user observed processes, Docker containers, and verified Compose services.
• Documents why parent PID 1, a Homebrew executable prefix, or supervisor resemblance is classification evidence rather than controller authority.
• Records project Stop All's continue-and-aggregate behavior and the explicit refusal boundary for root, protected, weak, stale, or changed targets.
• Updates MCP, Docker, ownership, security, architecture, differentiation, and implementation references to match the shipped control plane.

Why

Users and future contributors need one consistent explanation of which target DevBerth will stop, how it can force an unresponsive exact target, and why it never turns "administrator control" into an unsafe broad kill.

Impact

The repository rules and product documentation now agree with the implementation. The MCP remains the preferred control surface, and any missing or awkward control capability must be improved at the shared control-plane boundary.

Validation

• The complete final stack passed all 187 tests with zero failures or skips.
• Scripts/build-and-install-app installed DevBerth 0.1.0 (1) at /Applications/DevBerth.app and refreshed ~/Library/Application Support/DevBerth/bin/devberth-mcp.
• Production MCP read-only QA identified the Cloud gateway as a guarded exact-instance stop target.
• Production MCP Docker inspection reported contexts_verified: true for the Cloud backend despite its case-varying path spelling.
• The Full Disk Access System Settings pane was opened during the install handoff; macOS retains control of the permission grant.

Release provenance

• Merge commit: 0f82c82a70d8d056dc0e82e32456b80c93e84d0c
• Pull request: #16
• Compare v0.1.3...v0.1.4

This is a source-project release. It does not include a signed or notarized app binary.