feat(kap-server): add POST /api/v1/feedback endpoint

[7Sageer]

Related Issue

No linked issue; the problem is explained below.

Problem

kap-server has no way for hosts embedding it (the web UI) to submit user feedback. The CLI already ships a complete /feedback flow that posts to the managed collection backend with the managed provider's OAuth token; kap-server hosts need the same capability behind the local /api/v1 surface.

What changed

Mirrors the CLI's existing feedback implementation (apps/kimi-code/src/feedback/ on top of @moonshot-ai/kimi-code-oauth) as three kap-server routes:

• POST /api/v1/feedback — validates { content, session_id, type?, title?, contact?, diagnostics?, agent_id?, info? } (zod) and forwards the submission to the managed backend with the managed provider's OAuth access token. The host version, server OS, and default model are stamped server-side (same fields the CLI sends); the form-only fields (type / title / diagnostics / agent_id) fold into the backend's structured info bag. Returns { feedback_id } for the attachment flow. Only content and session_id are required — clients without a category picker are not forced into junk defaults.
• POST /api/v1/feedback/upload_url — proxies the backend's presigned-upload-url creation; the client then PUTs the archive parts to the presigned URLs directly (multipart, resumable).
• POST /api/v1/feedback/upload_complete — proxies the upload-completion marker.

Error mapping: not signed in to the managed provider → 40111; backend failure → 50001; validation → 40001. The routes are mounted under /api/v1 (so the global bearer-auth hook covers them) and appear in the OpenAPI document under a new feedback tag.

Tests cover the forwarded request shape (URL, bearer header, body stamping, info folding), the not-signed-in gate (backend never called), backend-failure mapping, both upload proxies, and validation failures. The API-surface snapshot gains exactly the three new routes.

The web UI feedback form that will consume these endpoints is follow-up work.

Client flow

All three endpoints are protected by kap-server's normal local bearer authentication. The managed provider's OAuth access token stays inside kap-server and is never returned to the client.

Every control-plane response uses the standard kap-server envelope:

{
  "code": 0,
  "msg": "success",
  "data": {},
  "request_id": "request-id"
}

The business result is carried by code; callers must not use the HTTP status alone to determine success.

1. Submit the text feedback

POST /api/v1/feedback

{
  "content": "The session list flashes on open",
  "session_id": "session-id",
  "type": "bug",
  "diagnostics": "logs"
}

content and session_id are required. type is one of bug, feature, or other; diagnostics is one of none, logs, or logs_and_codebase. The optional info object may carry additional metadata, but must not redefine the reserved type, title, diagnostics, or agent_id keys.

Successful response data:

{
  "feedback_id": 7
}

diagnostics only records the attachment selection in feedback metadata. kap-server does not collect, archive, or upload logs or source code automatically. The client is responsible for preparing each requested archive.

2. Create an attachment upload

Compute the archive size and SHA-256 digest, then request the multipart upload:

POST /api/v1/feedback/upload_url

{
  "feedback_id": 7,
  "file_name": "session.zip",
  "file_size": 1048576,
  "file_hash": "<SHA-256 hex>"
}

Successful response data:

{
  "upload_id": 3,
  "parts": [
    {
      "part_number": 1,
      "url": "https://storage.example.test/presigned-part-1",
      "method": "PUT",
      "size": 1048576
    }
  ]
}

Sort parts by part_number. Starting at byte offset zero, each part consumes the next size bytes of the archive; the next part starts immediately after the previous one. Upload those bytes directly to the returned url, using the returned HTTP method and a Content-Length matching the part size. Record the ETag response header for every successful part.

The archive bytes and presigned upload requests do not pass through kap-server.

3. Complete the attachment upload

After every part succeeds, report the collected ETags:

POST /api/v1/feedback/upload_complete

{
  "upload_id": 3,
  "parts": [
    {
      "part_number": 1,
      "etag": "\"etag-value\""
    }
  ]
}

Successful response data is null.

Text feedback is created before attachments are uploaded. An attachment preparation, part upload, or completion failure does not roll back the feedback record; clients should present that outcome as feedback submitted with an attachment failure, and may retry the attachment flow separately.

Checklist

• I have read the CONTRIBUTING document.
• I have linked a related issue, or explained the problem above.
• I have added tests that prove my feature works.
• Ran gen-changesets skill, or this PR needs no changeset — none: per the skill's rules, new kap-server REST endpoints without a shipped consumer are not user-perceivable (the global-search endpoint PR followed the same practice).
• Ran gen-docs skill, or this PR needs no doc update — no user-facing surface yet.

[changeset-bot]

⚠️ No Changeset found

Latest commit: c7f7041

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

pnpm dlx https://pkg.pr.new/@moonshot-ai/kimi-code@c7f7041

npx https://pkg.pr.new/@moonshot-ai/kimi-code@c7f7041

commit: c7f7041