changedInput schema / properties / content / anyOf
Previous value: -[
- {
- "properties": {
- "blocks": {
- "items": {
- "oneOf": [
- {
- "properties": {
- "text": {
- "maxLength": 20000,
- "type": "string"
- },
- "type": {
- "const": "paragraph",
- "type": "string"
- }
- },
- "required": [
- "type",
- "text"
- ],
- "type": "object"
- },
- {
- "properties": {
- "level": {
- "maximum": 3,
- "minimum": 1,
- "type": "integer"
- },
- "text": {
- "maxLength": 20000,
- "type": "string"
- },
- "type": {
- "const": "heading",
- "type": "string"
- }
- },
- "required": [
- "type",
- "level",
- "text"
- ],
- "type": "object"
- },
- {
- "properties": {
- "text": {
- "maxLength": 20000,
- "type": "string"
- },
- "type": {
- "const": "quote",
- "type": "string"
- }
- },
- "required": [
- "type",
- "text"
- ],
- "type": "object"
- },
- {
- "properties": {
- "items": {
- "items": {
- "maxLength": 20000,
- "type": "string"
- },
- "maxItems": 200,
- "minItems": 1,
- "type": "array"
- },
- "ordered": {
- "default": false,
- "type": "boolean"
- },
- "type": {
- "const": "list",
- "type": "string"
- }
- },
- "required": [
- "type",
- "items"
- ],
- "type": "object"
- },
- {
- "properties": {
- "headers": {
- "items": {
- "maxLength": 20000,
- "type": "string"
- },
- "maxItems": 20,
- "minItems": 1,
- "type": "array"
- },
- "rows": {
- "items": {
- "items": {
- "maxLength": 20000,
- "type": "string"
- },
- "type": "array"
- },
- "maxItems": 100,
- "type": "array"
- },
- "type": {
- "const": "table",
- "type": "string"
- }
- },
- "required": [
- "type",
- "headers",
- "rows"
- ],
- "type": "object"
- },
- {
- "properties": {
- "text": {
- "maxLength": 20000,
- "type": "string"
- },
- "type": {
- "const": "link",
- "type": "string"
- },
- "url": {
- "format": "uri",
- "type": "string"
- }
- },
- "required": [
- "type",
- "text",
- "url"
- ],
- "type": "object"
- }
- ]
- },
- "maxItems": 500,
- "minItems": 1,
- "type": "array"
- },
- "title": {
- "maxLength": 160,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "title",
- "blocks"
- ],
- "type": "object"
- },
- {
- "properties": {
- "format": {
- "const": "html",
- "type": "string"
- },
- "html": {
- "description": "Self-contained static HTML/CSS source. SharedBrief's default for new proposals, sales memos, pitches, one-pagers and business briefs is polished, content-led design. Create a bespoke responsive static HTML/CSS document (format html, mode static) without asking the user to request styling. An explicit user format, brand or visual reference overrides these defaults. Ordinary text documents and explicit plain-text requests can use structured blocks. For a narrow edit, preserve the existing design, content, stable URL and access/publication settings.\n\nDESIGN THE STORY: Decide what the reader needs to understand and do, then choose a visual composition that explains this particular subject. A sales proposal needs a clear offer, buyer benefit, credible support and next step. A product pitch may need a visual mechanism or comparison; a report may need evidence and changes over time. Do not force every genre into the same executive memo. Choose one coherent art direction from the subject's brand and audience: intentional typography, restrained color, generous whitespace and strong contrast. Light editorial pages and dark product presentations are both valid when they fit. Use system fonts with distinct display/body proportions; no external font imports.\n\nCOMPOSE, DO NOT JUST FORMAT: Lead with a dominant benefit headline (typically 40–64px desktop, 30–40px mobile), a concise explanation and a decisive visual idea. Establish a focal point rather than distributing attention evenly across small boxes. For a product proposal, let the product demonstration share the opening composition with the offer, instead of burying it below several paragraphs. Use an asymmetric layout or contrasting full-width moment when the content earns it, with generous quiet space around the focal visual. A literal memo or short text-only request need not add a diagram.\n\nPRODUCT AS EVIDENCE: When proposing a product, show its distinctive mechanism through one substantial HTML/CSS visual: an illustrative approval screen beside a purchase receipt, a product anatomy with precise annotations, a meaningful before/after, or an equivalent artifact that makes the benefit concrete. Choose from the researched subject, never force a payment metaphor onto unrelated products. A row of labeled text boxes with arrows is not by itself a product demonstration. Show the important relationship, decision or changed state spatially, then remove copy that merely repeats the visual. Use authentic terminology and explain who controls what. Any reconstructed interface must be labeled illustrative, not a real screenshot, exact shipped interface or completed transaction; use clearly marked example values only when necessary. Present a static state or a complete static sequence with readable annotations, not controls that look clickable. Do not fabricate brand assets, customer logos, card credentials, testimonials or claims of product functionality.\n\nGive different information different treatments: proof can be one well-supported fact with its caveat, rather than a mandatory metric strip; products can have distinct concise modules; a comparison can show the relevant alternatives together; customer evidence can be a tidy list; commercials can be one clear offer. Choose only structures justified by the content. Vary section rhythm and hierarchy within one coherent page. Do not repeat equal cards, tables, numbered sections and phase panels as a universal recipe. Avoid decorative UI that contributes no understanding, and do not invent fake toggles, replay buttons, inputs or controls for a static page. Preserve the explanatory value of an interactive reference using a complete static composition.\n\nCRAFT: Center the page at a width suitable for its composition (usually 850–1100px), with generous desktop margins and 20–28px mobile padding. Use readable body text around 14–17px, comfortable line height, short paragraphs, clear section headings, deliberate alignment and consistent spacing. For a one-page request prioritize roughly 250–400 words and a focused visual story; omit secondary detail before shrinking text. A one-page web brief is one coherent document, not a fixed-height canvas. Avoid a long mini-website or a compressed brochure. Keep only the buyer problem, the product mechanism, the strongest support and a clear offer/next step when those are relevant; there is no mandatory section list. Remove secondary product catalogs and repeated benefit lists before reducing whitespace. Use a small deliberate type scale, short heading lines, consistent alignment and a restrained accent repeated with purpose. Avoid excessive uppercase micro-labels and tiny footnotes as a substitute for hierarchy. No forced section count, preparation metadata or clerical To/From fields unless useful.\n\nDo not default to terminal windows, shell commands, monospace body copy or developer panels merely because the subject is technical. Actual code or a transaction trace belongs only when necessary to explain the product; it must not replace the main visual story. Do not rely on decorative gradients, emoji, generic icons or placeholder badges for visual quality.\n\nTRUTH AND USABILITY: Use available source material and the user's facts. Do not invent proof, metrics, prices, implementation dates, commitments, testimonials, brand assets or contact addresses. Label proposed rollout steps and assumptions clearly; distinguish current results from targets and keep material limitations visible. Use semantic markup, accessible contrast and descriptive links. Stack or recompose columns and diagrams on narrow screens; constrain long text and tables to avoid horizontal overflow. Set box-sizing:border-box. Do not fix page height, clip content or add internal scrolling. All content must be visible without a click or scroll-triggered reveal.\n\nDESIGN REVIEW: Before the first save, critique the full composition once: can the reader grasp the offer and mechanism at a glance; is there one unmistakable focal visual; does each section add information; are claims supported; and will the narrow-screen composition remain legible? Revise generic diagrams, uniform cards, dense copy and weak hierarchy before saving. If the host has a rendering/browser tool, inspect the actual desktop and mobile rendering and correct concrete defects in one bounded pass. If it has no such tool, review the source/layout and do not claim visual verification. After saving, show the actual draft with the preview tool when available; a preview call alone does not prove visual inspection. Never publish a draft to make inspection possible.\n\nCAPABILITIES: Use a self-contained style block and HTML/CSS. SharedBrief supplies viewport/security metadata. No scripts, event handlers, images, SVG, external dependencies, forms, iframes, trackers or meta elements. Do not promise unsupported interaction. Create new briefs privately and show the draft using the preview tool when available. Preserve existing publication state during edits. Publish only on the user's authorization.",
- "minLength": 1,
- "type": "string"
- },
- "mode": {
- "const": "static",
- "type": "string"
- },
- "title": {
- "maxLength": 160,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "format",
- "mode",
- "title",
- "html"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "properties": {
+ "format": {
+ "const": "html",
+ "type": "string"
+ },
+ "html": {
+ "description": "Self-contained HTML source. SharedBrief's default for new product proposals, pitches and one-pagers is polished, content-led design with useful working interactive demonstrations. Create bespoke responsive self-contained HTML/CSS/JavaScript (format html, omit mode for interactive HTML). Do not set mode to interactive; the accepted interactive shape omits mode. New briefs stay private and unpublished; show the saved draft with show_document. Publishing always needs user authorization. Preserve existing content, stable URL, access and publication state during narrow edits; do not convert an existing static design just because interaction is available. Explicit user formats, branding and references take precedence. Ordinary text-only memos can use structured blocks. Explicit static HTML requests use mode static when that capability is available, with no scripts or event handlers.\n\nDESIGN THE STORY: Lead with a clear buyer benefit, a dominant 40–64px desktop / 30–40px mobile headline, short explanation, and a substantial subject-specific product visual near the offer. Choose a coherent art direction suited to the brand and audience: disciplined type scale, restrained color, deliberate alignment and generous quiet space. Use system fonts, readable 14–17px body text and 20–28px mobile margins. Aim for roughly 250–400 words of unique explanatory copy, plus concise interaction labels. Keep the offer, core mechanism, material caveats and next step visible before interaction. Do not hide a brochure in tabs. Avoid repeated equal cards, numbered sections, excessive uppercase micro-labels and terminal styling just because the product is technical. Do not default to terminal panels; actual code is useful only when it explains a real mechanism.\n\nPRODUCT AS EVIDENCE: Include one or two substantial interactive modules when they make the product clearer: a replayable walkthrough of the product mechanism, comparison tabs that change meaningful evidence, or a scenario selector whose recommendation changes with an explanation. Choose the smallest useful set; these are choices, not a universal template or an Agentcard payment recipe. Show a concrete product state with spatial relationships, annotations and selective supporting copy. A row of labeled text boxes is not a demonstration. Give other information varied treatments within a coherent page; interaction must improve the story, not decorate a generic proposal.\n\nWORKING DEMOS: Implement controls with actual local event handlers and DOM state. Every control must produce a meaningful visible result; no fake buttons, toggles or empty links. A replay control must cancel/reset earlier timers, advance a bounded sequence, settle in a readable final state, and work on repeated runs. Default state must make sense immediately. Use semantic buttons, keyboard-operable tab/selector patterns, selected/expanded states, visible focus and live announcements for important changes. Recompose on mobile without overflow or clipped controls. User-initiated animation must respect prefers-reduced-motion and reach the same understandable final state without unnecessary motion. Use no autoplay, scroll-triggered reveals or indefinite timers. Demo state is local to this view and resets on refresh; it never saves document content or performs a real account/payment action.\n\nTRUTH: Use public source material and user-supplied facts. Label reconstructed interfaces, example amounts and simulated transactions visibly as illustrative; never imply an exact shipped interface or real approval/purchase. Do not invent product capabilities, proof, metrics, prices, dates, commitments, testimonials, customer logos, card credentials or contact details. Distinguish actual results from targets, proposed rollout from commitments, and comparisons from independently verified facts. Keep limitations and source caveats readable outside optional interactions.\n\nCAPABILITIES AND ISOLATION: Inline local CSS and JavaScript work inside an isolated opaque-origin iframe. Use only the document's DOM and local state. No external scripts/styles/fonts, imports, network calls, forms, nested frames, remote images/media, trackers or meta elements. Do not use parent/top/opener access, cookies, localStorage, host tools, privileged messages or navigation as part of a demo. No upload or managed-asset workflow is needed; draw product visuals in HTML/CSS. SharedBrief supplies viewport/security metadata. Explicit ordinary external links may use HTTP(S); SharedBrief presents them in the trusted Proposal links area below the demo. Use local fragments for in-document movement, and keep all demo actions local. Do not style external links as interactive demo buttons. Keep box-sizing:border-box, responsive width, normal document scrolling and no fixed page height or clipped content. Do not change access or publish to make inspection possible.\n\nDESIGN REVIEW: Before the first save, critique the composition, interaction logic, factual boundaries and narrow-screen layout once; fix weak hierarchy, generic visuals, repeated copy and nonfunctional controls. If actual rendering/browser tools are available, inspect desktop/mobile and exercise the controls, including replay twice. If not, review the source and do not claim visual or functional verification. A preview call alone does not prove inspection. Show the actual saved private draft; do not claim it matches a competitor merely because scripts are supported.",
+ "minLength": 1,
+ "type": "string"
+ },
+ "mode": {
+ "const": "static",
+ "description": "Omit this field for the default interactive proposal with working local JavaScript. Set static only for an explicit static request or to preserve an existing static document; static content cannot execute scripts.",
+ "type": "string"
+ },
+ "title": {
+ "maxLength": 160,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "format",
+ "title",
+ "html"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "blocks": {
+ "items": {
+ "oneOf": [
+ {
+ "properties": {
+ "text": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "type": {
+ "const": "paragraph",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "level": {
+ "maximum": 3,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "text": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "type": {
+ "const": "heading",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "level",
+ "text"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "text": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "type": {
+ "const": "quote",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "text"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "items": {
+ "items": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "maxItems": 200,
+ "minItems": 1,
+ "type": "array"
+ },
+ "ordered": {
+ "default": false,
+ "type": "boolean"
+ },
+ "type": {
+ "const": "list",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "items"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "headers": {
+ "items": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "maxItems": 20,
+ "minItems": 1,
+ "type": "array"
+ },
+ "rows": {
+ "items": {
+ "items": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "maxItems": 100,
+ "type": "array"
+ },
+ "type": {
+ "const": "table",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "headers",
+ "rows"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "text": {
+ "maxLength": 20000,
+ "type": "string"
+ },
+ "type": {
+ "const": "link",
+ "type": "string"
+ },
+ "url": {
+ "format": "uri",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "text",
+ "url"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "maxItems": 500,
+ "minItems": 1,
+ "type": "array"
+ },
+ "title": {
+ "maxLength": 160,
+ "minLength": 1,
+ "type": "string"
+ }
+ },
+ "required": [
+ "title",
+ "blocks"
+ ],
+ "type": "object"
+ }
+]