Materiality assessment of the second screenshot pack

Executive conclusion

Yes, the second pack is materially informative.

The first pack showed 18 desktop screenshots. The second pack adds:

• 22 desktop screenshots
• 19 mobile screenshots
• the static mock website source
• JavaScript for subject, tenant-admin, and operator experiences
• encryption helpers
• AFF fixtures with packs, programs, an assembled window, rationale, lint results, and webhook metadata

This changes the system characterization from "a sparse UI prototype" to "a functional thin vertical slice with important domain behavior, but with unresolved trust, productization, and enterprise-operability gaps."

Findings that are strengthened

The following v1 conclusions remain correct and are now better evidenced:

• The role surfaces are separated but use technical "console" navigation.
• Tenant and capability context already exist and should be preserved.
• The organization graph is a real foundation for scoped administration and rater routing.
• The survey lifecycle is functional but too manual and implementation-oriented.
• The global operator surface is a real control-plane seed, but far from enterprise operations.
• Offline exports are broken and visibly unstyled.
• The public marketing, trust, pricing, documentation, and customer-help layers are absent.
• Results and PDP need a complete user-facing experience, even though deeper implementation primitives exist.

Findings that must be revised

1. Mobile behavior exists, but it is not production-grade

The v1 audit said mobile behavior was not demonstrated. The new pack demonstrates basic responsive stacking at a 390 px viewport.

The evidence changes the diagnosis:

• The full sidebar remains expanded above page content and consumes most of the first screen.
• Data tables overflow or are clipped rather than adapting to narrow layouts.
• Admin pages become very long and difficult to scan.
• The survey composer is not presented as a focused, sticky mobile interaction.
• Role and tenant metadata dominate the mobile header.

The plan should retain responsive hardening, but now base it on observed defects rather than absence of evidence.

2. The survey experience is more developed than previously visible

The source includes:

• assignment loading and selection
• one-step-at-a-time conversational delivery
• progress persistence and resume
• 1-to-7 scale buttons
• Not observed
• optional rephrasing and example nudges
• importance ranking and open questions
• browser-side envelope construction and sealed submission

This should be productized and made accessible rather than replaced with a generic form flow. The long-form 360 path also needs a different density and navigation model from daily or weekly AFF pulses.

The screenshot labelled "Survey assignment picker" does not actually show the picker. It shows the same survey introduction state as the rater screenshot, with a different signed-in user. This is a fixture/capture-contract defect.

3. PDP and results are not only a placeholder, but the visible fixture under-represents them

The screenshot still shows only period selection and "Load my surveys." The source, however, includes:

• competency result cards
• a full interactive report
• methodology/wiki pages
• verification actions
• score-weight recomputation
• export
• a structured PDP interview
• goal finalization and completion

The uplift should preserve useful domain behavior but remove developer-facing controls from the ordinary subject experience. In particular, a participant should not be able to casually alter manager/peer weights for a published report.

4. The AFF domain appears to exist behind the current UI

The supplied fixture contains nine packs:

• annual deep 360
• daily signal
• monthly leadership
• quarterly 360 bridge
• quarterly 360
• weekly execution
• customer leadership
• engineering leadership
• PDP follow-up

It also contains four active program examples, deterministic assembly seed and rationale, anchor and rotating items, a mandatory-overflow flag, lint output, and an exposure-ledger collection.

This validates the v1 architecture, but changes Prompt 12 from "design and build from scratch" to "audit, preserve invariants, fill gaps, and expose the domain through governed product UI."

The fixture does not prove that cooldown, full-coverage, PDP override, tenant overlay, or concurrency semantics are complete. Repository discovery and domain tests remain required.

Critical trust-boundary findings

These findings materially change sequencing.

A. The private key is sent to server endpoints

The client extracts the private JWK secret and sends private_key_b64 to multiple endpoints for results, wiki rendering, metric recomputation, verification, export, PDP operations, envelope resealing, and wrap-up generation.

One export path places the private key in a URL query string. Query strings can appear in server logs, browser history, proxies, telemetry, and error reports.

If this contract reflects the real product, the claim that the key stays in the browser is not accurate. If this is only mock code, it is still a dangerous interface to carry into production.

Evidence paths:

• capablio-mock-website/static/app.js
• capablio-mock-website/static/admin/admin.js
• capablio-mock-website/static/shared/crypto-ui.js

B. Some ratings are sent outside the sealed envelope

For Peer, Team, and Customer relationships, the client adds consented_scores to the submission body in addition to the encrypted envelope.

That may be an intentional aggregation design, but it conflicts with the survey copy that says ratings, comments, and rankings are encrypted and the server cannot read the answers. The product must state exactly which data is readable by the service, why, for how long, and under which anonymity controls.

C. User-facing privacy claims and code behavior are inconsistent

The UI says the key stays in the browser and the survey screenshot says the server stores only sealed envelopes and cannot read answers. The source contract suggests otherwise.

Until the architecture is validated and corrected, the following language must not be published as a marketing claim:

• zero knowledge
• keys never leave the browser
• the server cannot read ratings
• end-to-end encrypted feedback

A precise, narrower claim may be possible after threat-model and implementation review.

D. Additional security/product risks need explicit review

• Private key and bearer token are held in sessionStorage, so an XSS compromise can access them.
• Server-generated HTML is placed into unsandboxed iframe.srcdoc containers.
• Some people data is interpolated into innerHTML without visible escaping in the supplied source.
• The sign-in copy refers to receiving a private key file from HR, which implies a custody model that must be reconciled with subject-private claims.
• Manual sign-in URLs and full email bodies are rendered inline in long admin pages.

These are not proof of production vulnerabilities because the pack is a mock/static export. They are sufficient to require a blocking architecture and security review.

What does not change

The target direction remains sound:

• public marketing and trust site
• customer documentation and contextual help
• role-aware workspaces
• individual, manager, HR, tenant-admin, and platform-operator experiences
• adaptive question/packs/program administration
• campaign and rater operations
• interactive results and PDP
• entitlement, billing, integration, retention, audit, and support-access controls
• accessible responsive design
• tested offline and printable reports

The new evidence changes how the team should reach that target, not the target itself.