test(layering): classify daemon edges that reach platform mechanics through a hub - #2557
Merged
thymikee merged 1 commit intoSep 13, 2026
Conversation
…hrough a hub R76 keyed its inventory on the target filename, so a daemon import of a root module that imports the platform-runtime family itself was invisible: the daemon could gain or widen an edge to a root hub without any gate noticing. Dynamic edges were invisible in the same way, and the ranked spine (R4, R5, R6) cannot see a dynamic import's direction at all. The target predicate is now computed from the tree: the platform-runtime family plus every module outside the daemon zone that reaches it, over static and dynamic edges alike. That made exactly three real edges visible, and all three are classified rather than allowlisted: the two provider-runtime hubs the daemon runtime composes, and the dynamic interactor lookup in the snapshot capture, which is a leak and now carries the rationale and the deepening issue (#2555) that a filename pattern never would have asked for. Part of #2542
thymikee
added this pull request to stack #2558
September 13, 2026 12:29
This was referenced Sep 13, 2026
Size Report
Startup median (7 runs, lower is better):
|
Member
Author
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Makes R76 classify daemon edges by what they reach instead of by filename (#2542, first half).
The inventory keyed on the target filename
src/platform-runtime*.ts. A daemon import of a root module that imports that family itself —src/provider-device-runtime.tsis the real case — carried the same platform mechanics and was invisible to the gate. Dynamic edges were invisible too, and the ranked spine cannot see a dynamic import's direction at all (R4 cycles, R5 back-edges, R6 inversions all skip it).computePlatformMechanicsHubsnow derives the target set from the tree: the platform-runtime family plus every module outside the daemon zone that reaches it, over static and dynamic edges alike. Intra-daemon hops stay out, so the rule does not flag every file in the zone (the measured alternative was 298 pairs; the real answer is 3).Newly visible, and classified rather than allowlisted
daemon/server/daemon-runtime.ts -> src/provider-device-runtimes.tsdaemon/server/daemon-runtime.ts -> src/provider-device-runtime.tsdaemon/snapshot-interactor-capture.ts -> src/core/interactors.ts(dynamic)The dynamic interactor lookup is the interesting one: a filename pattern never would have asked for a rationale there, and it is the only production edge that leaves the daemon zone dynamically.
Verification
Planted-violation cases in
scripts/layering/daemon-platform-runtime-inventory.test.ts(24 tests): a new hub import is red, a symbol added to a classified hub edge is red, a binding added to the dynamic lookup is red, an intra-daemon hop is not a hub, and the accepted paths hold on the real shapes.pnpm check:layeringpasses on this tip with the three entries; a recorded edge that disappears is still stale, so the inventory cannot drift in either direction.Not in this PR
The rest of #2542 is the entry half, and it is a different shape of work: declaring the root→daemon entry surface and repairing the eight
daemon-client -> src/daemon/**value edges (config.ts,daemon-process.ts,session-repair-tombstone.ts,request-progress-protocol.ts) rather than classifying them. The cut sets are small for three of those four (config.tshas 42 inbound files and needs a subset decision), so it belongs in its own change. I will file it as a child of #2542 rather than grow this PR across both halves.Part of #2542