jitxexamples 1.6.2__tar.gz → 1.7.0__tar.gz

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/.gitignore

@@ -5,7 +5,7 @@
 
 # Build / cache outputs.
 **/cache/
-# `jitx build` output: <repo-root>/designs/<module.path.design_name>/{design-info,temp,...}
+# `jitx design build` output: <repo-root>/designs/<module.path.design_name>/{design-info,temp,...}
 # The `designs` directory name is chosen by JITX, not by us — hence the Python
 # package is `demos`. Anchored: only the repo-root output tree.
 /designs/

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/CLAUDE.md

@@ -10,7 +10,7 @@ specifically about working *with an agent* in this repo.
 
 ## Repo-specific rules
 
-- **`designs/` at the repo root is JITX build output, not source.** `jitx build` creates
+- **`designs/` at the repo root is JITX build output, not source.** `jitx design build` creates
   `<repo-root>/designs/<module.path.design_name>/` (`design-info/`, `temp/`, ...). That name is
   chosen by JITX. The Python demo sources live in `src/jitxexamples/demos/` for exactly this reason.
   Never add source under a root `designs/`, and never rename `demos/` back to `designs/`.
@@ -21,12 +21,12 @@ specifically about working *with an agent* in this repo.
   real design elements.
 
 - **`jitx.test.TestCase` does not need the JITX runtime.** It only activates the instantiation
-  context, so instantiating a `SampleDesign` works offline. Only `jitx build` / `jitx ui` need
-  `jitx runtime start`; `jitx build --dry <target>` translates a design without one.
+  context, so instantiating a `SampleDesign` works offline. Only `jitx design build` / `jitx ui` need
+  `jitx runtime start`; `jitx design build --dry <target>` translates a design without one.
 
 - **The repo targets the jitx 4.4 line, and public PyPI serves it.** `pyproject.toml` requires
   `jitx>=4.4.0,<5`. Two surfaces have to agree — a 4.4 package against a 4.2 runtime is not a
-  working install — so `jitx build` also needs the runtime (`~/.jitx/current`, check with
+  working install — so `jitx design build` also needs the runtime (`~/.jitx/current`, check with
   `jitx runtime introspect`) on the same line as the library. Before concluding demo code is broken,
   check which `jitx` you actually resolved on both.
 

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: jitxexamples
-Version: 1.6.2
+Version: 1.7.0
 Summary: Library of example JITX components, substrates, and demo designs
 Project-URL: Homepage, https://jitx.com
 Project-URL: Documentation, https://docs.jitx.com

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/README.md

@@ -26,15 +26,15 @@ JITX design builds require an installed and running JITX runtime. From the proje
 
 ```bash
 jitx runtime start --background
-jitx find
-jitx build jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design
+jitx design find
+jitx design build jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design
 jitx ui open --board --design jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design
 ```
 
 Build the explicit non-test design target above; do not substitute similarly named targets from
-`test`, `tests`, or a test file listed by `jitx find`.
+`test`, `tests`, or a test file listed by `jitx design find`.
 
-`jitx build` writes its output to `<repo-root>/designs/<module.path.design_name>/`
+`jitx design build` writes its output to `<repo-root>/designs/<module.path.design_name>/`
 (`design-info/`, `temp/`, ...). That directory name is chosen by JITX, not by this repo, and is
 git-ignored — which is why the Python sources live in `src/jitxexamples/demos/` rather than
 `src/jitxexamples/designs/`.

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js0-setup/JS0_Reference_Companion.md

@@ -1,4 +1,4 @@
-<!-- JITX Setup — Reference Companion (JS0) · rev 1.5 · 2026-09-08 -->
+<!-- JITX Setup — Reference Companion (JS0) · rev 1.6 · 2026-09-14 -->
 
 # JITX Setup — Reference Companion (JS0)
 
@@ -16,9 +16,9 @@ Run these in a terminal — you'll get a working, authenticated install, proven
 2. **Install the JITX CLI.** `pip install jitx`. If you hit the PEP 668 "externally-managed-environment" error — the Python packaging rule that stops `pip` writing into a system-managed interpreter — install `uv` (https://astral.sh/uv) and run `uv tool install jitx` instead. Verify: `jitx --version`.
 3. **Install the runtime.** `jitx runtime install` — do this **before** signing in. **On Windows**, this launches an MSI installer in a separate popup window (possibly behind others) — complete it to finish. If it fails with `not tested on Linux distribution '<x>'`, retry as `jitx runtime install --target ubuntu`; the Ubuntu build runs on most glibc Linux. Check it with `jitx runtime introspect`, which works anywhere — `jitx runtime status` is project-scoped and fails with `No pyproject.toml found` until you create the project in step 5.
 4. **Sign in.** `jitx auth login` prints an activation link and a code; open it in any browser, approve, and the command completes on its own. It does not launch the browser for you, which matters on a headless or remote machine. **The link expires in 10 minutes** — re-run the command if it lapses. In the browser, **Sign in with Google** is simplest; if you're **not** using a Google-enabled account, enter your registered email and JITX password. Confirm with `jitx auth show`: **`Authorized: yes`** is the field that matters, and an `Expires` in the past is normal — the value shown is always the pre-refresh one, because the authorization check that renews the token runs after the claims are read.
-5. **Validate with two builds.** The global CLI (step 2) has no `pip`, so run this inside each project once it exists. Create and activate a virtual environment — `python3 -m venv .venv && source .venv/bin/activate` on macOS or Linux, or `$env:PYTHONUTF8 = "1"; py -3 -m venv .venv` then `.\.venv\Scripts\Activate.ps1` in Windows PowerShell — then `pip install jitx`, `jitx project dependencies upgrade`, `jitx runtime start --background`, and `jitx find`. After the upgrade, `pip show jitx` and `jitx runtime introspect` should report the same release line (4.4.x with 4.4.x). **On Windows**, `PYTHONUTF8=1` keeps the `cp1252` console from choking on `Ω`; and a `WinError 32` from the upgrade means pip is replacing the running `jitx.exe` — run `.\.venv\Scripts\python.exe -m pip install --upgrade jitx` and re-run the upgrade.
-   - **Simplest.** Create a new project with `jitx project layout init` (this seeds a two-resistor sample design). Build the seeded non-test target from `jitx find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx find`** — the two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `my-first-board` builds as `jitx build my_first_board.main.MyFirstBoard`. Then open the views with `jitx ui open --schematic` and `jitx ui open --board`.
-   - **Full.** Clone `https://github.com/JITx-Inc/jitx-examples` and build the [`si_bga_optimization`](https://github.com/JITx-Inc/jitx-examples/tree/main/src/jitxexamples/demos/si_bga_optimization) design, taking the target verbatim from `jitx find` as above — expect `jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design`. Open the board view to confirm.
+5. **Validate with two builds.** The global CLI (step 2) has no `pip`, so run this inside each project once it exists. Create and activate a virtual environment — `python3 -m venv .venv && source .venv/bin/activate` on macOS or Linux, or `$env:PYTHONUTF8 = "1"; py -3 -m venv .venv` then `.\.venv\Scripts\Activate.ps1` in Windows PowerShell — then `pip install jitx`, `jitx project dependencies upgrade`, `jitx runtime start --background`, and `jitx design find`. After the upgrade, `pip show jitx` and `jitx runtime introspect` should report the same release line (4.4.x with 4.4.x). **On Windows**, `PYTHONUTF8=1` keeps the `cp1252` console from choking on `Ω`; and a `WinError 32` from the upgrade means pip is replacing the running `jitx.exe` — run `.\.venv\Scripts\python.exe -m pip install --upgrade jitx` and re-run the upgrade.
+   - **Simplest.** Create a new project with `jitx project layout init` (this seeds a two-resistor sample design). Build the seeded non-test target from `jitx design find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx design find`** — the two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `my-first-board` builds as `jitx design build my_first_board.main.MyFirstBoard`. Then open the views with `jitx ui open --schematic` and `jitx ui open --board`.
+   - **Full.** Clone `https://github.com/JITx-Inc/jitx-examples` and build the [`si_bga_optimization`](https://github.com/JITx-Inc/jitx-examples/tree/main/src/jitxexamples/demos/si_bga_optimization) design, taking the target verbatim from `jitx design find` as above — expect `jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design`. Open the board view to confirm.
    - **`jitx ui open` holds the terminal** while its window is open — use a second terminal, or background it, for the next command. Later calls return straight away and add their windows to the JITX app already running; there's no limit on how many views can be open at once, so leave the Simplest build's windows up.
    - **If the command comes straight back, it crashed — it didn't open.** The slow-first-view note below applies only while `jitx ui open` is still running.
    - **The first view may be slow — if it's still running.** The very first board or schematic window can take a few minutes to appear — more likely on macOS. If it doesn't show up straight away, wait it out rather than re-running. If nothing shows after **5 minutes**, something is wrong. Later views come up faster.

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js0-setup/JS0_Setup_Runbook.md

@@ -1,5 +1,5 @@
 <!--
-JITX Setup Runbook (JS0) · rev 1.5 · 2026-09-08
+JITX Setup Runbook (JS0) · rev 1.6 · 2026-09-14
 Paste this file into your AI coding agent (Claude Code, Codex / GPT, or Devin), or upload it,
 and tell the agent to follow it.
 -->
@@ -85,11 +85,11 @@ $env:PYTHONUTF8 = "1"; py -3 -m venv .venv; .\.venv\Scripts\Activate.ps1
 pip install jitx
 jitx project dependencies upgrade
 jitx runtime start --background
-jitx find
+jitx design find
 ```
 
-- **5a — Simplest build.** Run `jitx project layout init` to create a new JITX project seeded with a two-resistor sample design (Devin users: you made this project in step 4). Then run the setup commands above and build the seeded non-test target from `jitx find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx find`** — the two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `my-first-board` builds as `jitx build my_first_board.main.MyFirstBoard`. Then show me the schematic and board views.
-- **5b — Full build.** Clone `https://github.com/JITx-Inc/jitx-examples`, run the setup commands above, and **take the `si_bga_optimization` target verbatim from `jitx find`** — the same rule as 5a, so a repo reorganisation can't strand you on a stale module path. Expect `jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design`. Two things about this repo's output: `jitx find` also prints an `errors: import failed` block for the repo's `tests/` modules — expected here (its tests aren't a package) and not a fault; the `designs:` list is what you take the target from. And after `jitx project dependencies upgrade`, `pip show jitx` and `jitx runtime introspect` must report the same release line (4.4.x with 4.4.x) — if the upgrade moved `jitx` to a different line than the runtime, stop and tell me rather than building. Build it, confirm it builds, and display the board UI windows for me.
+- **5a — Simplest build.** Run `jitx project layout init` to create a new JITX project seeded with a two-resistor sample design (Devin users: you made this project in step 4). Then run the setup commands above and build the seeded non-test target from `jitx design find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx design find`** — the two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `my-first-board` builds as `jitx design build my_first_board.main.MyFirstBoard`. Then show me the schematic and board views.
+- **5b — Full build.** Clone `https://github.com/JITx-Inc/jitx-examples`, run the setup commands above, and **take the `si_bga_optimization` target verbatim from `jitx design find`** — the same rule as 5a, so a repo reorganisation can't strand you on a stale module path. Expect `jitxexamples.demos.si_bga_optimization.bga_escape.bga_optimization_design`. Two things about this repo's output: `jitx design find` also prints an `errors: import failed` block for the repo's `tests/` modules — expected here (its tests aren't a package) and not a fault; the `designs:` list is what you take the target from. And after `jitx project dependencies upgrade`, `pip show jitx` and `jitx runtime introspect` must report the same release line (4.4.x with 4.4.x) — if the upgrade moved `jitx` to a different line than the runtime, stop and tell me rather than building. Build it, confirm it builds, and display the board UI windows for me.
 
 > **If a build fails with "You are not authenticated. Please sign in through the JITX Sidebar in VSCode"**, that means step 3 didn't complete — re-run `jitx auth login`, don't go looking for VSCode. `jitx runtime start --background` succeeds while unauthenticated, so a green step 2 is not proof of sign-in, and the real one-line cause arrives underneath two Python tracebacks.
 

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js1-stackup-components/README.md

@@ -21,7 +21,7 @@ JS1 consists of three parts: building a stackup (Part 1) and component creation
 
 In every part the user uses agents to drive a JITX skill rather than hand-writing the code, and
 nothing counts as done until it clears its ground-truth check — the fab spec, the datasheet, or the
-vendor pin file — **and** `jitx build <non-test design target>` completes successfully.
+vendor pin file — **and** `jitx design build <non-test design target>` completes successfully.
 
 ## Start here — the JS1 walkthrough
 
@@ -71,7 +71,7 @@ a machine-readable file — so you parse it rather than transcribe it. A committ
 generator reconciles the file to exactly 1,369 balls before any component code exists, and the
 circuit wrapper lifts the flat pin map into what a board designer actually consumes: 31 `Power`
 rails, three ground domains, and six GTM transceiver quads as bundles. Verification is layered —
-reconciliation (parsed rows = file footer = full 37×37 grid), 19 tests and 198 subtests including
+reconciliation (parsed rows = file footer = full 37×37 grid), an offline test suite including
 hand-read ball spot-checks, and both designs building `status: ok`. Expect roughly 2–3 hours across
 four `[HUMAN]` gates, most of it agent-autonomous.
 

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js1-stackup-components/part1-stackup/JS1_Part1_Stackup-from-Fab-CSV_Runbook.md

@@ -1,5 +1,5 @@
 <!--
-JITX Stackup-from-Fab-CSV Runbook (JS1 · Part 1) · rev 1.4 · 2026-09-08
+JITX Stackup-from-Fab-CSV Runbook (JS1 · Part 1) · rev 1.5 · 2026-09-14
 Paste this file into your AI coding agent (Claude Code, Codex / GPT, or Devin), or upload it,
 together with your stackup CSV, and tell the agent to follow it. Complete the JS0 Setup Runbook
 first. START A NEW AGENT SESSION before you begin — a skills install only takes effect in a
@@ -40,10 +40,10 @@ $env:PYTHONUTF8 = "1"; py -3 -m venv .venv; .\.venv\Scripts\Activate.ps1
 pip install jitx
 jitx project dependencies upgrade
 jitx runtime start --background
-jitx find
+jitx design find
 ```
 
-Build the seeded non-test target from `jitx find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx find`.** The two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `js1-hdi-stackup` builds as `jitx build js1_hdi_stackup.main.Js1HdiStackup`. This smoke test must succeed before you write any code of your own. If it fails, stop and tell me; do not start on the stackup. Then create `tests/`, add `pytest` and `pyright`, and `git init` if you want version control. Leave the seeded `.gitignore` as it is.
+Build the seeded non-test target from `jitx design find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx design find`.** The two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `js1-hdi-stackup` builds as `jitx design build js1_hdi_stackup.main.Js1HdiStackup`. This smoke test must succeed before you write any code of your own. If it fails, stop and tell me; do not start on the stackup. Then create `tests/`, add `pytest` and `pyright`, and `git init` if you want version control. Leave the seeded `.gitignore` as it is.
 
 **2 · Read the report before writing any code.**
 Parse the CSV and **restate it back to me** per the skill's Source Documents rules; flag whatever is ambiguous.
@@ -63,9 +63,9 @@ Drive the skill's **"From a fab impedance table"** pattern over the IMPEDANCE se
 **7 · Verify.**
 Run `pyright` — expect **zero errors and zero suppressions**; a `pyright: ignore` you feel you need is a finding to report, not a way to reach zero. Write CSV-sourced tests per the skill's **"Verifying a Substrate Against Its Source"**.
 
-Then `pytest`. Before you build, **wire the substrate into a design** per the skill's **"Smoke-Test Wiring (Board and Design)"** — step 1's seeded target is not acceptance here, and the skill says why. Then `jitx build <non-test design target>`, one design at a time. Read all of `jitx find`'s output, not just its design list — treat any `import failed:` line as a failure (make `tests/` a package with an `__init__.py` if your tests import shared helpers), and do not build designs discovered under `tests/`; those are pytest fixtures, not smoke-test targets. Finally run **`jitx-code-review`**, fix what it finds, re-run, and report every result to me — including the skill's filled **Substrate completeness check** block.
+Then `pytest`. Before you build, **wire the substrate into a design** per the skill's **"Smoke-Test Wiring (Board and Design)"** — step 1's seeded target is not acceptance here, and the skill says why. Then `jitx design build <non-test design target>`, one design at a time. Read all of `jitx design find`'s output, not just its design list — treat any `import failed:` line as a failure (make `tests/` a package with an `__init__.py` if your tests import shared helpers), and do not build designs discovered under `tests/`; those are pytest fixtures, not smoke-test targets. Finally run **`jitx-code-review`**, fix what it finds, re-run, and report every result to me — including the skill's filled **Substrate completeness check** block.
 
-A good result is: `pyright` reports zero errors, `pytest` is green with every assertion sourced from the CSV, `jitx build` of the design that **binds the substrate** completes and writes its design directory, and `jitx-code-review` returns no unresolved findings. Anything short of that is a failure. Report it to me and stop; do not work around it.
+A good result is: `pyright` reports zero errors, `pytest` is green with every assertion sourced from the CSV, `jitx design build` of the design that **binds the substrate** completes and writes its design directory, and `jitx-code-review` returns no unresolved findings. Anything short of that is a failure. Report it to me and stop; do not work around it.
 
 **8 · [HUMAN] Close the loop — re-issue the report.**
 Now show me the substrate regenerates from the report. **Invite me to change the CSV** — suggest I say: *"the fab came back on the through-hole again — 0.400 mm finished hole this time; re-issue the report and tell me what moved."* **Wait for me to ask.**
@@ -74,9 +74,9 @@ Edit the CSV only with values I give you — both unit columns for the hole, the
 
 **If I ask for a dielectric change instead, stop.** A dielectric change re-solves the controlled-impedance line widths, and that solve belongs to the fab — the CSV carries its result, not the model that produced it. Report the affected trace widths as blocked pending re-solved impedance rows; do not estimate them, and do not carry the old widths forward as if they still held. If I supply re-solved rows, carry them through and report before → after for every changed width.
 
-If the rebuild ends in `status: error` with `EOF when reading a line`, the runtime asked *"Significant changes detected… Do you want to continue? [Y/n]"* on a stdin it does not have under `--background` — there is no flag to pre-answer it, and piping `y` into `jitx build` does not reach it. Tell me: I stop the background runtime and run `jitx runtime start` in my own terminal, answer the prompt there, and you rebuild.
+If the rebuild ends in `status: error` with `EOF when reading a line`, the runtime asked *"Significant changes detected… Do you want to continue? [Y/n]"* on a stdin it does not have under `--background` — there is no flag to pre-answer it, and piping `y` into `jitx design build` does not reach it. Tell me: I stop the background runtime and run `jitx runtime start` in my own terminal, answer the prompt there, and you rebuild.
 
-Then close this step the way step 7 closes: `pyright`, `pytest`, a `jitx build` of the design that binds the substrate, and **`jitx-code-review`**. The code and tests you wrote here have not been through that gate — step 7's review went stale the moment you edited anything.
+Then close this step the way step 7 closes: `pyright`, `pytest`, a `jitx design build` of the design that binds the substrate, and **`jitx-code-review`**. The code and tests you wrote here have not been through that gate — step 7's review went stale the moment you edited anything.
 
 ---
 
@@ -86,5 +86,5 @@ Then close this step the way step 7 closes: `pyright`, `pytest`, a `jitx build`
 - Summed thickness matches the report's finished and overall thickness to the last printed digit; every annular ring and aspect ratio is within its capability limit, derived on the depth basis the NOTES state for that drill type.
 - No `Symmetric`, no invented SI models, and no **unlabeled** number that can't be pointed at a CSV row — reference-plane widths carry the skill's labeled default — and the STANDARD line/space recorded as prose, not as a structure.
 - The step-4 gate stopped after the stackup, with vias and routing structures written only after approval.
-- `pyright` clean with zero suppressions, `pytest` green from CSV-sourced tests, `jitx find` free of import errors, a design that **binds the substrate** builds, `jitx-code-review` findings fixed — run after step 8 as well as step 7 — and the skill's **Substrate completeness check** block filled in the completion report.
+- `pyright` clean with zero suppressions, `pytest` green from CSV-sourced tests, `jitx design find` free of import errors, a design that **binds the substrate** builds, `jitx-code-review` findings fixed — run after step 8 as well as step 7 — and the skill's **Substrate completeness check** block filled in the completion report.
 - A prompted CSV re-issue (the through-hole change) flows through to rebuilt code, with the aspect ratio and annular ring re-derived, re-checked against capability, and reported before → after — and the untouched impedance rows called out. A dielectric change without re-solved rows is reported as blocking the affected widths; no estimated width appears anywhere.

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js1-stackup-components/part2-parametric-passives/JS1_Part2_Parametric-Passives_Runbook.md

@@ -1,5 +1,5 @@
 <!--
-JITX Parametric Component Families Runbook (JS1 · Part 2) · rev 1.4 · 2026-09-08
+JITX Parametric Component Families Runbook (JS1 · Part 2) · rev 1.5 · 2026-09-14
 Paste this file into your AI coding agent (Claude Code, Codex / GPT, or Devin), or upload it,
 and tell the agent to follow it. Complete the JS0 Setup Runbook first.
 START A NEW AGENT SESSION before you begin — a skills install only takes effect in a session
@@ -9,7 +9,7 @@ drives a skill.
 
 # JITX Parametric Component Families Runbook (JS1 · Part 2)
 
-**Goal (for the agent):** In a fresh JITX Python project, build four **parameterized, datasheet-driven component families** — three SMD chip-resistor families (**Yageo RC_L**, **Panasonic ERJ**, **Vishay CRCW**) and one MLCC capacitor family (**Samsung Electro-Mechanics CL**). Each family is a single `jitx.Component` class that stands in for the manufacturer's whole catalog family, with **no parts database or online query** — the class *is* the data. Follow the steps **in order**; a family is not done until it passes its tests and `jitx build <non-test design target>`. Where a step is marked **[HUMAN]**, stop and wait for me — do not proceed until I confirm.
+**Goal (for the agent):** In a fresh JITX Python project, build four **parameterized, datasheet-driven component families** — three SMD chip-resistor families (**Yageo RC_L**, **Panasonic ERJ**, **Vishay CRCW**) and one MLCC capacitor family (**Samsung Electro-Mechanics CL**). Each family is a single `jitx.Component` class that stands in for the manufacturer's whole catalog family, with **no parts database or online query** — the class *is* the data. Follow the steps **in order**; a family is not done until it passes its tests and `jitx design build <non-test design target>`. Where a step is marked **[HUMAN]**, stop and wait for me — do not proceed until I confirm.
 
 > **For humans:** prerequisites are a completed **JS0** (authenticated `jitx` CLI, `jitx-skills` enabled in your agent) and network access to the manufacturer datasheet URLs in step 2.
 
@@ -75,7 +75,7 @@ Drive it; don't re-derive it. What is specific to *this* task:
 ```bash
 pyright                 # expect zero errors and zero suppressions
 pytest                  # the family's tests (plus all earlier families' tests)
-jitx build <non-test design target>  # build the intended design, never a target from tests/
+jitx design build <non-test design target>  # build the intended design, never a target from tests/
 ```
 
 A `pyright: ignore` you feel you need is a finding to report, not a way to reach zero. Run the
@@ -104,10 +104,10 @@ $env:PYTHONUTF8 = "1"; py -3 -m venv .venv; .\.venv\Scripts\Activate.ps1
 pip install jitx
 jitx project dependencies upgrade
 jitx runtime start --background
-jitx find
+jitx design find
 ```
 
-Build the seeded non-test target from `jitx find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx find`** — the two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `js1-passives` builds as `jitx build js1_passives.main.Js1Passives`. This smoke test must succeed before you write any component code. If it fails, stop and tell me. Then prepare the project for this task: create a `tests/` directory, add `pytest` and `pyright` as dev dependencies, and `git init` if you want version control. Leave the seeded `.gitignore` as it is.
+Build the seeded non-test target from `jitx design find` — ignore any target whose module path comes from `test`, `tests`, or a test file. **Take the target verbatim from `jitx design find`** — the two halves are derived differently, so don't assemble it yourself: the package is the directory lowercased with hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A directory called `js1-passives` builds as `jitx design build js1_passives.main.Js1Passives`. This smoke test must succeed before you write any component code. If it fails, stop and tell me. Then prepare the project for this task: create a `tests/` directory, add `pytest` and `pyright` as dev dependencies, and `git init` if you want version control. Leave the seeded `.gitignore` as it is.
 
 **2 · Fetch the datasheets.**
 Download all four manufacturer datasheets into `.context/` (gitignored — **link the URL in each family's docstring, never commit the PDF**):
@@ -120,29 +120,29 @@ Download all four manufacturer datasheets into `.context/` (gitignored — **lin
 Per the skill's **"Verify the download is a datasheet"**: these four URLs are canonical, so if one doesn't answer, say whether you hit an egress problem or a moved document, and tell me which URL you ended up using.
 
 **3 · Family 1 — Yageo RC_L.**
-Drive the component-modeler skill with the Yageo datasheet to build `yageo_rc.py`, following its **Parameterized Component Families** and **Two-Terminal Chip Components** sections. Values encode in Yageo's RKM style (`100K`). Keep this family **self-contained in one file — no shared helpers yet**. Write `tests/test_yageo_rc.py` per the skill's **"Verifying a component with tests"**, cross-checking the datasheet's own ordering example **`RC0402JR-07100KL`**. Table-driven checks go in `self.subTest(...)` — pytest's `parametrize` does not apply to `unittest`-style `TestCase` methods, and `jitx.test.TestCase` is one. Verify: `pyright` → `pytest` → `jitx build <non-test design target>`. Commit when green.
+Drive the component-modeler skill with the Yageo datasheet to build `yageo_rc.py`, following its **Parameterized Component Families** and **Two-Terminal Chip Components** sections. Values encode in Yageo's RKM style (`100K`). Keep this family **self-contained in one file — no shared helpers yet**. Write `tests/test_yageo_rc.py` per the skill's **"Verifying a component with tests"**, cross-checking the datasheet's own ordering example **`RC0402JR-07100KL`**. Table-driven checks go in `self.subTest(...)` — pytest's `parametrize` does not apply to `unittest`-style `TestCase` methods, and `jitx.test.TestCase` is one. Verify: `pyright` → `pytest` → `jitx design build <non-test design target>`. Commit when green.
 
 **4 · [HUMAN] Verify Family 1 together.**
 Stop and walk me through the family against the datasheet before replicating the pattern. Show me: (a) two or three transcribed dimensions side-by-side with the datasheet table, **including which of the two printed termination bands you used and why**; (b) the encoder reproducing the ordering-example MPN and a decade-carry case (`9999 → "10K"`); (c) a fail-fast rejection listing the valid options — run this demo **inside the instantiation context**, since a plain script raises nothing; (d) how each vendor size label maps to the generator's size key by body L×W — three naming systems meet here: the vendor's own label, the metric code, and the EIA imperial code the generator keys on. Yageo's `0075` is a 0.30 × 0.15 mm body, metric `03015`, imperial (and JITX key) `009005`; its `0100` is 0.40 × 0.20 mm, metric `0402`, imperial `01005`; (e) the skill's filled **Component completeness check** block. **Wait for my approval** before continuing.
 
 **5 · Family 2 — Panasonic ERJ.**
-Build `panasonic_erj.py` from the Panasonic datasheet: 3-digit EIA value code (`103`), its own tables and MPN f-string. This is the second consumer, so per the skill's **"Shared helpers — extract at the second family"**, extract them now into `chip_resistor.py` and refactor Family 1 onto them — Family 1's unchanged tests passing proves the refactor safe. Write `tests/test_panasonic_erj.py`, cross-checking **`ERJ3GEYJ102V`**. Verify: `pyright` → `pytest` (all families) → `jitx build <non-test design target>`. Commit when green.
+Build `panasonic_erj.py` from the Panasonic datasheet: 3-digit EIA value code (`103`), its own tables and MPN f-string. This is the second consumer, so per the skill's **"Shared helpers — extract at the second family"**, extract them now into `chip_resistor.py` and refactor Family 1 onto them — Family 1's unchanged tests passing proves the refactor safe. Write `tests/test_panasonic_erj.py`, cross-checking **`ERJ3GEYJ102V`**. Verify: `pyright` → `pytest` (all families) → `jitx design build <non-test design target>`. Commit when green.
 
 **6 · Family 3 — Vishay CRCW.**
-Build `vishay_crcw.py` on the shared helpers: fixed 4-character RKM value code (`10K0`). This datasheet specifies its cases by standard EIA/IEC size code (`RR1608M` = 1.6 × 0.8 mm for 0603), so prefer the generator's standard chip dimensions — and doc 20035 **p. 11** (`DIMENSIONS AND MASS`) tabulates them too, so the skill's **"Taking the standard table's dimensions is a verification obligation"** applies in full: read p. 11 and assert the table against it per size. Write `tests/test_vishay_crcw.py`, cross-checking **`CRCW0603562RFKEA`**. Verify: `pyright` → `pytest` → `jitx build <non-test design target>`. Commit when green.
+Build `vishay_crcw.py` on the shared helpers: fixed 4-character RKM value code (`10K0`). This datasheet specifies its cases by standard EIA/IEC size code (`RR1608M` = 1.6 × 0.8 mm for 0603), so prefer the generator's standard chip dimensions — and doc 20035 **p. 11** (`DIMENSIONS AND MASS`) tabulates them too, so the skill's **"Taking the standard table's dimensions is a verification obligation, not a shortcut"** applies in full: read p. 11 and assert the table against it per size. Write `tests/test_vishay_crcw.py`, cross-checking **`CRCW0603562RFKEA`**. Verify: `pyright` → `pytest` → `jitx design build <non-test design target>`. Commit when green.
 
 **7 · Family 4 — Samsung CL (MLCC).**
-Build `samsung_cl.py` — the same pattern with two new axes, **dielectric** (C0G/NP0, X7R, X5R as offered per size/voltage) and **rated voltage**, a 3-digit pF value code, `CapacitorSymbol`, and `reference_designator_prefix = "C"`. Cross-check against the real catalog part **`CL10B104KB8NNNC`**. The linked catalog is the overview edition and hits **both** gaps in the skill's **"When the catalog does not publish what you need, say so"** — no per-size capacitance lineup, and no chip outline table either. Work it per that section, and expect one size to fall out of coverage; tell me which and why. The shared file now serves a non-resistor part, so rename `chip_resistor.py` → `chip_smt.py`, update all imports, and re-run the **full** suite. Write `tests/test_samsung_cl.py`. Verify: `pyright` → `pytest` → `jitx build <non-test design target>`. Commit when green.
+Build `samsung_cl.py` — the same pattern with two new axes, **dielectric** (C0G/NP0, X7R, X5R as offered per size/voltage) and **rated voltage**, a 3-digit pF value code, `CapacitorSymbol`, and `reference_designator_prefix = "C"`. Cross-check against the real catalog part **`CL10B104KB8NNNC`**. The linked catalog is the overview edition and hits **both** gaps in the skill's **"When the catalog does not publish what you need, say so"** — no per-size capacitance lineup, and no chip outline table either. Work it per that section, and expect one size to fall out of coverage; tell me which and why. The shared file now serves a non-resistor part, so rename `chip_resistor.py` → `chip_smt.py`, update all imports, and re-run the **full** suite. Write `tests/test_samsung_cl.py`. Verify: `pyright` → `pytest` → `jitx design build <non-test design target>`. Commit when green.
 
 **8 · Full verification pass.**
-Create a small combined `SampleDesign` that instantiates one part from **each of the four families** and confirm `jitx build <non-test design target>` passes on it. Run `pyright` and the full `pytest` suite, plus the project's lint/format check if the scaffold seeded one. Then run the **`jitx-code-review`** self-critique skill over the four family files and the shared helpers, fix what it finds, re-run the tests, and commit. Report the results of all checks to me.
+Create a small combined `SampleDesign` that instantiates one part from **each of the four families** and confirm `jitx design build <non-test design target>` passes on it. Run `pyright` and the full `pytest` suite, plus the project's lint/format check if the scaffold seeded one. Then run the **`jitx-code-review`** self-critique skill over the four family files and the shared helpers, fix what it finds, re-run the tests, and commit. Report the results of all checks to me.
 
-A good result is: `pyright` reports zero errors and no suppressions, the full `pytest` suite is green including every family's datasheet cross-check, `jitx build <non-test design target>` completes on the combined design, `jitx-code-review` returns no unresolved findings, and each family has its **Component completeness check** block filled in, written next to the code.
+A good result is: `pyright` reports zero errors and no suppressions, the full `pytest` suite is green including every family's datasheet cross-check, `jitx design build <non-test design target>` completes on the combined design, `jitx-code-review` returns no unresolved findings, and each family has its **Component completeness check** block filled in, written next to the code.
 
 **9 · [HUMAN] Close the loop — request a part.**
 The library is done; now show me what it's for. **Invite me to ask for an arbitrary part** — suggest I say: *"give me a 49.9 kΩ 0402 1% Yageo and a 100 nF X7R 0603 50 V Samsung CL."* **Wait for me to ask.** When I do, instantiate the requested parts from the family classes in the combined design, rebuild, and show me the schematic/board — launch `jitx ui open` in the background, it blocks while its window is open (JS0 step 5 explains) — plus the **generated MPNs**, so I can spot-check them against the datasheets' part-numbering schemes.
 
-This step writes code, so it goes through step 8's gate like every other step — finish with the full verification block (`pyright` → `pytest` → `jitx build <non-test design target>` → `jitx-code-review`). Don't let the last code written be the only code that skipped the review. Print the BOM as well as the MPNs: value labels are the one thing none of those four commands checks.
+This step writes code, so it goes through step 8's gate like every other step — finish with the full verification block (`pyright` → `pytest` → `jitx design build <non-test design target>` → `jitx-code-review`). Don't let the last code written be the only code that skipped the review. Print the BOM as well as the MPNs: value labels are the one thing none of those four commands checks.
 
 ---
 
@@ -152,7 +152,7 @@ This step writes code, so it goes through step 8's gate like every other step
 - Four family classes exist — `yageo_rc.py`, `panasonic_erj.py`, `vishay_crcw.py`, `samsung_cl.py` — each with a passing `jitx.test.TestCase` file covering: build in a `SampleDesign`, metadata + pad count, the datasheet ordering-example MPN cross-check, the human-readable value label, value-encoder units (incl. decade carry), and fail-fast validation.
 - Wherever a family took the generator's standard chip dimensions, a test asserts that table against the datasheet's own, per size, with any disagreement overridden and commented.
 - Shared helpers were extracted **at Family 2** (not before) and renamed component-agnostic **at Family 4**, with the full suite green after each refactor.
-- `pyright` is clean with no suppressions, the full `pytest` suite passes, and the combined four-family design passes `jitx build <non-test design target>`.
+- `pyright` is clean with no suppressions, the full `pytest` suite passes, and the combined four-family design passes `jitx design build <non-test design target>`.
 - Each family carries the skill's filled **Component completeness check** block, written next to the code.
 - A `jitx-code-review` pass has run and its findings are fixed.
 - A live prompted part request (e.g. 49.9 kΩ 0402 1% Yageo + 100 nF X7R 0603 50 V Samsung CL) instantiates, builds, and its generated MPNs check out against the datasheets.

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js1-stackup-components/part3-versal-fpga/JS1_Part3_Reference_Companion.md

@@ -1,4 +1,4 @@
-<!-- Versal FPGA from the Vendor Pin File — Reference Companion (JS1 · Part 3) · rev 1.2 · 2026-09-08 -->
+<!-- Versal FPGA from the Vendor Pin File — Reference Companion (JS1 · Part 3) · rev 1.3 · 2026-09-14 -->
 
 # Versal FPGA from the Vendor Pin File — Reference Companion (JS1 · Part 3)
 
@@ -34,7 +34,7 @@ Ground truth is two AMD documents, both fetched during the run and never committ
 | `landpattern.py` | The 37×37 BGA land pattern from AM013 values, with a public `get_pad(row, column)` adapter. |
 | `symbols.py` | Partition policy: ~43 schematic boxes, one per bank / GT quad, rails chunked at ≤ 64 pins. |
 | `bundles.py` + `circuit.py` | `GTMQuad` (4 lanes + 2 refclks) and `XCVP1002Circuit`: 31 supply rails as `Power` ports, three ground domains, six GTM quads wired as bundles. |
-| Tests + two buildable designs | Offline invariants (counts, spot-checked balls, symbol coverage, mapping bijectivity, circuit roster) and non-test `jitx build` smoke targets for the component and the wrapped circuit. |
+| Tests + two buildable designs | Offline invariants (counts, spot-checked balls, symbol coverage, mapping bijectivity, circuit roster) and non-test `jitx design build` smoke targets for the component and the wrapped circuit. |
 
 Reference solution: the `jitxexamples` package, module
 [`jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga`](https://github.com/JITx-Inc/jitx-examples/tree/main/src/jitxexamples/jumpstart_kits/js1_stackup_components/versal_fpga).
@@ -75,9 +75,9 @@ wrapper exposes them as pass-through ports.
 
 - Generator reconciliation: parsed rows = file footer = **1369**, unique balls, full grid; the
   committed module regenerates **byte-identically** (`--check`).
-- 19 tests + 198 subtests pass offline on the jitx 4.4 line, including ~10 hand-read
-  ball spot-checks spanning the grid corners and every bank type, symbol coverage (every port in
-  exactly one box), and mapping bijectivity. Both non-test designs `jitx build` with `status: ok`.
+- The offline suite passes on the jitx 4.4 line, including hand-read ball spot-checks spanning the
+  grid corners and every bank type, symbol coverage (every port in exactly one box), and mapping
+  bijectivity. Both non-test designs `jitx design build` with `status: ok`.
 - Every one of the 1369 balls was **independently re-checked against the AMD file** by a
   13-agent review fan-out (grid slices plus rails / GTM / symbols / conventions audits) — zero
   mismatches.
@@ -97,8 +97,8 @@ python -m jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga.tools.g
     .context/xcvp1002nfvi1369pkg.txt --report      # inventory + reconciliation
 python -m jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga.tools.generate_pinout \
     .context/xcvp1002nfvi1369pkg.txt --check       # committed module is regeneration-exact
-jitx build jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga.main.VersalFPGADesign
-jitx build jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga.main.VersalFPGACircuitDesign
+jitx design build jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga.main.VersalFPGADesign
+jitx design build jitxexamples.jumpstart_kits.js1_stackup_components.versal_fpga.main.VersalFPGACircuitDesign
 ```
 
 Expect roughly **2–3 hours** end to end for the full runbook with an agent (most of it

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js1-stackup-components/part3-versal-fpga/JS1_Part3_Versal-FPGA-from-Pin-File_Runbook.md

@@ -1,5 +1,5 @@
 <!--
-JITX Versal FPGA from the Vendor Pin File Runbook (JS1 · Part 3) · rev 1.4 · 2026-09-08
+JITX Versal FPGA from the Vendor Pin File Runbook (JS1 · Part 3) · rev 1.5 · 2026-09-14
 Paste this file into your AI coding agent (Claude Code, Codex / GPT, or Devin), or upload it,
 and tell the agent to follow it. Complete the JS0 Setup Runbook first.
 START A NEW AGENT SESSION before you begin — a skills install only takes effect in a session
@@ -16,7 +16,7 @@ boundary ports. At this pin count you do not transcribe a ball map: you **parse
 machine-readable package pinout file and generate the component**, then verify the generation.
 The pinout file is the **only** ground truth for pin names, balls, and banks; AM013 (AMD's Versal
 packaging manual) is the only ground truth for package geometry. Estimate nothing; if the data doesn't say it, ask me. Follow
-the steps **in order**; nothing is done until it passes its checks and `jitx build <non-test design target>`. Where a step
+the steps **in order**; nothing is done until it passes its checks and `jitx design build <non-test design target>`. Where a step
 is marked **[HUMAN]**, stop and wait for me — do not proceed until I confirm.
 
 > **For humans:** prerequisites are a completed **JS0** (authenticated `jitx` CLI, `jitx-skills`
@@ -52,7 +52,7 @@ when a step names one, rather than working from the summary here.
 4. Partition the **schematic symbols by bank**.
 5. Wrap the component in a **circuit** that exposes rails, ground domains and GTM quads as
    JITX-native boundary ports.
-6. Verify at every stage: `pyright` → `pytest` → `jitx build <non-test design target>` → the `jitx-code-review` skill.
+6. Verify at every stage: `pyright` → `pytest` → `jitx design build <non-test design target>` → the `jitx-code-review` skill.
 
 ### What this task supplies
 
@@ -89,7 +89,7 @@ re-derive it. What is specific to *this* task:
 ```bash
 pyright                 # expect zero errors and zero suppressions
 pytest                  # the skill's test shape, plus this task's additions
-jitx build <non-test design target>  # both designs: component viewer + circuit wrapper
+jitx design build <non-test design target>  # both designs: component viewer + circuit wrapper
 ```
 
 A `pyright: ignore` you feel you need is a finding to report, not a way to reach zero. Run the
@@ -124,14 +124,14 @@ $env:PYTHONUTF8 = "1"; py -3 -m venv .venv; .\.venv\Scripts\Activate.ps1
 pip install jitx
 jitx project dependencies upgrade
 jitx runtime start --background
-jitx find
+jitx design find
 ```
 
-Build the seeded non-test target from `jitx find` — ignore any target whose module path comes from
-`test`, `tests`, or a test file. **Take the target verbatim from `jitx find`** — the two halves are
+Build the seeded non-test target from `jitx design find` — ignore any target whose module path comes from
+`test`, `tests`, or a test file. **Take the target verbatim from `jitx design find`** — the two halves are
 derived differently, so don't assemble it yourself: the package is the directory lowercased with
 hyphens and spaces turned into underscores, while the design class is that same name in CapWords. A
-directory called `js1-versal-fpga` builds as `jitx build js1_versal_fpga.main.Js1VersalFpga`. This
+directory called `js1-versal-fpga` builds as `jitx design build js1_versal_fpga.main.Js1VersalFpga`. This
 smoke test must succeed before you write any code of your own. If it fails, stop and tell me. Then
 prepare the project: create `tests/`, add `pytest` and `pyright` as dev dependencies, and `git init`
 if you want version control. Leave the seeded `.gitignore` as it is.
@@ -244,7 +244,7 @@ ports == assignments == pads, the per-rail counts from your step-4 inventory, ~1
 checks spanning `A1`, `AU37`, a double-letter row and one pin per bank type. Follow that section's
 cached-instantiation requirement rather than one build per assertion — at this pin count it is the
 difference between a suite of seconds and one that times out. Then: `pyright` →
-`pytest` → `jitx build <non-test symbol-viewer design target>` (expect `status: ok`) → run the
+`pytest` → `jitx design build <non-test symbol-viewer design target>` (expect `status: ok`) → run the
 `jitx-code-review` skill and fix findings. Commit when green.
 
 **10 · [HUMAN] Spot-check the balls.**
@@ -285,13 +285,13 @@ the sequence form is the first thing you will reach for and the first thing that
 
 And name the boundary rail ports distinctly from the net names (`pwr_vccint`, not `VCCINT`) — a
 named net colliding with a public port name fails only in the full runtime build ("Public name
-already in use"); `jitx build --dry` cannot see it.
+already in use"); `jitx design build --dry` cannot see it.
 
 **12 · Verify the circuit.**
 Extend the tests (rail roster + sizes, ground-domain separation, 6 quads × 20 topology links **and**,
 for at least one quad, that each link's two endpoints are the expected bundle sub-port and component
 ball — a count alone passes a lane- or polarity-swapped wiring; circuit design translates), then
-`pyright` → `pytest` → `jitx build <non-test circuit design target>` →
+`pyright` → `pytest` → `jitx design build <non-test circuit design target>` →
 `jitx-code-review`. Commit when green.
 
 **13 · [HUMAN] Close the loop.**
@@ -326,7 +326,7 @@ package, and it reaches me looking exactly like a verified one.
   single-ball ones — with three distinct ground domains, and all six GTM quads as bundles wired
   through the structural pin groupings; zero `getattr` anywhere.
 - `pyright` clean with no suppressions, `pytest` green — with the regeneration-idempotency test
-  confirmed to have *run*, not skipped — both non-test designs `jitx build` with `status: ok`, and a
+  confirmed to have *run*, not skipped — both non-test designs `jitx design build` with `status: ok`, and a
   `jitx-code-review` pass has run with findings fixed.
 - The component carries the skill's filled **Component completeness check** block, written next to
   the code, with the agreed `mpn` and what it identifies recorded in its `Identity` row.

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/jumpstart-kits/js1-stackup-components/part3-versal-fpga/README.md

@@ -37,13 +37,13 @@ add `GTMQuad` (4 lanes + 2 refclks) and `XCVP1002Circuit`: 31 `Power` rails, thr
 (GND / GND_SMON / GND_SENSE), and six GTM quad bundles wired through the generated pin groupings.
 
 **How we know it's right.** Reconciliation runs before any code: parsed rows = file footer = 1,369,
-unique balls, full 37×37 grid. Then 19 tests and 198 subtests on jitx 4.4 — hand-read ball
-spot-checks across grid corners and every bank type, symbol coverage, mapping bijectivity, circuit
-rail roster. Both designs, the component viewer and the wrapped circuit, build `status: ok` against
-the runtime. An independent 13-agent review re-checked all 1,369 balls against the AMD file with
-zero mismatches. A fresh agent replayed the runbook in an empty project and landed a ball map
-identical to the reference, 1,369/1,369 on name, row and column. And the geometry checks out: A1 ↔
-AU37 pad centers = 36 × 0.92 = 33.12 mm on both axes, exactly AM013's D1/E1.
+unique balls, full 37×37 grid. Then the offline suite on jitx 4.4 — hand-read ball spot-checks
+across grid corners and every bank type, symbol coverage, mapping bijectivity, circuit rail roster.
+Both designs, the component viewer and the wrapped circuit, build `status: ok` against the runtime.
+An independent 13-agent review re-checked all 1,369 balls against the AMD file with zero mismatches.
+A fresh agent replayed the runbook in an empty project and landed a ball map identical to the
+reference, 1,369/1,369 on name, row and column. And the geometry checks out: A1 ↔ AU37 pad centers =
+36 × 0.92 = 33.12 mm on both axes, exactly AM013's D1/E1.
 
 **Close the loop.** *"give me GTM quad 205 as a 4-lane bundle and tell me which power rails and bias
 pins it needs"* — answered live from the built circuit.

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/src/jitxexamples/jumpstart_kits/js1_stackup_components/versal_fpga/main.py

@@ -14,7 +14,7 @@ Two deliberately minimal ``SampleDesign``s:
 
 Build (runtime required)::
 
-    jitx build jitxexamples.jumpstart_kits.js1_stackup_components.\\
+    jitx design build jitxexamples.jumpstart_kits.js1_stackup_components.\\
 versal_fpga.main.VersalFPGADesign
 """
 

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/test.log

@@ -174,7 +174,7 @@ tests/test_w25q128.py::TestW25Q128::test_w25q128 PASSED                  [ 98%]
 tests/test_xunpu_ts_1088_ar02016.py::TestTS1088AR02016::test_ts_1088_ar02016 PASSED [ 99%]
 tests/test_yangxing_tech_x322512msb4si.py::TestX322512MSB4SI::test_x322512msb4si PASSED [100%]
 
-======= 131 passed, 2 skipped, 586 subtests passed in 160.27s (0:02:40) ========
+======= 131 passed, 2 skipped, 586 subtests passed in 167.49s (0:02:47) ========
 Name                                                                                                     Stmts   Miss  Cover
 ----------------------------------------------------------------------------------------------------------------------------
 src/jitxexamples/components/__init__.py                                                                      0      0   100%

{jitxexamples-1.6.2 → jitxexamples-1.7.0}/tests/test_js1_parametric_passives.py

@@ -36,7 +36,7 @@ class TestParametricPassivesShowcase(TestCase):
 
     def test_live_request_value_labels(self):
         # The value label is what a reader sees in the BOM, and it is the one
-        # thing pyright, pytest and `jitx build` all ignore. Scaling to an SI
+        # thing pyright, pytest and `jitx design build` all ignore. Scaling to an SI
         # prefix divides by a power of ten, so an exact 100 nF part renders as
         # "99.99999999999999 nanofarad" unless the magnitude is rounded back.
         design = ParametricPassivesShowcase()