chore(proto): pull FlowIntent and the consent document RPC

[rohanchkrabrty]

Part of RFC 0002: Explicit consent at signup. First of the stack; the login gate, the consent service and the migration follow.

Pins PROTON_COMMIT to the proton commit adding FlowIntent, the two AuthenticateRequest fields and the ListConsentDocuments RPC (raystack/proton#501), and regenerates. No frontier logic here — the generated code just has to exist before anything can reference it.

Changes

• PROTON_COMMIT bumped to b4a0f2fe8eaef5626e1661e7e2c9faede89693b9.
• Regenerated proto/v1beta1/frontier.pb.go and proto/v1beta1/frontierv1beta1connect/frontier.connect.go.

The new surface: the FlowIntent enum (UNSPECIFIED / LOGIN / SIGNUP), flow_intent = 6 and accepted_document_ids = 7 on AuthenticateRequest, and ListConsentDocuments with its request, response and ConsentDocument messages.

Technical Details

Both fields land in one proton change so neither can claim the other's number.

flow_intent is an enum rather than a string because the set is closed, and its zero value gives backward compatibility for free — an existing client that sends nothing keeps today's create-or-get behaviour. The RFC considered a oneof carrying LoginIntent and SignupIntent with the ids on the signup arm only (alternative 8), which would make a signup-only field unrepresentable on a login rather than merely rejected. It settles on flat fields, since AuthenticateRequest.email is already a field only some strategies use, checked at runtime. Worth settling now: moving to a oneof later means deprecating field 6 and carrying both for a window.

AuthCallback gains neither field — both ride on the flow, keyed by the state the provider returns.

ListConsentDocuments mirrors ListAuthStrategies: unauthenticated, no database, four fields per document. It is separate from ListAuthStrategies because consent is not a strategy and AuthStrategy carries only name and params, so the documents would land in a params map every client has to parse.

Before merge: PROTON_COMMIT points at the proton PR branch head, not a main commit. It must be re-bumped to the squashed commit once raystack/proton#501 merges.

Test Plan

• make proto clean, generated files committed
• make lint — 0 issues
• make test — passes; the internal/store/postgres suites need a Docker daemon and were not run locally
• New symbols referenceable from Go (FlowIntent, AcceptedDocumentIds, ListConsentDocumentsRequest, ConsentDocument)

SQL Safety

Not applicable — no *_repository.go or goqu.* changes.

---

Supersedes #1908, which GitHub auto-closed when its head branch was renamed. Same commit, same content.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontier	Ready	Preview	Aug 30, 2026 6:56pm

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 7ec1c7a4-7bfb-40a5-85a5-229abb296016

📥 Commits

Reviewing files that changed from the base of the PR and between 88410ba and 8814cdf.

⛔ Files ignored due to path filters (2)

• proto/v1beta1/frontier.pb.go is excluded by !**/*.pb.go, !proto/**
• proto/v1beta1/frontierv1beta1connect/frontier.connect.go is excluded by !proto/**

📒 Files selected for processing (1)

• Makefile

Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review.

---

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Updated the underlying Proton version used when generating protobuf files.
  • Regenerated protobuf outputs may now reflect the newer Proton revision.

Walkthrough

The Makefile updates PROTON_COMMIT to select a different raystack/proton revision for protobuf generation through the proto target.

Changes

Proton version pin

Layer / File(s)	Summary
Update proto source pin Makefile	PROTON_COMMIT now references commit b4a0f2fe8eaef5626e1661e7e2c9faede89693b9.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Merge Risk: 🟡 Moderate · up to 8814c

This change adds generated consent and authentication API definitions, but the build currently pins them to an unmerged feature-branch revision. Update the pin to the final merged revision before merging to avoid relying on a non-final dependency state.

Suggested reviewers: whoabhisheksah

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coveralls]

Coverage Report for CI Build 33329454195

Coverage remained the same at 49.161%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	40516
Covered Lines:	19918
Line Coverage:	49.16%
Coverage Strength:	15.74 hits per line

---

💛 - Coveralls