Different ideas deserve different diagrams.

Build a clean dashboard for our weekly support desk snapshot, week 32 (Mon 2026-08-03 to Sun 2026-08-09): 1,284 tickets received against 1,206 the prior week, first-response median 42 min against 55 min, 1,194 of 1,306 resolutions inside the 24 h SLA target against 88.9% the prior week, and 96 tickets open at week end against 118. Add a per-channel intake breakdown with median first response (email 528 / 66 min, in-app chat 431 / 11 min, phone 196 / 4 min, community forum 129 / 148 min) and the open backlog by age (51 under 24 h, 29 at 1 to 3 days, 12 at 4 to 7 days, 4 over 7 days). Do not invent any figure beyond these.

Create a warm narrative product brief. Preserve the following headings and exact copy. Eyebrow: “Product brief · café”. Title: “Café membership revamp”. Subtitle: “A brief for the café membership app: decisions first, then flow and impact.” ☕ Decision-first / The revamp in six decisions: 01 · R1 Stars, not points: Every yuan spent earns one star; no thresholds, no expiry. 02 · R2 Three tiers: Your rolling 90-day total sets silver, gold, or black-gold tiers. 03 · R3 One-scan checkout: A single scan earns stars and redeems rewards; it works offline. 04 · R4 Store value gifts: Load 200, get 20. Refundable, with the rules on the home page. 05 · R5 Birthday doubles: All purchases in the birthday week earn twice the stars. 06 · R6 Trends, not profiles: The store dashboard shows trends only, not per-customer profiles. ⭐️ Customer flow / One order, four steps: ☕️ Order: In person at the counter, or in the app. → ⭐️ Earn: Stars are credited after one scan. → 📈 Level up: 90 days sets your tier. → 🎁 Redeem: Stars trade for treats. 🧾 Impact / What changes for whom: Audience | Today | After the revamp; Regulars | Paper stamp cards, lost means gone | Stars live in the app, visible forever; Baristas | Stamp by hand, reconcile monthly | One scan covers earning and redemption; Managers | Manual membership counts at month end | Live sales trends in the dashboard; Bookkeeping | Stored value on notebook ledgers | Balances and gifts post automatically. ⚠️ Dependency / Risks and dependencies: Paper stamp cards convert into the app by the end of October, running in parallel for two weeks. If conversion slips, the new rules start a week later; store events are unchanged. ✅ Acceptance / Definition of done: ✓ A regular earns and redeems stars in a single scan; ✓ Tier changes on the 90-day total apply automatically; ✓ Baristas record offline; uploads resume on reconnect; ✓ Stored value refunds to the original payment method; 🚫 Boundary / Non-goals for this revamp: × Delivery and takeout; × Social feeds and comments; × Cross-store shared points; × Ad slots and co-branding; Footer label: “Decision owners”. Footer: “R1–R3 product, R4–R5 store ops, R6 data. Payment compliance sign-off is required before R4 ships. All names and figures are synthetic sample data.” Export PNG, standalone HTML, and the complete Diagram JSON.

Create an editorial layered architecture overview explaining text2html2png. A prompt and source facts enter the chosen agent, which may use a remote service under its own privacy settings. The agent selects a chart and style, preserves the supplied facts, and writes Diagram JSON. The local Node.js runtime generates and validates self-contained HTML, and local Chrome audits the layout. HTML is the default output; PNG is exported only on explicit request. The renderer has no telemetry and blocks browser network requests by default. Clearly distinguish agent processing from local rendering; do not claim the whole conversation stays on the machine.

Create a clean architecture grouping diagram for this synthetic order-system case, and also export PNG. This is an illustrative design, not a real customer system or a benchmark. Use three layers: entry points, services, and resources. The storefront synchronously calls the order service to create an order. The payment platform synchronously calls the payment callback service with a callback ID. The order service alone reads and writes its own PostgreSQL database: it commits an order and its outbox record together, then its publisher sends OrderCreated to the event queue. It also consumes PaymentConfirmed from that queue, updating payment status and recording the consumed event ID in one transaction. The callback service alone reads and writes a separate PostgreSQL database: it commits the callback ID and its outbox record together, acknowledges after commit, and its publisher sends PaymentConfirmed to the same queue. The inventory consumer receives OrderCreated and alone reads and writes a third PostgreSQL database, committing the reservation and consumed event ID together. Queue delivery is at least once: OrderCreated goes only to the inventory consumer; PaymentConfirmed goes only to the order service. Failed publishing is retried from each service's outbox. Callback IDs deduplicate callbacks; consumed event IDs deduplicate consumption. Mark all three databases and their exclusive owners, keep synchronous and asynchronous relationships explicit, and retain these delivery boundaries. Layer arrows indicate grouping only, not node-to-node wiring or a serial call chain. Do not add a gateway, cloud vendor, throughput, latency, or an exactly-once guarantee.

Make a clean comparison of three plans — Community, Team, Studio — on the same criteria: seats included, active projects, storage, support response, monthly price, annual price. Community: 3 seats, 5 projects, 2 GB, community forum only, $0; describe it as self-hosted, for solo work and evaluation. Team: 25 seats, 50 projects, 100 GB, 1 business day, $18 per seat monthly, $180 per seat annually; describe it as shared projects for a small group. Studio: unlimited seats and projects, 1 TB, 4 hours, $49 per seat monthly, $490 per seat annually; describe it as for larger groups that need a response time. Annual billing charges ten months per seat. Close with a short "how to read it" note: seats and projects are hard caps, support response is the target time to a first reply during business hours and Community has no target, and the ten-month rule is why $18 becomes $180 and $49 becomes $490. Title it "Choosing a plan" and do not declare a winner.

Create a clean flowchart for our release process: Plan → Build → Review → Test → Canary → Production. Keep it concise and show that every gate must pass before the next stage.

Make a glass funnel for our 30-day signup cohort: 48,200 visited the landing page, 18,795 started signup, 12,640 verified their email, 8,930 completed a profile, and 8,700 activated. For each stage show its share of all visitors, and between stages show the conversion rate and how many people dropped off, both computed from those volumes. Add nothing that the numbers do not support.

Draw a notebook-style Gantt chart for our eight-week community conference run-up, weeks starting Mon Apr 5 2027. Venue and date lock W1-W2. Call for talks open W3-W5, starting after the venue is locked. Talk review and scheduling W5-W6. Speaker confirmations W7, after review. Tickets and promotion W3-W8. Volunteer recruiting and briefing W5-W7. Walkthrough and event week W8, after the volunteer briefing. Milestones: call for talks closes end of W5, schedule published end of W6, doors open Sat May 29. Show a week-number axis.

Draw an editorial timeline of the public roadmap for our open-source charting library, subtitled "first render to extensible core", six milestones: 2031 Q2 v0.1 first render (line and bar marks from a plain number array, one canvas target, no interaction or theming); 2031 Q4 v0.4 scales and axes (linear, time, ordinal scales with tick labels derived from the data range); 2032 Q1 v0.7 interaction layer (hover, tooltip, range selection, keyboard reachable and announced to screen readers); 2032 Q3 v1.0 stable API (semantic versioning starts, mark/scale/theme contracts frozen for 1.x); 2033 Q1 v1.4 server rendering (same definition renders to static SVG without a browser, for documents and email digests); 2033 Q3 v2.0 plugin API (marks, scales, and themes ship as separate packages, so the core stops growing with every new chart). Close with a note that quarters are targets, not commitments, that scope moves before a date does, and that every milestone ships from the main branch.

Draw a warm org chart for a 14-person product studio using role titles only, no names. A studio lead owns direction, client mix, and hiring. Three discipline leads report to them. Design lead, craft quality across product and brand work, 5 including the lead: two product designers (flows, screens, and prototypes), a brand designer (identity, decks, and site pages), a design technologist (living prototypes and UI code). Engineering lead, technical direction, review, and releases, 4 including the lead: a frontend engineer (client apps and shared UI code), a backend engineer (services, data models, and APIs), a platform engineer (build, deploy, and tooling). Delivery lead, scope, schedule, and client communication, 4 including the lead: a user researcher (interviews and usability tests), a technical writer (product docs and handover), a delivery producer (estimates, schedules, vendors). Show headcount per branch and the studio total.

Create a clean architecture diagram: Browser → API Gateway → Auth Service and Order Service. Auth Service uses its own PostgreSQL database. Order Service uses a separate PostgreSQL database and its own Redis. Show client, entry, service, and data layers, with ownership stated in node descriptions. Do not add cloud providers, protocols, ports, or metrics.