Skip to content

refactor: extract durable capture resource lifecycle - #1720

Draft
thymikee wants to merge 1 commit into
mainfrom
agent/platform-runtime-recording
Draft

refactor: extract durable capture resource lifecycle#1720
thymikee wants to merge 1 commit into
mainfrom
agent/platform-runtime-recording

Conversation

@thymikee

@thymikee thymikee commented Aug 10, 2026

Copy link
Copy Markdown
Member

Summary

Extract the reusable daemon lifecycle substrate for durable captures and migrate app-log onto it without changing CLI or platform behavior.

The coordinator now owns manifest I/O, fenced transitions, start/adoption compensation, exact-owner recovery, and process-lifetime admission uncertainty. App-log keeps its specialized marker policy and runtime binding adapter. ADR 0019 records this bounded seam before the stacked screen-recording cutover.

Stack/tracking: #1117 (screen-recording cutover), #1704 (budget/distribution decision), and the ADR 0019 checkpoint sequence completed by #1703.

Validation

pnpm check:affected --run passed with host networking: all seven selected checks and 710/710 related tests. The staged structural scan also passed 131 policy tests and the full 1,165-file layering guard.

Exact-head live app-log lifecycle/recovery evidence and planted-red evidence are being gathered in response to the current review; this draft remains not ready until those are posted.

@github-actions

Copy link
Copy Markdown

Size Report

Metric Base Current Diff
JS raw 2.13 MB 2.13 MB +2.2 kB
JS gzip 695.2 kB 695.9 kB +694 B
npm tarball 826.8 kB 827.4 kB +630 B
npm unpacked 2.88 MB 2.88 MB +2.2 kB

Startup median (7 runs, lower is better):

Scenario Base Current Diff
CLI --version 32.3 ms 31.6 ms -0.7 ms
CLI --help 79.3 ms 75.2 ms -4.1 ms

Top changed chunks:

Chunk Raw diff Gzip diff
dist/src/internal/daemon.js +3.1 kB +1.0 kB
dist/src/session.js -856 B -326 B
dist/src/selector-runtime.js 0 B +1 B

@thymikee

Copy link
Copy Markdown
Member Author

Exact-head review at e3b0956be: not ready, though I found no confirmed source defect in the extraction. The production app-log start/adopt/finish, teardown, and daemon-lock exact-owner recovery routes appear mechanically preserved, and the small size delta is non-blocking.

Two validation gates remain open:

  1. No red-before/planted-red evidence is recorded. The new generic fixture suites did not exist on the parent, and the stated structural scan has no documented planted violation. Show a representative load-bearing mutation—such as bypassing the app-log delegation or breaking exact-owner terminalization—that makes the unchanged production app-log lifecycle/recovery suite fail, plus planted proof for the claimed structural invariant.
  2. No exact-head live changed-route evidence exists. Android and iOS CI use smoke tiers, while their logs scenarios live in the full observability suites; iOS is also still pending. Provide exact-head Android emulator and iOS simulator logs start/path-or-doctor/mark/relaunch/stop/close evidence, plus guarded daemon restart/dead-owned-process recovery followed by a successful replacement start. Record HarmonyOS/HDC unavailability as residual risk if that route cannot be exercised.

Finally, the PR declares no linked issue or stack dependency despite being the substrate for the recording cutover. Link the ADR 0019 tracker/checkpoint and the stacked recording/#1117 unit so the intended sequence and acceptance behavior are reviewable. No ready label applied.

@thymikee

Copy link
Copy Markdown
Member Author

Exact-head follow-up for e3b0956be058d0b03498c61b6179dba73c60aa04.

Non-vacuous regression evidence

I planted a representative delegation bypass in adoptStartedSessionAppLog (return Promise.resolve() instead of appLogDurableResource.adoptStarted(params)) and ran the unchanged production lifecycle/recovery tests:

pnpm exec vitest run --project unit-core \
  src/daemon/__tests__/app-log-session-resource.test.ts \
  src/daemon/__tests__/app-log-resource-recovery.test.ts

Red: 9/18 failed. The failures covered missing live-handle adoption, cancellation compensation, cleanup-pending evidence, envelope identity validation, tombstones, and same-process admission blocking. Restoring the delegation returned the same suite to 18/18 green.

The existing structural guard was also re-proven through its planted cases: node --test scripts/layering/logs-runtime-cutover-policy.test.ts passed 9/9, including executable legacy routes, capability/dual-admission routes, narrowing proof repair, off-owner app-log state construction, and forbidden resource syntax.

Exact-head live route evidence

Freshness: pinned pnpm install, pnpm build, pnpm build:android, and pnpm clean:daemon in an isolated detached worktree. Built CLI ran under the repo's Node 24.13.0. Final git status was clean and detached at the exact SHA above.

Android emulator emulator-5554, Settings com.android.settings

  • named session pr1720-android-logs: open → logs doctor (backend: android, adb/PID checks true) → start → marker → app relaunch → marker → stop → close;
  • app.log retained pr1720-android-before-relaunch at line 223 and pr1720-android-after-relaunch at line 433;
  • manifest terminalized with lifecycle: completed, local Android owner, generation 1; app-log.pid was absent after stop.

iOS simulator 6044A251-23C2-4584-B7DB-87A16B787757, Settings com.apple.Preferences

  • named session pr1720-ios-logs: open → logs doctor (backend: ios-simulator, simctl check true) → start → marker → app relaunch → marker → stop → close;
  • app.log retained the before/after markers at lines 14/781 and real post-relaunch Preferences lifecycle output;
  • manifest terminalized with lifecycle: completed, local Apple owner, generation 1; app-log.pid was absent after stop.

Guarded dead-owner recovery

  • separate session pr1720-android-recovery started an Android log stream and published all three artifacts;
  • before signals, daemon PID 7811 matched the isolated built daemon path and exact recorded start time; marker PID 67467 matched adb -s emulator-5554 logcat -v time --pid 19774 and its exact recorded start time;
  • SIGKILL was sent only after those checks, daemon first and child second; both disappeared while marker/manifest remained;
  • replacement daemon startup reported the old daemon unreachable, removed the marker, and changed the open manifest to lifecycle: completed with recoveryStatus: already-missing;
  • reopening the same target/session then completed a second logs start → marker → stop → close. The marker pr1720-android-after-recovery was present, the final manifest was completed at generation 2, and the PID marker was absent.

All three named sessions were closed and the isolated daemon was stopped. HarmonyOS/HDC remains the explicit residual live-evidence gap because no provisioned Harmony target is available; its deterministic package/runtime tests remain the evidence for that route.

@thymikee

Copy link
Copy Markdown
Member Author

Exact-head follow-up at e3b0956be: code-review ready. The prior blockers are closed.

  • The production app-log delegation is proven load-bearing: bypassing it made 9/18 unchanged lifecycle/recovery tests fail, and the restored head passes 18/18; the structural policy's planted cases also pass 9/9.
  • Exact-head Android emulator and iOS simulator evidence covers open → doctor → start → mark → relaunch → mark → stop → close, including persisted output, terminal manifests, and PID-marker cleanup. Android additionally proves guarded daemon/owned-child loss, startup recovery to already-missing, and a successful generation-2 replacement start/stop/close.
  • The PR now links the ADR checkpoint/budget and recording cutover dependencies. HarmonyOS/HDC unavailability is explicitly retained as residual risk with deterministic package/runtime coverage.

No source defect found, the size delta is small, all checks are green, and the PR is CLEAN/MERGEABLE.

@thymikee thymikee added the ready-for-human Valid work that needs human implementation, judgment, or maintainer merge label Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-human Valid work that needs human implementation, judgment, or maintainer merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant