Omair Saleh
056c47581f
Ships the second dashboard surface — a Pattern Library + Preview Theatre — that presents the 4-section PDP pilot batch back to Umar, compliance, and the board in an editorial format. Adds the full data layer that drives it: 5 source-backed per-SKU drafts at QA 100/100, 15 competitor PDP semantic extracts, PubMed evidence packs, EFSA claims library extension, JV brand voice guide, hand-curated product FAQs, and the Matrixify-ready CSV exports for Lewis. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.1 KiB
3.1 KiB
| 1 | Area | File | Check | Status | Evidence | NextAction | Guardrail |
|---|---|---|---|---|---|---|---|
| 2 | Compliance clinical blanks | data/content/compliance/clinical-blank-decisions.csv | All blank clinical claim rows have explicit approved_blank decisions with approver, date, rationale, and constraints acknowledgement. | blocked | 0/184 valid approved_blank rows; 184 still pending/invalid. | Compliance owner must fill the CSV or provide source-backed claims, then run bun run compliance:blank-decisions && bun run claims:sync-content. | Do not invent clinical claims or approve blanks without compliance input. |
| 3 | Product approval decisions | data/content/approvals/product-approval-decisions.csv | All products have human approve_all rows with all evidence/acknowledgement fields complete. | blocked | 0/190 valid approve_all rows; 190 still pending/invalid. | Umar/JV reviewer must complete the CSV, then run bun run approval:decisions && bun run approval:review-packet. | Do not self-approve products or treat generated drafts as human approval. |
| 4 | DataForSEO provider response | data/sources/provider-responses/dataforseo-reviews-endpoint-response.json | Support response proves the Reviews endpoint or replacement endpoint is available and retry-safe without leaking credentials. | blocked | responseReceived=false; endpointAvailable=false; replacementEndpoint=blank; retrySafe=false; credentialIncluded=false | Wait for DataForSEO support/docs clearance, fill the provider response tracker, then run bun run dataforseo:support-response. | Use the real pi-fresh-foundation credentials only in shell env; never paste or store secrets in the response tracker. |
| 5 | DataForSEO spend approval | data/sources/approvals/dataforseo-stage1-approval.json | Stage 1 approval file has approver, date, capped spend, exact target/run/depth caps, and hard-stop/no-secret/post-review acknowledgements. | blocked | approved=false; maxSpendApproved=0; targetCap=0/10; runLimit=0/1; depth=0/10; hardStop=false; noCredentialStorage=false | Project owner must explicitly fill the approval file after endpoint clearance, then run bun run source:spend-gate. | Approval alone must not override provider endpoint/support/docs blockers. |
| 6 | Staging import evidence | data/staging/import-logs | At least one real Matrixify/staging import log JSON exists outside templates. | blocked | 0 import log file(s) found. | Lewis/Euan must save real import logs under data/staging/import-logs/ and rerun bun run staging:evidence. | Queued templates are not import evidence. |
| 7 | Staging PDP spot checks | data/staging/pdp-checks | At least 5 real staging PDP spot-check JSON files exist outside the queue/templates. | blocked | 0/5 PDP check file(s) found. | Save real staging URL spot checks under data/staging/pdp-checks/ and rerun bun run staging:evidence. | Queue files under pdp-check-queue are assignments only, not completed checks. |
| 8 | Staging cutover approval | data/staging/cutover-approval.json | Cutover approval exists with explicit approval/signoff owner and timestamp. | blocked | approved=false; approver=blank; approvedAt=blank | Project owner/Lewis/Euan must sign the cutover approval after successful staging checks. | Do not treat handoff packet generation as cutover approval. |