**Problem:** `PsalmCheck`, `PhpCsFixerOnStringCode`, `EasyCodingStandardOnStringCode`, `RectorOnStringCode`, `PhpstanCheck` are all hard-wired to `sys_get_temp_dir()` + `shell_exec(vendor/bin/...)` — a fresh PHP CLI process, engine bootstrap, and (for Psalm) a directory-wide project scan on every single call. **Update 1 — this is no longer speculative for Psalm.** A time-boxed spike (PoC scripts + benchmark attached) proved out a genuine in-process path: - `Codebase::invalidateInformationForFile($path)` — called right after deleting the temp file — purges exactly the class/function storage that file registered, without touching stub-provided storage. Verified safe across 8 sequential in-process calls that deliberately reuse class/function names between calls (`Widget` declared 3×, `ReflectionClass`-touching code 2×): no crash, no stale-state false positives, all expected violations reported correctly. - Two more "obvious" recipes were tried and **rejected** by the same test, worth recording so nobody re-tries them: - No cache-busting between calls → silent correctness bug: a class name reused after its original temp file is deleted gets flagged `DuplicateClass` against a file that no longer exists. - `RuntimeCaches::clearAll()` between calls (the fix suggested by Psalm maintainers on [vimeo/psalm#4117](https://github.com/vimeo/psalm/issues/4117) back in 2020) *does* fix the above, but **reintroduces the exact crash `#4117` originally reported** (`Could not get class storage for reflectionclass`) on the currently-pinned Psalm 6.16.1 — it wipes stub-provided class storage, but the "stubs already visited" flag isn't reset, so stubs never get rescanned. This is a live gap in Psalm itself, not something we can fix on our side; already flagged upstream on [vimeo/psalm#11871](https://github.com/vimeo/psalm/issues/11871#issuecomment-5401230243) and [vimeo/psalm#11922](https://github.com/vimeo/psalm/issues/11922). - Benchmark, 5 representative snippets, same process reused across all 5: **~146 ms total** (11 ms bootstrap + one first-call cost of ~124 ms for the one-time stub scan + 1–5 ms per subsequent call) vs **~3842 ms** for the current `shell_exec` implementation — **~26× faster**, and the gap widens further with more calls since the stub-scan cost is paid once per process lifetime, not once per call. **Update 2 — php-cs-fixer spiked next, and it's an even cleaner win than Psalm. Now implemented: `InProcessPhpCsFixer` (`packages/postprocessors/src/InProcessPhpCsFixer.php`), with tests.** `PhpCsFixerOnStringCode`'s own docblock claimed php-cs-fixer "doesn't ship a small, stable, documented library API for fixing a string in-process (its Runner is built around Finder/file-based input)" — true of `Runner` itself, but `Runner::fixFile()` (`src/Runner/Runner.php:556`) is a thin wrapper around a much smaller sequence that's easy to replicate directly, without Finder/parallel-workers/cache/diff-manager: ```php $fixers = (new FixerFactory())->registerBuiltInFixers()->useRuleSet(new RuleSet(['@PSR12' => true]))->getFixers(); $tokens = Tokens::fromCode($code); $file = new SplFileInfo('/virtual/does-not-exist-on-disk.php'); // never read from disk, just used by fixers' supports() checks foreach ($fixers as $fixer) { if (!$fixer->supports($file) || !$fixer->isCandidate($tokens)) continue; $fixer->fix($file, $tokens); if ($tokens->isChanged()) { $tokens->clearEmptyTokens(); $tokens->clearChanged(); } } $fixed = $tokens->generateCode(); ``` - **No cross-call state hazard at all**, unlike Psalm — `Tokens::fromCode()` caches by a hash of the code content, not by file path, and php-cs-fixer has no symbol table. Deliberately fixed three different `class Widget` definitions back to back on the same virtual path in one process: no leakage, no false positives, correct output every time. No `invalidateInformationForFile()`-equivalent needed. `InProcessPhpCsFixer` holds its fixer list as a constructed-once property and is safe to reuse across calls — covered by `testRepeatedCallsWithReusedClassNamesDoNotLeakState`. - **Byte-identical output** to the real CLI (`vendor/bin/php-cs-fixer fix --rules=@PSR12`), diffed directly and asserted in `testProducesTheSameOutputAsTheShellExecPhpCsFixer`. - **`--allow-risky=no` parity checked, not assumed:** the CLI throws if the resolved rule set contains any risky fixer and `--allow-risky` isn't explicitly `yes`. The in-process version skips that check entirely, but `@PSR12` currently resolves to 0 risky fixers out of 51 — so behavior is identical *today*. If the rule set ever grows to include a risky fixer, the in-process version needs the same guard (`array_filter($fixers, fn($f) => $f->isRisky())` must be empty, or explicit opt-in) — not yet enforced by an automated check, still open (see acceptance criteria). - Benchmark, same 5 snippets: **~462.5 ms total** (~92 ms/call) for the current `shell_exec` implementation vs **~45 ms bootstrap** (`registerBuiltInFixers()`'s `Finder`-based class scan — the only real cost) **+ ~4.4 ms for all 5 calls** (sub-millisecond each) — **~9.3× faster** on this batch, and **>100× per call** once warmed up. **Update 3 — Rector spiked third: a real path exists, but full container reuse hit a genuine bug. Now implemented: `InProcessRector` (`packages/postprocessors/src/InProcessRector.php`), using the compromise variant, with tests.** The in-process entry point, built the same way Rector's own `AbstractRectorTestCase` bootstraps itself (not test-only — the underlying primitives are `LazyContainerFactory`, `RectorConfig::import()`/`boot()`, `ApplicationFileProcessor::processFiles()`, all outside the `Testing\` namespace). - ⚠️ **Reusing the booted container/`ApplicationFileProcessor` across multiple calls is NOT safe — TODO, not resolved.** On the 2nd and later `processFiles()` calls within the same booted container, `DeclareStrictTypesRector` silently stops firing: `declare(strict_types=1)` is correctly added on the first call processed by a given container, then silently omitted on every call after that, with no error, exception, or warning — a silent under-application of the configured rule set. Confirmed this is **not** about reused class/function names (it reproduces with entirely distinct class names across calls, e.g. `Foo` then `Bar`) — it's specifically about call position within one container's lifetime. Other rules (e.g. strict-comparison rewriting) keep working correctly on the 2nd+ call, so this isn't a full breakdown, just a targeted, silent one. Root cause not yet diagnosed. - **Shipped workaround: `InProcessRector` constructs a brand-new `LazyContainerFactory`/`RectorConfig`/`ApplicationFileProcessor` on every single `build()` call** (still zero `shell_exec`, same PHP process). No state carries over between calls because nothing is shared, so the bug above can't occur. Verified over 5 calls deliberately reusing `class Widget` 4 times: correct output every time, including `declare(strict_types=1)` — covered by `testRepeatedCallsAllGetDeclareStrictTypesAdded`. - This compromise is slower than the (buggy, unused) full-reuse path would have been, but still a clear win over `shell_exec`: benchmark on 5 snippets — **~2601 ms total** (~520 ms/call) for `shell_exec` vs **~484.6 ms total** for fresh-container-per-call (~403 ms for the first call in the process — one-time class-autoloading warm-up shared by everything after it — then ~20–27 ms per call) — **~5.4× faster** on this batch, and **~19–26× per call** once the process has warmed up. **Update 4 — a second, distinct bug found (and fixed) while adding `InProcessRector` alongside the existing `InProcessPhpcbf`: a cross-package PHP-token-constant collision.** Running `InProcessPhpcbf` (PHP_CodeSniffer) and `InProcessRector` (Rector, which bundles nikic/php-parser + requires `phpstan/phpstan`) in the **same PHP process** crashed on Rector's very first `LazyContainerFactory::create()` call, but *only* if PHP_CodeSniffer had already run first in that process: ``` Error: Token T_PUBLIC_SET has ID of type string, should be int. You may be using a library with broken token emulation vendor/rector/rector/vendor/nikic/php-parser/lib/PhpParser/compatibility_tokens.php:39 ``` Root cause: both `squizlabs/php_codesniffer` and `nikic/php-parser` (bundled inside `rector/rector`) polyfill not-yet-native PHP tokens (e.g. `T_PUBLIC_SET`, PHP 8.4) the same defensive way — `if (!defined($token)) { define($token, ...); }` — but they disagree on *what* to define it as: PHPCS defines a string sentinel (`'PHPCS_T_PUBLIC_SET'`), nikic/php-parser requires (and sanity-checks for) an int. Whichever loads first on a given request wins the race; if PHPCS wins, nikic/php-parser's own compat check throws the moment Rector is used afterward. Confirmed empirically that call order determines pass/fail (Rector-then-phpcbf: fine; phpcbf-then-Rector: crash), and that this reproduces with `InProcessRector` alone against `InProcessPhpcbf` — no third package involved. **Fix shipped:** `packages/postprocessors/token-compat-bootstrap.php`, registered as a Composer `files` autoload entry (`composer.json`), `require_once`s `rector/rector`'s bundled `nikic/php-parser/lib/PhpParser/compatibility_tokens.php` unconditionally at `vendor/autoload.php` load time — before *any* class in this package is touched, regardless of which one a caller uses first. This makes nikic/php-parser's int-based definitions win unconditionally; PHPCS's own `defined()`-guarded polyfill then just adopts them instead of defining its conflicting string version. Verified: the full postprocessors test suite (`InProcessPhpcbf`, `InProcessPhpCsFixer`, `InProcessRector`, `InProcessEasyCodingStandard` together) now passes regardless of test/call order. This is a real, general risk for the "ditch `shell_exec`, run tools in-process" strategy this whole issue is about: **any two in-process tools that each bundle their own copy of a token-polyfilling library (nikic/php-parser, PHPCS, possibly others) can collide the same way if they're ever loaded into the same worker process.** Worth keeping in mind for PHPStan and any future in-process spike — check for this class of conflict specifically, don't assume a tool that works fine alone still works fine next to the others. (Psalm, added in Update 6, doesn't bundle its own nikic/php-parser copy the way Rector does, and its own tests passed alongside the postprocessors package's suite without needing this fix — but it lives in a separate Composer package here, `packages/code-quality`, so the two never actually load into the same process together yet. Worth re-checking if that ever changes.) **Update 5 — ECS spiked last (as planned): also a clean win, same shape as php-cs-fixer. Now implemented: `InProcessEasyCodingStandard` (`packages/postprocessors/src/InProcessEasyCodingStandard.php`), with tests.** ECS is the "meta" tool (composes php-cs-fixer fixers + PHPCS sniffs behind one config), and its own `AbstractCheckerTestCase` gave the exact non-test-only bootstrap primitives, same shape as Rector's: `ServiceContainerFactory::create([$configPath])` → `ECSConfig::boot()` → `$ecsConfig->make(FixerFileProcessor::class)`. - Our `ecs.php` config is fixer-only (`withPreparedSets(psr12: true)`, all php-cs-fixer fixers under the hood, no PHPCS sniffs) — `FixerFileProcessor::processFileToString($path)` parses through php-cs-fixer's own `Tokens` machinery (the same `fileToTokensParser` chain `InProcessPhpCsFixer` uses directly), which caches by content hash, not file path. **Same safety property as php-cs-fixer: no cross-call state hazard from reusing the instance across calls that redeclare the same class name** — verified over repeated calls, same as `InProcessPhpCsFixer`'s test. - Unlike direct php-cs-fixer, still needs a real temp file per call (`processFileToString()` parses from a path), but never writes back to disk — the fixed code comes back purely as a string return value. - **Byte-identical output** to the real CLI (`vendor/bin/ecs check --fix --config=ecs.php`), diffed directly and asserted in a test. - Needed the same defensive PHP_CodeSniffer autoload guard `InProcessPhpcbf` already has (ECS's `ServiceContainerFactory` reflects on `PHP_CodeSniffer\Util\Tokens` even for a fixer-only config) — already covered by the same `token-compat-bootstrap.php` fix from Update 4, verified no conflict when `InProcessEasyCodingStandard` runs alongside `InProcessPhpcbf`/`InProcessRector`/`InProcessPhpCsFixer` in one test process. - Benchmark, same 4 snippets used for Rector: **~561.5 ms total** (~140 ms/call) for `shell_exec` vs **~15.5 ms bootstrap + ~6.8 ms for all 4 calls** (~22.3 ms total) — **~25× faster** on this batch, **~230× per call** once warmed up. - If `ecs.php` is ever changed to add PHPCS sniffs (not just php-cs-fixer fixers), `InProcessEasyCodingStandard` needs a `SniffFileProcessor` call alongside `FixerFileProcessor` (mirroring ECS's own `doTestFile()`) — not implemented, since the current config doesn't need it. Flagged in the class's own docblock. **Update 6 — PHPStan spiked last: a real, `@api`-marked in-process entry point exists and is what PHPStan's own production playground (phpstan.org/try) uses live — but replicating it produces silently wrong results, and the root cause wasn't found. Stays on `shell_exec`.** `PhpstanCheck`'s docblock claimed PHPStan has no stable internal API. That's not quite accurate: `PHPStan\DependencyInjection\ContainerFactory` is explicitly marked `/** @api */` on both the class and its constructor in `phpstan.phar`'s own source, and PHPStan's own team uses it directly (bypassing the CLI entirely) in their production Lambda-based playground runner — fetched from [phpstan/phpstan's `playground-runner/bref.php`](https://github.com/phpstan/phpstan/blob/2.2.x/playground-runner/bref.php): ```php $containerFactory = new ContainerFactory($tmpDir); $container = $containerFactory->create($tmpDir, [$configFile], [$codePath]); $analyser = $container->getByType(\PHPStan\Analyser\Analyser::class); $analyserResult = $analyser->analyse([$codePath], null, null, false, [$codePath]); $finalizer = $container->getByType(\PHPStan\Analyser\AnalyserResultFinalizer::class); $errors = $finalizer->finalize($analyserResult, true, false)->getErrors(); ``` - **Reproducing this exactly gives silently wrong (under-reported) results.** A function with an obvious type mismatch (`function add(int $a, int $b): string { return $a + $b; }`) gets flagged `"...should return string but return statement is missing"` (`MissingReturnRule`, wrong) instead of the correct `"...should return string but returns int"` (`ReturnTypeRule`) that the real CLI reports for the identical file. Worse: a textbook undefined-variable case (`echo $bar;` with `$bar` never assigned) reports **zero errors** in-process, while `vendor/bin/phpstan analyse` on the same file correctly catches it. - **Not just the playground's recipe — phpstan-src's own official test infrastructure gives the same wrong result.** Tried again following `PHPStan\Testing\PHPStanTestCaseTrait::getContainer()` + the pattern `AnalyserIntegrationTest::runAnalyse()` uses (both `@api`-marked, first-party test-writing helpers phpstan-src ships for extension authors) — including the one real gap found along the way (`$container->getParameter('bootstrapFiles')` needs a manual `require_once` loop after `ContainerFactory::create()`, which neither recipe does automatically). Fixing that changed nothing about the actual bug. - **Isolated to CFG/scope-based analysis specifically.** Reflection-based rules work correctly in-process (`totallyUndefinedFunctionXyz();` correctly reports `"Function totallyUndefinedFunctionXyz not found."`) — only rules depending on `NodeScopeResolver`'s statement-level scope/control-flow tracking (variable definedness, return-statement termination, expression type inference feeding `ReturnTypeRule`) silently produce nothing or a wrong fallback. - Root cause not found despite substantial investigation: confirmed `ReturnTypeRule` *is* registered in the container's `RuleRegistry` (`getRules(Return_::class)` lists it), confirmed the raw `Analyser::analyse()` result (before any finalizing/filtering) already lacks the expected error, ruled out `sourceLocatorPlaygroundMode`/`phpVersion`/other playground-specific parameters as the missing piece. The real CLI itself goes through a different, higher-level `AnalyseApplication`/`AnalyserRunner` service (which — outside `--debug` mode — spawns actual `proc_open()` worker subprocesses even for CLI runs), so it's possible the direct `Analyser` entry point is less battle-tested standalone than its `@api` marking suggests, despite being exactly what the playground uses live. - **Verdict: `PhpstanCheck` stays `shell_exec`-based.** Unlike Rector (found a working, if imperfect, workaround) or Psalm (found the exact right recipe), this one produces results wrong enough — a quality gate that silently stops catching real bugs — that shipping it would be worse than not spiking it at all. Worth a from-scratch upstream bug report to phpstan-src if this gets revisited (mirroring the Psalm issues filed earlier in this issue), but the repro isn't minimal enough yet to file as-is. - PoC scripts (`poc_phpstan.php` — playground-style, `poc_phpstan_v2.php` — official-test-helper-style) available on request; not committed anywhere since neither produced a usable result. **Direction (final — every non-PHPStan tool now has an in-process implementation, all five in code; PHPStan spiked and confirmed staying on `shell_exec`):** - **Psalm: done.** `InProcessPsalmCheck` (`packages/code-quality/src/InProcessPsalmCheck.php`) implemented and tested — holds a persistent `ProjectAnalyzer`/`Codebase` as an instance property, uses `invalidateInformationForFile()` after each `check()` call. Bonus finding while wiring this up: `Config::$find_unused_code` defaults to `true` even with no XML attribute set, and the CLI wires that into `Codebase::reportUnusedCode('auto')` — which is also what turns on `UnusedVariable` detection as a side effect. Missing this made the first draft silently under-report relative to `PsalmCheck` (caught by a test comparing issue *types* reported on the same bad-code fixture, not just pass/fail). Benchmark on the same 5 snippets as the PoC, run against the actual class: **3834.5 ms total** (`PsalmCheck`, shell_exec) vs **17.5 ms bootstrap + 136.5 ms for all 5 calls** — **~25× faster**, matching the PoC. - **php-cs-fixer: done.** `InProcessPhpCsFixer` implemented and tested. - **ECS: done.** `InProcessEasyCodingStandard` implemented and tested. - **Rector: done (compromise variant).** `InProcessRector` implemented and tested, with the fresh-container-per-call workaround. TODO below tracks upgrading to full reuse once the `DeclareStrictTypesRector` bug is understood. - **PHPStan**: spiked (Update 6) — a real `@api` in-process entry point exists, but produces silently wrong analysis results and the cause wasn't found. Stays on the interim path: an in-memory FS / process abstraction behind a swappable interface (real disk/process in prod, in-memory in tests) — the only tool left needing it. - Drop the `league/tactician`-as-process-abstraction idea entirely (already flagged as a naming mismatch — it's a command bus, not a process runner); if PHPStan ends up needing a process abstraction, it's a plain interface with a real-`proc_open` implementation, not a third-party package pretending to be one. - The 4 new `InProcess*` classes sit alongside their `*OnStringCode` `shell_exec` siblings (matching the existing `InProcessPhpcbf`/`PhpCbfOnStringCode` precedent) rather than replacing them outright — swapping the actual pipeline over to the in-process versions, and eventually removing the `shell_exec` ones, is a separate follow-up, not done as part of this issue. **Acceptance criteria (Psalm path) — done:** - ~~`PsalmCheck` no longer calls `shell_exec`~~ → `InProcessPsalmCheck` added alongside it instead (see Direction above); switching the pipeline over is a follow-up. - ✅ Regression test reproduces reused class/function names across calls (including one touching `ReflectionClass`) on a single persistent instance, asserting no crash and no `DuplicateClass` false positives. - ✅ Issue-type parity against the `shell_exec`-based `PsalmCheck` tested on a shared bad-code fixture. - ✅ Benchmark documented (this issue). **Acceptance criteria (php-cs-fixer path) — done:** - ~~`PhpCsFixerOnStringCode` no longer calls `shell_exec`~~ → `InProcessPhpCsFixer` added alongside it instead (see Direction above); switching the pipeline over is a follow-up. - ✅ Byte-identical output against the `shell_exec`-based behavior, tested (`testProducesTheSameOutputAsTheShellExecPhpCsFixer`). - ✅ `InProcessPhpCsFixer`'s constructor now throws `\LogicException` if the resolved rule set ever includes a risky fixer, instead of silently running it — closed via !3. - ✅ Benchmark documented (this issue). **Acceptance criteria (ECS path) — done:** - ✅ `InProcessEasyCodingStandard` added, byte-identical output tested (`testProducesTheSameOutputAsTheShellExecEcs`). - ✅ Cross-call state safety tested (`testRepeatedCallsWithReusedClassNamesDoNotLeakState`). - ✅ Benchmark documented (this issue). **Acceptance criteria (Rector path — compromise variant) — done:** - ✅ `InProcessRector` added, byte-identical output tested (`testProducesTheSameOutputAsTheShellExecRector`). - ✅ Regression test for the full-reuse bug: `testRepeatedCallsAllGetDeclareStrictTypesAdded` asserts `declare(strict_types=1)` applies correctly across repeated calls with the compromise (fresh-container-per-call) implementation. - ✅ Benchmark documented (this issue). - ✅ Docblock on `InProcessRector` explicitly explains why it's fresh-container-per-call, not persistent-instance, linking back to this issue's TODO. **Update 7 — root cause of the Rector full-reuse bug found (two, actually). `InProcessRector` stays fresh-container-per-call; a real fix depends on rector/rector upstream.** Went back to diagnose the TODO above properly. - **Root cause #1 (fully explains the originally-reported bug — reused container, distinct class names, e.g. `Foo` then `Bar`): `DynamicSourceLocatorProvider::provide()` caches its `AggregateSourceLocator` after the first call and never rebuilds it on later calls — except when running under PHPUnit:** ```php public function provide(): SourceLocator { // do not cache for PHPUnit, as in test every fixture is different $isPHPUnitRun = StaticPHPUnitEnvironment::isPHPUnitRun(); if ($this->aggregateSourceLocator instanceof AggregateSourceLocator && !$isPHPUnitRun) { return $this->aggregateSourceLocator; } ... } ``` `setFilePath()` updates the internal path list correctly on every call, but `provide()` keeps returning the *first* call's cached locator regardless — so reflection for the second file's method calls silently resolves against the wrong (first) file, which cascades into skipping `FileNode`-level rule application (`DeclareStrictTypesRector` included). **Fix confirmed**: calling `$dynamicSourceLocatorProvider->reset()` (already `ResettableInterface`, already `@api`, docblock literally says *"to allow fast single-container tests"*) right before each `setFilePath()` fully resolves this — verified `declare(strict_types=1)` applies correctly across repeated calls with **distinct** class names on one persistent, reused container. - **Root cause #2 (a narrower, separate bug found while stress-testing the fix above): reusing the *same* class name across calls, with a *different* method set each time, still breaks — `reset()` does not fix this one.** Traced it to `PHPStanServicesFactory` (`src/NodeTypeResolver/DependencyInjection/PHPStanServicesFactory.php`): Rector builds and holds its own **internal PHPStan container** for reflection/scope resolution (`new ContainerFactory(getcwd())` — the exact same class this issue's Update 6 already spiked directly, unsuccessfully). That container's `ReflectionProvider` appears to cache class reflection data by class name with no exposed reset, so a class name reused with a changed method set gets stale reflection data — the same category of caching problem Update 6 hit trying to use PHPStan in-process directly, just surfacing here through Rector's internal use of it instead. Not fixed; no reset hook found for it. - **Verdict: keep `InProcessRector` as-is (fresh container per call), don't switch to persistent reuse.** A code-generation library's realistic workload plausibly reuses the *same* class name across regenerate/edit cycles far more often than it uses genuinely distinct throwaway names — so root cause #2 alone rules out persistent reuse as safe by default, even though root cause #1 is now fully fixed and understood. Fresh-container-per-call already sidesteps both bugs by construction (nothing persists to go stale), so no code change to `InProcessRector` itself is needed or was made. - Root cause #1 filed upstream: [rectorphp/rector#9861](https://github.com/rectorphp/rector/issues/9861) — minimal repro, same treatment as the Psalm issues filed earlier in this issue. `DynamicSourceLocatorProvider::provide()`'s caching is gated behind `StaticPHPUnitEnvironment::isPHPUnitRun()` specifically, even though its own `reset()` method is explicitly `@api`'d for exactly this kind of external, non-PHPUnit caller. **Update 8 — closing this out. Root cause #1 filed upstream and rejected; root cause #2 investigated as far as is reasonable and confirmed unfixable from userland. `InProcessRector` stays fresh-container-per-call, final.** - Root cause #1's upstream report ([rectorphp/rector#9861](https://github.com/rectorphp/rector/issues/9861)) was closed by the maintainer (TomasVotruba) with: *"Rector is not designed to run without the process command. Closing as this is clearly AI slop with no real value."* No further engagement pursued — the repro and fix (`reset()`) stay valid and documented here regardless of upstream's stance; they're just not landing in rector/rector itself. - Went one layer deeper on root cause #2 before closing it out. `SafeDeclareStrictTypesRector` (not `DeclareStrictTypesRector` — that one requires an actual `namespace` declaration our test fixtures never had) is the rule actually responsible: it only adds `declare(strict_types=1)` if `StrictTypeSafetyChecker::isFileStrictTypeSafe()` finds no scalar-type coercions anywhere in the file, and that check calls `ReflectionResolver::resolveFunctionLikeReflectionFromCall()` for every method/function call in the file — if reflection resolution fails (returns null), the whole file is conservatively marked unsafe and the `declare` is skipped. - Tried clearing three distinct, real cache layers between calls, in order: `DynamicSourceLocatorProvider::reset()` (the root cause #1 fix, public `@api`), then `MemoizingReflectionProvider`'s and `MemoizingReflector`'s private per-class-name caches (`PHPStan\Reflection\ReflectionProvider\MemoizingReflectionProvider` / `PHPStan\Reflection\BetterReflection\Reflector\MemoizingReflector` — both `final`, no reset method, cleared via `ReflectionProperty::setAccessible()` since there's no public API for it), then PHPStan's own `ObjectType::resetCaches()` + `TypeCombinator::clearCache()` (the exact two calls `ContainerFactory::postInitializeContainer()` itself makes, per Update 6's spike). **The bug survived all three.** There's at least one more cache layer, almost certainly inside PHPStan's own `NodeScopeResolver`/`MutatingScope`, that isn't exposed and wasn't worth chasing further with reflection hacks against undocumented internals. - This confirms root cause #2 is the same architectural wall Update 6 already hit spiking PHPStan directly (in-process reuse of PHPStan's reflection/scope engine across redefined symbols isn't safely resettable via any public — or reasonably-reachable private — API) — just reached this time through Rector's internal use of that same engine rather than through our own direct use of it. - **Final verdict, no further action planned:** `InProcessRector` stays fresh-container-per-call. Both root causes are fully understood and documented; neither is fixable from our side without patching vendor code, which we won't do. This issue is done. **TODO — swap the real pipeline over — resolved, turned out to not apply.** - Checked: there is no "real pipeline" anywhere in this repo to swap. `PostprocessorInterface`/`QualityCheckInterface` implementations are only ever constructed in tests; there's no service container, config, CLI command, or Laravel service provider (`packages/laravel` has none) wiring them up. This is a pure library — composing the pipeline is the consumer's job, and the README/`doc/` examples are the actual "call site" a consumer copies from. Addressed the way that's actually actionable here: documented all 5 `InProcess*` classes (constructors, construct-once-and-reuse guidance, `InProcessRector`'s compromise caveat, `InProcessPsalmCheck`'s lifecycle requirement) as the recommended default in README/`doc/usePostProcessing.md` — closed via !4. **Attached:** PoC scripts — Psalm: `poc_naive.php`, `poc_stress.php`, `poc_fixed.php`, `poc_reload.php`, `poc_invalidate.php`, `bench_shellexec.php`; php-cs-fixer: `poc_pcsf_invalidate.php`, `bench_pcsf_shellexec.php`; Rector: `poc_rector.php` (reproduces the bug), `poc_rector_fresh_container.php` (safe compromise), `bench_rector_shellexec.php`; ECS: `poc_ecs.php`, `bench_ecs_shellexec.php`; PHPStan: `poc_phpstan.php`, `poc_phpstan_v2.php` (neither usable) — available on request. Implemented classes + tests: `packages/postprocessors/src/InProcess{PhpCsFixer,Rector,EasyCodingStandard}.php` + matching tests + risky-fixer guard, `packages/postprocessors/token-compat-bootstrap.php` (merged via !1), and `packages/code-quality/src/InProcessPsalmCheck.php` + `packages/code-quality/tests/InProcessPsalmCheckTest.php` (!2). Risky-fixer guard: !3. Docs: !4.