Flagging a design issue... While

[raw viper]

The problem is that I can't just "hide the core API" engine-side, because the CLI depends on parts of the core API, it's just not clearly documented or marked which parts... So that's what I'm stuck on.
I guess the idea has always been that the core API is always there and thus it would never matter.

You're gonna hit the same problem with function calls because SDKs use the core API to query what their inputs were, return results, return errors, etc.

• Thought process there being why invent a whole new API system when we already have one

That's all fixable with enough effort, but I do wonder how important it is to exclude the core API from being automatically loaded? If it's not that crucial, can save a bunch of effort + churn leaving that alone for now.

But then again if it is really important that we make core not autoloaded, it's more feasible these days given codex/claude... so not ruling that out as an option

[olive jungle]

yeah it's not actually a goal to not load core api - that's just how I tried to do it. Really the goal is to preserve the CLI behavior of selectively hiding it. Because the current mechanism for that relies on a concept of "main module" that goes away

maybe instead the CLI can detect which functions are from the coremod, and just hide them

[raw viper]

iiuc, yeah that's probably the easiest lift to start. I think the CLI already knows how to determine which fields under query are from core

[olive jungle]

ah! I will look for that. I haven't found that in CLI code, just saw that eg. dagger call -m foo bar just loads everything and wraps every query in foo { }

[raw viper]

I could be misremembering, take with salt. But if it doesn't have that ability, I think it would be trivial for an llm to knock out

[olive jungle]

yeah I'm thinking either a new field in typedef (core: bool?) or perhaps an argument to currentTypeDefs(includeCore: bool)