stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Make consequential pull reviews passkey-native and auditable #509

New Issue
Closed
opened 2026-08-10 19:50:12 +00:00 by timmy · 0 comments
timmy commented 2026-08-10 19:50:12 +00:00
Owner
Copy Link

Evidence

The consequential review flow introduced by #507 accepts fresh token grants, but submit_pull_review is absent from the WebAuthn authorization schemas in src/main.py. Enrolled passkey users therefore fall back to the shared recovery token. Successful approve/request-changes mutations also do not appear in Security activity, unlike other consequential actions.

This does not duplicate #485 (passkeys for then-existing actions), #493 (initial security activity center), or #507 (fresh authorization for consequential reviews).

User flow

An enrolled operator approves or requests changes, completes device passkey verification bound to repository, pull request, head SHA, and decision, and sees the completed decision in Security activity without review text being persisted. Comment-only reviews remain frictionless. Recovery-token fallback remains available.

Acceptance criteria

  • Passkeys authorize approve/request-changes without prompting for the recovery token.
  • Authorization remains bound to session, repository, PR, head SHA, and decision.
  • Successful consequential reviews create a completed privacy-safe activity event.
  • Definite upstream failure discards the reservation; ambiguous outcomes remain pending.
  • Comment-only reviews create no security event and require no step-up.
  • Frontend renders approve/request-changes activity labels.
  • Behavioral tests cover passkey options/grants, journal lifecycle, privacy, and rendering.
## Evidence The consequential review flow introduced by #507 accepts fresh token grants, but `submit_pull_review` is absent from the WebAuthn authorization schemas in `src/main.py`. Enrolled passkey users therefore fall back to the shared recovery token. Successful approve/request-changes mutations also do not appear in Security activity, unlike other consequential actions. This does not duplicate #485 (passkeys for then-existing actions), #493 (initial security activity center), or #507 (fresh authorization for consequential reviews). ## User flow An enrolled operator approves or requests changes, completes device passkey verification bound to repository, pull request, head SHA, and decision, and sees the completed decision in Security activity without review text being persisted. Comment-only reviews remain frictionless. Recovery-token fallback remains available. ## Acceptance criteria - Passkeys authorize approve/request-changes without prompting for the recovery token. - Authorization remains bound to session, repository, PR, head SHA, and decision. - Successful consequential reviews create a completed privacy-safe activity event. - Definite upstream failure discards the reservation; ambiguous outcomes remain pending. - Comment-only reviews create no security event and require no step-up. - Frontend renders approve/request-changes activity labels. - Behavioral tests cover passkey options/grants, journal lifecycle, privacy, and rendering.
timmy self-assigned this 2026-08-10 19:50:12 +00:00
timmy closed this issue 2026-08-10 19:59:07 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
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: stackchain/stackchain-dashboard#509
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?