Skip to content

WING-202 desktop and Cloud Run release

Plain-English version: ../plain/wing-202-release.md

This page records the 2026-07-27 release scope for both WorkWingman editions. Desktop remains the local-first Windows/Electron product. Cloud is the explicitly selected multi-tenant Server edition behind https://workwingman.ai.

Desktop release scope

Deterministic dual-grammar résumé import

The résumé pre-parser now recognizes two structural grammars without changing parse order based on probabilistic output:

  • Table grammar: work-history headers expressed as company | title cells, including cells in nested DOCX tables. Adjacent rows are reconstructed into the matching entry rather than flattened into unrelated text.
  • Heading grammar: role/company headings followed by date and description blocks.

Date normalization includes explicit EndDate values and month-name forms. The import review UI groups changes per work-history entry and presents each card as Title — Company — Dates, so approval applies to a coherent job rather than disconnected field rows.

LinkedIn details-page importer

The importer covers the live-verified LinkedIn profile details-page grammars for work, education, and skills. Extraction distinguishes actual skill names from endorsement and assessment metadata. Imported values retain provenance and confidence evidence so the review layer can expose the difference between directly observed content and weaker inferred structure.

“Live-verified” describes the surfaces checked during this release; it is not a promise that LinkedIn will keep its markup stable. Grammar failures must route to the fallback system rather than silently manufacturing profile data.

Fallback routing

Live application runs and profile imports share the same escalation vocabulary:

flowchart LR
    I["Instant<br/>deterministic automation or parser"] -->|success| R["Review / continue"]
    I -->|recoverable miss| W["Wingman Retry<br/>context-rich guided retry"]
    W -->|success| R
    W -->|unsupported or still uncertain| M["Manual Mode<br/>user-provided text or action"]
    M --> R
  • Instant is the deterministic first pass.
  • Wingman Retry preserves the failed operation's context and performs the guided recovery path.
  • Manual Mode is the explicit user-controlled fallback: paste/import text on the profile side, or complete the blocked action with guidance on the live-run side.

No tier may report success without a reviewable result. The WING-204 tutorial surfaces teach the same terminology used by the runtime.

Platform primer pack

The page-advisor prompt is primed before per-field advice with a general primer plus an ATS-specific primer selected for Greenhouse/iCIMS/Indeed/Lever/LinkedIn/UKG/USAJOBS/Workday-class surfaces covered by the pack. Primers capture operational knowledge such as navigation and field conventions. The deterministic driver retains page authority; the advisor returns advice and does not gain an independent click/type/submit capability.

Résumé Labs evaluation harness

The labs project supplies synthetic résumé families and a parser coverage scorecard. Synthetic families make regression expectations reproducible; a real-corpus smoke lane checks whether those expectations transfer to representative documents.

Current limitation, recorded without inflating the score: PDF extraction produces zero work-history entries for the present real-world PDF samples. The parser must surface that empty outcome rather than claim a successful import. The LLM extraction fallback and WING-203 own the remaining gap.

Cloud (Server edition) release scope

Tenant model

Invitation redemption selects an audience policy (team-test or yc-reviewer) and mints a private, opaque tenant/workspace per redemption. Audience is resolved from the authenticated server session, not a client flag. Firestore is the durable tenant store for invitation-redemption audit state, sessions, tenant identifiers, and the bounded tenant data admitted by the private-pilot routes.

The tenant boundary is fail-closed: repositories and routes without end-to-end tenant scoping remain unavailable in Server edition. Invitation hashes, session authentication material, and configured service secrets are injected through Secret Manager rather than source or image layers.

HTTPS and runtime topology

Cloud DNS points workwingman.ai to the Google Cloud external Application Load Balancer. A Google-managed certificate terminates HTTPS. The load balancer routes through serverless network endpoint groups to Cloud Run; application-level invitation, session, CSRF, and tenant checks remain the end-user authorization boundary.

flowchart TD
    DNS["Cloud DNS<br/>workwingman.ai"] --> LB["External HTTPS load balancer<br/>Google-managed certificate"]
    LB --> TEAM["Cloud Run service: ww-team<br/>rolling approved releases"]
    LB --> YC["Cloud Run service: ww-yc<br/>frozen image digest"]
    TEAM --> FS["Firestore<br/>tenant/session/audit store"]
    YC --> FS
    TEAM --> SM["Secret Manager<br/>invite hashes, session material, provider keys"]
    YC --> SM

LLM key resolution

Provider key resolution follows an explicit two-level policy:

  1. resolve a suitable BYOK credential from the protected vault;
  2. if no suitable BYOK credential is available, resolve the approved house key from server configuration backed by Secret Manager.

The fallback is credential resolution, not authentication fallback: browser requests still require their tenant session and CSRF boundary. Neither source may leak a key into client payloads, logs, container history, or release evidence.

Rolling team service and frozen YC service

  • ww-team tracks subsequent approved release digests and is the rolling internal service.
  • ww-yc is deployed from the same final gated digest selected for the YC release, then held immutable for the review window.

The YC freeze procedure is:

  1. complete the release gate and identify the final container image by immutable digest;
  2. deploy ww-team and ww-yc from that exact digest;
  3. verify HTTPS, invitation redemption, audience separation, and cross-tenant isolation;
  4. record the source commit/tree, image digest, deployment revision, and verification receipts;
  5. stop redeploying ww-yc; send later approved changes only to ww-team.

A change to YC scope requires a new reviewed digest and a new explicit freeze record. A mutable tag alone is never sufficient evidence of what YC received.

Traceability