ahmido
f37056e1de
Implemented management report layout branded report themes as requested. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #437
74 lines
5.2 KiB
Markdown
74 lines
5.2 KiB
Markdown
# 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.
|