api passthrough: endpointSuggestions misses the contents API — raw /contents/ calls aren't steered to madt_files #43

New issue

Closed

opened 2026-07-13 20:45:03 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-13 20:45:03 +00:00

(Migrated from codeberg.org)

Live evidence (2026-07-13, during the release-recovery work): I made four raw madt_api_call requests that all have first-class madt_files coverage, and the passthrough steered none of them:

GET /repos/{owner}/{repo}/contents/{dir} ×2 (directory list → madt_files action=list)
GET /repos/{owner}/{repo}/contents/{file} (file read → madt_files action=get)
POST /repos/{owner}/{repo}/contents/{file} (file create/commit → madt_files action=create)

endpointSuggestions (internal/service/api/suggestions.go) exists precisely so raw-API fallthrough points agents at the typed surface — but it has no mapping for the contents endpoints, so the calls pass through silently and the agent never learns madt_files exists.

Ask: add contents-API mappings — GET|POST|PUT|DELETE /repos/{owner}/{repo}/contents/* (file and directory forms, incl. the bare /contents/ root listing) → the corresponding madt_files action, on both surfaces (madtea api CLI and madt_api_call).

Acceptance:

A raw contents get/list/create/update/delete via the passthrough returns its result WITH the suggestion naming the exact madt_files action.
Suggestion coverage test extended; existing suggestions regression-pinned.

Also absorbed here: the repo previously carried a session-local rule blocking raw madtea api until an issue was filed for the missing command (removed in #45 — it never reached real users, since repo-local session config only loads inside a madtea clone). The suggestion surface this issue asks for is the shipped mechanism that intent actually needs: every unmapped passthrough call should point at the typed surface or invite an issue for the gap.

Live evidence (2026-07-13, during the release-recovery work): I made four raw `madt_api_call` requests that all have first-class `madt_files` coverage, and the passthrough steered none of them: - `GET /repos/{owner}/{repo}/contents/{dir}` ×2 (directory list → `madt_files action=list`) - `GET /repos/{owner}/{repo}/contents/{file}` (file read → `madt_files action=get`) - `POST /repos/{owner}/{repo}/contents/{file}` (file create/commit → `madt_files action=create`) `endpointSuggestions` (internal/service/api/suggestions.go) exists precisely so raw-API fallthrough points agents at the typed surface — but it has no mapping for the contents endpoints, so the calls pass through silently and the agent never learns `madt_files` exists. Ask: add contents-API mappings — `GET|POST|PUT|DELETE /repos/{owner}/{repo}/contents/*` (file and directory forms, incl. the bare `/contents/` root listing) → the corresponding `madt_files` action, on both surfaces (`madtea api` CLI and `madt_api_call`). Acceptance: - A raw contents get/list/create/update/delete via the passthrough returns its result WITH the suggestion naming the exact `madt_files` action. - Suggestion coverage test extended; existing suggestions regression-pinned. Also absorbed here: the repo previously carried a session-local rule blocking raw `madtea api` until an issue was filed for the missing command (removed in #45 — it never reached real users, since repo-local session config only loads inside a madtea clone). The suggestion surface this issue asks for is the shipped mechanism that intent actually needs: every unmapped passthrough call should point at the typed surface or invite an issue for the gap.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#43

No description provided.

Rows
Columns