ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
platform-dev
TenantAtlas/docs/ui-ux-enterprise-audit/page-reports/ui-099-rendered-review-report.md
ahmido f37056e1de feat: implement management report layout branded report themes (#437) 
Implemented management report layout branded report themes as requested.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #437
2026-06-08 03:35:20 +00:00

5.2 KiB
Raw Permalink Blame History

UI-099 Rendered Review Report

Field Value
Route /admin/review-packs/{reviewPack}/report
Source ReviewPackRenderedReportController
Area / scope Reviews / signed stakeholder report
Archetype Reviews
Design depth Strategic Surface
Repo truth repo-verified
Screenshot specs/366-management-report-layout-branded-report-themes-v1/artifacts/screenshots/01-customer-executive-report.png
Browser status Reached in the Pest browser on 2026-06-08 via Spec 366 fixtures and signed rendered-report URLs; verified management-first cover, text co-branding, KPI strip, profile-aware hierarchy, disclosure-proof badges, appendix hiding for customer_executive, technical/auditor appendix visibility, mobile-ish stacking, and print-toolbar hiding.

First Five Seconds

This route should answer four questions without exposing raw appendix files first:

  1. what can a stakeholder trust right now
  2. what evidence basis supports that conclusion
  3. what limitations or accepted risks still matter
  4. where can the operator return for review detail or artifact detail

Productization Review

  • Decision-first: the hero and guidance badges summarize stakeholder-safe posture before appendix detail.
  • Management-first: the cover includes prepared-by/prepared-for identity, generated-by metadata, governance status, evidence coverage, key-risk count, and open-decision count before detail sections.
  • Evidence-first: evidence basis, governance decisions, accepted risks, and technical details stay visible in bounded sections.
  • Audience-first: the route now states effective profile, requested profile, audience boundary, and source surface before appendix detail.
  • Truth-over-presentation: profile-specific filtering may hide appendix detail, but it may not hide readiness, evidence state, disclosure state, or non-certification copy.
  • Context: the route is signed, read-only, and anchored to one current review pack plus one released review.
  • Capability/RBAC awareness: the controller enforces tenant membership, review_pack.view, current-export authority, ready state, and expiry.
  • Customer/auditor safety: diagnostics remain appendix-level; customer-facing profiles fail closed or hide appendix detail when internal-only or PII-bearing scope remains.
  • Diagnostics/default hierarchy: HTML-first rendering leads, with ZIP download and print as secondary utilities.

Information Inventory

Default-visible content should include executive summary, effective profile, audience, requested profile, source metadata, evidence basis, limitations, key findings, accepted risks, governance decisions requiring awareness, next actions, disclosure-proof state badges, and non-certification disclosure. Technical details and the structured appendix remain profile-aware and may be hidden for customer-executive delivery.

Dangerous Actions

  • Dangerous or high-impact actions: none. This is a read-only route.
  • Current confirmation/evidence posture: toolbar actions only open review detail, review-pack detail, ZIP download, or browser print.
  • Target handling: keep the route signed and current-pack-only; do not widen it into a multi-review delivery surface or implicit PDF engine.

Spec 356 Follow-up

Spec 356 introduces this route as an HTML-first stakeholder handoff:

  • it is derived from the current review-pack contract rather than archive re-parsing
  • it keeps the ZIP as the structured appendix and downloadable artifact
  • it preserves owner-surface backlinks so operators can inspect the released review or pack detail without losing context

Spec 357 Follow-up

Spec 357 adds a bounded report-policy layer on the same route:

  • profile selection remains on the signed rendered-report URL seam and fails closed for unknown or placeholder profiles
  • the route now shows effective profile, audience, requested profile, and source surface metadata explicitly
  • disclosure proof is split into verified, assumed, missing, unknown, and not_applicable states instead of silently upgrading stored booleans to verified truth
  • appendix and technical-detail visibility now depend on the effective profile and current internal-only / PII boundary

Spec 366 Follow-up

Spec 366 productizes the same route as a management-ready report surface:

  • text-only co-branding is derived from existing workspace/environment truth; no logo upload, theme persistence, or editor UI was added
  • the KPI/decision strip is derived only from stored review-pack, environment-review, evidence, profile, and disclosure data; unsupported metrics remain omitted or marked not measured
  • profile layout modes now drive section prominence: executive/customer profiles lead with the management story, technical profiles pull evidence earlier, and auditor profiles make evidence/disclosure/appendix content more prominent
  • browser evidence now covers customer executive ready, customer executive limited, internal MSP, customer technical mobile-ish width, auditor appendix, and print-preview toolbar hiding

Target Direction

Keep this report calm, bounded, and print-friendly. Future follow-up should focus on browser evidence and hierarchy polish, not on a second rendering runtime or a broader delivery taxonomy.