Make your weekly update.

Help me create my weekly update as a static HTML page, using relevant authorized context already in this conversation. Example (complete fictional sample): https://shareartifacts.dev/examples/weekly-status-report 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: - Dated ticket excerpts with an owner and a clear status; omit private comments your audience should not see. - The previous weekly update, so changes are measured against what readers already heard. - Milestones, dependencies, and confirmed dates, including where a date is still only an estimate. - Open questions and decisions, with the person who can resolve each one and the deadline for an answer. - For a client update: agreed scope, acceptance criteria, delivery evidence, and the client's approval contact. Include only authorized source material. Creation task: Using only the project materials I provide, create a weekly status briefing for [audience] covering [date range]. Compare with the previous update. Lead with the overall position, meaningful changes, and decisions needed. For each material risk, include its consequence, known owner, next action, and confirmed deadline; mark missing information explicitly. Separate completed work, planned work, estimates, and interpretation. For a client audience, organize by agreed milestones and distinguish delivery, client acceptance, and measured outcomes. Omit internal margins and private comments from the output, not material scope, cost, or schedule risks. Ask for missing acceptance evidence rather than treating silence as approval. Name the approval contact and deadline only when supplied; direct replies to the established email or project workflow, not a form in the artifact. Do not infer progress percentages or invent dates. Keep an optional work log below the main summary. Build readable static HTML without scripts, forms, or live-data claims. Use my saved artifact style if available, prioritizing clear headings and restrained color. Include only audience-safe source notes and links. Show me the draft and flag contradictions for review. Do not publish or change anyone's access without separate explicit approval. If this is a sprint review recap, preserve the Sprint Goal, supplied Definition of Done, done/not-done work, stakeholder feedback and proposed adaptations. Do not mark incomplete work Done or treat feedback as an agreed backlog commitment. The static recap does not replace the collaborative Sprint Review. If I ask for a one-page project summary, produce a concise responsive overview of purpose, current position, next decision and approved evidence links. Do not shrink text to force one printed page. For unapproved work, clarify whether I need a proposal instead; do not recast a proposal as approved progress. 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: - Does every completed claim mean completed in the source, rather than started or nearly done? - Are milestones, reporting period, owners, and deadlines accurate and unambiguous? - Can the intended reader identify the decision or next action without reading the work log? - Have private ticket comments, customer details, and unsuitable internal links been removed? - For client reports, is delivery separate from acceptance and measured impact, with material risks still visible? 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.