Renata protected review packet planning

Review Packet Print Styles Planning

Protected, read-only planning for staff/privacy review packet print readability.

Purpose

This page plans low-risk print/readability structure for the staff/privacy review packet. It keeps the meeting packet concise, moves dense technical material to appendix/reference sections, and preserves all safety boundaries without generating any PDF or download.

Current Print/Export Boundary

Core Packet Sections

Appendix Sections

Print Style Goals

  • Keep the staff/privacy packet concise enough for a real review meeting.
  • Make no-go status visible near the top of every core packet section.
  • Make decision cards the primary print layout.
  • Keep wide tables, route inventories, diagnostics, and long boundaries as appendix/reference material.
  • Deduplicate blocked capability chips within each rendered list.
  • Improve line length, line height, and page-break behavior for long safety notes.
  • Keep safety content visible without making the main packet feel like a wall of text.
  • Avoid any PDF, export, download, approval, decision, or live workflow behavior.

Decision-Card Print Rules

  • Decision section cards remain before any wide table.
  • Cards must be labeled as the primary print layout.
  • Each card shows section, purpose, default values, approver role, evidence, blocking questions, and prohibited shortcut.
  • Avoid splitting a decision card across pages.
  • No card records approval, rejection, decision state, or staff action.

Table and Route-Inventory Print Rules

Operator Diagnostics Print Rules

  • Operator scan summary remains primary.
  • Navigation / Planning Map remains primary.
  • Full diagnostics are technical appendix/reference material.
  • Full source/recovery diagnostics stay outside the main staff/privacy packet unless requested.
  • Full protected workflow boundary note should wrap normally with readable line height.

Blocked-Chip Rules

  • Render blocked chips from a unique list per page section.
  • Do not merge unrelated blocked categories out of existence.
  • Avoid repeating the same chip in core and appendix unless the appendix is clearly secondary.
  • Keep no-go, not-generated, and not-recorded state visible near blocked lists.
  • Treat blocked chips as labels only, never as controls.

Boundary Note Rules

  • Use grouped boundary cards before long safety notes.
  • Keep long boundary notes readable with normal wrapping and line height.
  • Label full boundary text as appendix/reference material.
  • Do not remove safety content.
  • Do not repeat the same boundary text excessively in core packet sections.

Print Class Recommendations

Class Purpose Status
.review-packet-core Marks meeting-ready staff/privacy packet sections. static-css-only
.review-packet-appendix Marks reference-only sections such as route inventory, diagnostics, and wide tables. static-css-only
.print-card Applies card spacing and page-break rules for print. static-css-only
.print-avoid-break Keeps status boxes and decision cards together when possible. static-css-only
.print-secondary-reference Labels secondary appendix tables and references. static-css-only
.blocked-chip-list Marks deduped blocked capability chip groups. static-css-only
.print-boundary-note Improves wrapping and line height for long safety notes. static-css-only

Prohibited Print Content

real resident namesreal staff namesemailsCloudflare Access claimsJWTstokensraw identity headersreal draft bodiesprivate feedbackstaff review notesmedical detailsdiagnosis detailsmedication detailslegal case detailstrauma detailssubstance-use disclosures from residentsattendance dataparticipation dataparticipation analyticsscoring/ranking/compliance metricsresident performance metricsAI analysis of real draftsclinical claims

Required Gates Before Future PDF/Export Generation

  • staff/privacy approval
  • print/PDF scope approval
  • redaction policy approval
  • distribution policy approval
  • versioning policy approval
  • retention policy approval
  • audit policy approval
  • no-sensitive-content verification
  • no-identity-content verification
  • no-live-data verification

What Remains Blocked

no PDF filesno export filesno download artifactsno ZIP filesno approval recordingno decision storageno staff decisionsno database readsno database writesno active migrationsno protected API routesno protected live routesno live draft collectionno live submissionsno account storageno actor storageno identity captureno role assignmentno Morning Sheet placementno attendance trackingno participation trackingno participation analyticsno scoring/ranking/compliance metricsno OpenAI submission processing

Recommended Next Phase