Skip to content

refactor(daemon): resolve device interactors through a composed capability - #2593

Merged
thymikee merged 3 commits into
mainfrom
t3code/implement-issue-2555
Sep 14, 2026
Merged

thymikee merged 3 commits into
mainfrom
t3code/implement-issue-2555

Conversation

@thymikee

@thymikee thymikee commented Sep 14, 2026

Copy link
Copy Markdown
Member

Summary

src/daemon/snapshot-interactor-capture.ts reached interactor mechanics through await import('../core/interactors.ts') — the one production edge leaving the daemon zone dynamically, invisible to the ranked spine and recorded as leaked-platform-mechanics by R76.

Interactor resolution now arrives as a capability. src/daemon/interactor-resolution.ts holds the daemon seam, and startDaemonRuntime installs it beside installProviderDeviceAdmission, so one composition site names both request-scoped capabilities (ADR 0019 §1/2). An un-composed process fails closed with reason: interactor-resolution-missing instead of reaching for a lookup of its own.

R76 swaps the dynamic leaked edge for the composition edge, so no classified leaked-mechanics edge is reached dynamically, and src/core/interactors.ts keeps exactly one inbound daemon-zone edge — from composition. 10 files, +208/−38.

Closes #2555

Validation

Head 771de8f510: pnpm check:affected --run is green except mutation-model, which fails identically at base 730b20149e (pnpm mutation:test: 39 pass / 1 fail on both) — pre-existing, unrelated to this diff.

Also green locally: full unit-core (10,024 tests), pnpm test:integration:provider (210 tests), pnpm check:tooling (format, lint, typecheck, layering, di-seams, build, package), pnpm check:fallow.

The fail-closed default earned its keep: interaction-settle-private-ax-route.test.ts and the provider-scenario harness.ts had to compose the capability the way the process root does, exactly as they already do for the provider-device admission. src/daemon/server/daemon-runtime-interactor-composition.test.ts boots the real runtime and resolves through the seam, so the root install line is covered: deleting it fails that test with interactor-resolution-missing. No device-facing behavior changed, so no device run is claimed.

…ility

The legacy snapshot capture reached interactor mechanics through a dynamic
import of the shared lookup, the one production edge leaving the daemon zone
dynamically. Interactor resolution now arrives as a capability installed at the
same composition site as the provider-device admission, and an un-composed
process fails closed on a typed reason.
The dynamic leaked-platform-mechanics edge is gone, so the table records the
composition edge that replaced it and the dynamic-form tests assert against the
classified pair instead.
@github-actions

github-actions Bot commented Sep 14, 2026

Copy link
Copy Markdown

Size Report

Metric Base Current Diff
Installed (including dependencies) 4.53 MB 4.53 MB +173 B
Package (unpacked) 4.53 MB 4.53 MB +173 B
Package (download) 1.34 MB 1.34 MB +54 B

Startup median (7 runs, lower is better):

Scenario Base Current Diff
CLI --version 27.9 ms 28.5 ms +0.5 ms
CLI --help 77.1 ms 77.8 ms +0.7 ms

@thymikee

Copy link
Copy Markdown
Member Author

Looks good at fdcb981. startDaemonRuntime installs the interactor resolution before it builds the request handler, and it is the only production entry that builds one, so the fail-closed default cannot trip in a real daemon. The R76 change removes the dynamic edge instead of relabeling it.

One small gap, not a blocker: the harness installs its own copy, so no test fails if the install in daemon-runtime.ts is removed. Smoke Tests is the only check that covers that line today. A short test that startDaemonRuntime installs it would close that gap.

@thymikee thymikee added the ready-for-human Valid work that needs human implementation, judgment, or maintainer merge label Sep 14, 2026
Every harness that builds its own request handler installs the seam itself, so
the install at the process root had no unit coverage. Boot the real runtime and
resolve a provider-owned device through the daemon's seam.
@thymikee

Copy link
Copy Markdown
Member Author

Good catch — added src/daemon/server/daemon-runtime-interactor-composition.test.ts (771de8f): it boots the real startDaemonRuntime with the usual runtime/provider mocks, then resolves a provider-owned device through interactorResolution() and asserts the provider interactor comes back. Verified it kills the mutant: removing the install line from daemon-runtime.ts fails it with reason: interactor-resolution-missing. check:affected --run re-run at that head is green up to the pre-existing mutation-model failure (identical at base).

@thymikee

Copy link
Copy Markdown
Member Author

Still good at 771de8f. The new test boots the real startDaemonRuntime and resolves through interactorResolution(), and the un-composed default throws interactor-resolution-missing, so the test fails if the install in daemon-runtime.ts is removed. That closes the gap from my last comment. Checks are green and there are no conflicts.

@thymikee
thymikee merged commit 0326ad6 into main Sep 14, 2026
18 checks passed
@thymikee
thymikee deleted the t3code/implement-issue-2555 branch September 14, 2026 15:37
@github-actions

Copy link
Copy Markdown
PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-14 15:38 UTC

thymikee added a commit that referenced this pull request Sep 14, 2026
…tle-on-exit-2522

* origin/main:
  perf(scroll-until): answer every candidate from one visibility index (#2596)
  refactor(daemon): resolve device interactors through a composed capability (#2593)
  refactor(daemon): stop the client value-importing daemon internals (#2559) (#2594)
  refactor(shell-quote): one implementation, reached through the runner host port (#2595)
  docs(agents): delete the file-size tiers nobody enforces (#2597)
  fix(daemon): key the implicit session by workspace and platform (#2587)
  refactor(cli-schema): orient the schema layer above commands (#2543 step 3) (#2590)
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.

Resolve device interactors behind a composed capability

1 participant