An enterprise upgrade with the team's own libraries, and its video

.gitattributes

@@ -2,3 +2,4 @@
 *.svg text eol=lf
 *.png binary
 *.gif binary
+*.woff2 binary

.gitignore

@@ -12,3 +12,6 @@ evals/results/
 !CLAUDE.md
 !.claude-plugin/
 !.claude-plugin/**
+
+# The enterprise example's local registry keeps its packages here
+examples/enterprise/registry/storage/

ROADMAP.md

@@ -56,7 +56,16 @@ Everything else gets ordinary care, but none of these three gets traded away for
 - **Keep the version `ng update` picks inside a peer range (2026-11-08).** For a shared package the plan names the smallest move, while `ng update` takes the newest release the peers allow, such as TypeScript 5.9 where the plan said 5.8. The plan now prints the range, and anything inside it stays. *Why:* going back to the plan's pick fights `ng update` and costs a reinstall, and on readme-wizard an agent installed a package the re-run plan no longer listed. *Gave up:* the smallest possible move, for shared packages only. A library `ng update` takes a major further than the plan is reported, and the plan checks the license of the newest release that fits as well as its own pick.
 - **M7's internal libraries live in their own repo and reach the app through a private registry (2026-11-08).** A local Verdaccio on the Windows host stands in for a company's Artifactory or GitHub Packages. *Why:* "upgrade the libraries first" only means something when they're published separately, and that's how teams with shared UI libraries usually work. *Gave up:* the monorepo case, where `ng update` moves the libraries and the app in one go.
 - **M7's video is built with HyperFrames from the real run (2026-11-08).** Its terminal output, diffs and screenshots go into HTML scenes rendered to video, with a synthetic voice, captions and chapters, about 8 to 10 minutes, and short asides for newer and more senior developers. *Why:* it shows what really happened, and a scene can be fixed and rendered again without re-recording. *Gave up:* a live screen recording's feel.
+- **A scope with a registry of its own marks a library as the team's (2026-11-08).** *Why:* that's how a company publishes its packages (`@acme:registry=...`), and npm's own config already says it, so the plan keeps no list. *Gave up:* a company that serves everything, its own packages too, from one default registry gets no such hint. (Superseded by the 2026-11-08 decision on what the npm config shows.)
+- **The skill raises a Node pin the repo carries (2026-11-08).** A dev container, `.nvmrc`, `engines` field or CI workflow below the new Angular's range is raised in that major's commit. *Why:* those are the team's machines, and the upgrade would pass here and fail there. M7's dev container pins Node 22.12, which Angular 22 refuses. *Gave up:* a change outside the app's code that nobody asked for, so it's named under hand fixes. A pin outside the app's folder is raised only when it builds, tests or runs this app, since this app's checks can't catch what the change does to the rest of the repo. The plan reads only the Node major in a dev container's tag, so an image whose tag freezes an older Node, such as `typescript-node:1-22-bookworm` with Node 22.16.0, passes.
+- **The enterprise example lives in `examples/enterprise/`, as templates a setup script copies out (2026-11-08).** *Why:* the tutorial needs two repositories and a registry, which can't sit as git repositories inside this one, and anyone can rerun it from a clone. *Gave up:* the evals don't run it yet. A case could, with the registry started in CI.
+- **The video's source is in the repo, and the video isn't (2026-11-08).** `docs/video/enterprise/` keeps the narration, the scenes and the build scripts, and leaves out the voice, the timings and the render, which they make again. *Why:* being able to fix a line or a scene and render again is why it's built this way, and an eight-minute video would weigh down every clone. *Gave up:* making it again needs FFmpeg and a local Kokoro voice, and a render loads GSAP from a CDN.
 - **No unit test running stops the run, like a failing build (2026-11-08).** *Why:* on readme-wizard, one spec that didn't compile stopped Karma before any of its 20 specs ran, at the start and after all four majors, and the report called it one failing test. *Gave up:* one more question, on apps whose tests were already broken.
+- **The plan says what the npm config shows, and the skill confirms who owns the library (2026-11-08).** A blocker whose scope has a registry of its own gets a note naming that registry, and an offer to upgrade it first if it's the team's. *Why:* a licensed vendor sets up its registry the same way, as Font Awesome Pro does for `@fortawesome` and Infragistics for `@infragistics`, so the config shows the registry, not the owner. *Gave up:* the plan can't tell the team's library from a vendor's, so the skill checks the package's repository and author, or asks.
+- **Read a pnpm workspace's registry settings at its root (2026-11-08).** The plan reads the root's `.npmrc`, lays over it only the keys the app's own `.npmrc` sets, and tries `npm view` from the root's folder, then the app's, when a read needs a login. *Why:* pnpm reads the root's `.npmrc`, so a plan that looked only in the app's folder missed the team's registry and called a blocked app reachable. *Gave up:* pnpm 12 ignores the app's `.npmrc`, but the plan still lays its keys on top, as pnpm 10 and older do. An app inside an npm, yarn or bun workspace still gets no plan, because npm refuses to list its config there. And `ng update` from Angular CLI 22.0 and older reads only the app folder's `.npmrc`, so the troubleshooting guide shows how to give it the team's registry for that hop.
+- **When a library's release is too young for `ng update`, the runner installs it first (2026-11-08).** `update.mjs --install-first` starts from a clean tree, adds those libraries the way `package.json` lists them, checks that only `package.json` and the lockfile changed, then runs `ng update` for the rest with `--allow-dirty`. *Why:* from Angular CLI 22.1, `ng update` skips a release younger than the package manager's minimum release age and reads no exemption list, and the runner refuses `--allow-dirty` and a dirty tree on purpose. Doing the add in the runner also avoids cmd.exe dropping the `^` from a typed `pnpm add pkg@^22.0.0`. *Gave up:* an exemption the person approves needs a commit of its own first, and a library that ships migrations has to wait the day out, because installing it first skips them.
+- **The example's dev container pins corepack 0.34.7 (2026-11-08).** *Why:* the latest, 0.36.0, declares the image's Node 22.12 unsupported, and the image changed with every corepack release. 0.34.7 is the last whose engines include Node 22.12, and it starts pnpm 12.16.1. *Gave up:* newer corepack releases, until the image's Node is raised.
+- **A Node in a gap of Angular's range counts as too old (2026-11-08).** The plan calls a Node `unsupported` only when it's above every version in the range. One below the range, or in a gap of it such as 24.14 in Angular 22's `^22.22.3 || ^24.15.0 || >=26.0.0`, is `too-old`. *Why:* `ng` refuses to start on a Node in a gap, and the skill reads `unsupported` as carry on. *Gave up:* Node 23 and 25 sit in the gaps too, so they count as too old, though Angular CLI 22 only warns on them and runs.
 
 ## Shipped
 
@@ -103,14 +112,32 @@ Met on 2026-11-08. With the skill: yarn 16/16, bun 16/16 and the catalog 14/14,
 
 A company's app is rarely one package. This release takes one built like the real thing from Angular 21 to 22, and turns the run into a tutorial. The video is for developers who are new to agentic coding but not to development, and should still work for juniors and seniors.
 
-- [ ] A fixture: an Angular 21 app on the pnpm toolchain, with internal UI libraries whose peer ranges stop at Angular 21, so they have to reach 22 before the app can.
-- [ ] Set up for a dev container, and upgraded from the Windows host, not inside the container.
-- [ ] When a blocking library belongs to the person, offer to upgrade it first, in dependency order, besides waiting, replacing or forcing.
-- [ ] Take it to Angular 22 with the skill: the libraries first, then the app.
-- [ ] Make a video tutorial from that run.
+- [x] A fixture: an Angular 21 app on the pnpm toolchain, with internal UI libraries whose peer ranges stop at Angular 21, so they have to reach 22 before the app can. It's `examples/enterprise/`: `acme-ui`, `acme-portal` and a local registry.
+- [x] Set up for a dev container, and upgraded from the Windows host, not inside the container. Rebuilt afterwards, the container runs Node 22.23.4, builds the app and serves it.
+- [x] When a blocking library belongs to the person, offer to upgrade it first, in dependency order, besides waiting, replacing or forcing.
+- [x] Take it to Angular 22 with the skill: the libraries first, then the app. Claude Code did it in six turns from the Windows host, for $7.62. What it ran into, and what the skill learned from it:
+  - `ng update` refused at first, because the libraries' new 22.0.0 was minutes old. The agent blamed pnpm 12's minimum release age, and Claude Code's own safety check stopped it from relaxing that, so it asked. A later check showed pnpm installs a release named exactly and writes the exemption itself, unless `minimumReleaseAgeStrict` is set.
+  - Exempted, the release still failed: from Angular CLI 22.1, `ng update` applies the age rule in its own resolver and reads no exemption list. The agent found that in the CLI's source, then installed the releases by hand before updating Angular, with approval. `update.mjs --install-first` does that step now, and the troubleshooting guide gives the cause and both ways on.
+  - The agent missed the dev container's `FROM node:22.12.0`, and the container then refused Angular 22. The plan now names the repo's own Node pins below a major's range: from `.nvmrc`, `.node-version`, `.tool-versions`, a Dockerfile, the dev container and `package.json`'s `engines` and `volta`, in the app's folder and at the repo's root, and from GitHub workflows. The skill searches for the rest.
+- [x] Make a video tutorial from that run. It runs 7:52 in eight chapters, with captions and asides for newer developers and for team leads. Its source is in `docs/video/enterprise/`.
 
 **Done when:** the skill takes the libraries and then the app to Angular 22 from the Windows host, the dev container still builds and serves the app afterwards, and the video is made.
 
+Met on 2026-11-08. A review of the whole milestone afterwards found real problems, among them a pnpm workspace's `.npmrc` that the plan never read, so a blocked app looked reachable, and a way past the release-age rule that the runner refused to carry out. They're fixed, and what the review left for later is in M8.
+
+### M8: 0.5.0, the edges the enterprise run found
+
+M7's run and its review found places where the plan says too little, or can't run at all.
+
+- [ ] The plan checks release age the way the package manager and `ng update` do. A release younger than pnpm's `minimum-release-age`, yarn's `npmMinimalAgeGate` or npm's `before` makes the printed command fail, so the plan should name it and the wait instead of calling the hop ready.
+- [ ] A plan for an app inside an npm, yarn or bun workspace. npm refuses `config list` there with `ENOWORKSPACES`, so the plan exits today. It needs the workspace's root, lockfile and package manager. `npm prefix` can't find the root, because it masks path parts that look like secrets. Check too whether `ng update` from CLI 22.0 and older misses a scope registry set at such a root, as it does at a pnpm one.
+- [ ] Judge Node for Angular 22 and newer the way its CLI does, before Node 27 is stable. CLI 22 starts only on the majors its range lists, and warns on 23 and 25, so on Node 27 `ng` exits while the plan says ok.
+- [ ] Name a Node pin the plan can't read, such as `lts/iron` in `.nvmrc`, instead of counting it as fitting. Read a dev container at the repo's root (`.devcontainer.json`), and a Dockerfile that `build.dockerfile` names elsewhere.
+- [ ] Run the example's dev container on Docker Engine on Linux, which has no `host.docker.internal`: add the host gateway, and have the registry listen on the bridge address too, never on every address. Check it on a Linux host first.
+- [ ] Run the enterprise example as an eval case, with its registry started in CI, so a change that breaks it shows up.
+
+**Done when:** the plan names a release too young for the printed command, an app in an npm, yarn or bun workspace gets a plan, and the enterprise example runs in the evals.
+
 ## Later
 
 - Run the skill for real in GitHub Copilot. So far it's checked from Copilot's docs only.

docs/video/enterprise/.gitignore

@@ -0,0 +1,10 @@
+# Made from the sources here by tools/voice.mjs, tools/build.mjs and the HyperFrames CLI
+.voice/
+.hyperframes/
+assets/vo-*.wav
+timings.json
+index.html
+compositions/
+chapters.txt
+meta.json
+*.mp4

docs/video/enterprise/README.md

@@ -0,0 +1,28 @@
+# The enterprise upgrade, on video
+
+The source of M7's tutorial, where Claude Code with ng-hop takes [`examples/enterprise`](../../../examples/enterprise/) from Angular 21 to 22, the team's own libraries first. It's made with [HyperFrames](https://hyperframes.heygen.com) from the real run: the terminal lines, diffs and screenshots come from what the run did, and the narration is a synthetic voice.
+
+`script.mjs` holds the narration, a sentence at a time, and the styles every chapter shares. `scenes/<chapter>.html` holds a chapter's visuals, where `data-cue="s12"` brings an element in as sentence `s12` starts and `data-out` takes it away.
+
+## Make it
+
+It needs Node 22 or newer and FFmpeg. The voice also needs a Python with `kokoro-onnx` and `soundfile`, named in `HYPERFRAMES_PYTHON`.
+
+```sh
+node tools/voice.mjs   # the narration, and timings.json from it
+node tools/build.mjs   # index.html and compositions/, from the script, the scenes and the timings
+npx --yes hyperframes@0.9.22 check
+npx --yes hyperframes@0.9.22 render --quality delivery --output enterprise.mp4
+```
+
+After a scene changes, build, check and render again. After the narration changes, make the voice first, since every cue moves with it. The build also writes `chapters.txt`, the chapter list for the video's description.
+
+JetBrains Mono is under the SIL Open Font License, in `assets/fonts/LICENSE`.
+
+## What changed after the run
+
+The video shows ng-hop as it was during the run. A review afterwards changed three things a viewer may notice:
+
+- The plan no longer says a library "comes from your own registry". It names the registry the npm config sets for that scope, because a vendor's paid registry is set up the same way, and the skill checks who owns the library.
+- In "Publish, and a safeguard", the agent blames pnpm's minimum release age. pnpm in fact installs a release named exactly and writes the exemption itself. The cause was the age filter in `ng update`, which the next chapter finds.
+- The agent no longer has to find that filter itself. The troubleshooting guide names it, and `update.mjs --install-first` installs the young releases before updating Angular, the step the agent did by hand.

docs/video/enterprise/assets/fonts/LICENSE

@@ -0,0 +1,93 @@
+Copyright 2020 The JetBrains Mono Project Authors (https://github.com/JetBrains/JetBrainsMono) JetBrainsMono-Italic[wght].ttf: Copyright 2020 The JetBrains Mono Project Authors (https://github.com/JetBrains/JetBrainsMono)
+
+This Font Software is licensed under the SIL Open Font License, Version 1.1.
+This license is copied below, and is also available with a FAQ at:
+http://scripts.sil.org/OFL
+
+
+-----------------------------------------------------------
+SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
+-----------------------------------------------------------
+
+PREAMBLE
+The goals of the Open Font License (OFL) are to stimulate worldwide
+development of collaborative font projects, to support the font creation
+efforts of academic and linguistic communities, and to provide a free and
+open framework in which fonts may be shared and improved in partnership
+with others.
+
+The OFL allows the licensed fonts to be used, studied, modified and
+redistributed freely as long as they are not sold by themselves. The
+fonts, including any derivative works, can be bundled, embedded,
+redistributed and/or sold with any software provided that any reserved
+names are not used by derivative works. The fonts and derivatives,
+however, cannot be released under any other type of license. The
+requirement for fonts to remain under this license does not apply
+to any document created using the fonts or their derivatives.
+
+DEFINITIONS
+"Font Software" refers to the set of files released by the Copyright
+Holder(s) under this license and clearly marked as such. This may
+include source files, build scripts and documentation.
+
+"Reserved Font Name" refers to any names specified as such after the
+copyright statement(s).
+
+"Original Version" refers to the collection of Font Software components as
+distributed by the Copyright Holder(s).
+
+"Modified Version" refers to any derivative made by adding to, deleting,
+or substituting -- in part or in whole -- any of the components of the
+Original Version, by changing formats or by porting the Font Software to a
+new environment.
+
+"Author" refers to any designer, engineer, programmer, technical
+writer or other person who contributed to the Font Software.
+
+PERMISSION & CONDITIONS
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of the Font Software, to use, study, copy, merge, embed, modify,
+redistribute, and sell modified and unmodified copies of the Font
+Software, subject to the following conditions:
+
+1) Neither the Font Software nor any of its individual components,
+in Original or Modified Versions, may be sold by itself.
+
+2) Original or Modified Versions of the Font Software may be bundled,
+redistributed and/or sold with any software, provided that each copy
+contains the above copyright notice and this license. These can be
+included either as stand-alone text files, human-readable headers or
+in the appropriate machine-readable metadata fields within text or
+binary files as long as those fields can be easily viewed by the user.
+
+3) No Modified Version of the Font Software may use the Reserved Font
+Name(s) unless explicit written permission is granted by the corresponding
+Copyright Holder. This restriction only applies to the primary font name as
+presented to the users.
+
+4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font
+Software shall not be used to promote, endorse or advertise any
+Modified Version, except to acknowledge the contribution(s) of the
+Copyright Holder(s) and the Author(s) or with their explicit written
+permission.
+
+5) The Font Software, modified or unmodified, in part or in whole,
+must be distributed entirely under this license, and must not be
+distributed under any other license. The requirement for fonts to
+remain under this license does not apply to any document created
+using the Font Software.
+
+TERMINATION
+This license becomes null and void if any of the above conditions are
+not met.
+
+DISCLAIMER
+THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
+OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE
+COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
+DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
+OTHER DEALINGS IN THE FONT SOFTWARE.