create-zudo-circuit-doc 0.1.0

package/templates/default/doc/src/chrome-bindings.tsx

@@ -0,0 +1,11 @@
+// ADR-016 seam: registers the package's MDX components (EvidenceAnchor,
+// EvidenceDetails, EvidenceFact, EvidenceTable, ComponentReferences,
+// PackageModelViewer) with zudo-doc's chrome, so generated component pages
+// can use them with no import. Referenced by `zfb.config.ts`'s
+// `chromeBindingsModule`.
+import { defineChromeBindings } from "@takazudo/zudo-doc/chrome-bindings";
+import { circuitDocMdxExtras } from "@takazudo/zudo-circuit-doc/mdx-extras";
+
+export const chromeBindings = defineChromeBindings({
+  mdxExtras: { ...circuitDocMdxExtras },
+});

package/templates/default/doc/src/content/docs/architecture/index.mdx

@@ -0,0 +1,11 @@
+---
+title: "Architecture"
+description: "How the circuit is divided into functional blocks, interfaces and operating states."
+sidebar_position: 1
+---
+
+This section explains the circuit's structure: what each block is responsible for, how blocks connect, and which states the design moves through. It describes intent and rationale; exact component facts stay in the component evidence records.
+
+- [Architecture overview](./overview.mdx) is the current proposal. Nothing has been chosen yet.
+
+When blocks or connectors are proposed, add an interfaces page by copying `circuit/templates/project-docs/architecture/interfaces.mdx` into this directory.

package/templates/default/doc/src/content/docs/architecture/overview.mdx

@@ -0,0 +1,55 @@
+---
+title: "Architecture overview"
+description: "Functional blocks, operating states, design boundaries, and unresolved architecture questions."
+sidebar_position: 10
+---
+
+This page describes the architecture as it is proposed. No topology, component, board split, power source, or operating limit has been chosen yet.
+
+## Intended behavior
+
+Summarize the user-visible behavior from the [project brief](../project/index.mdx). Explain which physical or electrical functions are required to produce it.
+
+## Functional blocks
+
+| Block ID | Responsibility | Receives | Produces | Current design basis |
+|---|---|---|---|---|
+| Not entered | Not entered | Not entered | Not entered | Requirement, proposed approach, or decision reference |
+
+Start with responsibilities rather than IC names. Introduce selected components only after the relevant evidence and decision exist. If a diagram adds clarity, derive it from these same blocks and their interfaces; do not let a diagram silently introduce another net name or voltage domain.
+
+## Physical partitioning
+
+Describe the proposed physical arrangement: boards, external modules, cables, enclosure, mounting surfaces, and any user-accessible conductors. State why each boundary exists and whether it is fixed or still a candidate.
+
+| Boundary | Reason for separating it | Consequence for assembly or testing | Decision reference |
+|---|---|---|---|
+| Not entered | Not entered | Not entered | Not entered |
+
+Do not assume that a visually convenient board split is electrically or mechanically neutral. Record the interface work it creates in the interface page (copy `circuit/templates/project-docs/architecture/interfaces.mdx` when the first interface is proposed).
+
+## Operating states and transitions
+
+| State | How it is entered | Required outputs or behavior | Defaults and stored configuration | Evidence or test still needed |
+|---|---|---|---|---|
+| State not yet defined | Not entered | Not entered | Not entered | Not entered |
+
+Consider only states that apply to this project. Possibilities include unpowered, initial connection, reset, normal operation, deliberate shutdown, service/programming, and recovery from interrupted power. Delete inapplicable cases after recording why they do not apply.
+
+Defaults deserve explicit evidence. Separate manufacturer-documented defaults, intended programming, actual readback, firmware initialization, and observed hardware behavior.
+
+## Project envelopes and calculations
+
+| Analysis question | Related blocks | Required inputs | Evidence or calculation reference | Current limitation |
+|---|---|---|---|---|
+| Not entered | Not entered | Not entered | Not entered | Not entered |
+
+Keep exact component limits in the component evidence bundle. Link any cross-component calculation with its input facts, units, conditions, and current design revision. An operating target, a recommended range, a typical value, an absolute maximum, a simulated result, and a measured result are different kinds of information.
+
+If an analysis uses an assumed source impedance, load, thermal condition, tolerance, or configuration, state it next to the conclusion. A calculation cannot close a hardware question it did not model.
+
+## Architecture choices still open
+
+List choices that could change the block structure, interfaces, layout, firmware, or procurement. Link each to [next actions](../project/next-actions.mdx) and name the evidence or owner decision needed to close it.
+
+When a choice is made, capture the alternatives and conditions in a [decision record](../decisions/index.mdx). Keep the architecture page current and preserve the historical reasoning in the decision.

package/templates/default/doc/src/content/docs/components/catalog/index.mdx

@@ -0,0 +1,12 @@
+---
+# GENERATED by @takazudo/zudo-circuit-doc — do not edit; run `zudo-circuit-doc generate`
+title: "Catalog"
+description: "Every published component record with its orderable identity, board placements and evidence state."
+sidebar_position: 2
+---
+
+Generated from the component evidence records — edit the records, not this page.
+
+Every component record this project publishes, in the order the bill of materials lists them, with each subordinate record directly after the part it belongs to. The identity, placement and state columns are projected from stored evidence; the record pages behind them carry the facts, sources and coverage themselves.
+
+No component record is published yet. Add the first exact component with Workflow B in `circuit/WORKFLOW.md`, then select it in `circuit/publication/selection.json`.

package/templates/default/doc/src/content/docs/components/index.mdx

@@ -0,0 +1,49 @@
+---
+# GENERATED by @takazudo/zudo-circuit-doc — do not edit; run `zudo-circuit-doc generate`
+title: "Components"
+description: "Human reference projected from this project's validated component evidence."
+sidebar_position: 1
+---
+
+Generated from the component evidence records — edit the records, not this page.
+
+This section publishes the validated component evidence this project already holds as structured data. Every value below is projected from that data — nothing here is re-typed, summarised into a grade, or reconciled by hand.
+
+No component record is published yet. Add the first exact component with Workflow B in `circuit/WORKFLOW.md`, then select it in `circuit/publication/selection.json`.
+
+## How to read these pages
+
+- **Per-domain, never per-part.** Coverage is stated one domain at a time. There is no component-wide pass/fail verdict, and the absence of an open domain is not a safety claim.
+- **Verdicts keep their exact wording.** A distributor-confirmed identity and a primary-source confirmation are different verdicts and are shown as different verdicts.
+- **Open means unresolved, not unsafe.** An open domain names the reason it is open and the exact facts that block it.
+- **Sources may be unavailable.** A source recorded as unavailable stays visible so the gap is auditable rather than invisible.
+
+## Corpus
+
+<EvidenceAnchor id="components-corpus" />
+
+| Item                  | Count |
+| --------------------- | ----- |
+| Owner bundles         | 0     |
+| Records               | 0     |
+| Standalone records    | 0     |
+| Subordinate records   | 0     |
+| Evidence sources      | 0     |
+| Facts                 | 0     |
+| Coverage domains      | 0     |
+| Interactions          | 0     |
+| Pin maps              | 0     |
+| Pins                  | 0     |
+| Inventory lines       | 0     |
+| Fitted lines          | 0     |
+| DNP or hand-fit lines | 0     |
+
+## Raw agent resources
+
+Every page in this section is projected from a stored evidence bundle and does not restate it. The bundles are the source of truth: where the two disagree, the bundle is right and the projected page is stale. Each record page links to its own owning bundle; the whole published set starts here.
+
+[Browse the raw agent resources](/docs/claude/)
+
+## Sections
+
+<CategoryNav category="components" />

package/templates/default/doc/src/content/docs/components/integration/index.mdx

@@ -0,0 +1,34 @@
+---
+# GENERATED by @takazudo/zudo-circuit-doc — do not edit; run `zudo-circuit-doc generate`
+title: "Integration"
+description: "Cross-component rules. None is currently published."
+sidebar_position: 4
+---
+
+Generated from the component evidence records — edit the records, not this page.
+
+A component record answers questions about one part. These rules answer the ones that span several — whether a divider built from two resistors keeps a third part inside its own limit, whether a clamp event stays under everything downstream of it. Each rule is projected whole from stored evidence: its conditions, the exact facts it rests on, any conditioned arithmetic, and the exact wording of what it refuses to conclude.
+
+## How to read these rules
+
+- **The refusal is the rule.** — Every rule states, in its own words, what may NOT be concluded from the evidence above it. That sentence is the rule's real output; the verdict is shorthand for it.
+- **A verdict belongs to the rule, not to a part.** — A rule's verdict says how far the cross-component question has been settled. It is never a judgement about any of the parts the rule names, and the verdicts are never combined into one.
+- **Calculations are conditioned, and the conditions are the point.** — Each calculation publishes its expression, its inputs and the exact results that were recorded, together with the conditions under which the answer means anything. A result read without them is arithmetic mistaken for a measurement.
+- **Numbers here were carried, not computed.** — The expressions are published so a reader can redo the arithmetic. This page does not evaluate them — the results shown are the ones the evidence recorded.
+- **An evidence chain does not flow downhill.** — A stage being settled says nothing about any stage after it. A document confirming a limit is not a measurement of the assembled board.
+
+## Rules at a glance
+
+<EvidenceAnchor id="integration-index" />
+
+No cross-component integration rule is declared.
+
+## Legend
+
+What the recorded terms on this page mean, in ordinary words. The exact terms above are the ones that count; these descriptions explain them and never replace them.
+
+## Raw agent resource
+
+These rules are generated from a stored evidence bundle and do not restate it. The bundle is the source of truth: where the two ever disagree, the bundle is right and this page is stale.
+
+No owning bundle is identified in the published model, so no reciprocal link can be given.

package/templates/default/doc/src/content/docs/components/records/index.mdx

@@ -0,0 +1,14 @@
+---
+# GENERATED by @takazudo/zudo-circuit-doc — do not edit; run `zudo-circuit-doc generate`
+title: "Records"
+description: "Per-record evidence pages: facts, sources, coverage domains, pin maps and interactions."
+sidebar_position: 3
+---
+
+Generated from the component evidence records — edit the records, not this page.
+
+One page per published component record, each carrying that record's facts, sources, coverage domains, pin maps and interactions. They are ordered as the bill of materials orders them, with each subordinate record directly after the part it belongs to.
+
+To compare records against each other, start from the [catalog](/docs/components/catalog/).
+
+No component record is published.

package/templates/default/doc/src/content/docs/decisions/index.mdx

@@ -0,0 +1,9 @@
+---
+title: "Decisions"
+description: "Consequential design, component and sourcing choices, with alternatives and conditions."
+sidebar_position: 1
+---
+
+No decision has been recorded yet.
+
+For a consequential choice, copy `circuit/templates/project-docs/decisions/decision.mdx` into this directory with a topic-specific filename. For population and procurement choices, use `circuit/templates/project-docs/decisions/sourcing.mdx`. Keep superseded decisions and link them to the record that replaces them.

package/templates/default/doc/src/content/docs/project/how-we-work.mdx

@@ -0,0 +1,67 @@
+---
+title: "How we work"
+description: "The agent workflow this project follows, its templates and task examples, and where component evidence lives."
+sidebar_position: 3
+---
+
+This project is developed together with AI agents. Short requests such as "download this datasheet", "get the 3D model" or "check this spec" should leave durable, honest project knowledge behind: an exact identity, retained evidence, regenerated pages and a clear statement of what is still unknown.
+
+## The canonical workflow
+
+Every agent follows one file: `circuit/WORKFLOW.md`. The tool-specific entry files `CLAUDE.md` and `AGENTS.md` only point to it. It defines:
+
+- **Shared entry:** read the [project brief](./index.mdx) and [next actions](./next-actions.mdx), run `pnpm circuit:check` before editing, and route every request by exact manufacturer, complete part number, order code and project role.
+- **Seven workflows:** A, start a circuit; B, add or replace an exact component; C, find or download a datasheet or source; D, obtain a symbol, footprint and 3D model; E, verify a specification; F, record a bench result; G, handle a source or design change. Each ends with a stated "Done" criterion.
+- **Integration rules and publication policy:** cross-component rules are added only when a real interaction exists, and publishing a record is an explicit, reviewable selection change.
+- **A four-part completion report:** what was obtained or checked, the exact identity involved, what changed, and what remains with its reason.
+
+## Where things live
+
+| Kind of knowledge | Location | Edited by |
+|---|---|---|
+| Intent, rationale, decisions, plans, handoff | This site's Project, Architecture, Research, Decisions and Verification sections (`doc/src/content/docs/`) | People and agents |
+| Exact component evidence: sources, facts, verdicts, coverage, pin maps | One owner bundle per component under `.claude/skills/component-*/` | Agents, following the evidence contract |
+| Orderable identities and placements | `.claude/skills/component-spec-audit/references/inventory.json` | Agents |
+| Cross-component rules | `.claude/skills/circuit-spec-integration/references/rules.json` | Agents |
+| What is published | `circuit/publication/selection.json` and `circuit/publication/assets.json` | Agents, as a reviewed diff |
+| Component catalog and record pages | The Components section, generated from the evidence | The generator only |
+| Downloaded working copies of sources | `.circuit-cache/sources/` (not committed) | Agents |
+
+The evidence records are authoritative. When a page in this site and an evidence record disagree, the record is correct and the page needs updating. Generated component pages are never edited by hand.
+
+## Verdicts are explicit
+
+Component facts carry one of six verdicts: `PASS - primary-source confirmed`, `CONFIRMED - distributor identity only`, `BLOCKER - deterministic spec violation`, `NEEDS BENCH`, `UNSOURCED` and `NOT APPLICABLE`. There is no single pass/fail badge. A clean validation or a covered domain is not hardware sign-off; physical checks are recorded as verification reports.
+
+## Templates
+
+Authoring templates live in `circuit/templates/` and are not published. Copy one into this site when its activity happens:
+
+| Template | Use it for |
+|---|---|
+| `project-docs/project/task-request.mdx` | Delegating one bounded task to an agent |
+| `project-docs/project/change-impact.mdx` | A change with downstream effects |
+| `project-docs/architecture/interfaces.mdx` | Interface contracts, once blocks or connectors are proposed |
+| `project-docs/research/component-candidate.mdx` | One component research question |
+| `project-docs/decisions/decision.mdx` | One consequential choice |
+| `project-docs/decisions/sourcing.mdx` | Population and procurement choices |
+| `project-docs/verification/bring-up.mdx` | One verification plan or run |
+| `cad-asset-receipt.json` | Recording where a CAD asset came from and how faithful it is |
+
+The brief, next actions and architecture overview templates are already instantiated as live pages in this site. `circuit/templates/README.md` explains each template in detail.
+
+## Task examples
+
+`circuit/agent-task-examples.md` gives nine short requests in English and Japanese: download a datasheet, find and check a 3D model, verify a claimed specification, check an interaction, compare a replacement, implement a selected change, prepare a bring-up plan, turn bench observations into evidence, and continue the project from the handoff. Each names the workflow and commands it leads to.
+
+## Commands
+
+| Command | What it does |
+|---|---|
+| `pnpm dev` | Dev server, regenerating component pages as evidence changes |
+| `pnpm build` | Publish selected models, generate component pages, build the site |
+| `pnpm check` | Validate evidence and check that generated output is current |
+| `pnpm check:site` | Post-build reference, publication and link checks |
+| `pnpm circuit:check` | Validate the component evidence (offline) |
+| `pnpm circuit:generate` | Regenerate the component pages |
+| `pnpm circuit:doctor` | Report required and optional tools |

package/templates/default/doc/src/content/docs/project/index.mdx

@@ -0,0 +1,60 @@
+---
+title: "Project brief"
+description: "Purpose, intended behavior, constraints, and the current state of this circuit project."
+sidebar_position: 1
+---
+
+This is the project brief. Nothing has been entered yet. Describe the intended object and the experience of using it before selecting parts. Replace the prompts with project-specific statements as they become known.
+
+## Purpose
+
+| Field | Project statement |
+|---|---|
+| Project name | Not entered |
+| Intended user and setting | Not entered |
+| What the object does | Not entered |
+| Why this project exists | Not entered |
+| What a successful first prototype demonstrates | Not entered |
+| Current owner or maintainer | Not entered |
+
+Write one short scenario: what the user connects, touches, or observes; what the object does in response; and how the session ends. State which behavior is essential and which is a later experiment.
+
+## Scope and constraints
+
+| Topic | Requirement or preference | Basis | Still unknown |
+|---|---|---|---|
+| Power source and operating environment | Not entered | Owner request or evidence reference | Not entered |
+| Inputs, outputs and controls | Not entered | Owner request or evidence reference | Not entered |
+| Physical size, mounting and appearance | Not entered | Owner request or evidence reference | Not entered |
+| Assembly, sourcing and repair | Not entered | Owner request or evidence reference | Not entered |
+| Budget and prototype quantity | Not entered | Owner request or dated estimate | Not entered |
+| Firmware and development tools | Not entered | Owner preference or project decision | Not entered |
+
+A desired behavior is a requirement; an assumed component capability is a claim that still needs evidence. Keep that distinction visible. Mark preferences separately from constraints that would make a design unacceptable.
+
+## Current design state
+
+| Item | Current reference |
+|---|---|
+| Documentation revision reviewed | Not entered |
+| Schematic or circuit specification revision | Not entered |
+| PCB revision | Not entered |
+| Firmware revision, if applicable | Not entered |
+| Physical prototype or assembly ID | Not entered |
+| Latest relevant verification report | Not entered |
+
+Do not describe a schematic, PCB, firmware image, download, or physical prototype as present until it exists. When some representations are ahead of others, say which one describes the intended design and which one describes the built hardware.
+
+## How to read this project
+
+- [Next actions](./next-actions.mdx) is the entry point for continuing work.
+- [How we work](./how-we-work.mdx) explains the agent workflow, the templates and where evidence lives.
+- [Architecture](../architecture/overview.mdx) explains the functional blocks and operating states.
+- [Research](../research/index.mdx), [Decisions](../decisions/index.mdx) and [Verification](../verification/index.mdx) hold component research, consequential choices and verification reports as they are written.
+- The [component catalog](/docs/components/) is generated from the component evidence records.
+
+Exact component identity, sourced facts, asset provenance, and generated catalog entries belong to the component evidence bundle. This page describes project intent and current state.
+
+## Immediate next result
+
+Describe one concrete result needed next, the uncertainty it resolves, and the artifact that will preserve the answer. Link the corresponding entry in [next actions](./next-actions.mdx) instead of maintaining two independent task lists.

package/templates/default/doc/src/content/docs/project/next-actions.mdx

@@ -0,0 +1,58 @@
+---
+title: "Open questions and next actions"
+description: "A concise handoff of current uncertainties, dependencies, and the next concrete work."
+sidebar_position: 2
+---
+
+This is the continuation point for the project. Keep it short enough that a new session can identify what to do next without rereading the whole archive. The project has just been created: no design work, component research or verification has been done yet.
+
+## Current snapshot
+
+| Field | Entry |
+|---|---|
+| Snapshot date | Not entered |
+| Current project goal | Not entered; see the [project brief](./index.mdx) |
+| Design revision considered current | None exists yet |
+| Latest completed result and its evidence | None |
+| Most consequential remaining uncertainty | What the project is for; the brief is empty |
+| Next result to produce | A filled project brief |
+
+## Open questions
+
+| Question ID | Exact question | Why the answer matters | Evidence needed | Owner or next task |
+|---|---|---|---|---|
+| Not assigned | What should this circuit do, for whom, and under which constraints? | Every later choice depends on it | The owner's description | Next action 1 |
+
+Classify the needed work in plain language: source research, identity resolution, calculation, design choice, asset audit, supplier information, or physical measurement. This makes it clear whether another web lookup can answer the question or a bench test is required.
+
+## Next actions
+
+| Priority | Bounded action | Depends on | Concrete output | Completion condition |
+|---|---|---|---|---|
+| 1 | Fill the project brief from the owner's intent | The owner's description | An updated [project brief](./index.mdx) | Purpose and constraints are entered; unknowns are marked as unknown |
+| 2 | Draft the functional blocks and operating states | Action 1 | An updated [architecture overview](../architecture/overview.mdx) | Blocks are described by responsibility, without unselected part numbers |
+| 3 | Choose the first component question to research | Action 2 | A research page in [Research](../research/index.mdx) and an updated table here | One bounded research question with its criteria |
+
+Prefer actions with a visible result, such as retaining an exact document, mapping one connector, checking a model dimension, or producing one test report. “Investigate everything” gives the next agent no stopping point.
+
+## Blocked work
+
+| Blocked task | Missing prerequisite | Work that can continue meanwhile | Revisit when |
+|---|---|---|---|
+| No task entered | Not entered | Not entered | Not entered |
+
+Record the actual blocker. A failed download, missing hardware, unconfirmed identity, undecided requirement, and unavailable tool are different problems and require different follow-up.
+
+## Recently resolved or reopened
+
+| Question or action | New state | Evidence or decision reference | Pages or records updated |
+|---|---|---|---|
+| No entry | Not entered | Not entered | Not entered |
+
+Move a question here only with its supporting reference. A newer analysis can reopen a previously settled point; preserve both the earlier basis and the reason it no longer closes the question.
+
+## Handoff to the next session
+
+Read the [project brief](./index.mdx) and this page, run `pnpm circuit:check`, then start next action 1. The expected artifact is a filled brief. For a larger delegation, copy the task-request template described in [How we work](./how-we-work.mdx).
+
+When updating this page, remove stale imperative tasks that are already completed, keep historical work in its original decision or verification record, and carry forward only unresolved dependencies.

package/templates/default/doc/src/content/docs/research/index.mdx

@@ -0,0 +1,9 @@
+---
+title: "Research"
+description: "Bounded component and design research, with criteria, linked evidence and open gaps."
+sidebar_position: 1
+---
+
+No research has been recorded yet.
+
+To start one, copy `circuit/templates/project-docs/research/component-candidate.mdx` into this directory with a topic-specific filename, title and `sidebar_position`, and fill it as the research happens. A research page explains the question, the criteria and what the evidence establishes; exact identity, sources and facts go into the component evidence records. Candidates stay out of the inventory until one is selected.

package/templates/default/doc/src/content/docs/verification/index.mdx

@@ -0,0 +1,9 @@
+---
+title: "Verification"
+description: "Verification plans and execution reports, each tied to one revision and configuration."
+sidebar_position: 1
+---
+
+No verification has been planned or performed yet.
+
+For each plan or run, copy `circuit/templates/project-docs/verification/bring-up.mdx` into this directory with a filename that identifies the build and the run. A report starts as a plan and records observations only after they are made; a later successful run never overwrites an earlier failure.

package/templates/default/doc/src/styles/global.css

@@ -0,0 +1,31 @@
+/* Cascade layers: preflight → flow → (unlayered utilities). Tokens/base rules
+   ship from @takazudo/zudo-doc/theme.css.
+   NOTE: the `@takazudo/zdtp/styles.css` import is intentionally NOT here —
+   it is inserted right after the @layer line above, ONLY when
+   designTokenPanel is selected (see features/design-token-panel.ts). It
+   can't ship unconditionally because it pulls in zdtp's own bytes. */
+@layer zd-preflight, zd-flow;
+@import "tailwindcss/preflight" layer(zd-preflight);
+@import "tailwindcss/utilities";
+
+/* Package-shipped tokens, safelist, content typography, and feature CSS.
+   Order is load-bearing — theme.css MUST precede features.css. Do not reorder. */
+@import "@takazudo/zudo-doc/theme.css";
+@import "@takazudo/zudo-doc/safelist.css";
+@import "@takazudo/zudo-doc/content.css";
+@import "@takazudo/zudo-doc/page-loading.css";
+@import "@takazudo/zudo-doc/features.css";
+
+/* ADR-015: the package's unlayered styles, imported after the zudo-doc CSS. */
+@import "@takazudo/zudo-circuit-doc/styles.css";
+
+/* Scan this project's own source for Tailwind utility classes. */
+@source "src/content/**/*.{mdx,md}";
+@source "src/components/**/*.{tsx,ts,jsx,js}";
+@source "pages/**/*.{tsx,ts,jsx,js}";
+
+/* ── Your token overrides ──────────────────────────────────────────────
+   Override any default @theme token from @takazudo/zudo-doc/theme.css here. */
+@theme {
+  /* e.g. --color-accent: oklch(0.6 0.2 250); */
+}

package/templates/default/doc/tsconfig.json

@@ -0,0 +1,13 @@
+{
+  "extends": "@takazudo/zudo-doc/tsconfig.base.json",
+  "include": ["src", "pages", "zfb.config.ts"],
+  "compilerOptions": {
+    "baseUrl": ".",
+    "paths": {
+      "@/*": ["src/*"],
+      "react": ["./node_modules/preact/compat/"],
+      "react/jsx-runtime": ["./node_modules/preact/jsx-runtime"],
+      "react-dom": ["./node_modules/preact/compat/"]
+    }
+  }
+}

package/templates/default/doc/zfb.config.ts

@@ -0,0 +1,78 @@
+import { defineConfig } from "zfb/config";
+import { zudoDoc } from "@takazudo/zudo-doc/config";
+
+// The one config file for this project's doc site (@takazudo/zudo-doc). It
+// must stay free of `node:*` imports and must not import `circuit.config.ts`
+// (epic #1 Config contract, item 4): `zfb.config.ts` is evaluated through
+// esbuild with `--platform=neutral`, a graph the circuit config never joins.
+const site = zudoDoc({
+  siteName: "__SITE_TITLE__",
+  // Required by the v1 asset URLs (FOOTPRINT_ASSET_BASE / MODEL_ASSET_BASE
+  // in the package are root-absolute) — this already is the default, kept
+  // explicit so it is never accidentally changed.
+  base: "/",
+  // ADR-020: templates set the locale explicitly.
+  defaultLocale: "en",
+  themePacks: ["default"],
+  llmsTxt: true,
+  cjkFriendly: true,
+  dynamicPageTransition: true,
+  docHistory: true,
+  // The generated component catalog is regenerated from evidence, not
+  // hand-edited, so it carries no useful edit history of its own.
+  docHistoryExclude: ["components", "components/**"],
+  assetViewer: true,
+  strictContentBridge: true,
+  // ADR-016: ingest this project's `.claude/` tree (one level up from this
+  // zfb project) so `/docs/claude/` and `/docs/claude-skills/<owner>/`
+  // render the raw agent resources the generated pages link back to.
+  claudeResources: { claudeDir: "../.claude", scanRoot: ".." },
+  // These routes exist only for the default docsDir and never inside an
+  // archived version directory; this project has no `versions` config, but
+  // the prefixes stay explicit so a later version addition does not 404 them.
+  defaultLocaleOnlyPrefixes: [
+    "/docs/components/",
+    "/docs/claude/",
+    "/docs/claude-md/",
+    "/docs/claude-skills/",
+    "/docs/claude-agents/",
+    "/docs/claude-commands/",
+  ],
+  chromeBindingsModule: "./src/chrome-bindings.tsx",
+  headerNav: [
+    { label: "Project", path: "/docs/project", categoryMatch: "project" },
+    { label: "Architecture", path: "/docs/architecture", categoryMatch: "architecture" },
+    { label: "Research", path: "/docs/research", categoryMatch: "research" },
+    { label: "Decisions", path: "/docs/decisions", categoryMatch: "decisions" },
+    { label: "Verification", path: "/docs/verification", categoryMatch: "verification" },
+    {
+      label: "Components",
+      path: "/docs/components",
+      categoryMatch: "components",
+      children: [
+        { label: "Catalog & Records", path: "/docs/components", categoryMatch: "components" },
+        { label: "Raw agent resources", path: "/docs/claude", categoryMatch: "claude", versioned: false },
+      ],
+    },
+  ],
+  headerRightItems: [
+    { type: "component", component: "theme-toggle" },
+    { type: "component", component: "search" },
+  ],
+  footer: {
+    links: [],
+    copyright: "Built with zudo-circuit-doc on zudo-doc.",
+  },
+});
+
+// zfb's source-level `linkValidation` (which zudoDoc() switches on) only sees
+// anchor ids written as a literal `id` on an intrinsic element, never the id a
+// component such as the generated pages' `<EvidenceAnchor>` renders — so it
+// warned "broken link: #fact-…" / "#src-…" for every in-page evidence link
+// (#52, #68). The built-HTML scan in `pnpm check:site` (`check:links
+// --strict-anchors --strict-broken`) sees rendered ids and checks every page,
+// and `resolveMarkdownLinks` still warns on unresolvable `.md` links, so the
+// source-level check adds nothing but noise here.
+delete site.markdown?.features?.linkValidation;
+
+export default defineConfig(site);

package/templates/default/package.json

@@ -0,0 +1,23 @@
+{
+  "name": "__PROJECT_NAME__",
+  "version": "0.1.0",
+  "private": true,
+  "type": "module",
+  "packageManager": "pnpm@11.5.2",
+  "engines": {
+    "node": ">=22.18.0"
+  },
+  "scripts": {
+    "dev": "pnpm --dir doc dev",
+    "build": "zudo-circuit-doc models && zudo-circuit-doc generate && pnpm --dir doc build",
+    "check": "zudo-circuit-doc check && pnpm --dir doc check",
+    "circuit:check": "zudo-circuit-doc validate",
+    "circuit:generate": "zudo-circuit-doc generate",
+    "circuit:doctor": "zudo-circuit-doc doctor",
+    "check:site": "zudo-circuit-doc check-built && zudo-circuit-doc scan && pnpm --dir doc check:links -- --strict-anchors --strict-broken",
+    "previews:generate": "zudo-circuit-doc footprints generate"
+  },
+  "devDependencies": {
+    "@takazudo/zudo-circuit-doc": "^0.1.0"
+  }
+}

package/templates/default/pnpm-workspace.yaml

@@ -0,0 +1,9 @@
+packages: ["doc"]
+# pnpm 11 defaults minimumReleaseAge to 1440min. The exclude matcher can't
+# match a fresh install's peer-nested lockfile keys (upstream pnpm bug), the
+# same reason create-zudo-doc 5.27.0's own scaffold disables the gate
+# outright instead of excluding specific packages. Revisit once that's fixed
+# and this project is ready to publish.
+minimumReleaseAge: 0
+allowBuilds:
+  esbuild: true