feat(cli): add daemonless gortex analyze command

[avfirsov]

What

Adds a daemonless gortex analyze CLI command:

gortex analyze --kind <synthesizers|resolution_outcomes> --path <dir> [--format json|text]

It indexes --path entirely in-process — no daemon, no socket — and runs the analyzer against the fresh graph. Useful for CI pipelines and one-shot scripts that want graph analytics without standing up the daemon.

Why this shape

To avoid duplicating logic between the MCP tool and the new CLI, the analyzer cores are extracted into a new internal/analyzer package as pure calculations (graph in, struct out):

• AnalyzeSynthesizers
• AnalyzeResolutionOutcomes / ClassifyUnresolved

The existing MCP handlers (handleAnalyzeSynthesizers, handleAnalyzeResolutionOutcomes) are refactored to call these cores. Output shapes are unchanged — the existing MCP-layer tests pass as-is, which is the safety net for the refactor. The resolution-outcome taxonomy constants now live in internal/analyzer, with thin aliases retained in the mcp package so existing call sites/tests keep compiling.

Tests

• internal/analyzer: unit/shape tests for both cores (synthesizer grouping + name filter; the full unresolved-edge taxonomy + reason filter).
• cmd/gortex: end-to-end index→analyze tests asserting valid JSON for both kinds, plus unsupported-kind validation.
• Existing internal/mcp analyze handler tests unchanged and green.

go build ./... and go test ./internal/analyzer/... ./cmd/gortex/... ./internal/mcp/... pass.

Notes / scope

• Two kinds to start (synthesizers, resolution_outcomes) — the ones whose cores are extracted here. Easy to extend the dispatcher to more kinds in follow-ups.
• Purely additive on the CLI surface; the only change to existing code is the DRY refactor of the two MCP handlers onto the shared cores.

🤖 Generated with Claude Code

[avfirsov]

Hi @zzet 👋 — gentle ping on these four, all ready for review (CI green, mergeable: CLEAN, no conflicts with main):

• feat(cli): add daemonless gortex analyze command #84 — daemonless gortex analyze CLI
• feat(temporal): resolve wrapper-forwarded activity/workflow dispatch #85 — wrapper-forwarded activity/workflow dispatch
• feat(temporal): resolve executor struct-field dispatch #86 — executor struct-field dispatch
• feat(temporal): resolve func-returning-constant dispatch names #87 — func-returning-constant dispatch names

Update on the overlap I flagged earlier: I checked #85 and #87 against the temporal work that already landed in main, and there's no real duplication — they're complementary:

• feat(temporal): resolve wrapper-forwarded activity/workflow dispatch #85 builds directly on top of 83ef21e (dispatch-wrapper detection). That commit explicitly left cross-file wrapper-following as a documented blind spot; feat(temporal): resolve wrapper-forwarded activity/workflow dispatch #85 adds exactly that interprocedural pass — it reuses your markGoTemporalWrapper node marker and resolves the forwarded literal through the wrapper. Already rebased on the latest main, nothing to drop.
• feat(temporal): resolve func-returning-constant dispatch names #87 reuses the constant-value sidecar from 89e7aa4 as its persistence layer but adds a distinct capability: func() string { return "lit" }-style dispatch (func-returning-constant), which 89e7aa4 (const-variable deref only) doesn't cover. Rebased onto the current main.
• feat(temporal): resolve executor struct-field dispatch #86 (executor struct-field dispatch) is fully independent — no overlap with anything merged.

No rush at all — happy to split or adjust anything further if you'd prefer. Thanks for the project!

[avfirsov]

Hi @zzet 👋 — overview of the current open batch (all rebased onto latest main, CI green or running, no conflicts between a PR and main):

Docs / infra (independent, low-risk):

• docs(temporal): Java EE / Jakarta EE edge-resolver spec + design + plan #94 — Java EE / Jakarta EE edge-resolver spec + design + implementation plan (docs-only)
• fix(lsp): Windows-correct file:// URI conversion (jdtls no-op on Windows) #92 — fix(lsp): Windows-correct file:// URI conversion. Standalone leaf pkg internal/lspuri; fixes jdtls being detected-but-no-op on native Windows (drive-letter/separator round-trip dropped every LSP result). Routes 6 hand-rolled conversion sites through it.

Temporal dispatch resolvers (Go) — these all touch temporal_calls.go/temporal tests, so they conflict with each other; happy to keep rebasing as you merge, just merge in any order and ping me (or tell me a preferred order):

• feat(temporal): orphan/integrity detection + analyze temporal_orphans tool #88 — orphan/integrity detection + analyze kind=temporal_orphans (mostly additive)
• feat(temporal): resolve func-returning-constant dispatch names #87 — func-returning-constant dispatch
• feat(temporal): resolve unregistered activities by func-name convention #89 — unregistered activities by func-name convention
• feat(temporal): variable-tracing, const-to-const & exact-name signature dispatch #98 — variable-tracing + const-to-const alias + exact-name signature-match (re-implemented onto the post-Temporal cluster: merge #78/#79/#81 + cross-language Java→Go join (#77) + const retention (#80) #82/feat(temporal): resolve wrapper-forwarded activity/workflow dispatch #85/feat(temporal): resolve executor struct-field dispatch #86 const-deref sidecar; multi-candidate → hidden speculative)
• feat(temporal): env-helper dispatch resolution — source-tiered defaults, allow-list, const-ref #90 — env-helper dispatch: source-tiered defaults + opt-in allow-list + const-ref defaults

Java cross-language:

• feat(temporal): Java cross-language dispatch — Java→Go bridge, @Value, const-ref, invoker detection #97 — Java→Go bridge + @Value field + Java const-ref + invoker detection. Bridge/@Value/const-ref work standalone; invoker detection is config-gated (programmatic/test-only until a temporal-config surface exists on main — I left the config schema to you; happy to wire it if you want it active by default).

LLM:

• feat(temporal): LLM cleaning pass — analyze kind=temporal_verify #96 — analyze kind=temporal_verify LLM cleaning pass (verifies low-confidence temporal edges; promote/suppress/keep). Standalone (no dependency on the feat(temporal): env-helper dispatch resolution — source-tiered defaults, allow-list, const-ref #90 allow-list), LLM-gated, with the MCP handler wired.

CLI:

• feat(cli): add daemonless gortex analyze command #84 — daemonless gortex analyze. (A follow-up multi-repo analyze --repo extends this file, so I'm holding it until feat(cli): add daemonless gortex analyze command #84 lands.)

Suggested low-friction start: #94, #92, #88 are the most independent. The temporal-resolver cluster (#87/#89/#90/#98) I'll rebase-on-merge so each lands clean. No rush — thanks for the project!

[avfirsov]

@zzet — rebase sweep done. After #87 merged (and then #93 change_contract + #95 deps), the temporal-resolver cluster went DIRTY. All affected branches are now rebased onto latest main (2c3530e), with go build ./... + targeted tests (resolver, parser/languages, indexer; mcp for #96) green, and GitHub now reports them MERGEABLE:

• feat(temporal): Java cross-language dispatch — Java→Go bridge, @Value, const-ref, invoker detection #97, feat(temporal): variable-tracing, const-to-const & exact-name signature dispatch #98 — golang.go + temporal_calls.go: kept feat(temporal): resolve func-returning-constant dispatch names #87's broadened Constant|Function|Method dispatch-name filter while preserving each branch's own resolver structure (vartrace's resolveNames closure / feat(temporal): Java cross-language dispatch — Java→Go bridge, @Value, const-ref, invoker detection #97's Java field-value switch).
• feat(temporal): resolve unregistered activities by func-name convention #89, feat(temporal): env-helper dispatch resolution — source-tiered defaults, allow-list, const-ref #90 — keep-both on the temporal E2E tests + the same goConstLiteralValue(name) reconcile.
• feat(temporal): LLM cleaning pass — analyze kind=temporal_verify #96 — re-rebased onto Change-contract pipeline: one verdict envelope for every change source #93's change_contract pipeline; merged the analyze kind list so it carries both temporal_verify and suggest_boundaries.

#84 / #88 / #92 / #94 needed no rebase (#92 verified clean via git merge-tree). The cluster still self-conflicts on merge — happy to rebase the remainder again whenever you land the next one.

[avfirsov]

Friendly ping @zzet 🙂 — CI is green (10/10) and the branch is MERGEABLE / CLEAN (no conflicts, not behind main). This adds a daemonless gortex analyze command. Happy to rebase or address any review feedback whenever you have a moment. Thanks!

[zzet]

Hey @avfirsov
I'm concerned about explicit daemon less mode and I haven't finish experimenting with an alternative resolution of the problem. Can you bring more light on cases you're facing?

[avfirsov]

Thanks @zzet — and totally fair to hold off if you're still exploring an alternative. Let me lay out the concrete cases that pushed me to a daemonless one-shot, so we're optimizing for the same problem (the capability, not necessarily an explicit user-facing "daemonless mode").

The original need: comparing fork vs. original on a large legacy repo. The whole thing started because I wanted a clean A/B — "does the temporal work actually resolve more edges than baseline?" — on a real legacy codebase. Three constraints made the resident daemon awkward there:

1. Windows, no WSL, driven from an MCP client (opencode). On native Windows the daemon/AF_UNIX-socket path is the rough edge: running two builds side by side means two sockets, two state homes, and two MCP servers registered in the client. A one-shot analyze that indexes the path in-process, runs the analyzer, prints JSON and exits sidesteps all of it — no socket, no daemon, no collision.

2. One-shot / CI-style invocation. "Index this path once, give me temporal_orphans / synthesizers as JSON, exit." There's no long-lived editor session to amortize a resident daemon against — warming and tearing down a daemon for a single report is pure overhead.

3. Reproducible benchmark of two configurations. Same binary, flip one variable, diff the output. A resident daemon adds shared cache/snapshot state between runs that I specifically wanted out of the experiment.

So the value I'm actually after is "run an analyzer over a path without standing up a daemon." If you'd rather express that some other way — e.g. the existing daemon path auto-spawning an ephemeral in-process instance when no daemon is reachable, instead of a distinct daemonless concept — I'm very happy to rework #84 to fit whatever you land on. I don't want to lock in a parallel mode that fights your direction.

What does your alternative resolution look like so far? If you can point me at the shape you're leaning toward, I can adapt this PR (or close it and fold the CLI surface into your approach). No rush.