Readout
Component Showcase

01Summary

The login exchange is stable; routing and the candidate unlock path still have gaps.

• OAuth provider token is exchanged at POST /auth/oauth; the backend verifies it and issues JWT access + refresh tokens.
• The response field nextScreen routes the user to either account_completion or overview.
• Guards: JwtAuthGuard validates the Bearer token, RolesGuard enforces the @AuthRoles() decorator.

A KPI row for a recap-style glance at the session:

Plain paragraphs, bold, italic, inline code, and links all render normally inside a section.

A third-level heading

1. Ordered lists work too.
2. As do plain bullet lists outside KeyPoints.

Blockquotes render with the theme's blockquote styling.

02What changed

Four moving parts shifted this session — one landed, two are watch-items, one is a hard blocker.

A lone callout with a custom label works standalone (no wrapper needed):

03How the session went

The order we uncovered things — login first, routing next, then the wall.

1. 09:15
   Traced the login exchange

   Read handleOAuth end to end and confirmed the access + refresh tokens are issued in one pass.
2. 10:40
   Found the routing gap

   nextScreen was being inferred on the client. Moved the decision server-side so the two tiers can never disagree.
3. 11:30
   Hit the credits blocker

   Candidate identity unlock reads a balance from the credits module, which isn't implemented — hard stop for that path.

04Flow

From provider token to landing screen, the backend decides everything in one pass.

flowchart TD
A[OAuth provider token] --> B[POST /auth/oauth]
B --> C{User exists?}
C -->|no| D[Create user]
C -->|yes| E[Issue JWT access + refresh]
D --> E
E --> F{nextScreen}
F -->|account_completion| G[Onboarding: role + profile]
F -->|overview| H[Main app]

For the request path itself, a mermaid flow is too flat — the html variant draws the layers each hop passes through, as swimlanes with labeled arrows:

05The change

Routing moved off the client: the resolver now returns nextScreen from the server.

The block also accepts a unified patch string (a full git diff, file headers and all) instead of oldText/newText, plus a split prop for side-by-side.

06Key code

Enums are const objects with inferred union types, never the enum keyword.

A plain fenced code block renders through the same .codewrap structure:

// enums are const objects with inferred union types, never the `enum` keyword
export const UserRoleEnum = {
  Candidate: "candidate",
  Company: "company",
} as const;

export type UserRole = (typeof UserRoleEnum)[keyof typeof UserRoleEnum];

The explicit <Code> component is equivalent, useful when the source contains characters awkward to fence:

curl -s -X POST https://api.example.com/auth/oauth \
-H "Content-Type: application/json" \
-d '{"provider":"google","token":"..."}'

07Touched files

What moved this session, nested by directory and tagged by change kind.

08Plan support

Artifact generation is gated to the workspace tiers — not the consumer plans.

A props-driven table with sortable headers, a live filter, and mark cells:

A markdown GFM table also works — pass it as children:

09Verification

What we actually checked before calling the login path stable.

• OAuth token exchange returns access + refresh tokens
• nextScreen is computed server-side, never inferred by the client
• Both guards run before the handler (verified with a forged Bearer token)
• Refresh-token rotation covered by an integration test
• Candidate unlock path wired to the credits module

A GFM task list gets re-tagged into the same checklist styling:

• Manual login round-trip against staging
• Load test the token endpoint at 100 rps

10Open questions

Three decisions still need an owner before the candidate path can ship.

1. Should refresh-token rotation invalidate the old token immediately or after a grace window?
2. Where does the credits balance get checked — guard or use-case?
3. Does account_completion need to be idempotent if the client retries?