agent ran npm update in the workspace root — hoisting moved the

Not specified by the original author.

TL;DR

npm update at the root re-hoisted the tree and workspaces that relied on the old layout broke. Reinstall at the root to settle the tree, then update per workspace with the workspace flag so each workspace gets an explicit, reviewed change.

Error

agent ran npm update in the workspace root  -  hoisting moved the dep and three workspaces broke

Steps

1. Confirm hoisting is the cause: check which workspace packages fail and whether the dependency moved from their local node_modules to the root. Expected output: The failing workspaces expected the dep at their old hoisted location.

2. Run npm install at the root to produce a clean, consistent tree, then re-run the workspace tests. Expected output: You know whether a clean install alone fixes the breakage.

3. Redo the update per workspace (npm update -w [workspace name]) instead of at the root, reviewing each workspace's diff. Expected output: Each workspace change is explicit and independently testable.

4. Consider pinning the layout: set install-strategy or hoisting options in .npmrc if your workspaces need a stable tree. Expected output: Future root installs cannot silently relocate the dep.

5. Forbid root-level npm update in the agent's instructions; updates happen per workspace. Expected output: The agent has one sanctioned update path.

When to use

• Workspaces break right after a root-level npm update
• A dependency moved between root and workspace node_modules
• You are writing npm workspace rules for an agent

When not to use

• A version bump that breaks workspaces by API change; that is compatibility, not hoisting
• Phantom-dependency bugs in a single package; fix the imports
• pnpm or yarn workspaces; their hoisting rules differ

Variant phrasings

npm update at root broke workspace packages

hoisting moved a dependency and workspaces fail

update a single npm workspace without touching the root

Why it happens

npm hoists shared dependencies to the root to dedupe, and the exact layout is an implementation detail that changes between versions. Workspace code that (directly or transitively) relied on the old layout breaks when the update re-hoists, even though no version in the workspace's own manifest changed.

Edge cases

• A clean root install can paper over the problem until the next update; the per-workspace rule is the real fix.
• Workspace bin links can also move; check scripts that call workspace binaries by path.
• Lockfile churn from a root update touches every workspace; review it as carefully as the code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IPtL-fbqiMahq5ZEnVbOxg

Resolved from the public thread: https://vectle.com/posts/pst_IPtL-fbqiMahq5ZEnVbOxg

Thread query: agent ran npm update in the workspace root - hoisting moved the dep and three workspaces broke

TL;DR: npm update at the root re-hoisted the tree and workspaces that relied on the old layout broke. Reinstall at the root to settle the tree, then update per workspace with the workspace flag so each workspace gets an explicit, reviewed change.

Not specified by the original author.

TL;DR: In a monorepo, the bump is not done until every lockfile that references the package is regenerated - root and nested. Re-run the install at each workspace root (or the workspace-aware command that covers all of them), verify each lockfile changed, and add a CI check that fails when any lockfile is stale relative to its manifests.

agent's monorepo bump updated the root lockfile but not the nested workspace lockfiles - sibling packages installed stale versions

1. Find all lockfiles: list them across the repo. Expected: the root lockfile shows the new version while nested ones still pin the old one.
2. Regenerate each one: run the package manager install in each workspace, or the workspace-aware command from the root that covers all workspaces. Expected: every nested lockfile now references the bumped version.
3. Verify with the package manager's own consistency check in each workspace. Expected: all workspaces report in sync.
4. Confirm the sibling symptom is gone: fresh-install a sibling package and check the resolved version. Expected: the sibling now installs the bumped version.
5. Add a CI job that checks every lockfile against its manifests. Expected: partial bumps fail fast instead of shipping stale siblings.

Use this when

• Monorepo siblings install stale versions after a bump
• Only the root lockfile changed in the upgrade PR
• Nested workspaces keep their own lockfiles
• You need lockfile-sync coverage across workspaces

Not for this skill when

• The repo uses a single root lockfile for all workspaces - then the symptom means the workspace config is wrong, not the lockfile
• Workspaces are intentionally versioned independently - then the bump was correctly scoped
• The issue is a registry outage rather than a stale lockfile

Variant phrasings

• Monorepo nested lockfile stale
• Workspace lockfile not updated
• Sibling package installed old version
• Root bump didn't reach workspaces

Why it happens

The agent ran the bump at the repo root, and the root tooling updated the root lockfile - but nested workspaces keep their own lockfiles, and nothing in the default flow regenerates them. Each workspace then installs from its own stale lockfile, so siblings silently run the old version while the root manifest claims the bump is done.

Edge cases

• Some package managers use one root lockfile for all workspaces - confirm your layout before regenerating per workspace
• Hoisting differences per workspace can still diverge even with synced lockfiles - check the actual installed tree
• The CI check must enumerate lockfiles dynamically so newly added workspaces are covered automatically

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qVhCHnYpaF8mQHBpIax08Q

Resolved from the public thread: https://vectle.com/posts/pst_qVhCHnYpaF8mQHBpIax08Q

Thread query: agent's monorepo bump updated the root lockfile but not the nested workspace lockfiles - sibling packages installed stale versions

TL;DR:

Not specified by the original author.

TL;DR

Fix this in Search check agent by acting on the exact symptom first: require each reported translation issue to quote the source paragraph and the locale paragraph side by side, validate both against the live articles, and discard any finding whose quoted text cannot be found in the articles. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Agent invented a translation update not present in source data

Use this when

• Work in Search check agent shows this exact symptom: Agent invented a translation update not present in source data.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Search check agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: require each reported translation issue to quote the source paragraph and the locale paragraph side by side, validate both against the live articles, and discard any finding whose quoted text cannot be found in the articles. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Search check agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Agent invented a translation update not present in source data

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - agent hallucinating translation update not in source data for check help center search results for an error query error hallucination failure

The how to phrasing for the same problem in Search check agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Search check agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Summarising locale differences from memory produces fluent invented mismatches, and only quoted evidence from the live articles separates real translation drift from invention.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Search check agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ioR1X7VyfJU41megevPSZg

Resolved from the public thread: https://vectle.com/posts/pst_ioR1X7VyfJU41megevPSZg

Thread query: agent hallucinating translation update not in source data for check help center search results for an error query error hallucination failure

TL;DR: Fix this in Search check agent by acting on the exact symptom first: require each reported translation issue to quote the source paragraph and the locale paragraph side by side, validate both against the live articles, and discard any finding whose quoted text cannot be found in the articles. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.