141 lines
5.7 KiB
Markdown
141 lines
5.7 KiB
Markdown
# Quickstart: Evidence Temporal Freshness & Review Publication Trust
|
|
|
|
## Goal
|
|
|
|
Validate that stale and partial evidence now degrade review and pack trust consistently across tenant-scoped detail pages and canonical summary pages, without changing routes, authorization semantics, or the current action inventory.
|
|
|
|
## Prerequisites
|
|
|
|
1. Start Sail if it is not already running.
|
|
2. Ensure the acting user is a valid workspace member and entitled to the target tenant or tenants.
|
|
3. Prepare representative fixtures for these cases:
|
|
- fresh and complete evidence snapshot
|
|
- stale evidence snapshot
|
|
- partial evidence snapshot or review with partial sections
|
|
- review with publication blockers
|
|
- ready review pack derived from a fresh review
|
|
- ready review pack derived from a stale or partial review
|
|
|
|
## Focused Automated Verification
|
|
|
|
Run the smallest existing test set that guards the affected surfaces first:
|
|
|
|
```bash
|
|
vendor/bin/sail artisan test --compact tests/Feature/Evidence/EvidenceSnapshotResourceTest.php
|
|
vendor/bin/sail artisan test --compact tests/Feature/TenantReview/TenantReviewLifecycleTest.php
|
|
vendor/bin/sail artisan test --compact tests/Feature/ReviewPack/ReviewPackResourceTest.php
|
|
vendor/bin/sail artisan test --compact tests/Feature/TenantReview/TenantReviewRegisterTest.php
|
|
vendor/bin/sail artisan test --compact tests/Feature/Evidence/EvidenceOverviewPageTest.php
|
|
```
|
|
|
|
If implementation extends shared truth helpers or run-detail truth copy, also run:
|
|
|
|
```bash
|
|
vendor/bin/sail artisan test --compact tests/Feature/Monitoring/ArtifactTruthRunDetailTest.php
|
|
```
|
|
|
|
## Manual Validation Pass
|
|
|
|
Use one fresh tenant and one stale or partial tenant, or equivalent seeded records in the same tenant.
|
|
|
|
### 1. Evidence snapshot detail trust
|
|
|
|
Open the tenant-scoped evidence snapshot detail page for a fresh snapshot and a stale snapshot.
|
|
|
|
Confirm that:
|
|
|
|
- both snapshots can still exist structurally,
|
|
- the stale snapshot is clearly shown as stale or cautionary,
|
|
- the fresh snapshot remains current,
|
|
- next-step guidance differs appropriately,
|
|
- and no raw JSON is required to understand why the stale snapshot is less trustworthy.
|
|
|
|
### 2. Review detail trust
|
|
|
|
Open tenant reviews anchored to:
|
|
|
|
- fresh complete evidence,
|
|
- stale evidence,
|
|
- partial evidence.
|
|
|
|
Confirm that:
|
|
|
|
- review freshness and publication readiness remain separate concepts,
|
|
- stale or partial reviews can still be useful internally,
|
|
- but they do not present the same calm publishable posture as fresh complete reviews,
|
|
- and next-step guidance points toward refresh or completion work when needed.
|
|
|
|
### 3. Review pack trust
|
|
|
|
Open the review pack list and review packs linked to the reviews above.
|
|
|
|
Confirm that:
|
|
|
|
- the review-pack list row already surfaces the same internal-only or publishable caveat before the operator opens detail or clicks `Download`,
|
|
- a pack generated from stale or partial evidence no longer looks calmer than the source review,
|
|
- any internal-only or cautionary posture is visible before download,
|
|
- and the pack points back to the source review when corrective action is needed.
|
|
|
|
### 4. Canonical summary alignment
|
|
|
|
Open:
|
|
|
|
- `/admin/evidence/overview`
|
|
- `/admin/reviews`
|
|
|
|
Confirm that:
|
|
|
|
- stale or partial artifacts are visible as such in the row summaries,
|
|
- the next-step language is directionally the same as on detail pages,
|
|
- a tenant with fresh evidence but no current review shows a next step that points toward review creation rather than implying review readiness already exists,
|
|
- and drill-through links preserve tenant context and do not reveal non-entitled tenants.
|
|
|
|
### 5. Ten-second scan validation
|
|
|
|
Timebox the first visible scan of one snapshot detail page, one tenant review detail page, and one review pack detail page to 10 seconds each.
|
|
|
|
Confirm that within that time an operator can tell:
|
|
|
|
- whether the artifact is fresh enough,
|
|
- whether it is only internally useful or publishable,
|
|
- and what the next action is.
|
|
|
|
### 6. Authorization and action non-regression
|
|
|
|
Confirm that:
|
|
|
|
- view-only users can still inspect truth but not execute manage actions,
|
|
- non-entitled users still receive deny-as-not-found behavior,
|
|
- existing destructive actions still require confirmation,
|
|
- touched refresh, publish, export, regenerate, or create-next-review handlers still dispatch the existing services and current `OperationRun` types where applicable,
|
|
- and no new actions or route changes were introduced as part of the hardening.
|
|
|
|
### 7. Shared list-surface review checklist
|
|
|
|
Review `docs/product/standards/list-surface-review-checklist.md` against the touched list and report surfaces.
|
|
|
|
Confirm that:
|
|
|
|
- `/admin/evidence/overview` and `/admin/reviews` still use row click as the primary inspect model,
|
|
- the tenant-scoped review-pack list keeps its row-level trust caveat visible before drill-through or download,
|
|
- existing inline safe shortcuts and header actions remain in their established positions,
|
|
- empty and filtered states still read clearly without hiding trust truth,
|
|
- and default-visible row summaries still surface freshness, publishable posture, and next step without requiring drill-through.
|
|
|
|
### 8. Performance and render guardrails
|
|
|
|
Confirm from the implementation diff and final surface behavior that:
|
|
|
|
- the touched detail and canonical surfaces still render from existing database-backed truth inputs,
|
|
- no new render-time external calls, background dispatches, or route changes were introduced,
|
|
- and canonical row truth remains lightweight enough for a normal operator scan without adding a new per-row derivation layer.
|
|
|
|
## Formatting And Final Verification
|
|
|
|
Before finalizing implementation work:
|
|
|
|
```bash
|
|
vendor/bin/sail bin pint --dirty --format agent
|
|
```
|
|
|
|
Then rerun the smallest affected test set. If the user wants broader confidence afterward, offer the full suite. |