Skip to content

refactor(provider-core): share attachment prompts, notifications, and…

MacroscopeApp / Macroscope - Effect Service Conventions completed Oct 8, 2026 in 2m 52s

Effect Service Conventions: 1 violation

apps/server/src/provider/ProviderEventLoggers.ts:32 imports an Effect service tag by name at a service-construction boundary instead of using its module namespace. An inline review comment suggests the fix.

Details

Warning

  • Invalid effort level "max" in front matter. Fell back to "low". Valid values are: low, medium, high.

Note

Your check run agent prompt is: .macroscope/check-run-agents/effect-service-conventions.md
More information about how Check Run Agents work can be found in our Help Center.

Reviewed all 26 changed files (no prior completed review)


πŸ” Agent activity β€” 14 tool calls

πŸ’­ Inspecting service boundaries I need to investigate the new consumer import conventions alongside the service. There's something flagged about ProviderEventLoggers, which might indicate a potential violation of the import service boundary. It seems important to clarify these details to ensure everything is compliant with the regulations. So, I'll look deeper into the specifics and see what needs to be addressed to prevent any issues. Let's get to the bottom of this!

1. browse_code β€” apps/server/src/provider/ProviderEventLoggers.ts

πŸ’­ Inspecting module structure I'm thinking about how to handle a named import service module and whether I should treat it as a namespace at the boundary while re-exporting shims. The old module is focused on construction, which doesn't function as a shim, but is that okay? A canonical module for the service needs both a tag and a make layer together. This might mean splitting the tag into core and implementation on the server side due to necessity. I need to check the documentation to clarify.

2. browse_code β€” docs/internals/effect-services.md

πŸ’­ Identifying code violations I need to pinpoint where tangible violations are occurring, specifically a changed named import at boundary line 32. Replacing the namespace requires re-exporting while keeping existing consumers in mind. It might be worth suggesting a unified approach since changes affect many cross-file consumers without any noticeable differences. Also, it seems splitting the core module's service tag for packaging abstraction is unavoidable to prevent issues. I'll inspect other usages of named ProviderEventLoggers that only impact the server.

3. modify_pr β€” Submitted review with 1 inline comment

4. browse_code β€” apps/server/src/provider/EventNdjsonLogger.ts

5. browse_code β€” In PR head, are there other changed service-boundary imports of ProviderEventLoggers or effect service modules, or missing migrated consumers of old files? Give concise paths.

6. browse_code β€” packages/provider-core/src/server/ProviderEventLoggers.ts

7. browse_code β€” Find all imports referencing old apps/server/src/orchestration-v2/AttachmentPrompt.ts, Notification.ts, provider/RuntimeInstructions.ts, provider/Drivers/instanceIdentity.ts in repository head, including relative import paths. Report exact paths if any.

8. browse_code β€” apps/server/src/provider/Drivers/CodexDriver.ts

9. browse_code β€” Check only changed imports in PR diff from merge base 48b71f0 to head 574fbd0: are any moved helper files importing a service as named rather than namespace? Identify violations other than apps/server/src/provider/ProviderEventLoggers.ts.

10. modify_pr β€” not performed: the agent's request was refused before it ran

11. browse_code β€” packages/provider-core/src/server/attachmentPrompt.ts

12. browse_code β€” packages/provider-core/src/server/instanceIdentity.ts

13. browse_code β€” apps/server/src/provider/ProviderEventLoggers.ts

14. browse_code β€” packages/provider-core/src/server/notification.ts


Agent Credits: 36 credits

Token usage: 96 uncached input Β· 456,197 cache-read input Β· 80,389 cache-write input Β· 4,989 output
Agent Credits may also include non-token charges from external tools such as web research.