# Investigation: Inspiredesign Pinterest Diagnostic-Only Harvest

## Summary
Confirmed. The diagnostic-only output had two causes: runtime capture waited for full Pinterest `load` during canonical pin-media setup before media extraction, and the user-installed `opendevbrowser-best-practices` copy was stale enough for agents to miss current Pinterest recovery and authority checks. The minimal runtime fix changes only canonical Pinterest pin-media setup navigation to `domcontentloaded`; readiness remains strict and the final real workflow produced `productSuccess=true`, `artifactAuthority=product_ready`, `evidenceAuthority=pin_media_ready`, and one manifest-backed `pinMediaIndex` entry.

## Symptoms
- Real `opendevbrowser inspiredesign harvest` found five Pinterest pin URLs.
- No manifest-backed pin media was captured.
- Pin media entries failed as `search_shell` or `chrome_only`.
- User asks whether agents lack the right OpenDevBrowser workflow details, including whether `opendevbrowser-best-practices` is insufficient.

## Background / Prior Research
- Memory registry points to earlier Pinterest pin-media and Inspiredesign readiness work. Current behavior must be verified from source and a fresh bundle before relying on prior conclusions.
- `opendevbrowser-best-practices` asset validation passed locally: 12 referenced files present and 4 JSON templates parsed.

## Investigator Findings

### Runtime Capture And Readiness

- Runtime cause: explicit Pinterest pin URLs enter the primary pin-media capture path, but setup performs a full Pinterest navigation with `waitUntil="load"` inside a capped setup-step budget before DOM media extraction. Current constants cap total pin-media capture at 90s, warmup at 30s, setup steps at 10s, and network idle at 5s (`src/inspiredesign/capture.ts:154-158`). The setup budget is further clamped to the remaining budget divided by 3 (`src/inspiredesign/capture.ts:932-935`). The failing step is `manager.goto(session.sessionId, url, "load", gotoTimeoutMs)` wrapped as `"primary media capture navigation"` (`src/inspiredesign/capture.ts:1033-1038`), reached by explicit pin capture through `launchPrimaryCaptureSession` (`src/inspiredesign/capture.ts:1154-1159`). Setup errors are converted to failed pin-media metadata with `primary_capture_setup_failed` (`src/inspiredesign/capture.ts:1161-1168`). Browser navigation defaults to `load` and 30s (`src/browser/browser-manager.ts:2393-2398`), managed mode delegates to `navigatePage` (`src/browser/browser-manager.ts:2585-2588`), and `navigatePage` is a direct `page.goto(url, { waitUntil, timeout })` for non-data URLs (`src/browser/browser-manager.ts:5904-5912`). Therefore the observed failure is before candidate extraction, not after media candidate selection.
- Baseline bundle evidence: `.tmp/ulw-evidence/logs/baseline-20260702T134311.meta.json` has `exitCode: 0`, while `.tmp/ulw-evidence/logs/baseline-20260702T134311.stdout.json` has `success: true`, `ready: false`, `productSuccess: false`, `artifactAuthority: "diagnostic_only"`, `evidenceAuthority: "diagnostic_only"`, `rankedReferenceCount: 0`, and `pinMediaReadyReferenceCount: 0`. In `.tmp/ulw-evidence/baseline-output/inspiredesign/9f48a8d4-f403-4078-a1d7-9e72ce302223/pin-media-evidence.json`, both explicit pins have `status: "failed"`, `authority: "diagnostic"`, `warnings: ["primary_capture_setup_failed"]`, and `failure: "Deep capture primary media capture navigation exceeded timeout budget."` The first pin `39828777963624871` has `pinterestPageQuality: "search_shell"`; the second pin `204491639340909360` has `pinterestPageQuality: "chrome_only"`. Both also have rejection reasons `missing_artifact_path`, `invalid_sha256`, `missing_bytes`, `unsupported_content_type`, `missing_dimensions`, `missing_source_url`, `media_url_not_first_party`, and `page_quality_not_pin_media`. `.tmp/ulw-evidence/baseline-output/inspiredesign/9f48a8d4-f403-4078-a1d7-9e72ce302223/pin-media-index.json` is `{ "pinMediaIndex": [] }`, and `ranked-references.json` rejects both refs with `interface_chrome_shell` and `search_shell_without_media_signals`.
- Browser-native discovery is not the root failure for this explicit-URL baseline. It allows only canonical Pinterest pin URLs (`src/providers/browser-native-discovery.ts:455-463`) and treats `search_shell` as recoverable only when the record has search-result context plus rendered pin-link evidence (`src/providers/browser-native-discovery.ts:384-387`, `src/providers/browser-native-discovery.ts:426-428`, `src/providers/browser-native-discovery.ts:444-452`). Accepted discovery records preserve source page quality in attributes (`src/providers/browser-native-discovery.ts:759-769`). The baseline `discovery-diagnostics.json` shows `requested: false`, `acceptedUrlCount: 0`, and no failures, while `evidence.json` records the two explicit URLs and two attempted references, so discovery did not drop the pins.
- The `search_shell` and `chrome_only` labels are explained by Pinterest page classification. Page quality values include `pin_media`, `pin_grid_media`, `search_shell`, `chrome_only`, `login_challenge`, `unknown`, and `invalid` (`src/inspiredesign/pinterest-media-classification.ts:14-21`). Search-shell markers include autocomplete/search-result text, while chrome markers include `your profile`, `updates`, `messages`, `settings & support`, and `accounts` (`src/inspiredesign/pinterest-media-classification.ts:67-75`). Chrome-only URL paths and chrome markers take precedence unless rendered result signals are present (`src/inspiredesign/pinterest-media-classification.ts:153-166`), and source extraction is blocked for `search_shell`, `chrome_only`, and `login_challenge` (`src/inspiredesign/pinterest-media-classification.ts:251-255`). The second baseline pin title is `Your profile` in `evidence.json`, matching the `chrome_only` classification path.
- Readiness correctly stays diagnostic-only because no byte-backed, manifest-backed pin-media authority exists. Workflow finalization filters `packet.pinMediaIndex` to entries whose paths were actually persisted (`src/providers/workflows.ts:6981-6983`), counts pin-media authority from that manifest-backed index (`src/providers/workflows.ts:7020-7028`), then passes those counts into product readiness (`src/providers/workflows.ts:7053-7065`). Product readiness requires coherent counts, at least one ranked reference, product-ready evidence authority, and, when Pinterest evidence is required, `pinMediaReadyReferenceCount === pinterestCount` (`src/inspiredesign/product-readiness.ts:1149-1172`); failed success sets `artifactAuthority: "diagnostic_only"` and diagnostic evidence authority (`src/inspiredesign/product-readiness.ts:1111-1114`, `src/inspiredesign/product-readiness.ts:1180-1187`). Pin-media authority requires canonical source and first-party media plus valid path/hash/bytes/dimensions/content type (`src/inspiredesign/pinterest-pin-media-evidence.ts:724-735`), rejects non-`pin_media` page quality (`src/inspiredesign/pinterest-pin-media-evidence.ts:861-865`), returns `diagnostic` when any rejection exists (`src/inspiredesign/pinterest-pin-media-evidence.ts:929-939`), redacts diagnostic path/hash/bytes/dimensions/content type (`src/inspiredesign/pinterest-pin-media-evidence.ts:1041-1052`), and builds `pin-media-index.json` only for `authority === "design_evidence"` with all required persisted fields (`src/inspiredesign/pinterest-pin-media-evidence.ts:1079-1084`). Renderer gating also requires every Pinterest reference to have pin-media-ready authority before Canvas continuation (`src/providers/renderer.ts:400-407`).
- Test coverage supports this behavior. Search-shell pin-media evidence remains diagnostic and does not build an index entry (`tests/inspiredesign-pinterest-pin-media-evidence.test.ts:1177-1179`). Valid pin-media index data yields `productSuccess: true` and `evidenceAuthority: "pin_media_ready"` (`tests/inspiredesign-product-readiness.test.ts:1188-1198`), but no ranked references plus an index remains diagnostic (`tests/inspiredesign-product-readiness.test.ts:1200-1213`), and `pinMediaEvidence` without authoritative `pinMediaIndex` keeps `pinMediaReadyReferenceCount: 0` and `evidenceAuthority: "diagnostic_only"` (`tests/inspiredesign-product-readiness.test.ts:1281-1298`). Browser capture has a regression for target-scoped Pinterest pin-media timeout behind stale target work (`tests/browser-manager.test.ts:4842-4860`). Browser-native discovery tests confirm rendered `search_shell` links can be extracted while preserving `pinterestSourcePageQuality: "search_shell"` diagnostics (`tests/pinterest-guidance-recipe.test.ts:628-676`).
- Eliminated hypotheses: not daemon or transport failure, because the baseline command exited 0 and returned `success: true`; not missing explicit URLs, because `evidence.json` records both attempted pin URLs; not browser-native search discovery, because baseline discovery was not requested; not media-analysis authority, because `media-analysis.json` has empty `references` and explicitly says it cannot satisfy product readiness; not a readiness-gate bug, because source and tests require manifest-backed, byte-backed `pin_media` authority and correctly reject diagnostic evidence.
- Minimal fix recommendation: keep readiness strict. Fix the primary Pinterest pin capture setup so canonical pin-media capture does not depend on full `load` completion of Pinterest chrome before DOM/CDP media extraction. Prefer a canonical-pin-specific setup path using `domcontentloaded` or bounded early extraction after navigation commit, with a regression that reproduces a never-firing `load` on a Pinterest pin and still persists first-party media bytes into `pin-media-index.json` only when page quality is `pin_media` and provenance fields are valid. Also add artifact-level regression coverage for the baseline shape: explicit pins with navigation timeout must remain diagnostic-only, while a slow-loading but media-present pin becomes `pin_media_ready` through a non-empty manifest-backed index.

### Skill Guidance And Agent Instructions

**Finding:** Guidance is sufficient after syncing the installed copy, but the machine-local installed copy was stale at investigation start and could cause agents to stop at diagnostic-only output.
**Evidence:** The repo skill is version `2.6.0` and includes Inspiredesign Pinterest examples and explicit recovery commands, daemon preflight, artifact authority inspection, and `pin-media-index.json` authority checks. The installed user copy has now been synced to version `2.6.0`; both repo and installed validators pass and the guidance evidence records daemon preflight, explicit URL recovery, product authority, and pin-media index checks.
**Docs cross-check:** `docs/CLI.md` covers daemon preflight at `docs/CLI.md:322-324` and `docs/CLI.md:342-346`, explicit Pinterest URL recovery at `docs/CLI.md:593-595`, product artifact emission and authority inspection at `docs/CLI.md:598-604`, and `success:true` or `ok:true` versus `productSuccess` at `docs/CLI.md:611-614`. `docs/SURFACE_REFERENCE.md` now repeats daemon fingerprint preflight in the Inspiredesign subsection at `docs/SURFACE_REFERENCE.md:580`, covers explicit Pinterest URL recovery and pin-media authority at `docs/SURFACE_REFERENCE.md:581-586`, response keys including `productSuccess` at `docs/SURFACE_REFERENCE.md:593`, and strict artifact inspection plus `pin-media-index.json` authority at `docs/SURFACE_REFERENCE.md:595-596`.
**Conclusion:** Agents using current repo or installed guidance should now know to preflight the daemon, recover from diagnostic query harvests with one canonical Pinterest URL per run, inspect artifact authorities instead of wrapper success, gate on `productSuccess`, and treat `pin-media-index.json` as the only Pinterest pin-media authority.
**Minimal fix completed:** synced the current repo `opendevbrowser-best-practices` pack into the user skill location with a backup, strengthened validation for installed skill copies from repo cwd, and added a daemon fingerprint preflight reminder to the Inspiredesign harvest note in `docs/SURFACE_REFERENCE.md`.

## Investigation Log

### Bootstrap - Scope And Hypotheses
**Hypothesis:** The issue could be runtime misclassification/capture, daemon/build drift, authenticated Pinterest state, or incomplete agent guidance.
**Findings:** RepoPrompt window `2` is bound to `/Users/bishopdotun/Documents/DevProjects/opendevbrowser`. Git status has unrelated untracked investigation and review docs only.
**Evidence:** `rpce-cli -w 2 -e 'tree --type roots'`; `git status --short`; `.omo/ulw-loop/019f241a-f8ad-79f1-842e-91d3fe1bb026/goals.json`.
**Conclusion:** Investigation can proceed in this checkout without touching unrelated files.

### Baseline - Real Pinterest Harvest
**Hypothesis:** The reported diagnostic-only behavior reproduces with the current daemon and explicit Pinterest pin URLs.
**Findings:** Reproduced. The command exited `0`, but the workflow was not product-ready: `ready=false`, `productSuccess=false`, `artifactAuthority=diagnostic_only`, `evidenceAuthority=diagnostic_only`, `pin-media-index.json` was empty, and both explicit pins failed primary media capture with navigation timeout.
**Evidence:** `.tmp/ulw-evidence/logs/baseline-20260702T134311.meta.json`; `.tmp/ulw-evidence/logs/baseline-20260702T134311.stdout.json`; `.tmp/ulw-evidence/baseline-output/inspiredesign/9f48a8d4-f403-4078-a1d7-9e72ce302223/pin-media-index.json`; `.tmp/ulw-evidence/baseline-output/inspiredesign/9f48a8d4-f403-4078-a1d7-9e72ce302223/pin-media-evidence.json`.
**Conclusion:** The issue is not daemon fingerprint drift or a missing extension handshake in this run. It is a product-readiness failure behind transport success.

### Final Verification - Real Pinterest Harvest
**Hypothesis:** Canonical Pinterest pin-media setup can proceed without waiting for full page `load`, while readiness still requires manifest-backed first-party bytes.
**Findings:** Confirmed. The final explicit Pinterest harvest exited `0` and returned `success=true`, `ready=true`, `productSuccess=true`, `artifactAuthority=product_ready`, `evidenceAuthority=pin_media_ready`, `rankedReferenceCount=1`, and `pinMediaReadyReferenceCount=1`. `ranked-references.json.references` contains one accepted reference for pin `204491639340909360`. `pin-media-index.json.pinMediaIndex` contains one `authority: "design_evidence"` item at `pin-media-evidence/c5a50f0cc49b/poster.jpg`, `30203` bytes, `576x1024`, `image/jpeg`, with first-party provenance true. The first explicit pin remained rejected, which is acceptable because the second pin supplied complete pin-media authority.
**Evidence:** `.tmp/ulw-evidence/inspiredesign-pinterest-final-workflow.json`; `.tmp/ulw-evidence/final-output/inspiredesign/d845841b-04c9-4bd9-9eb9-24a3a3b7e8c5/ranked-references.json`; `.tmp/ulw-evidence/final-output/inspiredesign/d845841b-04c9-4bd9-9eb9-24a3a3b7e8c5/pin-media-index.json`; `.tmp/ulw-evidence/final-output/inspiredesign/d845841b-04c9-4bd9-9eb9-24a3a3b7e8c5/pin-media-evidence.json`.
**Conclusion:** The fix resolves the observed product-readiness failure for at least one real canonical Pinterest pin without weakening diagnostic gates for failed pins.

## Root Cause
Confirmed root cause: the canonical Pinterest pin-media capture path did the right authority work after setup, but setup itself waited for full Pinterest page `load` inside a tight setup budget. Pinterest authenticated pin pages can keep chrome, recommendations, or media loading active long enough that `load` never arrives within that setup budget. The workflow then emitted `primary_capture_setup_failed`, never reached byte-backed media extraction, and correctly stayed diagnostic-only because `pin-media-index.json` was empty.

Confirmed contributing issue: the machine-local installed `opendevbrowser-best-practices` skill copy was stale at investigation start, so agents using that copy could miss the required daemon preflight, explicit canonical URL recovery path, and artifact authority checks.

## Recommendations
1. Keep the runtime fix narrow: use `domcontentloaded` only for canonical Pinterest pin-media warmup and primary setup, while leaving visual/deep capture and non-canonical setup behavior unchanged.
2. Keep readiness strict: do not let screenshot, screencast, remote media URLs, or `media-analysis.json` replace manifest-backed `pin-media-index.json` authority.
3. Keep skill guidance synchronized across repo and installed copies so agents know to inspect `productSuccess`, `artifactAuthority`, `evidenceAuthority`, `ranked-references.json`, and `pin-media-index.json` before continuing to Canvas or implementation.
4. Treat source checkout daemon runs and installed daemon state separately. Use a source-built daemon only for validating uncommitted fixes, then restore the installed LaunchAgent before closeout.

## Preventive Measures
- Inspect artifact authority fields and saved pin-media artifacts before treating CLI transport success as product-ready output.
- Add schema-aware evidence parsers for Inspiredesign bundles: `ranked-references.json.references`, `pin-media-index.json.pinMediaIndex`, and `bundle-manifest.json.files`.
- Validate installed skill copies from the repo cwd when guidance changes, not only the repo-local pack.
