F18 Phase B: server-side endpoint for `vers feedback`

[AlephNotation]

PR #191 shipped F18 Phase A: vers feedback "..." writes to ~/.vers/feedback.jsonl locally and best-effort POSTs to $VERS_FEEDBACK_ENDPOINT if set. Phase B is the server-side ingestion target so users don't have to BYO endpoint.

Today

Local-only by default. Upstream POST is opt-in and lands wherever the user points it. Friction reports never reach maintainers unless the user explicitly configures something.

Target

A default VERS_FEEDBACK_ENDPOINT baked into the binary that points at hdresearch infrastructure. Users can override; agents get a working feedback channel out of the box.

The decision (this issue exists to surface it)

Two viable backends, each with cost/benefit:

Option A: GitHub Issues with a cli-feedback label

• Pros: zero new infra; team already triages issues there; gh issue list -l cli-feedback is the dashboard for free; addressable per-report.
• Cons: needs auth. Either a team-owned bot token (security risk if extracted from the binary), or a thin proxy on api.vers.sh that auths via the user's vers API key and creates the issue server-side.
• Recommendation: thin proxy. POST https://api.vers.sh/api/v1/cli-feedback with vers auth → server creates issue with cli-feedback label, returns issue URL.

Option B: dedicated datastore + dashboard

• Pros: clean separation; can add per-user dashboards, analytics, sentiment classification.
• Cons: requires building a datastore + dashboard from scratch; ongoing maintenance.

Recommendation

Option A. The issue tracker IS the dashboard. The cli-feedback label keeps the noise contained and searchable.

Scope (assuming Option A)

1. Backend (vers-api or wherever the orchestrator lives):

   • New endpoint: POST /api/v1/cli-feedback
   • Auth: standard vers API key
   • Body: {id, timestamp, vers_version, message}
   • Side effect: creates a GitHub issue on hdresearch/vers-cli with the cli-feedback label, body containing the message + metadata
   • Response: {issue_url}

2. CLI (this repo):

   • Set default VERS_FEEDBACK_ENDPOINT = "https://api.vers.sh/api/v1/cli-feedback" if unset.
   • On success, surface the returned issue_url so the agent can link to it.
   • Local journal entry adds issue_url field.
   • agent-context declares the default endpoint and notes it can be overridden.

Out of scope for this issue

• The vers-cli side wiring is trivial once the backend exists. The work is the backend decision + endpoint.
• Anonymization or PII scrubbing — discuss separately if needed.