docs(roadmap): refine postbox and university BI paths

docs/CONNECTED_GOVERNANCE_PLATFORM_ROADMAP.md

@@ -870,11 +870,17 @@ can be tested.
    acting context through their owned contracts.
 3. Postbox accepts one durable message and attachment references and returns a
    delivery receipt; Campaign or another sender retains only typed references.
-4. An authorized function holder or delegate discovers and handles the message.
-5. Vacancy, ambiguity, expiry, or unavailable dependencies create visible safe
-   states rather than an implicit personal fallback.
-6. Reassignment changes future access without moving or rewriting the message;
-   delivery, access, and correction evidence remains connected.
+4. The Postbox remains addressable with zero, one, or several incumbents. During
+   vacancy it retains the delivery and visibly waits for a holder rather than
+   falling back to a personal account.
+5. An authorized function holder or time-bounded delegate receives a
+   device-bound grant for the policy-selected key epochs and handles the
+   message in an explicit represented-function context.
+6. Hand-over, revocation, or delegation expiry rotates/withdraws future key
+   access without claiming to erase plaintext already obtained. Content is
+   corrected or superseded by a linked version, never silently substituted.
+7. Delivery, vacancy, assignment, key access, delegation, action, and correction
+   evidence remains connected and distinguishes multiple incumbents.
 
 ### Story J: from specialist-system context to reproducible document
 
@@ -892,17 +898,25 @@ can be tested.
 
 ### Story K: from operational sources to trusted institutional indicator
 
-1. A governed catalog declares source owner, purpose, classification, schema,
-   extraction mode, reporting-date semantics, freshness, and credentials.
+1. A governed catalog declares read-only HIS and CampusOnline source owners,
+   purpose, classification, schema, extraction mode, freshness, and credentials
+   for the internal student-statistics subject area.
 2. An ingestion run stages a snapshot or watermark and records schema drift,
    validation findings, quarantine, and replay evidence.
-3. Versioned transformations map official keys, organizational hierarchies,
-   time dimensions, and measures into a documented analytical data product.
-4. Reporting serves policy-aware aggregates and permitted drill-down with the
-   calculation and lineage visible.
-5. Scheduled outputs, APIs, templates, or open-data handoffs use the same
+3. The product records reference date separately from extraction, acceptance,
+   and freeze dates: for example, a `1 September` state accepted on
+   `12 December` becomes the pinned semester snapshot. Corrections supersede it
+   visibly rather than rewriting it.
+4. In a graphical typed data-flow editor, versioned source, validation, mapping,
+   transformation, aggregation, and data-product nodes map official keys,
+   organizational hierarchies, time dimensions, and measures. The graph is
+   acyclic, previewable, testable, and carries lineage and pinned versions.
+5. Reporting serves the internal student-statistics product with policy-aware
+   aggregates and permitted drill-down. A list report can become a governed
+   source for a downstream template-backed publishable report.
+6. Scheduled outputs, APIs, templates, or open-data handoffs use the same
    product version rather than reimplementing the calculation.
-6. Package promotion reproduces the accepted report in development, test, and
+7. Package promotion reproduces the accepted reports in development, test, and
    production; corrections create new evidence rather than rewriting history.
 
 ### Story L: from generated artifact to approved collaborative record
@@ -1216,16 +1230,19 @@ user-story implementation remains paused.
    examples as the first pinned reference product.
 2. **Function-bound Postbox.** Implement Postbox and the
    Organizations–Identity–IDM–Access responsibility path; add Campaign delivery
-   to a function in an organizational unit and prove reassignment, delegation,
-   vacancy, retention, and audit behavior.
+   to a function in an organizational unit and prove vacancy, multiple
+   incumbents, reassignment, time-bounded delegation, key-epoch access,
+   retention, and audit behavior without personal ownership fallback.
 3. **Templates, Reports, and deep launch.** Build one data-backed document and
    one report through curated source contracts; open the task safely from a
    mock and then target HIS-style producer; preserve reproducible input,
    definition, output, and return-reference evidence.
-4. **Governed university BI path.** Starting from that concrete source, add one
-   scheduled staging, quality, transformation, semantic-product, lineage, and
-   policy-aware reporting path. Package it for repeatable promotion between
-   development, test, and production before generalizing dataflow.
+4. **Governed university BI path.** Start with read-only HIS/CampusOnline data
+   and an internal student-statistics product. Add scheduled staging, explicit
+   reference/freeze states, quality, a graphical typed transformation and
+   aggregation flow, semantic-product lineage, list-report chaining, and a
+   template-backed publishable report. Package it for repeatable promotion
+   before generalizing dataflow.
 5. **Collaborative document lifecycle.** Add DMS versions, review/approval,
    provider-neutral editing sessions, one collaborative editor, conflict and
    recovery behavior, and Records handoff over Files-backed content.
@@ -1252,15 +1269,16 @@ them; they do not block the product vision today.
   system, and which conflict/failure behavior is acceptable?
 - Which default participant privacy profiles should ship for scheduling,
   consultation, committee, and public participation?
-- What assurance, signature, federation, and E2EE levels are required for the
-   first trusted postbox deployment?
-- Which external IDM source and conflict, disable, delegation, and vacancy
-  policy should prove delivery to organizational responsibility?
+- Which history window, device assurance, organizational recovery/quorum,
+  rotation strength, signature, and federation profile is required for the
+  first trusted E2EE Postbox deployment?
+- Which external IDM source and conflict/disable policy should prove function
+  assignment and time-bounded delegation for organizational responsibility?
 - Which HIS or other specialist system should be the first deep-launch
   producer, and which callback/reference behavior can it support?
-- Which bounded university dataset, reporting date semantics, official keys,
-  accepted calculation, privacy profile, and drill-down level should define the
-  first analytical data product?
+- Which exact HIS/CampusOnline interfaces, student-statistics fields and
+  official keys, accepted calculation, freeze/correction policy, privacy
+  profile, and drill-down level should define the first analytical data product?
 - After the first source-to-report proof, do repeated source/dataflow contracts
   justify separate `govoplan-datasources` and `govoplan-dataflow` modules?
 - Which collaborative editor should be the first target, and should its first

docs/FRONTEND_LAYOUT_PRINCIPLES.md

@@ -23,6 +23,10 @@ Principles:
   panels, calendar list panels, or mailbox folder panels.
 - Keep collection navigation and collection-level actions close to the relevant
   pane header.
+- In a list-detail workspace such as Scheduling, keep related lists stacked in
+  the left pane and use the remaining main pane for view/create/edit. A single
+  Add action stays in the relevant list-pane header and opens the common main
+  editor; it does not create an additional menu or launcher.
 - Use bounded widths for navigation/list panes and let the main detail/content
   pane take the remaining space.
 - Keep filtering controls inside the pane they affect.
@@ -63,3 +67,11 @@ components directly.
 
 When a module-specific component becomes generally useful, promote it to core
 with a parameterized API before reusing it elsewhere.
+
+Non-self-explanatory fields use Core `FieldLabel`; documented omissions must
+name their accessible-label source. Explicit Discard and dirty navigation use
+the same Core unsaved-changes dialog. Table action sets retain unavailable row
+actions as disabled controls and reserve empty-state slots so Add remains
+aligned. Use central feedback/dialog components; `window.alert` is not an
+authorized product surface unless a product-owner-approved exception is first
+recorded in the Core decision ledger.

docs/INTERFACE_PATTERN_LANGUAGE.md

@@ -110,7 +110,10 @@ one.
   upper-right of the page heading. `Discard` comes before `Save …`, with the
   primary save action at the far right. Keep both controls in the same place
   across validation, loading, and saved states; guard unsaved work when the
-  user discards or navigates away.
+  user discards or navigates away. Explicit Discard and dirty in-application
+  navigation use the same central unsaved-changes dialog and registered
+  save/discard callbacks. A browser-controlled tab/window unload warning is the
+  only unavoidable different surface.
 - A page or panel has one visually primary action for its current state. Put
   secondary actions beside it. Separate destructive actions and name their real
   effect.
@@ -125,10 +128,16 @@ one.
 - Row actions in tables are icon-only controls in a stable rightmost action
   column. Order them by intent: inspect/open, edit, copy/duplicate,
   transfer/share/download, retry/restore, then remove/delete last. Omit actions
-  that do not apply without closing the gap or changing the relative order.
-  Every icon has a translated accessible name and matching tooltip. Separate
-  destructive actions visually, and use a named confirmation/review surface
-  when the consequence cannot be understood from the icon and row context.
+  only when they are structurally irrelevant to the entire table. An action
+  that belongs to the table but is unavailable for one row remains in its
+  normal position and is disabled; when the reason is not obvious from row
+  state, provide it through the central focusable disabled-action explanation.
+  It does not disappear. Every icon has a translated accessible name and matching tooltip.
+  Separate destructive actions visually, and use a named confirmation/review
+  surface when the consequence cannot be understood from the icon and row
+  context. In an empty editable table, place Add in the same left-most action
+  slot it occupies in a populated row and reserve the remaining slots so the
+  column geometry does not move.
 - Transient feedback should not shift the workspace. Durable failures, partial
   results, and blockers remain attached to the affected item or operation.
 
@@ -136,7 +145,12 @@ one.
 
 - Keep the selected object's identity and material status visible while its
   detail changes.
-- Short field help sits with the label. Longer "Why?", policy source,
+- Every non-self-explanatory field uses the central `FieldLabel`; short field
+  help sits with that label. A field without `FieldLabel` is an explicit
+  documented omission whose register names the field, rationale, and accessible
+  label source. Users may hide inline help markers with their persisted
+  interface preference; the visible/accessibility label and validation remain.
+  Longer "Why?", policy source,
   diagnostics, or provenance belongs in an expandable area, detail panel, or
   review step.
 - Empty space is not an error. An empty state states what is empty, why that can
@@ -199,6 +213,11 @@ Errors should identify the affected object and whether saved state or external
 effects may already exist. Never expose raw exception text as the only user
 message.
 
+Use the central dialog, confirmation, alert, and attached-error components for
+feedback. `window.alert` and the global `alert` function are prohibited. A
+genuinely unavoidable exception requires explicit product-owner authorization
+and an entry in the Core alert exception register before implementation.
+
 ## State Contract
 
 Every surface implements the states it can reach; it does not render a blank
@@ -355,11 +374,18 @@ and appearance.
 The Scheduling request surface is the first explicit reference composition for
 these rules:
 
-- The `Scheduling requests` page heading owns one `Add` action.
-- The left panel is shown for the creation view; it is not a second permanent
-  creation launcher beside the request list.
+- The persistent left panel contains `My scheduling requests` and `Scheduling
+  requests for me` as two stacked lists. It preserves list context like mailbox
+  folders but does not invent folders.
+- The left pane's `Scheduling requests` heading owns one short `Add` action. It
+  opens a new request in the right pane without an extra menu or duplicate
+  launcher.
+- The right main pane is the stable view/create/edit surface. Selecting a list
+  item opens its details; Add opens the same editor composition used for edit.
 - `Basic information`, `Calendar integration`, `Candidate slots`, and
   `Participants` are logical sections rendered with the central `Card`.
+- Privacy and participation behavior is a separate settings `Card`; dependent
+  number/password fields are disclosed by their central `ToggleSwitch`.
 - Candidate slots and participants are row collections rendered with the
   central `DataGrid`, including its stable action column.
 - Calendar integration is a boolean choice rendered with the central
@@ -368,6 +394,10 @@ these rules:
   ordered row actions. An address-parsing text area is not the ordinary editor;
   parsing pasted address lists belongs only in an explicitly designed bulk
   import flow.
+- View mode shows participation statistics and only state-valid quick actions.
+  Scheduling owns those current domain actions; a future Workflow module may
+  coordinate them through stable action contracts but is not a runtime
+  dependency of the surface.
 
 Apply the underlying placement and component rules to equivalent collection and
 create/edit surfaces throughout the system; the Scheduling domain names are an

docs/REFERENCE_JOURNEY_PROGRAM.md

@@ -183,6 +183,15 @@ repeatable.
 - Campaign consumes a generic delivery-target capability. It may target an
   email recipient or a function-bound Postbox without importing either
   module's internals.
+- A Postbox exists independently of its current holders. Vacancy, one
+  incumbent, several incumbents, and time-bounded delegation are valid states;
+  none turns the Postbox into a personal account.
+- The E2EE target uses per-content keys and function/postbox key epochs.
+  Assignment grants device-bound access to policy-selected history, while
+  hand-over, revocation, and delegation expiry rotate or withdraw future key
+  access without claiming to erase plaintext already obtained.
+- Content and signed manifests are immutable. Correction or replacement is a
+  linked new object/version, never silent substitution.
 
 ### Implementation slices
 
@@ -195,18 +204,23 @@ repeatable.
 3. Complete the Organizations–Identity–IDM–Access function-assignment and
    delegation path, including provenance and compatibility migration from
    legacy projections.
-4. Add Campaign delivery to a function-bound Postbox, file attachment
+4. Define the E2EE key-grant/epoch profile for vacancy, multiple incumbents,
+   hand-over, history access, time-bounded delegation, recovery, and audit.
+5. Add Campaign delivery to a function-bound Postbox, file attachment
    references, optional external-mail bridge, and notification attention
    signals through capabilities.
-5. Document reassignment, delegation, vacancy, expired assignment, unavailable
+6. Document reassignment, delegation, vacancy, expired assignment, unavailable
    optional module, retention, and future E2EE limitations honestly.
 
 ### Gate
 
 A campaign message can be delivered once to a function-bound Postbox; an
 authorized holder can act in an explicit context; a reassignment changes future
-access without moving or rewriting the message; vacancy and ambiguous context
-fail visibly; delivery, access, and later corrections remain auditable.
+access without moving or rewriting the message. A vacant Postbox remains
+addressable, retains the delivery, and visibly reports that no holder can
+decrypt or act until assignment; multiple incumbents and delegates receive
+independent key/access evidence. Delivery, key access, and later corrections
+remain auditable.
 
 ## Stage 3: Templates, reports, data sources, and deep launches
 
@@ -314,26 +328,51 @@ evidence, policy, and correction across independently installable modules.
    cost/resource limits, retention, backup/restore, promotion between systems,
    and reproducible release recipes.
 
+### Selected first subject-area direction
+
+- Start with read-only HIS and CampusOnline source profiles and produce the
+  institution's internal student-statistics data product plus reports derived
+  from it.
+- Model reference/effective date separately from extraction, validation, and
+  freeze dates. For example, a semester state may describe `1 September`, be
+  accepted and frozen on `12 December`, and remain the reproducible source for
+  that semester's official statistics. Later corrections create a superseding
+  version; they never rewrite the frozen state silently.
+- Make a graphical, typed data-flow editor the primary analyst surface. Nodes
+  represent governed sources/snapshots, validation, mapping, transformation,
+  aggregation, a list report/data product, template rendering, and publication.
+  The graph is versioned, testable, previewable, acyclic, and shows schema,
+  lineage, quality findings, policy, and pinned upstream versions.
+- A list report may become a governed source for another flow. This enables
+  `source + transformations/aggregation -> list report/data product -> template
+  -> publishable report` without copying the calculation or losing lineage.
+
 ### Implementation slices
 
-1. Select one bounded, read-only university dataset and one decision-relevant
-   report; define its legal/policy basis, source owner, official keys, time
-   semantics, and acceptance calculation.
+1. Bound the first HIS/CampusOnline student-statistics dataset and internal
+   report; define its legal/policy basis, source owners, official keys,
+   reference/freeze semantics, privacy level, and acceptance calculation.
 2. Generalize the Stage 3 source profile into catalog, ingestion-run, staged
    dataset, validation, transformation, lineage, and data-product contracts.
-3. Implement one scheduled incremental load with quarantine/replay and a fully
-   transparent transformation into an aggregate product.
-4. Serve the product through Reporting with policy-aware aggregate and
+3. Implement one scheduled load and explicit frozen-state lifecycle with
+   quarantine/replay and a fully transparent transformation into the internal
+   student-statistics product.
+4. Implement the first graphical typed flow editor over those proven nodes,
+   including version/diff, validation, preview, cycle prevention, and pinned
+   upstream product versions.
+5. Serve the product through Reporting with policy-aware aggregate and
    drill-down behavior; export reproducible evidence and calculation metadata.
-5. Package mappings, transformations, validations, reports, documentation, and
+6. Chain one list report as a source into a template-backed publishable report.
+7. Package mappings, transformations, validations, reports, documentation, and
    tests so they can be promoted from development to test to production.
 
 ### Gate
 
-One university data product can be rebuilt from a declared source snapshot or
-watermark, passes explicit quality tests, explains every measure and mapping,
-enforces disclosure policy, survives schema/freshness failures visibly, and
-produces the same accepted report across promoted environments.
+One internal student-statistics product can be rebuilt from declared HIS and/or
+CampusOnline snapshots, preserves its reference and freeze dates, passes
+explicit quality tests, explains every measure and mapping, enforces disclosure
+policy, survives schema/freshness failures visibly, and produces the same
+accepted list and template-backed report across promoted environments.
 
 ## Stage 5: Collaborative document editing
 
@@ -400,9 +439,11 @@ that first needs them:
 
 - first target SMTP/IMAP, file/directory, identity, and deployment profile;
 - first external IDM source and identity conflict/disable policy;
-- first trusted Postbox assurance/E2EE profile and external-mail bridge;
+- first trusted Postbox assurance/recovery/history-access profile and
+  external-mail bridge;
 - first HIS or other launch producer and callback/reference contract;
-- first university dataset, report, reporting date semantics, and permitted
+- exact HIS/CampusOnline source endpoints, student-statistics keys and accepted
+  calculation, freeze/correction policy, privacy profile, and permitted
   drill-down level;
 - whether repeated data-source and dataflow contracts justify separate
   `govoplan-datasources` and `govoplan-dataflow` modules after the Stage 3 proof;