DevBerth v0.1.7

What changed

#29 — fix: bind DevBerth control hosts to exact app identity

Summary

DevBerth bundles can share the same product name and com.ysbc.devberth identity across installed Release, Debug, development-control, UI-test, DerivedData, and temporary hosts. This release removes shared identity metadata as a host selector.

• production MCP activation validates and opens exactly /Applications/DevBerth.app
• development activation requires explicit DEVBERTH_APP_PATH and a Debug-only bundle marker
• Release bundles with the same bundle identifier are rejected as development hosts
• exact bundle/executable/PID, build mode, socket/store context, and provenance are now durable AGENTS and documentation requirements
• cleanup by process name or bundle identifier is forbidden

Incorporated review shards

• #26 — exact production/development application resolution
• #27 — six identity-selection regression tests
• #28 — AGENTS, development setup, provenance, and cleanup rules

Impact

This prevents the MCP bridge and future capture/validation work from silently alternating between an installed production app and an isolated Debug/fixture host that presents the same identity. Ambiguous evidence now fails closed and must be recaptured.

Validation

• focused identity suite: 6 passed
• non-UI suite: 209 passed, 0 failed, 0 skipped
• UI suite isolated retry: 7 passed, 0 failed, 0 skipped
• initial combined suite: 209 tests passed; UI runner failed to initialize because macOS timed out enabling automation mode
• Debug bundle marker: YES
• installed Release bundle marker: NO
• Scripts/build-and-install-app installed matching DevBerth 0.1.0 (1) and devberth-mcp 0.1.0 artifacts

Release provenance

• Merge commit: bcf97468a140b240ad4be9f383cae3d4412587fa
• Pull request: #29
• Compare v0.1.6...v0.1.7

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