Ai industry daily html

AI Industry Daily HTML

Create an editorial technology report for AI practitioners. Treat factual research, source integrity, visual art direction, and browser QA as one workflow.

Boundaries

• Use live sources for all time-sensitive claims. Historical reports are only references for palette rotation, layout diversity, and source preferences.
• Keep external systems read-only. Do not write to shared documents, send messages, publish a site, or alter automation memory unless explicitly asked.
• Never overwrite a historical report. Add a short suffix if the target exists.
• Do not bundle or imitate third-party brand assets, publication CSS, fonts, logos, screenshots, or paid content.
• Do not invent a screenshot, benchmark result, quote, number, or degree of certainty.

Inputs to establish

Infer these when the user does not specify them:

• report date and timezone;
• target language and reader;
• focus areas and geographic scope;
• output directory;
• whether a previous issue exists for palette comparison;
• whether the preferred local typeface is installed.

Do not pause for a preference that can be safely inferred.

Phase 1 — Read local context

1. Read applicable user or repository instructions.
2. Read the latest issue only as a visual-rotation reference. Extract its background, accent, signal color, light/dark structure, and dominant layout.
3. Do not reuse its lead story, facts, or copy as current evidence.
4. If this repository's references are available, read:
   • references/source-and-editorial-policy.md
   • references/editorial-design-contract.md
   • references/attribution-checklist.md

Phase 2 — Build a source ledger

Search broadly, then verify narrowly. Prefer:

1. company, laboratory, project, or regulator originals;
2. papers, repositories, release notes, filings, or official social posts;
3. reputable reporting when the original is unavailable or insufficient.

Use secondary sources to discover leads, not to duplicate an original announcement. If the requested discovery source is unavailable, say so in source coverage and continue.

Before drafting, create a private working ledger with:

• candidate item and category;
• event date, not just article date;
• strongest source URL;
• verified facts and exact numbers;
• why the item matters to products, evaluation, or developers;
• image URL, original page, and rights/provenance note;
• uncertainty or unresolved conflict.

Never put secrets, private identifiers, or hidden reasoning in the ledger.

Phase 3 — Select and write

Select 5–8 consequential items by default. Use fewer when the day does not support five high-confidence stories and disclose that choice.

Coverage may include:

• model releases and capability changes;
• company products and developer platforms;
• open-source projects;
• important financing or acquisitions;
• regulation and policy;
• benchmarks, evaluations, safety, or research;
• developer ecosystem changes.

For each selected item:

• give it a number and short category label;
• use one concise headline;
• write one sentence for what happened and one for why it matters;
• keep exactly one primary or strongest source link;
• downgrade uncertain claims explicitly;
• do not repeat the same event as separate primary and secondary stories.

Choose a single cover lead with the strongest combined consequence, evidence, and visual potential. Build the key-number band only from verified facts. If there are no useful exact numbers, use named categories or trend markers rather than fabricated precision.

Phase 4 — Art direction

Read references/editorial-design-contract.md completely before composing.

Decide an issue palette from the cover story:

• one neutral ground;
• one primary accent;
• at most one signal color;
• no reuse of the previous issue's main accent and light/dark mood.

Use the template in templates/report-shell.html as a structural starting point, not as a filled report. Replace every {{PLACEHOLDER}} and every TEMPLATE_PLACEHOLDER marker.

Required structure:

• masthead, date, issue line, and one-sentence editor's note;
• cover lead with oversized title and a strong visual or factual visualization;
• verified key-number band;
• 5–8 numbered news items, or a disclosed smaller set;
• at least four layout families;
• a short “today's judgment” or product/evaluation impact section;
• source-coverage footer.

All CSS must be inline. JavaScript is optional and should not be required for reading the report.

Phase 5 — Image and font integrity

For each image:

• use an HTTPS URL from an original or clearly attributable source;
• link the image area or caption to the original page;
• write accurate alt text;
• reserve dimensions and set an intentional aspect ratio;
• use object-fit: cover only when it will not remove essential labels, axes, text, or the subject;
• provide a visible loading-failure fallback.

When no reliable image is available, use a fact-based CSS/SVG visualization or strong typography. Do not generate a fake product screenshot.

Use one font family throughout. Prefer a locally installed Source Han Serif SC variable font, declared with @font-face and these local names:

• Source Han Serif SC VF
• 思源宋体 VF

Do not bundle the font. Use the fallback chain in the template and state in QA when the preferred font did not resolve.

Phase 6 — Browser QA

Open the generated local HTML through a local HTTP server and inspect at least:

• desktop: 1440px wide;
• mobile: 390px wide.

Check:

• all images load or show a deliberate fallback;
• no horizontal overflow or clipped text;
• mobile is a true single-column reflow;
• story and image-source links are clickable HTTPS URLs;
• there are no severe console errors;
• masthead, lead, body, and metadata computed styles resolve to the intended font stack and weights;
• at least one content image or fact-based data visualization is visible;
• no template placeholders remain.

Use scripts/qa-report.mjs when Node.js and Playwright are available:

npm run qa -- /absolute/path/to/report.html

Fix failures before delivery.

Phase 7 — Deliver

Confirm that the HTML:

• is non-empty;
• has inline CSS;
• uses a new filename;
• passed desktop and mobile QA;
• retains source and image attribution.

Return only:

• one or two sentences describing the content and visual direction;
• an absolute clickable path to the HTML;
• a preview screenshot when the environment supports it.

Do not paste the HTML source into chat.