Single HTML Website Deployment

Completion criteria

For deployment requests, continue until the HTML is uploaded, public access is verified, and a clickable public URL is delivered to the user. Generating HTML, local previews, check_passed, and obtaining an upload address are intermediate steps. An explicit request to publish the selected page authorizes publication; do not ask again. On a real blocker, report deployment as incomplete with the actual error, any saved URL, and the minimum information needed to resume. Never substitute a local path for a public URL or repeat an upload to fix a verification failure.

Inputs and scope

Use the user-selected local .html/.htm file. When asked to create a page, first generate one UTF-8 HTML file. Ask for a selection only when multiple candidates leave the intended source unclear; do not choose the most recent file automatically. Keep CSS and JavaScript inline. Resolve local image, font, iframe, and module dependencies before uploading. Inline SVG and Data URLs are supported. Disclose remote image and font dependencies; external CSS and JavaScript do not meet the inline requirement. Do not silently rewrite the page or introduce a CDN. Do not upload for inspection-only or local-preview requests. The website upload command publishes one HTML file. It does not deploy server processes or databases. Multi-file directory uploads, deletion, domain management, rollback, and unverified same-URL replacement are outside this command’s verified capabilities. Backend-connected pages are supported as described below.

Backend-connected pages

A single HTML frontend may call a separately hosted backend over HTTPS. Do not reject a request for inquiry submission, product data, accounts, or other dynamic features merely because the frontend is a single file.

Use a user-supplied existing API when its contract is available. When the user asks to add a new backend, use an available, verified backend deployment capability and its applicable skill; establish the required endpoint, storage, and authentication behavior before implementation. Do not invent a backend endpoint or claim that oo website upload deploys server code. If the backend destination cannot be determined from context, ask one focused question while continuing independent frontend work.

Keep service credentials and privileged operations on the backend. Only include browser-safe public configuration in HTML. Configure CORS for the published page origin, validate requests on the server, and use authentication and abuse controls appropriate to the feature. Do not use a user’s ooCLI credentials in visitor-side JavaScript.

Implement loading, confirmed success, and recoverable error states. For backend features requested as part of the page, completion requires verification of the actual frontend-to-backend workflow as well as public HTML access. Use a non-sensitive test submission within the authorized scope; never display simulated submission success as a real result. A blocked backend means that feature remains incomplete even if the HTML is online.

Page language policy

The English language of this skill is an authoring convention, not a requirement for generated websites. Apply the following priority order:

Follow explicit user instructions about page language, target audience language, or bilingual output. A clearly specified audience language takes precedence over the conversation language; ask only if instructions conflict.
When revising an existing page, preserve its language and existing language choices unless translation or additional languages are requested.
For a new page without a language instruction, use the language of the user’s current substantive request, informed by the surrounding conversation. Do not switch to English merely because the business involves exports, ecommerce, or international trade. Ask only when a mixed-language request leaves the intended language materially unclear.
Generate Chinese-English bilingual output when the user requests it or an explicit project preference makes bilingual output the default. Otherwise create a single-language page. Do not interpret foreign-trade context alone as a bilingual request.

For bilingual pages:

Keep complete Chinese and English copy inside the same HTML file; do not depend on a live translation service or external language files.
Choose the initial language in this order: a valid saved manual choice, the browser’s first preferred language when it is Chinese or English, then the project’s default language. Use the creator’s conversation language as the project default when it is Chinese or English and no default was specified. If neither applies, ask for the bilingual fallback language rather than guessing.
Normalize browser language tags: zh variants map to Chinese and en variants map to English. Match the requested Chinese script when specified; otherwise use the script of the Chinese conversation, defaulting to Simplified Chinese when no script preference is available.
Provide an accessible, visible Chinese / EN language switch, with the Chinese option labeled in Chinese. Remember explicit choices in localStorage when available; catch storage failures and keep switching functional in memory. Browser detection must not override a visitor’s manual choice.
Translate navigation, product descriptions, buttons, forms, placeholders, validation and status messages, accessibility labels, page title and description, and generated downloads. Keep product names, codes, and factual values consistent. Switching languages must preserve form entries, selections, and other user state. Do not silently convert currencies, units, or commercial terms.
Update the document lang attribute and active language indicator. Check both languages on desktop and mobile, including longer English text, Chinese wrapping, interactions, and download content. Verify automatic selection, manual override, persistence when available, and graceful behavior when storage is unavailable.

Design guidance when creating or revising a page

Before creating or redesigning a page, read references/design-baseline.md. Use its defaults and release checklist to make visual quality repeatable. Apply these defaults when the user asks you to create or redesign a page. Preserve supplied brand guidelines and established visual systems. For upload-only requests, inspect the existing page without redesigning it.

Start with one audience, one page purpose, and one primary action. Organize the page around the visitor’s questions, with a clear headline, concise value proposition, relevant evidence, and an obvious next step.
Use a restrained visual system: one neutral background, one primary brand color, and one accent when needed. Use at most two font families, a consistent type scale, and a small spacing scale such as 8, 16, 24, 32, 48, and 64 px. Prefer system fonts unless approved fonts can be embedded within the size limit.
Build a clear grid with aligned text, images, and controls. Use a centered content width around 1120-1280 px on desktop, comfortable mobile gutters, generous section spacing, and consistent card treatments. Let content determine section count; avoid making every section a card grid.
Create one distinctive visual moment, such as a strong product image, an editorial headline, or a restrained brand illustration. Keep supporting sections quieter. Choose imagery and styling appropriate to the industry instead of reusing a coffee-shop palette or illustration style everywhere. Avoid decorative gradients, excessive shadows, badges, and animations without a clear purpose.
For consumer ecommerce, prioritize product use, benefits, variants, dimensions, materials, delivery information, and a clear purchase or contact path when those facts and destinations are available. For B2B export pages, prioritize product categories, capabilities, specifications, customization, and an RFQ or contact path. Include MOQ, lead time, packaging, certifications, and shipping terms only when supplied or verified; select relevant sections rather than forcing every field onto every page.
Use real, authorized product imagery when available. Preserve product proportions and label illustrative mockups as such. Never invent prices, certifications, customer logos, reviews, factory capacity, or commercial promises. If essential information is missing, ask for it or omit the claim; visibly identify demo content.
Follow the page language policy above. Adapt units, currency, and date formats only to the specified market or supplied facts. Use clear international English when English is selected, and avoid embedding essential copy inside images. Do not infer a target country or page language from the seller’s location or the fact that the business exports.
Make navigation and calls to action work. Connect buttons only to verified destinations or implemented interactions. Connect inquiry forms, checkout, or other dynamic features to a working backend when requested. Show success only after the relevant service confirms the operation. Use supplied contact links or clearly identify demo-only behavior when no service is connected.
Design for narrow screens first: stack columns naturally, preserve readable text, avoid horizontal overflow, and make controls easy to tap. Use semantic headings, visible keyboard focus, descriptive labels, sufficient contrast, and reduced-motion support. Keep body text around 16 px by default and avoid tiny text for important product details.
Before uploading a newly created or revised page, review desktop and mobile views when a browser is available. Check visual hierarchy, alignment, spacing, image cropping, readable specifications, and the primary action. Fix obvious layout defects before publication; report any visual checks that could not be performed.

File size and command

The developer specifies a maximum of 20M. Because decimal MB versus binary MiB has not been specified, the helper conservatively checks 20,000,000 bytes; this is not a claim about the server’s exact byte threshold. Reduce oversized files instead of splitting them or attempting multipart upload.

Basic usage: oo website upload <HTML-path>, for example oo website upload ./a.html. Add --json for structured output in automated workflows.

Execution

Prepare the final HTML and inspect it: python3 "<skill-dir>/scripts/deploy_single_html.py" check "/absolute/path/index.html" Resolve errors and record contentLength and sha256. This conservative static scan cannot prove that arbitrary dynamic JavaScript has no dependencies; review import, fetch, Worker, and dynamic URLs.
Use the native ooCLI website command directly, without connector discovery: oo website upload "/absolute/path/index.html" --json Add --team "<team>" only when the user specifies a team. Do not read local credentials or manually request signatures or perform PUT uploads. The command completes the upload and returns top-level fileName, fileSize, and url fields. Read response.url as the public address.
Immediately save the response and local sha256 in this task’s deployment record. Do not announce completion yet. Do not modify the file during signing or upload.
Verify the published content: python3 "<skill-dir>/scripts/deploy_single_html.py" verify "/absolute/path/index.html" --url "<response.url>" Require HTTP 200, text/html, no attachment disposition, and response bytes matching the local SHA-256.
If the helper returns 403, use an available browser to navigate to the same URL and inspect the main document status, Content-Type, and raw response SHA-256. Accept verification only when that evidence meets the same criteria. Record that the script received 403 while browser verification passed; do not speculate about the cause. Do not change authentication, fabricate credentials, or upload again.
When browser tools are available, check rendering, mobile layout, and key interactions. Record HTTP verification and browser interaction checks separately. If HTTP verification fails and no browser is available, report uploaded_unverified and preserve the URL.
Deliver a clickable public URL with a concise verification result and material limitations. State which interactions were actually checked. Retain a non-sensitive deployment record. Published pages and their URLs are long-term and have no preset expiration, as confirmed by the service owner. Do not volunteer expiration or invalidation warnings in routine delivery. Do not claim deletion or replacement support without a verified command.

Failure and recovery

Missing oo website: report that this CLI lacks the command and needs updating; do not fall back to generic temporary file uploads.
Authentication, permission, billing, or input errors: report the actual output without blind retries.
Upload timeout without a returned URL: treat the result as uncertain, preserve the output, and do not automatically create another object.
URL returned but access verification failed: mark uploaded_unverified and verify the same address through read-only requests before considering another upload.
Local content changed: the existing URL represents the earlier content. When asked to publish the revision, inspect and upload the new file and retain the new address.

Reference

See references/api-contract.md for the verified CLI contract and live validation evidence. This skill uses a native non-connector command and does not depend on connector search results.