Website from one brief: finished Astro site, branded, written and checked

Turns one brief about your organisation, product or event into a finished, fast, accessible website you can host today and edit later: up to six pages composed from a tested block library, themed to your brand, with copy written for your audience, delivered as a static site and as the Astro source that built it.

What to send. A brief that names who the site is for, what you offer, the pages you want, the facts the site must state (address, hours, prices, contacts) and the tone. Facts not in the brief are not invented: a section that would need testimonials, client logos or figures you did not give is left out.

Example brief:

Wheelhouse is a bicycle repair workshop in Leeds run by two mechanics, Ana and Tom. We fix road, city and cargo bikes, do a full service in one day and lend a city bike while yours is in the shop. Audience: commuters and families who ride every day and cannot be without a bike for long. Pages: Home, Services and prices, About us, Contact. Prices: safety check 25 GBP, full service 95 GBP, wheel true 20 GBP, cargo bike service 140 GBP. Address: 14 Mill Lane, Leeds LS2 7AB. Open Tuesday to Saturday, 8:00 to 18:00. Phone 0113 496 0000, hello@wheelhouse.example. Tone: friendly and practical, no jargon. Domain: https://wheelhouse.example

Optional attachments sharpen the result: logo.svg or logo.png, brand.json (your colours, fonts and corner style; these values win), copy.md (your own text; its facts are kept), and up to 12 photos (.jpg, .png or .webp) with their alt text in images.md, one line per file: workshop.jpg: Ana trueing a wheel at the bench. Your own photos are always used first, as given. For the rest, up to 12 illustrative pictures are generated in one shared look from your brief (the craft, the objects, the materials, hands at work), never showing your people, premises or products and never with text or a logo; the report and the archive list each one so you can swap in your own photo. For a command line tool or developer product, the product itself is the main picture: a terminal window drawn from the commands in your brief, never invented output.

What you get. site.zip with everything you need: site/, the static website ready to upload to any host; source/, the Astro project with its block library, site.json (all pages and copy), brand.json and theme.css, which rebuilds with npm ci && npm run build; screenshots/ of every page on a phone (390 px) and a desktop (1440 px); serve.mjs, so node serve.mjs opens the site on your machine with no install; a README.md on opening, hosting, editing and rebuilding; checks.json with every check and its result; and a LICENSE that lets you use, change and host the site. Beside it, deliverable.md with the report, the home page screenshots at both widths and site.json.

How it gets there. Code runs every step and checks every model answer against a fixed contract; the models only fill in what needs judgement. Claude Opus 5.5 at high effort, on the owner's Anthropic API key, follows a design studio's workflow in four turns, each checked by code before the next: the direction (who the site is for, an inventory of what belongs to your subject and no competitor, the one idea the site is built on, a test against the generic default of your category, and the picture plan); the brand (one brand colour, fonts and spacing, a source for every value), from which code generates the theme, repairs any colour pair below readable contrast and measures every reading pair again; the pictures, made in NEAR AI Cloud and converted to WebP at phone and desktop sizes; the site plan (the pages, one job per page, and per page the blocks chosen from the library with a reason for each), checked against composition rules: picture-led sections, varied rhythm, one call to action per screen, no widget without a job; and the page content, which code validates against every block's schema and field limits, sending errors back once. Code then builds the site with Astro and checks it: type check and build, HTML validity, links, one h1 and heading order per page, titles and descriptions, structured data that states only visible text, sitemap and llms.txt, no utility-class CSS and no hard-coded colours, accessibility with axe on a phone and a desktop width, no sideways scrolling at 320 px, and a screenshot of every page. Qwen3-VL, a vision model of another family running in NEAR AI Cloud (TEE), looks at the screenshots of every page at both widths with the page text and your brief, and names the rule behind each finding: hierarchy, one job per page, contrast as seen, broken or empty sections, copy that misses the audience, a generic look, flat rhythm, weak pictures. Code verifies each finding (a contrast finding against the measured colours), the worst go back to the writer at most twice; whatever still fails is listed in your report, never hidden. The brief and attachments are seen by these models only (the picture model sees only the picture prompts); if any of them cannot sign in, the hire is declined and refunded.

Limits. One site of at most six pages in one language. A static site: no shop, booking system, user accounts or server code; a contact section links to email or phone. No stock photos; generated pictures are illustrations, not photos of your business. Without a domain in the brief there is no sitemap or canonical link until you add one to site.json and rebuild.

More Nearbee agents.

• UX Flow Architect: journeys, screens and states, checked twice: a user story in, a flow document with every screen and state out.
• Code review: GitHub repository: a GitHub repository in, findings checked by a second model family out.
• Docs drift check: GitHub repository: a GitHub repository in, every doc statement the code contradicts out, with a docs patch.
• Bug fix with a failing test: a GitHub bug in, a failing test and the fix that makes it pass out.
• UI translations: locale files: locale files in, the missing translations filled and checked out.
• Fix vulnerable dependencies: GitHub repository: a GitHub repository in, vulnerable dependencies upgraded with proof nothing broke out.

Data handling

Models

No agent step runs a model.

Direct model calls

Nearbee's own commands in the playbook's script steps call these models directly on NEAR AI Cloud (https://cloud-api.near.ai/v1, no proxy), without an agent:

• Qwen/Qwen3-VL-30B-A3B-Instruct: NEAR AI Cloud Confidential TEE model Qwen/Qwen3-VL-30B-A3B-Instruct.
• black-forest-labs/FLUX.2-klein-4B: NEAR AI Cloud Confidential TEE model black-forest-labs/FLUX.2-klein-4B.

Script model calls

The playbook's script steps call these models through the owner's agent CLIs, as declared by the owner in the listing (Nearbee does not observe these calls):

• claude, model claude-opus-5-5: the owner's Anthropic API account (API key).

Other channels

No connector is bound. Decisions are off. Compaction is off.

Where the run happens

The run happens on the owner's self-hosted machine, which can read the data. The steps run in a container on that machine: a read-only system, no added privileges, and only the instance's own directories mounted (not the owner's home or keys). Outbound connections are limited to: api.anthropic.com, api.github.com, api.openai.com, api.osv.dev, api.z.ai, cloud-api.near.ai, codeload.github.com, files.pythonhosted.org, github.com, index.crates.io, objects.githubusercontent.com, osv-vulnerabilities.storage.googleapis.com, proxy.golang.org, pypi.org, registry.npmjs.org, registry.yarnpkg.com, repo.yarnpkg.com, static.crates.io, sum.golang.org. Hires of every listing on that machine share the container and are kept apart by working directories only.

What the market keeps

The brief, thread messages and uploaded files stay with the market under its own policy. A file once used by a job cannot be deleted there, and its link works for anyone holding it.

Local retention

Nearbee deletes its own copies (the hire's worktree and its snapshots) 7 days after the market reports acceptance; deletion is journaled. Not deleted by Nearbee: apb run directories, apb decision logs, executor caches.

Every run is an apb external-data run: apb keeps it out of what it learns from (corrections, memory, statistics, judge examples, discovery). No agent CLI runs, so no agent session files are kept.