ethotechnics.org

This repository powers ethotechnics.org, the home of Ethotechnics. Ethotechnics is the engineering discipline concerned with keeping capability, authority, evidence, dependency, standing, and correction coupled tightly enough that increasing machine agency does not silently become unreviewable institutional power. Its central claim: institutions absorb the evidence that their automated systems are wrong (a worker quietly fixes the error, an appeal settles one case, and the rule never changes). Ethotechnics names that mechanism, scores it in public cases, and specifies the records that carry the evidence back to the rule in any institution that adopts them. The site publishes proposed standards, mechanisms, diagnostics, and a glossary that make those states explicit and reviewable. The project favors lean, fast-loading pages and clear storytelling.

Live site: https://ethotechnics.org

Canonical Repository: This repository powers the authoritative public site at ethotechnics.org. Legacy traffic from ethotechnics.com is permanently 301-redirected here via zz-plant/et.

• Standards. Citable, versioned specifications with numbered clauses, from temporal rights and contestability through the delegation record, STD-08 Delegation, and STD-09 Agent chains.
• Laws. Twelve laws of delegated intelligence, each with the invariant the standards bind, at /standards/laws. The method that walks the chain and the six safeguards is at /method.
• Mechanisms. Operational blueprints for the controls the clauses call for: decision logs, kill switches, appeal paths, authority grant registers, dependency ledgers.
• Evals. Governability evaluation suites and test cases that ask whether a deployed system is correctable, not whether a model is capable.
• Diagnostics. Delegation self-assessment, record conformance checking, and burden measurement. The self-reported audit does not verify the evidence.
• Glossary and taxonomy. Canonical definitions and a branch structure for authority, dependence, governance, delivery, assurance, and experience.
• A machine-readable API. JSON and JSONL surfaces at /api, JSON Schemas under /standards, plus llms.txt, llms-full.txt, and an agent spec.

1. Install dependencies: bun install
2. Run the dev server: bun dev (opens local Astro server)
3. Run default PR validation: bun run check
4. Build the Worker bundle: bun run build
5. Preview build: bun run preview (Astro) or bun run preview:cf (Wrangler with local Cloudflare bindings)

For one-shot Codex bootstrap, run bun run setup:codex. For deeper setup tips, see docs/local-development.md.

The following paths are generated and safe to delete locally when you want to reclaim disk space:

• dist/, .astro/, .vercel/, coverage/
• test-results/, playwright-report/, blob-report/, playwright/.cache/, playwright/.auth/
• astro_check_log.txt
• node_modules/ (recreated with bun install)

Use bun run clean for standard output cleanup and bun run clean:all when you also want to remove dependencies and Playwright caches.

• After installing dependencies, run bunx playwright install --with-deps to install browser binaries and system packages.
• bun run test:e2e builds the Worker bundle and runs Playwright against bun run preview across Chromium, Firefox, and WebKit.
• bun run test:e2e:smoke and bun run test:e2e:ci run the same flow on Chromium only for faster PR and CI validation; run the full three-browser matrix locally before release.
• Use bun run preview:cf when you need to validate Worker runtime behavior (Durable Objects, bindings, or Workers KV) locally.
• Override the preview target with PLAYWRIGHT_BASE_URL (defaults to http://127.0.0.1:4321).
• Cloudflare Pages can run the suite using CF_PAGES_URL; enable testing in the dashboard to run Playwright after the Worker build.
• If Playwright browser downloads fail:
  • Reuse cached downloads with PLAYWRIGHT_BROWSERS_PATH=~/.cache/playwright.
  • Confirm proxies or firewalls are not blocking https://playwright.azureedge.net.
  • Use a mirror via PLAYWRIGHT_DOWNLOAD_HOST=https://your-mirror.example.com.

• bun test runs the test suite.
• Component tests run under Bun with happy-dom helpers.
• CI uses bun run test:unit:ci to execute once with coverage.

• Copy .env.example to .env.local for local development. Astro automatically loads .env, .env.local, and environment-specific files (such as .env.development).
• No environment variables are required today, but add new entries to .env.example if the project adopts external services.

Requests pass through src/middleware.ts, which redirects www.ethotechnics.org to the apex and appends a hardened header set to every response:

• HSTS (Strict-Transport-Security): one-year max age with subdomains and preload to enforce HTTPS everywhere.
• Content-Security-Policy: locks content to self, blocks frames and plug-ins, restricts styles to the site origin, and permits images from the site, https: origins, or data: URLs.
• Referrer-Policy: no-referrer to avoid leaking navigation history.
• X-Content-Type-Options: nosniff to disable MIME-type sniffing.
• Permissions-Policy: disables camera, geolocation, microphone, and payment features.

The site uses the official Cloudflare adapter for Astro to produce a Worker-compatible server build. wrangler.toml captures the base Worker name and compatibility settings; the generated dist/server/wrangler.json captures the built entrypoint (dist/server/entry.mjs) and assets. Session storage is not enabled by default; if you add it later, define the KV binding in wrangler.toml before deploying.

1. Ensure the adapter is installed (@astrojs/cloudflare) and configured in astro.config.mjs with output: "server".
2. The adapter is configured to use Cloudflare's image service and to exclude static assets (/_astro/*, /assets/*) from the server function so they can be served directly via the assets binding.
3. Build the Worker bundle with bun run build when you need to preview or inspect the output. The generated Worker entry is emitted to dist/server/entry.mjs, and the build runs patch:cf-worker so the generated Astro app renders buffered HTML under nodejs_compat.
4. Deploy with Wrangler using the repo defaults: bun run deploy.
   • The deploy script runs Wrangler via bunx, so no global installation is required.
   • The deploy script runs bun run build first so the upload always reflects the latest bundle.
   • The deploy command uses the generated dist/server/wrangler.json so Wrangler uploads the server entry and the matching dist/client assets together.
   • The build copies .assetsignore from public/ to dist/client so Wrangler only serves client assets from the asset binding.
5. Configure DNS for ethotechnics.org to point to the Cloudflare Worker route you set in Wrangler.

• Start with docs/README.md for how the docs folder is organized, when to add a new guide, and formatting expectations.
• docs/contributor-workflow.md outlines the change loop, required checks, and formatting conventions for day-to-day work.
• docs/architecture.md covers the rendering model, middleware, and Cloudflare Worker deployment. Update it when routing, layouts, or adapters change.
• docs/specifications.md provides a high-level snapshot of site goals, routing, and delivery defaults.
• docs/adding-pages.md walks through creating new Astro routes without breaking shared navigation and metadata. Use it as the checklist for new content.
• docs/page-specifications.md lists route-by-route expectations for data, layout, and accessibility.
• docs/content-data.md documents JSON-backed content sources, schemas, and validation steps.
• docs/content-components.md catalogs the page intro, section blocks, cards, and other building blocks reused across routes. Extend it when adding shared UI.
• docs/local-development.md captures local setup, previews, and troubleshooting tips.
• docs/cloudflare-playwright.md captures how to run the Playwright suite on Cloudflare Pages after the Worker build completes and how to surface test results in that environment.
• docs/testing-todos.md tracks current test coverage and outstanding gaps to prioritize.
• docs/glossary.md defines shared terminology used across the site and docs.
• docs/diagnostics-outputs.md collects diagnostics output references; docs/reviews/usability-audit.md is the dated UX review snapshot.

• src/pages: Astro routes, starting with src/pages/index.astro for the homepage content.
• src/layouts: Shared layouts such as src/layouts/BaseLayout.astro, which wires global SEO, fonts, and the navigation shell.
• src/components: Interactive islands and shared UI components such as the navigation in src/components/Navigation.astro.
• src/styles: Global styles and theme tokens defined in src/styles/global.css.

• Start with CONTRIBUTING.md for the canonical contribution workflow.
• Keep changes focused and easy to review; align with existing naming and formatting.
• Use Bun (not npm or yarn) and format Markdown/code with bunx prettier --write.
• Run bun run check for code or mixed changes; run bun run check:full for release prep or periodic deep validation. Docs-only updates can skip both.
• CI mirrors bun run check on pull requests via the Site checks workflow.
• Read AGENTS.md, docs/README.md, and CODE_OF_CONDUCT.md before making larger updates.
• Track version history and release notes in CHANGELOG.md.

This project is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license (CC BY-SA 4.0). Unless otherwise noted, you may share and adapt the content with proper attribution and under the same license terms. See https://creativecommons.org/licenses/by-sa/4.0/ for details.