library-manager: emit compiled .IntLib as 5th part-folder file (build_intlib step 7 + update rebuild)

SKILL.md

@@ -66,7 +66,7 @@ still lands somewhere the operator can retrieve.
 
 The rule is: **immediately after any successful part push to Gitea**, copy that part's
 `<MPN>_<make>_<typeid>/` folder — with its files intact (`<tag>.xlsx`, datasheet, `.SchLib`,
-`.PcbLib`) — into the connected folder. This is automatic and never a question, exactly like
+`.PcbLib`, `.IntLib`) — into the connected folder. This is automatic and never a question, exactly like
 the push itself. Details and the exact command are in *Copy the pushed folder to the connected
 folder* below.
 
@@ -111,6 +111,7 @@ library repo/
         <MPN>_data.pdf              the datasheet
         <symbol>.SchLib             user-provided
         <footprint>.PcbLib          user-provided
+        <MPN>_<make>_<typeid>.IntLib  compiled integrated library (SchLib+PcbLib in one)
 ```
 
 There is **no single master workbook** — each part carries its own sheet inside its folder.
@@ -363,14 +364,37 @@ and the Ultra-Librarian default-stripping behaviour — read `references/schlib_
 before building the parameter set. The values are already verified at this point, so this step
 inherits no verification loop of its own.
 
-### 7. Assemble the part folder
+### 7. Assemble the part folder — and compile the IntLib (fifth file)
 
-The staging folder `<tag>/` should now hold the four files: the per-part `<tag>.xlsx`, the
-datasheet (name it `<MPN>_data.<ext>`), the symbol, and the footprint.
+The staging folder `<tag>/` should now hold four files: the per-part `<tag>.xlsx`, the
+datasheet (name it `<MPN>_data.<ext>`), the symbol (`.SchLib`), and the footprint (`.PcbLib`).
 
-**Before pushing, check that the symbol has actually been filled** (step 6b). The part folder is
-not complete until it has. If the `.SchLib` still carries only Ultra-Librarian defaults, go back
-and run `schlib_write.py` — don't push, and don't ask the user whether to; just fill it.
+**Before compiling or pushing, check that the symbol has actually been filled** (step 6b). The
+part folder is not complete until it has. If the `.SchLib` still carries only Ultra-Librarian
+defaults, go back and run `schlib_write.py` — don't push, and don't ask the user whether to;
+just fill it. This ordering matters: the IntLib embeds the **finished** symbol, so it must be
+built *after* the SchLib parameters are written, not before.
+
+**Compile the integrated library** as the fifth file, so the folder ships a single ready-to-use
+`.IntLib` alongside the source SchLib/PcbLib. Run `build_intlib.py` against the two library
+files already in the folder, writing the output named after the part tag:
+
+```bash
+python scripts/build_intlib.py \
+    --schlib <stage>/<tag>/<symbol_name>.SchLib \
+    --pcblib <stage>/<tag>/<footprint_name>.PcbLib \
+    --out <stage>/<tag>/<tag>.IntLib
+```
+
+This is a pure-Python compile (no Altium needed): it embeds both libraries into one OLE
+compound file, reusing the bundled `assets/templates/intlib_container.IntLib` as the container
+skeleton, and self-validates by round-tripping the embedded libs. The symbol→footprint link
+lives inside the embedded SchLib (its RECORD=45 model link), so the compiled IntLib resolves
+the footprint on its own. Requirements: the `olefile` package, and the `.SchLib` **must** have a
+footprint model link (it will, after step 6b / a proper Ultra-Librarian export) — the script
+exits clearly if it doesn't. If the compile fails, fix the cause (usually a missing footprint
+model link) rather than pushing a folder without its IntLib; the IntLib is now a standard part
+of the deliverable. After it succeeds, the folder holds **five files**.
 
 ### 8. Push to the library repo, under the part's Class
 
@@ -380,8 +404,9 @@ python scripts/gitea_components.py push-part --folder <stage>/<tag> --typeid <ty
 ```
 
 This places the folder at `components/<Class>/<tag>/` — creating the Class folder if it
-doesn't exist yet, or pushing into it if it does — and commits and pushes. Confirm to the
-user where it landed. **Then copy the folder to the connected folder** (next section).
+doesn't exist yet, or pushing into it if it does — and commits and pushes all five files
+(xlsx, datasheet, SchLib, PcbLib, IntLib). Confirm to the user where it landed. **Then copy the
+folder to the connected folder** (next section).
 
 ### Copy the pushed folder to the connected folder — automatic, after every part push
 
@@ -634,4 +659,19 @@ change: nothing is overwritten until the engineer has verified the new version.
    - **Symbol/footprint** → copy the new `.SchLib`/`.PcbLib` into the folder under their proper
      names (replacing the old ones), then re-derive against the **new** files and rebuild with
      `--design` exactly as above (this is step 6 of the add flow). Still flag a genuine
-     symbol/footprint-vs-part misma
+     symbol/footprint-vs-part mismatch to the user rather than silently accepting it.
+
+   **Rebuild the IntLib whenever the symbol or footprint changed.** The `.IntLib` embeds copies
+   of the SchLib and PcbLib, so any update that touches either one leaves the old IntLib stale.
+   After the `.SchLib` is re-filled (and the footprint is in place), recompile it before pushing:
+
+   ```bash
+   python scripts/build_intlib.py \
+       --schlib work/<Class>/<tag>/<symbol>.SchLib \
+       --pcblib work/<Class>/<tag>/<footprint>.PcbLib \
+       --out work/<Class>/<tag>/<tag>.IntLib
+   ```
+
+   A values-only or datasheet-only update (symbol and footprint unchanged) doesn't require an
+   IntLib rebuild — the embedded libraries are still current — though rebuilding is harmless.
+   Then `commit-push` as usual, and the connected-folder copy carries the refreshed IntLib too.