You review the facts and access. Nothing is published without your approval.
The method behind the static artifact versus web app comparisonAsk your agent to distinguish reading from live operations, without drawing controls that cannot work.
When should I publish a static artifact instead of building a web app?
Use a static artifact when the job is to read a reviewed report, presentation, brief or snapshot. Use an application when readers must submit information, save changes, query live data, run calculations or carry out authenticated actions. HTML is used in both; the difference is the behavior the task requires.
What to give your agent
The recipient's actual task, including every required action after reading.
Whether inputs must be submitted, stored, calculated or shared between users.
Data freshness, identity, permissions and operational requirements.
The approved snapshot and source definitions if a reading artifact fits.
Describe the action in ordinary language
Ask what the reader must accomplish. 'Understand this week's result' differs from 'change a request and save it.' A button-shaped decoration does not deliver the second workflow. Separate explanatory content from the operations the user expects to perform.
Find the active requirements
List live data retrieval, submitted forms, saved state, user accounts, calculations and background work. MDN distinguishes static delivery from server-side processing and data-backed behavior. share/artifacts Safe Static Mode disables scripts, forms and external API calls; it is not a place to implement these operations.
Choose an honest split when both are needed
A reviewed briefing can explain results and link to an approved application for action. Keep source data and operational controls in that application. Do not mimic a working form, login or save button in the static page, and do not imply that a linked tool's state is synchronized with the briefing.
Review the actual output before sharing
Check that every visible affordance matches what the page can do. Show the snapshot date and limitations near changing data. If the primary job needs an app, choose an appropriate application workflow rather than hiding the unsupported behavior in a disclaimer. The agent can still draft a requirements brief for that separate work.
Create a static HTML decision brief that qualifies whether my reader task fits a static artifact or needs a web application. Use my authorized requirements and existing context. Separate reading and explanation from submitted inputs, saved state, live queries, calculations, accounts and background work. Recommend a real application workflow when active behavior is essential; suggest a reading-plus-approved-link split only when appropriate. Ask only for missing essentials. Use my saved artifact style if available. This task creates a communication brief only, not an app or a prototype with misleading controls. No scripts, forms, fake login, save buttons or live-data claims. Show the draft for review. Do not publish, deploy an application or change access without separate explicit approval.
Check before you shareAccuracy, clarity, and permission
Is every required reader action classified, not just the page's appearance?
Does the page avoid controls that imply unsupported submission or saved state?
Are snapshot freshness and external-app responsibilities explicit?
If the primary job needs an app, does the recommendation clearly say so?
When HTML fits
A decision brief, explanation, report or reviewed snapshot with ordinary reading navigation and approved links.
When another format fits better
Use an application platform for scripts, forms, APIs, accounts, mutable state, computation or background behavior. Sharing controls around an artifact do not turn submitted HTML into an authenticated application.
What we started withThe same facts, as a wiki page
Fictional team wiki
Cedar operations — reading versus saved-state requirements
The reading requirement
September 7, 2026. This is a requirements decision, not an implemented app. The manager needs to understand the August snapshot: 18 closed requests / 24 eligible under the same definition, or 75%. No cause or later result is supplied.
The operator requirement
The operator needs to assign incoming requests, save changes and see the current queue. A read-only snapshot cannot do those jobs. Application URL, identity requirements, authorization and storage design remain unspecified.
Decision and open requirements
The manager’s reading job fits a dated static explanation; assignment and saved state require an application workflow. Settle the missing operational details in a separate requirements review before implementation. A brief could link to an approved app after URL and recipient access are verified, but no URL is supplied here.
Static-mode boundaries
share/artifacts Safe Static Mode runs no scripts, submits no forms and calls no external APIs from the submitted HTML. This document is not a live queue, calculator, login or saved-state system, and should not display fake assignment, save or login controls. Artifact sharing access is separate from application authentication inside content. Publishing this decision does not deploy an app, grant operational permissions or authorize request changes.
Inspect the HTMLOne self-contained file
The example is sanitized and isolated from this site. No scripts, forms, or live data.
<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Cedar operations: snapshot or application?</title><style>
*{box-sizing:border-box}html{color-scheme:light}body{margin:0;background:#f5f8fc;color:#182e46;font:17px/1.65 system-ui,sans-serif}main{max-width:1000px;margin:auto;padding:clamp(20px,5vw,64px)}h1,h2,h3,p{margin:0 0 18px}h1{font:500 clamp(32px,5vw,58px)/1.14 Georgia,serif;letter-spacing:-.025em;overflow-wrap:anywhere}h2{font:500 29px/1.3 Georgia,serif;overflow-wrap:anywhere}h3{font-size:19px;line-height:1.4}.label{font:700 12px/1.6 system-ui,sans-serif;letter-spacing:.08em;text-transform:uppercase}.intro{font-size:20px}.lead{background:#23486b;color:white;padding:24px;margin:28px 0}.lead p:last-child{margin:0}.grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,230px),1fr));gap:20px;margin:24px 0}.card{background:white;border:1px solid #bbc5c4;padding:24px}.metric{font:500 38px/1.2 Georgia,serif;display:block;margin-bottom:12px}section{margin:36px 0}ul,ol{padding-left:22px}li{margin-bottom:12px}.note{font-size:14px}.warning{border-left:5px solid #956118;padding-left:20px}a{color:inherit;text-underline-offset:4px}a:focus-visible,summary:focus-visible{outline:3px solid #956118;outline-offset:4px}table{width:100%;border-collapse:collapse;table-layout:fixed;font-size:15px}th,td{text-align:left;vertical-align:top;border-bottom:1px solid #bbc5c4;padding:12px 8px;overflow-wrap:anywhere}caption{text-align:left;font-weight:700;padding:12px 0}pre,code{white-space:pre-wrap;overflow-wrap:anywhere}footer{border-top:1px solid #bbc5c4;padding-top:24px;margin-top:40px;font-size:14px}@media(max-width:480px){th,td{padding:10px 4px;font-size:14px}}@media print{body{background:white}.card,.lead{break-inside:avoid}h2,h3{break-after:avoid}}
</style></head><body><main><header><p class="label">Cedar operations / Fictional decision / September 7, 2026</p><h1>Two jobs. Only one is a reading page.</h1><p class="intro">The manager needs an explanation. The operator needs a system that saves changes.</p></header><section><h2>Job one: understand August completion</h2><div class="lead"><p class="label">Static artifact fits · R1</p><h3>18 of 24 eligible requests closed</h3><p>18 ÷ 24 × 100 = <strong>75% completion</strong> for the supplied August definition.</p><p>A dated reading page can explain this verified snapshot. It does not establish a cause or a later result.</p></div></section><section><h2>Job two: operate the request queue</h2><div class="card"><p class="label">Application required · O1</p><ul><li>Assign incoming requests to people.</li><li>Save those changes.</li><li>See the current queue state.</li></ul><p>These actions require an application workflow. A static snapshot cannot fulfill them.</p><p class="warning">No app URL, identity requirements, authorization rules or storage design is supplied. Settle those requirements separately before implementation.</p></div></section><section><h2>A useful split, if the tool is approved</h2><p>The briefing could explain the result and link to an approved operational application. The application would own assignment, permissions and saved state.</p><p>No URL is supplied here, so there is no invented link or working action. A link would not synchronize this August snapshot with later changes.</p><p class="note">Sources D1 and S1.</p></section><section><h2>What this page deliberately does not do</h2><h3>Capability boundary</h3><table><thead><tr><th scope="col">This brief</th><th scope="col">Separate application work</th></tr></thead><tbody><tr><td>Communicates a reviewed snapshot</td><td>Retrieves current queue data</td></tr><tr><td>Explains the required actions</td><td>Assigns requests and saves changes</td></tr><tr><td>Identifies missing requirements</td><td>Implements identity, authorization and storage</td></tr></tbody></table><p>No scripts, forms, fake login, assignment controls or save buttons are included. Artifact sharing controls are separate from authentication inside an application.</p><p class="note">Sources B1 and V1. Sharing this decision does not deploy an app, grant operational access or change a request.</p></section><footer>Fictional worked example by share/artifacts. Names, dates, figures and records are invented for demonstration. Static snapshot; no live data or automatic updates.</footer></main></body></html>
The original worked scenarioThe source scenario, step by step
A weekly snapshot fits. An editable request queue does not.
Fictional Cedar operations request. Two reader jobs use the same authorized situation but need different capabilities.
The original notes
Manager needs to understand August completion: 18 closed of 24 eligible. Operator needs to assign incoming requests, save changes and see current queue state. No approved app URL or authentication requirements supplied.
Reading job
A dated HTML snapshot can explain 18 / 24 = 75% completion.
Operational job
Assignment, saved changes and current queue state require an application workflow.
Possible split
A briefing may link to an approved app when its URL and access are verified. No link is supplied here.
Not implemented
This decision brief contains no working assignment controls, login or live queue.
Choose the medium by the required behavior, not by whether the output contains HTML.
Questions, adaptations & sourcesGo deeper when you need to
Is every HTML page a static artifact?
No. Applications also use HTML. The important distinction is the required behavior and supporting system. A static reading page does not provide a database, saved inputs or live application actions.
Can a static page link to a working tool?
Yes, when the link is approved and appropriate for the audience. The tool performs the action. The briefing does not gain that capability or automatically reflect changes made there.
Can I publish a calculator or signup form here?
Not in this Safe Static workflow. Scripts and forms are disabled. Keep calculations or signup in an appropriate application and use a static page only to explain verified results or instructions.