claudeandClaude Opus 4.8
1d3e52a5ed
Some HPE pages carry information only inside an image. The Morpheus release schedule / support-lifecycle matrix (sf000111242en_us) is the case that surfaced this: the entire "which version ships when, when a stream hits Maintenance/EOL" table is a JPEG, so html_to_md dropped every value and retrieval could never answer "when does 8.x.x reach end of life". New scrape/vision.py (opt-in via VISION_OCR) transcribes qualifying images with a local Ollama vision model and appends a labeled markdown block to the page so the text is chunked, embedded and retrieved. Model/prompt chosen against ground truth on the matrix (14x4 cells): - qwen2.5vl:7b + a bare "transcribe the table" prompt: 55-56/56, ~18s, GPU-resident, and prompt-ROBUST (accurate without hand-tuning). - gemma3:12b needs an exact "read row by row, keep cells aligned" prompt or it shifts a column by one row; qwen2.5vl:32b is no more accurate and 5x slower (CPU spill). Both documented in the code. - Note: self-consistency (2 samples must agree) only catches RANDOM flakiness — a wrong read is stable across seeds — so every block also ships a "verify against the source image" caveat. Reliability/cost: - content-hash cache in corpus/.vision-cache/ (committed) — each unique image OCR'd once ever, shared across version bundles. - VISION_MAX_NEW bounds NEW OCRs per run so the first pass can't balloon into hours; the cache fills incrementally. Deferred count is logged. - every failure path degrades to the pre-vision behavior; never blocks the scrape. Also: - add the morpheus_release_schedule bundle (sf single-doc) + 2 eval golden queries for it. - fetch_single_doc: title falls back to the bundle title (not docId) when a page has no <h1> (sf solution articles). - Pillow in requirements-vision.txt (scrape-only; kept out of the server image), installed + VISION_* wired into refresh.yml. Verified locally: matrix transcribes to the exact 14-row table; second run is a cache hit (ocr=0). Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01LFowQzJu7k97QLCRDSAeh1
scrape/
Product-specific. You implement this for each product. The template gives you the contract; the extraction logic depends on the upstream doc portal.
See PLAN.md Phase 1 for the corpus layout the rest of the pipeline
expects.
Product context — HPE Morpheus Enterprise Software
This repo is for HPE Morpheus Enterprise, the full cloud-management
platform. It is a different SKU from HPE Morpheus VM Essentials
(HVM), which has its own MCP at ../hvm-docs/. Don't ingest HVM
docs here; they're a separate, smaller product (the "VM-only" subset
of Morpheus). The Morpheus VM Essentials Deployment Guide refers to
Morpheus Enterprise as the "elevate to" target — that's the
relationship.
PRODUCT_NAME=morpheus. Tool will be named morpheus_api_lessons,
collection morpheus_docs, etc.
Upstream portal
HPE Support DocPortal (Tridion/SDL-derived, same surface as HVM and the Zerto docs). Anonymous JSON API, no auth required.
| Endpoint | Returns |
|---|---|
GET https://support.hpe.com/hpesc/public/api/document/{docId} |
DITA-source HTML — title page / abstract OR (for short docs like Release Notes) the entire body |
GET https://support.hpe.com/hpesc/public/api/document/{docId}/toc |
Nested JSON tree of {topicName, topicLink, description, children}. Empty/404 for single-doc Release Notes. |
GET https://support.hpe.com/hpesc/public/api/document/{docId}/render?page=GUID-XXXX.html |
{docId, page_html, doc_meta, page_meta} — single page body |
User-facing URL format:
https://support.hpe.com/hpesc/public/docDisplay?docId={docId}&page=GUID-XXXX.html
Bundle IDs (confirmed 2026-05-22)
Morpheus Enterprise User Manual — ~569 pages each, full nested TOC:
| Version | docId |
|---|---|
| 8.1.0 | sd00007510en_us |
| 8.1.1 | sd00007621en_us |
| 8.1.2 | sd00007732en_us |
Morpheus Enterprise Release Notes — short, single-doc-blob shape
(no TOC; full body returned by the /document/{docId} endpoint
itself; scraper needs a --single-doc mode for these):
| Version | docId |
|---|---|
| 8.1.0 | sd00007496en_us |
| 8.1.1 | sd00007610en_us |
| 8.1.2 | sd00007733en_us |
Cross-version peers are free
GUIDs are stable across versions (confirmed on HVM where 374/376/376
pages had 100% GUID overlap between adjacent versions). Same-GUID =
same-topic. Synthesize topic_cluster.clustered_topics by looking
up the same GUID in the other bundle slugs — no fuzzy matching
needed.
Reusable from hvm-docs
../hvm-docs/scrape/bundles.py and ../hvm-docs/scrape/runner.py
solve the identical portal shape. Copy and adapt the BUNDLES list +
PRODUCT_NAME; the fetch logic should drop in unchanged. Both the
TOC-paginated path and the single-doc path are needed (the HVM
build covers both because HVM Release Notes follow the same shape).
What you write
At minimum, two scripts:
scrape/bundles.py
Discovers the upstream portal's bundle catalog and writes
bundles.json at the repo root. One entry per bundle (versioned doc
set) with the schema in PLAN.md.
python -m scrape.bundles
scrape/runner.py
Scrapes the pages of each bundle (or a single bundle with --bundle <slug>). Writes:
corpus/<bundle_id>/<page_id>.md— extracted markdown bodycorpus/<bundle_id>/<page_id>.json— per-page metadata sidecar
python -m scrape.runner --all --force --concurrency 6
python -m scrape.runner --bundle Admin.VC.HTML.10.9
Tips
- Sniff before you scrape. Almost every modern doc portal is an SPA that calls a backend API. Open the browser's Network tab, click around, find the underlying JSON. Scraping the API is 10× cheaper and 100× more reliable than scraping the rendered HTML.
- Idempotent re-scrapes. Without
--force, the runner should skip pages already on disk so a resume doesn't have to re-fetch everything. With--force, re-fetch every page — that's the weekly cron mode that catches edits. - Respect the portal. Backoff on 429s. Set a recognizable user-agent so the portal owner can identify you if they want to.
- Whitespace normalize. Markdown that round-trips through HTML often has extra blank lines. Normalize to a single blank between paragraphs so diffs are clean (the changelog summary and digest tools care about line counts).
What's already reusable
scrape/changelog.py is fully product-agnostic and ready to use
as-is. It walks git diff --name-status output to produce a
structured summary, and walks git log for the digest history
(Phase 13).