Build a Swiss-minimal law or accounting firm site with strong trust signals

Build a Swiss-minimal, multi-page static site for our practice on my Opus Growth hosting server [server name]. Practice: [practice name], [profession, e.g. law firm or accounting practice], [city]. Practice areas: [areas]. Practitioners: [for each, name, title, bar or chamber they are registered with, registration number, areas]. Phone: [phone], email: [email], address: [address], domain: [domain]. Guidance note topic: [a frequently asked topic, e.g. the legal cap on rent increases]. This is a field where people make decisions about their money and their rights, so trust has to come from clarity, credentials and sources, not decoration. Respect the professional rules: for lawyers in Turkey the Union of Turkish Bar Associations' advertising ban regulation, for accountants TÜRMOB's professional rules, or the equivalent where you practise. Do not write success rates, numbers of cases won, client names, superiority claims such as "best" or "leading expert", fee comparisons, guarantees or exaggerated promises. Present information with a note that it is general and does not replace legal or financial advice. The design direction is Swiss-minimal: 1. Type: one grotesk family from Fontshare (e.g. Switzer 400, 500, 600). Hierarchy comes only from size and weight: a large, tight, left-aligned heading, calm body text, small section labels. 2. Colour: white background, near-black text, one dark grey and a single accent (e.g. Swiss red). The accent appears only on the section mark, labels and the focus ring. Photos are black and white (Tailwind grayscale). 3. Grid: a strict 12 columns. In every section the label sits in columns 1 to 3 and the content in 4 to 12; sections are separated by a 1-pixel black rule. No rounded corners or shadows. 4. Signature element: section labels numbered with a § mark in the accent colour, and faint 12-column guide lines drawn in CSS only behind the first screen. 5. Motion: none. Pages and their schema: 1. index.html: a first screen whose opening paragraph answers "which matters, for whom, where", the practice areas, how you work and how fees are set (no figures, the official tariff and a written engagement letter), the latest guidance note, a team summary. WebPage. 2. calisma-alanlari.html: one section per area; the first paragraph answers the most common question in that area, followed by the main topics and the legal basis. A Service per area. 3. ekip.html: a profile for each practitioner (name, title, bar or chamber, areas, short biography). AboutPage and a Person per practitioner (jobTitle, knowsAbout, worksFor #business, memberOf the bar or chamber). 4. bilgi-notlari/[topic].html: a note grounded in the statute that opens with a short answer. At the top: author, reviewer, publication date and last review date; at the end a list of sources. Article (author and publisher via @id, image, datePublished, dateModified, citation) and reviewedBy plus lastReviewed on the WebPage. Never write a legal or financial point you do not know; ask me about every sentence you are unsure of. 5. sss.html: six real questions, FAQPage. 6. iletisim.html: ContactPage. 7. kvkk.html (mentioning professional confidentiality) and 404.html. Technical rules. Follow them exactly, because the gates below measure exactly these: 1. Setup. Run scaffold_site as a preview first, show me the file list, and install with confirm=true after I approve. Then read site_design_guide and site_seo_guide in full. Before writing any code, write the direction in _kaynak/ART.md (feel, font pairing, colours with contrast ratios, grid, signature element, motion decision, page list) and show it to me. 2. Strip out JavaScript. No page on this site loads any JavaScript. Remove from every page the cdn.tailwindcss.com script, the tailwind.config line, the GSAP, ScrollTrigger, SplitText, Lenis and Swiper tags and the motion.js, chrome.js and site.config.js script tags; delete assets/chrome.js and assets/motion.js. Keep assets/site.config.js, but only as the brand, contact and seo source for seo-stamp.mjs; it is never loaded in the browser. 3. Menu and footer are static HTML. The <site-nav> and <site-footer> components are drawn by JavaScript, so search and AI crawlers cannot see the menu, the internal links or the contact details. Write the header to _kaynak/ust.inc and the footer (name, address, phone, email, every page link, privacy notice, "Web: Opus Growth") to _kaynak/alt.inc. Use the .inc extension so seo-stamp and html-validate do not treat the fragments as pages. Every page carries the markers <!-- ust:bas --><!-- ust:son --> and <!-- alt:bas --><!-- alt:son -->. Then write a dependency-free Node script with site_write_file at _kaynak/parca-bas.mjs: it stamps both fragments between the markers in every HTML file, adds aria-current="page" to the current page's menu link, and rewrites sitemap.xml using each page's JSON-LD dateModified as lastmod (skipping 404 and noindex pages). Build the mobile menu without JavaScript using <details><summary>Menu</summary>; the desktop and mobile menus are two separate <nav> elements with different aria-labels. 4. Host the fonts yourself. This site uses one font family and three files at most. Download the Fontshare CSS (https://api.fontshare.com/v2/css?f[]=family@400,600&display=swap, weight code 401 for italic) with site_fetch to _kaynak/fontshare.css, read it with site_read_file and take only the woff2 URLs of the family you asked for; the service sometimes appends a family you did not request. Download each woff2 with site_fetch into assets/fonts/. Put the @font-face rules (font-display: swap) inside assets/app.css, because design-check.mjs only looks for a custom font in that file. Do not use the default Inter, Roboto, Poppins or Montserrat. 5. Compile Tailwind. assets/app.css becomes the Tailwind source: @tailwind base; @tailwind components; @tailwind utilities; at the top, then @font-face, the focus ring, the skip link, a prefers-reduced-motion rule and your own component classes inside @layer components. Never give a component class the name of a Tailwind utility (list-item, table, grid, container, hidden and so on), because the clash silently breaks the layout after compiling. Write tailwind.config.js at the root (content: ["./*.html", "./**/*.html", "./_kaynak/*.inc"], colours and fontFamily). Run "npx --yes tailwindcss@3 -i assets/app.css -o assets/site.css --minify" with site_run_command and background=true, and wait for it with site_command_status. Every page <head> holds, in this order: a single <link rel="stylesheet" href="/assets/site.css">, then one preload line for every font file used on the first screen (heading, accent and body; as="font" type="font/woff2" crossorigin). Preload lines placed before the stylesheet delay the CSS and lengthen LCP; a first-screen font left without preload swaps late, shifts the page and raises CLS, and <link rel="icon" href="/assets/img/favicon.svg" type="image/svg+xml">. The favicon line is required: without it the browser asks for /favicon.ico, gets a 404, and the console error lowers Best Practices. 6. Images. Download photos with site_fetch using resize and image_format="webp" at several widths (480, 800, 1200 and 1600 for the first-screen image, 480, 800 and 1200 for the rest; quality between 60 and 75, lower for detailed photos). Every <img> has srcset, sizes that match the real layout, width and height (zero CLS) and a meaningful, honest alt text. fetchpriority="high" goes only on the image Lighthouse reports as the LCP element, and that image is not lazy; every other image uses loading="lazy". If the LCP element is text, no image gets fetchpriority. Also prepare assets/img/logo.png, a 1200x630 assets/img/og.jpg and assets/img/favicon.svg. 7. HTML rules (html-validate defaults). <!DOCTYPE html> in upper case; no inline style attribute (including the kit's style="background:var(--brand)", use a class instead); &nbsp; instead of plain spaces in the text of tel: links; a type on every <button>; no trailing whitespace; tables with <thead>, <tbody> and th scope. Links inside paragraphs are underlined; menu, footer, breadcrumb and button links have a touch area of at least 44x44 pixels (min-h-[44px] min-w-[44px]). 8. Structured data. Fill the seo block in site.config.js (siteUrl, description, logo, og image, business type, address fields) and run "node seo-stamp.mjs" with site_run_command; it stamps Organization, WebSite and, where relevant, a LocalBusiness subtype, plus canonical and OG tags. Add page-specific schema by hand: on every page a WebPage node with an @id (or AboutPage, ContactPage, CollectionPage, ProfilePage), datePublished and dateModified, isPartOf #site, about #business or #org, and breadcrumb pointing to a BreadcrumbList; plus a Service per practice area, a Person per practitioner on the team page, Article and reviewedBy on the guidance note, and FAQPage on the FAQ page. Write each node in its OWN <script type="application/ld+json"> block and do not use an @graph wrapper, because seo-check.mjs only reads the top-level @type and misses a BreadcrumbList inside @graph. Link the nodes with @id. Never invent opening hours, coordinates, ratings, reviews, awards, customer counts or certificates; leave unknown fields out. 9. AI access. Write robots.txt: the whole site open, only /_kaynak/ closed; Allow: / for GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended and Bingbot; your decision on CCBot with the reason as a comment; the Sitemap line last. Add llms.txt at the root: a correct two-sentence summary of the business, the important pages with one line each, and contact details. Write 404.html (noindex, with the header and footer markers). 10. Writing. Each page has at least 150 words of original text inside <main>, and the first paragraph answers the page's main question directly. Titles are 48 to 60 characters, descriptions 145 to 158, unique on every page. No em dashes or en dashes, no stock slogans, no empty promises. If anything on the site is not real, say clearly that it is fictional. Gates. After every change, run these with site_run_command in this order and do not move on until each one is clean: 1. node _kaynak/parca-bas.mjs, node seo-stamp.mjs, the Tailwind build (again if you added classes). 2. node seo-check.mjs: 0 errors and 0 warnings. If it warns "gövde kısa" (body too short), add real text, not filler. 3. node design-check.mjs: 0 errors. The only warning may be "Hiç hareket yok" (no motion); the style calls for it, so give the reason in the report. 4. npx --yes html-validate "**/*.html": 0 errors. 5. Look at every page with site_preview at view="mobile" and view="desktop", and check the home page at 360 and 768 pixels as well. Fix any horizontal overflow, cramped heading or touch target smaller than 44 pixels and look again. 6. Measure every page with core_web_vitals at strategy="mobile" and strategy="desktop", then audit the home page and the longest page with seo_audit. Target: on mobile, Accessibility, Best Practices and SEO 100 and Performance at least 95; on desktop all four at least 95. Not a single request may leave the site. If LCP is high, use resources=true to find the file holding it back: usually preload lines placed before the stylesheet, or fetchpriority given to an image that is not the LCP element. If CLS exceeds 0.1, look for a first-screen font that is not preloaded. Do not call the job done until all of these pass. After publishing, submit https://[domain]/sitemap.xml with gsc_submit_sitemap and check the home page with gsc_url_inspect. If there is no Search Console property, tell me; do not try to connect one yourself. Hand-over report: a table with the four Lighthouse scores and LCP per page on mobile and desktop, the result of the four gates, the reason behind any design-check warning, a list of information on the site that is fictional or missing, and what I still