DevBerth v0.1.11

What changed

#35 — Fix managed launch fingerprint stabilization

What changed

• retain a strong post-spawn fingerprint candidate across intermittent incomplete ps/lsof observations
• continue resetting the candidate whenever a conflicting strong fingerprint is observed
• add regression coverage for alternating strong and incomplete samples
• document the control-authority rule in repository guidance and architecture notes

Why

The npm-managed analytics dashboard failed twice during project startup because an incomplete fingerprint inspection was treated as evidence that the process identity had changed. That reset the bounded stabilization window even though later strong observations were mutually identical.

Impact

Script launchers can complete registration despite intermittent incomplete process-path samples, while PID-reuse and executable-replacement protection remains intact. DevBerth still requires nine mutually identical strong observations and refuses any conflicting strong fingerprint.

Validation

• ProcessGroupTests: 10/10 passed
• fresh DerivedData full scheme: 219/219 passed; 0 failures, skips, or expected failures
• Scripts/build-and-install-app: installed matching Release app and MCP helper successfully
• note: shared DerivedData initially produced unrelated stale-host failures; both affected tests passed from clean DerivedData, and the final full clean run passed

Release provenance

• Merge commit: e11d6329f4147e9de9193d3a664944283ef4c1f3
• Pull request: #35
• Compare v0.1.10...v0.1.11

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

DevBerth v0.1.10

What changed

#34 — Fix Projects scrolling performance

What changed

• Build value-type project and managed-service presentation snapshots once per Projects view update instead of rebuilding configurations as lazy List sections enter the viewport.
• Precompute activity, runtime, dependency, port, Docker, failure, and operation presentation data before scrolling.
• Consolidate secondary project controls into one Project Actions menu while preserving discovery, manifest export, service assignment, Finder, Terminal, and repository actions.

Why

Projects scrolling repeatedly filtered every SwiftData query, decoded each managed-service configuration, scanned runtime listeners, and constructed two AppKit popup hierarchies per project as rows entered the viewport. On the current production dataset, a matched 15-second Instruments trace recorded 16 microhangs from 255–437 ms and one 2.05-second severe main-thread hang.

Impact

Projects scrolling no longer reconstructs domain configurations or project sections on viewport entry. The matched after trace recorded zero hangs, and four 8-page down/up passes completed in 3.7 seconds instead of 28.5 seconds.

Validation

• Release build installed to /Applications/DevBerth.app with the matching MCP helper.
• Production-data UI inspected with the installed app; service states, ports, topology, and actions remained available.
• Instruments Time Profiler before/after traces captured against the exact installed production executable and dataset.
• Full macOS test suite: 218 passed, 0 failed, 0 skipped, 0 expected failures.

Release provenance

• Merge commit: f4409adc240a9c96c33c23fa4cb63b5341811067
• Pull request: #34
• Compare v0.1.9...v0.1.10

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

DevBerth v0.1.9

What changed

#33 — Fix parallel project startup pipe isolation

Release unit

This roll-up integrates the complete parallel-start fix as one main update and one source release.

Incorporated review shards

• #32 — implementation and regression coverage for command-capture and managed-log descriptor isolation
• #33 — durable engineering rules, architecture rationale, implementation evidence, and composed validation

What changed

• mark trusted-command capture pipes close-on-exec before subprocess launch
• mark managed-service log pipes close-on-exec before concurrent managed-service launch
• assert descriptor isolation and retained command-output capture in ProcessGroupTests
• document close-on-exec as a required process boundary in AGENTS.md, architecture, and implementation state

Why

A long-running service launched in parallel could inherit a sibling fingerprint probe’s pipe writer. The probe then waited indefinitely for EOF, leaving project startup at a non-terminal count even though the affected listener was active.

Impact

Dependency-layer siblings now inherit only their intended standard streams. Project startup can reach its normal readiness success or failure boundary instead of hanging inside process fingerprint capture. Lifecycle authority, restart trust, and readiness requirements are unchanged.

Observed validation

• focused ProcessGroupTests: 9 passed, 0 failed
• full warnings-as-errors macOS scheme: 218 passed, 0 failed, 0 skipped, 0 expected failures in about 180 seconds
• both shard CI runs passed before roll-up
• Release build installed at /Applications/DevBerth.app; strict signature verification passed
• exact installed UI showed Pharmacy Project at 3 of 3 active with no in-flight startup overlay; existing runtimes remained honestly observed after app restart

Source release

The repository release workflow will publish exactly one immutable source tag for this roll-up merge. This does not claim a signed, notarized, or auto-updating distributable.

Release provenance

• Merge commit: 8a414b4f4d11abf1919b86e1fcfbfa69d035cb3e
• Pull request: #33
• Compare v0.1.8...v0.1.9

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

DevBerth v0.1.8

What changed

#30 — docs: add Claude Code handoff instructions

Summary

• Add a repository-level CLAUDE.md.
• Direct Claude Code to repository rules and the canonical saved handoff.
• Preserve unrelated Git and runtime state when resuming work.

Why

This makes Codex handoffs resumable from Claude Code with the same startup procedure across the related repositories.

Validation

• Verified all eight CLAUDE.md files have the same SHA-256 hash.
• Ran git diff --check.
• Staged and committed only CLAUDE.md.

Release provenance

• Merge commit: 39ea499f49a3f55a6df77987ab5197d86c8087d5
• Pull request: #30
• Compare v0.1.7...v0.1.8

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

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.

DevBerth v0.1.6

What changed

#25 — Optimize DevBerth CPU usage and responsiveness

Release summary

DevBerth now uses one adaptive, coalescing runtime monitor instead of fixed independent high-frequency loops. Semantic evidence, real AppKit foreground surfaces, bounded native process identity caching, and decoupled Docker/resource/health/log schedules eliminate timestamp-only UI invalidation and persistence churn while preserving immediate refresh after known mutations and wake.

Incorporated review shards

• #19 — measured instrumentation and untouched CPU baseline
• #20 — adaptive semantic monitoring and full-identity cache
• #21 — bounded Docker, resource, health, log, and persistence work
• #22 — secret-free internal Performance Diagnostics UI
• #23 — performance regressions, benchmarks, isolation, and soak harnesses
• #24 — macOS surface/UDP cadence fixes, activation publication, navigation refinement, final profiling, documentation, and saved handoff

Why

The untouched Release app used 69.2% average CPU with its windows closed. Time Profiler attributed 19.558 of 24.4 sampled CPU-seconds to retained SwiftUI graph invalidation, while timestamp-only listener updates continuously wrote and pruned SwiftData. Monitoring also launched at least 126 command children per minute before metadata work.

User and developer impact

• closed-window CPU: 69.2% → 0.118% over matched 901-second samples (99.83% lower)
• idle Time Profiler CPU: 24.4 → 0.027 CPU-seconds; main thread 19.558 → 0.001
• main-window CPU: 49.5% → 2.62%; menu popover 0.10%
• direct monitoring children: about 97% lower
• deterministic unchanged snapshots: zero UI listener publications and zero lifecycle writes
• bounded diagnostics and repeatable Release soak tooling are now available

Polling remains necessary on the macOS 14 baseline. Hidden stable evidence can be up to 30 seconds old; foreground navigation retains two measured 279–320 ms microhitches; and the pre-fix persistent-history backlog is preserved rather than destructively compacted.

Validation

• exact local macOS test action: 210/210 passed, zero failures/skips/expected failures
• two repeated performance/soak iterations passed
• isolated 300-second Release soak: 0.11 CPU-seconds after warm-up over 293 seconds, steady RSS 132,992–165,568 KiB, bounded threads, zero children, zero error lines
• PR CI green on every incorporated shard
• /Applications/DevBerth.app and the installed devberth-mcp helper rebuilt from the same Release 0.1.0 (1) build

This is one source-release unit. It does not claim a signed, notarized, installable distribution artifact or automatic updater.

Release provenance

• Merge commit: 5b15efeaf128632821f60c01ff52959830f8566d
• Pull request: #25
• Compare v0.1.5...v0.1.6

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

DevBerth v0.1.5

What changed

#18 — docs: make stacked merges and save handoffs composable

What changed

• Makes one user-requested stacked merge one release unit: a single roll-up PR, one main update, and one version, while lower shard PRs close as incorporated after the release succeeds.
• Treats save as an actionable, case-insensitive command when used alone, with context, or in combined requests such as save and merge.
• Keeps discussion, quotations, and rule definitions non-operative unless the user also directs the agent to perform a save.
• Requires combined commands to follow the user's requested order while keeping every named mutation separately authorized.
• Records both decisions in durable implementation documentation and updates the documentation index.
• Executes the broadened save protocol and records byte-identical canonical and archived pre-merge handoffs.

Why

The prior workflow could produce several releases for one requested stack merge, and the previous exact-message save grammar rejected clear operational requests. These rules make both actions match the user's intended unit of work.

Impact

Users can naturally combine the handoff with commit, push, merge, or other explicit actions without weakening the boundary against accidental invocation. A stacked task now publishes one auditable source version instead of one version per implementation shard.

Incorporated PRs

• #17 — docs: make stacked merges publish one version
• #18 — docs: make stacked merges and save handoffs composable (roll-up)

Validation

• git diff --check passed.
• Verified operative and non-operative examples agree between AGENTS.md and the durable workflow decision record.
• cmp confirmed docs/next-steps/README.md and its timestamped archive are identical.
• The save snapshot was collected through the production DevBerth MCP and records Git, validation, runtime, services, ports, databases, and credential sources without secret values.
• PR #17 CI passed (Build and test, 5m46s).
• PR #18 CI passed (Build and test, 7m49s), including the application build, isolated UI-test target compilation, and unit/safe-integration suite.

Release provenance

• Merge commit: 8cc670eabeabe8559383d6f0f6a1918485102f45
• Pull request: #18
• Compare v0.1.4...v0.1.5

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

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.

DevBerth v0.1.3

What changed

#15 — test: cover every verified service stop route

What changed

• Verifies an unverified Compose service routes stop/restart to its exact container ID and never to a host PID.
• Covers case-only Compose path spelling and true symlink-component rejection.
• Covers revalidated managed-process force escalation after a graceful timeout.
• Covers observed-process force escalation and project Stop All continuation after one target fails.

Why

The control changes span multiple ownership routes. These tests prevent a future safety regression from either blocking a valid exact target or signaling a broader owner such as Docker Desktop.

Impact

No production behavior is added by this PR; it makes the implementation in the parent branch reviewable and regression-safe.

Validation

• Focused xcodebuild test for OwnershipTests, LifecycleRouterTests, DockerTests, ProcessGroupTests, and RuntimePresentationTests passed: 46 tests, zero failures.
• The ignored-SIGTERM integration fixture passed with verified force-stop escalation.
• The complete final stack passed all 187 tests with zero failures or skips.
• GitHub CI passed on a clean retry; the first attempt had one transient miss in the unchanged high-port listener-discovery integration fixture while every stop-control test passed.

Release provenance

• Merge commit: 8d99eb9c3aff9284aed1cfa1f4e987f8f65787bc
• Pull request: #15
• Compare v0.1.2...v0.1.3

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

DevBerth v0.1.2

What changed

#14 — fix: make verified service stops actionable

What changed

• Routes inferred Homebrew, user launchd-parented, and supervisor-owned listeners through exact fingerprint-and-listener revalidated process control instead of blocking on unverified service-manager metadata.
• Falls back from an unverified Docker Compose scope to the exact Docker Engine container ID, never the shared Docker Desktop host process.
• Accepts case-only path spelling differences on case-insensitive macOS volumes while continuing to reject real symlink components in Compose mutation contexts.
• Escalates DevBerth-managed process groups from graceful stop to a second ownership validation and force stop when the configured timeout expires.
• Makes project Stop All attempt every active service and report exact per-service failures instead of aborting at the first failure.

Why

Observed Cloud project services were marked active but could not be stopped because parent PID 1 and Homebrew-path heuristics were treated as controller authority, while a case-only GitHub/github path difference incorrectly invalidated an otherwise exact Compose context.

Impact

Users can stop each strong, same-user service independently and can stop whole projects without one failed target blocking the rest. Protected system/root processes, weak or changed fingerprints, stale listener ownership, and real symlinked Compose contexts remain blocked.

Validation

• Focused xcodebuild test for the implementation branch's ownership, Docker, and managed-process-group suites passed after aligning their existing expectations.
• The complete final stack passed all 187 tests with zero failures or skips.
• Scripts/build-and-install-app refreshed /Applications/DevBerth.app and the stable MCP helper from the same Release build.

Release provenance

• Merge commit: 772b5ab31f58325fdc9349078c1b17168a67926f
• Pull request: #14
• Compare v0.1.1...v0.1.2

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