effx inspect
Print one operation's kind, contract, errors, requirements, authority and exposures as a text tree.
effx inspect <name> [--project <tsconfig>] [--config <file>] [--out-dir <dir>] [--strict-access | --no-strict-access] [--target <profile>] [--emit <mode>]From the monorepo root: bun run effx inspect User.Get --project examples/users/tsconfig.json.
Source: inspectCommand in packages/cli/src/commands.ts, packages/cli/src/inspect.ts, spec 0003 "inspect format".
Arguments and flags
| Item | Detail |
|---|---|
name | required positional argument |
--project | path to a tsconfig, default tsconfig.json |
--config | path to an effx.config.ts module, default discovery beside the selected tsconfig |
--out-dir | output directory for generated files. Accepted, but inspect writes nothing. |
--strict-access, --no-strict-access | boolean flag, default false |
--target | effect-4.0, default resolved from the installed Effect |
--emit | contract, handlers or all, default all |
These are the six shared flags that the root command defines, so inspect accepts the same flags as check and build. Flags, effx.config.ts, the tsconfig effx block and defaults are resolved in the order given in Project config. inspect User.Get --strict-access exits 0 on examples/users (observed by running bun scripts/effx.ts).
inspect compiles the project with the resolved settings and the resolved extension list, and reads the IR through its graph index. It does not write files and does not print diagnostics, so --strict-access does not turn a warning into a failing exit here. Use check for that. Only generate is skipped when errors exist, so inspect still shows the IR (comment in indexed, commands.ts). A missing or invalid explicit --config still fails before compilation.
Name resolution
The name is resolved in this order (resolveName):
| Order | Rule | Example |
|---|---|---|
| 1 | A valid StableId that matches a node is used as given | operation:User.Get |
| 2 | Otherwise operation:<name> | User.Get |
| 3 | Otherwise the unique node whose id name equals name | a name shared by exactly one node |
If the resolved node is not an Operation, or nothing resolves, the command prints error: no operation named <name> on stdout and exits 1. See StableId.
Output format
The sections are always printed in this order. An empty section prints (none).
Operation <operation name>
Kind
<Query | Command>
Contract
<input schema> → <success schema>
Errors
<error schema names, sorted>
Requirements
<service names, sorted>
Authority
<capability name>
resource: <model name>
focus: <focus name>
Exposed
<METHOD /path>
RPC <name>
CLI <words>| Section | Rule |
|---|---|
| Schema names | The last / segment of the schema's StableId name. For example src/user/User.Self prints as User.Self. |
Errors, Requirements | The heading gains (inferred) when the IR marks the set as inferred rather than declared (ADR 0005). Values are sorted. |
Authority | One block per AuthorizedBy edge: the capability name, its resource, and its focus if it has one. A missing target prints (missing). |
Exposed | Listed in StableId order of the exposure. HTTP prints METHOD path, RPC prints RPC name, CLI prints CLI words. |
Example
This is the format example from spec 0003 for User.ChangeEmail. It is not captured from a run for this page.
Operation User.ChangeEmail
Kind
Command
Contract
ChangeEmailInput → User.Self
Errors
EmailTaken
UserNotFound
Requirements
Users
Authority
User.ChangeEmail
resource: User
focus: User.email
Exposed
PATCH /users/:id/email
RPC User.ChangeEmail
CLI users change-emailExit code
| Condition | Exit |
|---|---|
| Operation found | 0 |
| No operation resolves | 1 (UnknownName) |