Skip to content

Add go output language#100

Merged
kalil0321 merged 4 commits into
kalil0321:mainfrom
jarsh921:add-go-output-language
Jul 22, 2026
Merged

Add go output language#100
kalil0321 merged 4 commits into
kalil0321:mainfrom
jarsh921:add-go-output-language

Conversation

@jarsh921

@jarsh921 jarsh921 commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Summary by cubic

Adds Go as a supported output language. Generate a standard-library-first Go client and run it with go run api_client.go; the Go prompt now aligns filenames with the run command.

  • New Features

    • Go codegen: new prompt partial favoring net/http and encoding/json, one shared http.Client, hardcoded auth, 401/403 refresh handling, and a gofmt step in testing instructions.
    • Engine updates: .go extension, language name “Go”, run command go run api_client.go, and conditional go.mod/go.sum when external deps are required.
    • CLI/settings and docs: output_language: "go" added to the picker and docs; tests cover extension, run command, and prompt content.
  • Bug Fixes

    • Removed main.go reference in the Go prompt to match the saved api_client.go and go run api_client.go.

Written for commit 1092880. Summary will update on new commits.

Review in cubic

Greptile Summary

This PR adds Go as a supported output language. The main changes are:

  • Adds Go selection and configuration support.
  • Adds Go-specific client generation guidance.
  • Uses api_client.go for saving, discovery, and execution.
  • Adds tests and documentation for Go output.

Confidence Score: 5/5

This looks safe to merge.

  • The Go save path and run command consistently use api_client.go.
  • The earlier conflicting filename instruction has been removed.
  • No blocking issue remains in the updated code.

Important Files Changed

Filename Overview
src/reverse_api/prompts/partials/_language_go.md Adds Go client-generation guidance and consistently names the output api_client.go.
src/reverse_api/base_engineer.py Adds Go filename, display name, run command, and module-file handling.
src/reverse_api/cli.py Adds Go to the output-language settings picker.
tests/test_base_engineer.py Covers the Go extension, run command, and generated prompt.
tests/test_prompts.py Covers rendering the Go prompt with the expected output filename.

Reviews (2): Last reviewed commit: "Fix conflicting Go output filename in th..." | Re-trigger Greptile

Joshua Dunbar added 2 commits July 21, 2026 14:21
Follows the exact same pattern as python/javascript/typescript:

- New prompt partial (prompts/partials/_language_go.md): prefer the
  standard library (net/http, encoding/json) over third-party deps,
  reuse one http.Client across requests, hardcode auth found in the
  traffic (cookies via the client's cookie jar, tokens/API keys in
  headers) with the same auth-refresh-on-401/403 guidance the other
  languages already have, and the same three-tier bot-detection
  fallback (httpcloak -> Playwright CDP -> full browser automation).
- base_engineer.py: added "go" to _OUTPUT_LANGUAGE_EXTENSIONS (.go),
  _get_language_name() ("Go"), _get_run_command() ("go run
  api_client.go"), and _get_auto_output_files() (go.mod/go.sum,
  conditional on external deps being needed - same posture as
  javascript's package.json entry, since net/http-only Go code needs
  neither).
- cli.py: added Go to the interactive `output_language` config picker.
- Updated the three docstrings/comments that listed the language set
  (config.py, engineer.py, prompts/__init__.py) and README.md's output
  language line.
- Tests: mirrored the existing per-language test pattern in
  test_base_engineer.py (extension, run command, prompt content) and
  test_prompts.py (partial loading) for Go.

Full test suite passes (49/49 in the touched files; the 4 failures
elsewhere are pre-existing on main, unrelated to this change - TTY
detection and a Windows path-separator assertion). ruff check is clean
on every file this touches (8 pre-existing lint errors elsewhere on
main, none in the touched lines).
@@ -0,0 +1,23 @@
**Generate a Go program** that replicates the API calls found in the traffic. The following are guidelines — use your judgment on what's appropriate for the specific API:

- Prefer the standard library (`net/http`, `encoding/json`) — a single `main.go` with no external dependencies is the default; only introduce a module and third-party packages if the API genuinely needs something the standard library doesn't provide (e.g. a specific auth scheme's signing library)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Conflicting Go Output Filenames

The prompt calls main.go the default, but the save path and run command require api_client.go. If generation follows the first instruction, go run api_client.go fails and later runs cannot discover the generated client.

Suggested change
- Prefer the standard library (`net/http`, `encoding/json`) — a single `main.go` with no external dependencies is the default; only introduce a module and third-party packages if the API genuinely needs something the standard library doesn't provide (e.g. a specific auth scheme's signing library)
- Prefer the standard library (`net/http`, `encoding/json`) — a single-file program with no external dependencies is the default; only introduce a module and third-party packages if the API genuinely needs something the standard library doesn't provide (e.g. a specific auth scheme's signing library)
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/reverse_api/prompts/partials/_language_go.md
Line: 3

Comment:
**Conflicting Go Output Filenames**

The prompt calls `main.go` the default, but the save path and run command require `api_client.go`. If generation follows the first instruction, `go run api_client.go` fails and later runs cannot discover the generated client.

```suggestion
- Prefer the standard library (`net/http`, `encoding/json`) — a single-file program with no external dependencies is the default; only introduce a module and third-party packages if the API genuinely needs something the standard library doesn't provide (e.g. a specific auth scheme's signing library)
```

How can I resolve this? If you propose a fix, please make it concise.

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All reported issues were addressed across 10 files

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread src/reverse_api/prompts/partials/_language_go.md Outdated
Repository owner deleted a comment from kind-agent Bot Jul 21, 2026
Repository owner deleted a comment from kind-agent Bot Jul 21, 2026
Repository owner deleted a comment from kind-agent Bot Jul 21, 2026
Repository owner deleted a comment from kind-agent Bot Jul 21, 2026
Repository owner deleted a comment from kind-agent Bot Jul 21, 2026
Repository owner deleted a comment from kind-agent Bot Jul 21, 2026
Flagged independently by two review bots (greptile-apps, cubic-dev-ai)
on the PR: the partial's first bullet told the model the default was
a single "main.go", but the actual save path
({scripts_dir}/{client_filename}) and run command (go run
api_client.go) both resolve to api_client.go - if the model had
followed the main.go instruction literally, the run command would
fail to find the file it just wrote. Replaced the specific (wrong)
filename with a generic "single-file program" description, matching
how the Java/C# partials already describe their own output files
without hardcoding a filename that could drift from the real one.
@kalil0321

Copy link
Copy Markdown
Owner

@greptile review

@kalil0321
kalil0321 merged commit c5f60fe into kalil0321:main Jul 22, 2026
2 checks passed
kalil0321 added a commit that referenced this pull request Jul 22, 2026
* Make run/list language-aware and quote run-command paths per-platform

Two gaps found while testing the language PRs (#100-#105):

- discover_scripts() only globbed .py, so 'reverse-api-engineer run' and
  'list' reported 'No Python scripts found' for every non-Python client,
  and the run path always executed the shared-venv Python interpreter.
  Discovery now covers all supported extensions (single source of truth
  in utils.OUTPUT_LANGUAGE_EXTENSIONS, shared with BaseEngineer),
  excludes build dirs and the vendored cJSON sources, and the run
  command dispatches per language - node/npx tsx/go run/mvn exec:exec/
  dotnet run/php/ruby, plus compile-then-execute for C - with a clear
  error when the required tool is missing from PATH.

- The Java/C#/PHP/Ruby/C run commands quoted paths with POSIX-only
  shlex.quote, which cmd.exe/PowerShell parse incorrectly for paths
  with spaces. BaseEngineer._quote_path() now uses
  subprocess.list2cmdline on Windows and shlex.quote elsewhere.

Also asks the C partial for -Wall -Wextra-clean code (generated client
had unused-parameter warnings in live testing).

Verified live: run --json executed real generated Go/PHP/C/C#/Ruby
clients from earlier agent sessions end-to-end (C compiling first).

* Extend run-dispatch tests and fix missing-tool error classification

- The missing-toolchain message contained 'not found', which
  _classify_error's heuristics remap to engine_failure, overriding the
  config_invalid hint. Reworded so the intended kind survives.
- Unit tests for _quote_path on both platforms (list2cmdline quoting on
  win32, shlex on POSIX) and for spaced paths surviving intact in the
  dispatch argv lists.

Live matrix via the CLI: go/php/c/csharp/ruby clients from the language-PR
test sessions plus hand-written js/ts clients all ran with exit 0,
including --file selection, --ls listing, args passthrough (node),
the Java script-args misuse error, and the missing-tool config_invalid
error under a stripped PATH.

* Address review: fix path-component exclusion, resolve relative scripts, document quoting boundary

- discover_scripts filtered on every component of the full path, so a
  custom output_dir under a directory named like a build dir (e.g.
  /tmp/target/...) excluded all scripts. iterdir() doesn't recurse and
  non-files are already skipped, so the parts-based filter could only
  misfire - removed it.
- build_script_commands now resolves the script path before building
  argv: callers run with cwd=script.parent, which would re-anchor a
  relative path (from a relative output_dir) and fail to start.
- _quote_path docstring now states the Windows quoting boundary
  precisely: list2cmdline is cmd.exe/CreateProcess-safe; PowerShell
  additionally expands $/backtick inside double quotes and no quoting
  satisfies both shells for such paths.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants