Skip to content

Add suggestion_id to prompt chip and passive-suggestion result (REV-2138) - #364

Draft
warp-agent-staging[bot] wants to merge 1 commit into
mainfrom
factory/rev-2138-suggestion-id
Draft

Add suggestion_id to prompt chip and passive-suggestion result (REV-2138)#364
warp-agent-staging[bot] wants to merge 1 commit into
mainfrom
factory/rev-2138-suggestion-id

Conversation

@warp-agent-staging

Copy link
Copy Markdown
Contributor

Description

Adds an opaque, server-minted offer id to the two prompt-suggestion wire surfaces:

  • ToolCall.SuggestPrompt.PromptChip.suggestion_idfield 3 (task.proto). The server stamps this on each chip it streams.
  • PassiveSuggestionResultType.suggestion_idfield 5 (task.proto; 1–4 were taken by the trigger and suggestion oneofs). The client round-trips it verbatim when the user accepts a chip.

suggestion_id sits on the shared PassiveSuggestionResultType rather than on Input.UserInputs.PassiveSuggestionResultInput so one field covers both the accept request input (PassiveSuggestionResultInput.result) and the persisted history message (Message.PassiveSuggestionResult.result), which is exactly the request shape the spec calls for (passive_suggestion_result { suggestion_id, prompt }).

No existing field is renumbered, reused, or reserved. This PR is only the id plumbing — no server or client behavior.

Justification

Part of REV-2138 — Free-user credit allowance for prompt-suggestion agent runs, implementing the warp-proto-apis slice of the approved spec in warpdotdev/warp-server#15272 (specs/REV-2138/{PRODUCT,TECH}.md).

The prompt text on an accept request is client-authored today, so a client can send any string and have it run against the new free-tier allowance (TECH.md §5). The fix is an offer vault: the server persists the prompt text it generated, mints a single-use suggestion_id, puts that id on the streamed chip, and substitutes its stored text for whatever the client sends when the id redeems. That requires an id on both surfaces, which is what this change adds.

Mapping to the spec:

  • TECH.md §5, step 3: "Put suggestion_id on the streamed PromptChip (proto-apis)."
  • TECH.md "Request shapes": click: input.user_inputs[] = passive_suggestion_result { suggestion_id, prompt }.
  • TECH.md "Cross-repo" item 2: "suggestion_id on PromptChip and PassiveSuggestionResult."

Both fields are optional and unset by existing clients and by the server until the warp-server and warp changes land. An absent, unknown, expired, or already-redeemed id is not an error — the request falls through to the ordinary allowance waterfall with the client's text, per TECH.md §5 step 1 — so this can merge ahead of the other two repos. Ship order per the spec is proto → server → client.

Sensitive Fields

suggestion_id is an opaque server-generated identifier, not user content, so it is deliberately not marked (sensitive). No other string field is added or changed.

  • I have ensured that all string fields that contain sensitive information are marked as sensitive.

Validation

  • ./script/generate -a multi_agent -v v1 (protoc 30.2, protoc-gen-go v1.36.6) — regenerated apis/multi_agent/v1/gen/go/task.pb.go, committed.
  • Ran the generator a second time: the CI comparison (git diff -I '^[[:space:]]*//.*(protoc|protoc-gen-go)[[:space:]]*v[0-9]', the same expression check-generated-code.yml uses) is empty, so the checked-in Go is up to date. The other 14 .pb.go files only differ in the // protoc vX header comment this environment's protoc emits, which that check ignores by design, so they are left untouched.
  • cd apis/multi_agent && go build ./... && go vet ./... — clean.
  • cargo build and cargo test — clean; confirmed the build script's compile-time Rust bindings contain pub suggestion_id: ::prost::alloc::string::String on both messages.

Not touched: apis/multi_agent/v1/gen/python, which script/generate does not produce and which is already stale relative to main.

REV-2138 needs an opaque, server-minted id for a prompt-suggestion offer so
the server can substitute its own stored prompt text on accept instead of
trusting the client-authored string.

- ToolCall.SuggestPrompt.PromptChip.suggestion_id (field 3): stamped on the
  chip the server streams.
- PassiveSuggestionResultType.suggestion_id (field 5): round-tripped by the
  client on accept. Putting it on the shared type covers both the request
  input (Input.UserInputs.PassiveSuggestionResultInput.result) and the
  persisted history message (Message.PassiveSuggestionResult.result).

Regenerated the Go bindings with ./script/generate -a multi_agent -v v1.
@cla-bot

cla-bot Bot commented Aug 19, 2026

Copy link
Copy Markdown

Thank you for your pull request and welcome to our community. We could not parse the GitHub identity of the following contributors: Warp Factory.
This is most likely caused by a git client misconfiguration; please make sure to:

  1. check if your git client is configured with an email to sign commits git config --list | grep email
  2. If not, set it up using git config --global user.email email@example.com
  3. Make sure that the git commit email is configured in your GitHub account settings, see https://github.com/settings/emails

@warp-agent-staging

Copy link
Copy Markdown
Contributor Author

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.

View run View conversation View on Slack

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants