Cyberwise

Cyberwise

Verified: Cyberpunk 2077 patch 2.31 - August 2026 Every file under a references/ directory carries its own verification stamp and a Re-check after a patch line naming what to re-test first. Trust those over this one; some areas drift much faster than others.

Field notes for diagnosing a modded Cyberpunk 2077 install, at any scale, under any mod manager or none. This is not a modding tutorial - installing a mod and finding a log are assumed to be covered elsewhere. What follows is the set of things that are counterintuitive, undocumented, or actively contradicted by popular advice - each one learned by getting it wrong first.

Findings here are empirical, and most of the measuring happened on one large Vortex-managed install. Two consequences for how to use them. Where a claim is manager-specific, it names the manager - treat the same claim on another manager as untested rather than false. And where a worked example carries a big number, the number is that install's, not a threshold: the mechanisms fire identically on a twenty-mod list, they just fire less often.

Method, before anything else

These cost the most time when skipped, and they apply to every task below - they are why this front door exists rather than eight independent skills.

Read the installed patch version before trusting anything stamped with one.

(Get-Item "$GameRoot\bin\x64\Cyberpunk2077.exe").VersionInfo.ProductVersion   # -> 2.31

Every reference here carries a Verified: stamp. If the install reports a higher version, say so before answering - the reasoning holds, but offsets, record IDs and paths may have moved. (FileVersion is a build string and is not what anyone means by "the patch".)

Snapshot before every in-place write, and get approval on the DIFF, not the command. Nothing in this family modifies an install - but you will, by hand, and those edits have no undo. Someone who cannot read PowerShell can still read "this line becomes that line", and that is the only consent worth having. tools/ModFileBackup.ps1 does preview / snapshot / write / restore.

When a command produces nothing, prove it ran before interpreting the nothing. An empty result is the absence of evidence and looks identical whether the thing did not happen or the command never executed. Twice here a silent parse failure was read as a finding - # treated as a comment in modlist.txt produced 61 fabricated faults, and a path containing a space made Start-Process fail so quietly it was mistaken for a platform limit. Capture stderr, check the exit code, confirm the process exists.

A negative is only as wide as the layer you searched. "It does nothing" is a far stronger claim than "it does X", and one grep over one file cannot carry it. Name the layers the thing could act through - the mod's own config, the game's option registry, another control on the same subsystem, a native plugin - and until they are open, report "nothing in <layer>", not "nothing".

Find out how the install is assembled before you trust the filesystem - manual, Vortex, MO2 and Wabbajack lists show completely different pictures on disk. Two that bite hardest:

• An MO2 install may show an almost empty game directory (USVFS + Root Builder). "The file isn't there" proves nothing.
• On a Wabbajack list, updating the list DELETES every mod not in the new version, including any fix you add. Survivors must be named [NoDelete] ..., and those re-sort alphabetically, so order lives in the name too. Establish this before building anyone a fix.

Detection recipes and per-manager consequences: references/environment.md.

Answer the worry, not the mechanism. Most people here are modders, not developers. When someone asks "is this safe", "what does that do", "will this break my save" - answer that, in a sentence, without a lecture on how it works. Offer the detail second, for the ones who want it. And do the work yourself: if something needs building, installing or running, run it for them rather than handing over commands to paste.

Confirm the mod is actually deployed before theorising about why it fails. Hours have gone into explaining a mod that was staged but never deployed - and the manual-install equivalent, an archive unpacked one folder too deep, fails just as silently. On a virtualising setup, check the manager's own view.

Reproduce before bisecting. One crash or hang is not a deterministic fault. Confirm it repeats before halving anything, or you will bisect noise and "fix" it by coincidence.

Check your evidence actually discriminates. When testing "does earlier win or later win", make sure the two hypotheses predict different winners for the case you are looking at. In CP2077 this bites constantly: mods prefixed #/! sort early alphabetically and are usually placed early in load order too, so "earlier-in-list wins" and "later-alphabetically wins" often predict the same outcome. Three such cases prove nothing. Find a pair where the orders disagree.

Never quote a mod's shipped defaults as the user's configuration. Read the actual settings store (see references/environment.md). A mod's .reds or .xml declares what the author shipped, not what the user set. Keybinds are the worst case - there are five stores, not one, and a key you cannot find is not a key that is free (cyberwise-hotkeys).

A mod's own labels describe the mod, not the engine. That rule is about values; this one is about meaning. Comments, tooltips, INI section names and debug captions are the author's shorthand, and routinely misstate what a setting reaches or what gates it. Treat them as a lead; the game's own option registry declares the option itself and outranks them (references/environment.md).

Always dereference an internal name to something the user can find. Folder names, TweakXL namespaces, redscript modules and archive filenames are authored by mod authors for themselves and routinely bear no resemblance to the name the user sees - in a manager's list, or in their own notes on a manual install. Naming only the internal string ("ChipwareExpansion is doing this") leaves them unable to act. Give the display name, and the Nexus ID where one is recoverable. Where it is not recoverable - a manual install has no mapping from a deployed file back to a mod - say that instead of guessing. Recipe per manager: references/environment.md.

Do not hand your own guesses back to the user as their statements. Naming a mod you inferred and then writing "the mod is X, not Y" - as though they had said Y - wastes a turn and costs trust. If you worked something out, say you worked it out.

What the user saw in game outranks what a mod page says. They are running the build; documentation describes intent. When their observation contradicts your source, the source is what is wrong, and arguing the point is a waste of a turn.

And when the source that is wrong is one of these files, that is a report, not an embarrassment. A note that turns out to be false is worse than no note, so a user who can disprove one is doing the most valuable thing anybody does here. Offer to write it up - cyberwise-feedback gathers the facts and hands them a finished message. That applies just as much when the thing that got it wrong was you rather than the notes.

When a mod's author contradicts your reading of their mod, re-derive. Their word is not proof either, but it is a strong signal that a label was trusted or a layer was never opened. Check again at the authoritative source before either defending the reading or folding to the claim.

Check for drift at the start, and never edit a shipped tool quietly. One command, and it is the first thing to run on any Cyberwise task:

tools\Test-Upstream.ps1        # ~0.1s. Exit 0 nothing unlogged, 1 findings, 2 cannot check.

Then the behavioural half, which is the part a check cannot do for you. If you are about to edit a file Cyberwise ships - any tool, any SKILL.md, a test, the installer - say so to the user before you do it, say why, and record it in the change register. Not because changing it is wrong; because an unrecorded change is invisible to the next session, to the other agent, and to the person who has to decide a year from now whether they still want it.

And check first that the change is necessary at all. The commonest version of this failure is an agent patching a tool to solve something the family already has an affordance for:

Editing a shipped tool is the last option, not the first. When it is the right answer, one command records it:

. tools\UpstreamGuard.ps1
Register-CwChange -File '<path>' -What '<what changed>' -Why '<why>' -ApprovedBy '<who said yes>'

Full rationale, the two file formats, and what the check prints in each state: references/environment.md.

Ask the running game - CETMonkey is a prerequisite

Everything else here reads an install at rest. Live state - what is actually in the player's inventory, which status effects are applied, what a vendor really stocks - is answerable only from inside the running game, and CETMonkey is how.

bind\plugins\cyber_engine_tweaks\mods\cetmonkey\scripts\*.lua

List that folder before writing anything. Each script's first two comment lines are its title and description, so the Library reads as its own index. A whole duplicate CET mod was once built to dump an inventory while CETMonkey sat installed with a Library that runs scripts from a button - the same failure as inventing a load-order rule without opening modlist.txt.

Three things that decide whether a live query works at all:

• The CET console strips newlines from multi-line pastes, concatenating statements into a syntax error. Anything past one line must be read from a file. "Paste this into the console" is valid advice only for a true one-liner.
• Wrap every field read in its own pcall. The record worth finding is usually the one that does not resolve, so MISSING or <THREW> in a column is the finding - and a dump that dies on it, or skips it silently, destroys the only row that mattered.
• New scripts go in Vortex STAGING, then hardlink back. A file written into the deployed folder has link count 1 and dies at the next purge.

Read output.txt and log.txt yourself. Never ask for a screenshot of something that was written to a file.

Full contract - helpers, LuaJIT limits, the out-param return-slot trap, and the uiData / resolves columns: references/cetmonkey.md.

Do the work rather than proposing it

When the research converges on one path, build it. Strike the options that are impossible and merge the ones that are steps of the same plan; if one remains, that is not a choice to offer - it is the job. Ship it, then say in two lines what it does and what you were unsure about.

A proposal is the right output only for genuinely different paths with different consequences, for outward-facing or hard-to-reverse actions (publishing, filing, deleting, spending), and for design questions that are the user's by right. Everything else gets built.

Wrong work costs one message to redirect. Stopping to ask costs a round trip every single time, and reads as withholding something already asked for. wiki/process/do-the-work-do-not-propose-it.md.

To find out whether a mod took effect, READ THE LOGS

Not the deployed file list. Not archive\pc\mod\. Not what is on disk when you happen to look. The framework that loaded it writes down what it did, and that record covers the moment the user actually ran the game:

A file listing describes this instant; a log describes the run. A mod that was installed, tested, found wanting and uninstalled leaves an empty folder and a full log. Reading the folder and concluding "it was never installed" is a statement about the USER, made from evidence that cannot support it - and it lands as calling them careless. On 2026-08-28 that is exactly what happened, to a modder of thirty years, over a mod they had installed, tested and removed before the folder was ever looked at.

The logs were sitting there the whole time, with an explicit [WorldStreaming] Patching sector line naming what ArchiveXL did and did not apply.

So: never infer from absence on disk. Open the log for the run in question, find the entry for the mod by name, and quote it. If there is no entry, say the log has no entry for it - which is a fact about the log, not about the person.

NEVER claim what the base game does or does not contain

The base game is a file on disk. Read it before saying what is in it.

# what shipped with the game        vs        what is live with mods loaded
r6\cacheinal.redscripts                     r6\cacheinal.redscripts.modded

Check the mtimes and sizes first. r6\cache\moddedinal.redscripts is a DIFFERENT and often stale file - on one install it was four days old and 16 MB while the live modded bundle beside it was 40 MB and rewritten at every launch. Claims sourced from it were claims about a snapshot nobody was running.

A symbol in a bundle is not a feature in the game. RemoteBreach greps clean out of the vanilla bundle; remote breach on devices is nevertheless supplied by CustomHackingSystem plus a mod that configures it. The class was compiled. That says nothing about whether a player can ever reach it. Symbol presence rules things OUT, never in.

To establish that a feature exists in play, one of these - not a grep:

Why this earns its own rule. On 2026-08-26 a satellite dish that could not be breached was investigated for two days across four releases on the strength of guesses about backdoors, access points and cyberware prerequisites. The user had already stated that remote breach is not vanilla, and was contradicted from a stale bundle. One log line listing the device's offered actions settled in a second what the guessing had not: the action was present, the mod permitted it, and the mod that supplies its minigame had crashed during setup that morning. Every hour of that was avoidable by reading a file first.

Related: wiki/process/the-deployment-manifest-says-who-ships-what.md, wiki/process/proximity-is-not-evidence-without-a-base-rate.md.

NEVER name a mod you have not confirmed is installed

tools\Test-ModPresent.ps1 -GameRoot '<path>' -Name 'Immersive Gigs','Dark Future'

Exit 1 if any of them is absent. Run it before a report, a suspect list, or a sentence that names mods.

Why it matters more than it looks. On 2026-08-23 a crash suspect list named AnywherePrologueUnlock. It had been uninstalled, and the user had to say so. The cost was not the wasted line - it was that every other name in the list became worth less, because a diagnosis is only worth what its weakest claim is worth. "That mod isn't even installed" is the fastest way to make somebody stop believing the rest.

It happens by taking a name from memory instead of from disk, and the stale sources all look authoritative:

That last one is the one that catches an agent. A list assembled twenty minutes ago is not evidence about now, and on an install being actively worked on it is frequently wrong.

A feature that works for everyone else is not the thing to route around

If something is supposed to work, and works for thousands of other people, and does not work on this install - something is WRONG. Find it. Do not design a way to live without it.

A workaround written down becomes a rule, and the rule outlives the fault. On 2026-08-22 a CET overlay was dead for five hours. Once the cause was known - a second keyboard emitting phantom key events - the tempting conclusion was "never rebind CET's overlay through its UI, write the value to the file instead." CET's UI is not broken. It works for everyone. Recording that would have taught every future reader a false fact about CET that outlasted the broken keyboard.

A workaround is legitimate only as a stated temporary measure while the hunt continues. It is never the answer, and it never goes into a skill, a reference or a memory as guidance. When the cause turns out to be hardware or environment, fix or remove THAT - do not adapt the practice around it.

The same rule applies to describing what happened: what was done on the night is history; what to do next time is guidance. Only the second kind should read as instruction, and only when it is actually true in general.

For an input problem, inventory the physical inputs FIRST

One WMI query, before any software:

cyberwise-hotkeys	ools\Get-Hotkeys.ps1 -Devices

It names every keyboard the machine has, flags virtual endpoints, and says what more than one physical keyboard means. The failure that produced this rule went through five binding stores, CET's config and state files, the D3D12 render hook, ReShade, RTSS, Discord, DisplayFusion, Game Bar, accessibility filters, keyboard filter drivers and 425 mods parked in a bisect round - while Win32_Keyboard had been reporting four keyboards the entire time and nobody asked.

A keyboard switched OFF but still cabled still enumerates and still reports. Its switch is the radio, not the USB interface. On plug-in or power transition a faulty one emits a key-down with no key-up; every program running at that instant believes the key is held for the rest of its life. That is how a hotkey binding becomes a chord nothing can match, and how one app is unusable while others are fine - each tracks its own copy of the key state.

A virtual HID endpoint injects at driver level, so its events carry no INJECTED flag. A low-level capture showing "nothing is being injected" does not clear them.

Where records live - one place, agent-neutral

Anything this family must remember about an install goes on disk beside the game's own data, never in the repo and never only in conversation:

%USERPROFILE%\Saved Games\CD Projekt Red\Cyberpunk 2077\Cyberwise\

It is agent-neutral, which is the point: Claude Code and Codex read the same path, so work begun under one is picked up by the other. A fact held in one agent's memory is invisible to the next and lost the moment the user switches - and an unrecorded override is an invisible one. Rationale and the full layout: references/environment.md.

The change register lives there too, and that is why. It records approved local modifications to files Cyberwise itself ships, so it has to survive a fresh clone, a hard reset, and an update that overwrites the working tree. A record of local changes kept in the repo is destroyed by exactly the event it exists for.

A generated page can ask for work - carefully

The reports here are dead HTML, so a sheet that has drifted from reality stays wrong: fixing it means leaving the page, finding a terminal and remembering a tool name. tools/Start-CwEndpoint.ps1 is a loopback service that lets a button on the page ask for the work instead.

"A local listener that runs prompts when poked" is a genuinely bad object to leave on a machine, and the obvious implementation is an exploit. Five properties make it safe, and none is optional:

Commands, script paths and arguments live in endpoint.actions.json, which ships. Adding a capability is an edit to that file and a review, never a runtime decision. Placeholders in an action's arguments are filled from the endpoint's own startup parameters - never from the caller.

GET /actions returns each action's real prompt text, which is what the page's ? lightbox must display. A page that shipped its own copy of the prompt could show one thing and send another, which would make inspecting it theatre.

Every request is appended to <records>\Cyberwise\endpoint.log, refusals included. The page must degrade on its own: if /health does not answer it falls back to a copy button, because the endpoint is an accelerator and must never become a dependency.

Know where each kind of mod lives

Not everything deploys to archive\pc\mod. A mod "missing" from there may simply not belong there:

All of those are relative to the game root, wherever this install put it - Steam, GOG and Epic all differ, and the drive is whatever the user chose. Establish the root once and build paths from it; never assume a default install location.

Some archives are written at runtime. At least one known mod (Dynamic Moon Phases) generates its .archive from an ASI at game start, so the file appears and vanishes between sessions. Because the mod ships no archive of its own, any check that compares deployed archives against installed copies - a manager's staging folders, or a manual installer's own record - reports it as an orphan. Never prune its entry as stale, and note it still needs a permanent slot in modlist.txt, because an unlisted archive sorts last and loses.

Tools here

Cyberwise watches itself, and it is advisory on purpose. skills\cyberwise\upstream.manifest carries a sha256 of every behaviour-bearing file the family ships - tools, SKILL.mds, tests, the installer. Wiki articles are deliberately excluded: they are meant to grow, and guarding them would fill the register with noise inside a day.

Every tool checks on startup, so a change gets noticed by the act of using the thing rather than by somebody remembering to look. It is silent when clean and one short line when not. It never blocks anything, and it is deliberately not a PreToolUse hook - one of those fails closed and blocks every Edit in every session on the machine, including the edit that would fix it.

Two words about tone, because they decide whether it survives: it reports "differs from upstream", never "corrupted" or "tampered". Plenty of people legitimately want their copy changed. The finding is the unlogged change, not the change.

tools\Test-Upstream.ps1              # the report; -All to include the files that match
tools\New-UpstreamManifest.ps1       # dry run: what WOULD become the new upstream
tools\New-UpstreamManifest.ps1 -Write

Rerun the generator after any deliberate change to a shipped file, the same way you rerun Get-ToolIndex.ps1 -Write after adding a tool - that is what keeps the manifest current rather than a fossil. If the change belongs to this install rather than to Cyberwise, register it instead; regenerating would erase the only evidence it exists, and the next update would take it away with nothing noticing.

Before a launch, ask what state the install is in.

tools\Test-InstallReady.ps1 -GameRoot '<path>'      # ~0.5s; -Deep reads the bundle

It sorts findings into fixed by launching and launching will not fix this, which is the distinction that makes any of it actionable. Script mods newer than the compiled bundle are the first kind and need no action at all; archives with no modlist.txt entry are the second, and they sort last and lose every file they contest until somebody notices. Reported together they are a wall of warnings; reported apart, one of them is the answer.

"The file is in r6\scripts" is not "the code is running." .reds mods run from a bundle compiled at launch, so a mod installed since the last launch is enabled, correct, and doing nothing - with no sign in game. Ask the bundle:

tools\Test-ScriptsLive.ps1 -GameRoot '<path>'            # what is stale
tools\Test-ScriptsLive.ps1 -GameRoot '<path>' -Mod 'X'   # one mod, symbol by symbol

It also catches the log traps that make this hard to check by hand - an archived redscript log is named for the run that replaced it, and a compile test overwrites the current one. Both in references/script-cache.md.

Fixing another author's mod? Register it. Register-ModPatch records the hash of their file as it was when you patched it; Test-ModPatches re-checks after any mod update and reports CHANGED, GONE or NOOVER. Without that, an override silently keeps winning over every fix the author ships afterwards - which is the one failure mode that makes overriding a whole file risky at all. See references/environment.md.

Dot-source it (. tools\ModFileBackup.ps1) and use Set-ModFileContent instead of Set-Content for anything inside a user's install. It prints the diff, takes a timestamped snapshot, then writes - and tells you the exact Restore-ModFile command to undo it. -WhatIf shows the diff and stops, which is the right first call.

It refuses files over 50 MB without -Force, because .archive files run to gigabytes and are never hand-edited - a backup tool that fills the disk is its own kind of damage.

Every tool in the family

Before you write a tool, read this table. It is the whole point of it. On 2026-08-22 a preset decoder was proposed and half-designed before anyone noticed that Decode-Preset.ps1 had shipped months earlier with the exact -Compare mode being asked for. A second copy of a tool is worse than no tool: it splits the tests, and whoever comes next finds whichever one they find first.

The table is generated from the tools on disk by cyberwise/tools/Get-ToolIndex.ps1, and the test suite fails when it drifts - a hand-kept index would be right the day it was written and quietly wrong after, which is worse than none, because an index gets trusted.

tools\Get-ToolIndex.ps1            # print it
tools\Get-ToolIndex.ps1 -Write     # after adding or renaming a tool

Which skill covers it

Load the one that matches. They are separate so that reading about keybinds does not cost you anything when the question is about textures.

Two references stay here rather than in one of those, because they bear on all of them: references/environment.md (manager behaviour, the settings store, compile-testing) and references/script-cache.md (what is actually in the compiled script bundle, and the log traps around it).

Both are now mostly pointers. The knowledge they used to carry lives in the base wiki - wiki/ INSIDE the cyberwise-wiki skill, so it installs with the skills and is readable from an installed copy, not only a checkout - because a skill file is instructions and a wiki article is knowledge, and those rot at different rates. The reference files keep the parts that change what you do, and name the article for the rest. Its /process area is worth reading before running a documentation pass over a whole load order; /patterns before attributing any setting to a user.

Read the wiki before re-deriving anything

Two bundles, and both are worth a look before starting work:

• the base wiki ships with these skills and holds game, engine and format knowledge plus cross-mod patterns. /process before running any documentation pass; /patterns before attributing a setting to a user.
• the user bundle, beside the game's own records, holds this install: its machine profile and one article per deployed mod. If it does not exist yet, create it - cyberwise-wiki/tools/Initialize-UserWiki.ps1 -GameRoot '<path>'
  • because until it does, every session pays again for facts somebody already established here.

A question like "what does this mod do", "why is this key bound to that", or "what is this machine capable of" should start with a grep of those bundles. The whole point is that the second time costs a lookup instead of an afternoon.

These are additive. A hotkey sheet is also an HTML deliverable, so that job wants cyberwise-hotkeys and cyberwise-reports. Load both.

cyberwise-backstory is the odd one out: it is about playing the game rather than fixing it, and none of the method rules above apply to it. It is here because this is where the Cyberpunk knowledge lives. If the question is about a character rather than an install, go straight there - the diagnostic rules will only get in the way.