ahmido
b7907bd69d
Implementing report profiles and disclosure policy as per spec 357. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #428
64 lines
4.1 KiB
Markdown
64 lines
4.1 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/357-report-profiles-disclosure-policy-v1/artifacts/screenshots/spec357-in-app-browser-customer-executive.png` |
|
|
| Browser status | Reached in the live in-app browser on 2026-06-05 via the Spec 351 review-output fixture plus a signed rendered-report URL; verified HTML-first chrome, effective profile metadata, disclosure-proof badges, and appendix hiding for `customer_executive`. |
|
|
|
|
## 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.
|
|
- 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
|
|
|
|
## 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.
|