Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Step 08 · Daily tracking views
Goal. Pending approvals, unanswered questions, interests awaiting action, overdue actions.
Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.
Prerequisites
Steps 04, 06 and 07 (records the view mirrors). Policy-independent scaffolding may start only after the overall start conditions are met (statement of work, ready-to-start kickoff checklist, funded DG-owned accounts, region and identity provider chosen). Decision-dependent behaviour and its final oracle stay blocked until DG chooses the applicable rule. Proposed defaults are recommendations, never prerequisites. Any provisional synthetic exploration must be labelled reversible and unapproved and is not accepted production behaviour. Blocked until DG decides: definitions of unanswered, pending and on-hold, and the overdue boundary (Q10).
Changes (illustrative, not a final schema)
Read views over authorised records; overdue boundary rule in the company’s business timezone.
Build items:
- Views mirroring authorised records
- Overdue boundary in company business timezone
- No cross-party leakage
Expected outputs and invariants
The view equals the underlying permitted records at the time boundary; no cross-party leakage.
Tests-first subset
Primary scenarios of this step (write these tests first): T30, T31.
Assertions to write first: T30, T31; cross-party visibility half of T29.
Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Pending decision; no oracle is invented.
Deferred integration checks
Scenarios whose primary step is this one but whose full variants need later components:
- None: the scenarios of this step can be completed here.
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- T29 — Cross-party visibility and daily-view effects are checked with 08.
- T39 — Core screens exist only after those steps; measured at step 10 on the integrated build.
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Exit evidence
View equals source records on the named build for the boundary cases agreed under Q10.
Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).
Navigation: Step-07-Outbox-Worker-Email ← this step → Step-09-DG-Membership-Tool-and-Metadata · Implementation-Order-Overview