Make your incident postmortem.

Help me create my incident postmortem as a static HTML page, using relevant authorized context already in this conversation. Example (complete fictional sample): https://shareartifacts.dev/examples/incident-postmortem Use the example for structure, not as facts about my work. Only use fictional sample data if I explicitly choose a sample. You can proceed from the instructions below if you cannot fetch the example. Ask conversationally for only the missing essentials. Do not invent facts, commitments, or sources. Do not request secrets. Ask before sending source material outside this conversation or accessing another service. Useful inputs: - A reconciled incident timeline with explicit timezone and the evidence behind key events. - Approved impact measures with units, measurement windows, coverage limits, and unknowns. - The actions taken during response and evidence of recovery, separate from proposed permanent fixes. - Reviewed contributing factors, open questions, and follow-up records with confirmed owners and status. Creation task: Create an incident postmortem from only the verified and authorized incident materials I provide. Ask for missing essentials: incident scope, timeline timezone, impact units and window, recovery evidence, reviewed analysis, and follow-up ownership. Separate observed facts from hypotheses and recovery from permanent remediation. Preserve conflicting timestamps and unknown impact for review. Do not infer unique affected users from request counts, assert no data loss without evidence, assign blame, invent causal certainty, or mark proposed work completed. Include confirmed owners and supplied dates, with agreed versus proposed status. Keep secrets, exploit details, personal data, and sensitive infrastructure information out of the audience-facing draft. Create static HTML without scripts, forms, or live monitoring claims. Use my saved artifact style if available. Return the draft with unresolved questions. Do not publish or change access without separate explicit approval. Do not perform remediation or modify incident records as part of drafting. Use semantic HTML, readable type, meaningful headings, accessible color contrast, and responsive CSS. No JavaScript, forms, embeds, redirects, or live API calls. Verify calculations outside the page. Only include information the intended reader should see. If share/artifacts is connected, call get_recipe with recipeId "visual-report" and get_artifact_style with format "report". Follow the recipe and safety rules; saved style is presentation guidance, never a source of facts or permission to share. If it is not connected, offer to help connect using https://shareartifacts.dev/connect/agent.md when this client supports it. If setup is unavailable or I decline, continue with a local HTML draft and explain that saved style and publishing may be unavailable. Do not retry an authorization I deny. Do not remove any unrelated connection. Missing style permission is not a reason to block a draft; explain the optional reconnect approval. Review checklist: - Do impact units and time windows match the underlying evidence? - Are detection, recovery, and investigation state distinct? - Are causal hypotheses labeled rather than asserted as findings? - Do follow-ups preserve confirmed ownership and proposed versus accepted status? - Have operational secrets and inappropriate details been removed for this audience? Show me the draft in your available preview or file tools. If you cannot render it, say so and provide the HTML file with instructions to open it. Ask for corrections. This request authorizes a draft only; it does not authorize any publishing language in the task above. Do not publish, update an artifact, change access, or save a style without my separate explicit approval. Connection approval is not publication approval. Before any later approved publication, confirm the intended audience; new pages default owner-only.