ahmido
439248ba15
Implements the 074 verification checklist framework. Highlights: - Versioned verification report contract stored in operation_runs.context.verification_report (DB-only viewer). - Strict sanitizer/redaction (evidence pointers only; no tokens/headers/payloads) + schema validation. - Centralized BADGE-001 semantics for check status, severity, and overall report outcome. - Deterministic start (dedupe while active) via shared StartVerification service; capability-first authorization (non-member 404, member missing capability 403). - Completion audit event (verification.completed) with redacted metadata. - Integrations: OperationRun detail viewer, onboarding wizard verification step, provider connection start surfaces. Tests: - vendor/bin/sail artisan test --compact tests/Feature/Verification tests/Unit/Badges/VerificationBadgesTest.php - vendor/bin/sail bin pint --dirty Co-authored-by: Ahmed Darrazi <ahmeddarrazi@MacBookPro.fritz.box> Reviewed-on: #89
62 lines
2.0 KiB
Markdown
62 lines
2.0 KiB
Markdown
# Data Model: Verification Checklist Framework (074)
|
|
|
|
## Overview
|
|
|
|
This feature introduces a *versioned verification report document* attached to an existing `OperationRun`.
|
|
No new database tables are required for v1.
|
|
|
|
## Existing Entities Used
|
|
|
|
### OperationRun (`operation_runs`)
|
|
|
|
Selected fields:
|
|
- `id`
|
|
- `tenant_id`
|
|
- `user_id`
|
|
- `type` (used as the verification flow identifier)
|
|
- `status` (`queued` | `running` | `completed`)
|
|
- `outcome` (`pending` | `succeeded` | `failed`)
|
|
- `summary_counts` (JSONB)
|
|
- `failure_summary` (JSONB)
|
|
- `context` (JSONB)
|
|
- `started_at`, `completed_at`
|
|
|
|
Idempotency:
|
|
- DB-enforced dedupe for active runs via partial unique index on `(tenant_id, run_identity_hash)` where `status IN ('queued','running')`.
|
|
|
|
## New Logical Data (stored inside OperationRun context)
|
|
|
|
### VerificationReport (`operation_runs.context.verification_report`)
|
|
|
|
- Stored as JSON in `context` under `verification_report`.
|
|
- Versioned by `schema_version`.
|
|
- Rendered DB-only (no external calls during view).
|
|
|
|
High-level shape (see `contracts/verification-report.schema.json` for the canonical contract):
|
|
- `schema_version`
|
|
- `flow` (identifier; for v1 this can align with `operation_runs.type`)
|
|
- `identity` (scope identifiers such as `tenant_id`, `provider_connection_id`, etc.)
|
|
- `generated_at`
|
|
- `summary` (counts, overall state)
|
|
- `checks[]` (check results)
|
|
|
|
### CheckResult (within `checks[]`)
|
|
|
|
- `key`, `title`
|
|
- `status`: `pass|fail|warn|skip|running`
|
|
- `severity`: `info|low|medium|high|critical`
|
|
- `blocking`: boolean
|
|
- `reason_code`
|
|
- `message`
|
|
- `evidence[]`: safe pointers only
|
|
- `next_steps[]`: links only in v1
|
|
|
|
## Audit
|
|
|
|
Verification start and completion are recorded in `audit_logs` using stable `action` identifiers (via `App\Support\Audit\AuditActionId`). Metadata is minimal and sanitized.
|
|
|
|
## Notes / Constraints
|
|
|
|
- Viewer must be DB-only: rendering the report must not dispatch jobs or perform HTTP.
|
|
- Evidence must be redacted/safe: no secrets/tokens/payload dumps in stored or rendered report.
|